Operational resilience has moved well beyond being a business continuity exercise that firms revisit once a year. For financial services organisations, the real question is whether important services can continue through serious disruption without causing intolerable harm to customers or threatening market integrity. The FCA’s transition period ended on 31 March 2025, meaning firms within scope were expected by that date to have completed the mapping and testing needed to demonstrate that their important business services could remain within defined impact tolerances. The regulator’s 2026 observations make the direction equally clear: operational resilience now needs to be embedded, reviewed and improved as part of normal business management rather than treated as a completed compliance project.
Preparing for a review therefore requires more than locating a continuity plan and checking whether disaster recovery documentation is current. Reviewers may want to understand how the organisation identified its important business services, why particular impact tolerances were selected, which people and technologies those services depend on, what happens when a critical supplier fails and whether severe scenarios have actually been tested. For firms relying on IT support financial services arrangements, technology providers can play an important role in supplying the technical visibility behind these answers. Infrastructure diagrams, backup testing, access controls, cloud dependencies, cybersecurity monitoring and recovery capabilities all contribute to the wider operational resilience picture, but they need to connect clearly with business services and customer outcomes.
The strongest preparation starts before anyone announces the review. A firm that continuously maintains service maps, records vulnerabilities, tests response plans and gives senior management useful resilience information is in a very different position from one that attempts to reconstruct its framework shortly before scrutiny begins. Preparation should therefore focus on proving how the organisation understands disruption, how it would respond under pressure and how lessons from tests or real incidents lead to measurable improvements. The following areas provide a practical structure for examining whether an operational resilience framework is ready to withstand that level of challenge.
Start With Important Business Services
Everything becomes harder if the organisation has not clearly defined what it is trying to keep resilient. An important business service is not simply a critical application, department or internal process. The starting point should be the service delivered to an external end user and the potential harm that could arise if that service were disrupted. FCA observations have continued to emphasise the need for clear methodologies and rationale when identifying important business services.
Before a review, firms should challenge whether their current list still reflects how the business actually operates. New products may have launched, customer journeys may have changed, acquisitions may have introduced additional dependencies and services that once appeared separate may now rely on the same technology stack.
A useful review should ask whether:
- each important business service is described consistently across risk, operations, compliance and technology teams;
- the rationale for including the service is documented;
- the potential harm caused by disruption is clearly explained;
- services that were considered but not classified as important have a defensible rationale;
- major business or technology changes have triggered reassessment;
- ownership for each important business service is clear;
- the service definition reflects the customer outcome rather than only an internal process.
A practical test is to give the service description to somebody outside the team that created it. They should be able to understand what the customer receives, where the service begins and ends and why its disruption could matter. If the explanation immediately turns into application names, infrastructure components or internal department structures, the definition may be too technology-led.
The FCA has said that important business services and impact tolerances should be regularly reviewed, with its observations highlighting annual reassessment and reviews after material business changes as good practice. Keeping these definitions current gives the rest of the resilience framework a stable foundation and makes later discussions about testing, investment and vulnerabilities much easier to defend.
Set Impact Tolerances That Hold Up
An impact tolerance represents the maximum level of disruption that an important business service can tolerate before the consequences become unacceptable. It should not simply reproduce an existing recovery time objective. The FCA has specifically noted that impact tolerances and recovery time objectives serve different purposes and has encouraged firms to consider measures beyond time alone where appropriate.
A robust preparation process can follow five steps:
- Define the harm. Identify how disruption could affect customers or market integrity and determine what would make that impact intolerable.
- Choose meaningful measures. Time may be important, but transaction volumes, numbers of affected customers, financial values or other measures may provide a fuller picture.
- Document the rationale. Explain why the threshold was chosen rather than recording only the final number.
- Compare tolerance with recovery capability. Determine whether systems, people and workarounds can realistically keep the service within tolerance.
- Recalibrate using evidence. Use scenario tests, material changes and real incidents to decide whether the existing tolerance remains credible.
One of the weakest positions a firm can take into a review is an apparently precise tolerance with little explanation behind it. A four-hour threshold sounds clear, but a reviewer may ask what happens during those four hours. How many customers are affected? Are vulnerable customers exposed to greater harm? Does a backlog continue growing after systems recover? Is the firm dependent on a manual workaround that cannot scale?
TIP: Test impact tolerances against consequences, not just the clock. A service may technically recover within its stated time limit while customers continue experiencing significant disruption because transactions, requests or complaints accumulated during the outage.
FCA observations published in 2026 point to good practice including clearer harm thresholds and greater use of quantitative, non-time-based measures alongside time-based tolerances. They also note the value of using scenario testing and real incidents to inform calibration. An operational resilience review should therefore be able to trace each tolerance back to a reasoned assessment of potential harm.
Map Dependencies Before They Fail
Once important services and tolerances are defined, the next question is what those services actually depend on. Mapping should reveal the resources required to deliver an important business service, including people, processes, technology, facilities, information and third parties.
The goal is not to produce the largest possible architecture diagram. A useful map helps decision-makers understand where disruption could originate, where concentration risk exists and what would prevent recovery within tolerance.
| Dependency | What reviewers may examine | Useful evidence |
| People | Key roles and specialist knowledge | Role maps, deputies, access records |
| Technology | Critical systems and integrations | Architecture maps, recovery tests |
| Data | Availability and recovery requirements | Backup records, restore evidence |
| Suppliers | External service dependencies | Contracts, assessments, test results |
| Processes | Manual and automated workflows | Procedures, workaround testing |
Depth matters particularly when services depend on external providers. A cloud platform may support an application supplied by another vendor, which in turn supports a process operated by an outsourced team. Looking only at the organisation’s direct contractual relationship may hide important dependencies further down the chain.
Real-world incidents have demonstrated why this visibility matters. In its observations following the 2024 CrowdStrike disruption, the FCA noted that firms with detailed mapping of third and nth-party relationships were better able to understand their exposure and take mitigating action.
TIP: Do not ask only “Who is our supplier?” Ask “What would happen to this important business service if the supplier became completely unavailable tomorrow?” The answer usually reveals dependencies that ordinary vendor inventories miss.
Mapping should also remain alive. A diagram created for the initial operational resilience programme can become unreliable surprisingly quickly as applications migrate to the cloud, suppliers change, employees move roles and integrations are added. Review preparation should therefore include checking maps against the current environment rather than assuming that an approved document still represents reality.
Strengthen IT Support for Resilience
Technology is only one component of operational resilience, but it is involved in almost every modern financial service. Reviewers may therefore look beyond whether systems are “up” and ask whether the firm understands technical dependencies, recovery capability, security controls, backup arrangements and the weaknesses that could interrupt important services.
This is where the quality of the relationship between the firm and its IT provider becomes particularly important. Reporting based almost entirely on helpdesk ticket volumes provides little insight into resilience. Firms need information that helps them understand whether technology can continue supporting important business services during severe disruption.
Useful evidence may include:
- recovery and restore test results;
- infrastructure and cloud dependency maps;
- patching and vulnerability information;
- privileged access reviews;
- cybersecurity incident records;
- capacity and availability monitoring;
- endpoint protection coverage;
- backup failures and remediation actions;
- major change records;
- documented technology risks and improvement plans.
Where internal resources are limited, firms can obtain specialist IT support for financial services from providers such as Support Tree, with the aim of bringing day-to-day IT management, cybersecurity controls, documentation and resilience evidence into a more structured operating model. Any provider should still be assessed on its ability to supply meaningful evidence and support the firm’s resilience objectives, rather than simply promising rapid technical support.
The distinction matters because outsourcing an activity does not make the dependency disappear. The FCA states that critical third-party oversight does not remove the accountability of firms, boards and senior management for managing the risks associated with their outsourcing and third-party arrangements. Senior management therefore needs enough information to challenge technical assumptions rather than relying entirely on supplier assurance.
The best preparation connects technology evidence to business impact. Instead of reporting that a backup completed successfully, demonstrate whether the affected service can actually be restored within the required timeframe. Instead of saying that a secondary internet connection exists, establish whether it has been tested under realistic conditions. A resilience review is ultimately concerned with outcomes, not inventories of controls.
Test Severe but Plausible Scenarios
A resilience framework that has never been stressed is largely theoretical. Scenario testing provides evidence about what happens when assumptions meet operational reality and remains central to demonstrating that important business services can stay within their impact tolerances. The FCA expects testing to form part of business as usual rather than remain a one-off implementation exercise.
The phrase “severe but plausible” is important. Tests should be difficult enough to expose genuine weaknesses without drifting into scenarios so extreme that they provide little practical insight. Recent outages affecting major technology providers and significant cyber incidents have reinforced that dependencies considered highly reliable can still experience disruptive events. The FCA’s 2026 operational resilience observations specifically pointed to large cloud outages and cyberattacks as examples firms should consider when developing plausible testing scenarios.
Useful scenarios can include:
- loss of a critical cloud service;
- ransomware affecting core systems;
- prolonged loss of office or remote connectivity;
- failure of a major outsourced provider;
- corruption or unavailability of key data;
- simultaneous absence of specialist employees;
- compromise of privileged credentials;
- failure during a high-volume business period;
- disruption affecting multiple connected services.
A sophisticated scenario should create decisions rather than merely technical events. Teams may need to decide when a workaround is activated, who communicates with customers, how priority cases are handled and when senior management becomes involved. Testing these decisions often reveals more about resilience than checking whether a secondary server starts successfully.
Tests should also produce actions. If a scenario reveals that a manual workaround supports only 10% of normal transaction volume, that is a meaningful vulnerability. The firm should determine the impact, assign an owner, agree remediation and later verify whether the weakness has actually been addressed.
The FCA’s observations highlight the importance of using repeated scenario testing to evidence the closure of vulnerabilities. A strong review file therefore contains more than completed test reports. It shows an improvement cycle in which testing discovers weaknesses, investment addresses them and further testing confirms whether resilience has genuinely improved.
Build Evidence the Board Can Use
Operational resilience cannot remain a specialist project owned exclusively by IT, risk or compliance. Boards and senior management need enough information to understand where the organisation is vulnerable, whether important services can remain within tolerance and where additional investment or decisions are required.
That does not mean putting every technical report into a board pack. In its 2026 observations, the FCA noted that firms do not generally need to place every piece of underlying evidence inside the self-assessment itself, provided the information presented is clear enough for the board to understand the approach, accountability and ability to recover important services within tolerance.
A useful operational resilience self-assessment should therefore connect the major elements of the framework into one coherent picture. It should explain what the important business services are, how tolerances were determined, what mapping has revealed, which scenarios have been tested, where vulnerabilities remain and what is being done about them. Material changes from the previous review should be visible rather than buried inside updated wording.
Management information should also make difficult issues difficult to ignore. A dashboard showing that 95% of actions are complete may appear reassuring until the remaining 5% includes the only unresolved vulnerability capable of pushing a key service outside its impact tolerance. Resilience reporting needs context and prioritisation.
This is also where challenge becomes valuable. Board members do not need to become infrastructure engineers, but they should be able to ask whether assumptions are realistic. What if two supposedly independent suppliers rely on the same cloud provider? Has the manual workaround ever been used at real scale? Could recovery occur during a cyberattack in which normal administrative accounts cannot be trusted? Has a major transformation programme changed the service map?
The review should leave a clear evidence trail of these decisions. Approval should demonstrate informed oversight rather than simply the existence of a meeting minute. If investment is deferred or a risk is accepted, the organisation should be able to show why the decision was reasonable and how the resulting exposure is being monitored.
As the framework matures, the self-assessment becomes more useful than a compliance record. It becomes a management tool showing where the firm is resilient today, where it remains exposed and what needs to change before the next disruption tests those assumptions for real.
Make Operational Resilience Continuous
Preparing for an operational resilience review is ultimately less about producing a perfect document and more about demonstrating a repeatable way of working. Important business services change, technology estates evolve, new suppliers appear, customer expectations shift and threats develop. A resilience framework that accurately described the organisation twelve months ago may no longer describe it today.
The FCA’s current approach reflects this continuing responsibility. The 31 March 2025 deadline marked the end of the transition period, not the end of operational resilience work, and the regulator’s subsequent review of firms’ annual self-assessments has focused on how frameworks are being strengthened and embedded over time. Regular reviews, realistic testing and clear vulnerability management therefore matter as much after implementation as they did while firms were preparing for the original deadline.
The most resilient organisations are unlikely to be those that never experience an outage. Technology failures, supplier incidents, cyberattacks and human errors cannot be eliminated completely. What distinguishes a mature organisation is its ability to understand what matters most, detect when a service is at risk, make informed decisions under pressure and recover before disruption creates unacceptable consequences.
A successful review should therefore confirm more than regulatory readiness. It should give the organisation confidence that its understanding of resilience reflects reality. When service mapping remains current, impact tolerances are grounded in meaningful harm, scenarios challenge genuine weaknesses and lessons result in action, operational resilience becomes part of how the business thinks and operates every day. That is the position worth building long before the next review begins.
