Two failure modes account for almost every AI incident process we are asked to review. One has logged nothing across a year and more of heavy AI use. The next logs every hallucination and has a register nobody reads. Both fail the same test, because neither can tell you what is actually going wrong.
The classification test, in one sentence. An event is an AI incident when model behaviour, AI-generated content, autonomous decisioning or agent tool use materially contributed to the outcome. Most such events are also ordinary IT, security or privacy incidents. The answer is to tag them as both, not to choose.
Plain-English explainer · ISO/IEC 42001:2023 · ISO/IEC 27001:2022 · TSC 2017 (rev. 2022) · NIST AI RMF 1.0 · OWASP Top 10 for LLM Applications 2026 · EU AI Act Article 73 (post-omnibus dates) · Last reviewed August 2026
An AI incident is an event in which model behaviour, AI-generated content, autonomous decisioning or agent tool use materially contributed to harm, to a loss of control, or to a failure to meet a commitment or an objective. The word doing the work is materially. If the same event would have happened in the same way with the AI component removed, it is an ordinary incident that happened near some AI. If the AI component changed whether it happened, how far it went, or how long it took to notice, it is an AI incident as well — and it is almost always as well, not instead. That dual classification is the practical heart of this page. A support assistant that pastes one customer’s data into another customer’s ticket is a confidentiality incident by impact and an AI incident by mechanism. Running it as only the first means the retrieval fault never surfaces across the other four assistants sharing that connector. Running it as only the second means nobody notifies the affected customer on the clock your contract requires.
The standards are less exotic on this than the discourse suggests, and it is worth being precise about what each one actually says. ISO/IEC 42001:2023 control A.8.4 — communication of incidents — requires a documented plan for communicating incidents to users of the AI system. The standard’s own implementation guidance in Annex B.8.4 expects that plan to cover what constitutes an AI incident, the notification timelines and the details to be reported. So the definition is guidance rather than clause text, the Annex A controls are reference controls applied through the Statement of Applicability rather than blanket obligations, and the drafting is entirely yours. ISO/IEC 27001:2022 control A.5.25 is a triage control: assessment of events and the decision on which are incidents. And the SOC 2 criterion CC7.3 does the same work in a single sentence, requiring that the entity evaluates security events to determine whether they could or have resulted in a failure to meet its objectives — the parenthetical in that criterion is where an event becomes a security incident at all. You already own the machinery. What you are missing is the AI-aware intake question, seven category definitions, a set of AI severity anchors slotted into the scale you already use, a written threshold, a notification matrix, and about a dozen extra fields on the record.
Key Takeaways
- An event is an AI incident when model behaviour, AI-generated content, autonomous decisioning or agent tool use materially contributed to the outcome — the counterfactual test is whether removing the AI component would have changed whether it happened, how far it spread, or how long it went unnoticed.
- Most AI incidents are also security, privacy or availability incidents. Tag both, run one record, and let the impact tags drive notification while the AI tags drive root cause and trending.
- Six categories cover almost everything worth defining: unauthorised agent action, harmful or unsafe output, data leakage through prompts or outputs, agent malfunction, unintended change to systems or data, and model-behaviour regression — with governance or approval failure as the seventh, which is usually the root cause of one of the other six.
- Not every caught hallucination is a ticket. The threshold that survives contact with an assessor is that an inaccuracy becomes an incident when it reached beyond the review loop, when it recurs as a systemic failure mode, or when it could plausibly have been high-impact — and everything below the line is aggregated and trended rather than discarded.
- You almost never need a separate AI incident register. You need AI incidents to be identifiable, investigable, trendable and reportable inside the existing process, which in practice means a mandatory classification field rather than a second system nobody staffs at three in the morning.
- An AI incident record needs about a dozen fields an ordinary one does not: model and version, the trigger, the assembled context, every tool call including denials, the identity the agent acted under, the actions and their side effects, and the human oversight status — captured at the time, because configuration and trace data both expire.
Is this an AI incident, or just an incident?
Work the two columns independently. Ask whether the event is an incident under the definitions you already use, then ask separately whether an AI component materially contributed. The answers are not exclusive and the third column is where most of the argument in a triage call actually lives.
| Event | IT / security incident? | AI incident? | The reasoning |
|---|---|---|---|
| A phishing email steals an employee session cookie and the attacker reads their mailbox. | Yes | No | No AI component contributed to the event or its impact. Run it exactly as you always have. Having AI somewhere in the estate does not make every event an AI incident, and a taxonomy that says otherwise stops being informative within a quarter. |
| An employee pastes a signed customer contract into a personal chatbot account to summarise it. | Yes — disclosure of confidential data to an unapproved processor | Yes | The AI tool is the disclosure channel, but the failure is an approval and awareness failure rather than a model-behaviour one. Tag both. The corrective action belongs to shadow-AI discovery and to the approved-tool path, not to the model. |
| A support assistant replies to a customer with a paragraph drawn from a different customer ticket. | Yes — confidentiality | Yes | Retrieval scope and model composition together produced the disclosure. The impact is a confidentiality incident. The mechanism is an AI one, and only the AI tags will tell you whether it recurs across other assistants sharing that connector. |
| A coding agent proposes a dependency with a known critical vulnerability. CI blocks the merge. | No | Not on a single occurrence | The control operated and nothing reached an environment. This is a near miss and belongs in the aggregate quality log. It becomes an incident if the pattern recurs, or if investigation shows the block held by luck rather than by design. |
| After a model version change, an agent begins closing tickets without the confirmation step it was designed to require. | Yes — unauthorised change to records | Yes | Two AI categories at once: unauthorised agent action and model-behaviour regression. Without the version field on the record, the second one is invisible and you will fix the symptom. |
| Text embedded in a fetched web page causes an agent to call a tool outside its task. | Yes — an attack succeeded against a system | Yes | Attacker-controlled content steering tool selection is the AI dimension, and it changes the remediation entirely: the answer is capability scoping and confirmation design, not user training. |
| The model provider has a two-hour API outage and the internal assistant is unavailable. | Yes — supplier availability | Only if a governed AI system degraded unsafely | An unavailable assistant is a supplier availability event. It becomes an AI incident when the outage caused a fallback path to behave in a way nobody assessed — stale cached answers served as current, or a queue of agent actions replaying on recovery. |
| A summarisation feature states a wrong revenue figure in an internal draft. The analyst catches it. | No | No, as a single occurrence | The oversight step operated and that is the system working as designed. Record it as a quality signal. It becomes an incident if the same error recurs, if it reaches a decision, or if you find the review step was not actually being performed. |
| A periodic review of a screening tool finds a consistent pattern of disadvantage against one group. | No | Yes | There is no timestamped trigger and no alert fired, but material harm is attributable to system behaviour. Open the record dated to detection, with the analysis itself as the trigger artefact and the affected population as the impact. |
| An agent holding cloud credentials deletes a non-production storage bucket during a cleanup task. | Yes — unauthorised change | Yes | Autonomy contributed directly to the outcome. Severity follows reversibility rather than intent: a restorable bucket is a low-severity incident and a real one, because the same authority reaches production. |
The intake procedure, in six lines
Everything on this page is downstream of six questions. Put them in the runbook in this order, so the responder at eleven at night can follow them without reading the rest.
- 01 Does the AI contribution field say contributed or primary cause? If it says no, run the ordinary process and stop here.
- 02 Which of the seven categories applies? More than one is normal and both get tagged.
- 03 Did it escape the loop, does it recur as the same failure mode, or could it plausibly have been high-impact? Any one of the three makes it an incident rather than a quality signal.
- 04 What severity, read off the anchors — recipient, reversibility, data class, whether a decision path was affected?
- 05 Has any statutory or contractual clock started? Ask this before the severity meeting sits, because the clocks run from awareness and not from classification.
- 06 Which run-record fields have to be captured now, before they expire — model version, tool-call sequence, identity, action identifiers, guardrail configuration as it stood at the time?
Two habits make this table unnecessary within a quarter. The first is putting the question into intake rather than into a policy: a required field on every incident record asking whether an AI system contributed, with three options — no, contributed, primary cause — collects the data whether or not the person on call has read the taxonomy. The second is accepting that the classification will sometimes be wrong on first pass and building a review step into closure rather than into triage. An assessor is not looking for a process that never misclassifies. They are looking for one that records the decision, applies stated criteria, and corrects itself.
One boundary worth settling early. A tool that only drafts and a tool that acts are not the same governance object, and the classification threshold moves sharply once tool invocation enters the picture — the distinction is worked through in when a tool becomes an AI agent. If your estate is entirely drafting assistants, most of what follows still applies but the unauthorised-action and unintended-change categories will stay empty, and that is a legitimate finding rather than a gap.
The categories worth defining
A taxonomy earns its place when it changes what somebody does. These seven do: each routes to a different owner, a different detection source and a different corrective action. Resist adding an eighth for a scenario you have never seen — an unused category looks like a gap in your data rather than an absence of events.
| Category | What it looks like | Where it is detected | What sets severity |
|---|---|---|---|
| Unauthorised agent action | The agent invoked a tool, or acted on a system, outside the authority it was granted — a write where it held read, a recipient outside the allowed domain, an action the approval design said required a human. | Tool-gateway deny events carrying the tool name and the parameters attempted, MCP server audit logs, Copilot Studio agent run history, and the target system’s own trail — the Microsoft 365 Unified Audit Log, the Salesforce Setup Audit Trail, the cloud provider’s API activity log — reconciled against the approved capability list. | Blast radius of the tool and reversibility of the action, not the intent behind it. An unauthorised action with no harm is still an incident of this category. |
| Harmful or unsafe output | Output that is discriminatory, defamatory, dangerous, or that gives advice the system is explicitly not permitted to give — regulated advice, a commitment on price, a diagnosis, a legal conclusion. | User reports through the concerns channel, output classifiers, red-team exercises, evaluation-suite failures, customer complaints and, uncomfortably often, a screenshot on social media. | Who received it, whether anyone acted on it, whether a protected group or a regulated domain is involved, and whether the output can be retracted. |
| Data leakage through prompts or outputs | Confidential or personal data entering a model or vendor that was never approved for it, or appearing in an output shown to someone not entitled to see it — across tenants, across teams, or outside the organisation entirely. | Connector and retrieval audit logs carrying the identifiers of the documents actually returned, tenancy assertions evaluated in the retrieval query rather than in the prompt, DLP inspection on the prompt path, the identity provider’s enterprise-application inventory and OAuth grant log for unsanctioned tools, and recipient reports. | Data class, volume, recipient, and whether the receiving service retains the input or uses it beyond serving the request — a question to answer from current vendor documentation for your plan tier, not from memory. |
| Agent malfunction | The agent loops, stalls, retries indefinitely, exhausts a budget or an API quota, fails silently while reporting success, or emits malformed actions that break a downstream process. | Run step counts and loop detection, token and spend alerts raised at the billing account rather than in the app, rate-limit rejections, queue depth, and downstream 4xx and 5xx rates — the billing alert is in practice the fastest detector most organisations have. | Cost, how long it ran undetected, and the state it left behind. A loop that spent money is cheap, but a loop that half-processed two thousand records is not. |
| Unintended change to systems or data | Records altered, deleted, merged, sent or published that should not have been — including messages despatched to real recipients and tickets, CRM entries or documents modified in bulk. | Target-system audit logs read at record-identifier level rather than at count level, reconciliation against expected volumes, message-trace and mail-flow logs for anything despatched, version history on documents and tickets, and the team whose data changed under them. | Reversibility above everything, then whether anything left the organisation. An outbound email cannot be unsent, which is why messaging tools deserve a stricter approval design than database writes. |
| Model-behaviour regression | Measurable degradation after a model version change, a system-prompt edit, a retrieval or index change, or a data change: accuracy, refusal rate, tool-selection behaviour, output format, or tone. | Scheduled evaluation-suite results and the evaluation run gating each change, drift monitoring, human override and escalation rates, provider release notes and model deprecation notices, and the support queue. | What decisions depend on the degraded behaviour and how long it ran before anyone noticed. Regressions are the category with the longest average time-to-detect, because nothing alerts. |
| Governance or approval failure | An AI system in production use with no assessment, a system used well outside its approved use case, or a capability added to an existing tool that changed what it can do without anyone re-approving it. | Expense and procurement data, the identity provider’s enterprise-application and OAuth consent inventory, network egress and browser-extension discovery, self-reports through the concerns channel, and vendor change notices that add a capability to a tool you already approved. | What data it touched and how long it ran unassessed. This is the category that most often turns out to be the root cause under one of the others. |
Notice what the severity column does not contain: the word AI. Severity should be set by the same scale you use for everything else — data class, recipient, reversibility, duration, regulatory exposure, number of people affected. An organisation that invents a parallel severity scale for AI events ends up unable to compare them with anything, and a board paper that says two high-severity AI incidents without a common yardstick tells a director nothing they can act on.
The OWASP Top 10 for LLM Applications, 2026 edition, published on 4 August 2026, is the useful public taxonomy for threat modelling, and two of its items map directly onto categories above. Prompt Injection is LLM01. Excessive Agency moved to LLM03 in the 2026 edition, up from LLM06 in 2025 — the largest upward move in the list, driven by production incidents in agentic systems — and it is the item that corresponds to the unauthorised agent action category here. Because items are renumbered between editions, pin the edition and the item title whenever you cite one in a policy, or the policy silently misstates itself the next time the list is revised. The same discipline applies to anything you cite from a vendor taxonomy.
The anchors that make an AI severity call
These anchors slot into the severity scale your organisation already runs. They do not replace it, and inventing a parallel AI scale is the mistake that makes AI incidents incomparable with everything else on the board pack. What the AI column adds is the set of facts that decide the level for an AI event, which are not the facts a network or endpoint incident turns on: who or what received the output, whether an action reached a system and can be undone, whether a human decision depended on it, and whether a clock has started.
| Level | Anchor definition | AI-specific anchors | Response and escalation |
|---|---|---|---|
| Critical | Irreversible effect outside the organisation, a regulated decision affected, or an autonomous action that reached production and destroyed or corrupted data. | The agent wrote to or sent to external parties and the action cannot be retracted. An autonomous action executed against a production system. Harmful output reaching a protected group or a regulated domain. A statutory reporting clock has started. | Suspend the agent immediately rather than after the meeting. Executive and legal engaged within the hour. Notification assessment the same day, with the clock recorded against the awareness timestamp, not the classification timestamp. |
| High | External recipient, but reversible or retractable, or an internal effect on a decision that a person relied on. | Cross-tenant disclosure caught after delivery. An unauthorised tool call that succeeded. A model-behaviour regression sitting on a path where a human decision depends on the output. Bulk modification of records with identifiers recoverable. | Contain within the shift. AI system owner and the impact-assessment owner both on the record. Retraction attempted and the attempt recorded whether or not it worked. Customer communication drafted before it is asked for. |
| Medium | Internal only and contained, with the control chain intact and no external effect. | An unauthorised tool call denied at the gateway on a tool the agent has never needed. A regression inside a decision path where human review demonstrably still operated. A spend or loop event stopped by a limit. | Normal queue with a named owner and a fixed close date. The corrective action goes to capability scoping or to the evaluation gate, not to user training. |
| Low | No impact and the control operated as designed. Recorded because the causal chain is worth having. | A near miss on a high-consequence path. A denial on a tool adjacent to the approved set. A single caught inaccuracy on a path where inaccuracy would have mattered. | Recorded with impact stated as none, closed quickly, and counted in trending. These are the entries that make a short register credible rather than suspicious. |
Two anchors are worth arguing about in advance, because they are where a triage call stalls. Reversibility outranks intent and outranks volume. An agent that modified four thousand records recoverably is a lower severity than one that sent three emails, because the emails cannot be unsent. That ordering feels wrong the first time a team applies it and correct every time afterwards. Unauthorised action is severity-bearing even at zero impact. An agent that called a tool it was never approved for and caused no harm still sits at Medium rather than at Low, because the authority boundary is the control you are claiming operates, and it did not. Reserve Low for events where the control worked.
Not every hallucination is a ticket
The failure mode here is symmetrical and both halves are common. Log everything and the register becomes a stream nobody triages, which is functionally the same as logging nothing except that it costs more. Log nothing and you have no population, no trend, and nothing to show an assessor. The way through is two tiers with a written line between them, and the discipline that what falls below the line is aggregated rather than discarded.
| Signal | Default disposition | What moves it up to an incident |
|---|---|---|
| One wrong fact in a draft, caught by the person who asked for it | Quality log, aggregated. Not an incident. | Same wrong fact three times in a week, the draft went out, or you discover the reviewer had stopped reading and the catch was chance. |
| A refusal that blocked a legitimate task | Quality log. It is a usability defect. | Refusals concentrate on one group of users or one topic, which turns a defect into a fairness question worth a record of its own. |
| An agent action denied at the tool gateway | Aggregate. Denials are the control working. | A rising denial rate, denials on a tool the agent has never needed, or a denial pattern consistent with content-borne instructions rather than user intent. |
| An output that reached a customer, a regulator or a public channel | Incident. Always. | Nothing needs to move it up. The question at this point is severity and notification, not whether to open a record. |
| An evaluation regression inside your stated tolerance | Monitoring record, reported in the periodic review. | It crosses the threshold, it persists across two runs, or it lands on a metric that a human decision depends on. |
| A spend or volume spike with no business explanation | Incident, provisionally, until the run is explained. | It stays an incident if the cause was agent behaviour rather than legitimate demand — and this is the one place where opening early costs nothing and closing late costs a lot. |
| A near miss where the control held, but only just | Incident, with impact recorded as none. | Near misses are the single most valuable entries in the register, because they carry the whole causal chain without the harm. A register with no near misses in it is a register nobody trusts. |
Three questions decide the line, and they are worth writing into the procedure verbatim because they are what a triage call needs at eleven at night. Did it escape the loop? An output that reached a customer, a regulator, a public channel or an automated downstream system is an incident regardless of how minor it looks, because you no longer control its consequences. Is it recurring or systemic? A single wrong answer is an occurrence, but the same failure mode three times is a defect in the system and belongs on the record where it can be trended. Could it plausibly have been high-impact? Near misses on high-consequence paths — an agent that nearly wrote to production, an approval that nearly went through unread — carry the whole causal chain without the harm, and they are the most valuable entries in any register.
Below the line, the aggregate matters more than any single entry. Feedback ratings, evaluation failures, override rates, refusal rates, denied tool calls and support escalations are all monitoring data, and they are what ISO/IEC 42001 Clause 9.1 has in mind when it asks what you monitor, measure, analyse and evaluate. They also answer the question a buyer or an assessor asks about a short incident register, which is never really why is this list short — it is what would you have seen if something had been going wrong.
Who has to be told, and by when
Notification is the hinge the whole classification design turns on, and the single structural fact to absorb is this: every clock below runs from awareness, not from classification. You cannot buy time by deferring the severity call. That is why the intake question about a statutory clock has to sit ahead of the severity meeting, and why an incident procedure with a weekly triage cadence cannot serve a two-day obligation no matter how good the people running it are.
| Obligation | Notify whom | Clock | Runs from | Triggered when |
|---|---|---|---|---|
| EU AI Act Article 73 | The market surveillance authority of the Member State where the incident occurred | 15 days, 10 days where a person has died, 2 days for a widespread infringement or a serious incident affecting critical infrastructure | Awareness — specifically once a causal link between the system and the incident, or its reasonable likelihood, is established | You are the provider of a high-risk AI system placed on the Union market, and a serious incident as defined at Article 3, point (49) has occurred. Subject to the Digital Omnibus deferral: 2 December 2027 for stand-alone Annex III systems, 2 August 2028 for Annex I embedded AI. |
| EU AI Act Article 55(1)(c) | The AI Office and, as appropriate, national competent authorities | Without undue delay | Becoming aware | You are the provider of a general-purpose AI model with systemic risk. This obligation is not deferred — GPAI model obligations have applied since 2 August 2025. |
| GDPR Article 33 | The lead supervisory authority | 72 hours | Awareness | A personal data breach, unless it is unlikely to result in a risk to the rights and freedoms of natural persons. An AI incident that disclosed personal data is a personal data breach, and the AI mechanism does not change the clock. |
| GDPR Article 34 | The affected data subjects | Without undue delay | Awareness | The breach is likely to result in a high risk to the rights and freedoms of natural persons. |
| DPDP Act 2023 (India) | The Data Protection Board of India and each affected Data Principal | In the form and manner prescribed by the Rules | Becoming aware of the breach | You are a Data Fiduciary and a personal data breach has occurred. Read the operative timing off the current Rules rather than off a summary, including this one. |
| Contractual | Enterprise customers, and often their own regulators through them | Commonly 24 to 72 hours as negotiated | Awareness in some contracts, declaration of an incident in others | Whenever the contract says so — and which of those two triggers you signed up to is a clause worth reading before signature, because declaration-based wording gives you a triage window and awareness-based wording does not. |
The AI Act row carries a date qualification that most comparisons written before August 2026 get wrong, so it is worth stating plainly. The Act is Regulation (EU) 2024/1689. It was amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026, which deferred the stand-alone Annex III high-risk obligations to 2 December 2027 and Annex I embedded high-risk AI to 2 August 2028. For most organisations Article 73 is therefore a clock to design for rather than one already running — the exception being providers of general-purpose AI models with systemic risk, whose serious-incident duty has applied since 2 August 2025. The full post-omnibus timeline, and how it interacts with an ISO/IEC 42001 management system, is set out in ISO 42001 versus the EU AI Act.
Two practical consequences follow from putting these in one table. The shortest clock that could apply sets your triage design, not the most likely one. If any obligation in your matrix runs in days, your intake needs a path that reaches legal and privacy the same day, whatever the severity call eventually says. Assessed-as-not-notifiable is a decision that needs a record. The half of the population teams forget to keep is the events they looked at and correctly decided not to report. Without those records, an assessor cannot distinguish a considered judgement from an omission, and the difference is the whole finding.
Do you need a separate AI register?
Almost always, no. The test is not where the records live but whether four things are possible: AI incidents can be identified, investigated, trended and reported within the process you already run. If they can, a second register adds a coordination failure at exactly the moment you can least afford one. If they cannot, the fix is nearly always a field and a workflow rather than a system.
Identified means a mandatory classification field at intake and a stored query that returns the AI population without anyone assembling it by hand. Investigated means the extra record fields in the next section are captured, and that the AI system owner is on the escalation path rather than being consulted three days later. Trended means you can cut the data by system, category, model version, tool and detection source. Reported means the analysis reaches a management review with decisions attached, and that the communication plan A.8.4 asks for gets exercised rather than merely maintained.
Three situations genuinely justify separation, and it is worth being honest about which one you are in. A statutory clock your general process cannot meet — where the EU AI Act will reach you as a provider of a high-risk system from 2 December 2027 under the post-omnibus timeline, Article 73 deadlines run from awareness, and a triage cadence built for a five-day service target cannot serve a two-day obligation. Providers of general-purpose AI models with systemic risk are the exception that is already live. A contractual scope that excludes non-security events — some security incident procedures are written narrowly enough that a fairness finding or a model regression has no home in them, in which case the honest move is to widen the procedure rather than to bolt on a second one. A genuinely separate product-quality function — a model behaviour tracker owned by an ML team is a reasonable thing to have, provided the governance register can see into it and the criteria for promotion between them are written down.
What decides this in an audit room is unglamorous. An ISO/IEC 42001 assessor will ask you to produce the AI incidents for the period. If the answer involves someone reading through a general incident queue and using judgement, you do not have an identifiable population, and the finding is against the process rather than against the tooling. A single mandatory field, applied from day one, is the difference between a five-minute export and a two-week reconstruction — and it is also the difference between trending that means something and a chart assembled once for a slide.
The same logic applies across the management systems. If you already run ISO/IEC 27001, the incident controls at A.5.24 through A.5.28 are the ones your AI events will be tested against for the security dimension, and the sensible design integrates rather than duplicates — the mechanics of running both are set out in integrating ISO 42001 with ISO 27001.
One leak, nine tickets, two root causes
An illustrative composite, not a client. A B2B SaaS company running a customer-support assistant: it drafts and posts replies in the ticketing system, retrieves from a shared knowledge base through a connector, and holds a tool that can close tickets. Read the dates, and read the sixth row twice — it is the one that only exists because the earlier rows were tagged consistently.
| Trigger | 12 Feb 2026, 09:14 | A customer replies to a support ticket. The assistant drafts and posts a public reply that includes two sentences describing a different customer’s contractual terms, retrieved from the knowledge base through a connector scoped to a shared service account. |
| Detection | 12 Feb, 11:40 | The customer replies asking why the response describes another company’s contractual terms. Time-to-detect is two hours and twenty-six minutes, and the detection source is the affected party — the worst of the available sources, and the one that sets the tone of everything that follows. |
| Classification | 12 Feb, 12:20 | Logged once in the existing incident system. Primary tag: confidentiality. AI tags: data leakage through outputs, with governance failure noted as a candidate root cause. Severity set from recipient and data class, not from the fact that AI was involved. |
| Investigation | 12–17 Feb | The run record shows the retrieval step returned four documents, one belonging to another tenant, because the connector inherited the service account’s entitlements and the retrieval filter asserted tenancy in the prompt rather than in the query. The model did exactly what the context supported. |
| Correction | 18 Feb – 3 Mar | Tenancy moves into the retrieval query, the connector is re-scoped, and the assistant is put behind a human release step for external replies. The impact assessment for the assistant is reopened, because the original one assumed retrieval could only reach the requesting tenant. |
| Second signal | 9 Mar | Trending across the AI tags shows nine records in six days of the assistant closing tickets without the confirmation step. All nine post-date a provider model version change on 3 March. Individually each looked like a user complaint, but together they are a model-behaviour regression. |
| Governance outcome | 24 Mar | Two corrective actions to the March management review: pin the model version and gate changes behind an evaluation run, and add a monitoring rule on confirmation-step bypass rate. Both close with named owners and dates. |
The model was not the fault in either case. On 12 February the fault was an authorisation boundary implemented in a prompt instead of in a query — the retrieval layer was told to respect tenancy rather than being unable to violate it. That is a permission-inheritance failure of exactly the kind connectors produce, and the same pattern would have leaked without any model involved. On 9 March the fault was a version change consumed silently, with no evaluation gate between the provider release and production behaviour.
What made the second detection possible was the first record being tagged properly. Nine customer complaints spread across three support agents look like nine complaints. Nine records carrying the same AI system identifier, the same category and a model version that changed on 3 March look like one regression with a date. That is the entire argument for the record schema in the next section, and it is why the fields have to be captured at the time rather than reconstructed: by 24 March the provider had moved on, and the only proof of which version ran on 9 March was the field written by the intake form.
A single AI incident tells you about a system. A trend across consistently tagged AI incidents tells you about a change. Only the second one prevents anything.
Two of the corrective actions above are worth naming as patterns rather than fixes. Moving tenancy from the prompt into the query is the general form of not relying on instructions to enforce a boundary. Pinning a model version behind an evaluation gate is the general form of treating a provider release as a change subject to your change process, not as weather.
What an AI incident record must capture that a normal one does not
A conventional incident record answers what happened, to what, when, who responded and what was done. For an AI incident that leaves out the entire causal chain, because the system that acted is non-deterministic and its behaviour depends on a configuration that changes underneath you. These twelve fields are the delta. Add them to the existing record type as a conditional section rather than building a new one.
| Field | Why it exists | What good looks like | What makes the record unusable |
|---|---|---|---|
| AI system and agent identifier | Ties the event to an assessed system rather than to a product name, so you can ask whether the risk and impact assessments already contemplated this failure. | The identifier used in your AI inventory, plus the environment and the owning team. One identifier, used everywhere, including in the ticket subject. | A product name. Three teams calling the same assistant three things. An entry that cannot be joined to any assessment record. |
| Model, version and deployment identifier | Without it you cannot tell a one-off from a regression, and you cannot answer the only question that matters after a provider updates a model. | The exact model string and version or snapshot as configured at the time, the deployment or endpoint, and whether the version changed inside the incident window. | A family name with no version. A field populated at close from current configuration rather than captured at the time of the run. |
| Provider, plan tier and processing region | Contractual protections, retention behaviour and data location follow the tier and the region, not the brand — and they are exactly what a customer will ask about within an hour of notification. | Provider, the specific enterprise or business tier in force, the region, and a pointer to the current terms you relied on, dated. Consumer-tier and enterprise-tier accounts on the same brand — ChatGPT against ChatGPT Enterprise, Gemini against Gemini for Workspace, a personal GitHub Copilot subscription against the organisation’s — differ structurally in retention and in contractual protection, so the record must name the tier and not the brand. Verify the retention and training position in current vendor documentation for your tier at the time of the incident. Do not carry it from memory or from the last review. | The provider name alone. An assertion about training or retention that nobody re-verified after the contract renewed. A record naming Microsoft 365 Copilot where the run actually happened in a consumer account signed in with a personal address. |
| Trigger — the prompt, message or scheduled run | The event has a first cause and it is almost never the model. It is a user instruction, an inbound message, a webhook, a document, or a schedule. | The initiating input, the channel it arrived through, and whether any part of it came from content the organisation does not control. | A paraphrase written from memory. A field left blank on scheduled runs, which is where unattended failures hide. |
| Assembled context | The model saw more than the prompt. Reconstructing the decision without the context is guesswork, and the context is usually where the fault is. | System-prompt version, the retrieved documents or records with their source identifiers, connector scopes in force, and any memory or conversation history included. | Retrieval logs that record that retrieval happened but not what came back. Prompt templates with no version history. |
| Tools invoked, with parameters and results | This is the load-bearing record. For an agent, the tool calls are the actions, and everything else is commentary on them. | Every call in sequence with parameters, results, errors and denials, timestamped, including the calls that were refused. Denials tell you what the agent tried to do. | Only successful calls. A summary saying the agent updated the CRM without the record identifiers it wrote to. |
| Identity and delegated authority | Somebody has to answer whose permissions the action ran under, and whether the agent exceeded the human it was acting for. | The principal or service identity, the delegating user where the agent acts on someone’s behalf, the scopes granted, and whether those scopes were broader than the task required. | A shared service account used by four agents. An action attributable to a system but not to any person or entitlement. |
| Actions taken and their side effects | Distinguishes an agent that wrote a draft from an agent that changed the world, and drives both severity and recovery. | Each external effect enumerated: records created or modified with identifiers, messages sent with recipients, files written, payments raised, tickets closed. | Volume with no identifiers, which makes reversal a manual reconstruction and makes notification scope impossible to state. |
| Human oversight status | The most contested field in any AI incident and the one an assessor will press hardest on. Oversight that existed on paper and did not operate is a finding in its own right. | Whether a checkpoint was required, whether it fired, who approved, what they were shown, and how long elapsed between presentation and approval. | Approved with a name and no timestamp. A checkpoint recorded as satisfied by a default-accept timeout, which is an absence of oversight recorded as its presence. |
| Output disposition | Determines notification scope, and it is the field that decides whether this is an internal quality problem or an external one. | Who or what received the output, through which channel, whether it left the organisation, and whether retraction was possible and attempted. | Shown to the user with no indication of what happened next. No record of downstream systems that consumed the output automatically. |
| Guardrails and autonomy level in force | The configuration at the time of the run is the control you are claiming operated. It is also the thing most likely to have changed by the time anyone investigates. | Autonomy level, active filters and policies with versions, rate and spend limits, and the approved capability set as configured on that date. | A screenshot of the configuration taken during the investigation, offered as evidence about a run that happened three weeks earlier. |
| Reversal, containment and correlation | Closes the record honestly and links the AI record to the security, privacy or customer incident it also is. | What was undone, what could not be, what compensating action was taken, and the identifiers of every related record in the security, privacy and customer-communication tracks. | Closed as resolved with no statement of residual effect. Two unlinked records describing the same event from different desks. |
Coding agents deserve a note of their own, because they produce an incident class this schema handles awkwardly unless you plan for it. GitHub Copilot, Claude Code and Cursor generate three recurring failure shapes: a vulnerable or entirely hallucinated dependency introduced into a manifest, a secret committed into history, and an agent-authored change merged without the review the branch protection was supposed to require. The run record for those does not live in an application trace. It lives in CI logs, in version-control history, in the pull request and its review metadata, and in the package manifest diff — which is a different retention regime, a different access model and a different owner from the tracing stack behind a customer-facing assistant. Two fields carry the weight here: the commit or pull request identifier as the action identifier, and the human oversight status expressed as who approved the merge and whether the review was substantive. If your incident schema assumes every AI action produces a tool-call trace, the coding-agent incidents will be the ones with empty fields.
Most of these fields cannot be typed in by a responder. They have to come from telemetry the system was already emitting, which makes this table a design requirement for the platform rather than a form to fill. ISO/IEC 42001 control A.6.2.8 covers recording of event logs and A.6.2.6 covers operation and monitoring. Read together with the record above they say the same thing an engineer would say — if the run was not traced, the incident cannot be investigated, and no amount of process compensates.
The two fields that fail most often are the version field and the retention window behind the tool-call trace. Version fails because teams configure a model family rather than a pinned version and then cannot say what ran. The fix is pinning plus a recorded change process for moving between versions. Retention fails quietly: distributed tracing is often kept for days or weeks by default, an assessment window is a year, and the gap is discovered when somebody asks for March. List every log and trace store your incident schema depends on, write its retention beside it, and export anywhere retention is shorter than your reporting period plus the lag before anyone asks.
The identity field deserves its own note because it is the one that turns an AI incident into an accountability question. An action taken by an agent under a shared service account is attributable to a system and to nobody, which is a poor position in front of a regulator and an impossible one in front of an affected customer. What the record needs is the principal, the delegating human where one exists, and the scopes in force — the reasoning is set out in agent identity and delegated authority, and it is far cheaper to fix before an incident than during one.
What the assessor actually requests
Whether the examination is an ISO/IEC 42001 certification audit conducted by an accredited certification body, a SOC 2 examination performed by a licensed CPA firm, or a customer security review, the requests take the same shape and they begin in the same place. Not with a screenshot — with a population, because a sample drawn from an incomplete list proves nothing about the list it came from.
| The request | What satisfies it | What gets rejected |
|---|---|---|
| The complete population of AI incidents for the period | A filtered export from the incident system using a stored, repeatable query on the AI classification field, with the filter, date range and record count visible, produced before any sample is drawn. | A list assembled by hand for the assessment. A tracker separate from the operational system, which raises the question of what the operational system contains instead. |
| Evidence that the population is complete | Reconciliation against independent sources: alerting and monitoring output, the concerns and complaints channel, evaluation-run results, spend anomalies, and the AI system inventory, with differences explained. | A register with three entries and no reconciliation. Any gap between an obvious operational event — a public apology, a customer credit, a rolled-back release — and a corresponding record. |
| The classification decision for a sample of events | For each selection, the recorded decision, the criteria applied, who decided, and when — including events assessed and correctly classified as not an AI incident, which is the half teams forget to keep. | Classification applied retrospectively at close. A decision with no named decider. A criteria document that does not match how the records were actually tagged. |
| The run record behind one incident, end to end | Model and version, trigger, assembled context, the full tool-call sequence with parameters and denials, the identity used, and the actions with their identifiers — retained for the full period, not just the last thirty days. | Application logs that show a request and a response and nothing between. Trace data expired because retention was shorter than the assessment window and nobody checked. |
| Evidence that human oversight operated | The approval record with the reviewer, the timestamp, what was presented, and elapsed time — plus, for the sample as a whole, evidence that reviewers sometimes rejected or amended what they were shown. | A hundred approvals, none rejected, with a median elapsed time of two seconds. That is a rubber stamp and it will be named as one. |
| Evidence that communication happened as the plan requires | The notification itself with its date, mapped to the plan’s committed timeline, the decision record for events assessed as not notifiable, and any regulatory submission with its acknowledgement. | A plan with notification timelines that no incident record demonstrates. A customer told informally by an account manager with nothing in the record. |
| Evidence that trending fed something | The periodic analysis, the risk or impact assessment it updated, the monitoring threshold or guardrail it changed, and the management review minute where it was discussed and a decision taken. | A chart with no consequence. Corrective actions raised and left open across two review cycles, which reads as a process that records problems rather than one that resolves them. |
Selection sizes follow the population and the control frequency, not the subject matter. For a SOC 2 examination the service auditor draws from the incident population using the firm’s own sampling guidance rather than a number published anywhere. For an event-driven population in the low tens, expect the whole population to be examined rather than a sample, and for a population below roughly twenty-five items expect every record to be read. That has a consequence teams consistently underestimate: at small populations there is no averaging out. One record missing a model version or a tool-call trace is a defect rate the auditor cannot dismiss, where the same omission in a population of eight hundred access grants would be immaterial. Under an ISO/IEC 42001 certification audit the mechanism differs — the auditor samples across systems, sites and processes against an audit plan rather than to a statistical basis — but the exposure is identical, because a small population is read in full either way.
Where the AI incident population is genuinely nil for the period, the test does not disappear. It moves entirely onto completeness. Nobody accepts an empty register on its own. The auditor will instead examine the aggregate signals sitting below your threshold — the evaluation runs and their failures, the concerns channel, the escalation queue, denied tool calls, override rates, spend anomalies — to establish that nothing which should have produced a record failed to. This is the single strongest argument for building the below-the-line aggregation on day one rather than the day before fieldwork: a nil population with several hundred recorded signals underneath it is defensible, and a nil population with nothing underneath it is a finding waiting to be written.
The completeness problem is sharper here than anywhere else in an AI programme, and it is worth understanding why. Most control populations are large and mechanical — every merge, every joiner, every access grant — so completeness is a reconciliation exercise. An AI incident population is small and depends on human classification, so an assessor tests it from the outside in. They will read your evaluation results, your support escalations, your bug tracker, your status page and your customer credits, looking for an event that plainly should have produced a record and did not. One such gap does more damage than a badly written record, because it puts the whole population in question rather than a single entry.
A vocabulary note that saves time in fieldwork. What the auditor is establishing about anything you export is its completeness and accuracy, and for a SOC 2 examination the artefact class has a name — information produced by the entity, shortened to IPE. That is why they want the stored query, the filter, the date range and the record count visible rather than the result alone. For an ISO/IEC 42001 audit the vocabulary differs but the instinct is identical, and the auditor will also want to see the incident process running against its own documented criteria rather than against recollection.
One boundary, stated plainly because it is asked about often. ISO/IEC 42001 certificates are issued by accredited certification bodies and SOC 2 reports by licensed CPA firms. Tranquility Cybersecurity designs the classification criteria, builds the record schema, prepares the evidence and coordinates the examination — it does not certify, attest, audit or sign. Where a firm designs or operates a control, it cannot then be the party that examines it, which is the reason for the separation rather than a matter of preference.
How incidents become governance evidence
A register is a cost until it is analysed. The step that converts it into evidence is a periodic cut of the data along axes that correspond to decisions somebody can take. Cut it by AI system, by category, by model version and by tool, because those four tell you where to act. Then compute the six metrics below, because those tell you whether the process itself is working — and every one of them is computed from a field the record schema already carries, which is the whole reason the schema is worth the argument.
| Metric | Definition | Computed from | What a weak result looks like |
|---|---|---|---|
| Detection-source mix | Share of records first detected by monitoring or by an evaluation run, against those first detected by a customer or an affected party. | Detection source, set at intake and never edited at close. | Customer reports dominating, regardless of what the monitoring dashboard shows. This is the metric that embarrasses most programmes and the one a buyer asks for second. |
| Median time-to-detect by category | Detection timestamp minus the start of the exposure window, cut by the seven categories rather than reported as a single number. | Trigger time or exposure-window start, and detection time. | Model-behaviour regression is structurally the worst because nothing alerts on it. A regression found in days rather than weeks is the realistic target, and a single blended figure hides the category that is failing. |
| Oversight rejection rate | Approvals rejected or amended as a share of approvals presented, across the whole approval population and not only the incident sample. | Human oversight status — presented, approved, amended, rejected — with the elapsed time. | A rate at or near zero across a large population is a rubber stamp, and a median elapsed time of a couple of seconds proves it before anyone argues the point. |
| Near-miss ratio | Records with impact recorded as none, as a share of total records. | Impact field, where none is a permitted and expected value. | A register with no near misses in it is a register nobody trusts, because it implies either that the controls never nearly failed or that nobody wrote it down when they did. |
| Run-trace completeness at close | Share of closed AI records carrying model version, the full tool-call sequence and the identifiers of every action taken. | A completeness check on the AI record fields, run at closure rather than at assessment. | This is the one that predicts how the evidence request will go. Anything materially below complete means the run behind at least one sampled incident will not reconstruct. |
| Corrective-action ageing | Actions raised from AI incidents that remain open across two consecutive review cycles, and actions closed on completion rather than on evidence of effectiveness. | Corrective action record: raised date, owner, close date, effectiveness evidence. | Actions ageing past two cycles read as a process that records problems rather than one that resolves them, which is precisely the finding the trending was meant to prevent. |
Each cut needs a defined consequence or it is decoration. Trend data should update the risk assessment and the AI system impact assessment for the systems concerned — ISO/IEC 42001 treats impact assessment as a process with documented results, not a one-time artefact, so a category recurring against a system is exactly the trigger to revisit it. It should change monitoring thresholds and guardrails, because the categories that recur tell you which detections are missing. It should feed competence and training where the pattern is human. And it should reach a management review with decisions recorded against named owners, which is what Clause 9.3 expects and what a certification auditor will read.
One question the tables above do not answer: whether to report an AI incident anywhere beyond regulators and customers. Public repositories exist and are increasingly used as sector reference data — the AI Incident Database and the OECD AI Incidents Monitor are the two most cited — and researchers, journalists and procurement teams read them. Most organisations do not publish, and that is a defensible position. What is not defensible is arriving at it by default. Make the decision deliberately, write the position into the communication plan alongside the regulatory and contractual paths, and name who holds it. One asymmetry is worth weighing while you decide: where an incident is already public, through a customer post or press coverage, the absence of your own record looks considerably worse than the record would have.
Where an incident reveals that something in the management system did not work as intended, the route out is the nonconformity and corrective action requirement in ISO/IEC 42001 Clause 10 — react, evaluate whether the same cause exists elsewhere, implement action, review effectiveness, retain the documented information. Two habits make that convincing rather than performative. Ask whether the same cause exists in systems other than the one that failed, and record the answer even when it is no. And close corrective actions on evidence of effectiveness rather than on completion of the task, because an action closed the week it was raised is one nobody has yet had the opportunity to verify.
The other frameworks land in the same place with different vocabulary, which is useful when you are answering questionnaires. NIST AI RMF 1.0 puts it under MANAGE 4.3: incidents and errors are communicated to relevant AI actors, including affected communities, and processes for tracking, responding to and recovering from incidents and errors are followed and documented. ISO/IEC 27001 control A.5.27 covers learning from incidents. The SOC 2 criteria CC7.4 and CC7.5 cover executing a defined incident response programme and recovering from incidents, with CC4.1 supplying the evaluation layer above them. None of these requires a separate AI process. All of them require that yours produces analysed output, not a list.
A practical closing note on cadence. Monthly is right for the operational cut while an AI estate is growing, quarterly for the governance pack, and immediately for anything that crosses a severity or statutory threshold. What breaks programmes is not the interval but the absence of a standing owner: trending performed by whoever has time produces a chart, and trending owned by the person accountable for the AI management system produces decisions. Where that ownership does not exist internally yet, it is the kind of gap a fractional CISO or DPO engagement is built to hold until it does.
The edge cases that generate the questions
The tables above cover the ordinary eighty per cent. These nine are where governance teams, engineering and legal genuinely disagree, and where settling the answer in advance is worth several days during the first real incident.
The hallucination that was caught
The most common argument inside a governance team, and it is usually resolved by asking a different question. A wrong output that a human caught is evidence that the control operated, and logging each one as an incident buries the register within a month. Log it as a quality signal and let volume do the work. Two things flip it into an incident: recurrence of the same failure mode, which is a systemic defect rather than an occurrence, and any finding that the human check is not actually being performed. The second is the serious one, because it means every other record where you claimed oversight is now in question.
It was the vendor incident, not yours
A provider outage, a silent model change, a security incident at a model or platform vendor. You did not cause it and you often cannot investigate it, but you still owe your own customers whatever your contracts and your communication plan commit to, and you still have to record what happened in your estate. Treat supplier events as incidents in your register with the supplier named, hold the vendor status page or notice as the evidence, and be explicit in the record about what you could not determine. Where the same vendor produces repeated events, that is supplier-review input and it belongs in the next review rather than in an email thread.
The record you need is itself a privacy problem
Full prompt and output capture is the best investigative evidence available and it is also a copy of whatever users typed, which may include personal or special-category data your notices never contemplated. The workable position is not to choose one side. Capture metadata, tool calls, identities and outcomes broadly and by default. Capture prompt and output content narrowly, with a stated retention period, restricted access, a documented lawful basis and redaction on the ingest path. Then say so in the record schema itself, so an assessor sees a deliberate decision rather than an omission. Under the DPDP Act or the GDPR this is a processing activity like any other, and it needs the same paperwork.
An incident caused by a tool nobody approved
Shadow AI produces incidents that fall between two desks: security calls it a policy violation, the AI governance function calls it out of scope because the system was never registered. Both answers let it escape. Classify it as an AI incident under governance failure, with the policy violation as a separate people-and-process track, and count it in AI trending. Excluding unapproved systems from AI incident data guarantees that your trending describes only the systems you already control, which is precisely the population least likely to surprise you.
Nothing happened at a timestamp
Regressions and fairness findings have no trigger event. There is no alert, no first report, no minute at which it began. Incident systems are built around a moment, so teams either force a false one or never open a record at all. Open it dated to detection, name the analysis or the evaluation run as the trigger artefact, and record the exposure window separately as a range with a stated confidence. The exposure window is what notification and remediation scope hang off, and pretending to know it precisely is worse than stating it as an estimate with the reasoning attached.
The agent exceeded its authority and nothing bad happened
An agent calls a tool it was not approved for, or writes to a system it holds read access on, and the outcome is harmless. Some teams close it as a non-event. That is the wrong reading: unauthorised action is the incident, and impact is the severity, not the existence test. The authority boundary is the control you are claiming works, so a breach of it with no harm is a free, fully evidenced test of a control that failed. These are the cheapest findings you will ever get and they should be the ones you write up most carefully.
Incident or defect?
Engineering teams reasonably want behaviour problems in the bug tracker where they can be fixed, and governance reasonably wants them visible. The line we use: a defect is a known deviation from intended behaviour being managed through the change process. An incident is a deviation that reached beyond the system boundary, exceeded an authority, or has an unknown cause. Many events are both, and the practical answer is one incident record for the governance trail and a linked engineering ticket for the fix. What does not work is closing the incident when the ticket is raised, because the fix and the corrective action have different acceptance tests.
A statutory clock that does not wait for your triage meeting
Start with the instruments, because the dates moved. The AI Act is Regulation (EU) 2024/1689, amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026. The Omnibus deferred application of the obligations for stand-alone high-risk systems under Annex III — employment, education, credit assessment, law enforcement, critical infrastructure and similar — from 2 August 2026 to 2 December 2027, and AI embedded in products already covered by Annex I product-safety law to 2 August 2028. That is scheduling relief rather than a reprieve, for one structural reason: Article 73 clocks run from awareness, and an intake design takes longer to build than the notice period allows. Where the Act reaches you as a provider of a high-risk AI system, Article 73 sets deadlines measured from awareness and not from classification: immediately once a causal link or its reasonable likelihood is established and in any event not later than fifteen days after becoming aware, not later than two days for a widespread infringement or a serious incident affecting critical infrastructure, and not later than ten days in the event of a death. Serious incident is defined at Article 3, point (49). One category is not deferred at all — a provider of a general-purpose AI model with systemic risk has owed a serious-incident duty under Article 55(1)(c) since 2 August 2025. The governance consequence is structural: your intake has to ask whether a statutory clock has started before your severity meeting sits, because a Wednesday triage cadence cannot serve a two-day obligation. Whether the Act applies to you at all, and in which role, is a separate scoping question, and most enterprise assistants are not high-risk systems.
Which agent record, when several were involved?
In an orchestrated system a planner delegates to sub-agents and the harm surfaces three hops down. Opening a record per agent fragments the story, while opening one per run loses the delegation chain. Anchor the record on the run that a human or a schedule initiated, then carry the delegation chain inside it as a field, with each sub-agent, the authority it held, and the calls it made. The correlation identifier that ties the whole chain together needs to exist in your telemetry before the incident, because reconstructing it afterwards from timestamps across four services is how a two-day investigation becomes a two-week one.
Two of these have their own pages, because the answers are longer than a paragraph. For the capability-boundary question, see tool approval and capability change. For the ability to stop an agent quickly and evidence that you can, see kill switches and circuit breakers. And where the incident originates in a tool nobody approved, the discovery side is covered in shadow AI governance. For the statutory-clock case, the full post-omnibus EU AI Act timeline and how each obligation lands against an AI management system is in ISO 42001 versus the EU AI Act.
What buyers push back on and the answer
These seven now appear in almost every enterprise security review of a vendor running AI in a customer-facing path. The difference between a good answer and a defensive one is specificity, and in most cases the specific answer is shorter.
“Your register shows four AI incidents in a year. That means you are not detecting them.”
A fair challenge and the right answer is not a bigger number. Show the threshold document that says what is logged as an incident and what is aggregated as a quality signal, then show the aggregate volumes underneath it — evaluation failures, near misses, denials at the tool gateway, user reports. Four incidents above a stated threshold, sitting on top of several hundred recorded signals below it, is a credible picture. Four incidents with nothing underneath is the one that should worry them, and it is worth naming that distinction yourself before they do.
“Send us your AI incident response plan.”
Usually they are testing whether AI events have a defined path, not asking for a separate document. The strongest answer is your existing incident procedure plus the AI annex: the classification criteria, the taxonomy, the extra record fields, the escalation path that brings in the AI system owner, and the communication plan. If you maintain a wholly separate plan, expect the follow-up about how the two interact at three in the morning. One process with an AI-aware intake almost always reviews better than two processes with a coordination problem between them.
“Will you notify us when the underlying model changes?”
Answer with the commitment you can actually hold, because this one turns into a contract clause. Most organisations cannot commit to notifying on every provider-side change, since providers do not always announce them at a useful granularity and some changes are not visible from outside. What you can commit to is notifying on changes you initiate that affect the service, on provider changes you become aware of that materially affect behaviour, and on any incident classified as a model-behaviour regression. Say which of those you are offering rather than agreeing to a general obligation you will breach quietly.
“Hallucinations are incidents. Why are they not in your register?”
Because a register that contains every wrong sentence stops being usable for exactly the purpose they care about. Explain the two-tier design: individual inaccuracies are aggregated as quality signals and trended. An inaccuracy becomes an incident when it reaches someone outside the review loop, when it recurs as a systemic failure mode, or when it could plausibly have been high-impact. Then show the trending, because the buyer question underneath this one is whether you would notice a pattern — and a threshold plus trend data answers that far better than a longer list.
“Who is on call for the agent at two in the morning?”
Answer with the same specificity you would for any production service: which conditions raise an alert, where it lands, who holds the rota, what response target you have committed to, and what the record shows for alerts that fired during the period. For agents there is a second half that buyers increasingly ask about and it is worth volunteering — what stops autonomously overnight without a human. A rate limit, a spend ceiling and a circuit breaker that suspends the agent on an anomaly are what make a two-person rota defensible instead of aspirational.
“What is your recovery time if you have to switch an agent off?”
Two distinct numbers and conflating them is the common mistake. Time to stop is how long from decision to the agent no longer acting, and for a well-designed system it should be seconds to minutes, tested rather than asserted. Time to restore service is how long until the business function resumes, which usually means a documented manual fallback and the people to run it. If the honest answer is that the manual process no longer exists because the agent absorbed it, say so and treat it as a resilience risk on the register rather than discovering it during the first suspension.
“Do your prompt logs contain our data, and who can read them?”
A legitimate question that deserves the schema rather than a reassurance. State what is captured by default — metadata, tool calls, identities, outcomes — what content capture applies to, the retention period for each tier, who holds access and under what approval, whether redaction runs on ingest, and where the logs are processed. If content capture is on for their tenant, tell them, because they will find out during their own incident and finding out then is far more expensive than being told now.
A closing observation about all seven. The buyer is not testing whether you have had incidents. They assume you have. They are testing whether you would know, whether you could tell them, and whether the answer would arrive in a form they can act on. A threshold document, a tagged register, a record schema and a trend chart answer all three questions at once, and they take a fortnight to build if you start before you need them.
The first fortnight, in order
Nothing on this page requires a platform purchase and none of it needs to wait for a certification decision. Two of these run long and are the reason to start them in parallel rather than in sequence — the telemetry check and the inventory check both depend on engineering time you do not control. Every row names the artefact it produces and how that artefact gets tested later, because a step that produces nothing an assessor can read is a step you will repeat.
| Day | Action | Owner | Artifact it produces | How it is evidenced later |
|---|---|---|---|---|
| Day 1–2 | Add the mandatory AI contribution field to the existing incident record type, with three options: no, contributed, primary cause. | Incident process owner | The field definition, plus a stored query that returns the AI population on demand. | The five-minute export an assessor asks for, with the filter, date range and record count visible. |
| Day 3–5 | Write the definition, the seven categories, the severity anchors and the three threshold questions into the incident procedure. Two paragraphs each, no more. | AI management system owner | A versioned, dated revision of the incident procedure with an AI annex. | The criteria document the assessor compares against how the records were actually tagged. |
| Day 3–5 | Agree what sits below the line and where it aggregates, so nobody decides at eleven at night whether a wrong summary is a ticket. | Incident process owner with the AI system owners | The threshold document, with the aggregation destination named for each signal type. | The aggregate volumes underneath a short register — the answer to the four-incidents challenge. |
| Day 5–10 | Confirm the run telemetry behind the record schema exists, and that its retention exceeds the reporting period plus the lag before anyone asks. | Platform engineering | A log-store inventory with retention written beside each store, and an export configured wherever retention falls short. | The run record behind one incident, end to end, produced for a month eleven months ago. |
| Day 5–10 | Check the AI system inventory is real and that every record can be joined to an assessed system by identifier. | AI management system owner | The inventory, with the identifier used in incident records as its primary key. | Reconciliation of the incident population against the inventory, differences explained. |
| Day 8–12 | Map every statutory and contractual notification clock that could apply, and put the clock question ahead of the severity question in intake. | Legal and privacy, with the incident process owner | The notification matrix, with the awareness trigger stated for each obligation. | A decision record for events assessed as not notifiable, which is the half most teams never keep. |
| Day 10–14 | Draft the incident communication plan against a real scenario from your own estate, then walk one past incident through it and see where it stalls. | AI management system owner with communications | The communication plan: what constitutes an AI incident, who is told, on what timeline, in what form, who decides. | A notification with its date mapped to the timeline the plan commits to — a plan no record demonstrates is a plan that gets tested in the audit. |
The first row is the one to ship this week whatever else slips. A mandatory classification field starts building a population from the day it lands, and every week it is deferred is a week of data that cannot be recovered afterwards. The inventory row is the one most often underestimated: a record that cannot be joined to an assessed system by identifier cannot be trended and cannot be reported, so the inventory is the substrate for everything else here — building it is covered in the AI system inventory and registry.
Draft the communication plan against a real scenario from your own estate rather than a template, then walk one past incident through it end to end and see where it stalls. That walkthrough finds more design faults in an afternoon than a review cycle finds in a month. On fees, ISO 42001 pricing is all-inclusive and indicative: from $4,000 (₹3–3.5 Lakh) for small organisations, $5,000–6,000 (₹4.5–5 Lakh) for growing companies and $8,000 (₹7–10 Lakh) for large enterprises. It includes the accredited certification body’s audit fee. The certificate is issued by that certification body, not by Tranquility Cybersecurity, and the final figure depends on the certification body you choose.
Frequently Asked Questions
What is the difference between an AI incident and a normal IT incident?
Do we need a separate AI incident register?
Should every hallucination be logged as an incident?
What does ISO 42001 require about AI incidents?
How does SOC 2 handle AI incidents?
What fields does an AI incident record need that a normal one does not?
When does the EU AI Act require us to report an AI incident?
Is a prompt-injection attack an AI incident or a security incident?
How long should we retain AI incident and tool-call logs?
Our incident register only has a handful of AI entries. Is that a problem?
Related Reading
Copilot Oversharing and Permission Hygiene
AI collapses the effort to discover information, so latent over-permissioning becomes exploitable.
Read moreConnectors and the Permission Inheritance Problem
Data access entitlement is not authorisation for an AI purpose. Assessing connectors proportionately.
Read moreHow Much Should an AI Agent Be Allowed to Spend?
Per-transaction ceilings are the easy part. Velocity and aggregate limits are what actually bind.
Read moreThe Ten Questions That Govern Any AI Agent
Scope, ownership, data, capability, identity, oversight, failure detection, evidence, reassessment and how to stop it.
Read moreISO 42001 Knowledge Hub
AIMS controls, EU AI Act mapping, risk assessment and guides.
Read moreISO 42001 (AI Management)
The world's first AI management system standard, for AI builders.
Read more