An operational resilience framework is the operating model an organisation uses to keep its most important services running through disruption, built around named services, agreed tolerances for how long they can be impaired, and evidence that both have been tested. It is not a policy document. It is the structure that turns a regulatory expectation into something an organisation actually runs, month after month, and can show on demand.
- Important business services, named from the customer’s point of view rather than the org chart.
- Impact tolerances that state the maximum tolerable disruption for each one, in numbers.
- Dependency mapping that traces the people, systems, suppliers and premises behind every service.
- Scenario testing against severe but plausible events, not comfortable ones.
- A remediation plan for the gaps testing exposes, with owners and dates.
- Governance and a written self assessment that keeps the whole thing current and defensible.
What is an operational resilience framework?
A framework answers a question that a policy cannot: how does this organisation stay operational when something breaks, and how would we know before it happens? UK regulators arrived at a consistent answer. Rather than asking firms to prevent every failure, they ask them to assume failure will occur and to prove they can absorb it within a limit they have set and defended.
That shift changes what the framework has to contain. Prevention frameworks catalogue controls. An operational resilience framework starts from the service the customer depends on, works backwards through everything that service relies on, and sets a defensible limit on how long it can be degraded before the harm becomes unacceptable. Controls still matter, but they are evidence rather than the objective.
This page covers the framework itself. For the definition, the regulatory landscape and how the discipline relates to business continuity, see operational resilience.
What are the components of an operational resilience framework?
Six components, in sequence. Each one depends on the one before it, which is why frameworks assembled out of order tend to collapse under testing.
- Identify: list the services whose failure would cause intolerable harm to customers or to market integrity. Most organisations start with too many and refine down.
- Map: trace each service end to end through the people, processes, technology, facilities, data and third parties it depends on. Mapping is where hidden single points of failure surface.
- Tolerances: set the maximum tolerable disruption for each service, expressed as a time and a volume rather than an adjective.
- Test: run severe but plausible scenarios and observe whether the service stays inside its tolerance. A test that everything passes was not severe enough.
- Remediate: fix what the testing exposed, with named owners, dates and a record of what changed.
- Govern: keep it under board oversight, review it on a cycle, and maintain the written self assessment that explains your judgements.
What evidence does each component produce?
Each component of the framework produces a specific artefact, and those artefacts are what a supervisor, an auditor or a major customer actually asks to see. This is the most useful test of whether a framework is running: if a component produces nothing, it is not operating, whatever the documentation says.
| Component | Evidence asked for | Where it comes from |
|---|---|---|
| Identify | The list of important business services and the reasoning that put each one on it | A board approved record, revisited when the business changes rather than annually |
| Map | A current dependency map for each service, reaching through to suppliers and premises | Asset, supplier and process data maintained as part of normal operations |
| Tolerances | The tolerance for every service and the analysis that justified the number | Impact analysis, agreed at the level that owns the risk |
| Test | Scenario test records showing dates, participants and what actually happened | Exercise records captured during the test, not written up afterwards |
| Remediate | Every vulnerability found, its owner, its target date and its current status | A corrective action log tied back to the test that found it |
| Govern | A written self assessment that explains the judgements you have made | Maintained continuously as the framework runs |
What separates a framework that holds up from one that does not is rarely whether these artefacts exist at all. It is whether the tolerances can be defended, whether the mapping reflects the business as it operates today, and whether the self assessment describes the organisation that actually exists. Anyone examining the framework tends to arrive at those three questions, whether they are a supervisor, an external auditor or a major customer running due diligence. The regulatory detail behind the discipline sits on the operational resilience page, with sector specific expectations on resilience for finance.
There's a bigger picture behind this.
This page covers one part of business resilience. Real Resilience — IO’s framework for connecting security, privacy and AI governance — is where the full picture comes together.
How do you build an operational resilience framework?
The order below reflects where organisations get stuck rather than an idealised project plan. The hard parts are the second and third steps, and skipping them is what produces a framework that reads well and fails testing.
- Define services from the outside in: describe what the customer receives, not which department delivers it. A service that maps neatly onto your internal structure is usually a process, not a service.
- Set the tolerance before you know whether you can meet it: decide the point at which harm becomes intolerable on its own merits. Working backwards from current capability produces a tolerance you can always meet and that tells you nothing.
- Map to the depth where decisions change: enough detail to see the single points of failure and the concentration risk in your suppliers, and no more. Mapping projects fail by pursuing completeness.
- Choose scenarios that could actually happen to you: the failure of a named critical supplier, loss of a data centre, a ransomware event, the departure of the only team who understands a legacy system.
- Record the failures honestly: a test log showing breaches and the fixes that followed is stronger evidence than an unbroken run of passes, which mainly raises the question of whether the scenarios were severe enough.
- Assign the vulnerabilities: every gap gets an owner, a remediation date and a route to the board when it slips.
- Write the self assessment as you go: assembled once a year from memory it is a document. Maintained continuously it is the framework’s audit trail.
How is this different from a business resilience framework?
The two are often conflated, and the distinction is practical rather than academic. Operational resilience is a regulatory discipline with a defined scope: important business services and the tolerances attached to them. Business resilience is broader, covering the organisation’s capacity to absorb change of any kind, including security, privacy and AI risk alongside disruption.
In practice one sits inside the other. Operational resilience gives you the service view and the tolerances. The wider business resilience framework gives you the control set that the service view depends on, and the mechanism that stops each new regulation being answered with a separate programme. If you are choosing where to start and you are subject to operational resilience rules, start there, because the scope and the limits are set externally rather than by you. If you are not, the broader framework is the better entry point.
Continuity planning is the third related discipline. It supplies the plans and recovery objectives that let a service stay inside its tolerance, and is covered under business continuity.
Get started easily with a personal product demo
One of our onboarding specialists will walk you through our platform to help you get started with confidence.
How does the Resilience Loop support operational resilience?
Every component of an operational resilience framework rests on controls that already exist somewhere in your organisation. Access management, backup and recovery, supplier assessment, incident response and change control are the machinery that makes a tolerance achievable. The problem is rarely that those controls are missing. It is that each framework asks for them separately, so the same control is documented three times and evidenced none of them well.
The Resilience Loop runs information security under ISO 27001, data privacy under ISO 27701 and AI governance under ISO 42001 as one connected system. Operational resilience becomes a further lens over that same control set rather than a parallel programme. A supplier assessment performed once serves the mapping exercise, the security standard and the privacy standard together. Continuity capability is specified and certifiable under ISO 22301, which supplies the management system that keeps plans owned and tested.
How do you keep the evidence current?
Every framework produces the right artefacts at least once. The difficulty is that they decay quietly. A dependency map is accurate on the day it is drawn and wrong the moment a supplier changes. A tolerance agreed two years ago may no longer match the harm it was set against. Nothing announces any of this, so the gap between the documented framework and the operating one tends to open quietly and surface at the worst possible moment.
The difference lies in when the evidence is created. Produced as a by-product of running the framework, it is current by definition and there is nothing to reconstruct. Assembled ahead of a review, it records what the organisation believed about itself rather than how it operates, and that discrepancy is exactly what close examination exposes. The method is set out in how to evidence resilience, and the Resilience Score gives you a baseline before you start.
Why choose ISMS.online for an operational resilience framework?
A framework is only as good as its currency. ISMS.online is built to keep the service view, the mapping and the evidence in step with how you actually operate.
- One control set, every framework: map controls once and reuse them across operational resilience, ISO 27001, ISO 27701, ISO 42001 and ISO 22301 rather than rebuilding for each.
- Services linked to what they depend on: connect important business services to the controls, suppliers and assets behind them, so a change in one surfaces in the other.
- Test records and findings in one place: schedule scenario tests, capture what failed and track remediation to closure alongside the framework itself.
- Evidence ready on demand: produce the current picture for a supervisor, an auditor or a customer without a reconstruction exercise.
- Third-party risk in the same system: assess and monitor the suppliers your tolerances quietly depend on.
- Informed by deep expertise: guided implementation from specialists who have run these frameworks inside regulated organisations.
- Built for UK and regulated markets: designed for organisations that have to prove resilience to supervisors and to win contracts.
See how it fits together on the business resilience platform, or book a demo.
FAQs
What is an operational resilience framework in simple terms?
It is the way an organisation identifies the services its customers cannot do without, decides how long each one could be disrupted before the harm becomes unacceptable, works out everything those services depend on, and then tests whether the limits hold. The framework is the structure that keeps those four things current and evidenced rather than written once.
What is an impact tolerance?
An impact tolerance is the maximum level of disruption to an important business service that an organisation is prepared to accept, stated as a measurable limit such as a number of hours or a volume of failed transactions. It is deliberately set from the point at which harm becomes intolerable, not from what the organisation can currently achieve, which is why a well set tolerance is often uncomfortable at first.
Is an operational resilience framework only for financial services?
The regulatory obligation sits mainly with financial services, but the method does not. Telecoms, healthcare and managed service providers face equivalent expectations under their own regimes, and any organisation with contractual commitments on availability benefits from the same discipline. The service view and the tolerance are useful management tools regardless of who is supervising you.
Which standard should an operational resilience framework be built on?
No single standard covers it, because the requirements come from regulators rather than from a certifiable specification. In practice the framework draws on several: ISO 22301 for continuity management, ISO 27001 for the security controls the services depend on, and ISO/IEC 27031 for ICT readiness. Working to those standards gives you most of the evidence a supervisor asks for, in a form that has already been independently audited.
How often should the framework be reviewed?
At least annually for the full cycle, with scenario testing on a schedule through the year and mapping updated whenever something material changes. A new supplier, a system migration, an acquisition or a lesson from a live incident should all trigger a review rather than waiting for the annual date. Mapping that lags behind the organisation is a common weakness, and it undermines every component that depends on it.
