NIS2 Incident Response Plan: Build It Backwards From the 72-Hour Form — the 4 Internal Deadlines Article 23 Never Names

Most incident response plans are written forwards — detect, contain, eradicate, recover — and then a reporting step is bolted on at the end. That order is why so many plans fail their first real test. Under NIS2, the notification deadlines are not the last thing that happens; they are the constraint that determines how fast every earlier step has to run. Build the plan backwards from the filings and you get four internal deadlines the Directive never states, but that your organisation cannot meet Article 23 without.

Your Plan Answers to Two Legal Parents, and They Disagree About Reporting

In plain terms: NIS2 treats “handling an incident” and “telling the authorities about it” as two different legal duties, in two different articles. Your plan has to satisfy both, and only one of them has a clock.

Article 21(2)(b) lists incident handling as one of the ten minimum risk-management measures. Article 23 sets the reporting obligations. The Directive’s own definitions keep them apart: Article 6(8) defines incident handling as “any actions and procedures aiming to prevent, detect, analyse, and contain or to respond to and recover from an incident” [1]. Notification is not in that list.

The Commission’s implementing regulation puts it back. Annex point 3.1.1 of CIR 2024/2690 requires an incident handling policy laying down the roles, responsibilities and procedures for “detecting, analysing, containing or responding to, recovering from, documenting and reporting of incidents in a timely manner” [2]. Two verbs the Directive’s definition omits — documenting and reporting — sit inside the policy the regulation expects you to hold.

That is why a technically excellent runbook can still fail an inspection: it covers everything in Article 6(8) and nothing in Article 23, so the notification has no owner, no input deadline, and no evidence trail.

Before treating the CIR Annex as binding on you, check whether it is. Article 1 names the entities it applies to, and the list is narrower than most guidance implies.

Your entity type	Status of CIR 2024/2690 Annex Section 3	What that means for your plan
DNS providers, TLD registries, cloud, data centres, CDN, MSP/MSSP, online marketplaces, search engines, social platforms, trust services	Legally binding (CIR Art. 1) [2]	Points 3.1–3.6 are requirements. Where the Annex says “where appropriate” and you disagree, Art. 2(2) obliges you to document your reasoning “in a comprehensible manner” [2]
Every other essential or important entity (energy, health, transport, manufacturing, water, public administration and the rest)	Interpretive reference only	Use it as the benchmark your national authority is most likely to read Article 21(2)(b) against — but do not cite it as your legal obligation

The Four Internal Deadlines Article 23 Never Names

Article 23(4) gives you three external deadlines: 24 hours for the early warning, 72 hours for the incident notification, one month for the final report [1]. Those are the moments a filing must already be complete. A plan built on them alone has no instruction for the hours in between — which is where every failure actually happens.

Belgium’s national CSIRT is blunt about this. Its notification guide states that “without undue delay” means notifying “as soon as possible, without waiting for the maximum deadlines of 24 hours and 72 hours”, and that “compliance with the organisation’s internal procedures must not lead to an unreasonable delay in notifying the incident” [4]. Read that second sentence as a plan-design instruction: a slow internal approval chain is not a mitigating circumstance. It is the finding.

Working backwards from each filing gives you four internal deadlines and, for each, a document that must already exist when the clock starts.

Internal deadline	Driven by	What must exist before the incident
D1 — Declaration. Triage completed and the significance call made and timestamped	The 24-hour clock runs from awareness, and on the reading in CIR Recital 31 awareness is the end of triage, not the first alert	Predefined significance criteria, a named declaring role with deputies, a log field for the decision time and rationale
D2 — Early warning filed. Target well inside 24 hours from declaration	Art. 23(4)(a), read with the “without undue delay” rule [1][4]	Portal account or access route, the two indications the early warning carries, a named human to receive the CSIRT’s reply
D3 — Assessment frozen. Severity, impact and indicators of compromise written down, not still being investigated	Art. 23(4)(b) requires an initial assessment at 72 hours [1]	Sentence stems for severity and impact, an IoC export the responders can produce under pressure
D4 — Final report drafting starts on the day you file the notification	Art. 23(4)(d) runs the one-month clock from your submission, not from the incident [1]	A final report template pre-mapped to the four contents required by Art. 23(4)(d)(i)–(iv)

None of these four appear in the Directive. All four are forced by it.

Deadline 1 — Declaration: Who Is Allowed to Start the Clock

The Directive does not define “becoming aware”. The nearest EU-level formulation sits in Recital 31 of CIR 2024/2690: an entity is to be regarded as aware “when, after such initial assessment, that entity has a reasonable degree of certainty that a significant incident has occurred” [2]. Recitals are interpretive and non-binding — they explain intent rather than create obligations — but this one is reproduced almost word for word in national guidance, which tells you how authorities read it in practice.

So your organisation controls when its own clock starts, and that control is auditable. Two failure modes follow.

The first is declaring too late by accident. If the only person authorised to call an incident significant is the CISO, and the CISO is on a flight, triage stalls and the “unreasonable delay” test bites. Name deputies, in order, with the same authority — this is the escalation structure a crisis management plan already sets out in tiers, and the incident plan should point at it rather than invent a second hierarchy.

The second is declaring on instinct. CIR Annex 3.4.2(a) requires assessment “based on predefined criteria laid down in advance, and on a triage to determine prioritisation of incident containment and eradication” [2]. Criteria written in advance are what stop declaration becoming a judgement call under stress. Inside the CIR’s scope, Article 3(1) supplies seven, any one sufficient — including 3(1)(e), “a successful, suspectedly malicious and unauthorised access to network and information systems occurred, which is capable of causing severe operational disruption” [2]. A ransomware event meets that on its own, with no financial calculation required. Our guide to what counts as a significant incident and the classification decision guide work through the thresholds.

Either way, record the call. The declaration timestamp and its reasoning are the most useful artefact your plan generates, because every later deadline is measured from it.

Deadline 2 — Early Warning: Two Facts Out, One Channel In

Article 23(4)(a) asks for far less than most templates supply. The early warning “where applicable, shall indicate whether the significant incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact” [1]. Two indications, both qualified. Severity, impact and indicators of compromise belong to the 72-hour filing, not this one — the 72-hour notification requirements set out that split precisely.

Recital 102 confirms the design intent: the early warning “should only include the information necessary to make the CSIRT, or where applicable the competent authority, aware of the significant incident and allow the entity concerned to seek assistance, if required”, and must not “divert the notifying entity’s resources from activities related to incident handling that should be prioritised” [1]. Filing thin is not cutting corners. It is what the instrument asks for.

Belgium’s form shows what that looks like in practice: for both the malicious-intent and cross-border questions, entities are told that “if you do not know or are not convinced, please tick ‘Uncertain'” [4]. National portals differ — the CSIRT notification form comparison covers those differences — but “Uncertain” being an instructed answer rather than a failure belongs in your plan, so nobody delays a filing waiting for confidence they will not have at hour six.

The part almost every plan misses is the return channel. Article 23(5) obliges the CSIRT or competent authority to respond “without undue delay and where possible within 24 hours of receiving the early warning”, with initial feedback and, on request, “guidance or operational advice on the implementation of possible mitigation measures”; the CSIRT “shall provide additional technical support if the entity concerned so requests”, and must point you to law enforcement where criminal conduct is suspected [1]. Belgium makes describing the support you need a mandatory form field [4].

So the early warning is not a one-way filing — it opens a support channel with a 24-hour service level attached. Your plan needs a named person monitoring the inbox that reply lands in, and a pre-agreed position on whether you will request operational assistance. Deciding that at 03:00 is not a decision, it is an omission.

Deadline 3 — The 72-Hour Notification Is a Set of 500-Character Boxes

Article 23(4)(b) adds exactly three things to what you already filed: an update to the early warning, “an initial assessment of the significant incident, including its severity and impact”, and “where available, the indicators of compromise” [1].

Operationally, that is not a report. In the Belgian portal, the severity assessment, the consequences, the root cause and the support requested are each mandatory free-text fields with a hard maximum of 500 characters, and the actions-taken field is capped at 500 too [4]. Other Member States design their own forms, so treat the figures as Belgian rather than universal — but the shape inverts how most teams prepare. The deliverable at hour 72 is roughly a paragraph per question, written under pressure, by someone who has been awake for three days.

That makes the plan’s job specific and unglamorous: pre-write the sentence stems. A severity statement reading “X of Y production services were unavailable for Z hours, affecting approximately N customers, with no evidence of data exfiltration as at [time]” can be completed in ninety seconds. A blank box cannot.

Recital 101 supplies what the assessment should weigh: “the affected network and information systems, in particular their importance in the provision of the entity’s services, the severity and technical characteristics of a cyber threat and any underlying vulnerabilities that are being exploited as well as the entity’s experience with similar incidents” [1]. Note what that asks for: the affected systems, their importance to the service, the threat’s severity and technical characteristics, the vulnerabilities being exploited, and your own history with similar incidents. If your responders cannot answer those from the tooling they already run, the gap is in detection and asset inventory rather than in the plan’s wording — and hour 60 of a live incident is the worst moment to find out.

Note the trust service provider derogation: for incidents affecting their trust services, they file the incident notification within 24 hours, not 72 [1]. If that is you, D2 and D3 collapse into a single deadline and the plan has to be built accordingly.

Deadline 4 — The Final Report Clock Starts When You File, Not When You Are Breached

Article 23(4)(d) requires “a final report not later than one month after the submission of the incident notification under point (b)” [1]. Read that twice. The month runs from your submission, not from the incident, not from the day you recover.

Many guides state it as one month from the incident, and several leave the question open. The difference is not academic: file the 72-hour notification at hour 30 rather than hour 71 and you have shortened your own final-report window by roughly 41 hours. Filing early remains correct — “without undue delay” is a binding qualifier, and you cannot hold a filing back to buy drafting time — but the cost is real, and your plan should absorb it deliberately rather than be surprised by it.

The fix is simple: make “start the final report” a task that fires on the day the notification is submitted, owned by whoever will sign it. Article 23(4)(d) already names the four sections — a detailed description including severity and impact; the type of threat or root cause likely to have triggered it; applied and ongoing mitigation measures; and, where applicable, the cross-border impact [1]. Three of those four are things the response team knows on day one and has forgotten by week three, which is the whole argument for contemporaneous logging.

Where the incident is still running at the one-month mark, Article 23(4)(e) substitutes a progress report, with the final report due within one month of your handling of the incident [1]. The Directive sets no content list for a progress report, so any guidance on what it should contain — including ours — is practical convention, not law. Our final report and post-incident review guide covers the drafting.

Who Owns What, and the Gap You Probably Have

CIR Annex 3.1.2 requires the policy to include “assignment of roles to detect and appropriately respond to incidents to competent employees” and “effective communication plans including for escalation and reporting” [2]. Assignment means named roles, not departments.

Role	Owns	Effort to establish
Incident manager (and two named deputies)	D1 declaration call, timestamp and rationale; triage against predefined criteria	Medium — the criteria are the work, not the naming
Compliance officer or DPO	D2 and D3 filings, the reporting-obligations register, parallel GDPR assessment where personal data is involved	Medium
Technical lead	IoC extraction, the five Recital 101 assessment inputs, evidence preservation	High if detection tooling is immature
Named CSIRT liaison	Monitoring the Article 23(5) response channel; requesting operational support	Low
Management body	Approving the policy; the decision to disclose to service recipients under Art. 23(1)	Low, but must be scheduled in advance

To find your own gap, run the four internal deadlines as a three-column exercise: for each, write the current state (who does this today, and how long it takes), the required state (the deadline above), and the effort to close. In practice, two gaps recur often enough to check first. D1 — nobody is formally authorised to declare, so the call is made by consensus, and consensus takes hours. D4 — the final report is treated as a closure activity rather than a parallel one.

Smaller teams should resist writing a sixty-page plan. A six-page document that names three deputies, carries the significance criteria, holds the pre-written sentence stems and points at the notification portal will outperform an unread manual. What it cannot do is leave the declaration authority implicit.

The Evidence an Auditor Asks For

ENISA’s Technical Implementation Guidance (version 1.0, June 2025) lists, under each incident-handling point, examples of the evidence an assessor would expect [3]. Those bullets are explicitly indicative and non-exhaustive — ENISA’s guidance, not the binding text of the Annex — but they are the closest thing to a published evidence checklist the EU has produced.

Artefact	Why it exists
A list of reporting obligations and deadlines, covering legal and contractual duties [3]	NIS2 is rarely your only clock. Sector rules, GDPR and customer contracts run in parallel
An incident categorisation system [3]	Required by Annex 3.1.2(a); it is what makes D1 repeatable
Incident response logs recording detection, containment and eradication times, IoCs, root cause, impact assessment and whether the CSIRT was notified under Articles 23 and 30 [3]	These fields are the raw material for the 72-hour assessment and the final report
Documented procedures for communicating with the authorities and the CSIRT [3]	Annex 3.5.3(a) requires the communication plan; this is its evidence
Records of tests and drills, and the version history of the plan [3]	Annex 3.1.3 and 3.5.5 require testing and review

On frequency, be careful what you promise. The binding Annex says the roles, responsibilities and procedures “shall be tested and reviewed and, where appropriate, updated at planned intervals and after significant incidents or significant changes to operations or risks” — it names no interval [2]. ENISA’s guidance recommends testing and reviewing at least annually, and names tabletop exercises, incident simulations, red team/blue team exercises and past-incident walk-throughs as methods [3]. Annual is a defensible convention, not a legal cadence — and a tabletop exercise is the cheapest way to find out whether your declaration authority works when the named person is unavailable.

Frequently Asked Questions

Does the 24-hour clock start when our monitoring system raises an alert?
No. It starts at awareness, which CIR Recital 31 frames as the point where, after an initial assessment, the entity has “a reasonable degree of certainty that a significant incident has occurred” [2]. The Directive itself does not define the term, and that recital is interpretive rather than binding — but triage time is not free, and an assessment that drags is exposed to the “unreasonable delay” test [4].

Can the same document be our incident response policy and our incident response plan?
In a small organisation, yes, provided it carries both the governing rules and the operational detail. CIR Annex 3.1.2 lists what the policy must contain, including escalation and reporting communication plans and the response documents themselves [2]. Our incident reporting hub sets out how the reporting duties sit across those documents.

Who is allowed to submit the notification?
That is set nationally. Belgium’s portal, for example, requires no prior authentication, and an emergency phone call “may be considered equivalent to the notifications” where the form is unreachable [4]. Check your own authority’s rules, and name the submitter and a deputy in the plan either way.

If we file the early warning and the incident turns out not to be significant, are we penalised?
Article 23(1) provides that notification alone does not increase liability [1]. Withdrawing or correcting a filing is handled by national procedure.

We are not a cloud or MSP entity. Do we have to follow CIR 2024/2690?
Not as a legal obligation. Article 1 binds only the digital-infrastructure and trust-service categories it lists [2]. For everyone else the Annex is the most detailed published reading of Article 21(2)(b), and authorities are likely to measure against it — which is a strong reason to align, and a poor reason to cite it as your requirement.

Key Takeaways

• Article 21(2)(b) and Article 23 are separate duties. The Directive’s definition of incident handling at Article 6(8) excludes reporting; CIR Annex 3.1.1 puts documenting and reporting back inside the policy [1][2].
• Article 23’s three deadlines are outputs. Your plan needs four internal deadlines to produce them: declaration, early warning filed, assessment frozen, final report started.
• The 24-hour clock starts at awareness — the end of triage — so declaration authority and named deputies are the most consequential lines in the document [2].
• The early warning carries two indications, both qualified. It also opens a support channel the CSIRT must answer within 24 hours under Article 23(5) — staff the inbox [1].
• The 72-hour notification is a small number of short, mandatory fields. Pre-write the sentence stems [4].
• The one-month final report clock runs from your submission, not from the incident. Start drafting the day you file [1].

Those four internal deadlines live inside a document with a required shape. For the section list itself, see the six sections CIR Annex 3 expects in an incident response plan.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Directive (EU) 2022/2555 (NIS2), Articles 6(8), 21 and 23, and Recitals 101 and 102 — Article 21 and Article 23 linked in full above; all quoted wording verified against the Official Journal text on EUR-Lex, CELEX 32022L2555.
2. Commission Implementing Regulation (EU) 2024/2690, Articles 1, 2(2), 3 and 4, Annex Section 3 and Recital 31 — EUR-Lex, linked in full above; all quoted wording verified against the Official Journal text.
3. “Technical Implementation Guidance on cybersecurity risk management measures”, version 1.0, June 2025 — European Union Agency for Cybersecurity (ENISA), linked above.
4. “NIS2 Notification Guide”, version 1.2, October 2024 — Centre for Cybersecurity Belgium (CCB). A version 1.3 was published in August 2025; the figures cited here are from version 1.2 and describe the Belgian portal specifically.