Key takeaways (as of October 2026)
- PCI DSS is an industry standard from the PCI Security Standards Council, not a law; it becomes binding through contracts with acquirers and payment brands.
- Version 4.0.1 of June 11, 2024 is the only active version; version 4.0 was retired on December 31, 2024.
- The future-dated requirements introduced with version 4.0 have been mandatory since March 31, 2025, for example the management of payment page scripts (6.4.3).
- The Council issues no certificate; compliance is validated through a self-assessment questionnaire (SAQ) or a report on compliance (ROC), each with an attestation of compliance (AOC).
What is PCI DSS?
PCI DSS (Payment Card Industry Data Security Standard) is the payment card industry's security standard for protecting account data, meaning cardholder data and sensitive authentication data. It is published by the PCI Security Standards Council, which develops and maintains the standard but does not monitor its implementation.
Who does PCI DSS apply to?
PCI DSS applies to every organization that stores, processes or transmits card data, and to every organization whose environment can affect the security of that data. The Council explicitly names merchants, processors, acquirers, issuers and service providers.
Cardholder data and sensitive authentication data
PCI DSS protects two groups of data, which PCI DSS together calls account data:
| Data group | Elements | What applies |
|---|---|---|
| Cardholder data | Primary account number (PAN), cardholder name, expiration date, service code | May be stored if protected. The PAN is the defining element: the other data points fall under protection as soon as they are present with it. |
| Sensitive authentication data | Full track data (magnetic stripe or chip equivalent), card verification code, PINs and PIN blocks | Must not be stored after authorization, even if encrypted (requirement 3.3.1). |
An organization that outsources payment operations to a third party remains responsible, under the standard, for making sure the provider protects account data according to the applicable requirements.
PCI DSS in Germany: a contractual, not a legal duty
PCI DSS is an industry standard, not a rule from a government body. According to the Council, whether an organization must comply and validate compliance is decided by the organizations that manage compliance programs, meaning the payment brands and acquirers. For merchants, the obligation therefore arises from the acceptance agreement with the acquirer or payment service provider.
In the EU, Regulation (EU) 2016/679 (GDPR), Article 32 applies independently. Card data relating to a person is personal data, and Article 32 GDPR requires appropriate technical and organizational measures to ensure a level of security appropriate to the risk. Where a PCI DSS requirement conflicts with local law, the standard itself says the law prevails.
The 12 principal requirements of PCI DSS
PCI DSS is organized into 12 principal requirements grouped under six goals.
| Goal | No. | Principal requirement (paraphrased) |
|---|---|---|
| Secure network and systems | 1 | Install and maintain network security controls |
| Secure network and systems | 2 | Apply secure configurations to all system components |
| Protect account data | 3 | Protect stored account data |
| Protect account data | 4 | Use strong cryptography for cardholder data sent over open, public networks |
| Vulnerability management | 5 | Protect systems and networks from malicious software |
| Vulnerability management | 6 | Develop and maintain secure systems and software |
| Access control | 7 | Restrict access to systems and cardholder data to business need to know |
| Access control | 8 | Identify users and authenticate access |
| Access control | 9 | Restrict physical access to cardholder data |
| Monitoring and testing | 10 | Log and monitor all access to systems and cardholder data |
| Monitoring and testing | 11 | Test the security of systems and networks regularly |
| Security policy | 12 | Support information security with organizational policies and programs |
What changed with PCI DSS 4.0 and 4.0.1?
Version 4.0 was released in March 2022. On June 11, 2024, version 4.0.1 followed as a limited revision: it corrects errors and clarifies intent and guidance, but adds or removes no requirements. Version 4.0 was retired on December 31, 2024, leaving 4.0.1 as the only active version.
Version 4.0 introduced many new requirements that were initially treated as best practices.
Mandatory since March 31, 2025: four examples
Since March 31, 2025, these requirements have been mandatory and are assessed in every validation. Four examples:
- Payment page scripts (6.4.3): Every script loaded and executed on the payment page in the browser must be authorized, checked for integrity and inventoried with a written justification.
- Tamper detection (11.6.1): Unauthorized changes to the HTTP headers and contents of the payment page as received by the browser must be detected and alerted on, at least once every seven days or at the frequency set by a targeted risk analysis.
- MFA for all access into the cardholder data environment (8.4.2): With narrow exceptions, every non-console access into the CDE requires multi-factor authentication, not just administrative and remote access.
- Targeted risk analyses (12.3.1): Where a requirement calls for a targeted risk analysis, for example because it leaves the frequency of an activity to the organization, that analysis must be documented and reviewed at least once every 12 months.
The customized approach and the 2026 request for comments
Also new is the customized approach. Instead of implementing a requirement as written, an organization can use its own controls that demonstrably meet the requirement's stated objective. Organizations validating by self-assessment questionnaire cannot use this route.
From June 3 to July 20, 2026, the Council invited eligible stakeholders to comment on version 4.0.1 in a request for comments. The Council describes this as the start of work on the next iteration of the standard; it names no date for a new version (as of October 2026).
Is there a PCI DSS certification?
Not in the sense of an ISO certificate. The Council does not issue certificates. Compliance is validated through one of two reporting routes, each with an attestation:
| Evidence | Who prepares it | What it contains |
|---|---|---|
| Self-Assessment Questionnaire (SAQ) | The organization itself | Self-assessment of the applicable requirements; several SAQ types exist for specific payment environments, each with its own eligibility criteria |
| Report on Compliance (ROC) | Usually a Qualified Security Assessor (QSA) | Assessment report on the Council's mandatory template |
| Attestation of Compliance (AOC) | The organization, together with the assessor for a ROC | Declaration of the result of the SAQ or ROC; it goes to the requesting organization, for merchants the acquirer or payment brand |
| External vulnerability scans | An Approved Scanning Vendor (ASV) | At least once every three months, with a passing result under the ASV Program Guide (requirement 11.3.2) |
Payment brands and acquirers decide which route applies. What counts are the Council's official forms and templates, meaning the ROC, SAQ, AOC and the attestation for ASV scans, not a certificate issued by a service provider. How a certificate differs in principle from an audit report is shown in the comparison ISO 27001 vs SOC 2.
Scope: the cardholder data environment and connected systems
Scope covers the cardholder data environment (CDE) and every system connected to it or able to affect its security. Two requirements turn this into an ongoing duty:
- Inventory (12.5.1): All in-scope system components are inventoried with a description of their function and use, and the inventory is kept current.
- Scope confirmation (12.5.2): At least once every 12 months and after significant changes, the organization confirms its scope. This includes data flows for all payment stages and acceptance channels, all storage locations including backups, and all components connected to the CDE.
Network segmentation reduces scope if the assessor confirms it
Network segmentation is not a PCI DSS requirement, but the standard strongly recommends it because it can reduce assessment scope. It works when the assessor confirms the segmentation is adequate. As a prerequisite for reducing scope, the standard names restricting account data to as few locations as possible and eliminating data that is not needed.
PCI DSS, ISO 27001 and the GDPR compared
PCI DSS, ISO/IEC 27001 and the GDPR overlap in protecting data but differ in type, subject, binding force and evidence:
| Aspect | PCI DSS | ISO/IEC 27001 | GDPR |
|---|---|---|---|
| Type | Industry standard | International management system standard | EU regulation |
| Subject | Payment card account data | All information in scope | Personal data |
| Binding force | Through contracts with acquirers and payment brands | Voluntary, through contracts and tenders | By law |
| Requirements | Detailed, testable individual requirements | Risk-based selection from 93 Annex A controls | Appropriate measures under Article 32 |
| Evidence | SAQ or ROC with AOC | Certificate from an accredited body | Accountability of the controller |
An ISMS under ISO/IEC 27001 makes PCI DSS work easier but does not replace it: a PCI DSS assessment tests specific individual requirements whose selection is not left to your own risk assessment. How an ISMS is built and certified is described in the guide to ISO 27001 certification.