Operational resilience is now something you must prove, not declare

For most of the last decade, a financial institution’s operational resilience was a narrative: a business-continuity binder, an annual tabletop, an attestation signed by someone two levels above the people who would actually restore the systems. That era is closing. Europe’s Digital Operational Resilience Act has been enforceable since January 2025, and its influence is visible far beyond the EU — in supervisory guidance across Canada, in the operational-risk expectations of African central banks, and in what institutional counterparties now ask each other before they connect.

The shift is simple to state and hard to live: resilience has moved from something you declare to something you must evidence. Supervisors increasingly want to see the test, not the policy — the actual recovery of the actual system, inside a tolerance the board has signed its name to.

The gap between the binder and the estate

When we run resilience-focused assessments for financial institutions, the recurring finding is not negligence. It is drift. The continuity plan describes an estate that existed three re-organizations ago. The critical-function map omits the vendor API that quietly became load-bearing. The recovery-time objective was set by a workshop, not by a measurement, and nobody has ever tried to hit it under realistic conditions.

None of this shows up in a document review. All of it shows up the first time you rehearse a severe-but-plausible scenario end to end — which is precisely why regulators are converging on testing as the unit of assurance.

Third parties are the hard part

The most uncomfortable provisions in every modern resilience regime concern third parties, because they name the real architecture of modern finance: a bank is now a thin institutional layer over cloud providers, core-banking vendors, payment processors, and data services. Mapping those dependencies honestly — including the fourth parties behind your third parties — is tedious, unglamorous work. It is also where most of the systemic risk actually lives, and where supervisors are directing their sharpest questions.

Institutions in emerging markets should not read this as a European problem. Concentration risk is more acute, not less, where a small number of processors and telcos carry an entire market’s payment volume. The regulatory language will arrive later; the dependency is already there.

What good looks like

The institutions handling this well share three habits.

First, they map critical business services rather than systems — payments, client onboarding, settlement — and trace each one through every system, vendor, and team it touches. The map is maintained like code, not like a report.

Second, they test at the level of the service. A backup that restores is not the same as a payment service that resumes within tolerance, with reconciliations intact, while the incident is still live.

Third, they treat detection as part of resilience. You cannot recover from what you have not noticed. A detection program whose rules have quietly decayed fails you twice — once when the intrusion goes unseen, and again when the post-incident review asks why.

What to do about it

Start with one critical service and rehearse its worst credible day: severed vendor, corrupted data, active adversary. Measure what actually happens against what the board believes happens. The distance between those two numbers is your real resilience posture — and closing it is far cheaper before a supervisor, or an incident, measures it for you.