Skip to main content
Bureau of AI
Category: Incident & Remediation

Serious Incident Reporting

Also known as: SIR, Serious Incident Report, Critical Incident Reporting
Simply put

Serious incident reporting is the practice of notifying a relevant authority or oversight body when a harmful or potentially harmful event occurs, so that the event can be reviewed and addressed. The exact meaning of a 'serious incident' and who must report it depend heavily on the sector and jurisdiction, since the evidence here covers areas such as charities, human-services programs, research oversight, and emergency shelters rather than a single unified definition.

Formal definition

Serious incident reporting refers to formal processes requiring designated parties to report adverse events, whether actual or alleged, that result in or risk significant harm to people, an organization, or those it serves. Definitions and thresholds are context-specific: in the UK charity context it is described as an adverse event risking significant harm to a charity's beneficiaries, staff, or others (SOURCE 2), while other frameworks scope it to participant health and safety (SOURCE 3) or to the safety and well-being of emergency shelter residents (SOURCE 5). Reporting timelines are also framework-dependent, with more serious incidents typically requiring faster notification than less serious ones (SOURCE 4). Note that the evidence provided addresses charity, human-services, research-oversight, and shelter contexts, not AI-specific serious incident reporting regimes; readers should not assume these definitions transfer to AI governance frameworks without separate authority.

Why it matters

Serious incident reporting is a foundational accountability mechanism: it ensures that harmful or potentially harmful events are surfaced to a relevant authority or oversight body rather than being contained or overlooked within the organization where they occurred. The evidence available here spans distinct sectors—UK charities, human-services programs, research oversight, and emergency shelters—and in each the reporting obligation exists to protect the people an organization serves and to enable external review of adverse events. Because thresholds and definitions are set by the applicable framework rather than by a single universal standard, the practical value of a report depends on correctly identifying what counts as 'serious' in a given context.

The design of these regimes reflects a recurring principle: not all incidents warrant the same urgency. In the research-oversight context, for example, the guidance indicates that more serious incidents may require notification within days while less serious ones may allow a few weeks (SOURCE 4). This tiering matters because it allocates oversight attention to the events that pose the greatest risk of harm, while avoiding a flood of low-consequence reports that could dilute focus. Reporting also captures alleged as well as actual events (SOURCE 2), meaning the trigger is often the risk or allegation of significant harm rather than confirmed injury alone.

For readers working in AI governance and model risk management, an important caveat applies: the frameworks cited here are charity, human-services, research, and shelter regimes, and they do not describe AI-specific serious incident reporting obligations. Concepts such as reporting thresholds and escalation timelines may be conceptually analogous to emerging AI incident-reporting expectations, but the definitions and legal obligations documented in this evidence should not be assumed to transfer to AI systems without separate authority governing that domain.

Who it's relevant to

Charity trustees and foundation staff
In the UK context, guidance is directed at charity trustees to help them identify serious incidents and understand how and what to report (SOURCE 1). Foundations and their staff are also addressed, where a serious incident is framed as an adverse event, actual or alleged, that results in or risks significant harm to a charity's beneficiaries, staff, or others (SOURCE 2).
Human-services program contractors
Parties delivering human-services programs—such as IRIS contractors in the Wisconsin context—use incident reporting to monitor and resolve concerns related to participant health and safety (SOURCE 3). For these actors, the reporting scope is tied specifically to the well-being of program participants.
Research oversight and compliance staff
Those responsible for research compliance operate under frameworks where reporting timelines are graduated by severity, with more serious incidents potentially requiring notification within days and less serious ones allowing more time (SOURCE 4). Correctly classifying an incident's severity is central to meeting the applicable deadline.
Emergency shelter operators
Operators and staff of emergency shelters fall within a framework where a serious incident is defined as one that impacts the safety and well-being of any shelter resident or member of the emergency shelter population (SOURCE 5), making resident protection the reporting trigger.
AI governance and model risk professionals (with caution)
Compliance, model risk, and governance professionals may find the structural concepts here—graduated timelines, defined thresholds, and designated reporting parties—conceptually useful. However, the evidence covers charity, human-services, research, and shelter regimes and does not describe AI-specific serious incident reporting obligations. These definitions should not be assumed to apply to AI systems without separate governing authority.

Inside SIR

Triggering Event Definition
The set of circumstances that constitute a reportable incident, which in some frameworks includes events such as harm to health or safety, disruption of critical infrastructure, or infringement of fundamental rights. The precise definition and thresholds vary by framework and jurisdiction, so the scope of what counts as 'serious' is not uniform across regimes.
Reporting Obligation and Responsible Party
Identification of which actor (for example, a provider or deployer, depending on the framework) bears the duty to report, and to whom. In the AI governance context this maps to organizational accountability structures, while the underlying detection of the incident may draw on model risk monitoring activities.
Reporting Timeline
The window within which an incident must be notified after it becomes known or is established. Specific deadlines differ by instrument and are sometimes tiered by severity; where the exact number of days is not certain, treat timelines as framework-dependent rather than fixed.
Recipient Authority
The competent authority, regulator, or oversight body designated to receive reports. The relevant recipient depends on jurisdiction and sector, and a single organization may face multiple overlapping reporting channels.
Incident Information and Root-Cause Content
The substantive detail expected in a report, which typically covers the nature of the incident, affected systems or persons, and, where available, analysis of contributing causes and corrective measures. Root-cause analysis often relies on model risk management processes such as monitoring, performance review, and validation records.
Follow-up and Remediation Reporting
Ongoing obligations that may extend beyond the initial notification, including updates as investigation progresses and description of measures taken to reduce recurrence. This connects incident reporting to broader governance oversight and control activities.

Common questions

Answers to the questions practitioners most commonly ask about SIR.

Does serious incident reporting apply to every AI system an organization operates?
No. Serious incident reporting obligations are typically scoped to particular categories of systems and particular triggering events rather than to all AI use. Where such obligations arise from a specific regulatory instrument, they generally apply only to the classes of systems and the kinds of harm that instrument defines. Professionals err when they assume a blanket duty across an entire AI portfolio; the correct starting point is to confirm which systems fall within the applicable framework's scope and what that framework counts as a reportable incident. Absent an applicable legal obligation, incident logging may still be a sound governance practice, but that is distinct from a mandatory reporting duty.
Is a serious incident the same thing as a model failing to perform well or degrading over time?
Not necessarily. Performance degradation is a model risk and performance concern, whereas a serious incident is generally an event meeting a defined threshold of actual or potential harm as set out in the applicable framework. Degradation can be a contributing cause of an incident, but the two are conceptually distinct: monitoring for degradation is an ongoing measurement activity, while incident reporting is triggered by qualifying events. Treating routine performance drift as automatically reportable, or conversely assuming that stable performance metrics mean no incident could occur, both misread the relationship. The determining question is whether a given event meets the reporting criteria in scope, not solely whether a performance metric moved.
How should an organization determine whether a given event crosses the threshold for reporting?
In many frameworks the threshold is defined by reference to the severity, type, or reversibility of harm and sometimes to the category of system involved. A practical approach is to establish a documented triage process that maps observed events against the specific criteria in the applicable framework, records the assessment and its rationale, and escalates ambiguous cases for review. Because thresholds and definitions vary by instrument and can evolve, organizations typically avoid relying on a single internal definition and instead trace their criteria back to the framework that governs the system in question. This is a control that supports consistent decisions; it does not by itself guarantee correct classification of every event.
Which lines of defense are usually involved in the incident reporting process?
Responsibilities are commonly distributed across the lines of defense rather than concentrated in one function. The first line, typically the business or operational owners of the system, is usually positioned to detect and initially report events. The second line, often risk, compliance, or governance functions, commonly reviews classification, ensures consistency with applicable obligations, and oversees escalation. Independent assurance, often associated with the third line such as internal audit, may periodically test whether the reporting process operates as designed. This division supports accountability but does not eliminate the possibility of missed or misclassified incidents; it is a structure for managing that risk.
What should be documented and retained about a reported incident?
As a general governance practice, organizations typically maintain a record of the event, the date and manner of detection, the assessment against reporting criteria, the classification decision and its rationale, actions taken to contain or remediate, and any communications made to external parties. Retaining this documentation supports later review, assurance, and any regulatory inquiry. The specific fields, formats, and retention periods that are mandatory depend on the applicable framework and jurisdiction, so organizations generally confirm those requirements rather than assume a universal template. Where no specific requirement applies, documentation choices are a matter of internal governance policy.
How does incident reporting connect to broader corrective action and monitoring?
Reporting is generally one component of a wider loop that includes containment, root-cause analysis, remediation, and updates to ongoing monitoring so that similar events are detected earlier. In practice, findings from an incident often feed back into validation activities, control design, and monitoring thresholds. Treating the report as the endpoint is a common pitfall; the report typically initiates rather than concludes the response. It is also worth noting that corrective action reduces or manages the likelihood and impact of recurrence but does not eliminate the underlying risk, so continued monitoring remains relevant after an incident is closed.

Common misconceptions

Serious incident reporting requirements are uniform across regulatory frameworks and jurisdictions.
Definitions of a 'serious incident,' reporting timelines, the responsible party, and the recipient authority vary by framework and jurisdiction. Requirements issued by different bodies are not interchangeable, and some regimes are binding law while others are guidance or voluntary standards; practitioners should confirm which regime applies to their situation.
Reporting an incident and completing incident reporting obligations means the underlying model risk has been eliminated.
Reporting is a governance and transparency measure that supports oversight; it does not by itself remove or eliminate the risk. Residual risk typically remains and must continue to be managed through monitoring, remediation, and control activities. Reporting documents and communicates an event rather than resolving the underlying exposure.
Serious incident reporting is purely an AI governance activity, separate from model risk management.
The two overlap without being identical. Detecting and analyzing an incident often depends on model risk management activities such as monitoring and validation, while the obligation to report, escalate, and be accountable sits within AI governance structures. Collapsing the two obscures where detection ends and organizational accountability begins.

Best practices

Determine which specific framework(s) and jurisdiction(s) apply to your systems, and map the exact triggering-event definitions, timelines, responsible parties, and recipient authorities for each, rather than assuming a single uniform standard.
Establish clear internal escalation paths that connect model risk monitoring signals to governance decision-makers, so that potential reportable events are identified and assessed promptly.
Maintain documentation and monitoring records that support timely root-cause analysis, drawing on validation and performance-review evidence where available.
Define roles and accountability in advance across the lines of defense, so it is clear who detects, who assesses, and who submits reports to the competent authority.
Track follow-up and remediation obligations as an ongoing workflow, updating authorities as investigation progresses and documenting measures taken to reduce recurrence.
Treat reporting as one control within a broader risk-management program, and continue managing residual risk after a report is filed rather than treating the obligation as closed.