Free NIS2 Incident Report Templates (2026) — 24h/72h/Final, Word

NIS2 Incident Report Templates: The Free Article 23 Pack

NIS2 Article 23 requires essential and important entities to report significant incidents in three timed stages — an early warning within 24 hours of awareness, an incident notification within 72 hours, and a final report within one month — each with mandatory content set out in Article 23(4)(a)–(e) of Directive (EU) 2022/2555. This free pack ships every stage as a ready-to-file Word form, plus an internal incident-register entry that feeds them all, with the Implementing Regulation (EU) 2024/2690 significance criteria built into the assessment fields.

Vendors sell exactly this document set, and national portals publish instructions but rarely reusable forms. Meanwhile the deadline that matters most — 24 hours from awareness, not from root-cause confirmation — is the one teams miss by drafting from a blank page mid-incident. This pack — available as DOCX forms, a PDF companion, and a machine-readable Markdown file for AI agents — is the operational counterpart to our guide on the 24-hour deadline and how to meet it, which explains the capability problem; this page gives you the artefacts that solve the drafting half of it.

Key Takeaways

• Three timed stages, one clock: early warning ≤ 24 hours, incident notification ≤ 72 hours, final report ≤ 1 month after the notification — all counted from when the entity becomes aware (Art 23(4)).
• The early warning is deliberately light: only whether the cause is suspected to be unlawful or malicious, and whether cross-border impact is possible. File it fast; Article 23(5) obliges the CSIRT to respond within 24 hours with guidance.
• "Significant" is now quantitative for digital entities: since 7 November 2024, Implementing Regulation (EU) 2024/2690 sets concrete triggers — €500,000 or 5%-of-turnover direct loss (whichever is lower), trade-secret exfiltration, recurring same-root-cause incidents, and per-service outage thresholds.
• The final report has four mandatory elements — detailed description with severity and impact, threat type or root cause, applied and ongoing mitigation, and cross-border impact — and an ongoing incident swaps in a progress report instead.
• The same forms serve Germany's BSI portal regime (NIS2UmsuCG, in force 6 December 2025), Norway's digitalsikkerhetsloven ladder, and — once enacted — the UK's proposed 24h/72h regime, because all three follow the same staged structure.

What's Inside the Pack

The DOCX contains five forms. Form 0 is the internal incident-register entry you complete at detection — awareness timestamp (this starts every clock), entity classification, significance assessment against Article 23(3) or the 2024/2690 criteria, and a report log for authority reference numbers. Forms 1–4 are the filings themselves: early warning, incident notification, intermediate/progress report, and final report, each with its Article 23(4) anchor printed on the form and guidance text in every field. The PDF mirrors the pack for print and tabletop exercises; the Markdown variant carries the full field structure with enums so an AI agent can draft each stage from your incident data.

Form	Deadline	Legal anchor	Mandatory content
1 — Early warning	≤ 24 h from awareness	Art 23(4)(a)	Suspected unlawful/malicious cause; possible cross-border impact
2 — Incident notification	≤ 72 h from awareness	Art 23(4)(b)	Update of early warning; initial severity and impact assessment; indicators of compromise where available
3 — Intermediate / progress	On authority request; or at one month if ongoing	Art 23(4)(c), (e)	Relevant status updates; expected timeline
4 — Final report	≤ 1 month after notification	Art 23(4)(d)	Detailed description with severity and impact; threat type or root cause; applied and ongoing mitigation; cross-border impact

How to Use It

Step 1 — Wire Form 0 into your incident process now, not during an incident. The register entry captures the awareness timestamp that starts the 24-hour clock, names the incident commander and reporting officer, and holds the significance assessment. Teams that decide who reports and through which portal account before an incident are the ones that make the deadline; our guide to incident response plans versus management systems explains why the plan alone is not the capability.

Step 2 — Assess significance against the right test. Start with Article 23(3)'s two limbs. If you are a DNS, TLD, cloud, data-centre, CDN, managed (security) service provider, online marketplace, search engine, social network or trust service provider, apply the quantitative criteria of Implementing Regulation (EU) 2024/2690 — any single Article 3 trigger suffices, and recurring incidents with the same apparent root cause aggregate across six months. When in doubt, remember Article 30 permits voluntary notification of incidents that do not meet the threshold.

Step 3 — File the early warning within 24 hours, thin. Two mandatory indications, a contact block, a two-sentence description. Do not wait for forensics: the notification at 72 hours is where the initial severity and impact assessment belongs, and the CSIRT's Article 23(5) response to your early warning may shape it.

Step 4 — Keep service recipients in the loop. Article 23 requires notifying recipients of services adversely affected by significant incidents and, for significant cyber threats, telling affected recipients about possible countermeasures — and authorities can order public disclosure. Form 2 carries a recipient-communication field so this is decided, not forgotten; a Trust Center gives those notices a permanent, linkable home.

Step 5 — Close with the final report and feed the lessons back. The four Article 23(4)(d) elements are mandatory; the pack adds a lessons-learned block that routes findings back into your Article 21 risk-management measures — the supply-chain and reporting duties NIS2 audits actually test.

Legal Basis

The forms map to Directive (EU) 2022/2555, Article 23: the significance test in Article 23(3), the staged reports and their content in Article 23(4)(a)–(e), the CSIRT's 24-hour response duty in Article 23(5), and recipient notification in Article 23(1)–(2). The significance-assessment fields incorporate Commission Implementing Regulation (EU) 2024/2690, which has applied directly since 7 November 2024 to DNS, TLD, cloud, data-centre, CDN, managed (security) service, marketplace, search, social-network and trust-service entities — its Article 3 cross-entity triggers and Articles 4–14 per-service thresholds turn "severe operational disruption" into numbers. Voluntary notification of sub-threshold incidents rests on Article 30 of the Directive. National transposition laws can add fields and shorten sector deadlines — which is a reason to over-structure your internal register, not under-structure it.

Beyond the EU: UK and Norway

In the UK, the Cyber Security and Resilience Bill — before Parliament with Royal Assent expected late 2026 — proposes replacing the single 72-hour NIS notification with a NIS2-style two-stage duty: an initial notification within 24 hours of becoming aware, and a full report within 72 hours, filed to the regulator with the NCSC informed in parallel. In Norway, digitalsikkerhetsloven has been in force since 1 October 2025 and already runs the same ladder — notification to NSM and the sector authority within 24 hours, an update within 72 hours, and an incident report within one month — while NIS2 itself awaits incorporation into the EEA Agreement, with a broader replacement law expected. A group operating across the EU, UK and Norway can therefore run one internal register and one form set for all three regimes; only the destination portal changes.

From Filing Under Pressure to Provable Readiness

Reporting on time proves the incident was handled; what supervisory authorities increasingly ask next is whether it was prepared for — tested response plans, supplier notification SLAs, evidence that the Article 21 measures existed before the breach. Orbiq's continuous monitoring keeps that evidence layer current — controls, supplier assurances, incident-readiness artefacts — and publishes the buyer-facing side to your Trust Center, so the same preparation that satisfies the regulator also answers the customer asking "were you affected?" If you are still mapping your obligations, start with our NIS2 directive guide; if your suppliers are the risk, pair this pack with the NIS2 supplier evidence request checklist.

---

Sources & References

1. Directive (EU) 2022/2555 (NIS2) — full text — Article 23(1)–(5), Article 30.
2. Commission Implementing Regulation (EU) 2024/2690 — significance criteria for digital-infrastructure and ICT-service entities; applicable since 7 November 2024.
3. UK Government — Cyber Security and Resilience Bill: incident reporting factsheet — the proposed 24-hour initial / 72-hour full report structure.
4. Lov om digital sikkerhet (digitalsikkerhetsloven) — Norway's framework, in force 1 October 2025.
5. ENISA — Technical Implementation Guidance on Cybersecurity Risk Management Measures — June 2025; incident-handling and reporting expectations.
6. Mayer Brown — Cyber rules for essential and important entities take effect in Germany — NIS2UmsuCG in force 6 December 2025; BSI reporting.

Related Reading

• NIS2 Incident Reporting: The 24-Hour Deadline and How to Meet It
• Incident Reporting and Supply-Chain Duties: NIS2 Articles 21–23
• Incident Response Plan vs Incident Management System
• NIS2 Compliance Checklist: Article 21 Measures
• NIS2 Supplier Evidence Request Checklist (free template)