The NIS2 directive: who is in scope and what has to be built

What the NIS2 directive is and how it becomes national law

NIS2 is the second European directive on network and information security. It replaces the first NIS directive, widens the range of sectors covered considerably and shifts the emphasis: away from reporting individual incidents and towards risk management that works in day-to-day operations and can be evidenced.

A directive has no direct effect. It obliges the member states to create their own law, which is why the duties that actually bind you sit in a national act and not in the directive text. In Germany that act is the NIS2 implementation and cybersecurity strengthening act, known as NIS2UmsuCG, which recast the BSI Act. When people talk about NIS2 duties in Germany, they mean sections of the BSIG: section 28 for who is covered, section 30 for the measures.

The German act came into force on 6 December 2025, with no transition period. The number of organisations supervised by the Federal Office for Information Security grows from about 4,500 to around 29,500, and for most of them it is the first time that IT security is a direct legal duty rather than an internal policy. Other member states have their own act, their own authority and their own timetable. The substance of the duties is the same everywhere, because it comes from the same directive.

Three things that surprise people in practice

• Self-identification. Nobody writes to tell you that you are in scope. The classification is your job, and it binds you even when it is never carried out.
• No phased introduction. The duties apply in full from day one, not step by step.
• The supply chain counts. Organisations that are not in scope themselves still get the requirements on their desk through customers and tenders.

Who is in scope: sector, entity type, size

The directive distinguishes essential and important entities. In Germany that sits in section 28 BSIG, and the classification runs through three tests that belong in this order.

1. Special cases, where size does not matter

Operators of critical installations, qualified trust service providers, top level domain name registries and DNS service providers are essential entities regardless of size. Providers of publicly available electronic communications services and operators of public communications networks are important entities at minimum, and essential from medium size upwards. Federal administration bodies fall under a separate section.

2. Sector and entity type

Annex 1 of the German act lists seven sectors: energy, transport, finance, health, water, digital infrastructure and IT services, and space. Annex 2 lists seven more: postal and courier services, waste management, chemicals, food, manufacturing, digital providers and research. What decides is not the industry in the everyday sense but whether one of the entity types defined there applies to you. In digital infrastructure those include cloud computing service providers, data centre service providers, managed service providers and managed security service providers.

3. Size

Two rules move the result regularly. An activity may be left out if it is negligible measured against the organisation as a whole. And the employees, turnover and balance sheet total of partner and linked enterprises count towards your own figures, unless the organisation runs its IT systems, components and processes independently of the group. Both judgements belong in writing.

Deadlines and registration: what the German timetable shows

Germany is a useful example because its dates have already passed. The act applies since 6 December 2025. The registration deadline expired on 6 March 2026 and the grace period granted by the BSI ended on 31 July 2026. Any organisation that is still unregistered files without undue delay and is in a sanctionable position until it does.

Registration is not an application that somebody decides on. It is a filing: the organisation states that it classifies itself as an important or essential entity and gives contact details and its sector. The classification is the real first step, not the form.

What makes sense after a missed deadline

1. Derive your own classification properly and write it down, with sector, entity type, size class and the group question.
2. Register without waiting for a finished set of measures. Registration is not a statement that everything is implemented.
3. In parallel, survey the technical position and document the gaps with a date, an owner and a planned implementation. An evidenced plan is a different thing from nothing at all in front of a regulator.

Free whitepaper · 8 pages

Digital Sovereignty

By Andreas Hankel, CTO onehundred. Download in exchange for your e-mail address, no sales call.

Get the whitepaper

The duties: risk management, reporting, registration, accountability

Both classes carry largely the same duties. They fall into four blocks.

Risk management

The directive requires appropriate and proportionate technical and organisational measures to manage the risks to the systems you use and to keep the impact of incidents small. It lists the areas those measures have to cover, among them business continuity with backup management, disaster recovery and crisis management, Art. 21 (2) (c) of the directive and section 30 (2) no. 3 BSIG in Germany. Proportionate means that the risk determines the depth of the measure, and that you have to be able to justify that judgement.

Reporting

Significant incidents are reported to the national authority in stages, from a short early warning through to a final report. In practice that means a defined process beforehand, a named role and a decision aid for what counts as significant. Working those questions out during an incident costs exactly the time the procedure does not allow for.

Registration and evidence

On top of that come registration and the duty to give an account of the state of implementation. In Germany, essential entities are under ongoing BSI supervision, and operators of critical installations evidence implementation every three years.

Management accountability and fines

Management is accountable for implementation and cannot fully delegate that to the IT department. The German fines separate the two classes: up to EUR 10 million or 2 per cent of worldwide annual turnover for essential entities, up to EUR 7 million or 1.4 per cent for important entities, whichever is higher. Other member states set their ceilings in their own act, following the same framework.

RPO vs RTO: the two values that decide the architecture

Of all the duties, business continuity lands most directly on the platform. It does not mean that backups run. It means that a defined state is reachable again within a defined time, and that this has been tested.

Two values per application come first. The RPO, the recovery point objective, describes how much data loss is acceptable, in other words how far back the recovery point may sit. The RTO, the recovery time objective, describes how long recovery may take. RPO looks backwards from the incident, RTO looks forwards.

The difference matters because the two values are bought with different things. A short RPO costs replication frequency and storage: snapshots every few minutes rather than a nightly job. A short RTO costs standby capacity and automation, plus people who have run the procedure before.

Neither the directive nor the German act names figures for RTO or RPO. You derive the values from how critical the process is, write down the reasoning and then evidence that the technology meets them. In practice the evidence is missing more often than the technology. A pair of values agreed with the business, a recovery run with a measured duration and a record of the result are worth more in an audit than any product name.

What a disaster recovery plan has to cover

A disaster recovery plan is a procedure, not a product. It counts once it has run end to end at least once, with a measured duration against the agreed RTO. Four properties decide whether it holds.

• Physical separation. Copies in a second data centre with their own access paths. A backup server next to production shares its outage and its attacker.
• Immutability. An immutable backup cannot be changed or deleted for a defined period, not even with administrative rights. Alongside it a copy without a permanent network connection, often called air-gapped.
• A rehearsed restore. Recovery of a complete system, not of single files, recorded with the date, the duration and what went wrong.
• Reproducibility. Configuration as code, documentation in the repository. An environment nobody can reproduce cannot be restored either.

Does the 3-2-1 backup rule still apply?

The 3-2-1 backup rule appears in no legislation. It is practice: three copies of the data, on two different media, one of them off site. As a lower bound it still works, and it is worth keeping because it is easy to check. What it does not cover is the attack pattern of the last few years, where an attacker holds administrative rights for weeks before the encryption starts. The rule therefore needs two additions today: one copy that is immutable for a defined period, and a restore that has been tested rather than assumed.

How this is built and operated is set out on our page on disaster recovery services.

A business continuity and disaster recovery plan covers more than the systems

Disaster recovery answers the technical question: how does the system come back? Business continuity answers the operational one: how does the business keep running while it is gone? A business continuity and disaster recovery plan holds both halves, and they are written in that order.

The business half starts with a business impact analysis: which process needs which application, what an hour without it costs, and at what point the damage stops being linear. That analysis produces the criticality ranking, and the ranking produces the RPO and RTO values. Deriving the target values instead from what the current platform happens to manage is the most common reason why a recovery plan reads well and fails in use.

The rest of the business half decides the first hour: who declares the incident, who may authorise a failover, which fallback process runs on paper or by phone, how customers and authorities are informed, and who takes over when the people who know the systems are unreachable. None of that is infrastructure work, and none of it can be bought in.

The directive requires both halves. Where organisations fall down is rarely the technology on its own. It is a plan that names servers and not decisions.

DORA compliance: the special rule for financial entities

The financial sector has a rulebook of its own: the DORA Regulation (EU) 2022/2554 on digital operational resilience. It covers the same ground, ICT risk management, incident reporting, testing and the management of third party risk, for banks, insurers, investment firms and other financial entities.

The relationship between the two is settled. Under section 28 (6) BSIG the central duties of the German act do not apply to financial entities that fall under DORA. The classification as an important or essential entity remains, but supervision of the IT security requirements runs through DORA and the competent financial authority. Comparable precedence rules exist in the other member states, because the directive itself gives way to sector specific Union law.

Three practical differences

• Regulation, not directive. DORA applies directly in every member state, with no national act in between.
• Third parties in focus. DORA regulates contracts with ICT providers in considerably more detail, exit strategies included.
• Testing duties. DORA requires a digital resilience testing programme, for some entities up to threat led penetration testing.

For IT providers with customers in finance the requirements arrive through the contract, even when the provider itself is outside DORA. Technically NIS2 and DORA point the same way: documented procedures, tested recovery and traceable responsibilities serve both rulebooks from the same substance.

Outside the EU: the UK is preparing its own act

NIS2 is Union law, so it does not reach organisations established outside the EU by itself. The United Kingdom left the EU before the directive was adopted and is preparing its own legislation, announced as the Cyber Security and Resilience Bill. We say nothing here about its content or timing: while the text is not final, any summary would be speculation. What matters for planning is that a rehearsed recovery is an asset under any regime.

Two routes bring NIS2 to organisations outside the EU regardless.

• Entities in the Union. A subsidiary, a branch or a data centre inside the EU is assessed against the national act of the member state it sits in, independently of where the parent is based.
• The supply chain. Customers in scope pass their requirements on through contracts and tenders. Providers get the questionnaire whether or not they are covered themselves.

For groups operating in several countries that produces a practical rule: build once to the strictest requirement you face, evidence it once, and map that evidence onto each national act.

Five mistakes we meet in first conversations

The patterns repeat, across industries and company sizes.

1. Scope is estimated rather than derived

“We are too small” is often true and rarely checked. The thresholds run on employees, turnover and balance sheet total, and in group structures partner and linked enterprises count towards your figures unless the IT is genuinely run independently. Without the group question the assessment does not hold.

2. Registration done, technology untouched

Registration is the visible formal duty and therefore the one that gets ticked off first. It says nothing about the state of the measures.

3. The backup counts as done because it reports green

A job that completes without errors is not a tested recovery. In most cases the last full restore is further back than the people involved assume, or it never happened.

4. Compliance is run as a project instead of as a property of operations

Evidence assembled for an appointment starts ageing the day after. What holds up are artefacts that operations produce anyway: test records, change histories, documented procedures.

5. The supply chain stays out of view

A substantial part of your own availability hangs off providers. Anyone who does not know their recovery times and has not written them into the contract cannot commit to their own target values.

A sequence that holds up in a reasonable time

Implementation can be put in an order that works even when the deadlines have passed. What matters is that every step leaves an artefact behind that later carries the evidence.

1. Derive the classification and record it. Sector, entity type, size class, group question, each with its reasoning. The result is a document, not an opinion.
2. Register, if that is still open. Without waiting for the state of implementation.
3. Determine the criticality of the processes. Which business process needs which application, and how long can it go without? The RPO and RTO values follow from that.
4. Test the technical position against those values. Backup coverage, physical separation, immutability, recovery procedures, documentation. The result is a list of gaps sorted by risk, with the effort noted per item.
5. Close the gaps in order of risk. The most expensive gap is rarely the most dangerous one.
6. Rehearse once, completely. A full recovery with a measured duration, recorded. Whatever does not hold is corrected.
7. Hand it into operations. Restore tests at agreed intervals, monitoring, records. From here the evidence accumulates by itself.

Two notes on expectations. Steps 3 and 4 take weeks rather than months when the business side and IT sit at the table together. And organisations changing the platform anyway should lay the recovery path properly in the same move. Retrofitting it into a running estate visibly costs more.

Where the line of our own service runs, we say up front: the legal scope assessment, building an ISMS and the governance and reporting processes are not part of it. For those we work with specialised partners.