5 minute read
The FCA recently published PS26/2 Incident Reporting Rules, which introduces new requirements around operational incident reporting. The rules come into force on 18 March 2027, which gives firms less than 12 months to get their processes in order.
In this article we walk through what the regulation actually says, why it matters for business continuity professionals specifically, and how we have been thinking about this at Battleground.
What the Regulation Says
PS26/2 requires almost every FCA-regulated firm to report significant operational incidents to the regulator. The obligation covers all firms with a Part 4A permission, so the net is very wide.
The reporting obligation is triggered when a firm reasonably believes an incident meets one or more of three thresholds:
- The incident poses a risk of causing intolerable harm to consumers from which they cannot easily recover
- The incident threatens the safety and soundness of the firm or other market participants
- The incident threatens market stability, market integrity or confidence in the UK financial system
Most firms will submit what the FCA calls a standard report. A smaller group of larger and more complex firms, including banks, building societies and Solvency II firms, will be subject to enhanced reporting with more detailed lifecycle submissions.
The Bit That Really Matters
What caught our attention when we read through the guidance is this: the obligation to report triggers when you reasonably believe a threshold has been met. Not when it is confirmed. Not when your impact tolerances have been breached.
That is a really important distinction. If you get to the point where your impact tolerances are already breached and you have not yet reported anything, you have potentially failed on two counts. You have breached your operational resilience obligations under the existing framework, and you have also failed to report an incident under PS26/2 at the point when you should reasonably have identified it.
The FCA guidance is explicit that firms are expected to report before impact tolerances are breached, not after.
It is also worth noting that an incident does not need to affect an Important Business Service to be reportable. A cyber attack compromising customer data, a cascade failure in a non-critical system, an IT outage affecting services the firm has not classified as important business services: all of these can meet a threshold and require reporting.
What This Means Internally
The regulation creates a practical internal challenge that I do not think all firms have fully thought through yet.
If the obligation triggers on reasonable belief rather than confirmed impact, then someone inside your organisation needs to be able to identify that belief in real time, under pressure, and escalate it quickly. That is not a compliance function. That is an operational resilience and business continuity function.
The question for every BC and resilience professional reading this is: does your organisation currently have a process that allows anyone to flag a potential threshold-crossing incident, get it in front of the right people quickly, and create a record of what was reported and when?
If that process does not exist, or if it relies on someone knowing who to call and having the confidence to make that call at 11pm on a Friday, then there is a gap.
How We Have Approached This at Battleground
At Battleground, we have been mapping this out and working through what it means for how we supports our clients.
The way we have built it is straightforward. Anyone part of a business continuity plan can now report an incident directly in Battleground, via mobile or web. They do not need to be certain that a threshold has been met. If they think something may have crossed a threshold, they report it. That is exactly what the regulation asks for.
That report is immediately escalated to senior management, who can review it and decide whether a business continuity plan needs to be activated for their area. They have the information, they have the context, and they make the call.
Everything is logged throughout. The initial report, the escalation, the decision made. So if a regulator ever asks you to demonstrate that you identified an incident, assessed it and acted appropriately, the evidence trail is there.
A Cultural Point
One thing we must flag to any BC or resilience professional reading this, is the shift that this regulation requires is not just a process change, it is a cultural one.
People in organisations are often reluctant to raise an alarm until they are sure something is serious. Nobody wants to be the person who triggered a full incident response for something that turned out to be nothing.
But the FCA are not asking for certainty. They are asking whether, at the time, you reasonably thought a threshold may have been met. Reporting something internally that does not end up leading to plan activation is not a failure. It is exactly what good practice looks like under this framework.
The firms that will struggle with PS26/2 are not the ones that over-report internally. They are the ones where something happened, nobody was sure it was serious enough to flag, and by the time anyone acted the window had already closed.
If you want your teams to be able to report a suspected incident from mobile or web, trigger the right continuity plan, and automatically capture the evidence regulators will expect from March 2027, contact Battleground and let’s start planning how to embed this in your organisation.
