AI Incident Response Checklist: ISO 42001 to EU AI Act
The EU AI Act's Article 73 gives high-risk AI providers 15 days, 10 days, or as little as 2 days to report a serious incident, depending on severity. This checklist shows how to build the detection, triage, investigation, and reporting capability to meet those windows, mapped to ISO 42001 and NIST AI RMF so it slots into the management system you already run.
The problem: the reporting clock is brutal, and it starts before you feel ready
Most organisations treat AI incident response as something you figure out after something breaks. For most governance topics, that is a survivable strategy. For serious AI incidents, it is not.
The EU AI Act's serious incident reporting duty, Article 73, gives a provider of a high-risk AI system a reporting window measured in days, not weeks. Fifteen days by default. Ten days if the incident involves the death of a person. Two days if it involves a serious and irreversible disruption of critical infrastructure.
Those are maximums, and the clock starts when you or a deployer becomes aware of the incident, not when your legal team gets around to it. You cannot build the detection, triage, investigation, and reporting capability to hit those windows in the week after something goes wrong. It has to exist before.
There is a wrinkle worth naming early. The Digital Omnibus on AI, Regulation (EU) 2026/1744, deferred the Annex III high-risk obligations to 2 December 2027. That means the Article 73 reporting duty for standalone high-risk systems is not yet live for most providers. Do not read that as a reason to wait. It is time to build, because the capability takes months, and because ISO 42001 and NIST AI RMF expect incident management now, not in 2027.
What the three frameworks actually require
The EU AI Act: Article 73 in plain terms
Article 73 requires providers of high-risk AI systems to report any serious incident to the market surveillance authority of the member state where it occurred. The definition of "serious incident" sits in Article 3(49): an incident or malfunction that directly or indirectly leads to the death of a person or serious harm to health, a serious and irreversible disruption of critical infrastructure, or an infringement of Union law obligations protecting fundamental rights.
The windows follow severity. The default is 15 days after you establish a causal link, or a reasonable likelihood of one, between the system and the incident. Death shortens it to 10 days. Critical infrastructure disruption shortens it to 2 days.
Two details most summaries gloss over, and both matter operationally. First, Article 73(5) lets you file an incomplete initial report and follow it with a complete one. That is a lifeline only if you already know who files, in what format, and to which authority. Second, Article 73(6) requires you to investigate, run a risk assessment, and take corrective action, and it forbids any investigation that alters the system in a way that could affect a later evaluation of the causes, before you inform the competent authorities. Pull the plug on a misbehaving model to stop the bleeding and you may have destroyed the evidence regulators need.
And the stakes are not abstract. Non-compliance with operator obligations under the Act can draw fines of up to €15 million or 3% of worldwide annual turnover, whichever is higher (Article 99).
ISO 42001: incident management is threaded through the system
ISO/IEC 42001 does not have a single control labelled "incident response" the way ISO 27001 has Annex A.16. Instead, incident handling is distributed across the management system. Clause 8 requires operational planning and control of your AI risk treatment. Clause 9.1 requires monitoring, measurement, analysis, and evaluation, which is where detection and logging live. Clause 10.1 requires nonconformity and corrective action, which is what happens after. In Annex A, the control objectives on internal organization (A.3), the AI system life cycle (A.6), and information for interested parties (A.8) carry most of the incident workload.
The practical upshot: if you run an ISO 42001 management system, you already own most of the machinery and are missing the AI-specific trigger logic and the reporting muscle. If you do not run one, the checklist below doubles as the first real piece of your Clause 8 and Clause 9 implementation.
NIST AI RMF: the Manage function
NIST's AI Risk Management Framework organises risk work into four functions: Govern, Map, Measure, and Manage. Incident response lives in Manage, which covers risk prioritisation, response, and recovery, including post-deployment monitoring. The framework's central idea is that you cannot respond to an incident you cannot see, so monitoring and response are one loop, not two projects. That is the mental model for everything below.
The checklist: seven things to build before you need them
1. Define "serious incident" for your portfolio, not in the abstract
Article 3(49) gives you the legal definition. It does not tell you what it means for your specific systems. For every AI system you operate or provide, ask what failure mode would push it into the serious incident category. A chatbot producing a hallucinated medical recommendation. A credit scoring model that systematically denies a protected group. A safety component that misreads a sensor.
Write these down per system. This is your incident taxonomy, and it is the thing that turns "something went wrong" into "this is a 10-day report." Without it, you will discover at the worst possible moment that nobody agrees on whether what happened counts.
2. Build detection before you build response
You cannot report an incident you never noticed. This is the step the reporting-focused guides skip. For each serious incident category you defined, identify the signal that would surface it: output monitoring, drift detection, error-rate spikes, user complaints, deployer escalation paths, security telemetry, and log review.
The bar is lower than you think. A serious incident can start with a deployer phoning you, not with your dashboard lighting up. Detection therefore includes the human path: who answers the support ticket, the sales email, the emergency contact? Is there a documented route for a deployer to tell you something went wrong, and does it route to someone who can start the clock?
3. Build the causal-link triage step
The Article 73 clock starts when you establish a causal link, or a reasonable likelihood of one, between the system and the harm. That is a judgment call, and it is the step most teams have no process for. Who decides? On what evidence? How fast?
Write a triage checklist: which facts would establish or rule out a link, what the default position is while you investigate, and who has authority to declare something a reportable incident. A named individual, not a committee, because a committee is how you miss a two-day window.
4. Write the containment runbook with the evidence-preservation rule
Your first instinct in an incident is to stop it. Article 73(6) says you must not alter the system in a way that affects a later evaluation of the causes, before telling the competent authorities. That is in direct tension with normal incident response, where you roll back the model or kill the endpoint immediately.
The runbook has to separate containment that is safe from containment that destroys evidence. Snapshot the model weights, configuration, logs, prompts, and input data before you touch anything. Document what you changed and when. When in doubt, preserve first, then contain.
5. Draft the reports now, not after the incident
Article 73(5) lets you file an incomplete report and follow up. That grace is useless if you are staring at a blank page while a deadline runs. Build three templates now: the 15-day default, the 10-day death report, and the 2-day critical infrastructure report. Each should hold the fields the authority needs: system identification, the harm, the causal-link analysis, the affected deployers, and the corrective action plan.
You do not need to invent the fields. The European Commission's AI Act Service Desk publishes Article 73 guidance, and the reporting content is well defined. The point is to pre-populate your system inventory, technical documentation references, and deployer list so the report is a fill-in-the-blanks exercise, not a research project.
6. Wire it into your ISO 42001 corrective action loop
An incident that is reported but never corrected is a compliance time bomb. Map each incident to Clause 10.1: what was the root cause, what corrective action was taken, what residual risk remains, and was it closed by management review. This is the difference between a vendor that had an incident and a vendor that learned from one, and it is exactly what an auditor or a serious buyer will ask to see.
7. Rehearse it before it is real
Run a tabletop exercise at least annually. Feed the team a realistic incident, something like a biased output from a hiring model or a hallucinated dose from a clinical tool, and walk the full path: detection, triage, causal link, containment, report, corrective action. Time each step against the 2, 10, and 15-day windows. You want to find the gaps in the tabletop, not in front of a regulator.
Where this goes wrong in practice
The first failure pattern is treating AI incident response as a security problem. It is not only that. A serious AI incident is often not a breach. It is a model producing a harmful, biased, or unsafe output with no security compromise at all. If your only incident process is the security one, the AI incident falls through the crack.
The second is waiting for the deadline. The December 2027 deferral is real, but it is a trap if it becomes a reason to do nothing. The reporting windows do not get longer because you deferred the preparation. The organisations that use the time to build are the ones buyers and regulators will trust first.
The third is believing a governance platform gives you incident response out of the box. A dashboard can log an incident. It cannot establish a causal link, run a root cause analysis, or decide whether something meets the Article 3(49) threshold. Those are documented human processes. Software is the record, not the response.
Why this is a procurement asset, not just a compliance cost
Enterprise buyers are already asking AI vendors some version of "what happens when your system fails?" The vendor that can answer with a documented, rehearsed, ISO 42001-mapped incident response plan closes the deal. The vendor that says "we will figure that out if it happens" loses it, usually without being told why. When one vendor in a category can produce that evidence and another cannot, shortlists shift silently.
This is the same dynamic behind the gaps in standard security questionnaires. Buyers have learned that a SOC 2 report does not tell them how you handle a model that harms someone. A live, independently verified incident response posture does. If you want to know how independent verification maps to those questions, see our security questionnaire gap analysis and our breakdown of how ISO 42001, NIST AI RMF, and the EU AI Act converge.
The BizThriveAI take
Build the capability before the deadline forces it. Start with the incident taxonomy and the detection path, because everything else depends on them. The reporting windows are unforgiving, the evidence-preservation rule is counterintuitive, and the whole thing takes longer to stand up than most teams expect. Treat the deferral as runway, not as a pass.
If you want an independent read on whether your incident response posture would hold up, talk to us, look at a sample audit report to see how we map frameworks to evidence, or see how verification is structured on our pricing page.
Written by David Swan, reviewed and fact-checked against primary regulatory sources. AI-assisted but human-directed.
Frequently asked questions
What counts as a serious incident under the EU AI Act?
Article 3(49) defines it as an incident or malfunction that directly or indirectly leads to the death of a person or serious harm to health, a serious and irreversible disruption of critical infrastructure, or an infringement of Union law obligations protecting fundamental rights.
What are the Article 73 reporting deadlines?
The default is 15 days after you establish a causal link, or a reasonable likelihood of one, between the system and the incident. It drops to 10 days if the incident involves a death, and 2 days for a widespread infringement or a critical infrastructure disruption.
Does the Digital Omnibus deferral mean I can ignore incident reporting?
No. Regulation 2026/1744 deferred the Annex III high-risk obligations to 2 December 2027, so the Article 73 duty is not yet live for most standalone high-risk systems. But the capability takes months to build, and ISO 42001 and NIST AI RMF expect incident management now.
How does ISO 42001 address AI incident management?
It does not have a single incident response control like ISO 27001 Annex A.16. Instead, incident handling is distributed across Clause 8 (operational control), Clause 9.1 (monitoring and evaluation), and Clause 10.1 (nonconformity and corrective action), with Annex A objectives A.3, A.6, and A.8 carrying most of the workload.
What should an AI vendor show buyers about incident response?
A documented incident taxonomy, a detection and escalation path, a named owner for causal-link triage, an evidence-preserving containment runbook, draft report templates, and evidence that incidents feed a corrective action loop. Buyers ask what happens when your system fails, and a rehearsed, verifiable answer closes deals.
How long does it take to build this capability?
Realistically weeks to months, depending on portfolio size. The long pole is the incident taxonomy and the detection path, not the report templates. That is why building it before the December 2027 deadline matters.
