What makes a good operational resilience program?
The short answer
A good operational resilience program gives the organization one current, shared picture of how its critical services work and what they depend on. It answers four questions. How does the business work? Which disruptions matter? What capability exists today? Which gaps come first? Plans, exercises and compliance evidence follow from that work.
Most resilience programs are built for the audit
Regulators and auditors ask for evidence, so organizations produce documents: business impact analyses, continuity plans, recovery runbooks. Every year the cycle repeats. Chase the owners, collect the spreadsheets, reconcile last year's version with this year's.
In my work I meet three kinds of organizations. The first has little in place, or believes it does. The second runs a full framework and now uses AI to compare this year's plan with last year's. The third group is growing: teams tired of chasing people for spreadsheets, who know none of it will hold when an incident hits.
The documents also cost you during the incident. In a real infrastructure failure, coordinating hundreds of outdated runbooks with changed owners adds complexity at the exact moment it should disappear. Most teams end up managing spreadsheets and calling it resilience.
Resilience is built on ordinary days
A resilience program runs in two modes. You build capacity, or you use it. You use it a few days a year. You build it, or fail to, on every other day.
Picture a crisis at 9pm. Half the picture is missing, leadership wants answers, and nobody opens a binder. Long documents are unusable under that cognitive load. What carries the team is what was built earlier: principles that say what matters, trust so decisions aren't second-guessed, and a clear view of which services matter and what they run on.
Eisenhower: "In preparing for battle I have always found that plans are useless, but planning is indispensable." Most of the industry heard the first half and answered with better-formatted plans. The value sits in the planning. An incident is the exam. Build is the semester.
The four questions every resilience program has to answer
There is no fixed sequence of steps. A good program keeps returning to four questions, starting with one critical service and widening from there.
1. How does the business actually work?
Start with the services that carry the value, then follow what they run on: people, systems, sites, suppliers and data. This is the real dependency chain, and it rarely matches the org chart. Without it, every later decision rests on opinion.
2. Which disruptions do we worry about?
You can't plan for every threat. Nearly every threat lands as one of five losses: a site, a system, a supplier, people or data. Ransomware is a system and data loss. A cloud region outage is a system and supplier loss. Plan against the five losses and the work becomes finite.
3. What do we already have?
Take stock of the capability that exists today: workarounds, recovery procedures, backup sites, service provider contracts, trained people. Every organization has more than it thinks, and less than its documents claim. Check recovery objectives against the real chain before you trust them.
4. What do we improve first?
Put impact and preparedness in the same picture. High impact with low preparedness goes first. That one rule turns a long gap list into a budget conversation leadership will back. Define the minimum the business must keep running, then work backwards to what must recover first.
Someone has to own the space between your teams
Six functions usually hold a piece of resilience: business continuity, cyber security, IT disaster recovery and service continuity, risk and compliance, third-party management and asset management. Each sees part of the operation. Nobody holds the whole.
That gap stays invisible until an incident. Then everyone has a plan for their own area, and nobody can sequence recovery across the whole service. Resilience is what happens in the space between.
A good program makes that ownership explicit:
- A named resilience lead coordinates the work across functions, one service at a time.
- A service owner stands behind the business requirement: what customers need, and how long they can wait.
- A management route settles trade-offs the teams can't, such as competing priorities or budget.
- Functional teams own and deliver the improvements.
What regulators ask for
ISO 22301, DORA, NIS2 and the UK operational resilience rules differ in scope and detail. Most of them ask for the same core things: identify your important business services or critical functions, set limits for how much disruption they can take, test against realistic scenarios, and show evidence. All four are outcomes of the questions above. Compliance is a byproduct of doing the work properly, and a poor starting point for it.
Signs your program is working
- Your dependency map reflects changes made in the last few weeks.
- Every critical service has a defined minimum and a workaround the team has tried.
- Recovery objectives are checked against the real dependency chain, third parties included.
- Exercises start from the capabilities you want to test, and known gaps get fixed beforehand.
- Every open gap has an owner and a date, or an explicit management decision to accept it.
- In an incident, escalation takes minutes and the customer impact is visible within the first hour.
A practical way to begin
A whiteboard afternoon on the four questions gets an organization further than a purchased framework. Pick one critical service and bring the people who deliver, protect and recover it into one room.
- Choose one critical service and agree on who it serves and what they need from it.
- Sketch what it runs on: people, systems, sites, suppliers and data. Use the records you already have.
- Pick one of the five losses and follow it through the sketch. Note what stops, for whom, and when.
- Agree the minimum the service must deliver during that disruption, and how long the business can wait.
- Name the biggest gap, give it an owner and a date, and decide what to exercise next.
The map will be incomplete, and that is expected. The gaps tell you where to ask the next question.
How we do this in resimate
We built resimate because we ran these programs by hand for years. resimate turns the spreadsheets, CMDB exports and continuity plans you already have into one connected view, from vendors to technology to customers. Teams see what goes down with a failure, define what must keep running, and check whether they restore it in time. Teams go live in 4 to 6 weeks.