AI incident and serious incident reporting record (register plus report drafts)

Structure (8 sections)

1. 1. 1. Incident taxonomy, severity tiers and the reporting-duty matrix

   Start with a table of what counts as an incident, what counts as a serious incident, and which reporting duty each triggers — it is the foundation of the document. Art. 3(49) of the EU AI Act defines "serious incident" and Art. 73 sets tiered deadlines on that basis; write each tier with its trigger and clock: in general, report immediately after the provider (or deployer) has established a causal link between the AI system and the serious incident or the reasonable likelihood of such a link, and in any event not later than 15 days after becoming aware of it, with the period taking account of severity; in the event of a widespread infringement or a serious incident as defined in Art. 3(49)(b), report immediately and not later than 2 days; and in the event of a person’s death, report immediately after the causal relationship is established or as soon as it is suspected, but not later than 10 days after becoming aware. The text also permits an initial, incomplete report where necessary to ensure timely reporting, followed by a complete one — put that in the process so the team does not miss a deadline waiting for full information. One event usually triggers several duties at once: a personal data breach goes to the supervisory authority under GDPR Art. 33 within 72 hours of becoming aware where feasible, with Art. 34 notification to data subjects where the risk is high; in China, a security defect or vulnerability in a network product or service that endangers national security or the public interest is reported to the competent authority within 24 hours under Art. 10 of the Network Data Security Management Regulations; and a generative service that finds unlawful content handles and reports it under Art. 14 of the Interim Measures. Check one thing separately in the recipient column: the default recipient under Art. 73(1) is the market surveillance authority of the Member State where the incident occurred, but Art. 1(31) of Regulation (EU) 2026/1744 (the AI Omnibus) inserted Art. 75(1a) — by way of derogation from Art. 73, providers of high-risk AI systems falling under the AI Office’s exclusive competence in Art. 75(1) report serious incidents to the **AI Office**, with Art. 73(2) to (9) applying mutatis mutandis and the AI Office promptly passing the information to the relevant Member State market surveillance authority. Art. 75(1)(a) covers precisely those AI systems built on a general-purpose AI model where the model and the system come from the same provider or the same undertaking (excluding Annex I product-related systems, Annex III point 2 systems, law enforcement, border management and financial institutions under Art. 74(6), and Annex III point 8 administration of justice). Chinese companies that build their own base model and their own application land in that bracket easily, and sending the report to the wrong body means having reported without having reported to the right authority. Suggested columns: incident type / determination test / jurisdiction and provision / deadline / recipient (Art. 73 or Art. 75(1a)) / report template id / internal decision-maker.

   Evidence to attach

   • · Incident taxonomy and severity criteria, including AI-specific incident types
   • · Reporting-duty matrix with the columns above, covering every market served
   • · Rule for fixing the moment of "becoming aware" (which alert, ticket or complaint starts the clock)
   • · Internal early-warning settings per tier (a 2-day case must reach the committee within 12 hours)
   • · Annual review record for the determination criteria

   Common pitfalls

   • · Preparing only an information-security severity scale, with no AI-specific incident types (harm to health, safety or fundamental rights from model output, disruption of critical infrastructure, discriminatory outcomes);
   • · No rule for fixing "awareness", leaving the lateness question arguable after the fact;
   • · Treating 15 days as the default and overlooking the shorter 2-day and 10-day tiers;
   • · Naming the Member State market surveillance authority as the recipient in every row, without checking whether Art. 75(1a) routes the report to the AI Office instead;
   • · A matrix covering the EU only, with the duties in China, Singapore and elsewhere missing;
   • · No path for an initial incomplete report, so the team waits for full information and misses the deadline.

2. 2. 2. Detection channels and intake

   List every channel through which an incident might surface and make sure each funnels into the same intake point: system monitoring and alerting, anomalies in post-market monitoring metrics under Art. 72, analysis of Art. 12 logs, user complaints and reports, feedback from deployers and enterprise customers, vulnerability disclosures from external researchers, media and social-platform signals, enquiries from regulators or law enforcement, and internal staff escalation. For each, record the recipient or system, whether it is covered around the clock, and how and how fast it reaches intake. Intake must fix a few facts immediately: the time of detection, the channel, an initial description, the systems and versions involved, the geographies and user population affected, an initial severity judgement, and the determination of when the company became aware. Registration has to be faster than judgement — most missed deadlines come not from slow analysis but from nobody registering anything in the first few hours while the clock was already running.

   Evidence to attach

   • · Channel inventory with the recipient and coverage hours for each
   • · Configuration of the single intake point and the routing rules
   • · Intake form template, including the awareness-timestamp field
   • · Statistics on the delay from each channel to intake
   • · Vulnerability disclosure policy and records of responses to external researchers
   • · Process for receiving and routing regulator enquiries

   Common pitfalls

   • · Issues raised through sales or support never entering the incident process, and surfacing weeks later as a serious incident;
   • · Channels staffed only during business hours, leaving weekend and holiday incidents unhandled;
   • · An intake form with so many required fields that the front line skips registration to save time;
   • · A vulnerability mailbox nobody reads, pushing researchers to public disclosure and exposing the incident in the worst way;
   • · Regulator enquiries handled privately by individual staff with no company-level record.

3. 3. 3. Severity determination and causal assessment

   Art. 73(2) sets the trigger at the point where the provider has established a causal link between the AI system and the serious incident, or the reasonable likelihood of such a link. "Reasonable likelihood" matters: you do not need a finished root-cause analysis before the clock starts. So split the determination in two: a rapid triage (could this be a serious incident, could it relate to the AI system, which deadline tier applies) and a detailed assessment (root cause, blast radius, responsibility boundary). Triage must finish within hours and have a named decision-maker; detailed assessment runs in parallel. The determination covers: the type and degree of harm (personal injury, damage to health, property loss, infringement of fundamental rights, disruption of critical infrastructure, environmental damage), the number of people and geographies affected, whether the incident is ongoing, and whether it may spread. Preserve the technical chain of evidence for the causal assessment: relevant logs, model version, input and output samples, configuration snapshots. Note Art. 73(6): following the report the provider must without delay perform the necessary investigations into the serious incident and the AI system concerned, including a risk assessment of the incident and corrective action; it must cooperate with the competent authorities and, where relevant, the notified body during those investigations, and it must not perform any investigation that involves altering the AI system in a way that may affect any subsequent evaluation of the causes before informing the competent authorities. In other words, fixing before reporting is expressly prohibited.

   Evidence to attach

   • · Triage workflow with a named decision-maker and a round-the-clock backup
   • · Severity determination record (harm type, degree, scope, whether ongoing)
   • · Technical chain of evidence for causation (logs, versions, samples, configuration snapshots)
   • · Evidence-preservation procedure so remediation does not overwrite it
   • · Technical control implementing the no-alteration-before-notification rule (a change freeze)
   • · Escalation path where the determination is contested

   Common pitfalls

   • · Starting the clock only when root-cause analysis is done, while the statutory trigger is reasonable likelihood and the deadline has long since started;
   • · Engineering instinctively rolling back and hot-fixing, overwriting the evidence and altering the system before the authority is informed;
   • · A single decision-maker with no backup, so nobody can make the call while they are on leave;
   • · Log retention shorter than the investigation window, with the critical period already purged;
   • · A severity judgement based on technical impact alone, with no assessment of fundamental-rights impact or the number of people affected.

4. 4. 4. Containment, emergency response and user-protection measures

   Run containment alongside reporting, but keep the two records separate so response actions do not contaminate evidence. Containment covers: limiting exposure (rate limiting, disabling the affected function, rolling back to the last stable version, raising the human-review ratio, targeted blocking rules); reducing impact (withdrawing incorrect outputs, correcting decisions already made wrongly, providing redress to affected individuals); and recovery (verifying the fix, phased restoration, a heightened-monitoring period). Record for each action: what was done, by whom, when, who approved it, and whether it may affect the subsequent evaluation of causes — that last field implements the Art. 73(6) restriction, so an action that changes system state and could affect the causal evaluation must wait until the competent authority has been informed, or be preceded by full preservation of the scene. On user protection, decide three things: whether affected users must be told directly (GDPR Art. 34 requires communication to data subjects without undue delay where the breach is likely to result in a high risk to their rights and freedoms); whether contractual notification to enterprise customers is owed; and whether a public statement is needed. Art. 27 of China’s Cybersecurity Law requires an emergency response plan for cybersecurity incidents with prompt handling and reporting as prescribed, and that plan should match the process described here.

   Evidence to attach

   • · Response register (action, actor, time, approver, and the judgement on effect upon causal evaluation)
   • · Evidence-preservation records (snapshots, log exports, hashes)
   • · Notification text sent to affected users and the send records, including language versions
   • · Enterprise customer notifications and the contractual basis for them
   • · Public statement publication record and the approval of its wording
   • · Records of withdrawing incorrect outputs and correcting wrong decisions
   • · The cybersecurity emergency response plan and how this incident was handled against it

   Common pitfalls

   • · Changing the live system to stop the bleeding without preserving the scene or informing the authority first, breaching the Art. 73(6) restriction;
   • · Technical containment only, with decisions already made wrongly left uncorrected and the harm continuing;
   • · Notifying enterprise customers later than the contract requires, triggering breach;
   • · A public statement worded inconsistently with the report filed with the regulator;
   • · An emergency plan that lives in a filing cabinet and that nobody follows during a real incident.

5. 5. 5. Report drafts and submission records

   Prepare a draft template for each reporting duty so that during an incident it only needs filling in. The EU serious-incident draft should cover: provider and EU authorised representative details; the AI system identifier and version; the Member State where the incident occurred, since Art. 73(1) directs the report to the market surveillance authorities of the Member State where it happened; a description and timeline; the type of harm and the number of people affected; the current causal assessment and its evidence; measures taken and planned; and a contact. GDPR Art. 33(3) specifies the content of a breach notification: describe the nature of the personal data breach including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned; give the name and contact details of the data protection officer or other contact point where more information can be obtained; describe the likely consequences of the breach; and describe the measures taken or proposed by the controller to address it, including, where appropriate, measures to mitigate its possible adverse effects. The China 24-hour draft should cover the defect or vulnerability, the scope affected, the potential harm, measures taken and the plan going forward. Attach to each draft: the submission channel, the recipient’s contact details, and a history of past submissions (time, method, acknowledgement, follow-up correspondence). Art. 73(5) permits an initial incomplete report followed by a complete one, so design each draft with an initial and a complete column.

   Evidence to attach

   • · Draft templates for each report type, with initial and complete columns
   • · Recipient list with contact details per Member State or region, including backups
   • · Submission channel documentation and periodic checks that accounts and credentials still work
   • · History of submissions and acknowledgements
   • · Supplementary reports and follow-up correspondence
   • · Internal approval flow for external reports (who may sign one out)

   Common pitfalls

   • · Hunting for the authority’s contact details during the incident and losing hours to it;
   • · Not knowing which Member State to report to — Art. 73(1) points to where the incident occurred, not where the company is registered;
   • · Insisting on complete information and forgoing the initial report Art. 73(5) allows;
   • · A GDPR notification missing the Art. 33(3) elements, especially likely consequences and mitigating measures;
   • · Engineering sending the external report without legal review, with wording that concedes liability unnecessarily.

6. 6. 6. Value-chain notification: upstream providers and downstream deployers

   AI incidents rarely stay inside one company. Set out the two-way flow. Upstream: where the incident relates to a third-party model, dataset or component, notify the upstream provider under the contract and the Art. 25 cooperation arrangements, and request what they hold — logs, known issues, similar reports from other customers. Downstream: where your company is the provider, the incident may affect deployers’ ability to meet their own duties (Art. 26 operational obligations, Art. 27 FRIA updates, the deployer’s own route under Art. 73), so notify promptly and give them enough to judge their exposure — the affected version range, the triggering conditions, interim mitigations and the fix timeline. Art. 73 covers deployers as well as providers: in some situations the deployer carries its own reporting duty and depends on information from the provider, so the timeliness of your notification directly determines whether they can comply. Enterprise contracts often set shorter notice periods (24 or 48 hours), which belong in the same timeline as the statutory clocks. Agree the wording in advance so different account teams do not tell different customers different things.

   Evidence to attach

   • · Upstream and downstream notification lists with the contractual notice periods
   • · Notification templates: requesting information upstream, and disclosing impact downstream
   • · Records of notifications sent and acknowledgements received
   • · Information requests to upstream providers and their responses under Art. 25(4)
   • · The agreed external wording and its approval record
   • · A checklist of what downstream deployers need in order to meet their own reporting duty

   Common pitfalls

   • · Reporting to the regulator and forgetting that downstream deployers also have a duty and depend on your information;
   • · Overlooking a contractual 24-hour customer notice and applying the statutory 72 hours to everyone;
   • · Different account teams giving different customers different accounts of the same incident;
   • · No formal record of information requested upstream, so reasonable efforts cannot be shown later;
   • · A notification so vague ("an issue has been identified and fixed") that downstream cannot tell whether it is affected.

7. 7. 7. Investigation, corrective action and feedback into risk management

   Art. 73(6) requires the provider, following the report, to perform without delay the necessary investigations into the serious incident and the AI system concerned, including a risk assessment of the incident and corrective action, and to cooperate with the competent authorities and, where relevant, the notified body during those investigations. Close the loop here: investigation scope and method (log analysis, reproduction, data review, code review, interviews); root-cause conclusions at three levels (technical, process and organisational — write all three); corrective actions (immediate, short-term and structural, each with an owner and a deadline); effectiveness verification (how you show the same class of incident cannot recur — new test cases, monitoring metrics, gate rules); and the feedback path — the conclusions must return to the Art. 9 risk management system as new or adjusted risk entries, to the Annex IV item 6 change register as a relevant change, to the Art. 72 post-market monitoring plan as new metrics, and to the corresponding sections of the technical file. Where the incident exposes a design-level problem, assess whether it amounts to a substantial modification under Art. 43(4) and whether a fresh conformity assessment is therefore required. Keep a record of every exchange with the competent authority during the investigation.

   Evidence to attach

   • · Investigation plan and report, including three-level root-cause analysis
   • · Corrective-action register (tier, owner, deadline, completion evidence)
   • · Effectiveness verification records (new test cases, monitoring metrics, gate rules)
   • · Updates made to the risk register (entries added or adjusted)
   • · Synchronised updates to the change register and the technical file
   • · Substantial-modification determination under Art. 43(4)
   • · Correspondence with the competent authority and the notified body

   Common pitfalls

   • · Root-cause analysis stopping at the technical layer ("a threshold was set wrong"), never reaching process or organisation, and the same class of incident recurring six months later;
   • · Corrective actions consisting entirely of "more monitoring" and "more training", with no structural change;
   • · Investigation conclusions never fed back into the risk register or the technical file, breaking the loop;
   • · A design-level fix with no substantial-modification assessment, leaving conformity status in doubt;
   • · Several people corresponding separately with the authority and giving inconsistent accounts.

8. 8. 8. Incident register, metrics and drills

   The register is what this template looks like in peacetime and the material that best demonstrates governance maturity to inspectors and customers. Suggested fields: incident id; detection time; the awareness timestamp; detection channel; systems and versions involved; geographies; incident type and severity; which jurisdictions’ reporting duties were triggered, ticked one by one; the actual submission time of each report and the margin against its deadline; containment measures; root-cause level; corrective actions and their closure dates; lessons learned; and the related risk-register entry ids. Analyse trends on top of it: incident volume and type distribution, mean time to detect and mean time to report, deadline attainment rate, the share of repeat root causes, and the on-time closure rate for corrective actions. Those metrics serve Art. 72 post-market monitoring at the same time. On drills: run at least one tabletop exercise a year covering the shortest tiers (the 2-day and 24-hour clocks) to verify that contact details work, decision-makers are reachable, templates are usable and evidence can be preserved quickly; record what the drill exposes and fold it into improvements. Set the register’s retention period and access controls explicitly — incident records often carry sensitive technical detail and personal information, so they must be producible to regulators and still controlled.

   Evidence to attach

   • · The incident register with the fields above, including deadline margin
   • · Trend analysis reports, quarterly or half-yearly
   • · Metric definitions and calculation methods
   • · Annual drill plan, scenario scripts and drill records
   • · Issues exposed by drills and evidence they were addressed
   • · Retention period, access controls and redaction rules for the register
   • · How these metrics connect to the post-market monitoring plan

   Common pitfalls

   • · A register recording only "closed", with no deadline margins, so compliance with each clock cannot be demonstrated;
   • · Never drilling the shortest tiers, and discovering during a real incident that contacts are stale or decision-makers unreachable;
   • · A high share of repeat root causes that nobody tracks, showing corrective actions have long been superficial;
   • · Over-broad access to a register whose entries contain personal information;
   • · Incident metrics and post-market monitoring kept as separate systems, counting the same phenomenon twice on different conventions.