The PRA is making incident reporting more explicit and more operational
SS1/26 matters because it turns a familiar expectation, tell your regulators when something serious goes wrong, into a more structured operational discipline. The PRA is setting clearer expectations on what counts as an operational incident, when it crosses the reporting threshold, how firms should update the regulator as the situation evolves, and who should own the process internally.
That is a meaningful shift for banks, insurers and PRA-designated investment firms. In practice, the statement pushes operational resilience, cyber response, service management, compliance and regulatory reporting teams into the same room. A firm will not meet the standard just by having a policy document. It needs a reporting process that works while an incident is still unfolding.
What the new framework actually expects
The statement defines an operational incident broadly enough to catch both a single disruptive event and a series of linked events. It is not limited to formally designated important business services. If a disruption affects service delivery to an external end user, or compromises the availability, authenticity, integrity or confidentiality of end-user data, the incident can fall in scope even where the firm had not classified the affected service as important.
The reporting threshold is also deliberately judgment-based. Firms must report incidents that could pose a risk to financial stability for certain firms, to the firm's safety and soundness, or to policyholder protection for insurers. The PRA points firms to a practical set of lenses: contagion, reputation, legal and regulatory obligations, the ability to provide adequate services, the ability to safeguard data, and the firm's own internal incident classification and escalation. In other words, the regulator is asking firms to bring supervisory judgment much closer to their internal crisis process.
Why this changes incident response in practice
The phased reporting model is the part many firms will feel first. The PRA expects an initial report as soon as practicable after an incident meets threshold, and says it would generally expect that within 24 hours of the firm making that determination. After that, firms are expected to submit intermediate updates whenever there is a significant change in circumstances, and to complete a final report within 30 working days of resolution unless that is impracticable.
That means the operational challenge is not just identifying a serious incident. It is maintaining enough control-room discipline to refresh the supervisory picture as facts change. A new root cause, a worsening impact, activation of business continuity plans, an incident beginning to meet another authority's threshold, or even resolution itself can all trigger further reporting. Firms also need to remember that this regime does not replace Fundamental Rule 7 notifications or direct supervisory engagement where needed.
What firms should be doing before March 2027
The effective date is 18 March 2027, which gives firms time but not unlimited time. The right preparation is not to build a separate reporting silo. It is to test whether the existing incident lifecycle can support the PRA's requirements without confusion over threshold decisions, ownership, evidence and timing. The hardest point is often the handoff between incident management and regulatory reporting, especially where cyber, operations and compliance teams use different severity scales and governance routes.
In our view, firms should focus on four things now: align the incident taxonomy to the PRA definition, map internal severity levels to the PRA threshold lenses, define who can decide that an incident is reportable and who can file updates during a live event, and rehearse the phased reporting flow in tabletop exercises. The PRA also expects clear senior accountability, typically with the Chief Operations SMF holding overall responsibility where that role exists, even if that SMF does not personally approve each submission.