Resilience is now a regulated number: what DORA, the PRA and US third-party guidance mean for hybrid multicloud

For ten years the board question was "are we in the cloud yet?" In financial services it has changed. The question now is "prove you can lose one."

That shift did not come from a vendor. It came from regulators, on two continents, more or less at once.

Three regimes, one demand

EU: the Digital Operational Resilience Act (DORA). In force for banks, insurers and investment firms since January 2025. On 18 November 2025 the three European supervisors (EBA, EIOPA and ESMA) published the first list of critical ICT third-party providers. For the first time the large cloud providers are overseen directly as a source of risk to the financial system, not just as a line in each bank's vendor file.
UK: impact tolerances. The PRA's supervisory statement SS1/21, first published on 29 March 2021, asks firms to name their important business services and set a hard limit on how long each can be down. The transition period ran to March 2025. A tolerance is a number, and a number can be tested.
US: one third-party framework. On 9 June 2023 the Federal Reserve, the FDIC and the OCC replaced three separate sets of guidance with a single Interagency Guidance on Third-Party Relationships: Risk Management. It runs across the whole lifecycle, from due diligence through ongoing monitoring to termination, and termination is where cloud architecture comes in.

The wording differs. The demand is the same.

What the three have in common

Requirement	What it means in practice
Map the service, end to end	Not "the core banking app", but every dependency a payment touches, including the provider underneath
Set a tolerance	A maximum time down, and sometimes a maximum data loss, for each important service
Test severe but plausible scenarios	Including the loss of a provider or a region, not only a server
Manage concentration	Know where too much rides on one provider
Plan the exit	Be able to leave a provider without breaking the service, and show it

None of these is new as an idea. What is new is that each one now has to be evidenced.

What it does to cloud architecture

An exit plan is not a PDF. If the plan for leaving a provider is a document nobody has run, an examiner will treat it as exactly that. Portability has to be engineered in from the start, not promised at renewal time.

That pushes architecture in three directions:

The same controls on every cloud. If a workload moves and its controls do not, the move breaks compliance. That is the problem the industry's own standards body is working on: FINOS launched Common Cloud Controls in July 2023, starting from an approach Citi developed, to write security, resiliency and compliance controls once and apply them across the major providers. Control parity is now a resilience requirement, not a nice-to-have.
The same operating model on every cloud. Two clouds run by two teams with two toolchains is not resilience. It is two single points of failure. One platform layer that runs the same way on each provider is what makes a failover a procedure rather than a project.
Failover you can show on a schedule. Tolerances are tested, so failover has to be a regular, recorded event with the measured recovery time next to the tolerance it is meant to meet.

What that looks like when the controls are code rather than a spreadsheet:

Controls as code: written once, applied on every cloud, evidenced in one store

Failover measured against tolerance (illustrative numbers)

I wrote up one way to build this, active/active/standby across AWS, Azure and Google Cloud, in NC2 across AWS, Azure and Google Cloud. The pattern matters more than the product: one control plane, the same controls, and a failover that has actually been run.

Three questions I would put to any CIO

For your top three important business services, what is the tolerance, and when did you last measure recovery against it? If the answer is a date, good. If it is a document, that is the gap.
If your primary cloud provider became unavailable in your main region tomorrow, which services would breach tolerance first? If nobody can answer in a minute, the map is not finished.
Do your security and compliance controls move with the workload? If a failover drops you out of compliance, you have swapped one failure for another.

The short version

Resilience used to be a property you claimed. In financial services it is now a number you set, test, and defend to a supervisor, and the cloud providers themselves are now under the same lens. The firms that will find this easy are the ones whose platform, controls and operating model already look the same on every cloud they use.

This is my reading of public regulatory material, not legal or compliance advice. Check the primary texts and your own regulator's guidance before relying on any of it.

Sources: EBA/EIOPA/ESMA press release on the designation of critical ICT third-party providers under DORA (18 November 2025); Bank of England PRA, SS1/21 Operational resilience: Impact tolerances for important business services (first published 29 March 2021); Federal Reserve, FDIC, OCC, Interagency Guidance on Third-Party Relationships: Risk Management, Federal Register (9 June 2023); FINOS, announcement of the Common Cloud Controls project (27 July 2023) and ccc.finos.org.