NIS2 cybersecurity regulation obligations explained

The NIS2 regulation marks a turning point in enterprise cybersecurity in Europe.

The NIS2 cybersecurity regulation approach reduces space for improvisation. The goal is to move from "we follow best practices" to "we can demonstrate compliance." That changes how you design the process.

Why NIS2 is different from voluntary approaches

Under NIS2, the logic is straightforward: requirements are strengthened and supervision mechanisms are reinforced. What used to be "recommended" becomes mandatory expectations. For your organization, this means you do not stop at a checklist, you must be able to explain and show evidence.

What NIS2 requires to protect networks and systems

NIS2 compliance expects technical and organizational measures. The central idea is to protect networks and systems using controls that are appropriate and proportional. In practice, this usually includes access control and privilege management, encryption where applicable, periodic vulnerability assessment, and training that is not left to chance. NIS2 also includes governance: leadership and responsibility matter, not only engineering.

Incident notification: what you need to make it executable

Notification is a critical part of compliance. The directive expects processes that can run under pressure, meaning you need an internal protocol that includes detection and classification, severity assessment, the decision to notify, drafting and escalation, and an agreed communication channel. The protocol must be tested, not only written.

A ready-to-notify kit reduces decision time and should include a contact list and escalation roles, approved templates for initial messages and summaries, baseline information (systems, services, data categories, scope), criteria for deciding severity and whether to notify, and a way to capture timestamps and decisions during the event. When the kit exists, notification is an execution workflow, not a creative writing exercise during an incident.

Continuous risk management and an evolving risk register

Under NIS2, risk management is continuous, which means reviewing your risk register when context changes. Typical triggers include new systems or APIs, new providers, incidents or near-misses, and changes in the service. If the register does not evolve, evidence loses coherence.

In evidence, continuous risk management means you can show evolution: dated updates to your risk register, reviews triggered by changes in systems, architecture or scope, updates after incidents or near-misses, and changes in control effectiveness. If your register stays the same while your service evolves, inspectors notice the mismatch quickly.

Leadership and responsibilities: traceable coordination

Article 20 of NIS2 requires governing bodies to approve cybersecurity measures, take direct responsibility for their implementation, and receive specific training in cybersecurity. Delegating to a technical role is not sufficient: leadership accountability is a legal requirement, not a recommendation. In practice this means board-level approval of policies, documented training for the management team, and traceable decision records from risk and security forums.

ICT providers and the supply chain: risk moves

The supply chain is not decorative. In NIS2, ICT providers and outsourced services are part of the risk picture. Your framework should include ICT supplier assessment, security clauses in contracts, and follow-up on compliance and cooperation. This is especially relevant for digital services where SaaS is part of your architecture.

To prove you supervise suppliers, keep evidence of active follow-up: how you classify supplier criticality, how you reassess risk after changes, which security clauses you enforce, and how you respond when deviations appear. If a supplier updates an API, changes a configuration, or introduces a vulnerability in dependencies, your evidence should reflect that you updated risk and controls and followed up.

Evidence that typically matters during inspections

Authorities expect both narrative and technical evidence. In practice you should prepare a package that helps you answer: how you detect and escalate incidents, how training is delivered by role, how you manage risks and update your register, and how you supervise third parties. It usually includes exercise records, attendance evidence, and current documentation.

Effectiveness evidence is often what's missing. Effectiveness means the control reduces risk when the real world changes. During an inspection, that shows when you can demonstrate decisions and reviews with dates, treatment of incidents or near-misses with lessons learned, updates to the risk register, and consistency between training and observed outcomes.

Role-based evidence: show you prepared for each stakeholder

Inspectors look for consistency across roles, not only across documents. Prepare evidence by stakeholder group: leadership (governance decisions, risk meetings, follow-up after incidents); security and operations (executed procedures, logs, review outcomes); incident coordinators (notification flow readiness and tabletop results); and employees (role-based training records and minimal understanding checks).

Versioning: how you avoid stale or contradictory evidence

Stale evidence can be worse than missing evidence. Define who publishes documents, who approves them, and how you mark the current valid version. When risk or process changes, update the document and record the reason for the change, then keep older versions archived for traceability. This prevents an inspector from comparing outdated paper with your current reality.

Common mistakes that can block progress

Treating NIS2 as a one-time project. If you do not keep it continuous, evidence becomes outdated, and inspections quickly detect the mismatch.

Not rehearsing the incident notification flow. A non-tested protocol performs poorly. The difference shows up when decisions must happen in hours.

Training only IT and forgetting operational teams. Training must be adapted to role. If the relevant teams do not understand their part, human risk stays outside control.

Not linking risks to actions and provider follow-up. A risk register without treatment does not guide decisions, and a provider without monitoring breaks system coherence.

How CB Partners can help with NIS2

We help you turn NIS2 into a demonstrable process. We support defining scope and responsibilities, organizing documentation and evidence, and preparing exercises and continuous reviews.

Frequently Asked Questions