What Is the NIS2 Directive? Scope, Requirements and Deadlines Explained

The NIS2 Directive is the European Union's updated cybersecurity law. Its formal name is Directive (EU) 2022/2555, and it replaces the original 2016 NIS Directive with a broader, stricter and far more enforceable framework.

In one sentence: NIS2 requires organisations in critical sectors to manage cybersecurity risk properly, secure their suppliers, report significant incidents on a fixed clock, and have senior management sign off on all of it.

If that sounds like something your organisation should already be doing, that is the point. NIS2 is the EU writing down, in legal language, what competent security governance has looked like for years. The difference is that it is now a legal duty with named owners and financial consequences.

This article covers what the NIS2 Directive is, who it applies to, what it requires, the reporting deadlines, the penalties, and where AI fits into the picture.

What is the NIS2 Directive?

NIS2 stands for the second Network and Information Security Directive. It entered into force in January 2023, and Member States were required to transpose it into national law by 17 October 2024.

The directive does four main things:

• Widens the scope. It covers 18 sectors, split into 11 "highly critical" sectors in Annex I and 7 "other critical" sectors in Annex II.
• Sets minimum security measures. Article 21 lists ten risk-management measures every in-scope organisation must implement.
• Imposes reporting duties. Article 23 sets a 24 hour, 72 hour and one month reporting cascade for significant incidents.
• Makes management accountable. Article 20 requires management bodies to approve and oversee security measures, and to be trained.

One point causes more confusion than any other, so it is worth stating early.

NIS2 is a directive, not a regulation

A regulation, like GDPR, applies directly. A directive does not. NIS2 binds Member States, and each Member State then writes the national law that binds your organisation.

That national law is what actually determines your obligations: which authority supervises you, whether you must register and by when, which national CSIRT you report to, and what the penalty ceilings are. Member States are free to go beyond the directive's minimums, and several have.

So when someone asks "what does NIS2 require of us," the honest answer is: start with the directive, then check the transposition law in every country where you operate.

Is the NIS2 Directive in force yet?

Mostly, but not everywhere. The transposition deadline passed on 17 October 2024 and a large number of Member States missed it.

As of August 2026, 23 of the 27 Member States had a national NIS2 law adopted and in force. Ireland, Spain and France had still not adopted one. Austria had adopted a law that had not yet entered into force. The European Commission has referred the four outstanding Member States to the Court of Justice of the European Union, requesting a lump sum and daily financial penalties until full transposition is notified.

Two practical consequences follow:

• If you operate across borders, you are not managing one obligation. You are managing a set of national regimes anchored on a common directive. Being out of scope in one country tells you nothing about the next.
• If your national law is still pending, waiting is not a strategy. Parliament is not going to rewrite the ten measures in Article 21. Build against those now.

Why was NIS2 introduced?

The original NIS Directive covered a narrow set of sectors, left too much discretion to Member States, and produced wildly inconsistent security levels across the EU. It also had weak enforcement, which meant compliance was largely optional in practice.

NIS2 was designed to fix three things:

1. Coverage. More sectors, more organisations, clearer scoping rules.
2. Consistency. A common minimum baseline so that a hospital in one Member State is not dramatically less protected than one in another.
3. Accountability. Real supervision, real penalties, and duties that attach to named people rather than to an abstract "the organisation."

Underneath all of it sits a simple observation: modern critical services depend on interconnected digital supply chains, and the weakest link is usually somebody else's system.

Who does the NIS2 Directive apply to?

Three questions determine whether you are in scope: your sector, your size, and your national law.

The 18 sectors

Annex I, highly critical sectors: energy, transport, banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure, ICT service management (business to business), public administration, and space.

Annex II, other critical sectors: postal and courier services, waste management, manufacture and distribution of chemicals, production and distribution of food, manufacturing (including medical devices, computers and electronics, machinery, motor vehicles), digital providers (online marketplaces, search engines, social networking platforms), and research organisations.

The size threshold

Being in one of those sectors is not sufficient on its own. NIS2 generally applies to medium and large enterprises: 50 or more employees, or annual turnover and balance sheet total above EUR 10 million.

There are important exceptions that catch smaller organisations regardless of size, including qualified trust service providers, top-level domain name registries, DNS service providers, and providers of public electronic communications networks or services. Member States may also extend scope to any entity that is the sole provider of a critical service, or where disruption would significantly affect public safety, security or health. Some have used that discretion generously.

Essential and important entities

In-scope organisations are classified as either essential or important. Both must implement the same ten security measures. The difference is supervision and penalties.

Essential entities face proactive supervision: regulators can inspect and audit without needing a reason to suspect a problem. Important entities face reactive, ex post supervision: authorities act when there is evidence of non-compliance.

Does NIS2 apply to companies outside the EU?

This matters for suppliers based in Switzerland, the UK, and elsewhere outside the Union.

NIS2 does not directly regulate a non-EU company simply because it has EU customers, with one significant exception. Certain digital entities, including cloud computing providers, data centre providers, content delivery networks, managed service providers, managed security service providers, online marketplaces, search engines and social networking platforms, must designate a representative in the Union if they offer services within the EU while not being established there.

For everyone else, NIS2 arrives through the supply chain rather than through the regulator. Article 21(2)(d) makes your EU customers legally responsible for the security of their direct suppliers and service providers. That responsibility becomes your contract clauses, your security questionnaires and your incident cooperation obligations. Non-EU suppliers to European critical infrastructure are already feeling this, and it is only tightening.

What does the NIS2 Directive require? The 10 measures in Article 21

Article 21(2) sets out ten minimum cybersecurity risk-management measures. They are identical for essential and important entities.

Article 21(1) adds the proportionality principle: how deeply you implement each measure should reflect your size, your risk exposure and the societal impact of a failure. Proportionality applies to depth of implementation, not to which measures you can skip. All ten apply to everyone in scope.

The directive is also explicit that this is an all-hazards approach. It is not only about attackers. Supplier failure, human error, power loss, physical damage and cloud outages all count.

1. Policies on risk analysis and information system security. A documented, approved risk management framework rather than an informal understanding of what matters.

2. Incident handling. Prevention, detection, analysis, containment, response and recovery, with defined roles and escalation.

3. Business continuity, backup management, disaster recovery and crisis management. Tested backups and a plan for operating when key systems or suppliers are unavailable.

4. Supply chain security. Security of relationships with direct suppliers and service providers, including their security practices and their development processes.

5. Security in acquisition, development and maintenance, including vulnerability handling and disclosure. Secure development practices, patching, and a route for people to report vulnerabilities to you.

6. Policies and procedures to assess the effectiveness of risk-management measures. Audits, testing and review that prove the controls work.

This is the measure most organisations underestimate. The other nine ask whether you have a control. This one asks whether you can demonstrate it works, repeatedly, over time. It is where a paper-only compliance programme falls apart under inspection.

7. Basic cyber hygiene practices and cybersecurity training. Patching, access hygiene, MFA, backups, and continuous role-based awareness training.

8. Cryptography and, where appropriate, encryption. A policy on where encryption is applied and how keys are managed.

9. Human resources security, access control policies and asset management. Screening, joiner and leaver processes, least privilege, and knowing what assets you actually have.

10. Multi-factor authentication or continuous authentication, and secured communications. MFA on privileged and sensitive access, plus secured voice, video and text channels and a secured emergency communication path for when the main estate cannot be trusted.

A note on frameworks: if you hold ISO 27001, you already cover a substantial share of Article 21. The gaps that typically remain are supply chain security, management body accountability, incident reporting timelines and explicit MFA requirements. Zero trust architecture and network segmentation are sensible ways to satisfy several measures, but they are implementation choices, not NIS2 requirements. Do not present them internally as legal obligations.

What are the NIS2 incident reporting deadlines?

Article 23 sets the reporting cascade, and it applies to a significant incident.

The directive defines a significant incident as one that has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned, or that has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

The clock runs from the moment you become aware of the incident:

• Within 24 hours: early warning. Notify the CSIRT or competent authority, indicating whether the incident is suspected to be caused by unlawful or malicious acts, or could have cross-border impact.
• Within 72 hours: incident notification. Update the early warning with an initial assessment of severity and impact, and indicators of compromise where available.
• On request: intermediate report. Status updates if the authority asks for them.
• Within one month of the notification: final report. A detailed description, the type of threat or root cause, mitigation applied, and cross-border impact where relevant.

If the incident is still ongoing when the final report falls due, you submit a progress report instead, and the final report within one month of finishing incident handling.

The important implication is structural rather than technical. The 24 hour early warning is deliberately designed to happen before forensic certainty. Waiting until the picture is clear is not an option the law offers.

That means an organisation needs to answer three questions in advance:

• Who is authorised to judge that an incident is significant, and are they reachable at 03:00?
• Who signs the report, and who speaks to the authority?
• Have you tested that you can actually log in to your national reporting portal?

Incident response plans that include only IT, legal and communications are incomplete under NIS2. The regulator is now a participant.

What does NIS2 require of management and boards?

Article 20 is short and consequential. Management bodies of in-scope entities must:

• Approve the cybersecurity risk-management measures.
• Oversee their implementation.
• Follow cybersecurity training, and ensure comparable training is offered to employees.

This changes the internal conversation. Cybersecurity risk acceptance is now formally a management decision, recorded as such. A board that declines to fund a control is not simply making a budget choice, it is documenting an accepted regulatory risk.

What are the penalties under NIS2?

The directive sets minimum ceilings that Member States must provide for. National law may set them higher.

• Essential entities: up to EUR 10 million or 2% of total worldwide annual turnover for the preceding financial year, whichever is higher.
• Important entities: up to EUR 7 million or 1.4% of total worldwide annual turnover, whichever is higher.

For essential entities, supervisory authorities also have two further powers: temporarily suspending an authorisation or certification, and temporarily prohibiting an individual at chief executive or legal representative level from exercising managerial functions in that organisation.

These are last-resort measures that apply after other enforcement has failed, and their precise operation depends on national transposition. It is not accurate to say that every board member is automatically personally liable. It is accurate to say that management duties are now explicit, documented, and backed by instruments that can reach individuals in a serious enough failure.

Supply chain security under NIS2

Article 21(2)(d) is one of the most consequential changes from NIS1, and the one organisations are least prepared for.

You are responsible for the security of relationships with your direct suppliers and service providers, taking into account their specific vulnerabilities, the overall quality of their products and security practices, and their secure development procedures.

In practice:

• Vendor size and reputation are not a security assessment.
• Outsourcing the work does not outsource the accountability.
• Cloud, SaaS, managed service providers and OT vendors are all inside your NIS2 footprint.

What supervisors expect to see is a supplier inventory classified by criticality, evidence of assessment before onboarding, security and incident-cooperation clauses in contracts, and ongoing monitoring rather than a one-off questionnaire from three years ago.

Where does AI fit into NIS2?

The NIS2 Directive does not mention artificial intelligence, and it is not an AI regulation. The EU AI Act covers that ground separately.

But NIS2 is technology-neutral, which means it lands on AI systems exactly as it lands on anything else in your network and information systems. The trigger is dependency, not novelty.

An AI system becomes relevant to your NIS2 obligations when it:

• Supports a service covered by the directive.
• Processes customer, patient, employee or operational data.
• Arrives through a cloud, software or managed service provider, making it a supply chain question.
• Influences security monitoring, operational decisions or business continuity.
• Creates a dependency that could affect the confidentiality, integrity or availability of a service.

An experiment in a sandbox is not a compliance breach. A model sitting underneath a critical process, fed with production data, procured by a business unit without security review, is a NIS2 gap in at least four of the ten Article 21 measures.

The questions worth asking:

• Which AI systems are used in services that would be in scope?
• What data leaves the organisation to reach external AI providers?
• Which suppliers operate or maintain those systems, and what happens if one becomes unavailable?
• Are access control, logging, testing, human oversight and incident response documented for them?
• Do joiner and leaver processes revoke AI tool access as reliably as they revoke email? Are API keys and AI service accounts managed as the privileged identities they are?

That last point is where most organisations have a genuine blind spot. Article 21(2)(i) covers access control and asset management, and for most organisations the AI estate is neither controlled nor inventoried.

The objective is not to slow adoption down. It is to bring AI inside the same risk management, supplier assurance and incident response processes that already exist, before a regulator asks about it.

How to prepare for NIS2: a practical 90-day plan

You do not need a 300-page strategy. You need focused prioritisation.

Days 1 to 30: establish visibility

Confirm scope against your national law. Determine whether you are an essential or important entity, whether you have a registration duty, and what deadline attaches to it. Use the transposition law in each country where you operate, not the directive text.

Map critical services and dependencies. Critical systems, data flows, key cloud, AI and managed service providers, and the interfaces where a failure would trigger a reporting obligation. Aim for accurate enough to guide decisions, not perfect.

Find shadow IT and shadow AI. Surveys, interviews and log analysis. Anything capable of triggering a NIS2 obligation should not be shadow anything.

Days 31 to 60: build governance and rehearse

Set up a governance structure. Named accountable executives, defined roles across security, IT, operations, data protection and legal, and a steering group with actual decision rights. Attach it to existing risk committees rather than creating another forum.

Run a tabletop exercise. Simulate an incident hitting a critical service, include executive leadership, legal, communications and operations, and walk the 24 hour, 72 hour and one month timeline in real time. Make it realistic rather than comfortable.

Write the incident classification and reporting policy. Define "significant incident" for your context using the Article 23 wording as the anchor. Codify who decides, who signs and who contacts the authority. Verify your access to the national reporting portal before you need it.

Days 61 to 90: close the structural gaps

Review your most critical suppliers. Start with cloud and infrastructure providers, the SaaS and AI platforms underpinning essential services, and OT vendors in high-impact environments. Assess security posture, incident cooperation clauses, and data location and access. If contracts are weak, begin renegotiation now, because it takes longer than expected.

Publish an acceptable use policy for AI. What data may and may not go to external services, which tools are approved and how they get onboarded, and the requirements for logging, monitoring and human oversight. Make it something people can follow, because an ignored policy is evidence against you rather than for you.

Deliver management training. Article 20 duties, your actual risk exposure, and what the board is being asked to accept. End with a documented decision.

Build a risk register. Top NIS2-relevant risks with likelihood, impact, current controls, owners and timelines. Update it monthly and use it for funding conversations, not just audits.

NIS2 compliance checklist

• Confirmed in-scope status and entity classification against national law
• Registered with the competent authority where required
• Documented, management-approved risk management framework
• All ten Article 21 measures implemented and evidenced
• Supplier inventory classified by criticality, with security clauses in contracts
• Incident classification policy defining "significant incident" for your context
• Reporting playbook aligned to 24 hour, 72 hour and one month deadlines
• Tested access to the national CSIRT reporting channel
• Business continuity and recovery plans tested, not just written
• Management body trained, with attendance recorded
• Effectiveness of controls tested and reviewed on a defined cycle
• AI systems, vendors and data flows included in the above rather than treated separately

Frequently asked questions about the NIS2 Directive

Is NIS2 a regulation or a directive?
A directive. It obliges Member States to legislate, and their national law is what binds your organisation. Obligations, deadlines and penalties therefore vary by country.

When did NIS2 come into effect?
It entered into force in January 2023, with a transposition deadline of 17 October 2024. Most Member States now have national law in force, though a small number were still legislating as of August 2026.

Does NIS2 replace NIS1?
Yes. NIS2 repealed the original NIS Directive and significantly expanded its scope and enforcement.

How is NIS2 different from GDPR?
GDPR protects personal data. NIS2 protects the continuity and security of critical services. An incident can trigger both, with separate authorities, separate deadlines and separate reports.

Does ISO 27001 make us NIS2 compliant?
No, but it gets you a long way. A mature ISMS covers much of Article 21. The usual remaining gaps are supply chain security, management accountability, incident reporting timelines and explicit MFA requirements.

What happens if we do not comply?
Supervisory action, then fines up to EUR 10 million or 2% of worldwide turnover for essential entities, and EUR 7 million or 1.4% for important entities. Essential entities can additionally face temporary suspension of authorisations and temporary bans on senior individuals holding managerial functions.

Where can I find the directive's text?
You can find it in PDF and HTML form on this EU site.

Where to start

No organisation needs to solve NIS2 in one pass. The sensible order is to confirm whether you are in scope under your national law, identify the services and dependencies that matter most, and address the largest gaps in governance, incident response, supplier security and continuity.

Include AI where it forms part of those services and dependencies. The point is not to block new technology, but to introduce it with the same safeguards and accountability as everything else.

Pick one thing to do this week: confirm your status under national law, run an incident tabletop, start an inventory of critical suppliers, or brief your management body on what Article 20 now requires of them.

If you want a second pair of eyes on your NIS2 readiness, or help turning this into a board-ready plan, get in touch.