The NIS2 Directive imposes concrete cybersecurity obligations on companies and operators of critical services. A structured NIS2 implementation roadmap helps decision-makers translate regulatory requirements into practical projects. In this practical guide I explain a five-step roadmap from the initial asset scan to audit readiness. The objective is for IT leadership, security officers, compliance teams and executive management to have clear decision points, responsibilities, cost estimates and evidence formats.
NIS2 implementation roadmap: overview of the five phases
The recommended roadmap is divided into five phases that can be processed sequentially or in parallel, depending on company size and available resources:
- Phase 1: Asset inventory and governance scoping
- Phase 2: Risk analysis and prioritization
- Phase 3: Measures planning, policies and supply chain due diligence
- Phase 4: Implementation, operations and evidence documentation
- Phase 5: Audit readiness, testing and continuous improvement
Each phase contains clear outputs, typical activities, possible metrics (KPIs) and common pitfalls. The following sections provide practical explanations, checklists and templates for operational implementation.
Phase 1: Asset inventory and governance scoping
The goal of this phase is to determine the organizational scope of NIS2 obligations and to produce an initial, auditable inventory of critical assets, services and suppliers.
What belongs in the scope?
Under NIS2 certain sectors and providers are defined as obliged entities. It is crucial to define internally:
- Which services and business processes require high availability or integrity (e.g. production control, payment processing, customer portals).
- Which IT systems directly support those services (applications, databases, APIs, network segments).
- Which third parties, cloud providers and suppliers perform critical functions.
In this phase the CMDB (Configuration Management Database) or an inventory spreadsheet is your most important artifact. If a CMDB is missing, create a simple, auditable list with minimum fields: asset name, owner, location, service dependency, risk assessment, supplier.
Specific activities and outputs
- Review existing inventories: network diagrams, Active Directory, cloud accounts, IAM roles, backup lists.
- Interview business unit owners about the business relevance of services.
- Initial supplier classification by critical role (e.g. authentication providers, network operators, SaaS with customer data access).
- Governance decision: appointment of an NIS2 responsible person (e.g. Head of Security or Compliance Officer) and a steering committee.
Audit evidence and quick wins
Create an initial evidence pack with: inventory CSV, organizational chart of responsibilities, workshop minutes and a scoping decision (steering committee minutes). Quickly implementable improvements include clear owners for backups and migration plans or basic multi-factor authentication for admin accounts.
Typical pitfalls
Incomplete inventories (especially container, cloud and DevOps assets) and undocumented third-party services lead to surprises later. Intentionally allocate time for discovery in developer and cloud environments.
Phase 2: Risikoanalyse und Priorisierung
With the inventoried scope, the risk analysis follows: which threats can affect the availability, integrity or confidentiality of your critical services and how likely are they? The risk analysis forms the basis for prioritization and budgeting decisions.
Methodology and practice
Use a risk‑based methodology such as qualitative‑quantitative scoring (e.g. likelihood 1–5, impact 1–5). Important: impact should be considered from a business perspective (e.g. revenue loss, regulatory sanction, reputational damage).
# Beispiel: einfache Risikoregister-Zeile (YAML-Format für Automation/Import)
- id: RSK-001
asset: Kundenportal-API
owner: IT-Application-Owner
threat: DDoS-Angriff
likelihood: 3 # 1..5
impact: 4 # 1..5
score: 12 # likelihood * impact
mitigation: Rate-Limiting, WAF, CDN
residual_score: 6
review_date: 2026-12-01
Outputs of this phase are a prioritized risk register, acceptable risk limits (Risk Appetite) from management, and candidate measures with rough effort estimates.
KPIs for management decisions
- Share of critical assets with a risk assessment (target, e.g. 100% within 3 months)
- Top-10 risks and expected cost in case of occurrence
- Coverage by existing controls (e.g. % assets with WAF, backup/RESTore test coverage)
Actions and prioritization
Prioritize measures by risk reduction per euro invested. Typical high priorities: protection against ransomware, robust backup and RESTore processes, access control for admin accounts, monitoring and incident response.
Phase 3: Action planning, policies and supply chain due diligence
Now comes the concrete planning: drafting policies, specifying technical measures, assigning responsibilities and defining contractual adjustments with suppliers.
Governance and policies
Define at least these core policies as auditable and binding:
- Incident response policy (escalation levels, reporting obligations, communication channels)
- Access and privilege management policy
- Backup and RESTore policy including test frequencies
- Supplier security policy and due diligence checklist
Incident-Response-Policy (Auszug)
- Meldepflicht: Sicherheitsvorfälle, die Dienstverfügbarkeit > 1 Stunde oder Kundenbeeinträchtigung verursachen, sind innerhalb 24 Stunden intern zu melden.
- Eskalation: Team Lead -> Head of Security -> Geschäftsführung (bei Auswirkung > x)
- Externe Meldung: gemäß NIS2-Reporting-Fristen an zuständige Behörde, Responsible dokumentiert Zeitpunkt und Inhalte.
Manage supply chain risks concretely
NIS2 requires increased due diligence for third-party providers. Measures:
- Identify and classify critical suppliers.
- Embed standardized security requirements in SLAs and contracts (e.g. access RESTrictions, audit rights, incident reporting obligations).
- Define a due diligence process: security assessment before contract signing, followed by periodic reviews.
Example contract clause (Supplier-Security)
- Supplier undertakes to report security incidents that could affect service operations without delay (max. 48 hours).
- Supplier grants annual audit rights and discloses penetration test reports on request.
- SLA extension: mandatory recovery time objective (RTO) and recovery point objective (RPO) for critical data.
Budget and timeline planning
Create a portfolio of measures with effort estimates (person-days, third-party costs, license costs). Distinguish short-term measures (0–3 months), medium-term (3–12 months) and long-term architectural changes (>12 months).
Phase 4: Implementation, Operations and Evidence Documentation
The implementation phase is not only about technology, but primarily about operational resilience and evidence documentation: How do you ensure that implemented measures remain effective and verifiable over time?
Implementation with operational impact
Technical measures must be introduced in a way that is compatible with operations. A typical implementation stack includes:
- Hardening of endpoints and servers, patch management processes
- Network segmentation and Zero-Trust principles (least-privilege access control)
- SIEM/logging with defined correlations and retention policies
- Backup automation and regular recovery exercises
Clear runbooks are necessary for operations teams: start, stop and recovery procedures, responsibilities and SLA definitions.
Evidence documentation and audit trail
NIS2 requires evidence of measures, tests and management decisions. Make the following artifacts available:
- Records of risk workshops and management decisions
- Change records and test reports (e.g. RESTore tests, penetration test reports)
- Monitoring and incident logs with integrity-protected archive
- Supplier contracts with security clauses and audit results
Example: Minimal evidence for a Backup-Requirement
Backup evidence (example)
- Backup plan: describes scope, frequency, responsible party
- RESTore test: date, responsible person, RESTored data/services
- Result: successful / partial / failed with follow-up action
- Archive: test report and management approval
Phase 5: Audit readiness, testing and continuous improvement
The final phase ensures that your company passes inspections by the competent authorities or internal audits and continuously derives improvements.
Audit readiness in practice
Audit readiness means: auditors must be able to trace who made which decisions, which measures were implemented and how they were verified. Typical audit areas are:
- Governance and responsibilities
- Risk management and prioritization
- Technical controls (patch management, network segmentation, SIEM)
- Incident response and reporting processes
- Supplier management and contractual evidence
Types of tests and frequencies
Plan recurring tests:
- Tabletop exercises for management and incident response teams (semi-annually)
- RESTore and RTO/RPO checks (quarterly to semi-annually depending on the service)
- Penetration testing and Red-Teaming (annually or after major changes)
- Supplier audits (annually or risk-based)
Continuous improvement
Use insights from tests and incidents for improvement cycles. A simple PDCA cycle (Plan-Do-Check-Act) with documented actions and management reviews meets NIS2 requirements for governance.
Governance: Responsibility, RACI and management reporting
Clear responsibilities are crucial. A RACI pattern (Responsible, Accountable, Consulted, Informed) provides straightforward operationalization and auditable assignments. Example RACI for backups:
- Responsible: System Owner – performs RESTore tests
- Accountable: Head of IT Operations – approves frequency and resources
- Consulted: Application Owner, Security
- Informed: Executive management, Compliance
For management reporting define a small dashboard with 6–8 KPI fields (e.g. share of tested backups, open findings, MTTD, MTTR, % of critical suppliers with contract, % of assets inventoried). These metrics are usually sufficient for monthly or quarterly reviews.
Cost transparency and budgeting
Decisions need a financial basis. Structure the budget into three classes: Operations (ongoing licenses, personnel), Projects (implementation of new controls) and Reserve (for emergency consulting or external forensics). Create rough estimates for each measure: initial costs, annual recurring costs, expected savings from risk reduction.
Technical audit paths and samples for auditors
Audits often operate by sampling. Therefore define audit paths that are easy to follow: selection of 10 random assets, 3 critical suppliers and 5 recently closed changes. Define sample queries for logging and backup systems to provide auditors with quick answers.
# Example inventory CSV header
asset_id,asset_name,service_owner,service,location,criticality,cloud_provider,backup_scope,last_backup_date
-- Example SIEM query (simplified pseudo-SQL)
SELECT timestamp, host, event_type, user FROM logs
WHERE event_type IN ('failed_login','privilege_escalation')
AND timestamp >= NOW() - INTERVAL '7 days';
Evidence index: template for audit evidence
An evidence index saves time during audits. Structure it by topics (Governance, Inventory, Risk, Controls, Tests, Suppliers) and list documents with date, owner and storage location (e.g. DMS path or archive ID). An entry could look like this:
Evidence index entry
- Topic: RESTore test Customer Portal
- Date: 2026-04-12
- Responsible: IT-Operations
- Storage location: DMS/Compliance/Backups/RESTore-2026-04-12.pdf
- Brief summary: Complete RESTore in 01:45h, validation by App-Owner OK, open findings: 0
Practical recommendations for small and medium-sized enterprises
SMEs should proceed pragmatically: prioritize by business value and use cases. Focus first on identity-based controls (MFA, admin sessions), reliable backups and clear supplier agreements. Complete technical solutions are seldom necessary; demonstrable processes and regular tests are often sufficient.
Conclusion: Decide, prioritize, continuously demonstrate evidence
NIS2 is not a one‑off IT task but an organizational project with technical, contractual and operational implications. A clear NIS2 implementation roadmap structures the work, creates evidence and helps allocate budget efficiently. Crucial are a reliable inventory, risk‑based prioritization, binding policies and regular tests with documented results. Executives must assign responsibilities formally, provide budget and require the results in management reviews.
With the five‑phase roadmap outlined here you can implement NIS2 obligations in a structured way, control operational risks and deliver audit‑ready evidence. Start with an incremental rollout, measure progress with clear KPIs and use tests as a learning source for continuous improvement.
NIS2-implementation roadmap: architecture and operational pitfalls often overlooked
In addition to the roadmap, a number of technical and operational detail questions are decisive in practice: they affect cost, auditability and the operational robustness of your measures. Below are practical notes that are often discovered too late — with concrete responsibilities and actionable countermeasures.
Architectural risks and mitigations
- Shadow integrations: APIs, webhooks and service accounts that exist outside official CMDB processes are common entry points. Measure: discovery scan (cloud APIs, identity audit) and a mandatory onboarding checklist for integrations. Owner: IT‑Operations/Cloud Team.
- Log pipeline and costs: Long retention in SIEM can become expensive. Prioritize log retention by risk class (e.g. full audit logs only for critical assets). Define storage costs as an operational expense line in budget plans.
- Configuration integrity: Non‑versioned configurations complicate audit evidence. Solution: Git‑based configurations with signed releases and automatic deployment history. Responsible: Platform/Infra Team.
- Data locality and vendor compliance: Check whether third parties process data in regions that are regulatorily problematic. Contract clauses and technical isolation mechanisms must be aligned.
Operational pitfalls
- MFA exceptions: Exceptions for emergency access are often not properly documented. Implement a time‑bound approval practice and log all exceptions automatically.
- Patch cadence vs. availability: A conservative patch process without canaries can lead to large, risky rollouts. Use staged rollouts and defined backout plans (Canary + Monitoring + Rollback).
- Evidence automation: Manual evidence collection is error‑prone. Automate audit reports (e.g. backup test results, patch status) and archive metadata (hash, timestamp, auditor) in a DMS.
Concrete operational example: automated backup evidence
#!/bin/bash
# Holt Backup-Status vom Backup-API und legt PDF/JSON im DMS ab (vereinfachtes Beispiel)
curl -s -H "Authorization: Bearer $API_TOKEN" "https://backup.example/api/v1/status/latest"
-o /tmp/backup-status.json
jq . /tmp/backup-status.json > /var/dms/Compliance/Backup-Status-$(date +%F).json
Such automations reduce audit effort and create reliable time series. Define responsibilities and SLAs for these scripts (who maintains, who validates). Finally: decide early on configuration and log retention, automate evidence flows and integrate staged rollouts into your operational processes — this reduces risk, the effort to provide evidence and long-term costs.
Nis2 compliance is also important for this topic. The article puts these aspects into clear context and shows what matters in day-to-day operations.