Operational Resilience Software 2026: FCA & PRA Guide - SureCloud

You are not buying software. You are buying proof that you can stay within impact tolerances when things break.

Bank of England Systemic Risk Survey research ranks cyber attack among the top perceived risks to the UK financial system, and one of the most likely to materialise. Your board wants regulator-ready evidence. Dashboards and risk registers are not evidence. A living, versioned, board-approved self-assessment — linked to your Important Business Services, your impact tolerances, and your scenario test outcomes — is.

If your current platform cannot produce that on demand, you have a capability gap that your next supervisory review will find.

Operational resilience software, in the FCA and PRA sense, is a platform that lets your team identify Important Business Services (IBS), set and monitor impact tolerances, map end-to-end dependencies, run severe-but-plausible scenario tests, link incidents to services and tolerance impacts, and maintain a living self-assessment with board-approved version history.

That definition matters because the term is used two different ways, and buying for the wrong one leaves your programme exposed.

The generic definition covers enterprise risk management and business continuity tools: risk registers, continuity plans, incident workflows, and resilience dashboards. These platforms manage disruption. They are useful. They are not what FCA and PRA supervisors ask for when they review your operational resilience programme.

The FCA/PRA definition is service-centred and evidence-driven. The FCA's operational resilience rules and the PRA's supervisory statement SS1/21 require you to evidence IBS rationale, tolerance thresholds, dependency maps, tested scenarios, and a self-assessment that reflects how the programme is governed — not just that it exists.

If your platform is built for the generic definition, no amount of configuration will make it produce FCA/PRA-grade artefacts cleanly.

The transition period ended on 31 March 2025. Every FCA and PRA-regulated firm moved from building its operational resilience programme to proving it operates. That changes what good looks like — and what supervisors expect to see.

Where the programme stands now. Your self-assessment should be living, versioned, and board-approved. Scenario tests should be running against severe-but-plausible assumptions — not against optimistic ones that were designed to be passed. Dependency maps should reflect the environment as it actually is, not as it was when the programme was first built.

The regulators' published observations from the one-year review after the transition period emphasise three consistent weaknesses: mapping quality, scenario depth, and governance clarity. If your evidence chain is weak in any of these, your self-assessment is not telling the truth.

The next hard date. From March 2027, a unified FCA/PRA/Bank of England regime for operational incident and third-party reporting goes live. Your incident data model needs to be designed now. Retrofitting it to a system that was not built for structured incident-to-service linkage is painful and expensive.

What supervisors expect to see:

1. IBS register and rationale — why each service matters for customers and markets, with change history
2. Impact tolerances — defined thresholds, monitoring logic, and breach trails by IBS
3. Dependency mapping — people, process, technology, data, facilities, and third parties end-to-end
4. Scenario tests — severe-but-plausible designs, outcomes, issues, actions, and re-tests that show improvement over time
5. Incidents linked to IBS — timeline, communications, decisions, and tolerance impact, traceable
6. A living self-assessment — versioned, board-approved, with a visible record of what changed and why

Enterprise risk management and business continuity tools reduce risk and structure recovery. They are not substitutes for FCA/PRA operational resilience evidencing, and treating them as such is the most common gap supervisors find.

The distinction is not about labels. It is about what each type of platform is built to produce:

ERM platforms are built around risks and controls. FCA/PRA operational resilience is built around services and tolerances. An ERM system can tell you what risks affect your operations. It cannot tell you which Important Business Services are breaching their impact tolerances right now, and it cannot produce the service-centred evidence trail that a supervisor expects.

BCM tools organise continuity plans and recovery procedures. A continuity plan is not live tolerance monitoring. A recovery procedure is not regulator-grade incident linkage. Document stores do not produce a living, versioned self-assessment with board approvals and a diff view that shows what changed between versions.

You need ERM and BCM capabilities plus an operational resilience layer that is built around the FCA/PRA evidence requirements — not adapted to them after the fact.

For firms regulated under both FCA/PRA rules and DORA, the risk is building two parallel evidence worlds — one for UK supervisors and one for EU regulators — with duplicated effort and inconsistent outputs.

The practical alternative is a single control and evidence model mapped to both regimes. Three areas where alignment is most tractable:

Incident taxonomy. One set of incident fields, classified once, exported to the correct template per regime. FCA/PRA and DORA have different reporting requirements, but the underlying incident data is largely the same. Classifying incidents once and rendering two views is significantly less work than maintaining two separate incident records.

Scenario testing. DORA requires ICT resilience testing. FCA/PRA requires severe-but-plausible scenario tests against IBS and tolerances. Link your ICT testing programme to your IBS and tolerance monitoring so results serve both frameworks from the same evidence base.

Third-party oversight. DORA's requirements for critical ICT third-party oversight and FCA/PRA's dependency mapping requirements overlap substantially. Model critical dependencies once. Render each regulator's required view from the same underlying data. 

The question to ask of every platform is not what features it has. It is what evidence it produces, and whether that evidence matches what your supervisor will ask for.

IBS and tolerance management. Define IBS with rationale, set thresholds, monitor live KRIs and KCIs, alert on breaches, and export an IBS-level status in a single step. If producing a tolerance health report requires manual assembly, the platform is not doing its job.

Dependency maps that reflect operational reality. Connect people, process, technology, data, facilities, and third parties in one data model. Flag single points of failure. Refresh from CMDB, HRIS, and vendor data sources so the map reflects the environment as it changes, not as it was at the last review.

Scenario testing built into the programme cadence. Design, schedule, execute, and re-test severe-but-plausible scenarios. Capture findings, issues, actions, and lessons learned. Show improvement over time. A scenario programme that produces a document but does not track action closure and re-testing has not closed the loop.

Incidents joined to services and tolerances. Log an event once. Link it automatically to affected IBS. Show tolerance impact. Document decisions and communications. Export a regulator-format report from the same data that drove your internal response — not a manually reconstructed version of events.

A living self-assessment. Versioning, approval trails, watermarking, and a diff view that shows what changed between versions and why. When Internal Audit or a supervisor asks what has changed since the last review, the answer should be visible in the system — not assembled from email chains.

Governance and board reporting. Board dashboards that start with IBS health, tolerance status, outstanding risks, and critical third-party exposure. No manual consolidation. The board should see the truth, not a version of it that was current two weeks ago.

Integrations that keep evidence trusted. SSO, MFA, RBAC, and APIs connecting to CMDB, SIEM/SOAR, HRIS, and vendor-risk systems. If the source data moves, your evidence updates. If it does not, your maps and tolerances are measuring something that no longer exists. 

McKinsey Global Institute research shows that disruptions lasting two months or longer occur with regularity, and multi-week shocks are a persistent pattern in the data. That matters for your scenario programme.

Tolerance design and "severe-but-plausible" scenario assumptions must account for duration and compounding effects — not just single-day outages. A scenario that tests a four-hour outage against a 24-hour tolerance is not severe-but-plausible for most IBS. It is a test designed to be passed. Supervisors have said so explicitly in published feedback.

Scenarios should test the conditions under which your IBS would actually breach tolerance — including cascading failures across dependencies, sustained disruption, and concurrent incidents. If your scenario programme has never produced a tolerance breach finding, question whether the scenarios are severe enough.

A PoC that ends with a demo is not useful. A PoC that ends with regulator-ready artefacts from your own data is.

Days 0–30: Establish the evidence baseline Select two or three IBS. Import minimal CMDB, HRIS, and vendor data slices. Build dependency maps. Define impact tolerances and configure breach alerts. Output: IBS register, dependency maps, and live tolerance dashboards.

Days 31–60: Test for real Design and run one or two severe-but-plausible scenarios end-to-end. Capture outcomes, issues, and actions. Define and assign re-tests. Output: Scenario packs, lessons learned, re-test plan.

Days 61–90: Produce the evidence Generate a board pack and a self-assessment update. Simulate an incident and export a regulator-format report from the same data used internally. Output: Self-assessment diff, board deck, incident report export.

If a vendor cannot help you produce these outputs within 90 days using your own data, the platform will not produce them under audit pressure either.

The test is simple: would a supervisor or Internal Audit reviewer say yes to each of these without asking a follow-up question?

1. IBS register and rationale — named owner, clear rationale, complete change history
2. Tolerance dashboards — breach history, decisions taken, actions with owners and dates, by IBS
3. Service maps — single points of failure and critical third parties visibly flagged, with refresh date
4. Scenario documentation — design, execution, outcomes, issues and actions, re-test confirmation
5. Incident linkage — event to IBS to tolerance impact with communications and decisions captured
6. Self-assessment — versioned, board-approved, watermark-ready, exportable in one step

If any of these require manual assembly before a review, you are carrying evidence risk that will surface at the wrong moment.

Start where your evidence depends on live data being accurate.

CMDB and ITSM (ServiceNow or equivalent). Map assets to services and reflect infrastructure change faster than a manual process can. A dependency map built from static data starts degrading the day it is completed.

SIEM and SOAR. Pull high-fidelity incident signals and auto-link to affected IBS. Kick off response playbooks from the same event record that feeds your regulatory reporting.

HRIS. Show role coverage and escalation paths as they actually are — including during the staff changes that happen between annual reviews.

Vendor risk. Keep critical third-party exposure current, including concentration and fourth-party dependencies. Your dependency map is only as accurate as your vendor data.

Identity systems. Prove who approved what, when. Approval trails are a governance requirement, not an audit convenience. 

SureCloud is built for FCA and PRA-regulated firms that treat evidence as the output of their operational resilience programme — not a by-product of it.

The platform gives you a data model built around IBS, impact tolerances, dependency maps, scenario testing, incident-to-service linkage, and a living self-assessment — with board-grade reporting and a DORA-aligned evidence spine for dual-regulated firms. It integrates with ServiceNow, Microsoft 365 and Sentinel, major HRIS platforms, and vendor-risk systems so your evidence reflects live operational data rather than periodic snapshots.

In a 90-day PoC, you can stand up two to three IBS with tolerances, run at least one scenario, and produce a board-ready self-assessment update — using your own data, not sample content.

The question to ask before your next supervisory review is not whether your platform has the right features. It is whether it produces the evidence your supervisor will ask for, on demand, without manual assembly.

Two things need to be true at the same time. Your programme needs to withstand disruption. And it needs to prove that it can — on demand, to your board, your Internal Audit function, and your supervisor.

Most platforms are built to help with the first. Fewer are built to produce the second. In the continuous evidencing phase, that distinction is what your next supervisory review will test.

Anchor your selection on IBS, tolerances, dependency maps, scenario testing, incident linkage, and a living self-assessment. Build one evidence spine that satisfies both FCA/PRA and DORA if your firm operates in both regimes. Run a PoC that ends with regulator-ready artefacts from your own data — not a demo from sample content.

GRC isn't a data problem. It is an execution problem.

Your Business Assured.

The following items require verification before this post goes live.

1. Bank of England Systemic Risk Survey — cyber risk ranking. Retained with a link to the H2 2024 edition. Verify this is the most current published edition and that the characterisation of cyber as a top perceived risk is accurate. The survey is published twice yearly — confirm the finding has not been superseded by a more recent edition.
   
   
2. "March 2027" unified incident and third-party reporting regime. This date is taken from the original source material. Verify it is still accurate against the most current FCA/PRA policy statement and timeline. Reporting regime timelines have shifted during the consultation process — CP23/30 and subsequent policy statements are the reference. Do not publish a deadline that has since been revised.
   
   
3. FCA/PRA "one-year review" observations. The original references published regulatory observations about mapping quality, scenario depth, and governance clarity. This has been retained as a general characterisation. If a specific FCA or PRA publication is intended, identify it and link to it — generic attribution to "regulators' observations" weakens the authority of the claim. The FCA's Dear CEO letters and supervisory statements are the likely source.
   
   
4. McKinsey Global Institute — two-month disruption duration finding. The original cites MGI research on disruption duration. Retained with a link to the MGI risk and resilience page. Verify the specific report, its publication date, and whether the characterisation of the finding is accurate. McKinsey research pages sometimes aggregate findings across multiple publications — confirm the specific data point and its source.
   
   
5. DORA alignment section. The practical guidance on incident taxonomy, scenario testing linkage, and third-party oversight has been retained as general operational advice. Specific DORA technical standard requirements should be verified against current EBA ITS before publication — implementation standards have continued to develop.
   
   
6. SureCloud product capabilities. All capability claims in the "Where SureCloud Fits" section — specifically the FCA/PRA data model, DORA evidence spine, integration list, and 90-day PoC commitment — must be verified against references/product.md before publication.
   
   
7. Case study placeholder. Removed from the revised post. Replace with a verified, approved customer reference with real metrics before publishing.
   
   

Internal resource links. The original referenced a downloadable "FCA/PRA Self-Assessment Evidence Checklist" and a demo booking link. These have been removed as URLs were not provided. Confirm the correct URLs and reinsert — both are high-intent conversion assets for this piece and their absence is a missed opportunity.

1. Bank of England Systemic Risk Survey — cyber risk ranking data

2. FCA Operational Resilience rules — FCA supervisory expectations
3. PRA Supervisory Statement SS1/21 — IBS and impact tolerance requirements
4. FCA/PRA/BoE CP23/30 — Critical Third Parties — March 2027 reporting regime
5. DORA (EIOPA) — ICT risk and resilience obligations
6. McKinsey Global Institute — disruption duration data