NIS2 incident report template: early warning, notification and final report

Below are three plain-text templates you can copy: one for the 24-hour early warning, one for the 72-hour incident notification and one for the final report. Each field maps to what Article 23 of NIS2 asks for, plus the practical fields any CSIRT will want.

Before you use these templates

NIS2 says what information each report must contain, but it does not prescribe one EU-wide form [1]. You submit through the channel your Member State sets, and national law may add fields. Use these templates to prepare your text, then copy it into the official form or portal. Prepare them before an incident and keep them where the on-call team can find them.

The fields marked in the templates as legal content come from Article 23(4) [1]. Fields such as contact details, reference numbers and "next update expected by" are practical additions, not legal requirements.

Template 1: early warning (within 24 hours)

The early warning must indicate, where applicable, whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact [1]. Keep it short: the aim is to alert the CSIRT and ask for help if you need it.

NIS2 EARLY WARNING
Entity name:
Sector / entity type (essential or important):
Contact person, phone, email:
Time we became aware (date, time, time zone):
Short description of what happened:
Services affected:
Suspected unlawful or malicious act? Yes / No / Unknown. Why:
Possible cross-border impact? Yes / No / Unknown. Which countries:
Assistance requested from the CSIRT? Yes / No. What:
Next update expected by:

Template 2: incident notification (within 72 hours)

The notification updates the early warning and gives an initial assessment of the incident, including severity and impact, and indicators of compromise where available [1].

NIS2 INCIDENT NOTIFICATION
Reference of early warning (date, time, ticket number):
Changes since the early warning:
Initial assessment
  Severity (what is down, degraded or exposed):
  Impact (users, customers, other persons, duration so far):
  Systems and locations affected:
Indicators of compromise (if available):
  IP addresses / domains:
  File hashes:
  Other:
Containment and mitigation so far:
Cross-border impact (update):
Next update expected by:

Template 3: final report (within one month of the notification)

The final report must contain a detailed description including severity and impact, the type of threat or root cause, applied and ongoing mitigation measures, and the cross-border impact where applicable [1]. If the incident is still ongoing at the deadline, you send a progress report instead and the final report within one month after handling the incident.

NIS2 FINAL REPORT
Reference of notification (date, time, ticket number):
1. Detailed description of the incident
   Timeline (detection, awareness, containment, recovery):
   Severity and impact:
2. Type of threat or root cause likely to have triggered it:
3. Mitigation measures
   Applied:
   Ongoing:
4. Cross-border impact (where applicable):
Lessons learned and follow-up actions:
Status: closed / still ongoing (if ongoing: this is a progress report)

Between the notification and the final report, the CSIRT or competent authority may ask for an intermediate report with relevant status updates [2]. You can reuse template 2 for that, with the heading changed.

Filled-in example: early warning

This example is invented. It shows the level of detail that is realistic at hour 4 of an incident.

NIS2 EARLY WARNING
Entity name: Example Water Services BV
Sector / entity type: drinking water, essential entity
Contact person: J. de Vries, +31 6 0000 0000, security@example.com
Time we became aware: 12 May, 07:30 CEST
Short description: Unauthorised access to the remote access gateway
  for pumping station telemetry. Gateway taken offline at 08:10.
Services affected: remote monitoring of 6 pumping stations. Water
  supply continues; stations are monitored on site.
Suspected unlawful or malicious act? Yes. Log-ins from unknown IP
  addresses using a valid service account.
Possible cross-border impact? No indication at this time.
Assistance requested from the CSIRT? Yes: analysis of the IP addresses.
Next update expected by: 13 May, 12:00 CEST

Notice what it does not contain: no root cause, no full impact figures, no blame. Those come later. What it does contain is the awareness time, the reason for suspecting a malicious act, and a clear statement about cross-border impact.

How to fill them in well

Use one timeline. Keep a single log of times in one time zone. Copy from it into each report, so the reports never contradict each other.
Say "unknown" when it is unknown. An honest "unknown, under investigation" is better than a guess you have to correct in the notification.
Separate facts from assessment. "The gateway was accessed with a valid account" is a fact. "Probably a stolen password" is an assessment. Label which is which.
Reference earlier reports. Each report should name the date, time and reference number of the one before it.
Keep a copy of what you sent. Save the exact text and the time of sending. The final report deadline is counted from the moment you submitted the notification [1].

Where to go next

If you are not sure the incident needs reporting at all, check the definition of a significant incident. For how the 24-hour, 72-hour and one-month clocks are counted, with a worked example, read NIS2 24-hour reporting explained. If you are deciding whether to handle this in-house or hand it to an outside firm, see spreadsheet vs tool vs consultant.

Related guides

Sources

This guide explains the rules in plain language. It is not legal advice. Check your own country's law and, when in doubt, ask a qualified adviser.