Navigating NIS2: What you need to know to stay compliant

If you spent 2024 writing NIS2 policies, you are now being asked a different question. Back then, the job was to get the documents in place: a continuity plan, a supplier register, an incident procedure.

In 2026, a supervisor  wants to see that what you wrote down holds up in practice.

That change runs through everything in NIS2 compliance this year. The deadline has passed, most of Europe has put the rules into national law, and the first supervision cycles are live. This guide covers who they apply to, what they require, and what you now have to prove instead of promise.

What is the NIS2 directive?

NIS2 is the European Union's second Network and Information Systems Directive, a law that sets baseline cybersecurity obligations for organizations running critical services across the bloc. It requires those organizations to manage their cyber risk, report serious incidents, and prove they can keep operating when something goes wrong.

It replaced the original 2016 directive, known as NIS1, which the sector widely agreed was too narrow and too lightly enforced. NIS2 widens the net to many more sectors and raises the penalties.

It also puts new weight on something NIS1 barely touched: the security of your suppliers. That single addition reshapes what compliance means for anyone who depends on outside software, as the rest of this guide will show.

Before any of this binds you, though, you need to know whether you are in scope. That is where most organizations start, and where a surprising number get the answer wrong.

»  Want to see how NIS2 sits alongside Europe's other continuity rules? Our guide to DORA compliance covers the financial-sector regulation many of the same organizations fall under.

Who NIS2 applies to: essential vs important entities

NIS2 sorts the organizations it covers into two groups, and the group you fall into changes how closely you are watched and how hard you can be fined. The directive calls them essential entities and important entities.

Size is the usual deciding factor. As a rule, the directive applies to medium and large organizations, meaning at least 50 employees or annual turnover above €10 million. Some entity types are covered whatever their size, such as DNS providers, because a failure there carries outsized consequences.

There is a less obvious way the rules reach you. If you supply software or services to an in-scope European company, their NIS2 obligations flow down to you through their supply-chain duties, even when your own business sits outside the EU. You can be pulled in by your customer's compliance, not your own.

Whether you are essential or important, the obligations that bind you live in your country's national law, not the directive itself. And in 2026, where that national law stands is finally a question with real answers.

The NIS2 deadline and where transposition stands in 2026

The directive set a hard date: every member state had to write NIS2 into national law by October 17, 2024. Most missed it. A year and a half on, the picture has changed completely, and that change is what should shape your plans this quarter.

By mid-2026, 22 of the 27 member states have adopted their transposing legislation, with five still working through the legislative process: France, Ireland, Luxembourg, the Netherlands, and Spain. Italy, Belgium, and Lithuania were among the early movers, and Germany finally passed its law in 2025 after long delays in parliament. 

The countries that dragged their feet did not get away with it. The European Commission opened infringement proceedings, escalating to reasoned opinions against 19 member states in May 2025 for failing to fully transpose the directive. That pressure worked, and most of the laggards have since transposed.

The obligations are live, they differ in their detail from country to country, and supervisors have started checking. If you operate across several member states, you are no longer reading one rulebook. You are reconciling several.

The 10 NIS2 risk management requirements (Article 21)

At the center of NIS2 sits Article 21, which lists 10 areas of cybersecurity risk management every covered organization has to address. The directive does not tell you which products to buy. It tells you what outcomes to reach and expects you to match the depth of each control to your real risk.

The list below names all 10 and flags the gap auditors most often find. Two of them, business continuity and supply-chain security, are where the largest number of organizations come up short. 

1. Risk analysis and security policies. Assess your cyber risks and write policies that respond to them.

2. Incident handling. Detect, manage, and recover from security incidents.

3. Business continuity. Keep backups, disaster recovery, and crisis management ready.

4. Supply-chain security. Manage the security risks your suppliers introduce.

5. Secure development and acquisition. Build, buy, and maintain systems securely, vulnerabilities included.

6. Effectiveness assessment. Check on a schedule that your measures still work.

7. Cyber hygiene and training. Basic security practices and regular training for staff.

8. Cryptography. Set policies for encryption and use it where it counts.

9. Access control and asset management. Control who can reach what, and know what you hold.

10. Multi-factor authentication and secure communications. Use MFA and secure your voice, video, and emergency channels.

One rule sits above this list and changes how seriously it gets taken. Under Article 20, the management body is directly accountable for approving and overseeing these measures, and managers must take cybersecurity training themselves. NIS2 compliance is no longer something the board can delegate and forget. 

» Take a closer look at what regulators expect you to know about your suppliers.

Reporting obligations and timelines

NIS2 does not only ask you to handle incidents well. It puts you on a clock once a significant one hits, and the clock is tight. This is incident handling, the second measure above, turned into a hard legal deadline.

1. Within 24 hours: early warning. Tell your national authority a significant incident has occurred, with a first read on whether it looks malicious or could spread across borders.

2. Within 72 hours: full notification. Provide an updated assessment: severity, impact, and any indicators of compromise you have found.

3. Within one month: final report. Submit a detailed account of the incident, its root cause, and how you contained and recovered from it.

Three days is not long to assemble a credible picture of a live incident, which is exactly why the plan has to exist and work before anything goes wrong. A reporting duty you only think about after the breach is one you will miss.

Penalties and personal liability

The fines attached to NIS2 are large, as the scope table set out, and they scale with your global turnover rather than your local revenue. For a multinational, that distinction alone can turn a penalty from painful into severe.

The figure that changes behavior, though, is not the corporate fine. It is personal exposure. NIS2 makes the management body directly accountable for cybersecurity, and where non-compliance is serious, supervisors can temporarily ban individuals from holding management roles.

That is a real change in who carries the risk. A failed audit is no longer only a line item the company absorbs. It can land on the people who signed off on the controls, which is why NIS2 has moved from the IT budget conversation into the boardroom.

How software supply-chain failure becomes a NIS2 problem

Put the continuity measure and the supply-chain measure side by side, and a specific problem comes into focus, one the ten-point list tends to hide by keeping them apart.

Most of your critical systems run on software you did not build. A core supplier holds the source code, the build process, and the knowledge to keep it running. NIS2 makes you responsible for the security of that relationship under measure 4, and for keeping operations alive if it breaks under measure 3. Both duties point at the same supplier.

Now imagine that supplier fails. Not a breach you patch, but insolvency, an acquisition that kills the product, or support that simply stops. Your continuity plan is supposed to cover this. The question a supervisor will ask is whether it works, or whether it assumes a recovery nobody has tested.

This is the finding that comes up again and again in early NIS2 audits: continuity plans and backups that look complete on paper and have never been restored under real conditions.

Where software escrow fits

This is where software escrow earns a place in the conversation. Software escrow places a copy of a critical supplier's source code, data, and documentation with a neutral third party, held under an agreement that releases it to you if the supplier fails.

For the two measures we have been circling, that is a concrete control. If your supplier goes under, you hold what you need to keep the software running or move it elsewhere. It answers the continuity and supply-chain duties with something an auditor can point to, rather than a clause that promises recovery in the abstract.

What makes it audit-ready is verification. A deposit that has been tested for completeness, confirmed to build, and documented with a recovery certificate gives you more than a promise. It gives you evidence that recovery works, which is exactly what a supervisor is looking for.

If you want to see how this maps to the directive, our NIS2 page sets it out, and our verified recovery service covers the testing itself.

How to approach NIS2 compliance

None of this requires you to fix everything at once. NIS2 rewards a steady, evidenced approach far more than a frantic one, and the path through it is fairly settled. These six steps are a sensible order of work.

1. Confirm your scope. Work out whether you are an essential or important entity under the national law of each country you operate in, since the detail varies.

2. Assign ownership at board level. Article 20 makes this a management responsibility, so name who owns it before you build anything.

3. Run a gap analysis against Article 21. Measure your current controls against the 10 areas and record, honestly, where you fall short.

4. Close the highest-risk gaps first. For most organizations, supplier continuity and tested backups sit near the top, because they fail most often in audits.

5. Build the evidence pack. Gather the logs, test results, certificates, and review notes that prove each control works, not just that it exists.

6. Maintain the cycle. Reassess on a schedule, because NIS2 expects controls that stay current, not a one-time clean-up.

Notice what runs through every step: evidence. NIS2 in 2026 is less interested in what you intend to do and more interested in what you can demonstrate on the day someone asks. Get that right and your position changes from "we have policies somewhere" to "we can show you exactly what we do, and prove it holds."

When the plan finally gets tested

NIS2 splits organizations into two groups: those who can prove their controls work, and those who find out the answer during an actual incident. The directive's whole purpose is to push you into the first group before a supplier failure does it for you.

Getting there is not complicated. Build every control so you can show it works, and the audit takes care of itself.

» See how Codekeeper helps you meet your NIS2 continuity and supply-chain obligations.