Key takeaways
- DORA has applied across the EU financial sector since 17 January 2025. It is a regulation, so the same text applies directly in every member state.
- Its five areas — ICT risk management, incident reporting, resilience testing, third-party risk and information sharing — each need evidence that delivery work produces.
- Major incidents are reported in stages, starting within hours, so classification has to be quick, written down and rehearsed.
- The register of ICT third-party arrangements is a living record, not a spreadsheet built once for submission.
- Teams that already trace requirement to test to release decision hold most of the evidence. Teams that do not will assemble it by hand, every time.
What DORA is, and who it covers
The Digital Operational Resilience Act — Regulation (EU) 2022/2554 — entered into force in January 2023 and has applied since 17 January 2025. Because it is a regulation rather than a directive, it applies directly in every member state instead of being written into national law, which is why its requirements read the same in Frankfurt, Dublin and Paris.
It covers a wide range of financial entities — banks, insurers, investment firms, payment and e-money institutions and crypto-asset service providers among them — and, for the first time, brings the ICT third-party providers the sector depends on most under direct EU oversight.
Five areas, and where the evidence comes from
Read article by article, DORA looks like a compliance programme. Read from the delivery side, almost every obligation is answered by a record that engineering work either produces as it goes or has to recreate later.
| Area | What it asks | Where the evidence comes from |
|---|---|---|
| ICT risk management | A documented framework to identify, protect, detect, respond and recover, approved and overseen by the management body | Architecture records, change history, access reviews, recovery runbooks |
| ICT-related incident reporting | Classify incidents, and report major ones to the competent authority in stages | Monitoring, on-call records, a timestamped classification decision |
| Digital operational resilience testing | A risk-based testing programme, with threat-led penetration testing for the firms authorities identify | Test plans and results, linked to the systems and requirements they cover |
| ICT third-party risk | Contractual safeguards, and a register of information on every ICT third-party arrangement | Supplier inventory, contracts, dependency maps |
| Information sharing | Voluntary exchange of cyber-threat intelligence within trusted communities | Membership and handling procedures |
Incident reporting runs on a clock
Under the technical standards that accompany DORA, a major ICT-related incident needs an initial notification within four hours of being classified as major — and no later than 24 hours after the firm becomes aware of it — followed by an intermediate report and a final report.
The clock turns classification into a delivery problem. Someone has to be able to decide, quickly and defensibly, whether an incident crosses the thresholds, and the reasons have to be recorded. That is hard to do well at two in the morning without preparation.
- Write the classification criteria down and rehearse them against the clock, not just in a policy document.
- Put someone authorised to classify on the on-call rota, so the decision does not wait for office hours.
- Capture the incident timeline automatically from monitoring, alerts and chat, rather than reconstructing it afterwards.
- Link each incident to the change, release and requirement involved, so the root-cause section of the final report is a lookup, not an investigation.
Testing is a programme, not a penetration test
DORA expects a risk-based programme of resilience testing, proportionate to the firm, drawing on techniques such as vulnerability assessments, scenario-based tests, performance testing and source code review. Firms that authorities identify must also run threat-led penetration testing, at least every three years.
The habit that makes a programme defensible is tracing. When every test points at the system and requirement it covers, and every result is kept, the programme can show coverage — what has been tested and what has not — rather than a list of tools that were run.
The register of information is a living record
Every ICT third-party arrangement goes into a register of information that supervisors can request. The firms that struggle are those that build it once for a submission deadline and let it drift. Treat it like an architecture model: owned, versioned, and updated whenever a dependency changes — which means a new dependency should not ship without an entry.
What to put in place this quarter
Map critical functions to systems
Which services support which important business functions, and who owns each one.
Rehearse incident classification
Run a tabletop exercise against the reporting clock, and fix whatever slowed the decision.
Trace requirements to tests to releases
So resilience testing and change management produce evidence as a by-product of the work.
Tie the register to change management
A new or changed ICT dependency does not go live without its entry.