PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements designed to protect cardholder data wherever it is stored, processed, or transmitted. Maintained by the PCI Security Standards Council, the standard applies to every organisation in the payment chain — from multinational retailers and payment processors to small e-commerce shops and SaaS platforms that handle card data on behalf of their customers.
Unlike voluntary frameworks such as SOC 2, PCI DSS carries direct financial consequences for non-compliance. Organisations that fail to meet the standard risk fines of up to $100,000 per month, increased processing fees, and — in the worst case — the complete loss of their ability to accept card payments. For any business where card transactions are part of the revenue model, PCI DSS compliance is not optional.
A brief history of PCI DSS
Before PCI DSS existed, each card brand operated its own data security programme. Visa had the Cardholder Information Security Programme (CISP), Mastercard had Site Data Protection (SDP), and American Express, Discover, and JCB each maintained separate requirements. Merchants accepting multiple card brands faced overlapping and sometimes contradictory obligations, making compliance burdensome and inconsistent.
In 2004, the five major card brands collaborated to release PCI DSS v1.0 — a unified standard that replaced their individual programmes. Two years later, in 2006, they formalised this collaboration by founding the PCI Security Standards Council (PCI SSC), an independent body responsible for developing, maintaining, and promoting the standard.
The council does not enforce compliance directly. Enforcement remains the responsibility of the individual card brands, which delegate day-to-day oversight to acquiring banks and payment processors. The PCI SSC focuses on the standard itself, along with supporting programmes for assessor qualification, scanning vendor approval, and payment application validation.
Key version milestones
| Version | Released | Notable changes |
|---|---|---|
| v1.0 | December 2004 | First unified standard across all five card brands |
| v2.0 | October 2010 | Clarified scope and introduced virtualisation guidance |
| v3.0 | November 2013 | Added penetration testing methodology, expanded education requirements |
| v3.2 | April 2016 | Required multi-factor authentication for administrative access into CDE |
| v3.2.1 | May 2018 | Minor date corrections; remained effective until March 2024 |
| v4.0 | March 2022 | Major overhaul: customised approach, expanded MFA, e-commerce protections |
| v4.0.1 | June 2024 | Errata corrections and clarifications to v4.0 |
PCI DSS v4.0 — what changed and what it means
PCI DSS v4.0 represents the most significant revision since the standard’s inception. Version 3.2.1 was officially retired on 31 March 2024, and all organisations are now required to comply with v4.0. The future-dated requirements — those that were initially treated as best practices — became mandatory on 31 March 2025.
Major changes in v4.0
Customised approach. Version 4.0 introduces an alternative validation method alongside the traditional defined approach. Organisations can now design their own controls to meet a requirement’s stated objective, provided they can demonstrate through a customised validation that the control achieves the intended security outcome. This is aimed at mature organisations with strong risk management capabilities — it is not a shortcut.
Expanded multi-factor authentication. Under v3.2.1, MFA was required only for remote and administrative access to the cardholder data environment (CDE). Version 4.0 expands this to all access into the CDE, not just administrative or remote sessions. This is a substantial operational change for many organisations.
Targeted risk analysis. Several requirements now allow organisations to determine control frequency (such as how often to review access or run log analysis) through a documented, targeted risk analysis rather than prescribing a fixed interval. This adds flexibility but also demands robust risk assessment processes.
Enhanced e-commerce security. New requirements address threats to payment pages, including controls for managing scripts running on payment pages (Requirements 6.4.3 and 11.6.1). Organisations must maintain inventories of all scripts, justify their inclusion, and implement mechanisms to detect unauthorised changes. This directly targets Magecart-style attacks and formjacking.
Stronger authentication requirements. Password minimums have increased from seven to twelve characters (or eight if the system does not support twelve). Requirements for password complexity, session timeouts, and account lockout have all been tightened.
Roles and responsibilities documentation. Every requirement in v4.0 now begins with a sub-requirement to document roles and responsibilities for performing the activities described. This is a new structural element that runs across the entire standard.
Transition timeline
| Milestone | Date |
|---|---|
| PCI DSS v4.0 published | March 2022 |
| v3.2.1 retired — v4.0 mandatory | 31 March 2024 |
| Future-dated requirements become mandatory | 31 March 2025 |
Organisations that have not yet addressed the future-dated requirements are already out of compliance. If your programme is still aligned to v3.2.1, immediate action is required.
Who must comply with PCI DSS?
PCI DSS applies to every entity that stores, processes, or transmits cardholder data — and to every entity that can affect the security of cardholder data. This scope is deliberately broad.
Merchants
Any organisation that accepts payment cards for goods or services. This includes brick-and-mortar retailers, e-commerce businesses, subscription-based SaaS companies, and non-profits that accept card donations. If your organisation takes card payments in any form, PCI DSS applies to you.
Service providers
Organisations that store, process, or transmit cardholder data on behalf of another entity, or that could affect the security of another entity’s cardholder data environment. Examples include hosting providers, managed security service providers, tokenisation vendors, and payment gateway operators.
Payment processors and acquirers
The banks, processors, and payment facilitators that handle transaction authorisation and settlement. These entities face the most stringent compliance obligations and are typically assessed as Level 1 service providers.
Issuers
Banks and financial institutions that issue payment cards to consumers. While issuers operate under additional card-brand-specific programmes, PCI DSS requirements apply to their cardholder data handling operations.
A common misconception
Organisations sometimes assume that outsourcing payment processing to a third party eliminates their PCI DSS obligations entirely. It does not. Outsourcing can significantly reduce scope — if you never see, store, or transmit cardholder data, fewer requirements apply — but you remain responsible for ensuring your service providers are compliant, and certain requirements (such as those governing your payment page) still apply.
The four merchant levels
Card brands classify merchants into four levels based on annual transaction volume. The level determines how compliance must be validated — not which requirements apply. All levels must meet the same security standards; the difference is in the rigour and cost of the assessment process.
| Level | Annual transactions | Validation requirements |
|---|---|---|
| Level 1 | More than 6 million transactions across all channels | Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA); quarterly ASV scans |
| Level 2 | 1 million to 6 million transactions | Annual Self-Assessment Questionnaire (SAQ); quarterly ASV scans |
| Level 3 | 20,000 to 1 million e-commerce transactions | Annual SAQ; quarterly ASV scans |
| Level 4 | Fewer than 20,000 e-commerce transactions, or up to 1 million total transactions via other channels | Annual SAQ; quarterly ASV scans (recommended, may be required by acquirer) |
Important caveats. Any merchant that has suffered a data breach involving cardholder data can be escalated to Level 1 regardless of transaction volume. Card brands also reserve the right to reclassify merchants at their discretion. The thresholds above are based on Visa’s programme — other card brands use similar but not identical breakpoints, so check your acquirer’s specific requirements.
Service providers have a separate two-tier classification: Level 1 for those storing, processing, or transmitting more than 300,000 transactions annually, and Level 2 for those below that threshold.
The 12 PCI DSS requirements
PCI DSS organises its requirements under six overarching goals. Together, these 12 requirements form a comprehensive security baseline for protecting cardholder data. Each top-level requirement contains detailed sub-requirements — in v4.0, there are over 250 individual controls.
Goal 1: Build and maintain a secure network and systems
Requirement 1 — Install and maintain network security controls. Implement firewalls (or equivalent network security controls in v4.0 terminology) to protect the cardholder data environment. Define rules that restrict traffic to only what is necessary for business purposes.
Requirement 2 — Apply secure configurations to all system components. Do not use vendor-supplied defaults for system passwords, security parameters, or unnecessary services. Harden all systems before deployment into the CDE.
Goal 2: Protect account data
Requirement 3 — Protect stored account data. Minimise data retention — do not store cardholder data unless there is a legitimate business need. When storage is necessary, render the primary account number (PAN) unreadable using encryption, truncation, tokenisation, or secure hashing. Never store sensitive authentication data after authorisation.
Requirement 4 — Protect cardholder data with strong cryptography during transmission over open, public networks. Use strong cryptographic protocols (such as TLS 1.2 or higher) to protect cardholder data during transmission over networks that are accessible to the public.
Goal 3: Maintain a vulnerability management programme
Requirement 5 — Protect all systems and networks from malicious software. Deploy anti-malware solutions on all systems commonly affected by malware. Keep anti-malware mechanisms current, active, and capable of generating audit logs.
Requirement 6 — Develop and maintain secure systems and software. Establish a process for identifying and risk-ranking vulnerabilities. Apply critical security patches within one month of release. Follow secure development practices, including code reviews or application security testing for bespoke and custom software.
Goal 4: Implement strong access control measures
Requirement 7 — Restrict access to system components and cardholder data by business need to know. Implement role-based access control. Users should have access only to the systems and data they need to perform their job functions.
Requirement 8 — Identify users and authenticate access to system components. Assign unique IDs to all users. Implement multi-factor authentication for all access into the CDE (expanded in v4.0). Enforce password policies that meet the standard’s minimum requirements.
Requirement 9 — Restrict physical access to cardholder data. Control physical access to systems that store cardholder data. Use badge readers, cameras, and visitor logs. Protect point-of-interaction devices from tampering and substitution.
Goal 5: Regularly monitor and test networks
Requirement 10 — Log and monitor all access to system components and cardholder data. Implement logging and log monitoring to track user activities, detect anomalies, and support forensic investigation. Logs must record specific event types and be retained for at least twelve months, with at least three months immediately available for analysis.
Requirement 11 — Test security of systems and networks regularly. Conduct quarterly vulnerability scans using an Approved Scanning Vendor (ASV). Perform annual penetration testing. Deploy change-detection mechanisms for critical files. In v4.0, implement mechanisms to detect and alert on unauthorised changes to payment pages.
Goal 6: Maintain an information security policy
Requirement 12 — Support information security with organisational policies and programmes. Establish, publish, and maintain an information security policy. Conduct annual risk assessments. Implement a security awareness programme. Maintain an incident response plan and test it at least annually.
Cardholder data vs sensitive authentication data
Understanding the distinction between these two categories is critical for scoping your PCI DSS programme correctly and implementing appropriate controls.
| Data type | Examples | Can be stored post-authorisation? |
|---|---|---|
| Cardholder data (CHD) | Primary account number (PAN), cardholder name, expiration date, service code | Yes — if encrypted, truncated, tokenised, or hashed in accordance with Requirement 3 |
| Sensitive authentication data (SAD) | Full track data (magnetic stripe or chip equivalent), CVV/CVC/CAV2, PINs and PIN blocks | No — never, under any circumstances, even if encrypted |
The PAN is the defining element. If you store, process, or transmit the PAN, you are in scope for PCI DSS. Other cardholder data elements are only considered in scope when stored, processed, or transmitted in conjunction with the PAN.
Sensitive authentication data must be purged immediately after the authorisation process completes. There is no exception. Issuers may retain SAD if they have a legitimate business justification and store it securely, but this exception does not extend to merchants or service providers.
Consequences of non-compliance
PCI DSS non-compliance carries tangible financial and operational consequences. These are not theoretical risks — acquiring banks and card brands actively enforce penalties.
Financial penalties
| Consequence | Typical range |
|---|---|
| Monthly non-compliance fines | $5,000 to $100,000 per month, escalating over time |
| Forensic investigation costs (post-breach) | $20,000 to $500,000+ |
| Card brand case management fees | $25,000 to $500,000 per incident |
| Increased transaction processing fees | 1% to 2% surcharge on all transactions |
Operational consequences
- Loss of card acceptance. Acquiring banks can terminate your merchant account, rendering you unable to accept card payments. For businesses that depend on card revenue, this is existential.
- Mandatory Level 1 assessment. Following a breach, merchants are typically reclassified as Level 1 regardless of their transaction volume. This requires a full on-site assessment by a QSA — a significantly more expensive process than self-assessment.
- Brand and reputational damage. Card data breaches generate regulatory scrutiny, customer churn, and media coverage. The cost of reputational damage is difficult to quantify but often exceeds the direct financial penalties.
- Liability for fraudulent transactions. Non-compliant merchants may be held liable for the cost of fraudulent transactions that result from a breach, including card reissuance costs borne by issuing banks.
How PCI DSS relates to other frameworks
PCI DSS does not exist in isolation. Most organisations subject to PCI DSS also maintain compliance with other security frameworks. Understanding the overlaps — and the gaps — can significantly reduce the total cost of compliance.
PCI DSS and ISO 27001
ISO 27001 is an information security management system (ISMS) standard that provides a broad, risk-based framework for managing security across an organisation. PCI DSS is narrower in scope (focused specifically on cardholder data) but more prescriptive in its requirements.
| Dimension | PCI DSS | ISO 27001 |
|---|---|---|
| Scope | Cardholder data environment | Entire organisation (as defined by ISMS scope) |
| Approach | Prescriptive requirements with defined controls | Risk-based with Annex A control catalogue |
| Validation | Assessment by QSA or self-assessment | Certification audit by accredited body |
| Frequency | Annual assessment + quarterly scans | Three-year certification cycle with annual surveillance |
An organisation with a mature ISO 27001 ISMS will find substantial overlap — particularly in areas such as access control, logging, vulnerability management, and incident response. However, PCI DSS includes specific technical requirements (such as PAN masking rules, ASV scanning, and payment-page script controls) that ISO 27001 does not address.
PCI DSS and SOC 2
SOC 2 evaluates controls across five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Many of the controls that support SOC 2’s Security criterion overlap with PCI DSS requirements — access control, change management, logging, and vulnerability management in particular.
However, a SOC 2 report does not satisfy PCI DSS requirements, and vice versa. SOC 2 is attestation-based (a CPA firm issues an opinion), while PCI DSS uses its own assessment methodology (QSA or SAQ). Organisations that maintain both can share evidence across programmes — an area where a GRC platform with cross-framework mapping delivers significant efficiency gains.
Mapping controls across frameworks
Organisations pursuing multiple frameworks benefit from a unified control library. A single control such as “enforce multi-factor authentication for privileged access” can satisfy requirements in PCI DSS (Requirement 8.4), ISO 27001 (Annex A 8.5), and SOC 2 (CC6.1) simultaneously. Maintaining these mappings manually is error-prone; automated mapping through a GRC platform reduces duplication and ensures that evidence collected for one framework is automatically applied to others.
Reducing and managing PCI DSS scope
The most effective way to reduce the cost and complexity of PCI DSS compliance is to reduce scope — that is, to minimise the number of systems, networks, and processes that store, process, or transmit cardholder data.
Common scope reduction strategies
- Tokenisation. Replace cardholder data with a non-sensitive token that maps back to the original data in a secure token vault operated by a PCI-compliant service provider. If your systems only handle tokens, they are out of scope.
- Point-to-point encryption (P2PE). Use a PCI-validated P2PE solution to encrypt cardholder data from the point of interaction (the card reader) through to the decryption environment. Merchants using validated P2PE solutions can use a significantly reduced SAQ (SAQ P2PE).
- Hosted payment pages. Redirect customers to a payment page hosted by a PCI-compliant payment service provider. Your systems never receive cardholder data, reducing your scope to SAQ A or SAQ A-EP depending on the implementation.
- Network segmentation. Isolate the cardholder data environment from the rest of your network using firewalls, VLANs, and access controls. Segmentation does not reduce the number of requirements that apply, but it limits the number of systems subject to assessment.
Scope reduction is not scope elimination. Even with the most aggressive scope-reduction strategies, merchants still have PCI DSS obligations — including monitoring their service providers’ compliance status, securing their payment pages, and maintaining an information security policy.
Next steps
PCI DSS compliance is a continuous programme, not a one-time project. If your organisation is starting its compliance journey or navigating the transition to v4.0, focus on these priorities.
Determine your merchant level and applicable SAQ type. Your acquiring bank can confirm your classification. The SAQ type determines which requirements apply to your specific payment acceptance method.
Conduct a gap assessment against v4.0. Identify where your current controls fall short of v4.0 requirements — particularly the formerly future-dated requirements that became mandatory in March 2025. Prioritise the new e-commerce protections (Requirements 6.4.3 and 11.6.1) and expanded MFA requirements if you have not yet addressed them.
Map your cardholder data flows. Document every system, process, and third party that touches cardholder data. This is the foundation for accurate scoping and effective scope reduction.
Evaluate scope reduction opportunities. Tokenisation, hosted payment pages, and P2PE can dramatically reduce the number of systems in scope and the complexity of your compliance programme.
Establish continuous monitoring. PCI DSS compliance must be maintained year-round, not just at assessment time. Implement automated evidence collection, continuous control monitoring, and regular internal reviews to avoid compliance drift between annual assessments.
A GRC platform like Prova can accelerate each of these steps by automating evidence collection, mapping PCI DSS controls to your other frameworks, and providing continuous visibility into your compliance posture across the entire cardholder data environment.