UK Regime and Incident Reporting

Incident reporting, in the context of the UK operational resilience regime, means the arrangements by which a firm detects disruption to an important business service, escalates it to decision makers, communicates with users and, where applicable rules require it, notifies regulators, and then learns from the incident by updating maps, tolerances, procedures and test scenarios. The UK regime itself is organised around services, tolerances, mapping, testing and self-assessment, and incident reporting supports that regime by providing real evidence about how services actually fail and recover. An incident that is handled well operationally, but whose lessons are never recorded against the affected service, has not fully served the regime, because the next self-assessment will describe the service as if the incident had not happened.

Reporting arrangements therefore need to be understood in two directions: outward, to users and regulators, and inward, to the service record. Outward reporting manages harm and meets applicable notification expectations, which may sit in rules beyond the operational resilience policy statements themselves. Inward reporting ensures that the incident changes the firm's understanding of the service. Both directions matter, and a firm that focuses only on outward notification, without inward learning, will repeat the same failure in a later incident.

Detection should be tied to services, so that an alert about a system or supplier is quickly translated into a service question: which important business services are affected, how badly, and whether any service is approaching or beyond its tolerance? A monitoring arrangement that reports system status without service impact leaves decision makers to infer harm under pressure, which wastes time during disruption. Service based detection, by contrast, gives decision makers the information the regime cares about: the service, its users, its tolerance position, and the recovery route.

Users should be told, in plain language, which service is affected, what they can and cannot do, what the firm is doing to restore the service, and what they should do in the meantime, where a practical alternative exists. Communication should be possible even when the affected service channel itself is down, which means the firm needs an alternative channel that does not depend on the failed service. A communication plan that relies on the disrupted channel to tell users about the disruption will fail at the moment it is needed most, and scenario testing should examine that failure mode explicitly.

Regulator notification fits alongside the UK regime, under applicable notification rules that may apply to a firm depending on its permissions and the nature of the incident. This guide does not state a single notification timetable, because notification expectations can arise from different rules and can depend on the incident type, the firm and the regulator. What matters for the UK regime is that notification, where required, is made through the correct route, with accurate service information, and that the notification record is consistent with the firm's internal service record and its later self-assessment. Inconsistency between a regulator notification and a self-assessment account of the same incident undermines credibility in both documents.

After an incident, the firm should ask what the incident revealed about the service map, the tolerance, the scenario programme and the recovery procedures. Did the incident follow a route the map showed, or did it reveal a dependency the map had missed? Did the service remain within tolerance, approach tolerance, or breach tolerance, and was the tolerance itself still a fair statement of intolerable harm? Did existing scenarios cover this failure mode, or does a new scenario need to be designed? Did workarounds function at realistic volumes, and did communications reach users through an available channel? Each question, answered honestly, produces an update to the service record.

A recurring mistake is to treat incident reporting as notification alone, without service learning. Another mistake is to record incidents in a general log, detached from services, so that no service owner can say what incidents affected their service or what changed as a result. A further mistake is to communicate with users through the disrupted channel only, or to delay communication until full recovery, leaving users without guidance during the period when guidance matters most. Each mistake reflects the same underlying error: incident handling organised around systems or notifications, rather than around services and users.

A related mistake is to present an incident in different terms to different audiences, so that the regulator account, the user account and the self-assessment account of the same incident cannot be reconciled. Consistency does not require identical wording for every audience, since users and regulators need different levels of detail, but the core service facts, tolerance position and lessons should align. Where accounts diverge, a reader is entitled to ask which account reflects the service record, and why the others differ.