NIS2, turned from a directive into a defensible program.

NIS2 replaced the original 2016 NIS Directive to fix a problem regulators had watched grow: cybersecurity that was uneven across the bloc, a sector list that was too narrow, and obligations that too many organisations treated as filing rather than operating. The revised directive, formally Directive (EU) 2022/2555, came into force in January 2023 and replaced its predecessor from 18 October 2024. It widens the net to eighteen sectors, raises the baseline every covered organisation has to meet, and, the part that changes behaviour most, moves accountability onto the management body instead of leaving it with the IT department.

The practical shift is from documents to evidence. Holding a policy is no longer the point. You have to show that the measures work, that incidents are handled to a process you have actually tested, and that the suppliers who run your systems meet an equivalent standard. That is a different kind of effort from a one-off certification project, and it does not end on an audit date. It is closer to running a program than passing an exam, which is why the organisations that struggle are usually the ones that built a binder and stopped.

Three numbers frame the scale of the change. The sector list went from a handful of operators of essential services to eighteen sectors. The estimated population of regulated entities rose to around 160,000 across the EU, roughly sixteen times the original scope. And the penalty ceiling rose to a level that puts cybersecurity on the same board agenda as data protection. None of those numbers is the work, but together they explain why the directive cannot be delegated and forgotten.

Two questions decide whether NIS2 applies to you and how heavily. The first is sector: the directive lists sectors of high criticality in its first annex and other critical sectors in its second. The first annex covers energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure, ICT service management, public administration and space. The second adds postal and courier services, waste management, the manufacture and distribution of chemicals, food, manufacturing of certain products including medical devices and machinery, digital providers such as online marketplaces and search engines, and research.

The second question is size. The general rule pulls in medium and large enterprises, which the directive frames as fifty or more staff, or annual turnover or balance sheet above ten million euro. Micro and small organisations usually fall outside the mandatory scope, with an important exception: a member state can designate a smaller entity where it is the sole provider of a critical service in a region, or where its failure would have a significant effect on public safety, security or health. A second exception removes the size test entirely for certain entity types, including qualified trust service providers, top-level-domain registries and DNS service providers, which are in scope whatever their headcount.

Where sector and size place you then sets your category. Larger operators in the highest-criticality sectors are essential entities; medium operators and those in the other-critical sectors are important entities. Both carry the same obligations. What differs is supervision and exposure, and that difference is worth understanding before you plan the work.

The table makes the practical point clear. The work is the same for both categories; the consequence of getting it wrong is heavier for essential entities, and a regulator does not need to wait for an incident to come and look. That is the case for treating the assessment as the first step rather than something to schedule after the first audit letter arrives.

Article 21 lists ten areas every in-scope entity has to cover. They are written to be technology-neutral and outcomes-based: the directive tells you what to achieve and leaves the how to you, with a proportionality rule that scales the depth of each control to your size, your risk exposure and the societal impact of a failure. The ten are not exotic, and most security teams will recognise them. The work is making them real, current and provable across the whole estate, and keeping them that way after the project team has moved on.

In plain terms, the ten cover: risk analysis and an information-system security policy; incident handling, meaning detection, response and recovery; business continuity, including backup management, disaster recovery and crisis management; supply-chain security, including the security of relationships with direct suppliers and service providers; security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure; policies and procedures to assess whether the risk-management measures are actually effective; basic cyber hygiene practices and cybersecurity training; policies on cryptography and, where appropriate, encryption; human-resources security, access-control policies and asset management; and the use of multi-factor or continuous authentication, secured voice, video and text communications, and secured emergency communications where appropriate.

Two of these tend to be where existing security programs fall short. Supply-chain security asks you to look beyond your own perimeter at who runs and touches your systems, which many organisations have never formally assessed. And the requirement to assess the effectiveness of your own measures rules out the binder approach: it is not enough to have a backup policy, you have to show the restore was tested and worked. The proportionality rule is a relief here rather than a loophole. A medium manufacturer is not held to the same depth as a national grid operator, but both have to show the measure exists and functions at a level appropriate to their risk.

If you hold a current ISO 27001:2022 information-security management system, you have done a large part of the work, and it is fair to start from there rather than from a blank page. By ENISA's published mapping, an established ISO 27001 implementation addresses something in the order of seventy percent of the Article 21 measures. The management-system discipline, the risk assessment, the access controls, the supplier clauses and the continuity planning all carry across. The mistake is to read seventy percent as done.

The remaining gaps are consistent enough to plan around. NIS2 is more explicit than ISO 27001 about supply-chain security, naming the security of supplier relationships as its own measure. It adds the fixed incident-reporting timelines, which a management system does not impose. It places named accountability and a training duty on the management body, which goes beyond the governance an ISMS usually documents. And it is specific about multi-factor authentication and secured communications. A structured mapping exercise, comparing your Annex A controls against Article 21 line by line, finds these gaps so you close them deliberately instead of assuming the certificate stretches further than it does.

Article 23 imposes the most prescriptive reporting cascade in EU cybersecurity law, and it only triggers for a significant incident. The test for significance has two prongs, and either is enough: the incident has caused or could cause severe operational disruption or financial loss for your entity, or it has affected or could affect other people through considerable material or non-material damage. The second prong catches incidents that barely touch you internally but harm your customers, which is exactly the case organisations tend to miss when they judge significance by their own downtime alone.

Once an incident qualifies, the clock runs in three stages, all reported to the national CSIRT or competent authority where you provide services.

Organisations that have only written the procedure tend to lose the first day arguing about whether the event qualifies and who is allowed to sign the notification. Organisations that have rehearsed it spend that day containing the incident. A cross-border incident adds a complication worth planning for in advance: it has to be reported in parallel to every affected member state's CSIRT, not just your own. We build the reporting path into the incident plan and exercise it, so the decisions a real incident forces have already been made, calmly, before the twenty-four-hour clock is running.

The most consequential change in NIS2 is not a technical control. Article 20 requires the management body to approve the cybersecurity risk-management measures and to oversee their implementation, and it allows members to be held liable where they fail that duty. It also requires those same management-body members to follow training so they can identify risks and assess the adequacy of the measures, and it expects the entity to offer comparable training to staff on a regular basis.

This reframes cybersecurity as a governance obligation with names attached rather than a budget line the board signs off without reading. For essential entities, the directive goes further: an authority can ask for the temporary suspension of the management functions of an individual responsible for non-compliance. In practice this means the board needs more than a quarterly dashboard. It needs evidence that it has reviewed the risk, approved the measures knowingly, and kept its own competence current. The training requirement is easy to overlook and easy for an auditor to check, because a program that trains the workforce but skips the leadership does not satisfy the directive.

Article 34 sets the penalty framework, and the numbers are deliberately large enough to command board attention. For essential entities, administrative fines reach at least ten million euro or two percent of total worldwide annual turnover, whichever is higher. For important entities, the ceiling is at least seven million euro or 1.4 percent. Member states are free to set higher national ceilings, and several have. These are the headline figures, but the fine is rarely the whole story.

Authorities have a range of non-monetary powers that often bite harder. They can issue binding instructions to fix specific failings, order an entity to make an infringement public, impose periodic penalty payments to compel an entity to stop an ongoing breach, and, for essential entities, suspend management functions. The reputational damage of a public enforcement notice, the contractual consequences with customers who now have their own NIS2 supply-chain duty, and the operational cost of a forced remediation under a regulator's timeline tend to exceed the fine itself. The supervision model amplifies this for essential entities: because they can be audited proactively, a gap can be found and acted on without any incident at all.

NIS2 is a directive, which means it takes effect through each member state's own national law rather than directly. The transposition deadline was 17 October 2024, and most member states missed it; only a small group, including Belgium, Croatia, Italy and Lithuania, had national law in place on time. Through 2025 and into 2026 the rest moved, and the great majority of member states have now adopted transposing legislation, with a handful still completing the process. The European Commission opened infringement proceedings against the states that were late, escalated to reasoned opinions in 2025, and by 2026 the enforcement track had reached the Court of Justice for the slowest.

For an organisation, the lesson is not to memorise a country table that goes stale within weeks. It is that your obligations crystallise when your member state's law is in force, that national rules can add their own scope, registration steps, deadlines and competent authorities on top of the directive's baseline, and that several regimes set their own dates for registration and a first compliance assessment. We treat the directive minimums as the planning baseline and verify the country-specific overlays against the national competent authority, because that is the honest way to give advice on a position that is still settling.

We start with a scoping assessment to settle whether you are in scope at all, and if so whether you are essential or important and which services are caught. From there a gap assessment runs against each Article 21 measure and the Article 23 reporting duty, and produces a prioritised, costed roadmap rather than a wall of findings. The output is something a board can approve and a team can execute, with the heaviest risks and the cheapest fixes flagged so the first month of effort lands where it matters.

Then you choose how much to run yourself and how much we operate. Some clients want the assessment and the roadmap and will execute internally; others hand us the monitoring, detection and incident response, and the standing job of keeping the evidence current. Because we operate our own infrastructure inside the EU, the supply-chain measure has a short, defensible answer: the people and systems that touch your data are in the Union, under European law, rather than a diagram of offshore subcontractors an auditor has to unpick.

The deliverable an auditor cares about is evidence, not intention. The readiness check below is the kind of pass we run at the start of an engagement, mapping what exists against what Article 21 expects and flagging where the proof is missing rather than the policy.

# scope the entity before checking anything
$ argus nis2 scope --sector digital-infra --staff 180 --turnover 32M
  classification: IMPORTANT entity (Annex II, medium size)
  supervision: reactive   reporting: CSIRT (24h / 72h / 1 month)

# check each Article 21 measure for evidence, not just policy
$ argus nis2 assess --against article-21
  [pass] risk analysis & security policy      evidence: approved 2026-03
  [pass] incident handling                     evidence: runbook + 1 drill
  [pass] access control & asset management     evidence: IAM export
  [warn] multi-factor authentication           gap: remote access partial
  [fail] supply-chain security                 gap: no supplier register
  [fail] management training (Art. 20)         gap: no board record

  readiness: 71%   blocking gaps: 2   advisory gaps: 1
  next: (1) supplier risk register  (2) board training + sign-off

That output is the honest starting point of a NIS2 program: a clear scope, a short list of the gaps that actually expose you, and a path to closing them in priority order. If something we find sits outside our competence, we will tell you and bring in the right specialist rather than stretch to cover it. The goal is a program you can defend to a regulator and operate after we leave, not a binder that looks complete until someone asks for the evidence.