PCI DSS 4.0 to ISO 27001 Mapping: Reuse Controls

Organisations that hold both an ISO/IEC 27001 certificate and a PCI DSS validation often run them as two separate programmes, with two risk assessments, two policy sets and two evidence collections for what are largely the same controls. The two schemes overlap heavily, but they are built differently: ISO/IEC 27001:2022 is a risk-based management system standard that lets you choose controls, while PCI DSS v4.0.1 is a prescriptive set of requirements for protecting payment account data with defined testing procedures. This guide shows how to map one to the other, where reuse genuinely works, and where PCI DSS asks for more than an ISMS will ever require by default. It is written for GRC leads, ISMS managers and security architects in merchants and service providers who want one control framework that satisfies both an ISO certification body and a QSA.

Key takeaways

There is no official one-to-one mapping. In the PCI SSC sources we reviewed we found no Council-published mapping to ISO/IEC 27001, so every mapping on this page is an NHI Mgmt Group interpretation to be validated with your QSA and certification body.
ISO gives the management system, PCI gives the detail. Clauses 4 to 10 of ISO/IEC 27001 (context, leadership, risk, review, improvement) can run your PCI programme; PCI DSS supplies specific, testable control requirements inside the cardholder data environment (CDE).
Reuse runs mostly one way. A PCI-compliant CDE provides strong evidence for many Annex A controls, but an ISO certificate on its own does not demonstrate PCI DSS compliance, because Annex A controls are not tested to PCI's defined frequencies and parameters.
Scope is the first decision. The ISMS scope and the CDE are rarely the same. Make the CDE an explicitly named part of the ISMS scope so that one risk process, one Statement of Applicability (SoA) and one internal audit programme cover it.
Machine identities are where both fail together. Service accounts, API keys and encryption keys sit under PCI DSS Requirements 3 and 8 and under several Annex A controls; treat them as one inventory with one owner per credential.

What it is and who it applies to

PCI DSS is maintained by the PCI Security Standards Council (PCI SSC) and, in the Council's words, provides a baseline of technical and operational requirements designed to protect payment account data. Version 4.0.1, published in June 2024, is a limited revision of v4.0 that the Council states contains no additional or deleted requirements; v4.0 was retired on 31 December 2024 and the future-dated requirements became effective on 31 March 2025. PCI DSS applies to entities that store, process or transmit account data, and to entities that can affect its security, including service providers. Whether and how compliance must be validated (Report on Compliance by a QSA, or a Self-Assessment Questionnaire) is set by the payment brands and acquirers, not by the standard itself.

ISO/IEC 27001:2022 (edition 3, October 2022, with Amendment 1:2024 on climate action) sets requirements for an information security management system. It is voluntary, applies to any organisation, and is certified by accredited certification bodies. Its Annex A lists 93 reference controls in four themes (organisational, people, physical, technological), described in more detail in ISO/IEC 27002:2022. See the ISO 27001 Certification Guide and the PCI DSS 4.0 Guide.

Dimension	PCI DSS v4.0.1	ISO/IEC 27001:2022
Nature	Prescriptive security requirements with testing procedures	Management system requirements plus a reference control set
Scope	CDE and connected or security-impacting systems	Chosen by the organisation (clause 4.3), justified and documented
Control selection	All applicable requirements must be met (defined or customized approach)	Controls selected through risk treatment; exclusions justified in the SoA
Frequencies	Many are fixed in the standard; some set by targeted risk analysis	Set by the organisation
Assessor	QSA or internal self-assessment, per brand and acquirer rules	Accredited certification body
Output	ROC or SAQ with Attestation of Compliance (AOC)	Certificate (three-year cycle with surveillance audits)
Flexibility	Customized approach, compensating controls (Appendix B)	Any control set, provided risk treatment is justified

Structure and key requirements

PCI DSS is organised into 12 principal requirements under six goals. ISO/IEC 27001 has mandatory clauses 4 to 10 and Annex A. The table below maps each PCI DSS requirement area to the Annex A controls that most often carry the same intent. The requirement labels are NHI Mgmt Group summaries, not PCI SSC wording; always read the requirement text in your licensed copy of PCI DSS v4.0.1. The "gap" column notes where PCI typically asks for more than the ISO control alone.

PCI DSS requirement (NHIMG summary)	ISO/IEC 27001:2022 Annex A (NHIMG interpretation)	Typical gap when reusing ISO evidence
1. Network security controls	8.20 Networks security, 8.21 Security of network services, 8.22 Segregation of networks	Rule set review frequency and documented business justification for every allowed service
2. Secure configurations	8.9 Configuration management, 5.37 Documented operating procedures	Vendor default accounts and passwords changed or removed on every system component
3. Protect stored account data	5.12 Classification of information, 5.33 Protection of records, 8.10 Information deletion, 8.11 Data masking, 8.24 Use of cryptography	Retention limits, masking rules and key management procedures specific to account data
4. Strong cryptography in transmission	5.14 Information transfer, 8.24 Use of cryptography	Cardholder data over open, public networks, with certificate validity checked
5. Anti-malware	8.7 Protection against malware, 6.3 Information security awareness, education and training (phishing)	Periodic evaluation of systems deemed not at risk from malware
6. Secure systems and software	8.8 Management of technical vulnerabilities, 8.25 Secure development life cycle, 8.26 Application security requirements, 8.28 Secure coding, 8.29 Security testing, 8.32 Change management	Patch timelines for critical issues, protection of public-facing web applications, payment page script control
7. Restrict access by business need to know	5.15 Access control, 5.18 Access rights, 8.2 Privileged access rights, 8.3 Information access restriction	Periodic review of all user and application/system accounts with documented approval
8. Identify users and authenticate access	5.16 Identity management, 5.17 Authentication information, 8.5 Secure authentication	MFA into the CDE, password parameters and controls on system and application accounts
9. Restrict physical access	7.1 to 7.4 (perimeters, entry, offices, monitoring), 7.10 Storage media, 7.14 Secure disposal	Point-of-interaction device inspection and media inventories
10. Log and monitor access	8.15 Logging, 8.16 Monitoring activities, 8.17 Clock synchronisation	Defined audit log content, daily review approach and retention periods
11. Test security regularly	8.8 Management of technical vulnerabilities, 8.29 Security testing, 5.35 Independent review	Quarterly internal and external scans, ASV scans, annual penetration tests, segmentation testing
12. Policies and programmes	Clauses 5, 6.1, 9.3; 5.1 Policies, 5.2 Roles, 5.19 to 5.22 Supplier controls, 5.24 to 5.28 Incident management, 6.1 Screening, 6.3 Training	Service provider responsibility matrix, targeted risk analyses, incident response testing

Clause-level reuse: ISO clause 6.1.2 (risk assessment) can host the PCI targeted risk analyses; clause 9.2 (internal audit) can include PCI requirement testing; clause 9.3 (management review) can take PCI compliance status as an input; clause 10.2 (nonconformity and corrective action) can track PCI findings. This is where most of the practical savings come from.

Identity and NHI requirements

Identity is the area with the deepest overlap and the most findings in practice. PCI DSS Requirements 7 and 8 and ISO controls 5.15 to 5.18, 8.2 and 8.5 all address who and what can access systems, and both explicitly reach beyond human users.

System and application accounts: PCI DSS v4.x added requirements on accounts used by systems and applications, including how they are managed and how their authentication factors are protected. In ISO terms these are identities under 5.16 and authentication information under 5.17. Build one inventory that records owner, purpose, privileges, credential type and rotation date. See the Service Account Security Guide.
Secrets in code and configuration: hard-coded database passwords and API keys defeat both Requirement 8 and control 5.17. Move them to a vault with access scoped per workload. See the Secrets Management Guide.
Cryptographic keys: Requirement 3 key management and control 8.24 both expect keys to be protected separately from the data they protect. In the AI agent retail card theft campaign of 2026, a plaintext database password, a bulk dump of a cloud secrets manager and an application encryption key stored next to the data led to the decryption of more than 600,000 card numbers.
Privileged and administrative access: map PCI administrative access controls to 8.2 Privileged access rights and use one privileged access process for both. See the Privileged Access Management Guide.
Access reviews: one recertification campaign can satisfy 5.18 and the PCI account reviews if it covers non-human accounts, records the reviewer and decision, and runs at the PCI-required frequency rather than an ISMS-chosen one.

Implementation steps

Align scope. Document the CDE (systems that store, process or transmit account data, plus connected and security-impacting systems) and confirm it sits inside the ISMS scope statement under clause 4.3. Record segmentation assumptions. See the Network Segmentation Guide.
Build a unified control catalogue. Write each control once, in your own words, and tag it with the PCI requirement numbers and Annex A control IDs it supports. Use the mapping above as a starting point, not as an authority. See the Control Mapping Guide.
Set parameters to the stricter scheme. Where ISO lets you choose a frequency and PCI fixes one (scans, reviews, rule set reviews), adopt the PCI value for the CDE. Where PCI allows a frequency set by targeted risk analysis (12.3.1), document that analysis inside the ISO risk process.
Merge the risk process. Run one risk methodology under clause 6.1.2. Keep PCI targeted risk analyses as named records within it so the QSA can find them.
Update the SoA. For each Annex A control, cite the PCI-driven implementation where relevant. Do not exclude a control from the SoA if PCI requires its equivalent in the CDE.
Pilot on one requirement family. Start with Requirements 7, 8 and 10: collect evidence once, then test whether both the internal auditor (ISO view) and a QSA or PCI internal assessor (PCI view) accept it. Adjust the catalogue before rolling out further.
Integrate audit calendars. Schedule ISO surveillance audits and PCI assessments so evidence periods line up. See the Compliance Calendar Template.
Keep a rollback path. Retain the previous PCI evidence index for one assessment cycle. If the QSA rejects a merged artefact, you can fall back without losing the period.

Small vs large organisations: a merchant validating with an SAQ and a small ISMS can run a single spreadsheet catalogue and one internal audit per year. A Level 1 service provider with a ROC benefits from a GRC platform, separate control owners per requirement family and continuous evidence collection. See the Compliance Automation Guide.

Evidence and assessment

The two assessments look at evidence differently. A certification body samples to confirm the ISMS works and the SoA controls are implemented; a QSA follows defined testing procedures per requirement and expects evidence across the CDE population. Design evidence to meet the QSA standard and it will usually satisfy the certification body too.

Evidence artefact	PCI use	ISO use	Design note
Account and credential inventory	Requirements 7 and 8	5.16, 5.17, 5.18	Include system and application accounts, owners and last rotation
Network diagrams and data flows	Requirements 1 and scoping	8.20, 8.22, clause 4.3	Show account data flows and segmentation points
Vulnerability scan and penetration test reports	Requirement 11	8.8, 8.29	Keep scan dates and rescans as proof of frequency
Log review records	Requirement 10	8.15, 8.16	Record who reviewed, when, and what followed
Targeted risk analyses	12.3.1, 12.3.2	Clause 6.1.2 and 8.2	File as named records in the ISO risk register
Incident response test results	Requirement 12	5.24 to 5.27	One annual exercise with lessons learned feeds both

Customized approach: if you meet a PCI requirement through the customized approach, the Council's guidance points to a controls matrix and a targeted risk analysis (Appendix E templates). These documents also make strong ISO risk treatment records.
Compensating controls: they apply where a documented constraint prevents meeting a requirement as stated, and the Council notes they cannot be used retroactively for a requirement that was missed. Record them in the ISO risk register as risk treatments with an owner and review date.
Third-party attestations: a cloud provider's PCI AOC or ISO certificate does not certify your own use of the service; map shared responsibilities explicitly. See the Third-Party Risk Management Guide.

Metrics that show the mapping works: percentage of unified controls with both PCI and ISO tags; evidence artefacts reused across both assessments; findings raised by one assessor that the other missed; system and application accounts with a named owner and in-date rotation; and days from a PCI finding to a corrective action logged under clause 10.2.

Mapping to other frameworks

Most organisations that run PCI and ISO also report against a third framework. The table shows where the shared control themes sit in NIST frameworks, again as an NHI Mgmt Group interpretation.

Control theme	PCI DSS area	ISO/IEC 27001 Annex A	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Account management	Req. 7, 8	5.16, 5.18	PR.AA-05	AC-2
Authentication	Req. 8	5.17, 8.5	PR.AA-03	IA-2, IA-5
Network boundaries	Req. 1	8.20, 8.22	DE.CM-01 (monitoring)	SC-7
Logging	Req. 10	8.15, 8.16	PR.PS-04	AU-2
Vulnerabilities and patching	Req. 6, 11	8.8	ID.RA-01	RA-5, SI-2
Data at rest	Req. 3	8.24	PR.DS-01	SC-28
Incident reporting	Req. 12	5.24 to 5.26	RS.CO-02	IR-6
Supplier assurance	Req. 12	5.19 to 5.22	GV.SC-05	SR-6
Policy and governance	Req. 12	5.1, clause 5	GV.PO-01	PM-9

If you also run SOC 2, the same catalogue can carry Trust Services Criteria tags. See the SOC 2 Guide and the Identity Security Regulatory Map.

Common pitfalls

Treating the certificate as PCI evidence: presenting an ISO certificate to a QSA as proof of PCI controls. The certificate shows a working ISMS, not that each PCI testing procedure would pass.
Scope mismatch: the ISMS scope excludes the payment platform, or a CDE system sits outside the ISMS, so neither programme sees the whole picture.
Annual ISO frequencies applied to PCI controls: a once-a-year access review satisfies the ISMS but misses PCI frequencies, and the gap appears only during the PCI assessment.
Non-human accounts left out of reviews: recertification campaigns that cover people but not service accounts, API keys and vault roles fail Requirement 8 and weaken 5.18.
Keys stored with data: encryption that satisfies an ISO cryptography policy on paper but stores the key alongside the encrypted data, as in the AI agent retail card theft campaign.
Copied mappings treated as authoritative: using a third-party mapping spreadsheet without checking it against the current PCI DSS v4.0.1 text and your own SoA.

Practitioner checklist

Name the CDE explicitly inside the ISMS scope statement and keep one current data flow diagram.
Build one control catalogue tagged with PCI requirement numbers and Annex A control IDs, labelled as an internal interpretation.
Adopt the PCI frequency wherever the two schemes differ for CDE systems.
Record PCI targeted risk analyses as named entries in the ISO risk register.
Keep one inventory of human, system and application accounts with owners and rotation dates.
Store cryptographic keys and secrets in a vault or key management service separate from the data and code.
Run one annual incident response exercise and log outputs for both schemes.
Align ISO surveillance and PCI assessment calendars and share the evidence index with both assessors.
Have your QSA and certification body confirm the mapping approach before relying on it.

Standards and references

Related NHI Mgmt Group resources: PCI DSS 4.0 Guide · ISO 27001 Certification Guide · PCI DSS Readiness Checklist · Control Mapping Guide · ISO 27002 Controls Guide

PCI DSS 4.0 to ISO 27001 Mapping Guide: Reusing Controls Across Both