Anatomy of a DORA incident: from first signal to notification

DORA · Case study · June 2026 · 7 min read

The DORA clock does not start when you decide to report: it starts when you detect. What follows is an illustrative scenario (not a real client) of how a fintech walks a major incident from the first signal to the notification to its regulator, and where the manual process loses the hours the rule does not forgive.

The scenario

A payment institution detects a gateway degradation at 09:14: abnormal latency and a subset of rejected transactions. There is no certain root cause yet. The operational question is not "what failed?" but "is this a major incident for DORA purposes, and since when is the clock running?". The answer triggers notification obligations measured in hours.

Hour 0: detection and triage

DORA (Regulation (EU) 2022/2554) builds on the concept of an ICT-related incident. The first step is to record the detection time and open a case file. That timestamp is the origin of the count: if the timeline is not recorded from minute zero, reconstructing it later before the competent authority is guesswork, not evidence.

Is it a major incident? Classification

DORA requires notifying major incidents. The classification criteria (developed in the RTS) are not a hunch: they are assessable thresholds.

Criterion	What it measures
Clients and counterparties affected	Number and share of the total.
Duration and downtime	Time of degraded or unavailable service.
Geographical spread	Reach across other Member States.
Data losses	Integrity, availability or confidentiality compromised.
Criticality of services	Impact on essential or important functions.
Economic impact	Associated costs and losses.

Classification is not a later formality: it is the decision that starts the notification clock. And it must be justifiable with the data behind it.

The regulatory clock

Once classified as major, DORA structures the notification in three deliveries, each with its window:

Delivery	Indicative window
Initial notification	In the first hours after classification as major (and within the maximum window from detection).
Intermediate report	On service restoration or as the incident evolves.
Final report	When the root-cause analysis closes, within the one-month window.

The deadline runs from detection, not from calm

The recurring mistake is to start documenting once the incident is under control. By then, the initial notification may be late. The count runs in parallel with the technical response, not after it.

Where the manual process breaks

In the scenario, the technical team is mitigating while someone, in parallel, tries to gather the data to classify and draft. That is where the cracks appear:

Failure point	Consequence
Scattered timeline	The detection timestamp is not defensible.
Classification by eye	No traceability of which threshold was crossed, and on what data.
Deadlines with no alarm	The initial-notification window is discovered too late.
Manual reporting	Drafting under pressure multiplies errors and omissions.

The technical incident gets resolved. The regulatory defence of the incident does not.

What a system automates

Automation here does not replace judgement: it times it and documents it.

Timestamp at detection, with a case file open from minute zero.
Classification scoring against the RTS criteria, with the data that justifies each threshold.
Deadline alarms anchored to the moments of detection and classification.
Pre-filling of the three deliveries with the timeline and root cause.
Immutable audit trail of who decided what and when.

The principle holds: the system times, the person decides

Classifying an incident as major and notifying the regulator is a human decision. The system guarantees that decision arrives on time and stays documented, not that it is taken on its own.

How BlueUPALM approaches the DORA incident cycle

Capability	Implementation
Detection	Incident opening with a timestamp from the first signal.
Classification	Assessment against the RTS severity criteria.
Deadlines	Tracking of the three deliveries anchored to detection and classification.
Reporting	Pre-fill of initial, intermediate and final notifications.
Audit trail	Immutable record of the timeline and decisions.

DORA 2026: a practical guide for financial entities — The full framework this scenario comes from.
SEPBLAC software: automate AML reporting without losing traceability — The same traceability principle applied to AML reporting.
DORA Calculator — Assess your DORA maturity in minutes.

Want to see the DORA incident cycle automated?

We will walk you through BlueUPALM's classification, deadline and notification flow with a scenario from your sector.

→ Request a demo

→ Back to the blog · See the BlueUPALM product

Anatomy of a DORA incident: from first signal to notification ​

The scenario ​

Hour 0: detection and triage ​

Is it a major incident? Classification ​

The regulatory clock ​

Where the manual process breaks ​

What a system automates ​

How BlueUPALM approaches the DORA incident cycle ​

Related reading ​