← All writing
GRCRiskSecurity

Preparing for DORA: Operational Resilience for the Financial Sector

· 7 min read

For years, regulators treated technology risk in financial services as a subset of operational risk, something to be noted, capitalised against and largely left to the IT department. The Digital Operational Resilience Act, or DORA, ends that arrangement. It treats the ability of a financial firm to withstand and recover from ICT disruption as a board level concern in its own right, with prescriptive requirements behind it.

DORA is Regulation (EU) 2022/2554, and it has applied since 17 January 2025. If you work with banks, insurers, investment firms, payment institutions, crypto asset service providers or a long list of other regulated entities operating in the EU, it applies to you, and importantly it reaches into your critical technology suppliers as well. Once you see the structure, it is far less intimidating than the page count suggests.

Why DORA is different

DORA harmonises rules that already existed in fragments across member states and sectors. Before it, a bank in one country and an insurer in another could be held to quite different expectations on incident reporting or resilience testing. DORA replaces that patchwork with a single regulation, and it makes the management body, the board, explicitly accountable. You cannot delegate DORA compliance down to a managed service provider and consider the matter closed. The accountability stays at the top.

It is built on five pillars, and almost everything in the regulation hangs off one of them.

1. ICT risk management

This is the foundation. Firms must maintain a documented ICT risk management framework that covers the full lifecycle, identifying assets and dependencies, protecting them, detecting anomalies, responding, and recovering. None of this is novel to anyone who has run an information security programme, but DORA wants it formalised, owned by the management body, and reviewed regularly rather than treated as an annual document.

If you already run an ISMS aligned to ISO 27001, you have a substantial head start here. The vocabulary differs but the spirit is the same.

2. ICT incident management and reporting

DORA requires you to detect, manage, classify and report ICT related incidents on a defined basis. The classification piece matters more than people expect, because the regulation sets criteria for what counts as a “major” incident, and major incidents carry mandatory reporting timelines to your competent authority.

In practice this means your incident process needs to do two things it may not do today. It needs to consistently classify incidents against DORA’s criteria, and it needs to produce initial, intermediate and final reports within the windows the regulation specifies. Reporting after the fact, in your own format, on your own schedule, is no longer enough.

3. Digital operational resilience testing

You have to test your resilience, not just assert it. For most firms this means a programme of vulnerability assessments, scenario testing and reviews carried out at least annually. For the larger, more systemically important firms, it goes further into threat led penetration testing, TLPT, which is intelligence driven red teaming against live production systems, conducted to a defined standard.

Testing is where resilience claims meet reality. A recovery plan nobody has rehearsed can fall apart the day you actually need it, and DORA wants evidence that yours holds up. The testing pillar is how you produce that evidence.

4. ICT third party risk management

This is the pillar that catches people out, and in my view it is the centre of gravity of the whole regulation. Modern financial firms run on third parties, cloud platforms, core banking providers, data vendors, and DORA holds you responsible for the resilience of those dependencies.

Concretely, you are expected to maintain a register of information describing all your ICT third party arrangements, to ensure contracts contain specific provisions around access, audit, subcontracting, exit and incident cooperation, and to manage concentration risk, the danger of too much of the sector depending on too few providers. DORA also introduces an oversight regime in which providers designated as critical ICT third party providers are supervised directly by the European Supervisory Authorities.

If you do one thing first, build the register honestly. Most firms discover they have more critical dependencies, and weaker contractual protections around them, than they assumed.

5. Information sharing

The lightest pillar, and a voluntary one. DORA encourages financial entities to share cyber threat intelligence among themselves within trusted communities. The logic is straightforward, the threats are shared, so the defence should be too. There is no penalty for not participating, but the regulation deliberately makes space for it.

Where I would start

If you are staring at this with a January deadline already behind you and a programme that is not yet where it needs to be, here is the order I would work in.

  • Map your ICT third party estate and build the register. Everything in pillar four depends on knowing what you actually rely on. This is also where contractual remediation takes longest, so start the clock early.
  • Align your incident classification to DORA’s criteria. You almost certainly have an incident process. The gap is usually classification and reporting timelines, not detection.
  • Confirm board ownership in writing. The management body’s accountability is not a formality. Make sure responsibilities are assigned, minuted and understood.
  • Stand up a testing calendar. Even a modest, documented programme of annual testing puts you ahead of where most firms start.

Closing thoughts

DORA is demanding, but it is not arbitrary. Read against the five pillars it is a coherent statement that a financial firm should know its technology dependencies, protect them, test them, recover from disruption, and answer for all of it at board level. Firms that already run a mature security programme will find much of this familiar in substance even where the documentation needs reshaping. The ones who struggle are usually those who outsourced heavily and assumed the resilience came bundled with the service. DORA’s clear message is that it does not. The risk, and the accountability, stay with you.