DORA compliance,
explained plainly

DORA is the Digital Operational Resilience Act — Regulation (EU) 2022/2554. It sets a single, harmonized set of requirements for how financial entities across the EU manage the risk that their information and communication technology (ICT) fails, is disrupted or is attacked. The aim is plain: a bank, an insurer or a payment provider should be able to keep operating, and recover, when something in its technology stack goes wrong.

Two facts shape everything else. First, DORA is a regulation, not a directive — so it is directly applicable in every member state rather than transposed into 27 separate national laws. The text that applies to you is the EU text. Second, it has applied since 17 January 2025; this is not a future obligation to plan around but a live one.

It is also not a certificate. There is no DORA badge to hang on the wall and no accredited body that certifies you. DORA sets legal requirements you have to meet and be able to demonstrate to your supervisor — so the right framing is compliance and evidence, not certification.

DORA reaches across almost the entire EU financial sector. It covers banks and credit institutions, payment and electronic-money institutions, investment firms, insurance and reinsurance undertakings and their intermediaries, crypto-asset service providers, fund and asset managers, trading venues, and a long list of other regulated financial entities. If you are supervised as a financial entity in the EU, the working assumption is that DORA applies to you.

Crucially, it also reaches the ICT third-party providers that those entities depend on. The cloud platforms, software vendors and managed-service providers behind a regulated firm are pulled into scope through the contractual and oversight requirements — and the most systemically important of them are designated and supervised directly at EU level, which we cover further down.

DORA does apply proportionately. Smaller and less complex entities can meet a simplified ICT risk-management framework rather than the full set, and not every entity is required to run the most advanced testing. But proportionality narrows how much you do, not whether the regulation applies.

The first and foundational pillar requires a sound, comprehensive and well-documented ICT risk-management framework. This is the system that ties the other pillars together: identifying the ICT risks to your critical functions, protecting against them, detecting anomalies, responding and recovering, and learning afterwards. Everything else in DORA assumes this framework exists and is being run.

What sets this pillar apart from a generic security policy is accountability. DORA is explicit that the management body, the board or its equivalent, owns ICT risk. They approve the framework, set the risk tolerance, allocate the budget and stay informed; it is not a responsibility that can be quietly delegated to IT and forgotten. An auditor or supervisor expects to see that ownership reflected in real decisions and review cadence, not just a signature on a document.

In practice the framework has to cover the full lifecycle: an up-to-date map of ICT assets and the business functions they support, protective controls, continuous monitoring, tested business-continuity and disaster-recovery arrangements, and a process that feeds incidents back into improvement. The work is less about writing the framework once than about keeping it current and provably alive.

The second pillar is about what happens when something goes wrong. DORA requires a defined process to detect, manage, log and classify ICT-related incidents — and, for the ones that matter most, to report them to your competent authority. The point is to turn a scramble into a procedure: a known way to recognize an incident, judge how serious it is, and act.

Classification is the hinge. DORA sets criteria, things like the number of clients affected, the duration and the geographic spread of the disruption, and the data involved, that determine whether an incident counts as "major" and therefore triggers mandatory reporting. Getting the classification right under pressure is exactly the kind of thing a written, rehearsed process is for.

For major incidents, reporting runs on defined timelines: an initial notification once the incident is classified as major, an intermediate report as the picture firms up, and a final report once you understand the root cause. The deadlines are tight enough that the answer cannot be assembled from scratch each time — the entities that cope are the ones whose incident data, contacts and templates are already in one place.

The third pillar asks you to prove resilience rather than assert it. Every entity in scope must run a testing programme, covering vulnerability assessments, scenario-based testing, and reviews of the controls that protect critical functions, on a regular basis, and feed the findings back into the risk framework. Testing is how you find the gap before an incident does.

On top of that baseline, the most significant entities must carry out threat-led penetration testing, or TLPT. This is advanced, intelligence-led testing modelled on the TIBER-EU framework: realistic adversary scenarios run against your live production systems on a multi-year cycle, designed to test how you would actually hold up against a determined attacker. Not every entity is required to do TLPT, since supervisors identify which ones must, but where it applies it is a serious, scoped exercise, not a routine scan.

The thread running through this pillar is evidence. A supervisor does not want to hear that you test; they want to see the programme, the findings, the remediation and the proof that the loop closes. Keeping that record current is most of what the pillar asks of you between exercises.

The fourth pillar recognizes a simple reality: most financial entities run on technology they do not own. DORA therefore sets clear requirements for managing the risk of ICT third-party providers — from due diligence before you sign, through specific contractual terms the regulation insists be present, to monitoring and a credible exit strategy for the services that support critical functions.

The headline artifact here is the register of information. Every entity must maintain a structured register of all its contractual arrangements for ICT services: who the provider is, what they do, which functions they support and how critical those are. This register is not a private inventory; competent authorities can ask for it, and it feeds the EU-level view of where systemic concentration risk sits. The contractual terms DORA requires, on access, audit rights, sub-outsourcing, security and termination, have to be reflected in your agreements, which for many entities means renegotiating contracts that predate the regulation.

This is the pillar most likely to involve people outside your own walls, and the one where a current, accurate register pays off fastest. A register that is reconstructed from scattered contracts each time a supervisor asks is a recurring tax; one that is maintained as a living record is just a thing you keep up to date.

DORA does something unusual for financial regulation: it reaches past the regulated firms to the providers behind them. The largest and most systemically important ICT third-party providers, such as the major cloud platforms, can be formally designated as critical ICT third-party providers, or CTPPs, and placed under direct oversight at EU level by the European Supervisory Authorities (the ESAs).

For most financial entities this oversight regime operates above their own obligations rather than instead of them. You still have to manage your providers under pillar four; the ESA oversight of a designated CTPP is an additional layer that addresses the concentration risk of an entire market relying on a handful of the same providers. The practical consequence for entities is that the providers they depend on are themselves being scrutinized — and that your contractual and register obligations are part of how that EU-wide picture gets assembled.

DORA is often met by teams who already hold ISO 27001 or who are working through NIS2, and the relationship matters because the overlap is real but partial. ISO 27001 is a voluntary, certifiable management-system standard for information security in general; DORA is a binding, sector-specific regulation focused on operational resilience in finance. A strong ISO 27001 ISMS gives you a large head start on DORA, covering the asset inventory, the controls and the risk process, but it does not cover DORA-specific obligations like the incident-reporting timelines, the register of information or TLPT.

NIS2 is the other neighbour. It is the EU directive on cybersecurity across critical and important sectors, and where DORA applies to a financial entity, DORA generally takes precedence as the more specific regime for ICT risk. The two are designed to fit together rather than stack redundantly. The practical upshot for anyone running more than one of these is that the underlying work, knowing your assets, governing your providers, managing incidents, is largely shared, and the value is in maintaining it once rather than in three parallel binders.

Because DORA already applies, "getting ready" really means closing the gap between what you do today and what the regulation requires — and being able to evidence it. The usual starting point is a gap assessment against the five pillars: where is the ICT risk framework solid, where is incident classification undefined, is the testing programme real, and does a register of information actually exist and reconcile with your contracts.

The third-party pillar tends to surface the most work, because it touches agreements you do not fully control and a register most teams have never maintained as a single record. Build that register early — it is the artifact a supervisor is most likely to ask for, and the one that is most painful to reconstruct under time pressure.

Above all, DORA rewards a system you run, not a project you finish. The entities that find renewals and supervisory requests painless are the ones whose ICT risk framework, incident records, test results and provider register live in one place and stay current — so demonstrating compliance is a matter of pointing at what is already there.