A platform can meet its uptime target and still leave customers exposed when a payment queue, identity provider or manual workaround fails under pressure. FCA operational-resilience rules ask in-scope firms to begin with the important business service and the intolerable harm caused by disruption, then map the people, processes, technology, facilities, information and third parties needed to stay within impact tolerance. The transition period ended on 31 March 2025; by 2026, the question is whether the evidence survives real change and severe but plausible testing. The first commercial opportunity is a one-service failure-mode review that connects impact tolerance to dependencies, scenarios, workarounds and remediation. This reading shows how a technology or cyber-resilience specialist can sell that bounded decision and build recurring testing assurance without promising uninterrupted service, regulator approval, incident prevention or recovery within every scenario.
What changed when the transition period ended in March 2025?
By 31 March 2025, firms in scope were expected to have completed mapping and testing so each important business service could remain within its impact tolerance, with necessary investment underway or completed. The deadline did not end the obligation: services, tolerances, mappings, tests and self-assessments must keep evolving.
The FCA’s March 2026 observations show continuing focus on board challenge, clear methodologies, vulnerabilities and owned remediation. A dated transition plan is therefore not a mature evidence set. Buyers need to know which service has changed since its last credible test.
- Important business service and users
- Impact tolerance and harm threshold
- Process, people and information
- Technology, facilities and third parties
- Scenario, response, recovery and remediation
How is an impact tolerance different from a recovery target?
An impact tolerance marks the maximum tolerable disruption to an important business service before consumer harm or market-integrity risk becomes intolerable. A recovery-time objective concerns restoring a system; recovery may need to occur earlier so backlogs, manual processing and customer effects remain within the broader tolerance.
Use time with complementary measures where relevant: affected customers, transaction value, backlog, vulnerable-customer exposure or market impact. The rationale should explain why the boundary is intolerable, not merely copy a technology target.
- Disruption begins
- Response and workaround activate
- Technology recovery objective
- Backlog and customer remediation
- Impact tolerance boundary
What should the first paid resilience purchase deliver?
The first purchase should review one important business service against one severe but plausible failure mode. It should end with a service boundary, tolerance rationale, dependency map, test evidence, workaround limits, vulnerabilities, named remediation and a decision to accept, fix, retest or escalate.
One service keeps the evidence room bounded while exposing the real operating model. The specialist interviews service, technology, operations, risk and supplier owners; the governing body retains responsibility for the firm’s judgements and self-assessment.
Which dependencies must be mapped beyond the technology stack?
Useful mapping connects the service to people, processes, technology, facilities, information and third parties at enough depth to support testing and remediation. A cloud diagram alone misses decision rights, manual work, data quality, customer communication, physical access and supplier dependencies that can determine whether harm remains tolerable.
| Dependency | Evidence question | Common weakness |
|---|---|---|
| People and decisions | Who acts when automation fails? | Named role unavailable |
| Process and workaround | What volume can be handled? | Untested capacity assumption |
| Technology and data | What must recover in sequence? | Hidden shared component |
| Third party | What evidence and access exist? | Contractual promise only |
| Communication | Who must be told, when? | No customer prioritisation |
What makes a scenario severe but plausible?
A severe but plausible scenario combines credible causes and stressed conditions that expose the service’s weakest dependencies without becoming fantasy. It should test decisions, communications, third parties, capacity and recovery over the full customer-impact period, not stop when a technical component returns online.
Use incidents, threat intelligence, supplier failures and near misses to design scenarios. Vary one important assumption at a time—duration, time of day, concurrent failure or staff availability—so lessons remain attributable and actionable.
How should third-party evidence change the test?
A firm cannot outsource accountability for its important service. Supplier contracts, architecture, recovery evidence, incident communication, concentration and exit options must support the firm’s tolerance; where direct testing is limited, the firm needs alternative assurance and explicit uncertainty.
A supplier review should ask what the firm can observe and influence during disruption. Shared platforms may create correlated risk across services. Exit plans should identify data, competence, sequence and interim service—not merely a termination clause.
- Contract and service commitment
- Architecture and dependency disclosure
- Test result and remediation proof
- Joint incident and communication exercise
- Exit or substitution rehearsal
What recurring service follows the failure-mode review?
A recurring service refreshes service maps, samples changes, designs and observes scenarios, tracks vulnerabilities, challenges supplier evidence and updates self-assessment inputs. It earns renewal by keeping the resilience argument aligned with releases, incidents and business change rather than repeating one annual tabletop.
Cadence should follow material change and service risk. Report retest status, overdue remediation, untested workarounds, dependency concentration and assumptions that the board must accept or fund.
Which buying events expose a real resilience decision?
A cloud migration, core release, material outsourcing, merger, incident, failed test, new important service or board challenge creates a credible buying event. Outreach should name the service and evidence decision, not suggest that every technology change causes a regulatory breach.
Target firms in scope of the FCA policy and technology suppliers serving them. Search captures named concerns; risk and legal partners refer governance gaps; selected account outreach can use observable transformation events. The qualification call must reach both service and technical owners.
- Major release or migration
- New critical supplier
- Incident or near miss
- Failed scenario or overdue remediation
- Merger, service launch or board review
When is an operational-resilience offer ready to launch?
Launch when the specialist can work from an important business service, preserve regulatory and customer data, test a credible failure mode and deliver owned remediation without assuming the board’s judgement. The partner firm must provide service, technology, risk, operations and supplier access.
FCA PS21/3, Handbook rules and 2024–2026 observations bound public claims. The separate insurance draft should later become a vertical query path, not a duplicate framework. No results, tolerance or regulator outcomes are invented.
- 1Review service and tolerance
- 2Map material change
- 3Test severe but plausible failure
- 4Remediate and retest
- 5Feed governance and self-assessment
Could GetFishNet build a qualified acquisition route for your resilience service?
GetFishNet can test whether your resilience expertise, regulated audience, first review and delivery capacity form a credible acquisition opportunity. The free eligibility test examines current acquisition pain points and synergies without promising clients, revenue, uninterrupted service or regulatory outcomes.
If one important service carries a costly evidence gap, we can design a tailored multichannel route around that decision and test the market before expanding.
Editorial provenance
Sources used
- Financial Conduct Authority, PS21/3: Building operational resilience
- Financial Conduct Authority, Operational resilience
- Financial Conduct Authority, Operational resilience: insights and observations for firms
- Financial Conduct Authority, Operational resilience: insights and observations one year on
- Financial Conduct Authority, SYSC 15A: Operational resilience
- Prudential Regulation Authority, SS1/21: Operational resilience
The eligibility report dates and quantifies it, then tests whether it deserves action.
The topic is broken down into entities, attributes, evidence, channels, costs and decision points. Institutions are cited in the text; no external resource interrupts the reading path.