PCI DSS — Payment Card Industry Data Security Standard — Oracle Source

PCI DSS - Overview

The Payment Card Industry Data Security Standard (PCI DSS) is a global information security standard designed to prevent fraud through increased control of credit card data [cite:434][cite:448]. It was created in 2004 by the five major card brands — Visa, Mastercard, American Express, Discover, and JCB International — operating through the PCI Security Standards Council (PCI SSC) [cite:448][cite:429]. PCI DSS applies to every entity that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD), regardless of size or transaction volume — merchants, service providers, processors, acquirers, and issuers [cite:448][cite:425]. The current version is PCI DSS v4.0.1, published in June 2024 as a limited revision of v4.0, with 47 new requirements that became mandatory on March 31, 2025 [cite:430][cite:450]. The standard expanded from 370 to over 500 requirements, with a fundamental shift from periodic point-in-time validation to continuous compliance monitoring [cite:430]. PCI DSS is unique among major compliance frameworks in that it is not a government regulation but a contractual obligation — enforced through the merchant agreements between businesses, acquiring banks, and card brands, with a defined penalty structure ranging from $5,000 to $100,000 per month of non-compliance [cite:422][cite:428][cite:434]. Non-compliance discovered after a data breach triggers catastrophic additional costs including per-record fines, forensic investigation costs, card replacement fees, and potential termination of card processing privileges [cite:422][cite:431].

PCI DSS - What It Is

PCI DSS is a prescriptive, technical security standard comprising 12 high-level requirements organised under 6 control domains that collectively define the minimum security controls necessary to protect payment card data throughout its lifecycle [cite:423][cite:444].

The Six Domains and Twelve Requirements

Key PCI DSS Concepts

• Cardholder Data Environment (CDE) — The people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data [cite:429][cite:442]
• Scope — All system components included in or connected to the CDE; accurate scoping is the most critical and often most contentious element of PCI compliance [cite:439][cite:442]
• Compensating controls — Alternative controls that meet the intent and rigour of a PCI DSS requirement when the stated requirement cannot be met due to legitimate technical or business constraints [cite:434]
• Customised approach — New in v4.0: allows organisations to meet a requirement's stated security objective through controls of their own design, validated by a QSA [cite:430]
• Targeted Risk Analysis (TRA) — New in v4.0: a formal risk-based methodology to determine the frequency of certain recurring compliance activities (e.g., log reviews, password rotation) [cite:421][cite:430]

PCI DSS - Who It Applies To

PCI DSS applies to any organisation that stores, processes, or transmits cardholder data — regardless of size, geography, or industry [cite:448][cite:425].

Merchant Levels

Merchant levels are defined by annual transaction volume per card brand and determine the validation method required [cite:425][cite:426]:

Service Provider Levels

Third-party service providers (TPSPs) that store, process, or transmit cardholder data on behalf of merchants have their own compliance tiers [cite:439][cite:448]:

Industry Segments With PCI DSS Obligations

• Fintech — Payment processors, digital wallets, BNPL providers, embedded finance platforms [cite:448]
• E-commerce — Any online merchant accepting card payments; heightened requirements for payment page security (Req 6.4.3, 11.6.1) [cite:421][cite:430]
• Retail / Hospitality — POS environments, card-present transactions, POS device inspection requirements [cite:444]
• Insurance claims processing — When claim payments involve card data or payment card transactions [cite:425]
• Healthcare — When patient payments are processed via card; intersection with HIPAA for environments handling both CHD and PHI [cite:446]
• SaaS / Cloud — Cloud service providers hosting payment workloads; shared responsibility models under PCI DSS [cite:439]

TPSP Management Requirements

PCI DSS Requirement 12.8 mandates comprehensive third-party service provider management [cite:448][cite:442]:

• 12.8.1 — Maintain a list of all TPSPs with a description of services provided [cite:445][cite:442]
• 12.8.2 — Maintain written agreements requiring TPSPs to acknowledge responsibility for cardholder data security [cite:448]
• 12.8.3 — Establish a process for engaging TPSPs, including proper due diligence prior to engagement [cite:439][cite:445]
• 12.8.4 — Monitor TPSPs' PCI DSS compliance status at least annually [cite:448][cite:442]
• 12.8.5 — Maintain information about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any shared responsibilities [cite:439][cite:445]

PCI DSS - What It Requires - Network and System Security (Requirements 1–2)

Requirement 1: Network Security Controls

Install and maintain network security controls to protect the CDE [cite:444][cite:429]:

• Define and enforce firewall/router configurations that restrict connections between untrusted networks and the CDE
• Deny all traffic by default; permit only explicitly authorised connections
• Maintain network diagrams that identify all connections to/from the CDE
• Implement network segmentation to isolate the CDE from other networks
• Review firewall/router rule sets at least every six months
• v4.0.1 update: Network security controls now encompass firewalls, cloud security groups, SDN controls, and any technology that controls traffic flow [cite:430]

Requirement 2: Secure Configurations

Apply secure configurations to all system components [cite:444]:

• Change all vendor-supplied defaults (passwords, SNMP community strings, unnecessary accounts)
• Develop configuration standards for all system components consistent with industry-accepted hardening standards (CIS Benchmarks, NIST, vendor guidance)
• Implement only one primary function per server to prevent function conflicts
• Enable only necessary services, protocols, and ports
• Encrypt all non-console administrative access using strong cryptography

PCI DSS - What It Requires - Account Data Protection (Requirements 3–4)

Requirement 3: Protect Stored Account Data

Protect stored cardholder data [cite:441]:

• Minimise cardholder data storage; implement data retention and disposal policies
• Never store sensitive authentication data (SAD) after authorisation — this includes full magnetic stripe data, CVV2/CVC2/CID, and PINs/PIN blocks [cite:441]
• Mask PAN when displayed (first six and last four digits maximum)
• Render PAN unreadable anywhere it is stored using: one-way hash functions, truncation, index tokens with securely stored pads, or strong cryptography with associated key management [cite:441]
• Implement strong cryptographic key management processes [cite:441]

Requirement 4: Protect Data in Transit

Protect cardholder data with strong cryptography during transmission [cite:441]:

• Use TLS 1.2 or higher for transmission over open, public networks
• Never send unprotected PANs by end-user messaging technologies (email, SMS, instant messaging)
• Document and maintain security policies and operational procedures for protecting CHD in transit [cite:441]

PCI DSS - What It Requires - Vulnerability Management (Requirements 5–6)

Requirement 5: Malware Protection

Protect all systems and networks from malicious software [cite:444][cite:429]:

• Deploy anti-malware software on all systems commonly affected by malware
• Ensure anti-malware mechanisms are kept current, perform periodic scans, and generate audit logs
• Protect systems not commonly affected by malware through periodic evaluations

Requirement 6: Secure Development and Software

Develop and maintain secure systems and software [cite:444][cite:421]:

• Establish a process to identify security vulnerabilities using reputable outside sources and assign risk rankings
• Protect all system components from known vulnerabilities by installing applicable security patches within one month of release (critical patches)
• Develop software applications in accordance with PCI DSS and secure coding guidelines
• Requirement 6.4.3 (v4.0.1): Maintain an inventory of all scripts on payment pages; authorise and justify each script; implement integrity verification mechanisms [cite:430][cite:421]
• Requirement 6.4.3 was removed from SAQ A (January 2025 update) but remains a full PCI DSS requirement for all other validation types [cite:421][cite:424]

PCI DSS - What It Requires - Access Control (Requirements 7–9)

Requirement 7: Least Privilege Access

Restrict access to cardholder data and system components to only those individuals whose jobs require such access [cite:441][cite:444]:

• Define access needs for each role; implement role-based access control (RBAC)
• Default deny-all setting for access control systems

Requirement 8: User Identification and Authentication

Identify users and authenticate access to system components [cite:444]:

• Assign unique IDs to all personnel with computer access
• Implement multi-factor authentication (MFA) for all access into the CDE and for all remote network access
• v4.0.1: MFA requirements expanded; passwords must be at least 12 characters (or 8 if system doesn't support 12) [cite:430]

Requirement 9: Physical Access

Restrict physical access to cardholder data [cite:444]:

• Use facility entry controls (badge systems, locks, cameras)
• Distinguish between onsite personnel and visitors
• Inspect POS devices for tampering regularly
• Secure or destroy all media containing cardholder data

PCI DSS - What It Requires - Monitoring and Testing (Requirements 10–11)

Requirement 10: Logging and Monitoring

Log and monitor all access to system components and cardholder data [cite:444]:

• Implement audit trails linking all access to individual users
• Record audit trail entries for all system components (user identification, event type, date/time, success/failure, origination, affected data/component)
• Synchronise all critical system clocks (NTP)
• Secure audit trails so they cannot be altered
• Review logs and security events daily; use automated mechanisms (SIEM)
• Retain audit trail history for at least 12 months, with at least 3 months immediately available [cite:444]

Requirement 11: Regular Security Testing

Test security of systems and networks regularly [cite:423][cite:429]:

• Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) — This is unique to PCI DSS; ASV scans must be performed quarterly and produce a passing result (no vulnerabilities with CVSS score ≥4.0) [cite:423][cite:426]
• Quarterly internal vulnerability scans — Remediate and re-scan until passing [cite:429]
• Annual external penetration testing — By a qualified internal resource or external third party [cite:429][cite:432]
• Annual internal penetration testing [cite:429]
• Requirement 11.6.1 (v4.0.1): Deploy mechanisms to detect and alert on unauthorised changes to HTTP headers and payment page content in real time [cite:430][cite:421]
• Test network segmentation controls at least every six months [cite:429]

PCI DSS - What It Requires - Information Security Governance (Requirement 12)

Requirement 12: Organisational Policies and Programmes

Support information security with organisational policies and programmes [cite:444][cite:448]:

• Establish, publish, maintain, and disseminate an information security policy reviewed at least annually
• Implement a risk assessment process performed at least annually and upon significant changes
• Develop usage policies for critical technologies (remote access, wireless, removable media, email, internet, laptops, tablets)
• Define information security responsibilities for all personnel
• Implement a formal security awareness programme
• Screen potential personnel prior to hire (background checks)
• TPSP management (12.8) — Full lifecycle management of third-party service providers as detailed above [cite:448][cite:442]
• Implement an incident response plan; test the plan annually [cite:429]
• v4.0.1: Requirement 12.3.1 — Targeted Risk Analysis must be performed for each PCI DSS requirement that allows customised frequency [cite:421][cite:430]

PCI DSS - Governance Implications

PCI DSS compliance is not a one-time certification — it is a continuous governance discipline that must be embedded in operational processes, executive oversight, and technology infrastructure [cite:430][cite:429].

Continuous Compliance

PCI DSS v4.0.1 represents a fundamental shift from periodic point-in-time validation to continuous compliance [cite:430]:

• Requirement 11.6.1 mandates real-time detection of payment page changes (not daily or weekly) [cite:430]
• Continuous monitoring replaces snapshot assessments as the compliance paradigm
• Organisations must demonstrate compliance at any point, not just during annual audit windows

Ontic BOM Mapping

• model — AI/ML models used in payment fraud detection, transaction monitoring, and risk scoring operate within the CDE and must comply with all applicable PCI DSS requirements. Model training data containing CHD must be protected per Requirements 3–4. Model access controls must meet Requirements 7–8. Model deployment pipelines must follow Requirement 6 secure development practices [cite:430]
• oracle — PCI DSS itself is an oracle source — the authoritative standard defining payment security requirements. The ASV-approved vendor list, PCI SSC validation lists, and card brand compliance programmes constitute additional oracle sources. Requirement 6.3.1 requires maintaining an inventory of bespoke and custom software with identified vulnerabilities — a software bill of materials (SBOM) function [cite:444]
• ontology — The PCI DSS requirement taxonomy (6 domains → 12 requirements → sub-requirements → testing procedures) provides the compliance ontology. Control mappings to ISO 27001, NIST CSF, SOC 2, and HIPAA extend this ontology across frameworks [cite:440][cite:446]
• system_prompt — For AI systems processing payment data or operating within the CDE, prompt configurations that influence data handling, access decisions, or security-relevant outputs must be governed under PCI DSS change management (Requirement 6) and access control (Requirements 7–8) disciplines [cite:430]
• gate — PCI DSS defines multiple governance gates: quarterly ASV scans, annual penetration testing, annual ROC/SAQ validation, and Requirement 12.3.1 Targeted Risk Analyses are all compliance gates that must be passed before continued operations [cite:423][cite:429]
• security — PCI DSS is fundamentally a security standard: Requirements 1–11 define the technical and operational security controls. The CDE boundary, network segmentation, encryption, access control, logging, and testing requirements directly define the security BOM for any payment-processing system [cite:429][cite:441]
• signed_client — The AOC (Attestation of Compliance) is a signed document attesting to PCI DSS compliance, signed by both the QSA (for ROC) and the entity's executive officer. Digital signature and non-repudiation requirements support audit trail integrity for Requirement 10 [cite:426][cite:429]

E/A/D Axis Integration

PCI DSS - Enforcement Penalties

PCI DSS enforcement is contractual, not governmental — penalties flow through the card brand → acquiring bank → merchant/service provider chain [cite:434][cite:428].

Penalty Structure

Monthly non-compliance fines (assessed by card brands, passed through acquiring banks) [cite:422][cite:431]:

Data breach penalties [cite:422][cite:434]:

• Per-record fines: $50–$90 per compromised customer record [cite:431][cite:434]
• Card replacement costs: $3–$10 per card [cite:422]
• Forensic investigation costs: Mandatory PCI Forensic Investigator (PFI) engagement, paid by the breached entity
• Increased processing fees: Acquiring banks may increase transaction fees post-breach [cite:422]
• Termination of merchant relationship: Card brands may revoke processing privileges entirely [cite:422][cite:428]

Enforcement Mechanism

Penalties are not assessed directly by the PCI SSC (which is a standards body, not an enforcement body). The enforcement chain works as follows [cite:431][cite:434]:

1. Card brands (Visa, Mastercard, Amex, Discover, JCB) define compliance programmes and penalty structures
2. Acquiring banks are contractually obligated to ensure their merchants are PCI DSS compliant
3. Card brands fine the acquiring bank for non-compliant merchants
4. Acquiring banks pass fines to the merchant through contractual provisions in the merchant agreement
5. Merchants with persistent non-compliance risk termination of their merchant account and placement on the MATCH/TMF list (Mastercard Alert to Control High-Risk Merchants / Terminated Merchant File), effectively blacklisting them from card processing [cite:428][cite:434]

Card Brand Compliance Programmes

Each card brand maintains its own compliance programme with distinct requirements [cite:425]:

PCI DSS - Intersection With Other Frameworks

PCI DSS has significant overlap with other security and compliance frameworks, enabling control efficiencies for organisations subject to multiple standards [cite:440][cite:443][cite:449].

Cross-Framework Mapping

Compliance Efficiencies

The PCI SSC and NIST have published official mapping documents that enable organisations to [cite:449][cite:440]:

• Identify where a single control implementation satisfies requirements across multiple frameworks
• Prepare for cross-framework assessments using common evidence
• Reduce redundant testing and documentation
• Build a unified control library mapped to PCI DSS, NIST CSF, ISO 27001, SOC 2, and HIPAA simultaneously

GRC platforms such as StandardFusion, MetricStream, and OneTrust support automated control mapping across these frameworks [cite:440][cite:446].

PCI DSS - Recent Updates

PCI DSS v4.0.1 (June 2024)

PCI DSS v4.0.1 is a limited revision of v4.0, published by the PCI SSC in June 2024 [cite:450]. It includes corrections to formatting and typographical errors, clarifications of guidance and intent, and corrections to applicability notes. It does not introduce new requirements beyond those in v4.0.

March 31, 2025 Mandatory Cutover

47 requirements that were designated as "future-dated" in v4.0 became mandatory on March 31, 2025 [cite:430]. Key newly mandatory requirements include:

• Requirement 3.5.1.2 — Disk-level or partition-level encryption is no longer an acceptable method to render PAN unreadable on non-removable electronic media [cite:430]
• Requirement 6.4.3 — Maintain inventory and integrity verification of all scripts on payment pages [cite:430][cite:421]
• Requirement 8.4.2 — MFA for all access into the CDE (not just remote access) [cite:430]
• Requirement 11.6.1 — Real-time detection and alerting on unauthorised changes to HTTP headers and payment page content [cite:430][cite:421]
• Requirement 12.3.1 — Targeted Risk Analysis to support customised frequency controls [cite:421]

SAQ A Updates (January 2025)

In response to industry feedback, the PCI SSC announced significant modifications to SAQ A [cite:421][cite:424]:

• Removed Requirements 6.4.3, 11.6.1, and 12.3.1 from SAQ A
• Added new eligibility criteria requiring merchants to "confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)" [cite:421]
• The October 2024 SAQ A version was retired on March 31, 2025; the January 2025 version became effective from that date [cite:421]
• Important: removal from SAQ A does not remove or diminish the underlying PCI DSS requirements — SAQ A represents a streamlined validation method for the lowest-risk merchants [cite:421]

Key Thematic Shifts in v4.0/4.0.1

• Continuous compliance — Shift from periodic point-in-time assessments to ongoing monitoring and real-time detection [cite:430]
• Customised approach — New validation option allowing organisations to meet security objectives through custom-designed controls [cite:430]
• Supply chain security — Enhanced scrutiny of third-party service providers and software supply chain [cite:441][cite:448]
• Targeted Risk Analysis — Formalised risk-based methodology to determine compliance activity frequency [cite:421]
• Authentication hardening — Expanded MFA requirements and password length/complexity standar