A disaster-recovery plan answers a systems question: when the primary database fails over, how fast does it come back? Operational resilience answers a business question the board actually loses sleep over: how long can our customers be unable to do the thing they came to us for, and can we prove we stay inside that limit when several things break at once? Those are not the same question. The second one has quietly outgrown the runbook that used to answer the first.
I still see resilience treated as a folder — a DR plan, a BCP document, an RTO on a spreadsheet, a tabletop scheduled for the quarter. Each of those is real work. None of them is a program. A program starts from the service the customer buys and works inward. The runbook starts from the system you happen to run and works outward, and it almost never reaches the customer.
Here is the discipline I've come to believe in, borrowed openly from the way regulators in financial services now frame it.
Start with the service the customer buys, not the system you run
The first move is to stop inventorying systems and start naming business services. A business service is the thing a customer or a market relies on you to do, described from their side of the glass. In our world that is a member checking a credit score, a payment posting, an account opening, a lender receiving a decision. It is never "the auth service" or "the primary cluster." Those are components. The service is the outcome.
This reframing matters because failures don't respect your architecture diagram. A customer who can't open an account doesn't care whether the cause was the identity provider, a third-party KYC vendor, an expired certificate, or the one engineer who understood the batch job being on a plane. They experience one thing: the service is down. So you map the service the way they experience it — end to end — and you keep going until you've traced every person, process, system, data store, facility, and third party that stands between the customer and the outcome. The unit of resilience is the service. Everything else is a dependency of it.
Most teams have never drawn that map. They have architecture diagrams, which show systems, and org charts, which show people, and vendor lists, which show contracts, and no single artifact that shows how a real service actually gets delivered across all three. Drawing it is uncomfortable, because the first honest version has a lot of single points of failure that were invisible as long as you only looked at the technology.
Impact tolerances are a board decision, not an SRE metric
An RTO is an engineering target: how quickly a component should recover. An impact tolerance is a different animal. It is the maximum disruption to a business service the firm is willing to accept before the harm becomes intolerable — expressed in outcomes, not in minutes of a server being down. Harm to the customer. Harm to the firm. Harm to the market. The UK's operational-resilience regime coined the term, and it is the single most useful idea in the whole field.
The distinction is not pedantic. An RTO says "we aim to recover in four hours." An impact tolerance says "our customers cannot be unable to make a payment for longer than this, because past that point people miss obligations, the partner bank escalates, and the harm stops being recoverable." One is an aspiration owned by engineering. The other is a ceiling owned by the board, because only the board can weigh customer harm against the cost of the resilience it would take to prevent it.
That ownership is the part people get wrong. The tolerance is not something the platform team sets and reports upward. It is a decision the board has to take, which means my job — as the person who understands the dependency chain — is to frame that decision in terms a director can actually own, not in terms only an SRE can read. When I bring a tolerance forward, it has to say what breaks, for whom, and at what point, in plain language. A good impact tolerance has a few properties, and it is worth being strict about them:
- Expressed in customer or market harm, not system state. "Members cannot check their score for more than N hours" — not "the cluster is degraded."
- A hard ceiling, not a target. An RTO is what you aim for on a good day; a tolerance is the line past which the outcome is unacceptable on the worst day.
- Set for a severe-but-plausible scenario, not the happy path. The number only means something if it holds when several things fail together.
- Owned by the board and reviewed on a cadence, because the business changes, the customer base changes, and yesterday's tolerable outage is today's front-page incident.
Map the chain, then find the part that isn't yours
Once you've mapped a service end to end, the most revealing question is which parts of the chain you don't control. In modern fintech the answer is "most of it." Your KYC vendor, your card processor, your cloud region, your email provider, your data-enrichment feed, the subprocessor your vendor uses that you've never heard of — the fourth party in your third party's chain. Every one of them sits inside a service you're accountable for, and none of them reports to you.
This is exactly where DORA — the EU's Digital Operational Resilience Act, which has applied to financial entities since January 2025 — puts its weight. It requires a register of information on ICT third parties, it cares intensely about concentration risk and substitutability, and it stands up an EU oversight regime for the critical ICT third-party providers that half the industry quietly depends on. The insight underneath the regulation is simple: a dependency you can't replace is a risk you can't manage by testing your own failover. If a provider central to a service disappears for two weeks, the only questions that matter are whether the service can run without them and how fast you can move — and if the honest answers are "it can't" and "we can't," you don't have a resilience gap, you have a business decision the board hasn't been asked to make.
So substitutability becomes a first-class resilience control, and an exit plan stops being a procurement nicety and becomes part of how you stay inside tolerance. I'll add the part that's easy to forget when you serve regulated customers: you are also somebody's third party. Serving more than 1,500 financial institutions means we sit inside their resilience chains, and their subprocessors are our fourth parties. The discipline runs in both directions — I have to be substitutable enough that my customers can survive me, and I have to know my own chain well enough that I can survive my vendors.
Test to failure, not to the runbook
A warm-standby failover you've actually rehearsed, a ransomware recovery from backups you've genuinely restored, a tabletop that surfaced a real gap — those are all necessary, and I've argued for each of them elsewhere. They are also all tactical. Each one proves a single control works in isolation. None of them tells you whether the service your customer buys stays inside the limit the board committed to when three of those controls fail on the same afternoon.
Program-level testing is different in its aim. You are not verifying that a failover succeeds. You are testing whether an important business service stays within its impact tolerance under a severe-but-plausible scenario that spans people, process, and third parties at once — because that is how real incidents arrive. The scenario should combine failures on purpose: the primary region degrades, and the one person who knows the manual workaround is unreachable, and the third party you'd normally lean on is having their own bad day. Test the human chain, not just the technical one — key-person risk is a resilience finding, not an HR footnote. Test the process chain — that manual fallback everyone points to usually assumes a system that is also down in the same scenario. DORA formalizes this into a testing pillar, up to threat-led penetration testing for the largest firms, but the mindset doesn't wait for a mandate.
And the output of a real test is never a green checkmark. It is a list of the points where the service crossed its tolerance, each with an owner and a date — the same discipline you would apply to any audit finding. A test that everything passed is a test that wasn't severe enough. You are trying to find the breakage now, on a quiet Tuesday, on your own terms, instead of during the incident on the regulator's terms.
Resilience is a supervised expectation now, not a nice-to-have
The reason this reads like a compliance program is that it is becoming one, quickly. The UK's regime required firms to be able to stay within impact tolerances for their important business services under severe-but-plausible scenarios by a 2025 milestone. DORA turned the same logic into directly applicable EU law with incident-reporting and oversight teeth. In the US the language is softer but the direction is identical: the FFIEC rewrote its guidance from business continuity planning to business continuity management, and the 2020 interagency Sound Practices paper told the largest banks to think in terms of critical operations and a tolerance for disruption. The Basel Committee published its Principles for Operational Resilience in 2021. Different jurisdictions, one idea.
If you are a US fintech that isn't directly in scope of DORA today, don't file that as a reason to wait. Your regulated customers are in scope of something, and their expectations flow downhill to you through diligence questionnaires, contractual resilience clauses, and the exam findings they're trying to avoid. Being the third party means inheriting the discipline whether or not the statute names you. I would much rather build the program because it is the right way to run the business than retrofit it because a partner bank's examiner asked a question I couldn't answer.
Where to start
Name your handful of critical business services from the customer's side of the glass, not from your system inventory. Set one impact tolerance per service and take it to the board as a decision, not to the SRE channel as a metric. Map each service's chain end to end and mark every part you don't own. Then run one severe-but-plausible test that fails a person, a process, and a third party at the same time, and find out whether you stay inside the line you committed to.
I'm still refining how we express these tolerances in customer terms that a board and an on-call engineer will both accept without translation — that language is harder than the engineering. If you've landed on phrasing that survives contact with both audiences, I'd genuinely like to see it. And tell me where your last severe-but-plausible test actually broke, because the useful lessons are all in the breakage.
