Beyond Compliance: Strategic Approaches to Operational Incident and Third-Party Reporting by March 2027

In 2024, the UK regulators (FCA, PRA and Bank of England) consulted on enhanced reporting requirements for operational incident and material third party reporting through CP17/24 reflecting growing reliance by Financial Services Institutions (FSIs) on third party technology providers, an increasing prominence of cyber threats and increased sector interconnectivity.

In March 2026, UK regulators introduced a new operational incident reporting framework through Policy Statements. Designed to give supervisors a consistent, timely view of disruption, it enhances regulatory visibility, increases transparency of Third Party dependencies, focuses on cross-firm impact and systemic risks from critical service providers, and aligns with international regimes like EU DORA.

For many firms, this is more than a reporting change, necessitating:

• Clearer escalation processes;
• Stronger internal coordination; and
• A more disciplined approach to incident assessment and response.

In this first blog, we focus on the impact of the new UK requirements on operational incident reporting. In a second blog, we will look separately at the new requirements for material third-party reporting.

What has changed?

At a high level, the new UK regime introduces a common definition of an operational incident, a more consistent reporting process, and greater alignment across domestic regulators on how incidents should be notified and assessed.

• A common definition: the regulators have defined an “operational incident" as a “single event or a series of linked events that disrupt a firm's operations”. This includes any disruption to the delivery of a service to an external end user (e.g., customers, market participants, other group members). It also covers impacts on the availability, authenticity, integrity, or confidentiality of data belonging to that end user.
• Greater alignment across regulators: the PRA and FCA have aligned their incident notification processes for dual-regulated firms. This means firms are now expected to use a single reporting form, removing the need for separate submissions, although their respective reporting thresholds continue to reflect distinct statutory objectives.
• Enhanced regulatory insight: The framework introduces three stages of incident reporting (initial, intermediate and final), designed to provide regulators with consistent information during operational disruption. This enables them to identify emerging disruption and better understand the scale, impact, and systemic implications of incidents.

Why are regulators focusing on this now?

Regulators are intensifying their focus on operational resilience due to the escalating threat of systemic disruption within Financial Services Institutions. Recent high-profile third-party incidents have highlighted how a single event, particularly those involving shared infrastructure or critical third parties, can rapidly affect multiple firms across the sector. This systemic risk is clearly evidenced by the HMT’s designation, on 10 July 2026, of four global cloud service and technology providers as critical under the UK’s regulatory regime¹ for joint oversight, underscoring their pivotal role in the UK financial services system.

Further reinforcing this urgency, recent DORA incident data and the ESA’s 2025 Report² on Major ICT-related incidents reveal that major ICT disruptions are rarely isolated. Approximately one-third of these incidents have cross-border effects³, often driven by system failures, external events, and, significantly, third-party disruptions. While root cause analysis is complex, nearly one-third of reported incidents⁴ were attributable to third parties, including ICT providers, other financial entities, and infrastructure providers.

Given the interconnected nature of the financial services ecosystem, operational disruption is increasingly shared and not confined to single jurisdictions. This necessitates faster, more comprehensive data for regulators to assess sector-wide impacts and shape policy, alongside stronger reporting and sharper third-party oversight. Ultimately, this reinforces the critical importance of robust third-party risk management, oversight, and coordination across the financial system.

What counts as an operational incident?

A significant change in the new framework is the introduction of a common definition of an operational incident across the UK regulators. An operational incident is defined as:

"either a single event or a series of linked events which disrupts the firm’s operations such that it:

1. disrupts the delivery of a service to an end user external to the firm; or
2. impacts the availability, authenticity, integrity or confidentiality of information or data relating or belonging to such end user."

Whilst a near miss that does not result in actual disruption or data loss to an external end user is outside the formal reporting scope, we believe that it is prudent for firms to continue to collect and evaluate this data as it is important to recognise why operational disruption was avoided as well as reporting where it wasn’t.

When does an incident become reportable?

Although the regulators now use a common definition of an operational incident, the thresholds for reporting to the PRA and FCA are not identical, which reflects their different statutory objectives.

In practice, some incidents may be reportable to one regulator but not the other, and firms will need to assess both carefully. It is important to note that the regime is not limited to incidents affecting Important Business Services. The definition of end users is deliberately broad, and the thresholds are designed to capture incidents broader than those services just unpinning IBS’ but also those that underpin the broader definition of materiality i.e. internal facing services. Firms must submit an operational incident report to the PRA or FCA in line with the Incident Thresholds in the Figure 1 below.

Figure 1: PRA & FCA Incident Thresholds

When assessing whether those thresholds are met, the PRA and FCA point firms towards a similar set of impacts, even if the emphasis is not identical. In broad terms, firms should consider:

• the potential for operational or financial contagion;
• the effect on the firm’s ability to meet legal and regulatory obligations or continue providing services;
• the impact on data availability, integrity, authenticity or confidentiality;
• the reputational effect on the firm or wider market; and
• how the incident is being assessed and escalated internally.

For the PRA in particular, operational and financial contagion remain important indicators of financial stability risk. That is especially relevant for firms whose disruption could create knock-on effects for counterparties, policyholders or the wider system. To mitigate the risk of non-compliance stemming from ambiguous or uncertain reporting thresholds, a cautious stance favouring reporting is generally advisable. However, this should be balanced with an effort to ensure submissions remain relevant and proportionate, avoiding unnecessary burden while maintaining compliance.

For firms, the practical challenge will be to identify quickly when an incident may meet an FCA and/or PRA impact threshold, apply those thresholds consistently, and ensure that escalation processes can support timely notification. Whilst the regulators do not require firms to align internal incident severity levels with reporting thresholds, firms should consider updating their Risk Impact Criticality Matrix to reflect the regulatory impact thresholds . This updated matrix can then be integrated into an automated workflow to consistently and rapidly determine when thresholds may be or have been reached.

Building on this, firms must understand that an incident should therefore not be dismissed from regulatory reporting simply because it falls below an internal severity label. Crucially, a significant escalation in a firm's internal response to an incident should itself serve as a strong indicator that a regulatory reporting threshold has likely been met.

The decision to report must be underpinned by a comprehensive assessment that extends beyond internal classifications, considering the incident's broader governance implications, potential risks (e.g., financial, reputational, operational, legal), and overall impact on customers, market integrity, and business continuity. To ensure timely and accurate reporting, firms must establish clear roles and responsibilities for incident assessment and regulatory notification (aligning with the timely material third party notification requirements in our following blog). This will require close coordination across Compliance, TPRM, Legal, Cyber, Operational Resilience, Procurement and other relevant teams, typically involving dedicated incident management teams, compliance functions, and senior leadership oversight, ensuring that accountability for reporting is well-defined and understood across the organisation.

The reporting lifecycle: early, ongoing and final reporting

While the UK's operational incident reporting requirements largely align with the EU's DORA (see Figure 2 below) and FSB FIRE supporting global compliance, there are subtle nuances which firms should note:

• DORA mandates a tighter initial report within 4 hours of classification, compared to the UK's 'as soon as possible, within 24 hours of detection⁵'.
• DORA also requires a structured intermediate update within 72 hours, whereas UK updates are event-driven ('after any significant change').
• The UK framework offers a clearer maximum timeframe for final reports (which includes Post-Incident Review details with the origin of the incident and remediation planning) 60 days from incident, while DORA's final report timing is contingent on the last intermediate update, potentially extending the overall reporting timelines.

For firms operating across both jurisdictions, this means internal processes must be robust enough to meet DORA's more stringent initial and intermediate deadlines. Adhering to DORA's stricter cadence will likely ensure compliance with the UK's requirements, streamlining incident management and regulatory engagement, while still needing to track the UK's fixed final reporting window.

Figure 2: UK Operational Incident Regime vs DORA Notification requirements

It is also worth noting that payment service providers remain subject to a shorter reporting window under the UK requirements and must notify relevant incidents within four hours of detection, rather than the general 24-hour timeframe, reflecting their systemic importance.

Governance and accountability

The PRA expects the SMF24, or equivalent role, to have overall responsibility for implementing the incident reporting requirements and ensuring that the firm’s internal processes support accurate and timely notification. Formal sign-off of each report is not required, but firms should make sure their governance structure supports effective oversight and quick decision-making.

What should firms do now?

While the new regime takes effect on 18 March 2027, firms should not view this as a distant compliance deadline. For those already navigating the Digital Operational Resilience Act (DORA), you have a significant head start. However, the real challenge for all firms lies in ensuring that governance, incident management, data capture, and cross-functional escalation processes are not just ready, but highly efficient and largely automated, well before the deadline. The rapid reporting timelines and the complexity of linking incidents and determining threshold criteria demand a shift from manual data querying to near real-time detection and notification. This also presents a compelling case for leveraging AI, particularly causal AI, to identify missed patterns, determine root causes, and enhance the accuracy of incident classification, with human oversight.

Given there is not a significant uplift from the DORA requirements, firms should consider the following to accelerate existing operational resilience processes:

1. Develop an Integrated Operational Resilience data model: Implement a comprehensive Operational Resilience data model to enable the rapid synthesis of information across financial and operational data sets to determine where thresholds may be, or have been, breached.
2. Automate End-to-End Incident Workflows: Assess and automate workflows for observability, monitoring and incident detection, classification, notification, and reporting. This includes designing processes that account for cross-border events and varying time zones, clearly defining user roles and responsibilities to ensure swift escalation and resolution.
3. Integrate AI for Enhanced Incident Intelligence: Explore and integrate AI, particularly causal AI, to augment human capabilities in identifying subtle patterns in incident types, frequency and severity, determining underlying root causes, and improving the accuracy and speed of incident classification.
4. Strengthen Sector-Wide Information Sharing: Actively participate in and contribute to formal and informal sector-wide information sharing initiatives (e.g., FSCCC, FS-ISAC, CMORG) to support collective resilience and enable firms to learn from broader industry experiences.

Stay tuned! In our next article, we will explore the key changes and practical implications for applying the Material Third Party Reporting requirements.

References:

1. UK financial regulators to begin overseeing Critical Third Parties announced by HM Treasury | Bank of England
2. Memorandum of Understanding to strengthen oversight of critical third parties | Bank of England
3. ESAs 2025 Report on major ICT-related incidents.pdf
4. The ESA 2025 Report reinforces the systemic and interconnected nature of ICT incidents revealing that, out of 3,383 major incidents in 2025, approximately one-third had a cross-border impact.
5. Detection is usually at the point of service degradation or impact: an operational incident meets one or more of the following thresholds: operational and financial contagion (O-SIIs/relevant Solvency II firms only); other firm’s or, if an O-SII/relevant Solvency II firm, the sector’s reputation; other firm’s ability to meet its legal and regulatory obligations; other firm’s ability to provide adequate services; other firm’s ability to safeguard the availability, authenticity, integrity or confidentiality of data or information relating or belonging to an end user external to the firm; and other firm’s internal assessment and classification of the incident.