PCI DSS v4.0.1 to ISO/IEC 27001:2022: how the requirements map
The short version: an ISO/IEC 27001:2022 ISMS touches the intent of all 12 PCI DSS requirements. Six map broadly. The other six map only in part, because PCI DSS has payment-specific rules with no Annex A counterpart: sensitive authentication data, payment-page scripts, POI device inspection, ASV scans. Across all 12, PCI DSS fixes frequencies and settings that ISO leaves to your risk assessment. Reuse the ISMS, but don’t treat the certificate as PCI DSS evidence.
The table maps each PCI DSS v4.0.1 principal requirement to the ISO/IEC 27001:2022 Annex A controls, and clauses 4 to 10 where relevant, that cover the same ground. It’s our own crosswalk, not an official PCI SSC or ISO mapping.
- Broad means ISO addresses the same risk, but PCI DSS sets specific rules that ISO leaves to you.
- Partial means at least one area of the PCI requirement has no Annex A counterpart.
| PCI DSS v4.0.1 | ISO/IEC 27001:2022 | Coverage | What PCI DSS adds or does differently |
|---|---|---|---|
| Requirement 1 Network security controls | A.8.20 Networks security A.8.21 Security of network services A.8.22 Segregation of networks A.8.1 User end point devices (for 1.5) | Broad | ISO covers the intent. PCI is more prescriptive: network security control configurations reviewed at least every 6 months (1.2.7), current network and data-flow diagrams (1.2.3, 1.2.4), a business justification for every allowed service and port (1.2.5), controls between wireless networks and the CDE (1.3.3), and no direct access from untrusted networks to systems that store cardholder data (1.4.4). |
| Requirement 2 Secure configurations | A.8.9 Configuration management A.8.20 Networks security (wireless, 2.3) | Broad | A.8.9, new in 2022, covers defining and monitoring secure configurations. PCI adds specific rules: vendor default accounts dealt with before deployment (2.2.2), only necessary services enabled and insecure protocols justified (2.2.4, 2.2.5), all non-console admin access encrypted (2.2.7), and wireless defaults and keys changed (2.3.1, 2.3.2). |
| Requirement 3 Protect stored account data | A.8.24 Use of cryptography A.8.10 Information deletion A.8.11 Data masking A.8.12 Data leakage prevention (for 3.4.2) | Partial | ISO has no concept of sensitive authentication data. Nothing in Annex A matches the ban on keeping it after authorization, even encrypted (3.3.1). PCI also names how PAN must be made unreadable (3.5.1), requires keyed hashes (3.5.1.1), limits disk-level encryption (3.5.1.2), requires a check at least every 3 months that expired data is deleted (3.2.1), and sets key-management rules such as split knowledge and dual control (3.7.6). A.8.24 covers the principle of key management, not these specifics. |
| Requirement 4 Protect cardholder data in transit | A.5.14 Information transfer A.8.24 Use of cryptography | Broad | ISO covers rules for transferring information and using cryptography. PCI requires strong cryptography for PAN over open, public networks (4.2.1), an inventory of certificates (4.2.1.1), strong cryptography on wireless networks carrying PAN (4.2.1.2), and no PAN by unprotected end-user messaging (4.2.2). |
| Requirement 5 Protect against malicious software | A.8.7 Protection against malware A.8.23 Web filtering (nearest for 5.4) A.6.3 Information security awareness, education and training (nearest for 5.4) | Partial | A.8.7 covers 5.2 and 5.3. PCI adds periodic evaluation of systems not commonly affected by malware (5.2.3), anti-malware that users can't disable (5.3.5) and removable-media scanning (5.3.3). Annex A has no control named for phishing. The automated anti-phishing mechanism in 5.4.1, mandatory since March 31, 2025, has no direct counterpart. |
| Requirement 6 Secure systems and software | A.8.25 Secure development life cycle A.8.26 Application security requirements A.8.28 Secure coding A.8.29 Security testing in development and acceptance A.8.8 Management of technical vulnerabilities A.8.32 Change management A.8.31 Separation of development, test and production environments A.8.33 Test information | Partial | Development, patching and change management map well. PCI sets fixed rules ISO leaves to your risk assessment: critical patches within one month of release (6.3.3), code review before release (6.2.3), an inventory of bespoke and custom software (6.3.2), and no live PANs in pre-production (6.5.5). Protection of public-facing web applications (6.4.1, 6.4.2) and payment-page script management (6.4.3) have no dedicated Annex A control. |
| Requirement 7 Restrict access by business need to know | A.5.15 Access control A.5.18 Access rights A.8.3 Information access restriction A.8.2 Privileged access rights | Broad | ISO covers least privilege and access rights. PCI adds access reviews at least every 6 months (7.2.4), management of application and system accounts (7.2.5), query access to cardholder data repositories only through applications (7.2.6), and a deny-all default (7.3.3). |
| Requirement 8 Identify users and authenticate access | A.5.16 Identity management A.5.17 Authentication information A.8.5 Secure authentication | Broad | ISO sets no password-change interval and leaves length, lockout and timeouts to your own policy. PCI fixes them: passwords of at least 12 characters (8.3.6), lockout after no more than 10 attempts (8.3.4), re-authentication after 15 idle minutes (8.2.8), inactive accounts disabled within 90 days (8.2.6), and MFA for non-console access into the CDE (8.4.1, 8.4.2) and for remote access that could reach it (8.4.3). |
| Requirement 9 Restrict physical access | A.7.1 Physical security perimeters A.7.2 Physical entry A.7.4 Physical security monitoring A.7.10 Storage media A.7.14 Secure disposal or re-use of equipment | Partial | Facility entry, visitors, media handling and disposal map well. PCI adds camera or access-control data kept for 3 months (9.2.1.1), management approval for media leaving the facility (9.4.4) and cross-cut shredding of hard copy (9.4.6). Inspecting point-of-interaction devices for tampering and skimming (9.5.1) has no Annex A counterpart. |
| Requirement 10 Log and monitor all access | A.8.15 Logging A.8.16 Monitoring activities A.8.17 Clock synchronization | Broad | ISO covers producing, protecting and analyzing logs. PCI fixes the details: the events and fields to record (10.2.1.x, 10.2.2), daily review of security events (10.4.1) using automated mechanisms (10.4.1.1), 12 months' retention with 3 months immediately available (10.5), and detecting failures of critical security controls (10.7.2). |
| Requirement 11 Test security regularly | A.8.8 Management of technical vulnerabilities A.8.16 Monitoring activities (for 11.5) | Partial | ISO sets no scanning or penetration-test frequency. A pen test is one way to meet A.8.8. PCI requires internal and external scans at least every 3 months, external ones by an ASV (11.3.1, 11.3.2), annual internal and external penetration tests (11.4.2, 11.4.3), segmentation tests (11.4.5; every 6 months for service providers, 11.4.6), wireless access point detection (11.2.1) and payment-page tamper detection (11.6.1). |
| Requirement 12 Policies and programs | Clause 5.2 and A.5.1 Policies for information security Clauses 6.1.2, 6.1.3 and 8.2 (risk assessment and treatment) A.5.10 Acceptable use of information and other associated assets A.5.9 Inventory of information and other associated assets A.6.1 Screening; A.6.3 Information security awareness, education and training A.5.19 to A.5.22 Supplier relationships and services A.5.24 to A.5.28 Incident management | Partial | Policy, risk, awareness, screening, suppliers and incident response all have ISO counterparts. PCI adds a targeted risk analysis for each requirement whose frequency you set (12.3.1), yearly reviews of cipher suites and technologies (12.3.3, 12.3.4), PCI scope confirmed at least every 12 months (12.5.2), TPSP compliance status monitored at least every 12 months (12.8.4) with a responsibility matrix (12.8.5), and an IR plan that covers notifying brands and acquirers (12.10.1) and is tested at least annually (12.10.2). |
We haven’t mapped the PCI DSS appendices, such as A1 and A2. Where a pairing holds for only one sub-requirement, the table says so in brackets.
What ISO certification does not give you for PCI DSS
- No substitute for PCI DSS validation. You validate through a Report on Compliance from a QSA (or an ISA where the brand or acquirer allows), or a Self-Assessment Questionnaire, as your acquirer or the payment brands require. An ISO certificate is not PCI DSS evidence. That holds for your service providers too: under 12.8.4 you monitor their PCI DSS status, typically through an AOC covering the services you use. Their ISO certificate can support due diligence (12.8.3) but can’t replace that.
- No CDE scoping. You choose your ISMS scope under clause 4.3. PCI DSS scope isn’t chosen: it’s wherever account data is stored, processed or transmitted. It also takes in anything connected to those systems or able to affect their security. Segmentation can reduce it only if penetration testing proves it (11.4.5), and you confirm scope at least every 12 months (12.5.2). An ISMS scope that leaves out payments says nothing about your PCI DSS scope.
- No prescriptive testing. ISO auditors check you against the frequencies your own policies and risk assessment set. A QSA tests against PCI DSS’s fixed ones: quarterly ASV scans, annual penetration tests, daily log review.
- No Statement of Applicability. Under ISO you can exclude an Annex A control if your SoA justifies it. PCI DSS doesn’t work that way. A requirement is in place, not applicable to your environment, or met through a documented compensating control or the customized approach (ROC only). Risk appetite isn’t a reason to skip one.
- No payment-specific controls. SAD storage, PAN masking and rendering, payment-page scripts (6.4.3, 11.6.1) and POI device inspection (9.5.1) need their own controls. For the most recent changes to these, see what changed in PCI DSS 4.0.1.
What you can reuse
- Risk assessment. Your 6.1.2 method and risk register are a sound base for 12.3. Each targeted risk analysis under 12.3.1 still needs its own write-up for the requirement it supports.
- Policies. Your top-level policy (5.2, A.5.1) and topic policies can meet 12.1 and the policy and roles items that open each PCI requirement, once they name the CDE and the PCI DSS rules.
- Supplier management. A.5.19 to A.5.22 give you the TPSP program for 12.8. Add the TPSP list, AOC collection and the responsibility matrix.
- Incident response. A.5.24 to A.5.28 cover most of 12.10. Add notifying the payment brands and acquirers, annual testing, and a procedure for finding PAN where it shouldn’t be (12.10.7).
- Asset inventory, awareness and screening. A.5.9, A.6.3 and A.6.1 feed 12.5.1, 12.6 and 12.7, once the in-scope systems and people are marked.
- Internal audit. Adding PCI DSS requirements to your 9.2 audit program helps you manage compliance through the year (12.4), not just at assessment time.
How to use this
- Start from PCI DSS scope, not ISMS scope. Find where account data lives and flows, then check that those systems sit inside the ISMS.
- Fix the numbers in your policies. Wherever your ISMS says “periodically”, put the PCI DSS frequency in for in-scope systems. Your ISO auditor will then test you against it too.
- Build the payment-specific controls separately. The “Partial” rows are your gap list.
Heading the other way, to a SOC 2 report? See how ISO 27001 maps to SOC 2. For how ISO 27001’s clauses and Annex A fit together, see how many requirements are in ISO 27001.
Compliance Colleague answers questions like “Map our ISO 27001 SoA to PCI DSS Requirement 8 and list the gaps” with the requirement and control cited, so you can check each one against your own copy of the standards. Try it free, no card required →
PCI DSS is copyrighted by PCI SSC, and ISO/IEC 27001 by ISO and IEC. This guide cites numbers and short titles only and paraphrases everything else. The mapping is our own research aid, not an official crosswalk. Confirm against the official standards before relying on it in an assessment. Not legal advice.