OPERATIONAL RESILIENCE

Incident reporting starts before the incident

The UK's new operational incident reporting rules give firms a year to prepare. The quality of the eventual report will depend on decisions made now about service ownership, escalation and access to reliable information.

OpinionOperational resilienceIssue date: 5 min read

THE EXECUTIVE VIEW

Three takeaways

  1. Confirm which reporting requirements apply to each legal entity and service.

  2. Test how the organisation makes decisions when information is incomplete.

  3. Use preparation to improve recovery and customer outcomes as well as regulatory reporting.

Use the implementation period to resolve ownership

The FCA published its final operational incident and third-party reporting rules on 18 March. The new regimes take effect on 18 March 2027 and introduce a standardised approach coordinated with the PRA and Bank of England. The populations covered by incident reporting and material third-party reporting differ, so firms need a specific assessment of scope. Existing notification obligations continue during the implementation period. FCA PS26/2 (opens in a new tab) and current reporting arrangements (opens in a new tab)

A year can look generous when the deliverable is described as a new reporting process. It becomes less generous when the information required sits across technology teams, operations, suppliers and several legal entities. An incident exposes those boundaries at the moment the organisation has least time to negotiate them.

Leadership should appoint an executive sponsor and establish who owns the overall response. The business service owner should be able to describe the customer impact. Technology should explain the technical position and recovery options. Compliance should coordinate the assessment of reporting obligations. Those responsibilities need to work together without leaving every material judgement to a committee that may be unavailable.

Start with an inventory of current reporting routes, including sector-specific obligations and relevant overseas entities. Record the triggers, responsible people, approval arrangements and submission channels. This gives the programme a concrete basis for identifying overlap and gaps.

Build a shared account of the incident

Imagine that a supplier reports intermittent processing failures. Some transactions complete, others are delayed and the supplier cannot yet confirm the cause. Customer-facing teams begin receiving enquiries before technology has established the full extent of the problem. This hypothetical scenario tests the organisation's ability to act under uncertainty.

The response team needs a common record of what is known, when it became known and what remains uncertain. It should distinguish confirmed facts from estimates and keep a history of significant changes. Someone must be responsible for updating the affected services and customer populations as the picture develops.

That record should support decisions about recovery, customer communication and regulatory notification. Separate workstreams may require different detail, but they should draw on a consistent account. Otherwise, executives can spend scarce time resolving contradictions between presentations while the underlying incident continues.

Define the minimum information needed for an initial decision. Waiting for a final root cause can delay necessary action. Equally, an early estimate should not become a permanent fact merely because it appeared in the first report. A disciplined process records uncertainty and revisits decisions when better information arrives.

Bring suppliers into the exercise

A supplier's contractual promise to notify the firm does not demonstrate that the operating arrangements will work during disruption. The organisation should know who receives an alert outside normal hours, who can question an incomplete update and how business impact will be assessed while the supplier investigates.

Select a supplier supporting an important service and walk through those hand-offs. Ask for a realistic account of the information it could provide in the first hour. Test the consequences of losing the normal communication channel. Establish how the firm would respond if the supplier's estimate of recovery time changed repeatedly.

The exercise should include the business decision to restrict, reroute or temporarily suspend a service. Each option may protect some customers while creating difficulties for others. The people authorised to make that choice need to understand its consequences before they face it under pressure.

Supplier participation also helps distinguish a dependency that can be managed through contingency arrangements from one that requires additional investment. If an alternative route exists only in a document, the executive committee should know what would be required to make it usable.

Measure readiness through decisions and recovery

Completing a reporting template is a useful milestone, but it provides limited evidence about the wider response. A practical readiness exercise should show how quickly the firm can identify the affected service, appoint a decision-maker and reach a justified view on notification. It should also test how an initial assessment is corrected when new facts emerge.

We would use a small number of realistic scenarios, including disruption involving more than one supplier or jurisdiction. Record the decisions that were delayed, the information that was unavailable and the authority that was unclear. Assign the resulting actions to owners who can fix the underlying process, with dates that leave time for another exercise.

Management information should distinguish actions completed from weaknesses resolved. Updating a contact list may close an administrative action; demonstrating that the right people can be reached and mobilised provides stronger evidence of readiness. The same principle applies to recovery plans, supplier arrangements and customer communications.

Preparation should also establish how the firm returns to normal operations. Backlogs may remain after systems recover, and customers may still need help. Closing the incident record too early can separate the technical recovery from the business outcome that matters.

Before approving the implementation plan, leadership should ask: can we explain our reporting perimeter; can the response team make decisions with incomplete information; and can we demonstrate that recovery restores the service customers rely on? Resolving those questions now will make the organisation more predictable when the next incident arrives.

March 2026 perspective. Sources reflect information available at the issue date.