nexalign
← Alle Insights
Regulatorik·10 min read

DORA 24-hour initial notification: what really has to be in it

The DORA reporting cascade has been live since 17 January 2025: 24-hour early warning, 72-hour intermediate report, one-month final report. In practice, financial entities fail less on the technology and more on the question of who signs off what in what format. Here is a practical guide for the 24-hour initial notification.

When the 24-hour clock starts

The clock starts at internal classification of the incident as a 'major ICT-related incident' under DORA Art. 18. Not at the first anomaly, but at the classification decision.

Thresholds are specified by Delegated Regulations: number of affected clients, duration, geographic spread, data integrity, critical services, economic impact. Hitting at least one threshold is enough.

In practice: the SOC needs a clear escalation matrix and a designated classifier (typically CISO or IT risk lead) who makes and documents the call.

Mandatory fields in the initial notification

Identification of the reporting entity (name, LEI, supervisor ID).

Date and time of incident detection and classification.

Short description: affected systems, services, business areas.

Initial root cause assessment (technical, human, third-party, unknown).

Number of affected clients or estimate.

Immediate measures already taken.

Contact for follow-up (person, email, phone, 24/7 reachable).

What should not be in the initial notification

Unbacked speculation about root cause. Better 'unknown, under analysis' than a theory that has to be withdrawn later.

Damage figures that have not been quantified. At the 24h mark this is usually not possible.

Blame against third parties without forensic evidence.

Data covered by trade secret and not legally required.

Trail documentation

Supervisors expect an unbroken escalation trail: who decided what, when, with which sources available.

Recommendation: a single incident memo with timestamps, decisions, sign-offs. Exactly the structure DecisionOS produces for procurement decisions.

The memo serves two purposes: regulatory reconstruction for the auditor, organisational learning for the next TLPT exercise.

Most common failure modes

Notification too late: classification by consensus rather than by a designated owner.

Notification too early: every incident reflexively reported even when no threshold is hit. Causes supervisor fatigue and creates a poor capability signal.

Notification incomplete: contact not actually 24/7 reachable.

Notification inconsistent with the 72h follow-up: initial numbers were guesses.

Preparation: tabletop and trail template

Whoever runs the process for the first time in a real incident, fails. DORA Art. 25 already requires operational resilience testing. At least a half-yearly tabletop with a real stopwatch, including classification, notification, trail documentation. Template and mandatory fields must live in an audit-grade tool, not in a spreadsheet.