---
name: "NIS2 Incident Report Templates — Article 23 Pack"
version: "1.0"
updated: "2026-07-14"
source: "https://www.orbiqhq.com/templates/nis2-incident-reporting-pack"
license: "Free to use; attribution appreciated"
legal_basis:
  - "https://eur-lex.europa.eu/eli/dir/2022/2555/oj"
  - "https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj"
---

# NIS2 Incident Report Templates — Article 23 Pack

All stages of NIS2 significant-incident reporting as structured forms: the
24-hour early warning, the 72-hour incident notification, the intermediate /
progress report, and the one-month final report, mapped to Article 23(4)(a)–(e)
of Directive (EU) 2022/2555. An AI agent or an incident commander can run the
full reporting sequence from this file alone: (1) open a register entry at
awareness, (2) file the early warning within 24 hours, (3) file the incident
notification within 72 hours, (4) answer authority requests with intermediate
reports, (5) file the final report within one month — or a progress report if
the incident is still ongoing.

## 1. Trigger test — is the incident "significant"?

Article 23(3): report when the incident (a) has caused or is capable of causing
severe operational disruption of the services or financial loss for the entity,
or (b) has affected or is capable of affecting other natural or legal persons
by causing considerable material or non-material damage.

For DNS providers, TLD registries, cloud, data-centre, CDN, managed service /
managed security providers, online marketplaces, search engines, social
networks and trust service providers, Commission Implementing Regulation (EU)
2024/2690 (applicable since 7 November 2024) adds quantitative criteria.
Article 3 cross-entity triggers (any ONE suffices):

- `financial-loss` — direct financial loss > EUR 500,000 or > 5% of prior-year
  annual turnover, whichever is lower
- `trade-secret-exfiltration`
- `death-of-natural-person`
- `considerable-damage-to-health`
- `malicious-unauthorised-access` capable of causing severe operational
  disruption
- `recurring` — ≥2 incidents with the same apparent root cause within 6 months
  that collectively cross the financial-loss threshold

Plus per-service thresholds in Articles 4–14 (e.g. DNS resolution unavailable
> 30 minutes; average DNS response > 10 seconds for > 1 hour; integrity broken
for > 1,000 domains or 1% of the portfolio).

## 2. The reporting ladder (deadlines from awareness)

| Stage | Deadline | Anchor | Mandatory content |
|---|---|---|---|
| `early-warning` | ≤ 24 h | Art 23(4)(a) | suspected unlawful/malicious cause (`yes\|no\|unknown`); possible cross-border impact (`yes\|no\|unknown`) |
| `incident-notification` | ≤ 72 h (trust service providers: ≤ 24 h) | Art 23(4)(b) | update of early warning; initial assessment of severity and impact; indicators of compromise where available |
| `intermediate-report` | on authority request | Art 23(4)(c) | relevant status updates |
| `final-report` | ≤ 1 month after incident notification | Art 23(4)(d) | detailed description incl. severity and impact; type of threat or root cause; applied and ongoing mitigation; cross-border impact where applicable |
| `progress-report` | at final-report due date if incident ongoing; final report then ≤ 1 month after handling ends | Art 23(4)(e) | as intermediate, plus expected timeline |

Note: Article 23(5) obliges the CSIRT/competent authority to respond to the
early warning within 24 hours, including guidance and, on request, technical
support. Article 23(1)–(2): recipients of services must be notified of
significant incidents that adversely affect them and of significant cyber
threats with possible countermeasures; authorities may order public disclosure.
Article 30 allows voluntary notification of non-significant incidents and
threats.

## 3. Form fields

### Form 0 — incident register entry (internal, at detection)

```yaml
incident_id: ""            # e.g. INC-2026-041
entity:
  name: ""
  classification: ""       # essential | important; Annex I/II sector
  authority_registration: ""
incident_commander: ""     # name, role, 24/7 contact
reporting_officer: ""
awareness_at: ""           # ISO datetime with timezone — starts the 24h clock
detection_source: ""       # monitoring | employee | customer | third-party | authority
affected_services: []
significance:
  basis: ""                # art23-3-a | art23-3-b | cir-2024-2690 criterion id
  reasoning: ""
cross_border: ""           # member states / entities potentially affected
report_log: []             # {stage, submitted_at, channel, authority_reference}
```

### Form 1 — early warning (≤ 24 h)

Required: `entity`, `contact`, `awareness_at`, `brief_description` (2–4
sentences), `affected_services`, `malicious_suspected: yes|no|unknown` (+ one
line of reasoning), `cross_border_possible: yes|no|unknown` (+ Member States if
known). Optional: `assistance_requested: yes|no`, `contained: yes|no`.

### Form 2 — incident notification (≤ 72 h)

Required: `early_warning_reference`, `changes_since_early_warning`,
`severity_assessment` (scope, users/recipients affected, duration),
`impact_assessment` (operational, financial estimate, CIA effects),
`iocs` (where available), `significance_criteria_met`,
`mitigation_taken`, `cross_border_update`, `recipient_communication`
(whether service recipients informed per Art 23(1)–(2)).

### Form 3 — intermediate / progress report

Required: `reference`, `trigger` (`authority-request` | `one-month-ongoing`),
`status_update`, `updated_impact`, `new_findings`, `next_steps_timeline`.

### Form 4 — final report (≤ 1 month after Form 2)

Required (all four are mandatory under Art 23(4)(d)):

1. `detailed_description` — narrative timeline, final severity and impact
   figures
2. `threat_and_root_cause` — threat type; likely triggering root cause
3. `mitigation` — applied and ongoing measures, with owners and dates
4. `cross_border_impact` — where applicable

Recommended: `lessons_learned` — preventive changes feeding the entity's
Article 21 risk-management measures; review of whether the 24h/72h clocks held.

## 4. Where to file

- **Germany:** BSI reporting portal (Melde- und Informationsportal);
  NIS2UmsuCG in force since 6 December 2025 (24h / 72h / 1 month).
- **Norway:** NSM + sector authority under digitalsikkerhetsloven (in force
  1 October 2025): notification ≤ 24 h, update ≤ 72 h, report ≤ 1 month. NIS2
  itself is not yet incorporated into the EEA Agreement as of mid-2026.
- **UK:** the Cyber Security and Resilience Bill (before Parliament, Royal
  Assent expected late 2026) proposes a 24-hour initial notification and a
  72-hour full report to the regulator, with the NCSC informed in parallel.
- Other EU Member States: your national CSIRT / competent-authority portal;
  check the transposition status and sector-specific channels.

---

Formats: DOCX (five ready-to-file forms) + PDF (print/review companion) at
https://www.orbiqhq.com/templates/nis2-incident-reporting-pack. National
transposition laws may add fields or shorter sector deadlines. Not legal
advice.