For a smaller FCA-regulated firm on AWS, meeting the operational resilience rules comes down to four jobs: name your important business services, set an impact tolerance for each, map every AWS dependency behind them, and test that you can recover inside the tolerance. Running on AWS does not move the accountability: the FCA expects the firm to stay responsible for its own resilience, including when it relies on third parties. This guide turns the rules into steps a small team can follow.
What the rules require
The rules are in PS21/3 and Chapter 15A of the FCA’s SYSC sourcebook, as set out on the FCA’s operational resilience page. The head term is defined in our FCA operational resilience glossary entry; this post is about applying it on AWS.
| Requirement | What it means on AWS |
|---|---|
| Identify important business services | Pick the services whose failure would cause intolerable harm to customers or markets, for example “customers can send payments” |
| Set an impact tolerance | The most disruption each service can take, usually as a time limit, such as 4 hours |
| Map dependencies | List the people, processes, data, third parties and AWS services each service relies on, by Region and account |
| Test | Run severe but plausible scenarios and see whether recovery fits the tolerance |
| Self-assess and fix | Keep a written record, act on the gaps, and show the board the results |
Whether your firm is in scope depends on its type. According to the FCA, the rules apply to banks, building societies, PRA-designated investment firms, insurers, Recognised Investment Exchanges, enhanced scope SM&CR firms, firms authorised under the Payment Services Regulations 2017 and Electronic Money Regulations 2011, consolidated tape providers and qualifying cryptoasset firms. Smaller firms outside the list often meet the same expectations anyway, because clients and investors ask for them in due diligence.
Step 1: Choose your important business services
Start from the customer, not the system. A service is something a customer or market participant can do, not a server. Most small firms end up with three to six.
| Good choice | Poor choice |
|---|---|
| Customers can view and move their money | “The database” |
| We can execute client orders | “The trading application” |
| Clients can receive statements and valuations | “The reporting server” |
Step 2: Set an impact tolerance
The impact tolerance is the point beyond which disruption causes intolerable harm. Set it from what harm looks like for the customer: missed payments, unavailable funds, wrong prices. Express it in hours, and write down the reasoning, because the FCA expects the firm’s board to own it.
It then becomes the target for your technical design. A 4-hour tolerance for “send a payment” means the systems behind it need a recovery time objective comfortably under four hours, and a recovery point objective that avoids losing transactions. For how the two differ, see RTO vs RPO.
Step 3: Map each service to its AWS dependencies
This is where most small firms find surprises. For each important business service, record:
| Layer | Questions to answer |
|---|---|
| Compute and containers | Which accounts, Regions and Availability Zones does it run in? |
| Data | Which databases and buckets hold the data, and where are the backups and copies? |
| Network and DNS | Which load balancers, VPNs and DNS zones does traffic use? |
| Identity and keys | Which identity provider and encryption keys does it need to start? |
| Third parties | Which payment, identity-check or market-data suppliers does it call? |
| People | Who can run the recovery, and are they reachable at 3am? |
Two checks catch the common gaps. First, look for single points of failure: one Availability Zone, one Region, one engineer, one supplier. Second, check what recovery itself depends on. A failover plan stored only in a system that is down is not a plan. The shared responsibility model tells you which of these layers AWS looks after and which are yours.
Step 4: Test against severe but plausible scenarios
The rules ask firms to test whether they can stay within tolerance in severe but plausible scenarios. For an AWS-hosted service, a short list covers most of the ground.
| Scenario | What it tests |
|---|---|
| Loss of one Availability Zone | Whether Multi-AZ really works |
| Loss of a Region for several hours | Whether your recovery option fits the tolerance |
| Ransomware that deletes backups in the main account | Whether an isolated copy exists. See air-gapped backup |
| A key supplier or API is unavailable | Whether you have a manual fallback |
| Loss of the person who normally runs recovery | Whether the runbook works for someone else |
AWS offers tools that make some of this practical, including AWS Fault Injection Service for controlled fault experiments and a scenario library of prepared tests. Start in a non-production environment. Our post on how to test an AWS DR plan walks through a first drill.
A worked example
(Illustrative.) A 30-person e-money firm names “customers can send payments” as an important business service, with a 4-hour tolerance. Mapping shows the service runs in one London Region, with one RDS database in a single Availability Zone, a third-party identity-check API, and DNS managed by one engineer.
| Scenario test | Result | Gap |
|---|---|---|
| Database zone fails | 25 minutes to restore from a snapshot | Inside tolerance, but only just, and Multi-AZ is off |
| London Region unavailable | 9 hours to rebuild from backups | Breaches the 4-hour tolerance |
| Identity API down | No fallback | Payments blocked for new customers |
The fixes are ordinary engineering: turn on Multi-AZ, add a pilot light in a second Region defined in code, and agree a manual fallback with the API supplier. Re-testing the Region scenario then takes 1 hour 40 minutes. The firm now has a dated record of tolerance, mapping, test and fix, which is the evidence a regulator or client asks to see.
Where AWS helps, and where it doesn’t
AWS provides the building blocks: separate Availability Zones, multiple Regions, backup and replication services. Its 2022 guidance on UK operational resilience and outsourcing puts the split plainly: “Resiliency is a shared responsibility between AWS and the customer.” It predates the 2026 reporting rules below. In July 2026, HM Treasury designated AWS as a critical third party to the UK financial sector, which brings regulatory oversight of the provider, per the Bank of England. That does not change your own obligations.
Two dates matter. The FCA gave firms until 31 March 2025 to be able to operate their important business services within their impact tolerances. And the FCA’s new incident and third-party reporting rules, published as PS26/2 on 18 March 2026, come into force on 18 March 2027. Operational incident reporting applies to all firms with a Part 4A permission and to payment service providers. Third-party reporting applies to a narrower list that includes enhanced scope SM&CR firms, banks and authorised e-money and payment institutions, who must notify the FCA of new or significantly changed material third-party arrangements and submit a register of them annually. Check which category your firm falls into. For the FCA’s latest cloud and cyber signal, see The FCA’s Frontier AI Warning.
A practical order of work
| Week | Task |
|---|---|
| 1 | List important business services and draft impact tolerances for board review |
| 2-3 | Map AWS dependencies for each service, noting single points of failure |
| 4 | Fix the cheap gaps: Multi-AZ, backup copies in a second account, written runbooks |
| 5-6 | Run the first scenario tests and time the results |
| Ongoing | Re-test at least yearly and after major changes; update the self-assessment |
A Yemberzal Disaster Recovery Assessment does the mapping and recovery targets per system, proves them with a timed failover drill, and leaves you with the evidence in a form a board and a regulator can read.
