NIS2 explained: who is in scope, what it requires, and the deadlines

NIS2 is the European Union directive that sets baseline cybersecurity obligations for organizations that run important infrastructure and digital services. Its formal name is Directive (EU) 2022/2555, and it replaced the original 2016 NIS Directive. If your company operates in energy, transport, banking, financial market infrastructure, health, water, digital infrastructure, public administration, or a range of other sectors, NIS2 most likely applies to you. It expands the list of covered sectors, raises the security baseline, introduces strict incident reporting timelines, and makes senior management personally accountable for compliance. The penalties are real, the deadlines have already passed at the EU level, and national enforcement is now active.

We get asked the same three questions in almost every scoping call. Are we in scope? What do we actually have to do? When is it due? This post answers all three directly, then walks through the requirements, the process to reach compliance, the deliverables you should expect, the trade-offs, and the mistakes we see most often. NIS2 is not a checklist you complete once. It is an operating standard for risk management, incident handling, and supply chain control that you have to sustain. We do this work for regulated companies, and the practical reality is more demanding than most boards expect.

What NIS2 actually is

NIS2 is a directive, not a regulation. That distinction matters. A regulation like DORA applies directly and identically across all member states. A directive sets the objectives and obligations, then each member state writes its own national law to implement it. So the core duties are common across the EU, but the exact thresholds, the supervisory authority, the registration mechanics, and the fine schedules vary by country. You comply with your national transposition law, and that law is built on the NIS2 text.

The directive has four pillars. It defines who is in scope through sector and size criteria. It imposes risk management measures that covered entities must implement. It sets incident reporting obligations with hard deadlines. And it establishes supervision and enforcement, including management accountability and significant fines. Everything else in NIS2 is detail hanging off those four pillars.

NIS2 is security led, not paperwork led. The original NIS Directive was criticized for inconsistent national implementation and weak enforcement. NIS2 closes those gaps by widening the sector list, removing much of the discretion member states had over who counts, and attaching meaningful penalties. For most companies, treating it as a documentation exercise is the fastest way to fail an audit. The supervisory authorities can demand evidence that controls work, not just that policies exist. Our GRC practice treats NIS2 as a technical program with governance attached, which is the order that survives scrutiny.

Who is in scope

NIS2 scope is decided by two tests applied together. First, does your organization operate in a covered sector. Second, does it meet the size threshold. The directive splits covered entities into two tiers, essential entities and important entities, and the tier you fall into changes how strictly you are supervised, not whether the duties apply.

• Sectors of high criticality include energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management between businesses, public administration, and space.
• Other critical sectors include postal and courier services, waste management, manufacture of certain products, chemicals, food production and distribution, manufacturing of medical devices and electronics, digital providers such as online marketplaces and search engines, and research organizations.
• The general size rule captures medium and large entities, meaning 50 or more employees or annual turnover and balance sheet above 10 million euros, though several entity types are in scope regardless of size.
• Certain providers are covered no matter how small they are, including DNS service providers, top level domain registries, trust service providers, and providers of public electronic communications networks or services.
• An entity is essential if it operates in a high criticality sector and exceeds the larger size ceilings, and important if it is in a covered sector and meets the medium threshold but not the essential criteria.
• Supply chain reach matters, because even if you are not directly in scope, your in-scope customers must assess and manage the security risk you introduce as a supplier.

That last point catches a lot of companies. We regularly work with technology vendors who assumed NIS2 did not touch them, then received a security questionnaire from a banking or healthcare client who is in scope and is now contractually obligated to vet suppliers. If you sell into regulated industries, the directive reaches you through your customers even when it does not reach you directly. This overlaps heavily with DORA for financial entities, and the difference between the two is worth understanding, which we cover in our NIS2 versus DORA breakdown.

What NIS2 requires

Article 21 of the directive lists the risk management measures every covered entity must put in place. These are deliberately broad because they have to fit a hospital, a power utility, and a cloud provider. The text uses an all-hazards approach, meaning you protect against the full range of threats to network and information systems, not just a named subset. The ten measure categories below are the spine of any NIS2 program.

• Risk analysis and information system security policies that are documented, approved by management, and based on a real assessment of your threats and assets.
• Incident handling, covering detection, response, and the internal processes that feed the mandatory reporting timelines.
• Business continuity and crisis management, including backup management, disaster recovery, and the ability to keep critical services running during an incident.
• Supply chain security, meaning you assess and manage the security of your direct suppliers and service providers and the quality of their practices.
• Security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure.
• Policies and procedures to assess whether your risk management measures actually work, which means testing and measurement, not assumption.
• Basic cyber hygiene practices and security training for staff at all levels including management.
• Policies on the use of cryptography and, where appropriate, encryption.
• Human resources security, access control policies, and asset management so that the right people have the right access and nothing more.
• Multi-factor authentication or continuous authentication, secured voice, video, and text communications, and secured emergency communication systems where appropriate.

The measure that quietly drives the most work is testing whether controls function. You cannot satisfy the requirement to evaluate effectiveness with a policy document. You need evidence. That evidence comes from penetration testing, vulnerability management, external attack surface monitoring, and detection coverage you have actually validated. A policy that says you patch within 30 days means nothing if a test shows a six month old critical vulnerability exposed to the internet. We see that exact gap constantly, and it is the difference between a clean audit and an enforcement action.

The incident reporting deadlines

NIS2 incident reporting is staged and the clock is tight. Once you become aware of a significant incident, a multi-step reporting sequence begins. A significant incident is one that has caused or can cause severe operational disruption or financial loss, or that has affected other parties through considerable material or non-material damage. The exact reporting destination is your national CSIRT or competent authority as named in your transposition law.

• Within 24 hours of becoming aware of a significant incident, you must submit an early warning, indicating whether the incident is suspected to be caused by unlawful or malicious acts and whether it could have cross-border impact.
• Within 72 hours, you must submit an incident notification that updates the early warning and provides an initial assessment including severity, impact, and any indicators of compromise.
• On request from the authority, you must provide an intermediate report on status updates during the handling of the incident.
• Within one month of the incident notification, you must submit a final report describing the incident in detail, its root cause, the mitigation applied, and any cross-border impact.
• If the incident is ongoing at the one month mark, you submit a progress report and then a final report within one month of handling the incident being concluded.
• Where the incident affects recipients of your services, you may also have to inform those recipients without undue delay, particularly when the incident could harm them.

These timelines are the part that breaks teams without preparation. The 24 hour early warning is fast. If you do not have a pre-built classification process, named decision makers, and a tested escalation path, you will burn the first 24 hours arguing about whether the event even qualifies. We build incident response runbooks specifically against these windows, tied to detection capability from threat detection and response, so that the classification decision is mechanical rather than improvised under pressure.

The deadlines that have already passed

The headline dates are behind us, which is why enforcement is the live concern now rather than preparation in the abstract. The directive entered into force in January 2023. Member states were required to transpose it into national law by 17 October 2024, and the obligations applied from 18 October 2024. Member states also had to establish their lists of essential and important entities, with a deadline around April 2025 for that registration exercise.

In practice, several member states missed the transposition deadline and passed their national laws late, with some still finalizing implementing rules through 2025. That created a confusing situation where the EU level deadline had passed but the local law you actually comply with did not exist yet. If you operate across multiple member states, you are now subject to a patchwork of national laws that arrived on different schedules. The correct posture today is to assume you are in scope, build to the directive baseline, and adjust for the specifics of each national law where you operate. Waiting for perfect clarity is no longer a defensible position.

NIS2 is not a deadline you hit once. It is a security standard you have to keep passing, and the auditor will ask for proof, not promises.

How a NIS2 program comes together

We run NIS2 engagements in a sequence that front-loads the decisions that everything else depends on. The order matters because scope and gap analysis determine where you spend money, and skipping straight to controls wastes effort on things you may not need.

• Confirm scope and tier by mapping your legal entities, sectors, and size against your national transposition law, then register with the competent authority where required.
• Run a gap assessment against the Article 21 measures, comparing your current controls and evidence to the directive baseline and producing a prioritized remediation backlog.
• Build or update the governance layer, including the management-approved security policies, risk methodology, and the accountability structure that names who owns what.
• Close technical gaps through remediation, which usually combines patching, hardening, access control changes, segmentation, encryption, and detection improvements.
• Validate the controls with testing, including penetration testing and attack surface review, so you hold evidence that the measures work rather than just exist.
• Stand up incident handling against the 24 hour, 72 hour, and one month reporting clocks, with runbooks, escalation paths, and a tested classification process.
• Operate and measure continuously, repeating assessment and testing on a defined cycle so you can demonstrate ongoing compliance to supervisors.

Most of the durable value sits in steps five through seven. Anyone can write a policy. The companies that pass supervision are the ones who tested their controls and can show the results, who ran a tabletop exercise against the reporting timeline, and who repeat the cycle. If you are choosing a partner for the testing portion, our guide on how to choose a penetration testing company covers what separates real testing from a scan with a logo on it.

What you get from the work

A NIS2 program should leave you with concrete artifacts, not a vague sense of improvement. When the supervisory authority asks for evidence, you point to these. When your in-scope customers send a supplier questionnaire, you answer from these. The deliverables below are what we hand over, and they double as the audit trail you will rely on for years.

• A scope and applicability memo that states which entities are in scope, the tier, the governing national law, and the registration status.
• A gap assessment report mapping each Article 21 measure to your current state, with a risk-ranked remediation plan and owners.
• Management-approved security policies and a documented risk management methodology that the board can demonstrate it reviewed.
• Penetration test and vulnerability assessment reports that provide the effectiveness evidence the directive requires, covering your external surface, applications, and network.
• Incident response runbooks built against the reporting deadlines, plus a tabletop exercise report showing the process works under time pressure.
• A supplier risk register and assessment process so you can manage the supply chain security obligation and respond to your own customers credibly.
• A continuous compliance schedule that defines retesting cadence, policy review intervals, and the metrics you report to management.

How NIS2 relates to ISO 27001, DORA, and SOC 2

You almost certainly already hold or want one of the major frameworks, and the good news is that the work overlaps heavily. NIS2 does not name a specific standard you must certify against, but the Article 21 measures map cleanly onto controls you may already have. Building once and reusing the evidence across frameworks is how you keep the cost sane.

• ISO/IEC 27001:2022 gives you an information security management system, and its 93 Annex A controls across the four themes of organizational, people, physical, and technological cover most of the NIS2 risk management measures already.
• DORA, Regulation (EU) 2022/2554, has been in force since January 2025 and governs financial entities specifically, with its own incident reporting and resilience testing rules that overlap with NIS2 but apply directly.
• SOC 2 reports against the Trust Services Criteria and demonstrates control operation to customers, which supports the NIS2 supply chain obligation even though it is a US-centered attestation rather than an EU legal requirement.
• The EU AI Act adds obligations for organizations building or deploying AI systems, and where you run AI in a covered sector, your security testing has to extend to those systems too.

If you are mapping these out, our ISO 27001 work is the most efficient backbone for a NIS2 program because the management system structure carries most of the governance load. For financial entities juggling both regimes, the DORA compliance checklist shows where the two diverge. And if you are weighing certifications, SOC 2 versus ISO 27001 explains which one buys you more in a European context.

Common mistakes and red flags

We see the same failure patterns repeat across companies and sectors. Most of them come from treating NIS2 as a documentation project owned by legal, rather than a security program owned jointly by security and the board. Watch for these.

• Assuming you are out of scope without checking the supply chain test, when your in-scope customers will pull you in through supplier obligations anyway.
• Writing policies you never test, so that the effectiveness evidence the directive demands does not exist when the auditor asks for it.
• Treating the 24 hour early warning as something you can figure out on the day, with no pre-agreed classification criteria or named decision makers.
• Ignoring the management accountability provisions, which can hold senior leadership personally liable and require them to undergo security training.
• Buying an automated scan and calling it a penetration test, when the difference between the two is exactly what supervisors probe, as we explain in our piece on a pentest versus a scan.
• Scoping NIS2 once and never repeating the assessment, when the obligation is continuous and your environment changes every quarter.

Cost and effort

There is no single price for NIS2 because the cost tracks your starting maturity and your scope. A company that already holds ISO 27001 and runs regular penetration tests is mostly doing a mapping and gap-closing exercise. A company starting from scattered policies and no testing program is building the foundation first. The realistic budget lines are the gap assessment, remediation engineering time, security testing, incident response readiness, and the ongoing operating cost of continuous compliance.

The largest variable is remediation, because that is real engineering work in your environment, not advisory hours. The testing line is more predictable, and you can scope it sensibly once you know your external surface and application count. Our penetration testing cost guide breaks down how that pricing works so you can budget the validation layer without surprises. The mistake we warn against is underspending on testing to save money, then failing the effectiveness requirement and paying for both the original gap and the enforcement consequence.

NIS2 rewards companies that treat it as a security program with governance attached, and it punishes companies that treat it as paperwork. The deadlines have passed, national enforcement is active, and the supervisory authorities want evidence that your controls work. We help regulated companies confirm scope, close the Article 21 gaps, validate the controls with real testing, and stand up incident response against the reporting clock. If you want to see how your current posture maps to the directive, start with our GRC services and our NIS2 compliance page, then book a scoping call and we will tell you exactly where you stand.