DORA incident reporting: classification, deadlines and the ITS templates

What this solves

An ICT incident becomes a regulatory event the moment it is classified as major, and from that point the clock is not yours. The initial notification, the intermediate report and the final report each have a deadline, each has a template, and each asks for fields nobody collects unless the runbook told them to collect it at the time.

The gap is almost never the reporting form. It is that the technical response and the regulatory response run as two separate activities, and the second one starts hours late because the first one did not capture what it needed.

What is inside

• 5 incident-type runbooks with decision trees
• Major-incident classification decision tree
• ITS template walkthrough with worked example
• Full draft initial / intermediate / final reports
• 4-drill exercise kit (tabletop + functional)
• Post-incident review (PIR) template
• 12 KRIs for incident programme assurance

What it covers in the regulation

• Articles 17–23 — ICT-related incident management and reporting
• Article 18 — classification of major incidents
• Article 19 — reporting to the competent authority
• RTS (EU) 2024/1772 — classification criteria and materiality thresholds
• ITS — reporting templates and submission content

Who uses it, and when

Incident managers, SOC leads and the compliance officer who has to sign the report. Used while building the incident process — and kept beside the on-call runbook, because that is when it earns its price.

How to work through it

1. Run the classification criteria against your own thresholds and write down where your materiality lines sit.
2. Fold the five runbooks into your existing response process so the reportable facts are captured as they happen.
3. Walk the ITS template with the worked example to see which fields need a data owner.
4. Rehearse the deadline chain once, before you need it.

Related