CASP ICT Incident Reporting Under DORA — 4h/72h Deadlines 2026

The three-stage reporting framework

DORA Articles 17-23 establish a three-stage reporting cadence for major ICT-related incidents. Each stage has a specific deadline, a specific content threshold, and a specific operational discipline that gets it filed on time. Operators that build proper workflow hit the deadlines without strain. Operators that improvise face missed deadlines and Article 109 exposure.

Stage 1 — Initial notice, 4 hours from detection. Minimum-content report identifying the incident, the affected systems, the initial customer-impact estimate, and the response actions in progress. Short, fast, factual. The purpose is to get the supervisor informed quickly so they can start their own coordination.

Stage 2 — Intermediate report, 72 hours from the incident. Progressive-detail report covering everything known at the 72-hour mark. Root-cause hypothesis. Confirmed customer impact. Containment status. Recovery timeline. The supervisor uses this report to assess whether further regulatory action is needed.

Stage 3 — Final report, 1 month from incident resolution. Substantive deliverable with full root-cause analysis, lessons-learned framework, remediation actions completed and scheduled, framework-improvement actions. This report closes the matter from a regulatory perspective when it’s substantive.

The deadlines are calendar-time, not business-hours. Incidents that start at 11 pm on Friday have a 4-hour clock running through Saturday morning. The operational implication: 24/7 incident-response capability is required.

What counts as a major incident

The Joint ESAs RTS on incident classification sets thresholds across seven dimensions. An incident is major if it crosses the threshold on any one:

• Affected clients. Materially affected client count or percentage of total clients.
• Data lost. Volume or sensitivity of data lost, leaked, or modified.
• Financial impact. Direct financial loss to the operator, clients, or counterparties.
• Geographic spread. Number of member states or regions affected.
• Duration of unavailability. Hours or days of service downtime.
• Reputational impact. Media coverage, social-media volume, customer-complaint spike.
• Effect on critical or important functions. Disruption to specific defined operational functions.

The RTS thresholds are calibrated by operator size. A 10,000-customer operator and a 10-million-customer operator face different absolute thresholds but similar relative thresholds. The discipline is to know your operator’s specific thresholds and apply them consistently.

The 4-hour clock — what the operations team needs

Hitting the 4-hour initial-notice deadline requires three things in place before any incident starts.

Detection and classification workflow. Monitoring needs to detect incidents reliably and route them through a classification process that determines major vs non-major status quickly. Detection is necessary but not sufficient — the classification decision is what starts the clock. Most major-CASP operations run a duty-officer rotation that handles classification 24/7.

Pre-built initial-notice template. The NCA submission isn’t drafted from scratch in the middle of an incident. The template is pre-built, with placeholder fields for incident-specific detail. The duty officer fills in the placeholders during the incident and submits. Drafting from scratch under time pressure produces errors.

Submission infrastructure. The home-state NCA usually accepts incident reports via secure portal or email to a specific address. The infrastructure needs to be tested before incidents happen — credentials in place, submission process documented, fallback channels available. Operators that test submission infrastructure during incidents discover problems at the worst possible time.

The 72-hour intermediate report

The intermediate report is substantially heavier than the initial notice. At 72 hours, the operator typically has identified the root cause hypothesis, contained the incident, confirmed customer-impact extent, and started remediation. The intermediate report documents what’s known and what’s still unknown.

Standard content elements:

• Updated incident description with technical detail
• Confirmed root-cause hypothesis with supporting evidence
• Confirmed customer-impact figures (affected count, financial impact, data-impact extent)
• Containment status — what was done to stop ongoing impact
• Recovery status — what’s been restored, what’s still degraded
• Timeline of incident from detection through current state
• Communication actions — what’s been told to customers, counterparties, media
• Forward plan to final report — what’s still being investigated

NCAs use the intermediate report to assess whether the operator has the incident under control or whether further regulatory engagement is needed. Reports showing competent containment and clear forward plan typically don’t trigger follow-up; reports showing inadequate containment or unclear forward plan typically do.

The final report — substantive deliverable

The 1-month final report is the closing document that closes the matter. The content threshold is higher than either earlier report.

What a substantive final report contains:

• Definitive root-cause analysis with supporting evidence
• Full customer-impact quantification including any remediation paid to affected customers
• Lessons-learned framework identifying systemic factors that contributed to the incident
• Remediation actions completed — what’s been fixed
• Remediation actions scheduled — what’s in progress with milestones
• Framework improvements — what changes in operational procedures, monitoring, or infrastructure
• Internal-audit recommendations and management responses
• Board-level engagement record showing senior-management awareness

Operators that file thin final reports treating the 1-month deadline as the only consideration face NCA follow-up requests. The substantive final report typically closes the matter; the thin one keeps the supervisory engagement open for 3-6 additional months.

Enforcement patterns through 2025-2026

DORA went operationally binding on 17 January 2025. The first 18 months of operational experience reveal supervisory patterns.

NCAs have prioritised enforcement against:

• Missed 4-hour deadlines where the operator’s incident-management workflow failed to classify and submit within the window
• Under-classification of borderline incidents identified through pattern analysis across multiple reported events
• Thin final reports that fail the substantive-deliverable test
• Inadequate timestamping of detection, classification, and submission moments
• Missing fallback infrastructure discovered when primary submission channels failed during incidents

Fines under Article 109 in DORA-related enforcement have ranged EUR 100,000 to EUR 5 million depending on operator scale and violation pattern. The largest fines have been for repeat-pattern violations rather than single-incident failures.

The supervisory message: NCAs use DORA reporting actively. Operators with mature incident-response infrastructure operate without enforcement risk; operators that improvise face supervisory engagement.

Operational compliance build

For operators building DORA incident-reporting compliance:

24/7 duty-officer rotation with documented escalation paths and classification authority.

Incident-classification framework mapped to RTS thresholds for the specific operator profile, with documented decision-tree logic.

Pre-built submission templates for initial notice (4h), intermediate report (72h), and final report (1m), each with placeholder fields.

Submission infrastructure tested before incidents, with documented credentials, fallback channels, and backup contacts at the NCA.

Timestamping discipline with reliable logging of detection, classification, and submission moments across the workflow.

Final-report drafting workflow that builds substantive deliverables rather than treating the 1-month deadline as the only consideration.

Internal-audit cycle testing the incident-response workflow periodically with tabletop exercises and red-team scenarios.

Board-level oversight with regular reporting on incident-response readiness and any actual incidents.

The full build cost for DORA incident-reporting compliance: EUR 200,000-500,000 in Year 1 for a mid-tier CASP, EUR 100,000-300,000 ongoing annually. Operators with mature pre-existing ICT incident-management infrastructure face lighter incremental cost; operators starting from venture-stage practices face the heavier end.

The deadline matters more than it looks

DORA’s 4-hour deadline is the strictest incident-reporting clock in EU financial-services regulation. It exists because crypto-asset and broader fintech operational risk has the speed characteristics that traditional financial-services regulation didn’t anticipate. The supervisor needs to know fast because the impact can spread fast.

For operators building DORA compliance into broader MiCA readiness, the incident-reporting framework is among the most operationally demanding components. The 4-hour discipline can’t be retrofitted reactively after an incident — it requires mature pre-existing infrastructure. The 72-hour and 1-month deliverables can’t be improvised under pressure — they require trained teams and pre-built workflows.

Build it before you need it. The operators that hit the deadlines clean are the ones that planned for them.