Designing a NIS2 Compliance Program and Roadmap

1. Anchoring Your Roadmap in the Current NIS2 Landscape

Before designing a roadmap, you must be clear about what NIS2 actually requires, right now.

Where NIS2 Stands Today (relative to Dec 2025)

• Directive (EU) 2022/2555 (NIS2) entered into force in January 2023.
• Member States had to transpose NIS2 into national law by 17 October 2024.
• As of today (late 2025), most EU countries:
• Have national NIS2 acts or amendments in force.
• Have identified or are identifying essential and important entities.
• Are issuing guidance, sectoral rules, and technical standards.

Key Implications for Your Roadmap

1. NIS2 is not directly applicable like a Regulation; your obligations arise from national transposition laws.
2. You must design a roadmap that aligns with:

• The Directive’s core obligations (risk management, reporting, governance, supply chain security, etc.).
• National specifics (e.g., stricter thresholds, reporting timelines, sectoral add‑ons, penalties).

1. NIS2 uses a risk‑based and proportionality approach:

• Controls must be commensurate with size, risk profile, and sector criticality.
• This is crucial for tailoring your roadmap (e.g., a small important entity vs. a large essential entity).

Link to Previous Modules

• You already know about supply chain risk and national authorities/CSIRTs.
• Your roadmap must:
• Integrate supplier risk management as a core workstream.
• Anticipate interactions with competent authorities and CSIRTs (for reporting, supervision, and incident handling).

In the next steps, you will translate these legal and institutional elements into a phased, project‑managed compliance program.

2. Scoping: Defining Organizational and System Boundaries

A NIS2 roadmap fails quickly if the scope is unclear. Scoping is Step 0.

2.1 Identify Whether the Entity is In‑Scope

Use Annex I (essential entities) and Annex II (important entities) of NIS2, then refine via national law:

• Essential entities (e.g., energy, transport, banking, health, DNS, TLD registries, cloud, data centers, etc.).
• Important entities (e.g., certain digital services, manufacturing of critical products, food production, postal services, etc.).

Check national criteria (often based on size‑cap rule: medium and large enterprises) and derogations (e.g., smaller but critical entities).

2.2 Define the Internal Scope

Once the legal entity is in scope, define what parts of the organization the roadmap covers:

• Business units / services that deliver the NIS2‑relevant service (e.g., electricity distribution, hospital care, cloud hosting).
• Information systems that support those services:
• Critical applications
• OT/ICS (for industrial sectors)
• Network infrastructure
• Identity and access management systems
• Supporting processes:
• HR (background checks, awareness)
• Procurement (supplier risk)
• Legal/compliance (contracts, incident reporting)

2.3 Edge Cases to Consider

• Group structures: A multinational group may have multiple NIS2 entities in different Member States with different competent authorities.
• Shared services: A central IT function serving several NIS2 entities—do you scope the shared platform as in‑scope for all entities?
• Cloud / outsourcing: If a critical function is outsourced, you must still treat it as in‑scope from a risk and control perspective.

Deliverable: A formal scope statement (1–2 pages) that your roadmap will use as the reference boundary.

3. Thought Exercise: Rapid Scoping for a Hypothetical Entity

Consider this scenario and draft a 1‑minute scoping note.

> Scenario:

> You are the security lead of MediLink Hospital Group, operating 3 large hospitals and 5 outpatient clinics in one EU Member State. National law classifies hospitals above a certain bed capacity as essential entities under NIS2. MediLink has a central IT department and uses a third‑party cloud EHR (Electronic Health Record) platform hosted in another EU country.

Task: In bullet points, define:

1. Is MediLink a NIS2 entity? If yes, what type?
2. Which services and systems fall into scope?
3. Which third parties are clearly in the NIS2 risk perimeter?

Write your answer somewhere (notes, text editor) before checking the model solution below.

Model solution (high‑level):

• MediLink is an essential entity (hospital sector, meets size threshold).
• In‑scope services: inpatient care, emergency care, surgery; possibly critical outpatient clinics if they support hospital operations.
• In‑scope systems: EHR platform, hospital information systems, PACS/radiology, network and identity infrastructure, backup and DR systems, OT in critical wards (e.g., ICU monitoring).
• Third parties: cloud EHR provider, network provider, critical medical device manufacturers with remote access, key IT service providers (e.g., SOC/MDR).

4. Designing a NIS2 Gap and Maturity Assessment

With scope defined, you perform a structured gap and maturity assessment.

4.1 Map Legal Requirements to Control Domains

Break down NIS2 (and national law) into practical domains. A common mapping (aligned with ENISA guidance and ISO/IEC 27001:2022) is:

1. Governance & Risk Management (policies, risk assessments, roles, board oversight)
2. Asset & Configuration Management
3. Identity & Access Management
4. Network & System Security (incl. secure development)
5. Incident Detection & Response (including reporting to CSIRT/authorities)
6. Business Continuity & Disaster Recovery
7. Supply Chain & Third‑Party Security
8. Human Factors (training, awareness, background checks)
9. Monitoring, Logging & Continuous Improvement
10. Compliance, Documentation & Auditability

4.2 Choose an Assessment Framework

To make your roadmap credible, align with recognized standards:

• ISO/IEC 27001:2022 and 27002:2022
• NIST CSF 2.0 (updated 2024) for a function‑oriented view
• Sectoral frameworks (e.g., DORA for financial entities, IEC 62443 for OT)

Define a maturity scale, e.g. 0–5:

• 0 = Non‑existent
• 1 = Ad‑hoc
• 2 = Repeatable but informal
• 3 = Defined and implemented
• 4 = Managed and measured
• 5 = Optimized and continuously improved

4.3 Evidence‑Based Assessment

For each control requirement:

• Ask: Does this exist? How well is it implemented?
• Collect evidence: policies, logs, system configs, training records, incident reports, contracts, etc.
• Interview process owners (IT, OT, legal, HR, procurement, operations).

4.4 Output

Produce:

• A gap register: for each requirement, note current maturity, target maturity (often at least 3 for NIS2), and description of the gap.
• A heatmap: visual overview of maturity per domain (e.g., red for low maturity, green for high).

This assessment becomes the backbone of your implementation roadmap.

5. Quiz: Interpreting Gap Assessment Results

Test your understanding of how to interpret a NIS2 gap assessment.

6. Prioritizing Controls, Quick Wins, and Risk‑Based Sequencing

After the gap assessment, you must convert findings into a prioritized, phased plan.

6.1 Prioritization Criteria

Rank each remediation item using at least three axes:

1. Regulatory criticality

• Is it explicitly required by NIS2/national law (e.g., incident reporting timelines, risk management, basic cyber hygiene)?
• Is it a focus area for supervisors (check national guidance, ENISA publications)?

1. Risk impact

• How much would failure of this control increase the likelihood or impact of major incidents?
• Does it affect safety, continuity of essential services, or systemic risk?

1. Effort / complexity

• Cost, time, organizational resistance, technical complexity.

You can add a fourth axis: dependency (does another control depend on this being implemented first?).

6.2 Quick Wins vs. Structural Changes

• Quick wins (low effort, high impact, or highly visible):
• Formalize incident reporting procedures and contacts to CSIRT.
• Update policies to explicitly reference NIS2 and national law.
• Implement basic MFA where technically easy.
• Launch targeted awareness training for management.
• Structural changes (high effort, foundational):
• Implement centralized logging and SIEM.
• Redesign supplier due‑diligence and contracting process.
• Introduce formal risk management and governance structures at board level.

A good roadmap mixes quick wins (to show progress) with structural initiatives (to actually reduce risk).

6.3 Phased Roadmap Structure

Typical phases for a 12–24 month program:

1. Phase 0 – Mobilization & Scoping
2. Phase 1 – Governance & Foundations (policies, roles, risk management, basic reporting)
3. Phase 2 – Technical & Process Controls (network security, IAM, incident response, backup/DR)
4. Phase 3 – Supply Chain & Integration (third‑party risk, contracts, continuous monitoring)
5. Phase 4 – Optimization & Audit Readiness (metrics, internal audits, management review)

Each phase should have clear deliverables, milestones, and owners.

7. Example: Prioritization Matrix for a Mid‑Size Cloud Provider

Imagine a mid‑size cloud provider classified as an essential entity under NIS2.

7.1 Selected Gaps from Assessment

| ID | Gap Description | Current Maturity | Reg. Criticality | Risk Impact | Effort |

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

| G1 | No formal NIS2‑aligned incident reporting process | 1 | High | High | Low |

| G2 | MFA not enforced for admin accounts | 2 | High | High | Medium |

| G3 | Supplier security clauses missing in 60% of critical contracts | 1 | High | High | High |

| G4 | Asset inventory incomplete for test environments | 2 | Medium | Medium | Low |

| G5 | No formal board‑level cybersecurity reporting | 1 | Medium | High | Medium |

7.2 Prioritization Logic

• Top priority: G1 and G2
• Directly touch incident handling and account compromise, high risk and high regulatory visibility, relatively low/medium effort.
• Second priority: G3
• Very high risk and critical under NIS2 (supply chain), but high effort—start early but expect longer timeline.
• Third priority: G5
• Important for governance and demonstrating compliance; schedule in Phase 1 or early Phase 2.
• Lower priority: G4
• Still necessary but less critical; can be treated as a quick win in parallel.

Phase allocation (simplified):

• Phase 1 (0–3 months): G1, G2, start G3, start G5.
• Phase 2 (3–9 months): Complete G3, G5; address G4.
• Phase 3 (9–18 months): Optimize and expand controls, add metrics and continuous monitoring.

8. Program Governance and Stakeholder Engagement

NIS2 compliance is not an IT project; it is an organizational change program.

8.1 Governance Structure

For a serious NIS2 program, define at least:

• Executive Sponsor: often the CIO, CISO, COO, or a board member. Ensures funding and authority.
• Program Steering Committee:
• Representatives from IT/OT, security, risk, legal, compliance, operations, HR, procurement.
• Meets regularly (e.g., monthly) to review progress and risks.
• Program Manager / PMO:
• Coordinates workstreams, manages dependencies, tracks milestones.
• Workstream Leads:
• Governance & Risk, Technical Security, Incident Response, Supply Chain, Training & Awareness, Documentation & Audit.

8.2 Stakeholder Mapping

Identify who is affected and what you need from them:

• Board and top management: approval of policies, risk appetite, resource allocation.
• IT/OT operations: implementation of technical measures.
• HR: training, background checks, disciplinary processes.
• Procurement: supplier onboarding, contract templates, vendor risk assessments.
• Legal & Compliance: interpretation of national law, regulator interactions.
• Business units: process changes, incident reporting, continuity planning.

8.3 Escalation and Decision‑Making

Define how conflicts are resolved:

• What if security requirements delay a product launch?
• Who decides acceptable residual risk for a critical third‑party dependency?

Document RACI matrices (Responsible, Accountable, Consulted, Informed) for key NIS2 processes (incident reporting, risk assessment, supplier onboarding, audits).

A clear governance model is itself evidence of compliance and will be scrutinized by supervisors.

9. Design a Mini Governance Model (Thought Exercise)

Using the MediLink Hospital Group scenario from Step 3, sketch a minimal but credible NIS2 governance model.

Task: Identify:

1. Executive sponsor
2. At least 3 key stakeholders and their roles
3. One concrete escalation rule

Write your answers before comparing with the model below.

Model solution (example):

• Executive sponsor: Chief Medical Officer (CMO) or COO, with delegated authority from the CEO.
• Key stakeholders:
• Head of IT: leads technical security workstream.
• Chief Nursing Officer: ensures clinical processes align with security and incident reporting.
• Head of Procurement: integrates NIS2 supplier requirements into contracts.
• Legal Counsel: interprets national NIS2 law and liaises with the health regulator.
• Escalation rule: Any cyber incident affecting patient care for more than 30 minutes must be escalated within 15 minutes to the CMO, CISO, and incident manager, who jointly decide whether to notify the national CSIRT within the legally required timeframe.

10. Documentation, Evidence, and Audit Readiness

NIS2 supervision is evidence‑driven. Having controls is not enough; you must prove they exist and work.

10.1 Documentation Architecture

Organize documentation in layers:

1. Policy level ("what" and "why")

• Information security policy, risk management policy, incident management policy, supplier security policy, etc.

1. Standard / procedure level ("how")

• Incident response playbooks, access management procedures, backup and restore procedures, vendor onboarding process.

1. Records / evidence level ("show me")

• Logs, tickets, risk registers, training attendance, incident reports, board minutes, supplier assessments, test results.

10.2 Evidence Management Practices

• Define evidence owners for each control domain.
• Establish retention periods consistent with national law and sectoral rules.
• Use structured repositories (e.g., GRC tools, document management systems) with version control.
• Periodically perform internal audits or readiness reviews:
• Sample incidents: can you show detection, triage, escalation, and reporting?
• Sample suppliers: can you show due diligence, contract clauses, and monitoring?

10.3 Preparing for Supervisory Actions

Under NIS2, authorities can perform:

• Off‑site supervision: request documentation, policies, incident reports.
• On‑site inspections: interview staff, review systems.

Your roadmap should include a "Supervision Readiness" workstream that:

• Maintains a NIS2 evidence catalogue (mapping each legal requirement to specific documents and records).
• Prepares standard briefing decks explaining your governance, risk management, and key controls.
• Trains relevant staff on how to interact with regulators and CSIRTs.

Audit readiness is not a one‑time event; it is a continuous capability.

11. Flashcards: Key Concepts in NIS2 Roadmapping

Flip the cards (mentally or in your notes) to reinforce the core concepts.

12. Final Check: Building a Coherent Roadmap

One last scenario to integrate scoping, prioritization, governance, and evidence.