DORA: Operational Resilience Requirements for Financial Entities

The Digital Operational Resilience Act applies a single set of ICT risk requirements across EU financial entities — banks, insurers, investment firms, payment institutions and others — and, significantly, brings critical ICT third-party providers under direct oversight.

Its premise is that financial stability now depends on technology resilience, and that supervising each entity individually misses the concentration risk created when hundreds of them depend on the same handful of providers.

The five pillars

ICT risk management requires a documented framework with governance, identification of ICT-supported functions, protection and prevention, detection, response and recovery, and learning. The management body is accountable and cannot delegate that away.

Incident reporting uses classification criteria to determine which incidents are major, with initial, intermediate and final reports on defined timelines. As with NIS2, the binding constraint is detection and decision speed rather than legal drafting.

Resilience testing requires a programme proportionate to the entity, including vulnerability assessments, scenario testing and, for significant entities, threat-led penetration testing conducted against live production systems using threat intelligence.

Third-party risk is the pillar with the most operational work.

Information sharing on cyber threats is encouraged among entities.

The register of information

Entities must maintain a register of contractual arrangements with ICT third-party service providers, covering the arrangements, the functions they support, and whether those functions are critical or important.

This is a substantial exercise for an entity with a long supplier list, and it is not merely a procurement record. It requires mapping which business functions depend on which providers, which most organisations have never documented.

That dependency mapping is the genuinely useful part. It answers the question an incident forces: if this provider goes down, what stops working?

Mandatory contractual terms

DORA specifies terms that must appear in contracts with ICT third-party providers, with additional requirements where the provider supports critical or important functions.

Exit strategies deserve particular attention. For critical functions you must be able to exit a provider without disproportionate disruption — which means having thought through where the function would go and how the data would move, before you need to.

Threat-led penetration testing

For entities in scope of TLPT, this is testing against production systems, using threat intelligence to model realistic adversaries, conducted by qualified testers under a defined framework.

It is closer to a red team engagement than a conventional penetration test, and it requires maturity to be worthwhile. Entities approaching TLPT for the first time should ensure their basics are genuinely in place, because the exercise is expensive and will otherwise report what a cheaper test would have found.

Oversight of critical providers

DORA establishes direct oversight of designated critical ICT third-party providers. For a financial entity, the practical implication is that some of your providers become supervised entities, which changes the dynamic of your negotiations with them — and does not transfer your own accountability.

Where to start

Build the register, and build it as a dependency map rather than a contract list. Which business functions depend on which providers, and which of those functions are critical. It satisfies the requirement and simultaneously answers the continuity question you would otherwise be unable to answer during an incident.

Concentration risk, which is the point of the regime

DORA exists partly because supervisors noticed that a large share of the financial sector depends on a small number of cloud and software providers. An outage at one of them is not an entity-level problem; it is a sector-level one.

Individual entities are expected to assess their own concentration exposure:

• Single-provider dependency for a critical function, with no tested alternative
• Hidden concentration, where several apparently independent providers all run on the same underlying platform
• Sub-contracting chains that converge on one point you never contracted with directly
• Regional concentration, where the failure domain is a single cloud region

The second and third are the ones entities miss, because the register records who you contracted with rather than who they depend on. Asking providers to disclose their own material dependencies is the only way to see it.

What to do in the first six months

1. Build the register as a dependency map, with criticality per function
2. Gap the mandatory contract terms against existing agreements, and prioritise the critical-function providers for amendment
3. Write exit strategies for critical functions — where the function would go, how data would move, how long it would take
4. Set incident classification criteria so the reporting decision is mechanical rather than debated
5. Assess concentration, including hidden and sub-contracted dependencies
6. Schedule resilience testing proportionate to your classification

Step three is the one with the longest lead time and the one most often deferred, because it requires an answer nobody wants to give.

GuardsArm supports operational resilience programmes and third-party risk assessment. See third-party risk management or book a scoping call.