DORA, explained: what it actually asks you to do
The Digital Operational Resilience Act has applied since January 2025. Five obligations, and the one that catches most firms out.
What DORA is
The Digital Operational Resilience Act is an EU regulation that sets a single standard for how financial entities manage information and communications technology risk. It has applied since 17 January 2025.
Because it is a regulation rather than a directive, it applies directly. There is no national implementation to wait for and no local variation to interpret, which is a meaningful difference from NIS2.
Scope is broad. It reaches banks, investment firms, insurers, payment institutions, crypto-asset service providers, trading venues and more, and it reaches the ICT providers those firms depend on.
The five pillars
ICT risk management. A governed framework, owned by the management body, covering identification, protection, detection, response and recovery. The management body is explicitly accountable, which is the part that changes board conversations.
Incident management and reporting. Classify ICT-related incidents against defined criteria and report major ones to your competent authority on a defined timetable. The work that makes this survivable is done before the incident, not during it.
Digital operational resilience testing. A programme of testing proportionate to your risk. For a subset of significant entities this includes threat-led penetration testing, which carries its own scope and provider requirements set by the regulator.
ICT third-party risk. Contractual requirements, oversight, exit strategies, and a register of information on all contractual arrangements with ICT providers.
Information sharing. Permitted and encouraged between entities on cyber threat information.
The register of information
This is the pillar firms consistently underestimate. It is not a vendor list. It is a structured record of every contractual arrangement for ICT services, at entity level, with the detail needed to understand which services support which functions and where concentration sits.
The difficulty is rarely the template. It is that the underlying information lives in procurement, in legal, in the CMDB and in several people memories, and none of those agree. Firms that treat the register as a reporting exercise rebuild it every submission. Firms that treat it as an operational record maintain it once.
What supervisors are actually asking
The pattern across the pillars is the same: show us that this operates. A policy describing a control and a control that demonstrably ran are different things, and DORA is written to close the gap between them.
That is why evidence generation matters more than documentation. If your evidence is produced by the act of operating, the supervisory conversation is a report you run. If it is assembled by hand for each review, it is a project you survive, and it will be out of date by the time it is finished.
Where to start
Map your important business services first, then the ICT and third parties each one depends on. Almost every DORA obligation resolves back to that map, and almost every firm that struggles has skipped it.
Whether and how DORA applies to your specific entities is a question for your counsel. We confirm applicability with you during onboarding rather than asserting it here.
Questions, answered
Does DORA apply to us if we are outside the EU?
Is threat-led penetration testing mandatory?
How does DORA relate to NIS2?
Where this goes next
Want this applied to your estate?
Tell us what you are protecting and where you feel exposed. We will map it to the right capabilities and set up a walkthrough.