Cybersecurity & Compliance —  Practical Insights

NIS 2 in Practice: The Four Core Requirements

Part 1 covered the fundamentals: what NIS 2 is, who it affects, and what consequences executive management can face personally. Anyone reading this article has presumably clarified their scope, registered with the BSI, and thereby fulfilled the formal obligations.

Now the real work begins. NIS 2 does not just require that you appear on the list. It requires concrete measures in four areas: a living risk management process, a functioning incident reporting process, tested contingency plans, and a robust approach to the supply chain. Organizations that deliver here are not only compliant – they are genuinely more secure. This is the point where compliance and operational security converge, provided it is done right.

1. Risk Management

In practice, we frequently see the same picture: risk assessments exist, but they are years old, undocumented, or were never translated into concrete actions. Anyone who has a 2022 risk assessment sitting in a drawer does not have risk management – they have a document. NIS 2 requires the exact opposite: a living process that is regularly updated, traceable, and assigned to clear responsibilities.

Living means: whenever the IT landscape changes, a new system is introduced, or a cloud service is added, the risk assessment must move with it. Traceable means: it must be visible in writing which risks have been identified, how they are evaluated, and which measures follow from them. And clear responsibility means: a named individual carries the accountability – not the IT department as a whole.

What must be in place in concrete terms:

• Continuous assessment of cyber risks – not as a one-off project, but as an ongoing task with a defined cadence.
• Technical minimum standards: encryption, granular access controls, multi-factor authentication. What was optional five years ago is mandatory today.
• Vulnerability management with defined patch cycles, escalation paths, and clear responsibilities – not patching whenever someone has time.
• Documentation that holds up under a BSI audit – not for the drawer, but for the auditor.

The typical mistake at this stage is to park risk management with IT and let it die there. NIS 2 explicitly requires interlocking with executive management – and therefore a reporting structure that makes risks visible at the top.

2. Incident Response and Reporting Obligations

The law prescribes a three-stage reporting process: 24 hours for the early warning, 72 hours for the initial report, one month for the final report. Anyone who reads these deadlines and does not yet have a functioning reporting process understands the problem immediately: 24 hours is not enough time to build one. Under the pressure of an active attack, only procedures that have been practiced beforehand will actually work.

The real risk is not the deadline itself, but the combination of time pressure, unclear facts, and legal sensitivity. Reporting incorrect information in the first hours risks follow-on problems. Reporting too late risks fines. The only safeguard against this is a pre-defined and practiced process.

What must be in place before the first incident:

• Clear escalation chains: who informs whom, in what order, with what information? Including substitution rules for vacation and illness.
• Reporting channels to the BSI – including technical access, stored contacts, and templates for all three reporting stages.
• Predefined communication templates for internal and external crisis communication – employees, customers, press, and, where applicable, regulatory authorities.
• Regular tabletop exercises, so that the plan is not read for the first time during a real incident. Once a year is the minimum.

A frequently overlooked point: the final report after one month is just as mandatory as theearly warning. Many organizations report the initial incident but let the closure slip because the pressure eases. This is traceable and subject to sanctions.

3. Business Continuity and IT Operations

Resilience is not a new concept. But many continuity plans are three years out of date, were never tested under realistic conditions, or simply no longer reflect today's IT landscape. Organizations that have moved to cloud services, software-as-a-service, and hybrid architectures cannot rely on a contingency plan that still assumes an on-premises data center.

NIS 2 turns this into an auditable obligation. It is not enough to claim that a contingency plan exists – you must demonstrate that it is current, has been tested, and works in a real emergency. A PDF in the archive that no one remembers does not meet this requirement.

What must hold up under audit:

• Current, tested business continuity plans – as lived processes with named owners, not as dormant documents.
• Disaster recovery procedures with defined recovery time objectives (RTO) and acceptable data loss (RPO) depending on system criticality.
• Redundancies for critical systems and communication channels – even when the primary channel fails, the situation must remainmanageable.
• Annual exercises that surface weaknesses before an attacker does – ideally with external observation.

The most common gap at this stage: IT has plans, the business has plans, but neither side knows the other's. In an emergency, it then turns out that the IT recovery time does not match the expectations of the business units – and no one had reconciled the two beforehand.

4. Supply Chain Security

This is the most frequently underestimated point. Your own infrastructure is secured – but what about the cloud provider, the software developer, the IT service provider, the external help desk? NIS 2 makes it unambiguously clear: responsibility does not end at your own corporate boundary. Anyone who engages third parties shares the liability for their security posture.

The consequence is inconvenient because it generates active effort. Contracts that have been running for years without security clauses must be renegotiated. Suppliers that have never been assessed for security must provide information. And this applies not only to the major hyperscalers, but equally to the small provider running the HR system.

What matters:

• Security requirements must be embedded in supplier contracts – concrete, verifiable, and with consequences for breach, not as a statement of intent.
• Regular review and assessment of third parties: audits, certifications, structured questionnaires. Prioritized based on risk, not applied uniformly across the board.
• Transparency over deployed software components – the SBOM (Software Bill of Materials). If you do not know what is inside your software, you cannot evaluate its vulnerabilities.
• Contractual reporting obligation for security incidentsat the service provider – with deadlines that align with your own 24-hour reporting requirement.

The strategic insight behind this: the supply chain is today the preferred attack vector. Anyone who has followed the major incidents of recent years knows that the affected companies were rarely attacked directly – they were connected to a compromised service provider.

The best time to act is now. Tomorrow may already be too late. Organizations that act in a structured way now will repel attacks before they cause damage –and at the same time achieve the required compliance. Both belong together. Once the attack has happened, there is no room to maneuver. Then you reactunder pressure – and that is rarely the basis for good decisions.

As of May 2026  — This article provides practical insights and does not replace individuallegal or security advice.

‍