NIS2 1-Month Final Report: The Clock Starts at Your 72-Hour Filing, and Article 23(4)(d) Asks for Only Four Things

The one-month clock on your NIS2 final report does not start when the incident happens. It does not start when you become aware of it. It starts the moment you press submit on the 72-hour notification — which means an entity that files its 72-hour notification on day one gives itself a shorter final-report window than one that files on hour 71.

That single mechanic is written into the text of Article 23(4)(d), and almost every published guide gets it approximately right and precisely wrong. The same guides also inflate what the final report must contain, typically to eight or ten items. The Directive names four, and three of them are unconditional.

What follows is what the provision requires, how to compute the deadline, why "root cause" does not mean a completed forensic investigation, and what you are not obliged to file. If you have not yet reached this stage, start with the 24-hour early warning and the 72-hour notification.

What Article 23(4)(d) Actually Requires

In plain language: one month after you filed your 72-hour notification, you owe the authority a closing report with four things in it — what happened and how bad it was, what kind of threat or underlying cause you believe triggered it, what you did and are still doing about it, and whether it crossed a border. That is the whole list.

The operative text is worth reading exactly as written:

"(d) a final report not later than one month after the submission of the incident notification under point (b), including the following: (i) a detailed description of the incident, including its severity and impact; (ii) the type of threat or root cause that is likely to have triggered the incident; (iii) applied and ongoing mitigation measures; (iv) where applicable, the cross-border impact of the incident"

Read the qualifiers. Only item (iv) carries "where applicable". Items (i), (ii) and (iii) are unconditional — you owe them whether or not they are convenient.

Item	What the text says	Conditional?	What it means in practice
(i) Description	"a detailed description of the incident, including its severity and impact"	No	The same severity and impact fields you filled in at 72 hours, now at full depth rather than as an initial assessment.
(ii) Cause	"the type of threat or root cause that is likely to have triggered the incident"	No	Disjunctive and probabilistic. Threat type alone satisfies it. Certainty is not required.
(iii) Mitigation	"applied and ongoing mitigation measures"	No	The text presumes remediation may be unfinished. Report both what is done and what is still running.
(iv) Cross-border	"where applicable, the cross-border impact of the incident"	Yes	The only qualified item. This is where the suspicion flagged at 24 hours gets confirmed or withdrawn — see cross-border incident notification for who you file with.

Set the three reporting stages side by side and a deliberate pattern appears. At 24 hours, both of the early warning’s indications are prefaced "where applicable". At 72 hours, only the initial assessment is unconditional; indicators of compromise are owed only "where available". At one month, three of four items are owed outright. The obligation tightens as your knowledge does — the final report is the only stage in the cascade where the content list is mostly mandatory.

One thing the final report does not do is create fresh legal exposure for the act of filing. Article 23(1) states that "the mere act of notification shall not subject the notifying entity to increased liability".

When the One-Month Deadline Actually Falls

The trigger is the phrase "after the submission of the incident notification under point (b)". Not after the incident, not after you became aware, and not after the 72-hour deadline expired — after you actually submitted.

This produces a genuinely counter-intuitive incentive. Belgium’s Centre for Cybersecurity is explicit that "without undue delay" means filing as soon as you are able rather than running the clock down, and only "duly justified special circumstances" excuse waiting until the deadline. Follow that advice and you shorten your own final-report window by up to three days. Both obligations are real, and the resolution is not to file the 72-hour notification late — it is to start the final report on the day you file it.

Then there is the arithmetic. "One month" is not thirty days, and several widely-shared guides convert it to thirty anyway. Under the EU’s general rules on time limits in Regulation 1182/71, a period expressed in months ends on the same date in the following month, the starting day is not counted, and two edge cases follow:

• Short months. If the expiry date does not exist in the following month, the period ends on that month’s last day. File on 31 January and the report is due 28 February — twenty-eight days, not thirty.
• Weekends and public holidays. Saturdays, Sundays and holidays count inside the period, but if the last day falls on one, the deadline rolls to the next working day.

72-hour notification submitted	Final report due	Elapsed days
15 March	15 April	31
31 January	28 February (29 in a leap year)	28
31 March	30 April	30
30 September (due date a Saturday)	Following Monday	32

An honest limit on that rule. Regulation 1182/71 applies by its own terms to acts of the Council and Commission. NIS2 is a Directive, so the deadline that actually binds you sits in your national transposing statute and is computed under national administrative-procedure rules. Treat the above as the EU-level default reading and confirm the computation with your competent authority — particularly the weekend roll-forward, which is the rule most likely to differ. Do not build a runbook that assumes thirty days.

"Root Cause" Does Not Mean a Finished Forensic Investigation

This is where the market’s guidance diverges hardest from the text. Competitor checklists routinely demand a "confirmed root cause with supporting evidence" at the one-month mark. Article 23(4)(d)(ii) asks for "the type of threat or root cause that is likely to have triggered the incident". It is a disjunction and a probability. Naming the threat type — credential stuffing, a phishing-delivered loader, an exploited edge device — discharges the obligation even if the underlying cause is still open.

The regulatory architecture is consistent about this. Point 3.6.1 of the Annex to Implementing Regulation 2024/2690 requires post-incident reviews to identify the root cause "where possible", and ENISA’s technical implementation guidance (version 1.0, June 2025) repeats the hedge in its own advice: conduct root cause analysis and identify the root cause "where possible". Belgium’s notification form asks for the threat type or root cause that "probably" triggered the incident. Nowhere does the EU demand certainty it knows you may not have.

That is a floor, not a ceiling. Where you can establish cause, the useful target is the systemic one. FIRST’s CSIRT Services Framework defines the function as identifying "the circumstances that allowed the exploited vulnerabilities to exist or that allowed the exploitation to succeed" — the weakness behind the weakness. NIST SP 800-61r3 makes the same distinction a high-priority recommendation: analyse the incident to find the "underlying or systemic root causes".

Most teams get there with an ordinary technique rather than a formal methodology — iterative "why" questioning to walk back from the proximate failure to the process that permitted it, or a cause-and-effect (fishbone) breakdown across people, process, technology and suppliers where several factors combined. Neither is prescribed by NIS2 or the Implementing Regulation; treat them as practitioner tooling, not compliance requirements. What the regulator sees is one field of prose, and the discipline that matters is calibration: write "likely" when it is likely, name the threat type when the cause is unresolved, and never present a working hypothesis as a finding.

What You Do Not Have to File

Published checklists for this stage commonly add a full indicator-of-compromise package, total financial cost, lessons learned, corrective-action plans and sector-wide recommendations. None of those appear in Article 23(4)(d). They are reasonable things to produce internally; they are not the filing.

Two national authorities make the point concretely. Germany’s BSI, in its #nis2know guidance on the reporting duty, lists the Abschlussmeldung contents as exactly the Directive’s four items and adds nothing — which is striking, because at the 72-hour stage the BSI does add national items, pulling forward detailed cause information, mitigation measures both taken and planned, and a law-enforcement cooperation question. Germany front-loads, then asks for nothing extra at the close. The BSI also states plainly that there is no documentation duty beyond the report itself, while recommending you document anyway for continuous improvement and audit preparation.

Belgium adds nothing either, but caps every mandatory free-text field on its form at 500 characters — including the incident description, the severity assessment and the root-cause field, at the final-report stage as much as at the first. The CCB’s guidance describes the same severity field three ways across the cascade: "very brief and/or partial" at early warning, an "initial" assessment at 72 hours, and "detailed" in the final report. "Detailed" there means detailed relative to the earlier filings and within 500 characters. It does not mean an attached forensic report.

One asymmetry is worth noting for planning purposes. Recital 102 — a recital, so interpretive rather than binding — asks Member States to ensure the reporting obligation does not divert resources from incident handling, but it says that about the early warning "or the subsequent incident notification". The protection stops before the final report. By one month, the Directive assumes response work is no longer competing with paperwork, so the final report is the one filing you are expected to resource properly.

For multi-jurisdiction operators the rule is unchanged from the earlier stages: the Directive is the floor, the national form is the deliverable.

The Post-Incident Review Is a Separate Duty on a Different Clock

The final report is a filing. The post-incident review is an internal control, and conflating them causes teams to miss both. Point 3.6 of the Annex to Implementing Regulation 2024/2690 requires entities, where appropriate, to carry out post-incident reviews after recovery, identifying the root cause where possible and producing documented lessons learned. Point 3.6.2 requires those findings to feed back into the risk assessment and risk treatment plan and to inform an assessment of whether existing risk-treatment measures actually worked. Point 3.6.3 requires a periodic check that incidents did in fact lead to reviews.

Scope caveat: the Implementing Regulation binds only the eleven digital-infrastructure and digital-provider categories named in its Article 1. For every other sector it is an interpretive reference, not a binding requirement — though the equivalent duty reaches you through Article 21(2)(b) incident handling, and ENISA maps point 3.6 to ISO 27001:2022 control A.5.27 if you need a certifiable anchor.

Note the timing collision. The review is triggered "after recovery"; the report is due one month after your 72-hour filing. For a long incident the report comes first, which is precisely why item (ii) is hedged and why Article 23(4)(e) exists. Run the review when recovery allows, and treat its output — ENISA’s named evidence includes root-cause analysis results, individual reports of the handling of significant incidents, and documented lessons learned — as the source material that makes a later filing or audit response straightforward rather than reconstructive.

If the Incident Is Still Open at One Month

Article 23(4)(e) covers this: where the incident is ongoing at the time the final report would fall due, you submit a progress report then, and the final report within one month of your handling of the incident.

Two cautions. First, the Directive specifies no content whatsoever for a progress report. Belgium fills the gap usefully — the progress report should contain as much of the information that belongs in the final report as the entity possesses at the time — but that is national guidance, not a legal content list. Germany takes a different route again, treating the continuation as simply another Folgemeldung rather than a distinct report type. Second, the Directive says the final report is then due within one month of "their handling of the incident", not of its resolution. Most commentary silently substitutes "resolution". The wording is genuinely ambiguous about whether handling ends at containment, at recovery, or at the close of the post-incident review, and we found no authoritative guidance resolving it — if your incident is heading that way, agree the trigger point with your competent authority rather than assuming.

Do not confuse either of these with the intermediate report at Article 23(4)(c), which several guides mislabel as the progress-report provision. The intermediate report is a different instrument entirely: it exists only when a CSIRT or competent authority requests it, it carries no deadline and no content list beyond "relevant status updates", and it is unrelated to whether the incident has run past a month. If you are asked for one, answer the question that was asked.

Who Owns What

The final report is the stage where ownership most often falls through the gap between the incident-response team standing down and the compliance function assuming the matter is closed.

Role	Owns	Effort
CISO / IR lead	Items (i)–(iii): the technical narrative, threat type or likely root cause, and the status of applied and ongoing mitigations.	High
Compliance officer	Computing the deadline from the 72-hour submission timestamp, confirming national field requirements, and filing.	Medium
Legal	Certainty calibration on cause and item (iv), plus checking whether parallel regimes (GDPR, sectoral, product) are also engaged.	Medium
Management body	Nothing statutory at this stage under Article 20(1), which ties liability to Article 21 measures — but the incident-handling process itself is one of those measures.	Low

A workable sequence: record the 72-hour submission timestamp the moment it is filed and diary the one-month date from it (low effort, highest value); draft items (i) and (iii) from the incident log rather than from memory (medium); resolve item (ii) to the highest defensible certainty and no further (medium); confirm or withdraw the cross-border flag raised at 24 hours (low); and decide by the three-week mark whether you are filing a final report or a progress report (low) — which leaves a week to assemble it rather than a day.

Frequently Asked Questions

Does the one-month clock run from the incident or from the 72-hour notification?
From the submission of the 72-hour notification, per the words "after the submission of the incident notification under point (b)". Filing that notification early therefore shortens your own final-report window.

Do I need a completed root cause analysis to file?
No. Article 23(4)(d)(ii) asks for the type of threat or the root cause that is likely to have triggered the incident. Naming the threat type satisfies it where the cause remains unresolved.

Is one month the same as thirty days?
Not under the EU’s general time-limit rules, which use the same date in the following month, shorten to the last day where that date does not exist, and roll a weekend or holiday expiry to the next working day. Because NIS2 is a Directive, confirm the computation under your national transposing law.

Can I withdraw or correct a report I have already filed?
Germany’s BSI states that a submitted report cannot be cancelled or withdrawn, but can be corrected or supplemented by a follow-up report. Check your own authority’s position, as this is a national procedural matter.

What happens if the incident is still ongoing?
You file a progress report at the one-month point under Article 23(4)(e), then a final report within one month of your handling of the incident. See our incident reporting overview for how this sits within the wider Article 23 framework, and the incident classification decision guide for whether an event was reportable in the first place.

Sources

• "NIS 2 Directive, Article 23: Reporting obligations" — primary-text mirror, Directive (EU) 2022/2555
• "Article 23, Reporting obligations" — NIS2 Resources, independent second verification of the Article 23(4) wording
• "NIS 2 Directive, Recitals 101 to 110" — Recital 102 (interpretive, non-binding)
• Directive (EU) 2022/2555 (NIS2) — official consolidated text, EUR-Lex
• "Technical Implementation Guidance on Cybersecurity Risk-Management Measures", version 1.0, June 2025 — ENISA (linked above)
• "#nis2know: NIS-2-Meldepflicht" — Bundesamt für Sicherheit in der Informationstechnik, Germany (linked above)
• "NIS2 Notification Guide", version 1.2, October 2024 — Centre for Cybersecurity Belgium (a version 1.3 has since been issued)
• Regulation (EEC, Euratom) No 1182/71, Article 3 — rules applicable to periods, dates and time limits
• "Incident Response Recommendations and Considerations for Cybersecurity Risk Management", NIST SP 800-61r3, April 2025 — NIST (linked above)
• "Computer Security Incident Response Team (CSIRT) Services Framework", version 2.1, section 6.2.4 — FIRST (linked above)

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.