NIS2 becomes manageable when each outstanding requirement leads to a decision: what must we protect, what already works and who will close the remaining gap? This guide combines an implementation roadmap with a practical checklist. Use it to build your action plan and identify work that needs to run in parallel.

Scope: The legal references concern Germany. Reviewed on 29 October 2026. Austria has its own NISG 2026 and authority procedures. A project plan does not extend a statutory deadline.

Where to start

Your situation	Next useful step	Outcome
Applicability is unclear	Assess the entity, its activities and size criteria	Reasoned classification with open questions
Applicability confirmed, registration outstanding	Establish authority access and required information	Registration and a responsible contact
An ISMS is in place	Assess existing measures against NIS2 requirements	An additions list rather than a second management system
Measures exist, evidence is scattered	Verify effectiveness and associate evidence	A traceable implementation status

The NIS2 calculator supports an initial assessment. Borderline cases require consideration of linked enterprises and special entity categories. Headcount alone does not determine applicability.

1. Establish scope and responsibility

Describe the entity and its services first. Which business processes depend on which information, applications, locations and suppliers? A server list is not enough: you also need the relationship between a technical failure and its business impact.

Record the classification, its basis, the assessment date and outstanding assumptions. The threshold database helps distinguish size criteria from sector-specific conditions.

Appoint an operational coordinator and owners across IT, business functions, procurement and incident handling. Management needs to decide on risks, resources and priorities. In Germany, its implementation, oversight and training obligations follow from section 38 BSIG. External support does not replace that responsibility.

Outcome: A traceable scope, a reasoned classification and people authorised to make decisions.

2. Address registration and incident readiness in parallel

Do not wait for the complete measures programme before addressing registration and incident handling. Establish your applicable registration deadline and prepare access to the authority. The BSI registration guide explains the procedure and information required.

For significant incidents, section 32 BSIG requires an early notification without undue delay and no later than 24 hours after awareness, followed by a further notification within 72 hours. The final report is generally due no later than one month after the second notification; ongoing incidents have specific follow-up requirements.

Define who assesses an incident, documents the time of awareness, involves management and prepares notifications. Name a deputy. Rehearse internally using a fictional incident; do not send unannounced test incidents to a real reporting authority.

The reporting guide and incident report template support preparation. Internal incident documentation does not replace an obligatory notification.

3. Assess existing security before assigning new work

Collect existing risk assessments, policies, recovery tests, supplier assessments and training records. For each document, ask: which systems and period does it cover? Was the described process actually performed? Are there outstanding deviations?

A backup policy demonstrates planning. A traceable recovery test shows whether the tested data and systems became usable under the tested conditions. This distinction prevents a well-stocked document repository from being mistaken for effective security.

The NIS2 requirements define the assessment areas. An existing ISO 27001 ISMS provides a useful foundation. The NIS2–ISO 27001 mapping guide explains how to reuse that work. Certification does not replace assessment of statutory obligations.

4. Close gaps according to risk and dependencies

Prioritise based on the impact on your services, applicable obligations and actual weaknesses. Every measure needs an owner, a deadline, resources and a verifiable acceptance criterion.

Fictional example: A service provider backs up customer data daily. Its last recovery test is outdated. “Backup available” is therefore not accepted as complete. The owner must test a representative recovery, document the result and address deviations. Business owners assess whether the achieved recovery time meets the needs of the service.

Measure	Acceptance question	Suitable evidence
Test recovery	Can the required service be restored within internally defined objectives?	Test record with scope, result and deviations
Assess a critical provider	Have dependencies, security requirements and residual risks been assessed?	Assessment with contractual context and a decision
Rehearse incident handling	Do information and decisions reach the right people in time?	Exercise record with improvement actions
Introduce a policy	Is the approved version available and communicated to relevant people?	Version, approval and appropriate training or acknowledgement records

Technical measures can run in parallel: protecting privileged access, addressing critical vulnerabilities or improving recoverability. Their design follows your risk assessment. Generic password lengths, retention periods or fixed product lists are not universal NIS2 evidence.

Supply-chain security belongs in the programme from the start. Begin with providers whose failure or security incident would materially affect your services. Always check the actual scope of certificates and assurance reports.

5. Make effectiveness and change part of operations

A completed task does not establish lasting protection. Define who reviews results and which changes trigger reassessment: a new provider, a different application, a vulnerability or an incident.

Bring risks, deviations and decisions together in regular management reviews. Metrics should show whether protection works, rather than merely counting closed tasks. For example, assess failed recoveries, overdue critical measures and unresolved dependencies in their business context.

NIS2 checklist: is your implementation substantiated?

Use these questions in your next assessment. “Open” creates work; “fulfilled” requires a traceable basis.

Assessment question	What to record
Is our applicability decision justified?	Entity, activity, size criteria, special cases and review date
Are owners and deputies named?	Decision authority, operational roles and escalation
Are registration and contact information addressed?	Evidence, owner and maintenance process
Do we know critical services and dependencies?	Business processes, information assets, systems and providers
Have we assessed risks and prioritised measures?	Assessment, treatment decisions and outstanding work
Do detection and incident handling work?	Roles, communication, deadline assessment and exercise results
Has recovery been tested in practice?	Test scope, results, deviations and follow-up actions
Are critical suppliers assessed?	Requirements, evidence, contractual context and residual risks
Do policies and training reach the right people?	Audience, approved content and suitable records
Do we follow up effectiveness and changes?	Review triggers, results and management decisions

How long does NIS2 implementation take?

A defensible schedule starts with your current state. An existing ISMS can save work; outdated evidence, additional locations or untested recovery procedures can still require considerable effort.

Plan around verifiable outcomes rather than a generic 3–6–12-month promise. Start by clarifying classification and responsibility, addressing urgent obligations in parallel, assessing existing work and deriving a prioritised programme. Statutory deadlines remain independent of this project plan.

Separate internal effort, external support, technical implementation, software and ongoing maintenance in your budget. A software licence replaces neither technical safeguards nor management decisions. See the NIS2 cost guide for further context.

From checklist to ongoing implementation with Kopexa

In Kopexa, evidence is attached to measures. Measures are mapped to the relevant controls. You can reuse implemented work across requirements and see which evidence or decisions remain outstanding.

This turns an assessment into a shared working status: owners implement measures, reviewers assess results and management sees where decisions are needed. Effectiveness assessment remains a professional responsibility.

With Kopexa’s ISMS software, you bring together measures, owners and evidence. Existing measures can be mapped to relevant controls across frameworks, so you can focus on implementation gaps instead of maintaining parallel lists.

Implementing NIS2: a roadmap and checklist for your action plan