Explainer · frameworks compared
ISO 27001 and the others: what maps across and what does not.
A mapping saves work once you know what it does. It aligns topics – it does not turn two forms of evidence into one.
A company running a management system and then asked for SOC 2 by an American customer faces the same question as a German vendor whose customer demands IT-Grundschutz: how much of what already exists can be reused?
The honest answer: most of the substance, none of the formalities. Access management, logging, contingency planning and supplier governance are required by every framework. They are required in different vocabulary, with a different form of evidence and a different examiner. Confusing those plans too tightly.
This page aligns the frameworks thematically, names the typical pitfalls and compares the part that concerns us here: the requirements on providers and suppliers.
Two ageing traps before you use any mapping table
Both affect almost every table produced before 2023 – official ones included.
- The Annex A renumbering
- ISO/IEC 27001:2022 reorganised Annex A completely: fourteen sections became four themes with 93 controls. A table still citing A.5.1.1, A.9.2.3 or A.12.4.1 works from the 2013 edition. It remains usable, but every line must be translated first – the correspondence tables sit in Annex B of ISO/IEC 27002:2022.
- The move from NIS1 to NIS2
- Mappings to the security requirements for digital service providers frequently reference Implementing Regulation (EU) 2018/151. That belonged to the NIS1 Directive, repealed by NIS2. Implementing Regulation (EU) 2024/2690 took its place, in force since 7 November 2024 and directly applicable in every member state.
- Where to find a current alignment
- In June 2025 ENISA published technical implementation guidance for that regulation. It contains evidence examples and explicit cross-references to ISO 27001 – non-binding, but recognised by supervisors and considerably more current than the older tables.
An outdated mapping table is not worthless, but it is a translation exercise rather than a shortcut. Adopting it unchecked means citing control numbers in an audit that no longer exist.
The frameworks at a glance
They differ less in substance than in form of evidence, examiner and scope.
| Framework | Form of evidence | Character |
|---|---|---|
| ISO/IEC 27001:2022 | Certificate from an accredited body, three years | A management system with 93 controls in four themes. Risk-based; you set the scope. |
| BSI IT-Grundschutz | Certificate on the basis of IT-Grundschutz | A module catalogue with spelled-out requirements. Own risk analysis only at elevated protection needs. |
| SOC 2 | Audit report from an audit firm, type I or II | Controls against the Trust Services Criteria, assessed for a period. Not a certificate. |
| NIST CSF 2.0 | No certificate; self-assessment or third-party review | A framework with six functions: Govern, Identify, Protect, Detect, Respond, Recover. |
| PCI DSS 4.x | Attestation of Compliance, annually | Binding technical requirements for anyone processing cardholder data. |
| HIPAA Security Rule | No certification; supervision by the authority | US law for health data, with required and addressable safeguards. |
Thematic alignment
Rough but usable: master one column and you usually have the substance for the others.
| Topic | ISO/IEC 27001:2022 | Counterparts in the other frameworks |
|---|---|---|
| Leadership and accountability | Clause 5, A.5.1 to A.5.4 | SOC 2 CC1 control environment · NIST CSF Govern · IT-Grundschutz ISMS.1 · HIPAA security management process |
| Risk assessment | Clauses 6.1.2 and 6.1.3 | SOC 2 CC3 risk assessment · NIST CSF ID.RA · IT-Grundschutz BSI standard 200-3 · HIPAA risk analysis |
| Assets and classification | A.5.9 to A.5.13 | SOC 2 CC6.1 · NIST CSF ID.AM · IT-Grundschutz structure analysis and protection needs |
| Access management | A.5.15 to A.5.18, A.8.2 to A.8.5 | SOC 2 CC6 · NIST CSF PR.AA · PCI DSS req. 7 and 8 · HIPAA access control · IT-Grundschutz ORP.4 |
| Cryptography | A.8.24 | SOC 2 CC6.7 · NIST CSF PR.DS · PCI DSS req. 3 and 4 · HIPAA encryption · IT-Grundschutz CON.1 |
| Logging and monitoring | A.8.15 to A.8.17 | SOC 2 CC7.2 · NIST CSF DE.CM · PCI DSS req. 10 · IT-Grundschutz OPS.1.1.5 |
| Vulnerabilities and change | A.8.8, A.8.32 | SOC 2 CC8.1 · NIST CSF ID.RA and PR.PS · PCI DSS req. 6 and 11 · IT-Grundschutz OPS.1.1.3 |
| Incident handling | A.5.24 to A.5.28 | SOC 2 CC7.3 to CC7.5 · NIST CSF Respond · PCI DSS req. 12.10 · HIPAA security incident procedures |
| Business continuity | A.5.29, A.5.30, A.8.13, A.8.14 | SOC 2 A1 availability · NIST CSF Recover · HIPAA contingency plan · IT-Grundschutz DER.4 and CON.3 |
| Suppliers and third parties | A.5.19 to A.5.23 | SOC 2 CC9.2 and subservice organisations · NIST CSF GV.SC · PCI DSS req. 12.8 and 12.9 · HIPAA business associate agreements · IT-Grundschutz OPS.2 and OPS.3 |
The supplier part compared directly
All six frameworks require governance of third parties. What they demand differs sharply in one respect: how far down the chain it reaches.
| Framework | Reference | What is required |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.19 to A.5.23 | Address risks from supplier relationships, anchor security requirements contractually, consider the ICT supply chain including upstream suppliers, monitor services continuously, separate rules for cloud services. |
| BSI IT-Grundschutz | OPS layer modules on outsourcing and cloud | Spelled-out requirements from defining requirements through contracting and monitoring to orderly termination – a checklist rather than a principle. |
| SOC 2 | CC9.2, plus the treatment of subservice organisations | Assessment and governance of vendors and business partners. Subcontractors are either included in the examination or expressly carved out – the customer must close that gap. |
| NIST CSF 2.0 | Category GV.SC | A dedicated category for cybersecurity supply chain risk management, new with version 2.0. Requires strategy, roles, supplier requirements and monitoring across the whole lifecycle through to termination. |
| PCI DSS 4.x | Requirement 12.8, extended by 12.9 | A register of every provider with access to cardholder data, written agreements delimiting responsibility, due diligence before engagement and at least annual monitoring of compliance status. |
| HIPAA | Business associate agreements | A written agreement with every provider processing protected health information, including passing the duties on to their subcontractors. |
The largest substantive difference sits at the second tier. PCI DSS and HIPAA regulate the pass-through explicitly, NIST CSF covers the lifecycle, ISO 27001 requires a risk-based look at the ICT supply chain – and SOC 2 permits subcontractors to be taken out of scope. That is exactly where the gaps arise that customer audits find.
Using a mapping in practice
- One control set, several viewsMaintain the controls once and map framework requirements onto them – not the other way round.Building separate documentation per framework means maintaining the same control three times and living with contradictions from year two.
- Reuse evidenceAn access log, an approval list or a supplier register evidences the same thing in every framework.What differs is who may see it: a SOC 2 report contains detail that never appears on an ISO certificate.
- Name gaps rather than bridging themWhere one framework asks for more, carry it as its own requirement.Typical cases: PCI DSS on encryption and network segmentation, HIPAA on agreements, IT-Grundschutz on physical measures.
- Ask the examiner earlyWhat counts as evidence is decided by the examiner, not the table.One conversation before the examination saves two weeks of rework. Audit firms expect the question.
Four pitfalls
- Confusing mapping with equivalence
- An alignment means “addresses the same topic”, not “satisfies the same requirement”. Evidence must still be produced per framework.
- Overlooking scopes
- An ISO certificate may cover a site, the SOC 2 report a product and the PCI attestation a network segment. Three forms of evidence, three scopes.
- Believing percentages
- Claims like “80 percent overlap” are marketing. The effort sits in the remaining percent and in the evidence format, not in the number.
- Adopting old tables unchecked
- See above: pre-2022 Annex A numbering and NIS1 references are the two most common legacies.
One supplier register, every framework
The supplier part carries the largest overlap: a register, criticality, contract attributes, evidence with expiry and monitoring cycles are required by all six frameworks. In SCRM that exists once – and is evaluated differently for each examination.
Request a consultation ISO 27001 or SOC 2? ISO 27001 or IT-Grundschutz?