UK operational resilience rules require financial firms to show that they can keep their most important services running through severe disruption, or bring them back within a limit they have set in advance. The rules were introduced by the Financial Conduct Authority and the Prudential Regulation Authority, came into force on 31 March 2022 and gave firms a three-year transitional period that ended on 31 March 2025. Since then, firms have been expected to remain within their impact tolerances, not merely to be working toward them. Storage and recovery are where that expectation is frequently won or lost.
This post explains the main concepts in the rules, how they translate into requirements for storage and backup, and what the regime for critical third parties adds. It is a general overview and not regulatory advice.
The FCA rules, set out in policy statement PS21/3, apply to banks, building societies, designated investment firms, insurers, recognised investment exchanges, enhanced-scope firms under the senior managers regime and payment and electronic money institutions, among others. The PRA's expectations for the firms it supervises are in supervisory statement SS1/21. Firms outside the formal scope often adopt the same approach because their customers or group policies require it.
The rules are built on a small number of concepts. Each has a direct reading for the systems that hold data.
| Concept | What the rules mean by it | Storage reading |
|---|---|---|
| Important business service | A service whose disruption could cause intolerable harm to clients or risk to market stability | Identify which data sets and storage systems each service depends on |
| Impact tolerance | The maximum tolerable disruption, measured in time and other metrics | A hard ceiling on recovery time for the data behind the service |
| Mapping | Documenting the people, processes, technology, facilities and information needed | Storage, backup, network paths and suppliers recorded per service |
| Scenario testing | Showing the firm stays within tolerance in severe but plausible scenarios | Restore tests that assume data loss or corruption, not just failover |
| Self-assessment | A written record approved and reviewed by the governing body | Test results and known gaps described in terms a board can sign |
An impact tolerance is set for a service as the customer experiences it. A recovery time objective is set for a system. The tolerance for a payments service might be a number of hours. Within that time the firm has to detect the problem, decide to act, restore the data, rebuild or fail over the systems, validate them and reopen the service. Storage restore time is one component, and it has to fit with room to spare.
That arithmetic exposes weak points quickly. A backup that takes longer to restore than the tolerance allows cannot support the service, however reliable it is. The posts on restore speed as the new RTO and mass restore planning explain how to measure restore throughput and what limits it when many systems are restored at once.
The scenario testing requirement is where storage design is tested hardest. Regulators expect firms to consider scenarios in which data is corrupted or destroyed, including by a cyber attack, and not only scenarios in which a site is lost. Replication protects against the loss of a site. It does not protect against corruption, because the corruption is replicated too. A scenario of that kind needs a copy that the incident could not reach and a tested path to restore from it.
Testing has to be realistic to count. That means restoring a representative service end to end, including the dependencies listed in the post on backup recovery dependencies, and recording how long each stage took. The post on ransomware recovery exercises describes how to structure such a test and what to capture from it.
Mapping is meant to be detailed enough to find vulnerabilities and fix them. For storage that includes which systems hold the primary data for each important business service, where the backup copies are, which network paths a restore would use, which credentials and key services are needed and which suppliers are involved. Shared platforms complicate this: when one storage system supports several important services, its failure affects all of them at once, and a restore queue forms. The mapping should show that concentration so that tolerances can be tested together.
A separate regime addresses providers on which the financial sector as a whole depends. Its rules took effect on 1 January 2025. The Treasury decides which providers to designate, on the regulators' recommendation, and the first designations came into force on 13 July 2026, covering four large cloud and technology providers. Designation places resilience duties on the provider. It does not move responsibility away from the firm, which remains accountable for staying within its own tolerances whatever its providers do.
For storage decisions, the regime underlines a question the rules already posed: how would an important business service be recovered if a provider it depends on were unavailable for longer than the tolerance? Firms answer that with exit plans, with copies of critical data held outside the provider and with the ability to run the service elsewhere. The post on sovereign disaster recovery discusses recovery sites under the firm's own control, and UK technical guidance on backups is summarized under NCSC.
Scality RING is software-defined object and file storage that runs on standard x86 servers in facilities the firm controls. It exposes an S3 interface and supports versioning and S3 Object Lock, so backup copies and records can be held under retention that is protected until it elapses, which provides the copy that a corruption scenario cannot reach. RING can span multiple sites, with erasure coding and replication selectable per policy, and self-healing runs as a background task.
RING distributes data across nodes and scales from petabytes upward, with nodes added to a live system without taking the namespace offline. It is multi-tenant, with accounts, buckets and policy-based isolation, so data for different services can be separated and mapped. Metrics and logs are kept locally and support the evidence a self-assessment needs.
The rules do not prescribe technology. They ask firms to decide how much disruption is tolerable and then to prove they can stay inside it. For most services that proof comes down to how quickly clean data can be put back, and that is decided by storage design long before any incident.