PCI DSS to ISO 27001: which evidence carries over (and which does not)

Payment companies pursuing ISO 27001 certification often arrive with a PCI DSS compliance programme already in place - a QSA-assessed Report on Compliance (RoC), an annual penetration test, a change management process, and a library of security policies. The natural assumption is that most of the ISO 27001 work is already done. The reality is more specific: some PCI DSS evidence carries over directly, some needs reframing, and a set of ISO 27001 requirements has no PCI DSS equivalent at all.

Understanding the mapping before you start saves wasted effort on areas where you already have strong evidence, and prevents a false sense of security about the genuine gaps.

The frameworks are different in structure

Before mapping specific controls, it helps to understand the structural difference. PCI DSS is a prescriptive technical standard. It tells you exactly what to do (use TLS 1.2 or higher, rotate encryption keys annually, review firewall rules every six months) and a QSA checks whether you did it. Compliance is binary within the assessment scope.

ISO 27001 is a management system standard. It requires you to identify your own risks, decide which controls address those risks, implement them, and demonstrate through an auditable management system that you are continuously improving. The auditor is checking whether your management system is effective, not whether you followed a prescribed checklist.

That structural difference means that even where PCI DSS and ISO 27001 cover the same technical ground - access control, encryption, vulnerability management - the evidence requirements are not identical. PCI DSS evidence typically demonstrates that a specific technical control exists and was operational at the time of assessment. ISO 27001 evidence typically demonstrates that a control is owned, managed, reviewed, and embedded in a living governance process.

What carries over: the strong overlaps

Access control and access reviews - PCI DSS Requirement 7 (restrict access to system components and cardholder data) and Requirement 8 (identify users and authenticate access) map closely onto ISO 27001:2022 Annex A.5.15, A.5.16, A.5.17, A.5.18, and A.8.2. If you have access control policies, a user provisioning process, MFA on remote access and privileged accounts, and a completed access review cycle, that evidence is directly relevant to the ISO 27001 audit. The key reframing is scope: the ISO 27001 scope should extend to all significant information assets, not just the cardholder data environment. But the underlying access management evidence is shared.

Change management - PCI DSS Requirement 6 (develop and maintain secure systems and software) includes change control requirements: documented change requests, testing before deployment, change authorisation, and a separation between test and production environments. ISO 27001:2022 Annex A.8.32 (change management) requires a managed change process. A mature PCI DSS change management process with documented records is strong ISO 27001 evidence. The question is whether the process covers all systems in the ISMS scope, not just those in the CDE.

Cryptography - PCI DSS Requirement 4 (protect cardholder data with strong cryptography during transmission) and Requirement 3 (protect stored account data, including key management) map onto ISO 27001:2022 Annex A.8.24 (use of cryptography). Key management policies, key rotation schedules, and encryption-in-transit documentation all carry over. Again, the scope question matters: ISO 27001 requires cryptographic controls across all relevant data, not just cardholder data.

Incident logging and response - PCI DSS Requirement 10 (log and monitor all access to system components and cardholder data) and Requirement 12.10 (implement an incident response plan) map onto ISO 27001:2022 Annex A.8.15 (logging), A.8.16 (monitoring), and A.5.26 (response to information security incidents). Security event logs, log retention policies, and a tested incident response plan are common to both frameworks. PCI DSS tends to be more specific about log content and retention periods; ISO 27001 requires that the logging approach is risk-based and that incident response is documented and tested.

Vulnerability management - PCI DSS Requirement 11 (test security of systems and networks regularly) maps onto ISO 27001:2022 Annex A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance). Annual penetration tests, quarterly vulnerability scans, and remediation tracking records are directly relevant to both frameworks.

What does not carry over: the ISO 27001-specific gaps

This is the part most payment companies underestimate. There is a set of ISO 27001 requirements that PCI DSS does not address, and where a PCI-compliant organisation typically has little or no existing evidence.

Management review - ISO 27001 clause 9.3 requires top management to review the ISMS at planned intervals, covering information security performance, audit findings, risk treatment status, and changes in the organisation's context. PCI DSS has no equivalent. The QSA does not check whether the board or executive team formally reviewed the security programme. For an ISO 27001 audit, management review minutes are mandatory evidence. If they do not exist, there is a nonconformity regardless of the quality of the technical controls.

Internal audit - ISO 27001 clause 9.2 requires a planned programme of internal audits against the standard's requirements. PCI DSS has QSA assessment and internal security assessments, but not a formal internal audit programme against an ISMS standard. The internal audit must be conducted by someone sufficiently independent from the area being audited, and the results must be reported to management. A PCI-compliant organisation typically needs to build this from scratch.

Risk register - ISO 27001 clause 6.1 requires a documented information security risk assessment using a defined methodology, with identified risks, owners, likelihood and impact assessments, and treatment decisions. PCI DSS does not require a risk register in this sense. PCI DSS Requirement 12.3 requires a targeted risk analysis for certain control decisions, but that is not the same as a living organisational risk register covering the full scope of information assets. The risk register is the backbone of ISO 27001; its absence is typically the largest single gap for PCI-compliant organisations.

Statement of Applicability - ISO 27001 requires a Statement of Applicability (SoA) that lists all Annex A controls, states whether each is applicable, and where controls are excluded, provides a justification. PCI DSS has no equivalent document. The SoA must be produced, reviewed by management, and maintained as a live document. It is one of the first things an auditor requests.

Scope document and ISMS boundary - ISO 27001 requires a formally defined scope document that establishes the boundaries of the management system, including organisational units, locations, processes, and technology. PCI DSS scope is defined by the cardholder data environment and connected systems. ISO 27001 scope is broader and defined by the organisation's own risk assessment. A PCI DSS scoping document does not substitute for an ISMS scope document.

Supplier information security reviews - PCI DSS Requirement 12.8 covers third-party service providers with access to the CDE, including a list of providers, written agreements, and an annual confirmation of their PCI DSS compliance status. ISO 27001:2022 Annex A.5.19 to A.5.23 requires supplier information security management across all relevant suppliers, with written agreements, periodic reviews, and a defined due diligence process. The PCI DSS supplier programme is a good starting point, but typically covers a narrower set of suppliers than the ISO 27001 requirement demands.

The evidence reframing question

For the areas of genuine overlap, the work is often less about creating new evidence and more about ensuring existing evidence is correctly framed for an ISO 27001 audit. PCI DSS evidence is typically formatted for a QSA, not an ISO 27001 auditor. The access review spreadsheet used for PCI DSS Requirement 7 evidence will satisfy ISO 27001 Annex A.5.18 if it covers the right scope and includes the right fields. The penetration test report used for PCI DSS Requirement 11 evidence will satisfy ISO 27001 Annex A.8.8 if it covers all systems in the ISMS scope, not just the CDE.

The reframing work is real but manageable. The gap-filling work - management review, internal audit, risk register, SoA - requires genuine effort and typically takes several months to build from evidence that can withstand audit scrutiny.

Where Kellwick fits

Kellwick works with payment companies to map existing PCI DSS evidence against ISO 27001 requirements, identify the genuine gaps that need to be built, and prepare the management system for certification without duplicating effort. If you are a payment provider approaching ISO 27001, see how the payments readiness review works.