Skip to main content
NIS2Certify
Back to overview

NIS2 Incident Handling: Why Article 21(2)(b) Fails More Audits Than Article 23

By NIS2Certify
nis2incident-handlingarticle-21incident-responsemspcompliance
NIS2 Incident Handling: Why Article 21(2)(b) Fails More Audits Than Article 23

A security analyst at a Dutch managed service provider sees unusual outbound traffic from a client's file server at 02:14 on a Saturday. She raises a ticket, tags it "investigate", and goes back to the queue. The account manager reads it Monday at 09:30, calls the client, and someone finally asks the question that matters: is this reportable?

By then the 24-hour early warning window closed 31 hours ago.

That is not an incident reporting failure. It is a NIS2 incident handling failure — Article 21(2)(b) — and it is the measure that quietly decides whether every other deadline in the directive is achievable.

Article 23 gets the attention. Article 21(2)(b) decides whether you can meet it

Most compliance conversations start with the reporting clock: 24 hours, 72 hours, one month. Those deadlines come from Article 23. They are visible, countable, and easy to put on a slide.

Article 21(2)(b) is the measure underneath them. It requires incident handling — a documented, exercised process for detecting, analysing, containing, responding to, and recovering from incidents.

The relationship is one-directional. You cannot notify an incident you have not classified. You cannot classify an incident nobody escalated. You cannot escalate an incident that sits in a ticket queue labelled "investigate" over a weekend.

When a supervisory authority finds a missed 24-hour deadline, it does not stop at the deadline. It asks how the entity became aware, who decided, and against what criteria. That line of questioning lands squarely in Article 21(2)(b) — and it usually finds nothing written down.

What the binding text actually requires

Article 21(2)(b) of the directive is one line. The detail lives in Commission Implementing Regulation (EU) 2024/2690, which applies directly in all 27 member states without national transposition.

The CIR binds a specific list of entity types: DNS service providers, TLD name registries, cloud computing service providers, ICT service management and managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers. If you run an MSP or MSSP, you are on that list — not as a supplier, but as a regulated entity in your own right. We covered that double obligation in NIS2 for MSPs and MSSPs.

For everyone else — energy, healthcare, transport, manufacturing, public administration — the CIR is not formally binding, but it is the most authoritative statement available of what "appropriate and proportionate" means. Assume your regulator will read it that way, because they have nothing better to reach for.

Annex point 3 of the CIR covers incident handling. It requires a policy and procedures covering detection, analysis, containment, response and recovery; defined roles and responsibilities; logging; escalation and communication paths; and a structured post-incident review that feeds lessons learned back into the other measures.

That last clause is the one teams skip. Incident handling is not a closed loop that ends when the system is restored. It is an input into your risk assessment, your training programme, and your effectiveness review under Article 21(2)(f).

Article 21 — 10 NIS2 Cybersecurity Measures
Article 21
10 Cybersecurity Measures
Governance & Strategy
1Risk analysis & information security policies
6Effectiveness assessment of security measures
Incident & Continuity
2Incident handling & notification
3Business continuity & disaster recovery
Supply Chain & Systems
4Supply chain security
5Security in network & information systems development
Technical Controls
8Cryptography & encryption
10Multi-factor authentication & secure communications
People & Assets
7Cyber hygiene & training
9HR security & access control

Your significance threshold is a control, not a judgement call

The CIR does not leave "significant" to interpretation. Article 3 sets criteria: an incident is significant where it causes direct financial loss exceeding EUR 500,000 or 5% of annual turnover, results in exfiltration of trade secrets, or causes death or considerable damage to a person's health.

Article 4 adds a rule that most incident processes ignore entirely: recurring incidents that individually fall below the threshold can be aggregated and treated as a single significant incident if they collectively meet the criteria within a six-month period. Five small credential-stuffing events across a client base are not five non-events. They may be one reportable incident, and nobody notices unless someone is tracking the aggregate.

Article 5 tightens this further for DNS providers and TLD registries — availability dropping below 99.9% for any period is enough on its own.

The practical consequence for consultants: your client's incident classification criteria must be written down before an incident, mapped to these thresholds, and owned by a named role. An analyst at 02:14 on a Saturday should not be inventing a significance test. She should be applying one.

The clock runs from awareness, not from agreement

Article 23(3) starts the 24-hour early warning window when the entity becomes aware of a significant incident. Not when management agrees it is significant. Not when the incident response retainer is activated. Not on Monday.

That distinction is where most missed deadlines originate. The organisation had the information on Saturday and the decision on Monday, and treats the gap as internal process. The regulator treats it as a 31-hour delay.

Build the process backwards from the deadline instead. If the early warning is due in 24 hours, escalation to a decision-maker has to happen in hours, which means detection has to raise a classified alert, which means someone must be reachable outside business hours with authority to decide. Each of those is a design choice you make now or discover during an incident.

The full sequence — early warning at 24 hours, incident notification at 72 hours, final report at one month — is in our incident reporting deadlines guide, and the official reporting templates tell you exactly which fields you will need to fill under time pressure.

NIS2 Incident Reporting Timeline
24h
Early Warning
Notify the competent authority (CSIRT/NCA) within 24 hours of becoming aware of a significant incident.
72h
Incident Notification
Submit a detailed notification within 72 hours with an initial assessment of severity, impact and indicators of compromise.
1mo
Final Report
Deliver a comprehensive final report within one month covering root cause, remediation taken and cross-border impact.

Five places incident handling breaks in a real client environment

Detection produces alerts, not incidents. A SIEM firing 400 alerts a day is not incident detection. Detection under Annex point 3 means alerts are triaged into a defined severity model with an owner and a response time.

Escalation depends on one person. The process works because Marco knows what to do. Marco is on holiday. Document the role, not the person, and name a deputy.

Out-of-hours coverage is assumed, not contracted. Ask the direct question: between Friday 18:00 and Monday 08:00, who has the authority to declare a significant incident? If the answer needs a meeting, the answer is nobody.

Third-party dependencies are outside the process. Your client's incident may start at their cloud provider or at you. Article 21 obligations do not transfer with the workload. Contractual notification requirements toward suppliers belong in the plan — see supplier contracts and NIS2.

Post-incident review is a debrief, not a record. A conversation is not evidence. The CIR expects a structured review with findings, owners, and changes made. No document, no measure.

Supervision escalates when handling is absent

Essential entities are under ex-ante supervision — authorities can audit proactively, without waiting for an incident. Important entities face ex-post supervision, triggered by an incident or credible information about non-compliance.

Either route ends in the same place if incident handling is missing. Authorities can issue binding instructions, order specific remediation, require notification of affected customers, publish the non-compliance, and impose administrative fines. For essential entities that ceiling is EUR 10 million or 2% of global annual turnover, whichever is higher. The non-financial consequences are frequently the harder ones — we covered those in 7 NIS2 penalties worse than money.

2026 is when this stopped being theoretical. Member state transposition is now largely complete, the Netherlands' Cyberbeveiligingswet entered into force on 15 August 2026, and the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice in July over incomplete transposition. Supervisory authorities are running inspections against national law that exists.

NIS2 Penalty Escalation — Beyond the Fine
!
Trigger event
Non-Compliance Detected or Incident Occurs
A supervisory authority identifies a compliance gap or an organisation fails to meet NIS2 requirements
Authorities can impose
▼
Non-Monetary Penalties
1
Compliance orders with binding deadlines
2
Mandatory security audits at your expense
3
Public disclosure of violations
4
Binding instructions on specific security measures
Escalates to
▼
Operational & Personal Consequences
1
Suspension of certifications or operating licences
2
Temporary ban on management functions for individuals
3
Public naming of responsible natural persons
Trigger
Non-monetary
Operational / personal

The evidence that proves the process exists

An auditor does not assess your intentions. They assess what you can produce. For Article 21(2)(b), the file should contain:

  • An incident handling policy, approved by management, with a review date inside the last 12 months
  • Written classification criteria mapped to the CIR Article 3 thresholds
  • A named escalation chain with deputies and out-of-hours contact routes
  • Incident tickets showing detection time, classification time, and decision time as separate timestamps
  • At least one exercise or tabletop record from the past year, with the findings it produced
  • Post-incident reviews with assigned owners and evidence the actions closed
  • Logging configuration and retention that supports reconstructing a timeline after the fact

That last point matters more than it looks. If your retention window is 30 days and you file a final report at one month, you may be writing about events you can no longer evidence.

Start with the timestamps. Pull the last five incidents from any client environment and check whether detection, classification, and decision are separately recorded. If they are not, the 24-hour window is untested — and you will find out how long it really takes during the incident that counts.

If you want a structured view of where a client stands across all ten Article 21 measures before you commit to a remediation plan, run a free NIS2 quick scan. It takes a few minutes and gives you a defensible starting point for the conversation.

Incident handling is the measure that turns every other control into a response. Get the process, the criteria, and the clock right, and Article 23 becomes an administrative step. Get it wrong, and no amount of tooling will make the deadline.

    NIS2 Incident Handling: Why Article 21(2)(b) Fails More Audits Than Article 23 — NIS2Certify