DORA: Lessons from Year One

By Jonas Osman Abdelghafour.

A full cycle of incident reporting under the Digital Operational Resilience Act has produced a clear pattern: the binding constraint is rarely detection technology. It is the ability to classify an incident correctly, assemble accurate impact data, and file within tight deadlines while the incident is still being managed. Firms that struggled did so for organisational reasons, not technical ones.

Classification is the hard part

DORA's classification criteria — clients and counterparties affected, duration and service downtime, geographical spread, data losses, criticality of services impacted, and economic impact — are individually reasonable and collectively demanding under time pressure. Assessing them requires knowing which business services depend on the affected component, how many clients sit behind those services, and what the downtime actually was.

Firms with a maintained mapping from business services to applications to infrastructure answered in hours. Firms without one spent the reporting window rebuilding the map from tribal knowledge, which is both slow and unreliable. The most valuable investment coming out of year one is not tooling; it is a service-dependency map that is kept current as a control rather than refreshed for an audit.

The second classification lesson is about aggregation. Recurring incidents that individually fall below thresholds can become reportable when linked. That requires an incident record structured to identify root-cause commonality, which many ticketing systems do not support by default.

Timelines force a pre-built process

The staged reporting model — initial notification, intermediate report, final report — assumes that a firm can produce a defensible preliminary view quickly and refine it later. Two behaviours cause failure. The first is waiting for certainty before notifying; the framework does not ask for certainty at the initial stage. The second is a legal and communications review chain designed for considered disclosure rather than regulatory deadlines.

The remedy is boring and effective: templates pre-populated with static firm data, a delegated approver with authority to file out of hours, a named incident reporting owner separate from the incident commander, and a rehearsal in every major resilience exercise. Firms that ran their reporting process in a simulation before it was needed reported the smoothest first year.

The third-party register earns its cost

The register of information on ICT third-party arrangements was widely treated as a data-collection burden. It becomes an asset the moment an incident involves a provider, because it answers immediately which contracts, which services, which criticality, and which exit arrangements apply. The recurring data-quality problems were unsurprising: inconsistent entity identifiers, subcontracting chains recorded only to the first tier, and criticality assessments that were inherited rather than assessed.

Fourth-party concentration is the risk this exercise exposes and few firms have addressed. Multiple providers resting on the same cloud region or the same identity provider is a single point of failure that per-vendor assessment cannot see. The analysis has to be run across the register, not within each entry.

Testing that produces findings worth having

Resilience testing under DORA is only useful when scenarios are severe and plausible: loss of a critical provider, corruption rather than merely unavailability of data, and a compromise of the very tooling used to respond. Threat-led penetration testing for the firms in scope should target business services, not just infrastructure. Findings should be tracked to closure with the same discipline as validation findings, and the recovery-time assumptions used in resilience planning should be tested rather than asserted.

Priorities for year two

• Maintain the service-to-asset dependency map as a live control with an owner.
• Automate the extraction of classification data from monitoring and CRM sources.
• Delegate filing authority and rehearse the reporting path out of hours.
• Clean the third-party register and analyse concentration across it, including subcontractors.
• Test data corruption and provider-loss scenarios, and validate stated recovery times.
• Report resilience posture to the board in business-service terms, not system counts.

DORA's underlying question is whether a firm can keep delivering critical services through disruption. The reporting regime is simply the mechanism that makes the honest answer visible.

Primary sources: Regulation (EU) 2022/2554 (DORA) and related RTS/ITS on incident classification, reporting and the register of information; EBA Risk Assessment Report, June 2026.