The short answer
Operational resilience is a firm's ability to prevent, adapt to, respond to, recover from and learn from operational disruption. In the UK, PRA SS1/21 and FCA PS21/3 require banks, insurers, payment firms and others to identify important business services, set impact tolerances, map and test them, and since 31 March 2025 stay within those tolerances.
On this page
- What is operational resilience?
- What are the FCA and PRA operational resilience rules?
- What is an impact tolerance?
- Operational resilience example: a payment firm
- What changed on 31 March 2025?
- What is the Critical Third Parties regime?
- What new reporting rules apply from March 2027?
- How does UK operational resilience differ from DORA?
- Where does testing evidence fit in operational resilience?
- Why Sovereign Secure
- Plan your next scenario test
Operational resilience is the ability of a firm to prevent, adapt to, respond to, recover from and learn from operational disruption. In UK financial services it is a binding requirement, not a good-practice aim: the Prudential Regulation Authority (PRA) and the Financial Conduct Authority (FCA) published their rules in March 2021, the rules have applied since 31 March 2022, and the transition period ended on 31 March 2025. Since then, in-scope firms must be able to keep each important business service within its impact tolerance through severe but plausible disruption.
What is operational resilience?
Operational resilience is the regulators’ name for keeping the services customers and markets rely on running through disruption, whatever the cause: a cyber attack, a supplier failure, a data centre outage or a bad software release. It differs from the disciplines it draws on:
- Business continuity recovers processes and systems after an event.
- Cyber security tries to stop attacks happening.
- Operational resilience assumes disruption will happen and asks whether customers still get the service they depend on, within a limit the board has approved.
What are the FCA and PRA operational resilience rules?
The PRA, the FCA and the Bank of England (for financial market infrastructures) published their final rules together on 29 March 2021.
| Regulator | Documents | Who is in scope |
|---|---|---|
| PRA | Policy Statement PS6/21, Supervisory Statement SS1/21, and the Operational Resilience Parts of the PRA Rulebook | UK banks, building societies, PRA-designated investment firms, UK Solvency II insurers, and Lloyd’s and its managing agents |
| FCA | Policy Statement PS21/3 “Building operational resilience”, with rules in SYSC 15A of the FCA Handbook | Banks, building societies, PRA-designated investment firms, insurers, recognised investment exchanges, enhanced scope SM&CR firms, and payment and e-money firms authorised or registered under the Payment Services Regulations 2017 and Electronic Money Regulations 2011 |
| Bank of England | Operational resilience policy for financial market infrastructures | Recognised payment systems, central counterparties and central securities depositories |
Dual-regulated firms meet both sets of rules. The FCA’s operational resilience page lists the current scope, which now goes beyond the 2021 list, for example to consolidated tape providers.
What do the rules require?
| Requirement | What it means in practice |
|---|---|
| Identify important business services | Services provided to external end users whose disruption could cause intolerable harm (FCA) or threaten safety, soundness or stability (PRA). A service is something a customer receives, such as “make a payment”, not a system |
| Set impact tolerances | A maximum tolerable level of disruption for each service, with at least a time-based metric |
| Map the service | The people, processes, technology, facilities and information needed to deliver each service, including third parties |
| Scenario testing | Testing whether you can stay within tolerance in severe but plausible scenarios, such as a cyber attack or the loss of a key supplier |
| Remediate | Act on the vulnerabilities that mapping and testing reveal |
| Communications | Internal and external communication plans for when disruption happens |
| Lessons learned | A lessons-learned exercise after testing and after real incidents |
| Self-assessment | A written self-assessment, kept up to date and available to the regulator |
| Governance | Board approval of the services, tolerances and self-assessment, reviewed at least once a year and after material change |
What is an impact tolerance?
An impact tolerance is the maximum tolerable level of disruption to an important business service, measured as a length of time plus any other useful metrics, such as the number of customers affected or the value of transactions delayed. It is set at the point beyond which harm becomes intolerable, so it is an outer limit rather than a target: internal recovery targets normally sit inside it.
A firm can meet every system recovery target and still breach a tolerance, so the difference matters.
| Measure | Level | Question it answers |
|---|---|---|
| Impact tolerance | Business service | How long can customers be without this service before the harm is intolerable? |
| Recovery time objective (RTO) | System or process | How quickly should this system be back after an outage? |
| Risk appetite | Firm | How much risk of disruption are we willing to accept? |
Risk appetite deals with likelihood. An impact tolerance assumes the disruption has already happened and asks only whether you can stay within the limit.
Operational resilience example: a payment firm
Here is how the rules work for one important business service at a hypothetical UK e-money firm. It is an illustration, not a client case, and the regulators do not set tolerance values: each firm’s board sets its own.
| Step | What the firm does | In this example |
|---|---|---|
| 1. Identify the important business service | Name a service a customer receives, not a system | “Customers can send payments from their e-money account” |
| 2. Set the impact tolerance | Fix the point at which harm to customers becomes intolerable, with at least a time-based metric | A maximum number of hours without outbound payments, plus a cap on the number of customers left unable to pay, approved by the board |
| 3. Map the service | Record the people, processes, technology, facilities, information and third parties it depends on | Mobile app and API, the payments platform hosted with a cloud provider, the sponsor bank’s Faster Payments connection, a fraud screening supplier and the payments operations team |
| 4. Run a severe but plausible scenario test | Test whether the service stays within tolerance | Ransomware encrypts the payments platform at the start of a working day, and recovery has to come from backups |
| 5. Remediate | Fix the vulnerabilities the test reveals | The test shows the backups share administrator credentials with production, and the manual payment fallback has never been rehearsed |
| 6. Record it in the self-assessment | The board approves the results, the remediation plan and the date the scenario will be run again | Separate backup credentials, a rehearsed manual fallback and a repeat test once both are fixed |
Two things stand out. The tolerance comes from the harm to customers, not from how quickly IT says it can recover, so a recovery time objective that looks comfortable on paper can still breach it. And mapping brings in third parties, such as the cloud provider and the sponsor bank, that the firm still has to manage through its third-party risk management programme.
What changed on 31 March 2025?
The transition period ended. Since 31 March 2025, firms must be able to remain within the impact tolerance for each important business service in severe but plausible scenarios, and supervisors test that claim against evidence: the self-assessment has to show real scenario testing, the vulnerabilities it found and what was done about them. The FCA also uses self-assessment questionnaires: CQUEST for cyber resilience, run with the PRA, and ORQUEST for wider operational resilience.
What is the Critical Third Parties regime?
The Critical Third Parties (CTP) regime lets UK regulators oversee technology and other providers whose failure could threaten financial stability or confidence. It comes from the Financial Services and Markets Act 2023. The PRA, FCA and Bank of England published the rules on 12 November 2024 (PRA PS16/24 and FCA PS24/16, with Supervisory Statement SS6/24), and they took effect on 1 January 2025.
The rules apply only once HM Treasury designates a provider. The first designations were announced on 10 July 2026 and took effect on 13 July 2026:
- Microsoft Ireland Operations Limited
- Google Cloud EMEA Limited
- Amazon Web Services EMEA SARL
- Oracle Corporation UK Limited
Once designated, a CTP must meet the CTP Fundamental Rules and operational risk and resilience requirements for the services it provides to the sector, run scenario testing and incident management playbook exercises, and report serious incidents to the regulators and the firms affected.
The regime does not move accountability: a bank whose payments service runs on a designated cloud provider still has to keep that service within tolerance and manage the outsourcing under its existing rules, through its third-party risk management programme.
What new reporting rules apply from March 2027?
On 18 March 2026 the FCA published PS26/2 and the PRA published PS7/26 on operational incident and third-party reporting, with an updated version of the PRA’s outsourcing statement, SS2/21. The new requirements apply from 18 March 2027.
| Requirement | What firms must do | Who is covered (FCA) |
|---|---|---|
| Operational incident reporting | Report incidents that meet set thresholds, through a single submission whichever regulator the report is for | All firms with a Part 4A permission, payment service providers, recognised investment exchanges, registered trade repositories and registered credit rating agencies |
| Material third-party arrangements | Notify new material arrangements and significant changes, and keep a register submitted once a year | A narrower group including banks, building societies, Solvency II firms, enhanced scope SM&CR firms, large CASS firms and authorised payment and e-money institutions |
Good service mapping already shows which third parties each important business service depends on, which gives the register a head start.
How does UK operational resilience differ from DORA?
DORA is the EU’s Digital Operational Resilience Act, Regulation (EU) 2022/2554, which has applied to EU financial entities since 17 January 2025. UK groups with regulated entities in the EU usually have to meet both regimes, and the two do not map one to one.
| Aspect | UK regime | DORA |
|---|---|---|
| Legal basis | PRA Rulebook and FCA Handbook | Directly applicable EU regulation |
| Applies to | UK-authorised firms in scope of SS1/21 and SYSC 15A | EU financial entities, including EU subsidiaries of UK groups |
| Organising idea | Important business services and impact tolerances | ICT risk management across five pillars |
| Third-party oversight | Critical third parties designated by HM Treasury | Critical ICT third-party providers designated by the European Supervisory Authorities |
| Threat-led testing | CBEST for firms chosen by the regulators | Threat-led penetration testing at least every three years for entities identified by their regulators |
| Key date | Tolerances met by 31 March 2025 | Applied from 17 January 2025 |
Our guide to DORA regulation covers the EU side, including the register of information and incident reporting.
Where does testing evidence fit in operational resilience?
Scenario testing needs evidence, and different kinds of testing answer different questions. None of them alone proves you can stay within tolerance.
| Evidence | What it shows | Where it helps |
|---|---|---|
| Tabletop exercise | Whether people, decisions and communications work under a realistic scenario | Scenario testing, lessons learned, communications plans |
| Penetration testing | Exploitable weaknesses in the systems that support an important business service | Identifying vulnerabilities to remediate |
| Red team assessment | Whether you detect and respond to a realistic, goal-led attack | Severe but plausible cyber scenarios |
| Vulnerability scanning | Known weaknesses across the estate, run regularly | Ongoing assurance between tests |
| Business continuity exercising (ISO 22301) | Whether continuity plans recover services as designed | Recovery strategies and plan testing |
A cyber tabletop exercise is often the cheapest way to start testing a cyber scenario against a tolerance. A red team assessment goes further by testing detection and response against a live attack path. For recovery planning, ISO 22301 certification gives a structured business continuity management system, and ISO 27001:2022 controls A.5.29 (information security during disruption) and A.5.30 (ICT readiness for business continuity) link the two. For the plans themselves, our free business continuity plan template covers impact analysis, recovery objectives and exercising.
Why Sovereign Secure
Your board owns the important business services and tolerances. Our part is independent evidence for the programme.
- Penetration testing and red teaming of the web, API, cloud and network systems behind your important business services, plus regular vulnerability scanning between tests.
- Payments expertise. We are a PCI SSC Qualified Security Assessor (QSA) company, Qualified PIN Assessor (QPA) and Card Production Security Assessor (CPSA), and a member of the PCI SSC Global Executive Assessor Roundtable for 2026 to 2028. See how we work with banks and card issuers and fintech and payments firms.
- ISO 27001 certified, with ISO 22301 and ISO 27001 consultancy. Certification audits are carried out by our partner certification body, MQA International.
- A UK company since 2012, headquartered in Accrington, Lancashire, with offices in Los Angeles, Singapore, Dubai and Dhaka.
Plan your next scenario test
If you are preparing scenario testing for an important business service, tell us which systems and suppliers sit behind it and the scenario you want to test. We will scope penetration testing or a red team assessment around it. Contact us or call +44 161 523 5276.
Your next step
- ISO 27001 checklistClause-by-clause readiness and a Stage 1 and Stage 2 audit checklist, free in Excel.Get the checklist
- Statement of Applicability templateAll 93 Annex A controls in a free spreadsheet, with a worked example.Get the SoA template
- Get an ISO quoteConsultancy from an ISO 27001-certified firm, with audits through our partner certification body, MQA International.Get an ISO quote
Last reviewed October 2026 by the Sovereign Secure assessment team.
