ISO 27001 in the Compliance Ecosystem: NIST CSF, SOC 2, GDPR, NIS2, DORA, and ISO 27002 Alignment Maps
"Compliance is not security, but security without compliance is not sustainable."
- GRC practitioner axiom
Introduction: The Compliance Multiplication Problem
The modern organization does not operate in a single compliance universe. It operates in several simultaneously. A financial services firm processing EU customer data and operating cloud infrastructure may be subject to ISO 27001 expectations from enterprise customers, DORA requirements from financial regulators, GDPR obligations from data protection authorities, NIS2 requirements as an important entity, SOC 2 expectations from US customers, and PCI DSS requirements from its card payment infrastructure - all at once, all with partially overlapping and partially conflicting requirements.
The naive approach to this situation is to run each compliance program independently - separate teams, separate documentation, separate controls, separate audits. The result is compliance multiplication: each framework demands its own evidence set. The security team spends its time generating compliance artifacts rather than managing security.
The sophisticated approach is compliance integration - designing a single, coherent security program that satisfies multiple framework requirements simultaneously, using a well-implemented ISO 27001 ISMS as the governance backbone from which framework-specific requirements are addressed as extensions rather than parallel programs.
This chapter maps ISO 27001 against the six most significant frameworks and regulations - NIST CSF, SOC 2, GDPR, NIS2, DORA, and ISO 27002 - identifying where they align, where they diverge, and how a single ISMS can be extended to address the unique requirements of each.
Part 1 - ISO 27001 and ISO 27002: The Parent-Child Relationship
1.1 Understanding the ISO 27000 Family
ISO 27001 does not stand alone. It is the certifiable standard at the center of the ISO/IEC 27000 family:
| Standard | Title | Purpose |
|---|---|---|
| ISO/IEC 27000 | Overview and vocabulary | Definitions and concepts |
| ISO/IEC 27001 | Requirements | The certifiable ISMS standard - defines what must be done |
| ISO/IEC 27002 | Code of practice for information security controls | Guidance on how to implement Annex A controls |
| ISO/IEC 27003 | Guidance on implementing ISO 27001 | Implementation guidance |
| ISO/IEC 27004 | Monitoring, measurement, analysis, and evaluation | Guidance on ISMS performance measurement |
| ISO/IEC 27005 | Information security risk management | Guidance on risk assessment and treatment |
| ISO/IEC 27017 | Code of practice for cloud services | Cloud-specific security controls |
| ISO/IEC 27018 | Protection of PII in public clouds | Cloud privacy controls |
| ISO/IEC 27701 | Privacy information management | Extension for GDPR and privacy programs |
| ISO/IEC 27035 | Incident management | Guidance on security incident management |
1.2 ISO 27001 vs ISO 27002: The Critical Distinction
ISO 27001 contains the requirements - the "shall" statements an ISMS must conform to. Annex A of ISO 27001 is a normative reference to controls that must be considered in risk treatment.
ISO 27002 is the implementation guidance standard - the "should" companion to Annex A. For each of the 93 controls referenced in Annex A of ISO 27001:2022, ISO 27002:2022 provides a purpose statement, guidance on implementation, and other contextual information.
ISO 27001 requires that Annex A controls be considered. ISO 27002 explains how to implement them. An organization is certified against ISO 27001, not ISO 27002.
Practitioners who treat ISO 27002 as a requirements checklist over-engineer their ISMSs. Practitioners who ignore ISO 27002 entirely miss the implementation depth that distinguishes controls that exist from controls that work.
1.3 ISO 27701: The Privacy Extension
ISO 27701:2019 is a privacy information management system (PIMS) standard that extends ISO 27001 and ISO 27002 with requirements and guidance specifically addressing the management of personally identifiable information (PII). It is designed to be integrated with an existing ISO 27001 ISMS.
For organizations subject to GDPR, ISO 27701 provides a structured approach to demonstrating compliance with GDPR's security and privacy management requirements. The alignment between ISO 27701 and GDPR is substantial, and organizations investing in ISO 27001 with GDPR obligations should seriously evaluate the marginal investment required to extend to ISO 27701.
Part 2 - ISO 27001 and NIST CSF: Complementary Architectures
2.1 The NIST Cybersecurity Framework
The NIST Cybersecurity Framework (CSF) - published by the US National Institute of Standards and Technology - organizes cybersecurity activities into six Functions in CSF 2.0 (2024):
| Function | Description |
|---|---|
| Govern (new in 2.0) | Establish and monitor cybersecurity risk management strategy, expectations, and policy |
| Identify | Develop organizational understanding of cybersecurity risk |
| Protect | Develop and implement appropriate safeguards |
| Detect | Develop and implement activities to identify cybersecurity events |
| Respond | Develop and implement activities to take action regarding detected events |
| Recover | Develop and implement activities to maintain resilience and restore capabilities |
2.2 Where ISO 27001 and NIST CSF Align
Risk management: Both frameworks place risk assessment and risk-informed decision-making at the center. ISO 27001's Clauses 6.1–6.1.3 and the NIST CSF's Identify Function address substantially the same risk management objectives.
Organizational governance: ISO 27001's Clause 5 (Leadership) and the NIST CSF 2.0's new Govern Function both require top-level commitment and integration of security into organizational governance.
Control implementation: ISO 27001's Annex A (Protect-oriented controls) aligns closely with the NIST CSF's Protect Function.
Detection and response: ISO 27001's incident management controls (Annex A 5.24–5.28) and technological monitoring controls (8.15–8.16) align with the NIST CSF's Detect and Respond Functions.
Recovery and resilience: ISO 27001's business continuity controls (5.29–5.30) and redundancy controls (8.14) align with the NIST CSF's Recover Function.
2.3 Where They Diverge
Depth vs. breadth: ISO 27001 is more prescriptive about management system requirements - documentation, internal audit, management review, continual improvement. NIST CSF is more prescriptive about specific security activities within each function.
Certification: ISO 27001 is certifiable. NIST CSF has no equivalent certification mechanism.
Technical specificity: NIST CSF Subcategories are more specific about technical activities than most ISO 27001 Annex A controls.
US regulatory alignment: NIST CSF was designed with US regulatory and government contexts in mind and is referenced in US federal cybersecurity requirements and CISA guidance.
2.4 Integration Strategy: Using Both Together
Use ISO 27001 as the management system backbone. The management system requirements provide the governance infrastructure that NIST CSF does not replicate.
Map Annex A controls to NIST CSF Categories. NIST has published a mapping between ISO 27001 controls and NIST CSF Categories.
Address NIST CSF gaps as ISMS enhancements. For NIST CSF requirements not addressed by ISO 27001's control set - typically in the Detect, Respond, and Recover Functions - add specific controls or enhanced procedures to the ISMS.
Produce a NIST CSF Profile as a reporting artifact. Using the NIST CSF Organizational Profile format, document the current and target states for each Function and Category.
Part 3 - ISO 27001 and SOC 2: The Trust Services Framework
3.1 What SOC 2 Is
SOC 2 (Service Organization Control 2) is an auditing standard developed by the AICPA for service organizations. It assesses whether a service organization's controls satisfy the Trust Services Criteria (TSC):
| Category | Description |
|---|---|
| Security (CC) | The foundational category - required for all SOC 2 reports |
| Availability | System availability commitments to users |
| Processing Integrity | Complete, valid, accurate, timely, and authorized processing |
| Confidentiality | Protection of confidential information |
| Privacy | Collection, use, retention, disclosure, and disposal of personal information |
Type I vs. Type II:
- SOC 2 Type I: Assesses whether controls are suitably designed at a point in time. Faster to obtain; less commercially valuable.
- SOC 2 Type II: Assesses whether controls operated effectively over a defined period (typically 6–12 months). Required by most enterprise customers.
3.2 Where ISO 27001 and SOC 2 Align
Common Criteria (CC) - Access controls: SOC 2's logical and physical access control criteria map directly to ISO 27001 Annex A controls in the access control domain (5.15–5.18) and physical security (7.1–7.2).
Change management: SOC 2's change management criteria align with ISO 27001 Annex A 8.32.
Risk assessment: SOC 2 requires evidence of risk assessment processes. ISO 27001's risk assessment framework satisfies this requirement when appropriately documented.
Incident response: SOC 2's incident response criteria align with ISO 27001's incident management controls (5.24–5.28).
Monitoring: SOC 2's monitoring criteria align with ISO 27001's monitoring and measurement requirements (Clause 9.1) and technological monitoring controls (8.15–8.16).
3.3 Where They Diverge
Scope and audience: SOC 2 is specifically designed for service organizations. A SOC 2 report is a customer-facing attestation; ISO 27001 certification is a market-facing credential.
Auditor type: ISO 27001 is audited by CB auditors accredited through national accreditation bodies. SOC 2 is audited by licensed CPAs.
Report vs. certificate: ISO 27001 produces a certificate. SOC 2 produces a detailed report typically shared under NDA with customers.
Control specificity: SOC 2's Trust Services Criteria are more specific about certain controls - particularly system monitoring, logical access provisioning, and encryption requirements for customer data.
Availability category: If the SOC 2 report includes the Availability category, it imposes specific requirements around uptime and incident notification.
3.4 Integration Strategy: ISO 27001 as the SOC 2 Foundation
Align scopes carefully. The ISO 27001 scope and the SOC 2 scope may differ - ensure that the controls required for SOC 2 compliance fall within the ISO 27001 ISMS scope.
Map the Trust Services Criteria to ISO 27001 controls. The AICPA has published mapping guidance between SOC 2 Trust Services Criteria and ISO 27001 controls.
Address SOC 2-specific requirements as ISMS enhancements. Common gap areas include: vendor management with specific customer notification requirements, system description documentation, and detailed logical access provisioning controls.
Coordinate audit timing. ISO 27001 surveillance audits and SOC 2 audit periods can often be aligned to reduce organizational disruption.
Part 4 - ISO 27001 and GDPR: The Security-Privacy Interface
4.1 GDPR's Security Requirements
Article 32 requires that controllers and processors implement "appropriate technical and organisational measures" including:
- Pseudonymisation and encryption of personal data
- Ability to ensure ongoing confidentiality, integrity, availability, and resilience of systems and services
- Ability to restore availability and access in a timely manner after an incident
- Process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures
4.2 ISO 27001 as GDPR Article 32 Evidence
A well-implemented ISO 27001 ISMS is the most comprehensive available demonstration of GDPR Article 32 compliance, for two reasons:
First, the risk-based approach mirrors GDPR's requirement. GDPR requires that security measures be appropriate to the risk - controls selected based on specific risks to specific personal data being processed. ISO 27001's risk assessment framework produces exactly this.
Second, the management system requirements exceed GDPR's expectations. GDPR requires measures; ISO 27001 requires a managed, documented, continuously improved system for implementing and maintaining those measures.
In regulatory enforcement proceedings, an ISO 27001 certificate is strong evidence that the organization took its security obligations seriously.
4.3 GDPR Requirements Beyond ISO 27001
Data subject rights: The rights to access, rectification, erasure, restriction, portability, and objection require specific operational processes. ISO 27001's control set does not address subject access requests.
Lawful basis and consent management: GDPR requires that processing has a lawful basis - consent, legitimate interest, contract performance.
Data Protection Impact Assessments (DPIAs): Article 35 requires DPIAs for high-risk processing activities.
Data Protection Officer (DPO): Where required, the DPO role has specific legal requirements.
Records of Processing Activities (RoPA): Article 30 requires controllers and processors to maintain records of their processing activities.
Integration approach: Extend the ISMS to incorporate privacy management elements - using the risk assessment framework for DPIAs, expanding the information asset register to serve as input to the RoPA, incorporating data breach notification procedures into incident management. ISO 27701 provides the formal structure for this extension.
4.4 Data Breach Notification: The Operational Interface
GDPR Article 33's 72-hour breach notification requirement is one of the most operationally demanding intersection points.
Breach detection capability: The ISMS must detect personal data breaches within a timeframe that allows the 72-hour notification window to be met.
Breach assessment process: Not every personal data incident constitutes a notifiable breach. GDPR requires notification only where the breach is "likely to result in a risk to the rights and freedoms of natural persons."
Notification content readiness: The Article 33 notification must include specific information - prepare notification templates and identify information sources in advance.
Supervisory authority contacts: Identify the national data protection authority contact in each EU member state where affected individuals are located, and embed these in the incident response playbook.
Part 5 - ISO 27001 and NIS2: The Essential Entity Requirement
5.1 What NIS2 Is
The Network and Information Security 2 Directive (NIS2) is EU legislation requiring essential and important entities to implement security measures and report significant incidents. It entered into force in January 2023, with member state transposition required by October 2023.
NIS2 applies to entities in sectors deemed critical to society - energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, and space - plus "important entities" in sectors including postal services, waste management, manufacturing, food production, and digital providers.
5.2 NIS2's Security Requirements and ISO 27001 Alignment
Article 21 of NIS2 requires "appropriate and proportionate technical, operational and organisational measures":
| NIS2 Requirement | ISO 27001 Alignment |
|---|---|
| Policies on risk analysis and information system security | Clauses 6.1–6.1.3; Information security policy (5.2) |
| Incident handling | Annex A 5.24–5.28 |
| Business continuity and crisis management | Annex A 5.29–5.30 |
| Supply chain security | Annex A 5.19–5.23 |
| Security in network and information systems acquisition, development, and maintenance | Annex A 8.25–8.31 |
| Policies and procedures to assess the effectiveness of cybersecurity risk-management measures | Clause 9.1; Clause 9.2 |
| Basic cyber hygiene practices and cybersecurity training | Annex A 6.3 |
| Policies and procedures regarding the use of cryptography | Annex A 8.24 |
| Human resources security and access control policies | Annex A 6.x; 5.15–5.18 |
| Use of multi-factor authentication | Annex A 8.5 |
5.3 Where NIS2 Goes Beyond ISO 27001
Incident reporting timelines: NIS2's three-stage notification regime - early warning within 24 hours, incident notification within 72 hours, final report within one month - is more prescriptive than ISO 27001.
Management accountability: NIS2 Article 20 requires that management bodies approve the cybersecurity risk-management measures and be liable for infringements. This creates personal legal liability for board members.
Cyber hygiene and training: NIS2 requires cybersecurity training for management bodies specifically - more specific than ISO 27001's general awareness requirements.
Registration and reporting: NIS2 requires entities to register with their national competent authority.
Supply chain security specifics: NIS2 Article 21(2)(d) requires addressing "specific vulnerabilities in each direct supplier or service provider" - more granular than ISO 27001's supplier controls.
5.4 Integration Strategy for NIS2-Subject Organizations
Extend incident management procedures to explicitly address the 24-hour and 72-hour NIS2 notification requirements.
Implement management body cybersecurity training as a specific addition to the awareness training program.
Enhance supply chain security to address NIS2's requirement for assessment of individual supplier vulnerabilities.
Establish the NIS2 registration and reporting process as an ISMS-adjacent compliance process.
Conduct a NIS2 gap assessment against the ISMS to identify specific areas where the current ISO 27001 implementation does not fully address NIS2 requirements.
Part 6 - ISO 27001 and DORA: Financial Sector Resilience
6.1 What DORA Is
The Digital Operational Resilience Act (DORA) - Regulation (EU) 2022/2554 - became directly applicable to EU financial entities from January 17, 2025. Unlike NIS2 (a Directive requiring national transposition), DORA is an EU Regulation that applies directly and uniformly across all EU member states.
DORA applies to banks, investment firms, insurance companies, payment institutions, electronic money institutions, crypto-asset service providers, and ICT third-party service providers to financial entities. It establishes requirements across five pillars:
- ICT risk management - comprehensive ICT risk management framework
- ICT-related incident management, classification, and reporting - specific incident classification and notification requirements
- Digital operational resilience testing - threat-led penetration testing (TLPT) for significant entities
- ICT third-party risk management - enhanced requirements for ICT service providers
- Information and intelligence sharing - voluntary sharing arrangements
6.2 DORA's ICT Risk Management Framework and ISO 27001
| DORA Requirement | ISO 27001 Alignment |
|---|---|
| ICT risk management framework | ISMS framework (Clauses 4–6) |
| ICT risk identification and assessment | Risk assessment (Clause 6.1.2) |
| ICT protection and prevention | Annex A Organizational and Technological controls |
| ICT detection | Annex A 8.15–8.16 (Logging and monitoring) |
| ICT response and recovery | Annex A 5.24–5.30 (Incident management and continuity) |
| ICT backup policies | Annex A 8.13 (Information backup) |
| ICT business continuity | Annex A 5.30 (ICT readiness for business continuity) |
| Communication and learning | Annex A 5.27 (Learning from incidents); Clause 7.4 (Communication) |
6.3 Where DORA Exceeds ISO 27001
Threat-Led Penetration Testing (TLPT): DORA Article 26 requires significant financial entities to conduct advanced threat-led penetration testing based on the TIBER-EU framework. This goes far beyond the annual penetration testing that ISO 27001-compliant organizations typically conduct.
ICT Third-Party Service Providers (ICT TPPs): DORA introduces large ICT service providers designated as critical by the European Supervisory Authorities (ESAs) being directly supervised by those authorities.
Contractual requirements for ICT contracts: DORA Article 30 specifies detailed mandatory content for contracts with ICT service providers - audit rights, performance SLAs, incident notification timelines, data portability, exit provisions - far more prescriptive than ISO 27001's Annex A 5.20.
ICT incident classification: DORA establishes a specific incident classification scheme with defined severity criteria. Major incidents must be reported within 4 hours of classification as major, with an intermediate report within 72 hours and a final report within one month.
Register of information on ICT arrangements: DORA requires a comprehensive register of all contractual arrangements with ICT service providers, with specific data elements.
6.4 Integration Strategy for DORA-Subject Organizations
Extend the risk assessment to explicitly address ICT risks as defined by DORA.
Enhance incident management procedures to accommodate DORA's classification scheme and the 4-hour notification requirement for major incidents.
Develop DORA-specific supplier management procedures addressing mandatory contract content requirements.
Establish TLPT capability if the organization falls within DORA's significant entity scope for TLPT requirements.
Maintain the ICT arrangements register as a formal document with the specific DORA-required data elements.
Part 7 - Building the Integrated Compliance Program
7.1 The Control Consolidation Map
The foundation of an integrated compliance program is a control consolidation map - a matrix that maps each compliance requirement from each applicable framework to the controls that address it.
Step 1 - Framework inventory: List all applicable frameworks and their specific requirements at the most granular requirement unit available.
Step 2 - Control mapping: For each requirement, identify the ISMS controls that address it. Multiple requirements may map to the same control.
Step 3 - Gap identification: Requirements not addressed by any current ISMS control represent gaps.
Step 4 - Redundancy identification: Controls addressing requirements from multiple frameworks are core to the integrated program and should be maintained with the highest priority.
7.2 The Evidence Reuse Architecture
The most operationally significant benefit of an integrated compliance program is evidence reuse - a single control activity produces evidence satisfying requirements across multiple frameworks simultaneously.
Example: Access review An access review conducted quarterly produces:
- Evidence for ISO 27001 Annex A 5.18 (Access Rights management)
- Evidence for SOC 2 CC6.2 (Logical and Physical Access Controls)
- Evidence for NIS2 Article 21 (Access control policies)
- Evidence for DORA Article 9 (Protection and prevention)
- Evidence for GDPR Article 32 (appropriate technical measures)
A single operational activity, properly documented, satisfies five framework requirements.
Example: Risk assessment The annual ISMS risk assessment produces:
- Evidence for ISO 27001 Clause 6.1.2 and Clause 8.2
- Input to NIST CSF Identify Function (ID.RA)
- Evidence for SOC 2 CC9.1 (Risk assessment process)
- Evidence for GDPR Article 32
- Evidence for NIS2 Article 21 (risk analysis policies)
- Evidence for DORA Article 6 (ICT risk management framework)
7.3 The Compliance Calendar Integration
Annual risk assessment: Timed to precede the annual management review and to provide input to the ISO 27001 SoA review, the GDPR DPIA schedule review, the DORA ICT risk assessment update, and the NIS2 risk management review.
Internal audit: The internal audit program should be designed to cover ISO 27001 requirements while also producing evidence relevant to SOC 2 Trust Services Criteria.
Supplier reviews: A single supplier review process, with tiers calibrated to the highest applicable framework requirement (DORA for ICT service providers, NIS2 for critical infrastructure supply chains), produces evidence for all applicable frameworks.
Management review: The management review agenda should include standing items for each applicable framework's governance requirements.
7.4 Framework-Specific Documentation Requirements
GDPR-specific documentation:
- Records of Processing Activities (RoPA) - Article 30
- Data Protection Impact Assessments (DPIAs) - Article 35
- Consent records (where consent is the lawful basis)
- Data subject request records and response timelines
NIS2-specific documentation:
- NIS2 registration documentation
- Incident notification records (24-hour early warning, 72-hour notification, one-month final report)
- Management body cybersecurity training records
DORA-specific documentation:
- ICT risk management policy (specific DORA format)
- ICT arrangements register (with DORA-required data elements)
- ICT incident classification records
- TLPT planning and results documentation (for significant entities)
- Major incident notification records (4-hour, 72-hour, one-month)
SOC 2-specific documentation:
- System description (part of the SOC 2 report)
- Complementary User Entity Controls (CUECs)
- Vendor management documentation meeting SOC 2-specific criteria
7.5 Compliance Ownership and Governance
The compliance owner model: A single compliance owner - typically the CISO or Chief Compliance Officer - is accountable for the integrated program, maintains the control consolidation map, manages the compliance calendar, and is the single point of contact for all compliance frameworks.
The subject matter expert model: Each framework has a named subject matter expert who maintains current knowledge of the framework's requirements, monitors for changes, and advises on framework-specific requirements.
The governance escalation model: Compliance issues exceeding the authority of the compliance function must have clear escalation paths to executive management and the board.
Part 8 - Framework Comparison Summary
8.1 The Decision Matrix
| Dimension | ISO 27001 | NIST CSF | SOC 2 | GDPR | NIS2 | DORA |
|---|---|---|---|---|---|---|
| Type | Management system standard | Voluntary framework | Auditing standard | Regulation | Directive | Regulation |
| Certifiable | Yes | No | Attestation report | No | No | No |
| Geographic scope | Global | Primarily US | Global (US-originated) | EU + EEA | EU | EU financial sector |
| Primary driver | Customer/market requirement | US federal/sector | B2B customer requirement | Legal obligation | Legal obligation | Legal obligation |
| Enforcement | Market/contract | None | Market/contract | Regulatory | Regulatory | Regulatory |
| Fine/penalty | None (market consequences) | None | None | Up to €20M / 4% global turnover | Up to €10M / 2% global turnover | Up to 1% average daily global turnover |
| ISO 27001 overlap | - | ~70-80% | ~60-70% | ~50-60% (Art. 32) | ~70-80% | ~65-75% |
8.2 The Integration ROI Case
Cost reduction: An integrated program requires approximately 40% fewer compliance FTEs than parallel programs for equivalent coverage, because evidence is reused rather than duplicated.
Audit fatigue reduction: Parallel programs generate parallel audits. Integrated programs coordinate audit schedules and share evidence bases.
Consistency improvement: Parallel programs frequently produce inconsistent controls. Integrated programs produce a single, consistent control description across all frameworks.
Summary: What Chapter 9 Has Established
The modern compliance landscape demands integration - a single, coherent security program that satisfies multiple framework requirements simultaneously.
ISO 27001 as the backbone: The ISO 27001 management system framework provides the most comprehensive single foundation from which other framework requirements can be addressed as extensions.
The alignment picture: NIST CSF aligns 70–80% with ISO 27001, with CSF's greater technical specificity in Detect/Respond/Recover providing useful augmentation. SOC 2 aligns 60–70%, with SOC 2's customer-facing attestation format complementing ISO 27001's market certification. GDPR's Article 32 security requirements are substantially satisfied by a well-implemented ISMS, with the privacy-specific obligations requiring ISO 27701 or equivalent extension. NIS2 aligns 70–80%, with specific gaps in incident notification timelines, management body accountability, and supply chain specificity. DORA aligns 65–75%, with significant gaps in TLPT requirements, ICT TPP oversight, incident classification speed, and contractual specificity.
The integration strategy: Control consolidation mapping, evidence reuse architecture, integrated compliance calendar, framework-specific documentation management, and unified compliance governance deliver the cost, efficiency, and consistency benefits of the integrated program.
Next: Chapter 10 - Sector Playbooks: ISO 27001 Applied to Finance, Healthcare, Cloud Providers, and Critical Infrastructure - With Implementation Checklists
© ISO 27001 Wiki - For CISOs, Security Analysts, and GRC Professionals