UK banks, insurers, payment firms and other regulated financial firms must be able to keep each important business service within a board-approved impact tolerance through a severe but plausible disruption, and since 31 March 2025 regulators expect them to prove it. The regime is set by the PRA's Supervisory Statement SS1/21 and the FCA's PS21/3, which created SYSC 15A in the FCA Handbook. It is the UK's closest equivalent to the EU's DORA, but it is outcome-based: it tells firms what to achieve, not which controls to deploy. New incident and third-party reporting rules (PRA PS7/26 and FCA PS26/2) take effect on 18 March 2027, and the critical third parties regime adds direct oversight of key suppliers. Status line: this guide reflects the rules and regulator pages as checked on 27 October 2026. It is written for operational resilience leads, CISOs, technology risk teams and the SMF24 and board members who sign off the self-assessment.
Key takeaways
- Services, not systems. Firms identify important business services from the perspective of the client or market and set a tolerance for each one, then map every person, process, technology, facility and piece of information the service depends on.
- The deadline has passed. By 31 March 2025 firms had to be able to operate within impact tolerances; regulators now expect continuing investment to stay there, not a transition plan.
- Cyber is the hardest scenario. Severe but plausible testing must include scenarios such as destructive malware, identity provider compromise and loss of a key third party, where recovery time is longest and least certain.
- Reporting changes on 18 March 2027. A single incident report through FCA Connect, an initial report expected within 24 hours of determining the threshold is met, and a final report within 30 working days of resolution, plus notification and an annual register of material third-party arrangements.
- Enforcement is real. The FCA and PRA fined TSB 48.65 million pounds in December 2022 for its 2018 IT migration failure, including poor management of a critical outsourced supplier, and the PRA separately fined its former CIO.
Scope: who and what is covered
| Instrument | Regulator | Firms in scope |
|---|---|---|
| SS1/21 and the PRA Rulebook Operational Resilience Parts | PRA | UK banks, building societies, PRA-designated investment firms, UK Solvency II insurers, the Society of Lloyd's and its managing agents |
| PS21/3, SYSC 15A | FCA | Banks, building societies, designated investment firms and Solvency II firms (dual regulated), enhanced scope SM&CR firms, UK recognised investment exchanges, payment institutions, e-money institutions, registered account information service providers, consolidated tape providers and qualifying cryptoasset firms |
| PS16/24 critical third parties regime | Bank of England, PRA and FCA | Third parties designated by HM Treasury because failure of their services could threaten UK financial stability or confidence |
| PS7/26 and PS26/2 incident and third-party reporting (from 18 March 2027) | PRA and FCA | PRA incident reporting: banks, building societies, PRA-designated investment firms, overseas bank branches, Solvency II firms, Lloyd's. FCA: almost all FCA-regulated firms, with most solo-regulated firms filing a standard report |
Dual-regulated firms must meet both the PRA and FCA requirements, which are aligned but not identical: the PRA focuses on safety and soundness and financial stability, the FCA on harm to consumers and market integrity. A single service can therefore have two tolerances.
Key terms
- Important business service: a service provided to an external end user or market participant whose disruption could cause intolerable harm to clients or risk to the firm or the market. SYSC 15A.2.3G and 15A.2.4G list factors such as client vulnerability, substitutability and harm to the UK financial system. Internal services such as HR or the identity platform are not important business services in themselves; they are dependencies to map.
- Impact tolerance: the maximum tolerable level of disruption to an important business service, set with a clear metric, most often a maximum duration, and sometimes volumes or values affected.
- Severe but plausible: the scenario standard for testing. SYSC 15A.2.9R requires firms to be able to remain within each tolerance in such a disruption.
Key obligations
The FCA rule references below come from SYSC 15A; the PRA's expectations in SS1/21 follow the same structure.
| Obligation | FCA rule | Frequency | Security and technology implication |
|---|---|---|---|
| Identify important business services | SYSC 15A.2.1R, 15A.2.2R | At least annually and after material change | Agree with the business which services matter before scoping technical controls |
| Set an impact tolerance for each service | SYSC 15A.2.5R, 15A.2.6R | At least annually and after material change | Recovery time objectives for supporting systems must sit inside the tolerance, with margin |
| Remain within tolerance in severe but plausible disruption | SYSC 15A.2.9R | Continuous | Backups, recovery and failover must work in a cyber scenario, not only a data centre outage |
| Map people, processes, technology, facilities and information | SYSC 15A.4.1R, 15A.4.3R | At least annually and after material change | Include identity providers, privileged access, certificates, secrets, APIs and third-party services in the map |
| Scenario testing plan and testing | SYSC 15A.5.1R, 15A.5.3R to 15A.5.7R | Regularly, after material change and after improvements | Test cyber scenarios end to end, including clean rebuild and identity recovery |
| Lessons learned after tests and real incidents | SYSC 15A.5.8R, 15A.5.9R | After each test or disruption | Feed findings into the remediation plan with owners and dates |
| Written self-assessment | SYSC 15A.6.1R, 15A.6.2R | Kept up to date; each version kept for at least 6 years | Evidence for mapping, testing methods and vulnerabilities found |
| Governing body approval | SYSC 15A.7.1R | Regular review | The board approves the self-assessment and must understand the cyber dependencies |
| Internal and external communications | SYSC 15A.8.1R, 15A.8.3R | Maintained; used during incidents | Out-of-band communications if email or collaboration tools are compromised |
Incident and third-party reporting from 18 March 2027
- Thresholds: the FCA requires a report where an incident risks intolerable harm to consumers from which they cannot easily recover, harm to the safety and soundness of the firm or other market participants, or harm to market stability, integrity or confidence. The PRA threshold is risk to UK financial stability, the firm's safety and soundness, or policyholder protection. Near misses need not be reported to the PRA.
- Single report, three phases (PRA PS7/26): initial report as soon as reasonably practicable, expected within 24 hours of determining that the threshold is met; updates when circumstances change significantly; final report within 30 working days of resolution, extendable to 60 working days where the root cause is complex or depends on a third party.
- One channel: reports are submitted through FCA Connect, with joint PRA and FCA reports permitted. Payment Services Regulations incident reporting is folded into the new framework.
- Accountability: the Chief Operations function (SMF24) or equivalent holds overall responsibility for incident reporting but need not approve each submission.
- Material third-party arrangements: firms must notify the regulator when entering into or significantly changing a material third-party arrangement and submit an annual register. The PRA notification is not an approval and replaces material outsourcing notifications; PRA guidance sits in an updated SS2/21 and the new SS1/26.
- Until March 2027: the FCA asks firms to report material incidents to their named supervisor or through the SUP 15 notification form, and dual-regulated firms to tell the PRA too.
Timeline and current status
| Date | Event |
|---|---|
| 29 March 2021 | PRA publishes SS1/21 (PS6/21); FCA publishes PS21/3 |
| 31 March 2022 | Rules in force: services identified, tolerances set, initial mapping and testing done; SS1/21 March 2022 version takes effect |
| 12 November 2024 | PS16/24 critical third parties rules published; in force 1 January 2025, with CTP obligations applying from HM Treasury designation |
| 31 March 2025 | End of transition: firms must be able to remain within impact tolerances |
| October 2025 | Joint publication on cyber response and recovery; the FCA states it adds no new requirements |
| 18 March 2026 | PRA PS7/26 and FCA PS26/2 published on incident and third-party reporting |
| May 2026 and September 2026 | Joint FCA, Bank of England and HM Treasury statement on frontier AI, followed by FCA practical insights |
| 18 March 2027 | New incident and third-party reporting rules take effect |
As of 27 October 2026 the impact tolerance rules are fully in force and the reporting rules are in their preparation year. Check the regulators' operational resilience pages for any further policy statements before relying on dates, and see the Financial Services Cyber Regulation Map for how this sits beside DORA, NYDFS and other regimes.
Enforcement and penalties
- Supervision first: SYSC 15A.9 lets the FCA give individual guidance on whether a firm's approach is adequate and require action, with formal powers under sections 55J and 55L of the Financial Services and Markets Act 2000 if disagreement remains.
- Firm fines: on 20 December 2022 the FCA (29.75 million pounds) and PRA (18.9 million pounds) fined TSB a total of 48.65 million pounds after a 30% settlement discount. Its April 2018 migration failed immediately, disrupted branch, telephone, online and mobile banking for a significant share of its 5.2 million customers until December 2018, and TSB failed to manage the operational risks of outsourcing to a critical third-party supplier. TSB paid 32.7 million pounds in redress.
- Individual accountability: on 13 April 2023 the PRA fined TSB's former Chief Information Officer 81,620 pounds under Senior Manager Conduct Rule 2 for not taking reasonable steps to oversee the outsourced migration supplier. Operational resilience failures can follow senior managers personally.
- Critical third parties: designated CTPs are bound by six CTP Fundamental Rules and eight operational risk and resilience requirements, including incident management. Designation does not reduce firms' own responsibility for their outsourcing.
What it means for AI agents and non-human identities
Mapping under SYSC 15A.4.1R covers technology and information, and in practice the dependencies that break first in a cyber incident are often non-human: certificates, service accounts, API keys, OAuth integrations and now AI agents in customer and operations workflows.
- Map the identity layer as a dependency of every service: if the identity provider, privileged access tooling or secrets vault is lost, most services fail together. Treat identity recovery as a scenario in its own right. See the Financial Services Identity Security Guide.
- Machine credentials can breach a tolerance on their own: an expired certificate or revoked service account key can stop payments or trading. Include them in the map and the test plan. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
- Third-party NHIs belong in the register: material third-party arrangements usually run on API keys and OAuth grants; record which credentials each provider holds and how to revoke and reissue them quickly.
- AI agents in important business services: where an agent handles customer service, payments operations or fraud triage, map its model provider, tools, credentials and fallback process, and test the scenario where the agent must be switched off. The FCA's frontier AI materials of 2026 signal supervisory interest. See the AI Agents in Financial Services Security Guide.
- Incident thresholds: a compromise of a service account or agent credential that lets an attacker move money or data can meet the consumer harm threshold even without an outage.
Compliance steps
- Confirm the service list and tolerances are current. Re-run the annual review and confirm each tolerance is a clear metric with board approval.
- Close mapping gaps for technology and identity. For each important business service, list applications, infrastructure, identity providers, privileged accounts, service accounts, certificates, secrets stores, third parties and their sub-processors.
- Align recovery objectives. Check that recovery time and recovery point objectives for each mapped system fit inside the tolerance, including time to rebuild from clean backups after destructive malware.
- Test cyber scenarios. At minimum: ransomware with backup compromise, identity provider compromise, loss of a major cloud or SaaS provider, and a faulty security tool update. See the Security Tool Faulty Update Outage Playbook.
- Record lessons and remediation. Every test and real incident produces an action list with owners, dates and a re-test.
- Build the 2027 reporting process. Define who decides the threshold is met, how the 24-hour initial report is drafted and approved, how FCA Connect access works out of hours, and how the final report is assembled within 30 working days.
- Build the material third-party register. Identify material arrangements, gather the template data fields, and set triggers for notification on new and significantly changed arrangements. See the Third-Party Concentration Risk Guide.
- Refresh the self-assessment. Update it, keep every version for six years, and take it to the governing body for approval.
Framework mapping
| Requirement | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | EU DORA comparison |
|---|---|---|---|
| Important business services and tolerances | GV.OC-04 | CP-2 Contingency Plan | Critical or important functions |
| Mapping | ID.AM-01, ID.AM-02 | CM-8 System Component Inventory | ICT asset and dependency identification |
| Scenario testing | ID.IM-02 | CP-4 Contingency Plan Testing | Digital operational resilience testing |
| Third-party arrangements | GV.SC-07 | SA-9 External System Services | Register of information |
| Incident reporting | RS.CO-02 | IR-6 Incident Reporting | Major ICT-related incident reporting |
Detection and measurement
- Important business services with a tested severe but plausible cyber scenario in the last 12 months.
- Gap between tested recovery time and impact tolerance for each service.
- Percentage of mapped dependencies (including identity and machine credentials) with a named owner and recovery procedure.
- Open remediation actions from tests and incidents past their due date.
- Time from incident detection to threshold decision, measured in exercises against the 24-hour expectation.
- Material third-party arrangements recorded in the register with tested exit or substitution plans.
Common failure patterns
- Tolerances set to match current capability: setting the tolerance at whatever recovery already achieves, rather than at the point of intolerable harm.
- Mapping that stops at applications: identity, network, certificates and third-party sub-processors left off, so the map misses the shared dependencies that fail together.
- Testing only infrastructure failover: scenarios that assume clean data and working credentials, which a destructive cyber attack removes.
- Outsourcing without oversight: relying on a supplier's assurance of readiness without testing it, the failing the regulators found at TSB.
- Self-assessment as a document exercise: a polished annual pack with no evidence of tests, gaps or remediation, approved by a board that does not understand the dependencies.
Practitioner checklist
- Confirm each important business service has a board-approved, metric-based impact tolerance reviewed this year.
- Extend mapping to identity providers, privileged access, service accounts, certificates, secrets and APIs.
- Check recovery objectives of every mapped system fit inside the tolerance with margin.
- Run at least one destructive cyber scenario and one identity compromise scenario per year.
- Record lessons learned with owners and re-test dates after every test and incident.
- Design the 2027 incident process: threshold decision owner, 24-hour initial report, 30 working day final report.
- Build the material third-party register and notification triggers.
- Include AI agents and their providers in mapping and scenario testing where they support a service.
- Keep every version of the self-assessment for six years and evidence governing body approval.
Standards and references
- FCA Handbook: SYSC 15A Operational resilience
- Bank of England PRA: SS1/21 Operational resilience, impact tolerances for important business services
- FCA: PS21/3 Building operational resilience
- Bank of England PRA: PS7/26 Operational incident and third-party reporting
- FCA: PS26/2 Operational incident and third party reporting
- Bank of England: PS16/24 Critical third parties to the UK financial sector
- FCA: Operational resilience
- Bank of England: TSB fined 48.65m pounds for operational resilience failings
This guide summarises the UK PRA and FCA operational resilience requirements as of 27 October 2026 and is not legal advice. Related NHI Mgmt Group resources: Financial Services Cyber Regulation Map · DORA Guide · Major IT Outage Lessons Guide · Banking Cybersecurity Programme Guide