AI Incident Response Policy Template 2027 (EU AI Act).

A severity scheme built on outage and response time does not track the AI Act’s reporting trigger, which is an outcome: death or serious harm to health, a serious and irreversible disruption of critical infrastructure, an infringement of fundamental-rights obligations, or serious harm to property or the environment (Article 3(49)). This AI incident response policy template ties severity classes to those outcomes and to the Article 73 reporting clocks, then sets out the reporting workflow and the tabletop exercises that test it, followed by a clause-by-clause policy skeleton you can adapt. Planning dates are 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems under Regulation (EU) 2026/1744.

Which Incident Duties Bind Which Role, and From When

Regulation (EU) 2026/1744 of 8 July 2026, the Digital Omnibus on AI, entered into force on 27 July 2026. It replaced the third paragraph, point (c), of Article 113, which fixes when Chapter III applies. The consolidated text of Article 113 on the Commission’s AI Act Service Desk (EUR-Lex consolidated version as at 27 July 2026) sets Chapter III, Sections 1 to 3, to apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems classified under Article 6(1) and Annex I. Four incident duties sit across those dates.

The Article 73 row carries an interpretive question that a policy should record rather than hide. Article 73(1) binds providers of high-risk AI systems, and the rules that classify a system as high-risk and impose provider obligations sit in Chapter III, which Article 113 defers. Because Article 113 lists no exception for Chapter IX, published commentary reads the commencement of Article 73 differently. Govern365’s analysis (4 October 2026) treats Article 73 as applicable from 2 August 2026 on the ground that Chapter IX appears in no exception, while noting that the population it binds arrives with Chapter III. aissist’s summary attributes to Gibson Dunn the view that the Article 73 deadlines apply from 2 December 2027 for Annex III systems. As analysis, a policy for an Annex III provider is safest built against 2 December 2027 and carries a revision trigger for any Commission guidance on the point.

Legacy systems have their own rule. As amended, Article 111(2) applies the Regulation to operators of high-risk systems placed on the market before the date of application of Chapter III only if those systems undergo significant changes in their designs, while providers and deployers of high-risk systems intended for use by public authorities must take the necessary steps to comply by 2 August 2030. A policy that covers legacy systems therefore needs a design-change test, not only a placement date.

Two narrowing rules also shape scope. Under Article 73(9), providers of Annex III systems that are subject to Union reporting obligations equivalent to those in the AI Act report only the incidents covered by Article 3(49)(c), meaning infringements of obligations under Union law protecting fundamental rights. Article 73(10) applies the same limit to high-risk systems that are safety components of devices, or are themselves devices, under Regulations (EU) 2017/745 and (EU) 2017/746, with the report made to the national competent authority that the Member State where the incident occurred has chosen for that purpose.

Article 26(5) also carries two carve-outs. The deployer’s duty does not cover sensitive operational data of deployers that are law enforcement authorities, and for financial institutions subject to internal governance requirements under Union financial services law, the monitoring obligation in the first subparagraph is deemed fulfilled by complying with those rules.

The Article 3(49) Trigger and What the Policy Scope Should Say

The policy’s definition clause should track the statute rather than an internal incident taxonomy. Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to one of four outcomes: the death of a person or serious harm to a person’s health; a serious and irreversible disruption of the management or operation of critical infrastructure; an infringement of obligations under Union law intended to protect fundamental rights; or serious harm to property or the environment. The words “directly or indirectly” widen the causal link beyond harm the system produces itself, so a wrong output that a person acts on can meet the definition.

Two further definitions drive the shortest clock. Article 3(61) defines a widespread infringement by reference to harm to the collective interests of individuals in at least two Member States other than those in which the act originated or the provider or deployer is established, or to common-feature harm occurring concurrently in at least three Member States. Article 3(62) defines critical infrastructure by reference to Article 2, point (4), of Directive (EU) 2022/2557. A scope clause should name both so the incident lead can test them without consulting counsel first.

The Commission’s draft guidance and reporting template on serious AI incidents was published for consultation on 26 September 2025 and the consultation ran until 7 November 2025. Article 73(7) set 2 August 2025 as the date for the Commission’s guidance. Published Commission materials located for this article present only the draft, so figures that appear in it should be treated as non-binding direction, and the policy should reserve a review point for the final version.

Severity Classes Keyed to Statutory Outcomes

An AI incident severity scheme needs two classifications on every record. The first is an operational tier that governs containment urgency, set by the organisation: for example, whether the system is disabled, degraded, or left running under monitoring. The second is a statutory reportability class that follows the Article 3(49) outcomes and the Article 73 clocks. The operational tier is governance practice. The statutory class is binding text. The class labels A to D below are this template’s own drafting labels and are not statutory terms.

Two readings of the table matter for drafting. The ten-day clock in Article 73(4) attaches to death of a person, while the serious-harm-to-health limb of Article 3(49)(a) falls under the fifteen-day default unless a death occurs. And the fifteen-day figure is an outer bound, since Article 73(2) requires the report immediately after the provider has established a causal link or its reasonable likelihood.

Policy wording for these classes can run along these lines, to be adapted by each organisation and not a statutory text:

1. Every incident record carries an operational tier and a statutory reportability class, and the record states the reasoning for each.
2. The statutory class is assigned by [named role] using the Article 3(49) outcome limbs and is reviewed whenever new facts arrive, including later confirmation of a death or of a cross-border effect.
3. The awareness timestamp records the earliest moment at which [the organisation] or its deployer, where applicable, became aware of the incident, and later entries do not overwrite it.
4. An incident whose class is uncertain is handled on the clock of the shortest class it could belong to until the class is settled.

The reason for a second axis is analytical. A matrix that ranks by availability and response time cannot detect a system that is healthy, fast and wrong, whose output entered a decision about a person. Reportability under Article 3(49) turns on what the output was used for and who was affected, which is why the statutory class cannot be derived from the operational tier.

The Reporting Workflow

The workflow below follows the order in which Articles 26(5) and 73 operate. Owners are role names for the organisation to assign.

1. Record the awareness timestamp. Article 73(2) to (4) run their outer bounds from the moment the provider or, where applicable, the deployer becomes aware of the serious incident. Owner: incident lead.
2. Classify on both axes. Assign the operational tier and the statutory class from the table above. The window for doing so is an internal choice, set short enough to leave room inside a two-day clock.
3. Deployer path. Under Article 26(5), a deployer that has identified a serious incident informs the provider first, then the importer or distributor and the relevant market surveillance authorities. Where the deployer cannot reach the provider, Article 73 applies mutatis mutandis. Owner: deployer liaison.
4. File an initial report where timing requires it. Article 73(5) allows an incomplete initial report followed by a complete one. The policy should state that uncertainty about causation is not a reason to wait. Owner: notification lead.
5. Identify the recipient. Article 73(1) directs the report to the market surveillance authorities of the Member States where the incident occurred. Providers within AI Office competence report to the AI Office under Article 75(1a). Designations of national authorities vary by Member State, so the policy should hold a register that is updated as designations change.
6. Preserve before altering. See the next subsection.
7. Investigate. Article 73(6) requires the provider, without delay after reporting, to carry out the necessary investigations, including a risk assessment of the incident and corrective action, and to cooperate with the competent authorities and, where relevant, the notified body.
8. Handle authority follow-up. Under Article 73(8), the market surveillance authority takes appropriate measures within seven days of receiving the notification, following the notification procedures of Regulation (EU) 2019/1020. Article 73(11) requires national competent authorities to notify the Commission of any serious incident immediately.

Preservation before alteration

The second subparagraph of Article 73(6) bars the provider from performing any investigation that involves altering the AI system concerned in a way that may affect a later evaluation of the causes of the incident, before informing the competent authorities of that action. The text does not list examples. As analysis, the distinction a policy needs is between containment that leaves the artefact under investigation intact, such as disabling a route or feature, and remediation that changes it, such as replacing model weights, changing a prompt, or redeploying a previous version. The second group should require sign-off from the person authorised to notify the authorities, and the policy should name that person.

Evidence package

An incident file that can be reconstructed after the people involved have moved on contains the following:

• the awareness timestamp and the classification record with reasoning;
• a snapshot taken at detection covering model or system version identifiers, prompts, configuration, inputs, outputs and logs;
• notification records, including any incomplete initial report and the later complete report;
• the record of authority communications and any prior notice of system alteration;
• the record of which parallel regimes were assessed and notified.

Log retention belongs in the same clause. Article 26(6) requires deployers to keep the automatically generated logs of a high-risk system, to the extent the logs are under their control, for a period appropriate to the intended purpose and of at least six months, unless Union or national law provides otherwise, in particular Union law on personal data protection. Under Article 72(3) as amended, the Commission is to adopt guidance, including a template, on the post-market monitoring plan by 2 September 2027, and the plan forms part of the technical documentation referred to in Annex IV.

Parallel regimes

An AI incident can trigger duties outside the AI Act at the same moment. Article 33(1) of the GDPR sets notification of a personal data breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of it. Article 23 of Directive (EU) 2022/2555 (NIS2) sets an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report not later than one month after the notification. Entities in other regulated sectors, including financial entities, should map the incident-reporting rules of their own sector regulation into the same workflow. These regimes run on their own triggers and their own clocks. The analysis of GDPR and AI Act data overlaps addresses the case where one incident involves personal data and also falls within Article 55.

Model Providers: Article 55(1)(c) and the Code of Practice Clocks

For providers of general-purpose AI models with systemic risk, Article 55(1)(c) requires keeping track of, documenting and reporting serious incidents and possible corrective measures without undue delay to the AI Office and, as appropriate, to national competent authorities. The article states no number of days. Article 113(b) applies Chapter V from 2 August 2025 with the exception of Article 101, which covers fines for providers of general-purpose AI models and takes the general application date in Article 113.

Article 55(2) allows providers to rely on codes of practice to demonstrate compliance until a harmonised standard is published, and requires providers that do not adhere to an approved code to demonstrate alternative adequate means of compliance for assessment by the Commission. The Commission published the General-Purpose AI Code of Practice on 10 July 2025, and Jones Day’s summary describes its Safety and Security chapter as requiring serious-incident notifications to the AI Office within two to fifteen days depending on severity. The Code is voluntary. As analysis, a non-signatory still owes Article 55(1)(c), and the Code’s clocks are the only published benchmark against which “without undue delay” is likely to be read, so a non-signatory’s policy should record how it will demonstrate its alternative means.

Where the model and the AI system built on it are developed by the same provider or by providers in the same undertaking, Article 75(1) gives the AI Office exclusive competence, subject to four exceptions: systems related to Annex I products, systems referred to in Annex III point 2, systems provided by law enforcement, border management authorities and financial institutions insofar as Article 74(6) applies, and systems referred to in Annex III point 8 on the administration of justice. Systems integrated into designated very large online platforms or search engines also fall within AI Office competence. For a provider in that position, the policy’s recipient field is the AI Office under Article 75(1a).

Tabletop Exercises That Test the Clock

Article 73 does not prescribe exercises, and neither the AI Act provisions cited here nor the standards below set a frequency. The case for a tabletop is the shape of the shortest clock: two days leaves no room for an external legal opinion or a weekly governance meeting, so the first time the organisation tests its classification and notification decisions should not be during an incident.

CISA reports that it has conducted two tabletop exercises on AI security incident collaboration with participants from industry, government and international partners, and that lessons from them feed into an AI Security Incident Collaboration Playbook; its JCDC AI Cyber Tabletop Exercise Series page lists the objectives and scenario resources. A NIST workshop deck on incident reporting and response for frontier AI risks (14 May 2026) lists emerging-practice pitfalls that bear on drill design: avoid reporting timelines that do not allow thorough analysis, and avoid assuming reporting mandates substitute for response capability.

The scenarios below are editorial designs, one per Article 3(49) limb, each aimed at a specific decision.

Pass criteria belong in the policy as organisational choices, not statutory requirements: the awareness timestamp is recorded, the correct class is selected with reasoning, an initial report is drafted inside the shortest applicable window, the competent authorities are informed before any alteration, parallel regimes are identified, and the evidence package is assembled. A tabletop differs from adversarial testing. The red team and adversarial testing template documents tests of the system, while a tabletop tests the organisation’s decisions about the system’s incident.

Standards Crosswalk

The standards below are voluntary and do not discharge Article 73 or Article 26(5). They supply management-system framing that auditors and procurement teams recognise.

Roles and Authority to Suspend

Article 26(5) ties the deployer’s duty to a power: where a deployer has reason to consider that use of a high-risk system in accordance with its instructions may present a risk within the meaning of Article 79(1), it informs the provider or distributor and the market surveillance authority without undue delay and suspends use. A policy that names an incident lead but does not name who can order suspension leaves that duty without an owner. The role set should therefore include an incident lead, the notification lead, the person authorised to inform authorities before any alteration, a deployer liaison to the provider, and a legal contact. As analysis, oversight roles that cannot intervene do not meet an intervention duty, so each role in the policy should carry written authority to act.

Policy Skeleton: Clause-by-Clause Draft Wording

The sections above explain the reasoning. This section turns it into a draft policy the reader can adapt. Square brackets mark text the organisation must replace. The class labels A to D are this template’s own drafting labels and are not statutory terms. The wording is a starting point, and a lawyer who knows the organisation’s systems should review it before adoption.

Adapt the placeholders to the organisation’s actual systems, roles and tooling before adoption. Clause 6 should be re-read against the consolidated text of Article 73 whenever the AI Act is amended again, because the clocks are the part of the policy most likely to be tested in practice.

Misreadings That Break Incident Policies

Treating fifteen days as an allowance. Article 73(2) requires reporting immediately after a causal link or its reasonable likelihood is established, and describes fifteen days as the outer limit. A policy that schedules the report for day fourteen misreads the text.

Applying the ten-day clock to serious harm to health. Article 73(4) is limited to the death of a person. Serious harm to health falls under the fifteen-day default unless a death occurs.

Attaching a fine tier to Article 73. Article 99(4) lists obligations of providers under Article 16, authorised representatives under Article 22, importers under Article 23, distributors under Article 24, providers and operators under Article 25(2) and (4), deployers under Article 26, notified bodies, and transparency obligations under Article 50, with a ceiling of EUR 15 000 000 or 3% of worldwide annual turnover. Article 73 is not named in it. Member States lay down penalty rules under Article 99(1). For operators within AI Office competence, Article 75c(4) subjects infringement of any applicable provision, including provisions not listed in Article 99(4), to the Article 99(4) fines, so exposure depends on which authority has competence.

Overlooking the accuracy of authority replies. Article 99(5) sets a separate ceiling of EUR 7 500 000 or 1% of turnover for supplying incorrect, incomplete or misleading information to notified bodies or national competent authorities in reply to a request. The policy should route follow-up questions from an authority through the notification lead and a documented review.

Reading deployer silence as no duty. The clock provisions in Article 73(2) to (4) refer to awareness by the provider or, where applicable, the deployer, and Article 26(5) imposes an immediate duty on deployers.

Treating Code of Practice clocks as statute. The Code is voluntary under Article 55(2). Its clocks describe what signatories commit to and do not appear in Article 55(1)(c).

Why Incident Readiness Now Turns on Evidence and Decision Rights

Article 99(7) lists factors that bear on whether and how much to fine, including the degree of cooperation with national competent authorities, the manner in which an infringement became known to them, in particular whether the operator notified it, and any action taken to mitigate harm to affected persons. Those factors reward a file that shows a timestamp, a classification, a notification and a mitigation record. A severity label does not supply that file.

The dated milestones for planning are 2 September 2027 for the Commission’s post-market monitoring plan guidance under Article 72(3), 2 December 2027 for Annex III systems, 2 August 2028 for Annex I systems, and 2 August 2030 for legacy high-risk systems intended for use by public authorities under Article 111(2). Work that can start before those dates:

1. Adopt the two-axis severity record and set the window for assigning the statutory class.
2. Define the awareness timestamp and make it a protected field.
3. Write the preservation routine and name the person authorised to inform authorities before any alteration.
4. Raise log retention for high-risk systems to at least six months where the organisation controls the logs.
5. Build the recipient register for market surveillance authorities and decide whether reports go nationally or to the AI Office under Article 75(1a).
6. Run one tabletop for each Article 3(49) limb, with the preservation inject in at least one.
7. Add a review trigger for final Commission guidance under Article 73(7) and for any guidance on the commencement of Article 73.

AI Governance Desk

Covering responsible AI, governance frameworks, policy, ethics, and global regulations shaping the future of artificial intelligence.