Written by Technical Team | Last updated 23.07.2026 | 17 minute read
Operational incident reporting is often treated as a compliance process that begins after a serious outage, cyber attack or data failure has occurred. That view is increasingly difficult to sustain. The quality and speed of a regulatory report depend on decisions made months or years before an incident: how services are mapped, how telemetry is designed, how customer impact is measured, how third-party dependencies are recorded and whether technical evidence can be reconstructed under pressure.
In 2026, FCA operational incident reporting is at a significant transition point. The Financial Conduct Authority has finalised a new standardised reporting regime, although the rules do not come into force until 18 March 2027. Firms must therefore continue to meet their existing notification obligations during 2026 while also preparing their systems, processes and data for the new framework. For engineering teams, this preparation period should not be viewed as spare time. It is the window in which reporting requirements need to be converted into technical capabilities.
The central engineering challenge is not completing a regulatory form. It is creating a trustworthy incident data model that can answer, at short notice, what happened, when it happened, which services and users were affected, how serious the consequences might be, what the firm is doing about it and whether the incident has materially changed. A firm that cannot produce those answers from its operational systems will be forced to assemble them manually during a crisis, precisely when its technical staff are least able to tolerate distraction.
The new FCA framework introduces a clearer definition of an operational incident, three regulatory reporting thresholds and a standardised submission process through Connect. Most solo-regulated firms will use a shorter standard report. A more limited group, including banks, building societies, enhanced-scope SMCR firms, designated investment firms, Solvency II firms, CASS large firms, payment service providers and certain financial market entities, will be subject to enhanced reporting. Enhanced reporting follows the incident throughout its lifecycle, with initial, intermediate and final phases rather than a single static notification.
Although implementation is scheduled for March 2027, the practical engineering deadline is earlier. Firms need time to map the FCA’s reporting fields to internal data sources, resolve inconsistent definitions, connect incident tools to service and customer data, test reporting playbooks and establish ownership. Attempting this work in the final weeks before implementation is likely to produce a reporting process dependent on spreadsheets, manual calculations and the institutional knowledge of a few individuals. The stronger approach is to use 2026 to build reporting into the operating model: detection creates the incident record, service mapping enriches it, impact systems quantify it, decision logs explain it and the post-incident process completes it.
Under the new framework, an operational incident is broadly a single event or a series of linked events that disrupts a firm’s operations and either disrupts a service delivered to an end user outside the firm or affects the availability, authenticity, integrity or confidentiality of information relating to such an end user. This is wider than a conventional definition of an IT outage. A service may remain technically available while returning corrupted balances, exposing confidential information or processing transactions using inaccurate data. From an engineering perspective, availability monitoring alone is not enough.
The reference to a series of linked events is particularly important. A cloud platform failure, an unsuccessful failover, delayed transaction processing and a reconciliation backlog may be separate alerts in different systems, but together they may form one operational incident. Firms therefore need an incident correlation capability rather than a collection of disconnected tickets. Parent and child events, common causes, shared services and downstream consequences should be linked without double-counting affected customers or transactions. An incident record should be capable of evolving from “database latency” to “payments service disruption caused by a third-party infrastructure failure” as the organisation’s understanding improves.
An incident becomes reportable when the firm reasonably believes that it meets at least one of the FCA’s three thresholds. It may pose a risk of causing intolerable levels of harm to consumers from which they cannot easily recover; pose a risk to the safety and soundness of the firm or other market participants; or pose a risk to market stability, market integrity or confidence in the UK financial system. These thresholds are deliberately concerned with regulatory outcomes rather than purely technical severity. A total failure of an internal development tool may be operationally disruptive without meeting a threshold. A short-lived defect that sends incorrect payment instructions or exposes vulnerable customers to financial harm may be reportable even if infrastructure availability remains high.
Engineering severity and regulatory reportability should therefore be related but distinct classifications. A severity-one technical incident should trigger an immediate assessment, but it should not automatically be treated as reportable solely because of its internal label. Equally, a severity-three event should not escape regulatory review if the affected journey is unusually sensitive. The decision should incorporate the nature of the service, customer vulnerability, transaction values, data sensitivity, duration, geographic spread, legal obligations, market dependencies and the recoverability of any harm. Internal incident severity is evidence for the decision, not a substitute for it.
The FCA’s framework applies to incidents that have crystallised and meet a reporting threshold. It does not require firms to use the new operational incident reporting process for every near miss. A blocked cyber attack, a defect stopped before deployment or an attempted fraud that did not create a qualifying operational impact may fall outside this specific process. That does not make near misses irrelevant, and other notification obligations may still apply. Engineering teams should retain them for risk analysis, vulnerability management and lessons learned, while ensuring that the regulatory workflow distinguishes an actual qualifying incident from a hypothetical threat.
Planned maintenance is similarly not an operational incident simply because a service is intentionally unavailable. The position changes if the controlled interruption does not proceed as designed, service cannot be restored as expected and the resulting impact meets a reporting threshold. Change-management systems should consequently preserve planned start and end times, approved customer impact, rollback criteria, actual restoration time and any deviation from the plan. When an upgrade overruns, the reporting assessment should not begin with a search through deployment chat messages; the evidence should already be attached to the change and incident records.
A defensible FCA report requires more than a narrative written by an incident manager. It requires a structured record with stable identifiers, defined timestamps, traceable calculations and version history. The record should separate confirmed facts, working estimates and hypotheses. During the first hour of an incident, the suspected cause may change several times. Updating a field without retaining its earlier value destroys the audit trail and can make an entirely reasonable evolution in understanding look like inconsistent reporting. Every material field should therefore carry an “as at” time, source, owner, confidence level and change history.
Time data deserves special attention. Engineering teams should capture the time of occurrence, where it can be established; the time of first detection; the time the incident was declared; the time a regulatory threshold assessment began; the time the firm determined that a threshold had been met; the time each report was submitted; the time customer impact was brought under control; the time affected services were restored to acceptable levels; and the time the incident was formally closed. These timestamps describe different events and should not be collapsed into one field called “resolved at”. All systems contributing evidence should be synchronised to a reliable time source, with timestamps normalised to a common time zone while preserving the original source time.
The distinction between resolution and closure is also technically meaningful. An incident may be resolved when its immediate impact has been controlled and service has returned to an acceptable level, even though the root cause has not been fully proven and permanent remediation remains outstanding. Closure should follow the post-incident review, identification of lessons and appropriate treatment of remaining vulnerabilities. Incident-management tools that offer only “open” and “closed” statuses encourage premature closure and make it difficult to demonstrate the lifecycle expected by the FCA. At minimum, the data model should support open, resolved and closed states, with explicit transition criteria.
Service information needs to come from an authoritative catalogue rather than free-text descriptions. The record should identify the affected business service, its owner, the customer or market outcome it supports, its technical components, whether it is classified as an important business service, the impact tolerance that applies and the third parties required to deliver it. Service names used in incident reports should match those used in operational resilience mapping and board reporting. If engineering calls a platform “Payments Core”, operations calls it “Money Movement” and compliance calls it “Domestic Transfers”, the firm will lose time reconciling terminology during the incident.
Impact measurement is likely to be the most difficult part of the reporting capability. Most monitoring platforms are designed to measure infrastructure behaviour, not consumer harm. CPU utilisation, error rates and request latency may indicate that something is wrong, but they do not reveal how many customers were unable to access funds, how many transactions failed, which users were vulnerable or whether incorrect data influenced a financial decision. Firms need instrumentation at the business-journey level, linked to customers, transactions, products and channels while respecting data-protection and access-control requirements.
The minimum engineering dataset should be capable of producing, or supporting the production of, the following information:
Percentages require controlled denominators. “Ten per cent of users were affected” is not reproducible unless the firm records whether the denominator means registered users, active users, users of the affected service, users who attempted the journey during the disruption or an average for a comparable time period. Transaction impact has similar complications. Retried requests can inflate counts, queued payments may be delayed rather than failed, and later reversals may alter the net financial value. The calculation logic should be documented and repeatable, with the result tied to a specific query or dataset snapshot.
Impact-tolerance consumption creates another data-design challenge. An impact tolerance may use elapsed time, transaction failures, complaint volumes, financial loss or a combination of measures. The incident system should not assume that every tolerance is expressed as hours. It should retrieve the applicable metric, threshold and unit from the operational resilience repository, calculate consumption against the latest approved tolerance and preserve the value used at each reporting stage. If the tolerance changes after the incident, the historical report must remain linked to the version that was valid at the time.
Third-party attribution should be supported by the firm’s dependency model. Recording only the name of the contracted supplier is insufficient where a service depends on subcontractors, cloud regions, network providers, identity platforms or shared group services. The immediate origin may be a third party even when the technical fault occurs deeper in the supply chain. Engineering and procurement records should connect providers to services, contracts, data locations, technical components, continuity arrangements and escalation contacts. The incident record can then identify exposure quickly while the detailed causal chain is still being investigated.
For most firms, the initial reporting expectation will be as soon as practicable after determining that a qualifying threshold has been met, with the FCA expecting submission within 24 hours of that determination. Firms should not interpret this as permission to wait until the twenty-fourth hour. Payment service providers face a more demanding position, with the initial phase expected within four hours of first detecting a major incident. Engineering systems should therefore record both detection and threshold-determination times. Without both, the organisation cannot show which reporting clock applied or whether the submission was timely.
The initial report is intentionally based on information available during an active response. It does not require the firm to have completed root-cause analysis or calculated every impact figure. However, “information not yet known” must not become an excuse for information that the firm could have generated through appropriate instrumentation. A strong initial report should be assembled from a pre-defined minimum dataset: affected service, incident type, detection time, current severity, regulatory trigger, known impact, actions taken, actions planned and a credible statement of uncertainty. The incident commander should not have to ask five teams to interpret raw logs before basic service impact can be described.
Enhanced-reporting firms must then update the report when a significant change occurs. This is not the same as sending the regulator every technical update. The reporting workflow should detect changes that alter the regulatory understanding of the event, such as identification of a third-party origin, a substantial increase in affected customers, activation of disaster recovery, discovery of a data-integrity problem, expansion into another jurisdiction, satisfaction of an additional regulatory threshold or resolution of the incident. Each intermediate report should state what changed since the previous version rather than replacing the earlier narrative with a rewritten history.
The final phase is where engineering evidence is tested most severely. It must reconcile early estimates with verified impact, distinguish the initiating event from contributing control failures and explain why the incident produced the observed outcome. “Human error” and “software defect” are rarely adequate root causes. A high-quality causal account may identify an unsafe configuration change as the initiating event, inadequate automated validation as a contributing control weakness, shared infrastructure as the mechanism of spread and an untested recovery dependency as the reason the disruption exceeded expectations. The account should connect those findings to concrete remediation with owners, priorities and verification criteria.
An effective evidence pipeline will normally connect several operational systems:
Connect will be the regulatory submission channel, but it should not become the firm’s primary incident repository. The organisation needs its own authoritative record from which the Connect submission is produced. That record should be append-only for material changes, access controlled, backed up and capable of generating a snapshot matching each regulatory submission. Where information is copied manually into Connect, the submitted values should be captured internally so that later updates can be compared with exactly what the FCA previously received.
The reporting workflow must also control sensitive information. Raw security logs, personal data, authentication secrets, unnecessary customer identifiers and legally privileged analysis should not be indiscriminately attached to the incident record or regulatory form. The objective is to preserve sufficient evidence without broadening access to sensitive material. Role-based permissions, redaction procedures, secure evidence stores and clear attachment approval should be designed in advance. A crisis is a poor time to decide who is allowed to see a forensic image or whether a customer dataset can be shared.
The first readiness task is a field-level gap assessment. Firms should compare the standard or enhanced reporting template with the data their systems can currently produce. For each field, they should identify the authoritative source, accountable owner, calculation method, expected availability during an incident and any manual dependency. A field marked “available” should mean that the information can be produced accurately under incident conditions, not that somebody believes it exists somewhere in a data warehouse. Gaps should be prioritised according to reporting phase: initial-report data needs the highest availability and shortest production time.
The second task is to establish a regulatory decision workflow. Engineering can supply evidence, but determining whether a qualitative FCA threshold has been met will usually require input from operational resilience, compliance, risk, customer operations and senior incident leadership. The workflow should specify who initiates the assessment, who can decide, how uncertainty is recorded, how disagreements are escalated and who submits the report. The decision itself should be time-stamped and supported by the facts available at that moment. Automated rules can flag likely reportability, but they should not reduce nuanced regulatory thresholds to a simplistic numerical score.
The third task is repeated scenario testing. Tabletop exercises should require participants to produce the regulatory report, not merely discuss how they would respond technically. One exercise might involve a third-party cloud failure affecting several services; another could involve silent data corruption while the customer interface remains online; another could combine a cyber incident with unavailable staff and incomplete supplier information. The clock should run during the exercise. Teams should discover whether they can identify affected services, calculate customer impact, find the correct contacts, distinguish resolution from closure and generate an approved report while engineers are still restoring service.
Third-party readiness must form part of these tests. Supplier contracts and operating procedures should require prompt incident notification, meaningful status updates, impact data, root-cause information and post-incident cooperation. The firm should know how it will proceed when a provider cannot supply a confirmed cause within the final-report timetable. It should also test whether supplier information can be received outside normal communication channels. An outage that disables corporate identity, email or collaboration tools may also remove access to the contacts and documents needed to manage the provider.
Engineering leaders should set internal objectives that are stricter than the regulatory maximum. For example, the organisation might aim to assemble its minimum reporting dataset within the first hour, complete an initial threshold assessment shortly afterwards and maintain regulator-ready updates throughout the incident. These are not alternative regulatory deadlines; they are operational targets designed to create sufficient time for challenge, approval and submission. The objective is to make reporting a controlled by-product of incident response rather than a competing emergency.
The most important measure of readiness is whether the firm can explain an incident from customer outcome back to technical cause. It should be possible to move from affected customer journeys to business services, from services to applications and infrastructure, from infrastructure to changes and third parties, and from technical failures to the actions taken to contain harm. That traceability is valuable far beyond regulatory reporting. It improves prioritisation, recovery, customer communication, root-cause analysis and investment decisions.
FCA operational incident reporting in 2026 is therefore an engineering data problem as much as a regulatory one. The firms best prepared for the new regime will not be those with the most elaborate reporting documents. They will be those whose architecture, telemetry and operating model make the relevant facts available quickly and reliably. When a serious disruption occurs, they will know which services matter, which users have been affected, how close they are to intolerable harm, what changed and whether recovery is working.
By the time the new rules take effect in March 2027, regulatory reporting should be embedded in the incident lifecycle. Detection should start the evidence trail. Service mapping should provide context. Business telemetry should quantify impact. Decision records should demonstrate judgement. Recovery data should establish resolution, and the post-incident review should complete the causal account. Building that capability during 2026 will not simply make FCA submissions easier. It will give engineering and operational teams a clearer, faster and more disciplined way to manage the incidents themselves.
Is your team looking for help with FCA operational incident reporting development? Click the button below.
Get in touch