PRA SS1/26: The UK's Answer to DORA

On 18 March 2026, the Prudential Regulation Authority published SS1/26 — a new supervisory statement that puts operational incident reporting and third-party risk obligations on a formal statutory footing for UK financial services firms.

The rules take effect on 18 March 2027. That is twelve months. Not a roadmap. Not a consultation. A deadline.

For compliance, risk, and operations teams in UK-regulated financial services, this is the moment to stop watching the regulatory horizon and start building the programme.

The headline is simple. UK financial services firms must now report operational incidents to the PRA within a defined timeframe, maintain detailed registers of material third-party arrangements, and submit those registers to the regulator so it can map shared dependencies across the sector.

The detail is what matters.

On incident reporting: firms must submit an initial report to the PRA as soon as reasonably practicable — and the expectation is within 24 hours of determining that an incident has met the reporting threshold. That threshold covers disruptions that pose a risk to the firm's safety and soundness, policyholder protection, or UK financial stability. It also covers incidents that affect the availability, authenticity, integrity, or confidentiality of data belonging to external end users. The incident does not need to have affected an important business service to trigger the obligation. The assessment must happen regardless.

On phased reporting: SS1/26 sets out a phased structure — initial report, intermediate updates as the incident develops, and a final report once it is resolved. Each phase has its own requirements. This is not a single notification and done. It is an ongoing reporting obligation throughout the life of the incident.

On third-party risk: the updated SS2/21, published alongside SS1/26 as part of PS7/26, significantly strengthens the PRA's expectations around outsourcing and third-party risk management. Firms must maintain a register of material third-party arrangements — mapping what each provider does, how it connects to important business services, what dependencies exist, and what due diligence has been conducted. Critical arrangements must be reported to the PRA directly, giving the regulator visibility of concentration risk across the sector.

On accountability: the Chief Operations Senior Management Function (SMF24), where it exists, holds overall responsibility for implementing the incident reporting requirements and ensuring internal processes are accurate and timely. Where SMF24 does not exist, firms must clearly allocate responsibility to a named senior manager. This is personal accountability, not organisational accountability. That distinction matters. 

Anyone who has been tracking the EU's Digital Operational Resilience Act will find SS1/26 immediately familiar. The structural logic is identical: mandate operational incident reporting to the regulator, require detailed third-party registers, and give supervisory authorities the data they need to understand systemic concentration risk across the financial system.

That convergence is not accidental. UK and EU policymakers are responding to the same underlying risk — that financial services firms are deeply interconnected through shared technology providers, and that a single provider failure can cascade across the sector in ways that no individual firm's risk register can capture. The PRA's explicit goal in collecting material third-party registers is to build exactly that sectoral view.

It is also worth noting that SS1/26 does not stand alone. The FCA published its parallel rules simultaneously — PS26/2 — covering FCA-regulated firms outside PRA scope, including payment service providers and other enhanced SM&CR firms. The two regimes share common definitions, aligned templates, and a single reporting portal. The direction of travel is a unified UK operational resilience reporting framework, with the PRA and FCA advancing it in lockstep.

For dual-regulated firms or UK firms with EU operations, this creates a practical compliance challenge. DORA is already in force. SS1/26 takes effect in twelve months. The requirements are similar enough that a well-designed programme should be capable of meeting both — but that only holds if the programme is built on a connected data architecture rather than two parallel manual processes.

The firms that treated DORA as a template and built sustainable infrastructure will find SS1/26 manageable. The firms that treated DORA as someone else's problem are now facing two frameworks simultaneously, with less time to respond.

The PRA's 24-hour incident reporting window is deceptively demanding. Most firms have internal incident management processes. Far fewer have processes designed to produce a regulatory-quality submission within 24 hours of incident classification, while simultaneously managing the incident itself.

That gap is structural. It cannot be closed by working harder in the moment. It requires processes and tooling that capture the right data in real time, structure it against the PRA's reporting fields, and surface it to the people who need to approve and submit it — without pulling the operations team away from the recovery effort.

The third-party register obligation has a parallel gap. The PRA's expectations in SS2/21 are specific: firms must document what each material third party does in the organisation, how it connects to important business services, what dependencies exist upstream and downstream, and what due diligence has been conducted and when. For most firms, that information is currently distributed across procurement systems, vendor contracts, IT asset registers, and operational resilience mapping documents — if it exists at all in structured form.

Assembling a credible register from that starting point in twelve months is achievable. Maintaining it continuously, updating it as arrangements change, and producing it accurately on demand is a different task entirely. That requires a single connected environment, not a pre-submission consolidation exercise.

We have spent 19 years building GRC infrastructure for regulated financial services firms. What SS1/26 describes is not a new category of problem. It is a formalisation of obligations that mature risk and compliance functions have been working toward — and that many are still not adequately equipped to meet.

The operational incident reporting requirement is solvable. Firms need real-time visibility of their operational environment, clear classification criteria mapped to the PRA's thresholds, and a structured reporting workflow with named accountability at each stage. SureCloud's operational resilience capability supports exactly this — with audit trails, escalation paths, and reporting outputs that are regulator-ready, not retrospectively reconstructed.

The third-party register requirement is where the greater operational challenge sits. Building a register once is a project. Keeping it accurate, connecting it to the risk register and compliance programme, and having it available for regulatory submission at any point — that is an ongoing programme. Our TPRM capability delivers 50% faster third-party risk assessments and 40% faster third-party onboarding, with a complete audit trail maintained throughout.

The firms that will find SS1/26 manageable are those that treat it not as a compliance exercise to complete before March 2027, but as a structural question about how they manage operational and third-party risk on a continuous basis.

1. Assess your incident reporting readiness against the 24-hour threshold. Run a simulation: if a material operational incident occurred today, could your firm produce a PRA-quality initial report within 24 hours while managing the incident? If the honest answer is uncertain, the gap is in process design, not effort.

2. Audit your material third-party inventory against SS2/21's requirements. The PRA's expectations are specific — what the provider does, how it connects to important business services, the nature of the dependencies, the due diligence record. Map where that information currently lives. Where it is incomplete, fragmented, or held only in documents rather than a structured system, that is the remediation scope.

3. Assess whether your current programme can meet both DORA and SS1/26 without duplication. For firms with EU obligations, building two parallel manual compliance processes is not sustainable. A connected GRC platform that maps controls once and applies them across frameworks is the only architecture that holds up at this level of regulatory complexity.

SS1/26 gives firms twelve months. That is enough time to build a programme that works — if the work starts now.

1. Published: 18 March 2026, as part of PS7/26
2. Effective date: 18 March 2027
3. Scope: All UK banks, building societies, PRA-designated investment firms, branches of overseas banks, UK Solvency II firms, the Society of Lloyd's and managing agents
4. Key obligation 1: Operational incident reporting to the PRA within 24 hours of threshold determination, with phased updates throughout the incident lifecycle
5. Key obligation 2: Maintenance and regulatory submission of a material third-party arrangements register, covering service function, business service dependencies, and due diligence records
6. Accountability: Chief Operations SMF24 (or named equivalent) holds personal responsibility for implementation
   
   

Related documents: PS7/26 — policy statement (PRA) · SS1/26 — incident reporting supervisory statement · SS2/21 — outsourcing and third-party risk management · FCA PS26/2 — parallel FCA rules for FCA-regulated firms not in PRA scope