Suppose a UK bank runs its payments and online banking across a network built on equipment from one of the major infrastructure vendors. This scenario plays out over four months: 

• February: The vendor publishes a notice about a bug in one version of its software. Under certain conditions, the equipment stops passing traffic for several minutes. The notice names the affected version and the version that fixes it. 

• April: The bank upgrades to close a security vulnerability. The upgrade is planned, tested, and signed off. The version chosen is the one the February notice said was affected. The security advisory had been tracked; the bug notice had not. 

• May: On a Friday morning, the condition triggers. Card payments and online banking are unavailable for most of the morning. The outage is detected in seconds. It takes until the following week for the vendor to confirm the cause, and another day for someone to find the February notice. 

Under the rules that take effect on 18 March 2027, the bank files a report with the PRA. The form asks: 

• what caused the incident, and whether it came from a third party and, if so, which one 

• how much of the impact tolerance for payments was used 

• at the final phase, what lesson was learned and what is being done about it.  

The honest answers:  

• the cause was a software fault in a third-party product and the vendor had published it three months earlier 

• the payments tolerance was exceeded  

• the lesson is the bank had a process for its vendors' security notices and none for their operational bug notices.  

The PRA receives this as structured data alongside every other firm's reports and has said it will share anonymized aggregated findings on industry-wide trends. Nothing in this story involves an attacker. Under PS7/26 that makes no difference at all. The cause-type field on the form is built on the Financial Stability Board's incident taxonomy, and its drop-down runs to more than fifty root causes. Ten of them are types of cyber-attack. Others include “Change - Defect/Bug”, “3rd Party - Systems Issue” and “Software - Configuration”. The regulator has made room on the form for known vendor defects. The question for in-scope firms is whether they knew about the defect before they needed to report an incident on the form. 

The PRA published PS7/26 on 18 March 2026. It sets final rules for two things: reporting operational incidents and notifying and registering material third-party arrangements. The incident rules apply to UK banks, building societies, PRA-designated investment firms, UK branches of overseas banks, UK Solvency II insurers, and the Society of Lloyd's and its managing agents. 

An operational incident is a single event or a series of linked events that disrupts the firm's operations such that it either disrupts delivery of a service to an end user outside the firm, or affects the availability, authenticity, integrity or confidentiality of that end user's data. The definition does not mention a cause. The PRA was asked to add the word "unplanned" and declined. It was asked to limit the definition to important business services and declined that too, on the grounds that an incident can affect a service the firm never classified as important and still matter to the PRA's objectives. 

The PRA did say that a planned, controlled interruption where the risks are adequately managed is unlikely to meet the threshold for reporting. A routine upgrade carried out according to plan is not an incident. An upgrade that goes wrong can be. 

A firm reports when it reasonably believes an incident poses a risk to UK financial stability, to the firm's own safety and soundness, or to policyholder protection. Near-misses are not reportable. The report is a single form completed in three phases. The initial phase is due as soon as practicable, which the PRA expects to mean within 24 hours of the firm deciding the threshold has been met. The final phase is due within 30 working days of resolution, or 60 where the firm needs more time, including where it is waiting on a third party for information. 

Accountability sits with a named individual. The Chief Operations Senior Management Function (SMF24) holds overall responsibility for implementing the outcomes of the PRA’s incident reporting requirements, and for ensuring that the firm’s internal processes enable the accurate and timely reporting of operational incidents that meet the PRA’s thresholds. 

Many firms are building their implementation around the security operations center, because that is where incident detection already lives. The PRA's own illustrations point somewhere else. Of the four types of reportable incident SS1/26 gives as examples, only one is cyber-attack. The other three are process failures, system update failures, and infrastructure problems. SS1/26 even illustrates a “series of linked events” with a third-party provider outage caused by a pre-existing technical fault, which takes a bank’s payments platform offline.  

An outage like the one in the above scenario is not hard to detect. What is hard is knowing, before it happens, that the version you are running has a published fault in it, and knowing, after it happens, what that fault was. Security teams have both of those covered for vulnerabilities. For defects, there is usually no equivalent.  

The rules then expect the firm to go back to the vendor. Where an incident originates at a third party, the PRA expects the firm to take reasonable steps to obtain root cause information from that third party. The reporting templates carry the same expectation: the firm must take reasonable steps to get what it needs from third parties in order to complete them. The 60-working-day extension exists partly because the PRA knows this takes time. 

There is a plainer problem underneath the rules. For a vendor-originated incident, the questions on the form are the ones a firm least wants to answer badly. If the vendor had published the fault and the firm did not know, the cause was avoidable, the impact tolerance was spent on something the firm could have prevented, and the lesson is an admission. 

The second half of PS7/26 is third-party reporting. From March 2027, in-scope firms notify the PRA before entering into or significantly changing any material third-party arrangement, and submit a register of all of them once a year. This is scoped wider than what the consultation proposed: the draft would have limited notifications to arrangements needing a high degree of due diligence, and the final rule covers all of them. 

What counts as material is set by the PRA Rulebook and explained in the updated SS2/21. A third-party arrangement is material where a defect or failure in its performance could pose a risk to, or materially impair, the firm's safety and soundness, its policyholders' protection or, for the largest firms, UK financial stability.  

SS2/21 says that buying hardware, software or other ICT products is a third-party arrangement even though it is not outsourcing, and that firms must assess the materiality of every third-party arrangement regardless of whether it is outsourcing. Cloud and SaaS services supporting an important business service are listed as arrangements the PRA would generally expect to be material. 

The register then asks, for each material arrangement, whether it supports an important business service, when the firm last risk-assessed it and with what outcome, whether a senior manager signed it off, and where it ranks in the supply chain. The PRA kept the supply chain ranking despite objections because it wants to see the critical nodes. 

Consider what "outcome of the most recent risk assessment" means for a platform the firm runs at a version with a dozen open vendor-documented bugs against it. A risk assessment that does not know those bugs exist is not wrong, exactly. It is just not an assessment of the thing the PRA defined as material. 

Scope is not symmetric, and this trips people up. The third-party rules cover UK banks, building societies, PRA-designated investment firms, Solvency II insurers, Lloyd's, and credit unions with at least £50 million in assets. They exclude UK branches of overseas banks, which are in scope for incidents but not for third-party reporting. Intragroup arrangements are out unless the group provider has itself contracted with someone outside the group. 

In the opening scenario, the bank did not need a better incident response plan. It needed, in April, to know that the version it was about to install had a published bug in it. That knowledge had three places to be useful and it reached none of them. 

The first was the change record. The upgrade was raised to fix a vulnerability, and the change showed the vulnerability. It did not show the bug. If it had, the reviewer could have picked the fixed version instead, or delayed, or added a workaround. It would also have given the firm the evidence that matters most afterwards: that the risk was known and considered before the change ran. 

The second was the operations queue. A published bug in a product the firm runs, at a version the firm runs, supporting a business service the firm has mapped, should become a ticket with an owner and a due date in the same system the firm uses for everything else. Then it gets fixed on a quiet weekend rather than a Friday morning. 

The third was the report itself. If the bug had been tracked, the cause, origin and vendor fields are answered from the ticket. The root cause information the PRA expects the firm to obtain from the vendor is already attached, because the vendor published it. And the lesson identified is about scheduling, which is a real lesson rather than a confession. 

Security teams already have this pipeline for vulnerabilities. CVEs are published in a standard format, scored, pulled into scanners and routed to remediation. Operational bugs have none of that. Each vendor publishes them in its own way, in a knowledge base or release note or support bulletin, and no one aggregates them. Discovery depends on an engineer happening to read the right page. 

BugZero maintains an Operational Defect Database built from what vendors publish, matches it against the firm's own inventory in the ServiceNow CMDB, and raises the bugs that affect products and versions the firm actually runs as tasks in the firm's existing ServiceNow workflow, each with a risk score, alongside the CVEs the firm already tracks. Since it sits in the change process, the reviewer sees the bugs and the vulnerabilities for a target version in the same place, before the upgrade goes ahead. 

For a firm preparing for March 2027, that gives three things the rules will ask for: 

•  A change record that shows known bugs were considered before an upgrade. 

•  An incident record where the cause, origin, and vendor are already populated when the form opens.  

• A materiality assessment, for each platform on the register, that reflects what the vendor has said about it. 

None of that removes the obligation. What changes is whether the firm hears about the bug from its vendor in February or from an outage in May. 

1. PRA, PS7/26 — Operational resilience: Operational incident and third-party reporting, published 18 March 2026, effective 18 March 2027.  

2. PRA, SS1/26 — Operational resilience: Incident reporting, March 2026. PRA, SS2/21 — Outsourcing and third-party risk management, March 2026 update, effective 18 March 2027.  

3. FCA, PS26/2 — Operational Incident and Third-Party Reporting, March 2026, including the joint reporting templates at SUP 15 Annex 15.1R (incident) and SUP 15 Annex 16.1R (third-party notification and register).  

4. The opening scenario is illustrative and does not describe a real firm, vendor, product or defect.