NIS2 in 2026: who it covers, the 24-hour clock, and why your country's version is the one that counts.

NIS2 is the European Union's cybersecurity law for organisations that matter to how society runs, and in 2026 it has moved from a deadline most people ignored to enforcement that is starting to land. It applies to medium and large entities across eighteen sectors, sorts them into essential and important, and obliges each to run a baseline of security measures, report significant incidents on a 24-hour, 72-hour and one-month clock, and hold its board personally answerable for getting this right. The complication that defines the year is that NIS2 is a directive, not a regulation, so what binds you is your country's national transposition rather than the directive itself, and those national laws arrived late and unevenly. The obligations are real; the rulebook you must read is the one written in your own member state.

Member states were required to transpose NIS2 by 17 October 2024, with the rules applying from the next day. A large number missed it. The European Commission opened infringement proceedings against 23 member states in November 2024, and in May 2025 sent reasoned opinions, a sharper formal step, to 19 that still had not notified full transposition, with several referred toward the Court of Justice. Through late 2025 and into 2026 the picture has steadily filled in: earlier movers such as Belgium, Italy, Hungary and Croatia completed their laws, Germany's NIS2 implementation act took effect in December 2025 with its national registration live, and by the first quarter of 2026 the majority of states had transposed, while a few, among them France, the Netherlands and Spain, were still finalising or operating under interim arrangements.

Two things follow from that for a covered organisation. The first is that enforcement has begun where the law is in place: through the first half of 2026, the earliest-transposing states started supervisory action, with proceedings over late incident notification, formal warnings to entities lacking baseline measures, and sector inspections. The grace period, in those countries, is over. The second is that waiting for your own country to finish is not a strategy, because several states apply obligations from the moment their law takes effect with no transition period, and the security work the directive demands takes months to stand up regardless of the legal date. The honest reading is that the deadline debate is a distraction from the build, which has to happen either way.

NIS2 expects entities in scope to make themselves known to their national competent authority, registering basic details such as their name, sector, contact points and the member states in which they operate, so the regulator has a population it can supervise. The mechanism is national: Germany's authority opened its registration process when its implementation act took effect at the end of 2025, and other member states run their own portals and timelines. For a group operating in several countries this multiplies, because the entity may need to register, and report incidents, separately in each member state where it has covered operations, each through a different channel and authority. Identifying the right authority and registering on time is unglamorous, but failing to do it is itself a breach, and it is the step that puts you on the regulator's radar in the first place. The sensible order is to settle scope and entity type, then register, then turn to the security baseline, rather than discovering the registration duty after an incident has already started the reporting clock. There is some relief coming on the reporting side: the NIS2 cooperation group has adopted common incident-reporting templates to standardise filings across member states, and a single entry point for reporting has been proposed to spare multi-country entities from filing the same incident many times over.

When a covered entity becomes aware of a significant incident, one that causes or can cause serious operational disruption or financial loss, or affects others through harm, the reporting runs in stages. An early warning goes to the national CSIRT or competent authority within 24 hours, flagging whether the incident looks malicious or could cross borders. A fuller notification follows within 72 hours, with an initial assessment of severity and impact and any indicators of compromise. A final report is due within one month, and if the incident is still live at that point, a progress report is filed instead, with the final report following once it is resolved. The cooperation group has been standardising the templates for this to cut the paperwork, but the deadlines themselves are firm.

The 24-hour figure is the one that exposes the gap between compliance on paper and compliance in fact. You cannot warn an authority within a day about an incident you have not detected, and you cannot characterise its severity at 72 hours without logs, monitoring and someone watching them. A great deal of NIS2 reads like governance, but the reporting clock is a detection-and-response requirement wearing a legal coat, and an organisation without round-the-clock visibility of its systems will miss the first deadline not through negligence but through blindness. This is the part that turns NIS2 from a document your lawyers own into a capability your security operations have to provide, and it is the reason a serious response to the directive starts with the question of who, or what, is watching.

Under Article 20, the management body of a covered entity must approve the cybersecurity risk-management measures, oversee their implementation, and take part in training so that members can recognise and weigh cyber risk themselves. Crucially, members of that body can be held personally liable for failures in this duty, and several national transpositions give authorities the power to suspend named individuals from management functions until the failures are remediated. This is the provision that turns NIS2 from an IT budget line into a governance obligation, because it removes the option of treating security as something delegated entirely downward and forgotten. A board that has never seen the entity's risk assessment, or that signs it off without understanding it, is now carrying a personal exposure it cannot outsource.

Strip the directive back to what it forces you to be able to do, and a pattern emerges. You must detect a significant incident, because the 24-hour clock starts at awareness. You must characterise it within 72 hours, which needs logs, telemetry and someone able to read them under pressure. You must show, on demand for essential entities, that your measures work and that you can reconstruct what happened. None of that is satisfied by a binder of policies; it is satisfied by continuous monitoring, by a security information and event management system that is tuned rather than merely installed, and by people or automation watching it around the clock. An organisation can have every Article 21 policy written and still fail NIS2 at the first real incident because nothing was watching when it mattered.

That is the lens we bring, because monitoring is the discipline the firm is built around rather than a service we bolted on. A workable NIS2 response sequences in a particular order: confirm your scope and entity type under national law and register where required; close the Article 21 gaps with the board trained and signed on; and stand up the detection and response capability that the reporting clock silently assumes, whether that is a managed SIEM, a security operations capability, or open-source tooling run properly rather than left in default. We are candid about where the honest answer is to do less or to use what you have, because a tuned open-source stack watched by people who understand it beats an expensive platform nobody reads. Where it helps to put real eyes on your systems, that is the work our managed security practice exists to do, and it is where NIS2 stops being a compliance cost and becomes the monitoring you should have had anyway.