We'd like to set analytics cookies to measure which pages are useful. They are not needed to run the site, and declining changes nothing about what you can do here. Privacy Policy.
The reporting window is short and it starts at awareness, not at diagnosis. Having the structure drafted before anything happens is the difference between filing on day two and discovering on day twelve that nobody knows which authority to write to.
Every template on this page is readable in full right here, copyable as Markdown, and downloadable as a PDF. No sign-up, no e-mail address, no click-to-reveal.
Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
The provider of the high-risk system files. A deployer who becomes aware of a serious incident must inform the provider — and, in the sequence Article 73 sets out, the importer or distributor and the relevant authority where the provider cannot be reached.
Immediately on establishing a causal link or its reasonable likelihood, and no later than the applicable window: 15 days as standard, 10 days where a death is involved, 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure.
With the high-risk regime for Annex III systems, from 2 December 2027. The internal escalation path is worth building first — it is the part that cannot be produced under time pressure.
Article 73 — Article 73, Article 72, Article 26
Article 73 requires providers of high-risk AI systems to report serious incidents to the market-surveillance authority of the Member State where the incident occurred. The report is made immediately after the provider establishes a causal link, or the reasonable likelihood of one, and in any event within 15 days of becoming aware of the incident (Article 73(2)); within 10 days in the case of the death of a person (Article 73(4)); and within 2 days in the case of a widespread infringement or a serious and irreversible disruption of the management or operation of critical infrastructure (Article 73(3)). Article 73(5) allows an incomplete initial report followed by a complete one.
Starting the clock at the wrong moment. It runs from awareness of the incident, not from the completion of your investigation — which is exactly why Article 73(5) permits an incomplete initial report.
7 sections. Each one carries what to write and — the part templates normally leave out — what an assessor is looking for when they read it.
Your legal entity, the role you hold under the Act for the affected system, a monitored contact, and the authority this report is going to.
That the right authority was identified — the market-surveillance authority of the Member State where the incident occurred, which is not necessarily where you are established.
System name and unambiguous reference, intended purpose, risk classification, underlying models, and the EU database registration entry if one exists.
Whether the version identified here is the version that was live when the incident occurred, which is not always the current one.
What happened, in sequence. Date of occurrence, date you became aware, date the causal link was established or judged reasonably likely, and the internal status.
The gap between occurrence and awareness, and between awareness and this report. These three dates are the first thing read, because they decide whether the filing was timely.
Which Article 73 category applies and therefore which window: standard (15 days), death of a person (10 days), or widespread infringement or serious and irreversible disruption of critical infrastructure (2 days). Record the reasoning.
The reasoning, not the label. The legal category drives the deadline, so an internal severity rating that quietly downgraded a 2-day case to a 15-day one is the finding.
What you did on becoming aware — suspension, rollback, customer notification — and what corrective action is planned or completed.
Whether the system kept running. Continuing to operate an implicated high-risk system without a documented reason is scrutinised harder than the incident itself.
Who was affected and how many, the nature and extent of the harm, and whether any of it is irreversible.
That the count is a count. 'Potentially all users' where a log query would give a number reads as an investigation that has not been done.
Whether this is an initial or a complete report, what remains under investigation, and when the complete report will follow. Record the investigation and risk assessment you are required to carry out, and your cooperation with the authorities.
That the promised complete report was actually filed. An initial report with no follow-up is a documented, dated, unclosed obligation.
The same document in two portable forms. The Markdown pastes into Notion, Confluence, Google Docs or a repository; the PDF is laid out to be printed and written on, with ruled fill-in areas and a sign-off block.
# Serious incident report (Article 73)
**Legal basis:** Article 73, Article 72, Article 26 — Regulation (EU) 2024/1689 (EU AI Act).
> Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
**Who fills this in:** The provider of the high-risk system files. A deployer who becomes aware of a serious incident must inform the provider — and, in the sequence Article 73 sets out, the importer or distributor and the relevant authority where the provider cannot be reached.
**When:** Immediately on establishing a causal link or its reasonable likelihood, and no later than the applicable window: 15 days as standard, 10 days where a death is involved, 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure.
| Field | Value |
| --- | --- |
| Organisation | |
| AI system | |
| Version / reference | |
| Document owner | |
| Date | |
| Version of this document | |
## 1. Reporter identity
*What to write:* Your legal entity, the role you hold under the Act for the affected system, a monitored contact, and the authority this report is going to.
*What an auditor looks for:* That the right authority was identified — the market-surveillance authority of the Member State where the incident occurred, which is not necessarily where you are established.
_[Your text here]_
## 2. AI system identification
*What to write:* System name and unambiguous reference, intended purpose, risk classification, underlying models, and the EU database registration entry if one exists.
*What an auditor looks for:* Whether the version identified here is the version that was live when the incident occurred, which is not always the current one.
_[Your text here]_
## 3. Incident description and dates
*What to write:* What happened, in sequence. Date of occurrence, date you became aware, date the causal link was established or judged reasonably likely, and the internal status.
*What an auditor looks for:* The gap between occurrence and awareness, and between awareness and this report. These three dates are the first thing read, because they decide whether the filing was timely.
_[Your text here]_
## 4. Seriousness category
*What to write:* Which Article 73 category applies and therefore which window: standard (15 days), death of a person (10 days), or widespread infringement or serious and irreversible disruption of critical infrastructure (2 days). Record the reasoning.
*What an auditor looks for:* The reasoning, not the label. The legal category drives the deadline, so an internal severity rating that quietly downgraded a 2-day case to a 15-day one is the finding.
_[Your text here]_
## 5. Immediate measures and corrective action
*What to write:* What you did on becoming aware — suspension, rollback, customer notification — and what corrective action is planned or completed.
*What an auditor looks for:* Whether the system kept running. Continuing to operate an implicated high-risk system without a documented reason is scrutinised harder than the incident itself.
_[Your text here]_
## 6. Affected persons and impact
*What to write:* Who was affected and how many, the nature and extent of the harm, and whether any of it is irreversible.
*What an auditor looks for:* That the count is a count. 'Potentially all users' where a log query would give a number reads as an investigation that has not been done.
_[Your text here]_
## 7. Further information and follow-up
*What to write:* Whether this is an initial or a complete report, what remains under investigation, and when the complete report will follow. Record the investigation and risk assessment you are required to carry out, and your cooperation with the authorities.
*What an auditor looks for:* That the promised complete report was actually filed. An initial report with no follow-up is a documented, dated, unclosed obligation.
_[Your text here]_
---
Template by Conformly — getconformly.com/templates/serious-incident-report. Free to copy and adapt. Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
How you will know the system is still behaving after launch — sources, thresholds, owners, and the route to an incident report.
One row per AI system, with the columns the EU database will ask for — so the register you keep internally is the register you can file from.
The six-element assessment certain deployers of high-risk AI must complete before the first use of the system.
Not sure this document is yours to write? Classify the system first — or browse all 7 templates.