How much of PCI DSS v4.0.1 does ISO 27001 actually cover?
ISO 27001 and PCI DSS cover many of the same subjects, yet an ISMS leaves most PCI requirements unmet. The reason is not missing topics but missing detail.

Organisations that take card payments and already run an ISO 27001 ISMS often expect PCI DSS to be a small extension. The numbers say otherwise. Here is how ISO 27001 lines up against all of PCI DSS v4.0.1, requirement by requirement, and why the gap is bigger than the topic overlap suggests.
The headline number
Of the 260 PCI DSS requirements, 77 (30%) map to something in ISO 27001, 76 are only loosely related and 107 have no mapping in our data. Open the gap report →
Under a third of PCI DSS requirements map to anything in ISO 27001, and a similar number are only loosely related. Almost every PCI topic exists somewhere in Annex A, so this isn't a topic gap. It is a detail gap.
Where the overlap is
| PCI DSS section | Mapped | No mapping | |
|---|---|---|---|
| Requirement 1: Install and maintain network security controls | 4 of 19 | 3 | 12 |
| Requirement 2: Apply secure configurations to all system components | 2 of 11 | 3 | 6 |
| Requirement 3: Protect stored account data | 8 of 29 | 7 | 14 |
| Requirement 4: Protect cardholder data with strong cryptography during transmission | 2 of 6 | 2 | 2 |
| Requirement 5: Protect all systems and networks from malicious software | 4 of 13 | 5 | 4 |
| Requirement 6: Develop and maintain secure systems and software | 10 of 19 | 3 | 6 |
| Requirement 7: Restrict access to system components and cardholder data by business need to know | 3 of 12 | 3 | 6 |
| Requirement 8: Identify users and authenticate access to system components | 6 of 29 | 15 | 8 |
| Requirement 9: Restrict physical access to cardholder data | 8 of 27 | 9 | 10 |
| Requirement 10: Log and monitor all access to system components and cardholder data | 6 of 27 | 10 | 11 |
| Requirement 11: Test security of systems and networks regularly | 3 of 21 | 6 | 12 |
| Requirement 12: Support information security with organizational policies and programs | 21 of 37 | 10 | 6 |
| Appendix A: additional requirements | 0 of 10 | 0 | 10 |
Have ISO 27001, need PCI DSS. Requirement by requirement: open the gap report →
The overlap clusters in the parts of PCI DSS that read like any security standard: policies and roles at the start of each requirement, risk and governance in Requirement 12, access control principles in Requirement 7, and incident response. ISO 27001's management system and Annex A cover those well.

Why most of PCI DSS is new work
PCI DSS is prescriptive where ISO 27001 is risk-based. Annex A says "manage technical vulnerabilities"; PCI DSS says how, how often and with whose scanner. The no-mapping rows are dominated by requirements like these:
- Account data handling (Requirement 3): what you may never store after authorisation, masking PAN when displayed, rendering it unreadable wherever stored, and detailed key-management procedures.
- Specific frequencies: internal vulnerability scans every three months and after significant changes, external scans by an Approved Scanning Vendor, log reviews, and access reviews every six months.
- Specific technical settings: MFA for all access into the cardholder data environment, session time-outs, password lengths and lockout thresholds.
- Payment-specific controls: payment-page script management and tamper detection, and inspection of card-reading devices for tampering.
- Targeted risk analyses: v4.0 introduced risk analyses that set the frequency of some activities, which then must be documented.
ISO 27001 lets you choose all of that through risk treatment. PCI DSS decides for you.
What an ISMS still gives you
The mapped third isn't trivial. An ISMS that includes the cardholder data environment in scope gives you the policy framework, risk assessment, roles, supplier management, incident response and internal audit that PCI compliance depends on year after year. Requirement 12 reads like a summary of ISO's clauses 4 to 10, and organisations with an ISMS usually find the governance side of PCI DSS straightforward.
How to plan
- Bring the cardholder data environment into the ISMS scope, and add PCI DSS to your legal and contractual requirements (A.5.31).
- Run the ISO 27001 → PCI DSS gap report and treat every unmapped requirement as a control to design, not a mapping to find.
- Reduce scope before building controls: segmentation, tokenisation and outsourced payment pages can take large parts of PCI DSS out of scope.
- Use PCI's frequencies in your ISMS controls, so one control meets both: ISO is satisfied by any well-reasoned frequency, so pick PCI's.
The ISO 27001 vs PCI DSS comparison lists every requirement in both directions. PCI DSS text is PCI SSC's copyright, so the requirement titles on this site are our own short summaries.
Questions
Does ISO 27001 certification satisfy PCI DSS?
No. Card brands require PCI DSS validation (a Report on Compliance or a Self-Assessment Questionnaire) regardless of ISO certification. An ISMS helps run the programme, but most PCI requirements are more specific than Annex A.
Which PCI DSS requirements does ISO 27001 cover best?
Governance and policy (Requirement 12), access control principles (7) and incident response map well. The gaps are concentrated in specific technical settings, frequencies and account-data handling.
Data as of 2026-10-27: numbers in this post are computed from the current crosswalk and update when it changes. Crosswalk a published crosswalk (NIST, ENISA, CIS, PCI SSC) makes the link · Editorial ControlMapping's judgement where no crosswalk exists; the reason is shown · only shares a CSF 2.0 outcome: worth checking, not a mapping · No mapping in our data nothing mapped in our data; often new work, but check the coverage notes. Not compliance advice.