Integrating NIS2 with Existing Frameworks (ISO 27001, SOC 2, Sectoral Rules)

1. Orienting NIS2 Among Existing Frameworks

NIS2 (Directive (EU) 2022/2555) entered into force in 2023 and must be transposed by Member States by 18 October 2024. As of today (late 2025), most EU countries have enacted or are finalizing national laws implementing NIS2.

For organizations that already use ISO/IEC 27001:2022, ISO/IEC 27002:2022, SOC 2, or sectoral regimes (e.g., DORA, GDPR, PSD2, healthcare rules), NIS2 is not a fresh start. Instead, it is a regulatory overlay that you can meet largely by:

• Mapping NIS2 obligations to existing controls
• Identifying residual gaps (especially governance, supply chain, and reporting)
• Integrating NIS2 into your existing ISMS or GRC structure

Key high‑level distinctions:

• NIS2 is law, not a voluntary standard. It imposes minimum cybersecurity risk‑management measures and incident reporting obligations on “essential” and “important” entities.
• ISO 27001 is a certifiable management system standard; ISO 27002 is a control catalogue. They are technology‑neutral and globally used.
• SOC 2 (AICPA) is an assurance report, not a management system. It focuses on Trust Services Criteria (TSC): Security, Availability, Confidentiality, Processing Integrity, Privacy.
• Sectoral rules (e.g., DORA for financial entities, eIDAS, medical device cybersecurity) partially overlap NIS2 but often have more specific requirements.

In this module you will learn to:

1. Interpret NIS2’s risk‑management and reporting requirements through the lens of ISO 27001/27002 and SOC 2.
2. Build a control‑mapping matrix and spot overlaps and gaps.
3. Integrate NIS2 into an integrated management system to avoid duplicated audits and documentation.

Keep your mental model: NIS2 = what the law requires; ISO/SOC2 = how you demonstrate you meet it.

2. Decomposing NIS2 Operational Requirements

For integration, you need a structured breakdown of NIS2. Focus on three clusters:

2.1 Risk‑management measures (Article 21)

NIS2 requires entities to implement appropriate and proportionate technical, operational and organizational measures. Article 21(2) lists minimum areas, including:

1. Policies on risk analysis and information system security
2. Incident handling
3. Business continuity and crisis management (including backup, disaster recovery)
4. Supply chain security, including security‑related aspects of relationships between entity and direct suppliers/service providers
5. Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure
6. Policies and procedures to assess the effectiveness of cybersecurity risk‑management measures
7. Basic cyber hygiene practices and cybersecurity training
8. Policies and procedures regarding the use of cryptography and, where appropriate, encryption
9. Human resources security, access control policies and asset management
10. Use of multi‑factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems where appropriate

2.2 Incident reporting (Articles 23–24)

Key obligations (with exact timing defined in NIS2, sometimes refined by national law):

• Early warning to the CSIRT or competent authority within 24 hours of becoming aware of a significant incident
• Incident notification within 72 hours with initial assessment
• Final report within 1 month (or after mitigation)

You must have:

• Criteria for what counts as a significant incident
• Processes and tooling to detect, triage, and escalate incidents
• Clear roles and communication paths to CSIRTs and regulators

2.3 Governance, accountability, and enforcement

NIS2 strengthens management accountability:

• Management bodies must approve and oversee the implementation of cybersecurity risk‑management measures.
• They are required to follow specific training and may face personal liability under national law for non‑compliance.

These aspects are often less explicit in ISO 27001 and SOC 2, so they are frequent gap areas.

For mapping, treat each of these NIS2 elements as a requirement row in your future control‑mapping matrix.

3. Mapping NIS2 Article 21 to ISO/IEC 27001:2022 and ISO/IEC 27002:2022

You can think of ISO 27001/27002 as your toolbox and NIS2 as the building code. The table below shows a conceptual mapping (not exhaustive) from NIS2 Article 21(2) items to ISO 27001/27002 controls.

> Visualize this as a spreadsheet where each NIS2 requirement is a row, and you have columns for ISO 27001 clause, ISO 27002 control, SOC 2 criteria, status, evidence, and owner.

| NIS2 Art. 21(2) area | Typical ISO/IEC 27001:2022 / 27002:2022 alignment |

|----------------------|----------------------------------------------------|

| 1. Policies on risk analysis and information system security | 27001 Clause 4–10 (Context, Leadership, Planning, Support, Operation, Performance evaluation, Improvement); 27002 controls such as 5.1 Information security policy, 5.7 Threat intelligence, 8.28 Secure coding |

| 2. Incident handling | 27002 5.24 Information security incident management planning and preparation, 5.25 Assessment and decision on information security events, 5.26 Response to information security incidents, 5.27 Learning from incidents |

| 3. Business continuity & crisis management | 27002 5.29 ICT continuity, 5.30 ICT readiness for business continuity, 5.31 Identification of legal and contractual requirements; alignment with ISO 22301 if present |

| 4. Supply chain security | 27002 5.19 Information security in supplier relationships, 5.20 Addressing information security within ICT supply chain, 5.21 Managing information security in the use of cloud services |

| 5. Security in acquisition, development, maintenance | 27002 8.25 Secure development life cycle, 8.26 Application security requirements, 8.27 Secure system architecture and engineering principles, 8.28 Secure coding, 8.33 Protection of systems during audit testing |

| 6. Effectiveness assessments | 27001 Clause 9 Performance evaluation; 27002 5.36 Compliance with policies and standards for information security, 5.37 Documented operating procedures; internal audit process |

| 7. Cyber hygiene & training | 27002 6.3 Information security awareness, education and training, 6.2 Segregation of duties, 8.1 User endpoint devices |

| 8. Cryptography & encryption | 27002 8.24 Use of cryptography, 8.23 Information masking, 8.22 Data leakage prevention |

| 9. HR security, access control, asset management | 27002 6.1 Screening, 6.4 Disciplinary process, 8.2 Privileged access rights, 8.3 Information access restriction, 5.9 Inventory of information and other associated assets |

| 10. MFA and secure communications | 27002 8.2 Privileged access rights, 8.4 Access to source code, 8.5 Secure log‑on procedures, 8.21 Security of network services, 8.20 Use of network services |

Key insight: If you are certified against ISO/IEC 27001:2022 and have a reasonably mature control implementation, you already cover a large proportion of NIS2 Article 21. Your real work is to:

1. Prove that these controls are appropriate and proportionate for your risk profile and sector.
2. Close gaps in governance, incident reporting timing, and supply‑chain depth demanded by NIS2.

4. Hands‑On: Build a Mini NIS2–ISO Control Map

Imagine you are the security lead at a cloud‑based payment processor headquartered in an EU Member State, already ISO 27001:2022 certified.

Your task: For each NIS2 requirement below, write down (mentally or on paper) which ISO 27002 controls you would reference first.

1. You must ensure multi‑factor authentication for remote administrative access to critical systems.
2. You must have a documented process to notify the national CSIRT of a significant incident within 24 hours.
3. You must manage security risks from a third‑party cloud provider that hosts your production environment.

Reflect, then compare with the suggested mapping:

• 1. MFA for remote admin access

Likely 27002 controls: 8.2 Privileged access rights, 8.5 Secure log‑on procedures, 8.1 User endpoint devices, possibly 8.20 Use of network services.

• 2. Incident notification process

27002 controls: 5.24–5.27 (incident management life cycle). However, note: ISO 27002 does not explicitly encode 24‑hour reporting to authorities. That timing is a NIS2‑specific legal requirement, so you would add it in your ISMS procedures and playbooks, not just rely on ISO.

• 3. Third‑party cloud provider risk

27002 controls: 5.19 Information security in supplier relationships, 5.20 Addressing information security within ICT supply chain, 5.21 Managing information security in the use of cloud services.

Takeaway: The mapping is strong but not perfect. Any time you see timelines, regulator communication, or management liability, expect NIS2‑only additions on top of ISO.

5. Aligning NIS2 with SOC 2 Trust Services Criteria

SOC 2 reports assess how well your controls meet the Trust Services Criteria (TSC), organized under COSO principles. Unlike ISO 27001, SOC 2 is not a management system standard but a controls‑based attestation.

5.1 Conceptual mapping

NIS2 risk‑management measures and reporting obligations can be related to SOC 2 as follows:

• Security (Common Criteria, CC series)

Aligns with NIS2’s baseline security requirements: access control, change management, vulnerability management, incident response.

• Availability (A series)

Overlaps with NIS2’s business continuity and incident handling expectations.

• Confidentiality (C series) and Privacy (P series)

Support NIS2 where personal data or confidential service data are at risk; integrate with GDPR obligations.

• Processing Integrity (PI series)

Less central to NIS2, but relevant for sectors where integrity of transactions is critical (e.g., payments, energy dispatch systems).

5.2 Typical NIS2–SOC 2 mapping examples

• NIS2 incident handling → SOC 2 CC7.2, CC7.3, CC7.4 (monitoring, detecting, and responding to security events)
• NIS2 business continuity → A1.2, A1.3 (availability commitments, disaster recovery) and CC9.2 (risk mitigation)
• NIS2 supply chain security → CC3.2 (board oversight), CC9.2 (identifying and mitigating risks from business partners), sometimes C1.2 (confidentiality commitments with third parties)
• NIS2 policies and training → CC2.1–CC2.4 (communication and training), CC3.1–CC3.4 (control environment)

5.3 Where SOC 2 falls short for NIS2

SOC 2 does not inherently:

• Enforce specific legal reporting timelines (24h/72h/1 month)
• Address EU‑specific regulatory structures (CSIRTs, competent authorities, EU‑CyCLONe)
• Mandate management body liability or training as NIS2 does

Therefore, a SOC 2 report can provide strong evidence of operational control effectiveness, but you must augment it with:

• A legal/regulatory overlay mapping SOC 2 controls to NIS2
• Additional procedures for regulator communications, incident significance criteria, and board‑level oversight

Think of SOC 2 as a powerful evidence package inside your broader NIS2 compliance dossier, not as a standalone guarantee of NIS2 compliance.

6. Quick Check: SOC 2 vs NIS2

Test your understanding of how SOC 2 aligns with NIS2.

7. Integrating Sectoral Rules and National Standards with NIS2

Many NIS2‑covered entities are also bound by sector‑specific regimes and national standards. Integration is crucial to avoid conflicting requirements and audit fatigue.

7.1 Common sectoral overlaps

• Financial sector:
• DORA (Regulation (EU) 2022/2554) entered into force in 2023 and started applying in 2025. It imposes detailed requirements on ICT risk management, incident reporting, digital operational resilience testing, and third‑party risk.
• NIS2 and DORA both require robust ICT security and incident reporting, but DORA is more granular for financial entities and has its own supervisory structure.

• Healthcare and medical devices:
• NIS2 covers healthcare providers and some digital health services.
• Medical devices and in vitro diagnostics are regulated under MDR and IVDR, which now include cybersecurity expectations (e.g., secure design, vulnerability handling).
• National health data regulations and EHR rules may impose additional security and logging requirements.

• Energy and transport:
• Often subject to network codes, aviation/maritime safety rules, and critical infrastructure protection laws, some of which pre‑date NIS2.

7.2 Integration principles

1. Single risk register and control catalogue

Maintain one master risk register and one master control set (often ISO 27002‑based), and tag each control with:

• Applicable frameworks (NIS2, ISO 27001, SOC 2, DORA, GDPR, etc.)
• Evidence sources (policies, logs, reports)

1. Harmonize incident taxonomies and thresholds

• DORA, NIS2, and GDPR all have incident/ breach concepts with different thresholds and timelines.
• Build a unified incident classification matrix that maps one event to multiple reporting obligations.

1. Avoid conflicting requirements

• If sectoral rules are stricter than NIS2 (e.g., shorter reporting timelines, more detailed testing), treat NIS2 as the floor and the sectoral rule as the ceiling. Implement to the stricter standard and document that it satisfies NIS2.

1. Use national standards as implementation guidance

• Some Member States publish national cybersecurity baselines or sectoral guidelines. These can help interpret what is “appropriate and proportionate” under NIS2 in your national context.

The goal is a coherent, layered architecture where NIS2 is just one more tag in your integrated control library, not a separate program.

8. Design an Integrated Incident Reporting Workflow

Thought exercise: You are CISO at a large EU bank subject to NIS2, DORA, and GDPR. Consider a cyber incident where a DDoS attack on your online banking platform causes 6 hours of unavailability and minor leakage of pseudonymized customer data.

Task: Sketch a high‑level, integrated workflow (mentally or on paper) that answers:

1. Which regimes are likely triggered (NIS2, DORA, GDPR)?
2. How do you avoid separate, conflicting playbooks for each regime?
3. What single set of steps can you define that will satisfy all three?

Reflect, then compare with this outline:

• Regimes triggered:
• NIS2 (significant incident affecting essential service availability and possibly data)
• DORA (major ICT‑related incident affecting critical services)
• GDPR (personal data breach, even if pseudonymized, depending on risk to individuals)

• Unified playbook approach:
• Maintain one incident classification scheme that includes criteria for NIS2, DORA, GDPR severity.
• Trigger a single major‑incident process covering: triage, containment, forensics, communication, regulatory notifications.

• Single set of steps (simplified):

1. Detect and verify incident; classify severity using a matrix that embeds NIS2/DORA/GDPR thresholds.
2. Launch major‑incident bridge including IT, legal, compliance, DPO, and PR.
3. Decide on reportability under each regime; record rationale.
4. Prepare a core incident factsheet and tailor it into:

• NIS2 notification to national CSIRT/authority
• DORA incident report to financial supervisor
• GDPR breach notification to DPA and possibly data subjects

1. Coordinate timelines so the earliest deadline drives the process.
2. Feed lessons learned back into the shared risk register and control set.

The key integration move is to drive all regulatory outputs from one process and one dataset, rather than running three parallel workflows.

9. Building an Integrated Management System for NIS2

To avoid duplication and audit fatigue, many organizations implement an Integrated Management System (IMS) that combines:

• ISO/IEC 27001 (information security)
• Possibly ISO 22301 (business continuity), ISO 20000‑1 (service management), ISO 9001 (quality)
• SOC 2 reporting controls
• NIS2, DORA, GDPR, and national requirements

9.1 Core components of an IMS for NIS2

1. Unified policy framework

• One Information Security Policy referencing NIS2 and other regimes.
• Sub‑policies (e.g., Incident Management Policy, Supplier Security Policy) mapped to NIS2 Article 21 areas.

1. Single risk management methodology

• Risk identification, analysis, evaluation, and treatment done once, with outputs reused for ISO 27001, NIS2, SOC 2, and sectoral laws.

1. Integrated control library

• Use ISO 27002:2022 as the backbone, add controls specific to NIS2 (e.g., CSIRT reporting timelines), DORA (e.g., advanced resilience testing), GDPR (e.g., DPIAs), etc.
• Each control is tagged with applicable frameworks.

1. Central evidence and documentation repository

• A GRC tool or structured SharePoint/Confluence space where you:
• Store policies, procedures, records, logs, reports
• Link each item to controls and frameworks
• Facilitate reuse for audits and regulatory inspections

1. Coordinated audit and review calendar

• Plan internal audits and management reviews to cover multiple frameworks simultaneously.
• For example, one internal audit cycle could simultaneously test ISO 27001 controls, NIS2 incident reporting, and SOC 2 readiness.

9.2 Governance and accountability

• Ensure the management body formally approves the IMS and is briefed on NIS2 obligations, including potential personal liability under national law.
• Use existing ISO 27001 management review meetings to also review NIS2 compliance status, incident statistics, and regulatory interactions.

This approach makes NIS2 compliance a by‑product of good governance, rather than a separate, parallel project.

11. Key Concept Review

Flip these cards (mentally) to reinforce core concepts about integrating NIS2 with existing frameworks.

12. Synthesis Challenge

One final question to check your ability to integrate NIS2 with existing frameworks.