What are DORA's incident reporting deadlines and communication duties?

DORA gives EU financial entities a clocked, three-stage reporting cascade for major ICT incidents — an initial notification, an intermediate report, and a final report to the competent authority — plus a duty to inform affected clients without undue delay and to maintain crisis communication plans that actually work mid-incident. Under the technical standards accompanying Article 19, the working assumptions are: initial notification within 4 hours of classifying the incident as major (and no later than 24 hours after becoming aware of it), intermediate report within 72 hours, final report within one month — but the forms, portal, and precise mechanics belong to your competent authority, so verify them there before an incident forces you to. This page turns those obligations into a checklist you can pre-stage.

The reporting cascade, stage by stage

DORA's Chapter III (Articles 17–23) requires an ICT incident management process: detect, classify (Article 18, against the criteria in the classification RTS — clients affected, duration, geographic spread, data losses, criticality, economic impact), and, for major incidents, report (Article 19).

• Initial notification. Filed fast, on a standard template, with what you know: when it started, what's affected, whether it's classified major, suspected cause category. Nobody expects root cause at this stage — they expect punctuality and honesty about uncertainty.
• Intermediate report. Status update: what changed, updated impact figures, actions taken. A further intermediate report is expected when status changes materially or the authority asks.
• Final report. The full account: root cause, actual impact against the classification criteria, remediation, and lessons. This is where your incident timeline and evidence trail either exists or gets reconstructed painfully.

Two often-missed extras: recurring significant incidents can be reportable in aggregate even when no single one is major, and entities may voluntarily report significant cyber threats. Both depend on you having classification data over time, not just per-incident heroics.

Communication duties beyond the regulator

Article 19(3) requires informing clients without undue delay when a major incident affects their financial interests — including what you're doing about it. Article 14 goes wider: communication policies and crisis communication plans covering staff, clients, counterparties, and (where relevant) the public, with designated spokespeople. In practice this means pre-drafted notification templates, current contact trees, and a channel that doesn't depend on the systems that just failed.

That last point is the one that fails in real incidents. If your IdP is down, your incident channel is behind SSO, and your client contact list lives in the CRM that's in scope of the outage, every deadline above is at risk simultaneously. DORA's testing regime — including threat-led penetration testing (TLPT) under Articles 26–27 for entities designated for it — is increasingly where this assumption gets exposed: a red team that takes out your identity provider also takes out your ability to coordinate, unless coordination is genuinely out-of-band.

Copy-pasteable incident communication checklist

Pre-stage everything in this list; during an incident you should be executing, not drafting.

# DORA Incident Communication & Reporting Checklist

## Before any incident (pre-staged)
- [ ] Classification criteria and thresholds (RTS 2024/1772) encoded in
      an assessment worksheet the on-call lead can complete in minutes
- [ ] Competent authority identified: [name], portal: [URL],
      out-of-hours channel: [phone/email], account access verified [date]
- [ ] Current report templates downloaded and pre-filled with entity
      static data (LEI, contacts, sector)
- [ ] Client notification templates drafted for [top 3 scenarios]
- [ ] Contact tree current: authority, board/management body, clients,
      counterparties, ICT third-party providers, PR/legal — verified [date]
- [ ] Out-of-band channel provisioned and drilled: reachable if
      SSO/IdP, email, and chat are ALL unavailable
- [ ] Credentials needed mid-incident (authority portal, DNS, cloud,
      status page) vaulted with quorum-controlled emergency access
- [ ] Roles named: incident classifier, report author, authority
      liaison, client comms owner, decision-maker for "is this major?"

## Hour 0–4 (detection → classification)
- [ ] Incident clock started; awareness time recorded: [timestamp]
- [ ] Classification worksheet completed; decision recorded with
      rationale (major / not major / re-assess at [time])
- [ ] If major: initial notification submitted within 4h of
      classification (≤24h of awareness); submission receipt saved
- [ ] Internal escalation completed per contact tree; acknowledgments
      tracked, non-responders escalated

## Hour 4–72
- [ ] Clients whose financial interests are affected notified without
      undue delay; log who, when, via which channel
- [ ] Counterparties / ICT providers notified where relevant
- [ ] Intermediate report submitted within 72h; delta from initial
      documented
- [ ] All comms and decisions logged with timestamps as they happen

## Day 3 → 1 month
- [ ] Further intermediate report(s) on material change or request
- [ ] Final report submitted within one month: root cause, impact vs
      classification criteria, remediation, lessons
- [ ] Post-incident review held; classification thresholds and this
      checklist updated with what broke

## Evidence to retain
- [ ] Submission receipts, classification worksheet, comms log,
      timeline, decision rationale — retained [x years]

Mapping the checklist to Glassbreak

Glassbreak is an end-to-end-encrypted break-glass platform, and the checklist's hardest items are exactly what it exists for:

• Out-of-band channel — Glassbreak runs on two independent cloud providers (AWS US and Scaleway EU Paris) with continuous replication, deliberately outside your corporate SSO blast radius, so the coordination layer survives the incident. An EU-only residency zone is in rollout for Enterprise customers on request; today data replicates across both the EU and US regions — factor that into your own data-classification decision.
• Contact trees and escalation — emergency messages go out over voice, SMS, and email with per-recipient acknowledgment tracking and escalation tiers, so "internal escalation completed, non-responders escalated" is a system behavior, not a task. Escalation trees when everything is on fire covers the design thinking.
• Mid-incident credentials — authority-portal, DNS, and status-page credentials sit in the vault under M-of-N quorum approval, so they're reachable in an emergency but never by one person quietly. See how DORA affects emergency access to ICT systems for the access-control side of DORA specifically.
• Playbooks and drills — the pre-staged checklist itself lives as a playbook next to the credentials it references, and drill scheduling exercises the notification path on a cadence — evidence for your testing regime, not just your conscience.
• Evidence to retain — the audit log captures who was notified, who acknowledged, and who approved access, with exportable evidence packs for the final report and for supervisory review.

If you also answer to NIS2, the cascades rhyme but differ — see the NIS2 incident handling and business continuity guide. For the certification-audit angle on the same emergency-access controls, see the ISO 27001 break-glass procedure guide, and for the underwriting angle, cyber-insurance questionnaire prep. Glassbreak's own DORA posture as a supplier is published at /trust/dora, and plans are per responder with recipients free — details on the pricing page.

This page summarizes DORA's reporting and communication obligations for planning purposes; it isn't legal advice, and the regulation, its technical standards, and your competent authority's current guidance govern your actual obligations.