FCA PS26/2: What the New Operational Incident Reporting Rules Mean for Smaller Firms

Which of the two regimes actually applies to you

PS26/2 contains two distinct obligations with two distinct populations and blending them is the most common error I see when firms first read it.

Operational incident reporting applies broadly: firms with Part 4A permissions, payment service providers, UK recognised investment exchanges, registered trade repositories and registered credit rating agencies. If you hold a Part 4A permission, you are almost certainly in scope, regardless of your size. There is no small-firm exemption.

Material third party reporting applies to a narrower population: enhanced-scope SM&CR firms, banks, designated investment firms, building societies, Solvency II firms, CASS large firms, UK recognised investment exchanges, authorised payment institutions and electronic money institutions, and consolidated tape providers.

The point worth pausing on is that last list. Authorised payment institutions and e-money institutions are in scope for third party reporting even though many of them are small, founder-led and nowhere near enhanced SM&CR status. A payments firm of thirty people can find itself inside both regimes while a considerably larger investment firm sits inside only one. Do not assume your obligations from your headcount or your revenue. Check them against your permissions.

So, the first task is unglamorous and takes an afternoon: establish precisely which of the two regimes you fall into, write the conclusion down, and have the board note it. Firms that skip this step tend to discover the answer during an incident, which is the worst possible moment to find out.

What counts as an operational incident?

The definition is broad. An operational incident is a single event, or a series of linked events, which disrupts your operations and either disrupts the delivery of a service to external end users or impacts the availability, authenticity, integrity or confidentiality of information or data relating or belonging to them. Note the fourth limb. Confidentiality is what brings data loss inside the definition even where nothing stopped working.

Two features of that definition deserve attention.

The first is "a series of linked events". Cumulative impact counts, and the guidance describes connected events that often share the same root cause. Three small outages in a fortnight that individually look trivial may, taken together, cross the threshold, provided something links them. Three unrelated outages are three incidents. This is the sort of pattern that firms without a decent incident log simply cannot see. Each event gets fixed, nobody joins them up, and the aggregate picture never reaches anyone with authority to assess it.

The second is that the test is about harm, not about cause. You are not reporting because a server failed. You report when you reasonably believe the incident poses a risk of intolerable harm to consumers, a risk to the safety and soundness of your firm or other market participants, or a risk to market stability, integrity or confidence in the UK financial system. A minor technical fault with serious customer consequences is reportable. A dramatic-looking internal failure with no external effect may not be. That is a judgement, not a calculation. Which brings us to the part that matters most.

The 24-hour clock is a governance problem, not a reporting one.

Reports must be submitted as soon as practicable. The FCA expects that to mean within 24 hours of the firm determining that the threshold has been met, and it says plainly that firms should not default to waiting the full 24 hours. Payment service providers face a tighter obligation still: four hours, and importantly that clock runs from detection, not from the point of determination.

Read those two sentences again, because the distinction between them is where firms will get caught.

For most firms, the 24 hours begins when someone decides the threshold is met. That creates an obvious question, and the FCA will ask it: who is that someone, and how quickly can they be reached? If your incident escalation route depends on a single individual who happens to be on a flight, or if the decision effectively must wait for a scheduled management meeting, then your clock is being started late and you cannot demonstrate otherwise. Deliberately delaying the determination in order to delay the report is not a strategy any board should be comfortable signing off.

For payment service providers the problem is sharper again. Four hours from detection is not enough time to convene anyone. It requires a pre-agreed decision framework and named individuals with standing authority to act on it, at any hour.

This is why I would treat PS26/2 as a governance and decision-rights exercise rather than a compliance one. The deliverable is not a template. It is a documented answer to three questions: who decides, on what criteria, and how do we prove afterwards when the clock started.

The regime also distinguishes between standard reporting, a single, relatively short submission that will cover most smaller firms and enhanced reporting, a fuller lifecycle process involving an initial report, intermediate updates as the picture develops, and a final report after resolution. The final report is due within thirty working days of resolution, extendable only in exceptional circumstances.

Check this tier carefully, because it is a third population and it is different from either of the two above. Enhanced reporting captures enhanced scope SM&CR firms, banks, designated investment firms, building societies, Solvency II firms, CASS large firms, UK RIEs, registered trade repositories, registered credit rating agencies and, significantly, all payment service providers. Size does not come into it. The thirty-person payments firm in the example above is not only inside both regimes, but also an enhanced reporter running a four-hour clock from detection and a three-phase reporting lifecycle after it.

Your report will not be read on its own.

There is a consequence of the unified regime that is easy to miss. A single definition, a single portal and standard templates mean that for the first time the FCA can line up reports about the same event from every firm that experienced it.

Many serious incidents at smaller firms do not originate at smaller firms. They originate at a cloud host, a core banking platform, a payments processor, a market data feed. When one of those fails, it does not fail for you alone. It fails for everyone who depends on it, and the affected population will arrive in the FCA's inbox across a single afternoon.

This is not an inference about the regulator's intentions. The FCA has said it wants visibility of the systemic risks that arise when many firms rely on the same third party, and that the annual register is there to help identify systemic third-party risk, particularly where many firms depend on a small number of providers. Seeing the whole affected population at once is the design, not a side effect.

What follows from that is my reading rather than something PS26/2 states. Your submission sits inside that group, with a timestamp on it, and the time of detection is a required field even in the short standard report. If a dozen firms hit by the same outage have reported by mid-afternoon and yours arrives the following morning, nobody needs to examine your escalation route to form a view about it. The comparison does that work on its own.

None of which changes the rule, but it changes how a board should treat the deadline. Twenty-four hours is an outer limit, not a target. And the benchmark you are being measured against is one you will never see, which is a good argument for building the capability to decide quickly rather than the capability to decide eventually.

Material third party arrangements are broader than outsourcing.

If you are in scope for the third-party obligations, note that the concept is deliberately wider than the outsourcing arrangements you may already track. It captures any service or product provided to your firm where disruption could cause intolerable harm to clients, threaten the stability of the financial system, or undermine your ability to meet your regulatory obligations. Cloud hosting, data centres, cybersecurity services, real time market data feeds, software and infrastructure can all qualify. Intragroup arrangements fall inside the definition too, though most firms only have to report them where an external third-party dependency exists behind them. UK RIEs are the exception and report intragroup arrangements regardless.

The obligations are twofold: notify the FCA of new material arrangements and of significant changes to existing ones, engaging early rather than after contracts are signed; and maintain a register of those arrangements, submitted annually. The FCA has not set a notification deadline but expects to hear from you before you are contractually or operationally committed. The register is submitted when the FCA opens the annual window, with ninety calendar days to respond and data accurate as of 31 December the previous year.

Firms that already maintain a decent outsourcing register are perhaps a third of the way there. Firms relying on a procurement spreadsheet and institutional memory are not and should start now. Building the register is a matter of weeks, while establishing who owns each relationship and what the exit route looks like takes considerably longer.

What to do between now and March 2027

Six months of preparation, spread sensibly, is comfortable. Six weeks is not. A reasonable order of work:

• Establish scope. Which regime or regimes apply, on the basis of your permissions rather than your size. Record the conclusion.
• Define the threshold in your own terms. Translate the FCA's harm-based test into criteria your own people can apply at speed: customer numbers affected, services unavailable, data compromised. Generic thresholds do not survive contact with a real incident.
• Name the decision-maker and a deputy. Give them standing authority, out-of-hours contact routes and a written basis for the call. This is the single highest-value thing on this list.
• Connect it to work you have already done. If you completed operational resilience mapping for the March 2025 deadline, your important business services and impact tolerances are the natural foundation for incident thresholds. Do not build a parallel framework.
• Build or upgrade the incident log. You need to be able to see linked events, not just individual ones.
• Run one dry run. A ninety-minute tabletop exercise against a plausible scenario will tell you more about your readiness than any amount of policy drafting, and it gives the board something concrete to take assurance from.

Related articles