Keeping an AI incident register: what to record

Why keep one

Security teams have kept incident logs for decades. Most do not have a place for the incidents that AI use produces, because many of them are not security incidents in the usual sense. Nobody broke in. An employee used a tool as it was designed to be used, with data that should not have gone into it. A chatbot answered a customer confidently and wrongly. A model's output was biased in a way nobody tested for.

Three audiences will ask what you recorded.

Customers. "Have you had an AI-related incident in the past twelve months, and how was it handled?" is now a standard questionnaire item. "None that we know of" from a company with no register is a different answer from "none recorded" from a company with one.

Auditors and standards. The NIST AI Risk Management Framework expects incidents and errors to be tracked, responded to and communicated under its MANAGE function. ISO/IEC 42001 expects an AI management system to handle nonconformities and corrective action. Neither can be evidenced without a record.

Regulators. Under the GDPR, Article 33(5) requires a controller to document personal data breaches, including the facts, the effects and the remedial action, whether or not the breach had to be reported. The EU AI Act sets out duties around serious incidents involving high-risk AI systems. In both cases the first thing asked for is the record.

There is a fourth audience: you, next year. Incidents repeat. A register is how you notice.

What counts as an AI incident

Define it broadly. An AI incident is any event in which the use of an AI system caused, or could have caused, harm to a person, a customer, the organization or its data. In practice they fall into a few categories:

• Data exposure. Confidential or personal data entered into a tool that was not approved for it.
• Wrong or harmful output. A hallucinated fact sent to a customer; advice that was unsafe; content that infringed someone's rights.
• Policy violation. Use of a prohibited tool; an approved tool used outside its approved purpose.
• Bias or fairness. Output or a decision that treated people differently in a way that cannot be justified.
• Security. Prompt injection, a leaked API key, a compromised AI vendor.
• Availability. A process that depends on an AI system failed when the system did.

Near misses

Record the ones that did not hurt. An employee about to upload a customer list is stopped by a warning. A reviewer catches an invented citation before the document goes out. Nothing happened, and that is exactly why near misses are valuable: they show where the next real incident will come from, at no cost.

Organizations that record only harm have a register with three entries and no patterns. Mark near misses as such and keep them in the same place.

The ten things to record

A record does not need to be long. It needs to answer the questions someone will ask later.

1. 01What happened. A plain title and a few sentences. Write it so a person outside the team understands it.
2. 02When it occurred and when it was detected. Two different times. The gap between them is one of the most telling numbers in the register.
3. 03How it was found. Reported by an employee, flagged by monitoring, raised by a customer, announced by the vendor, found in a review. If nearly everything is found by customers, your detection needs work.
4. 04Category. From a short fixed list like the one above, so that you can count.
5. 05Severity. Four levels are enough: low, medium, high, critical. Write down what each means in your organization before you need to use them.
6. 06The AI systems involved. Linked to your inventory, so an incident shows up on the record of the system it concerns.
7. 07Who and what was affected. How many people, which customers, what kind of data. Estimates are fine if they are marked as estimates.
8. 08Actions. Two kinds, kept apart. Containment stops it getting worse: delete the conversation, revoke the key, block the tool. Corrective stops it happening again: change the policy, train the team, approve a proper alternative. Each has an assignee and a due date.
9. 09Notification decisions. See the next section.
10. 10How it ended. A closing note: what was done, what was learned, what changed.

The timeline is the evidence

Beside the fields, keep a timeline: every change of status, every action completed, who did it and when. Make it append-only. Entries are added and never edited or removed.

This matters more than it seems. When a customer or a regulator reviews an incident, they are reconstructing a sequence: when did you know, what did you do, how long did it take. A record that could have been tidied afterwards cannot answer that. A timeline that only grows can.

A simple workflow is enough: open, contained, resolved, closed. Allow steps to be skipped forwards, because a near miss is often resolved the moment it is recorded. Allow an incident to be reopened, and record that it was.

Notification: record that you asked

Whether an incident must be reported outside the company is a legal question that depends on the facts. A register cannot answer it. What a register can do is make sure the question was asked every time, and keep the answer.

For each incident, work through a short list and record, for each line, whether it applies, and why:

• The data protection authority. A personal data breach is notified within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people's rights and freedoms (GDPR, Article 33).
• The people affected. Told without undue delay where the risk to them is high (Article 34). United States state breach laws have their own triggers.
• Customers. Contracts and data processing agreements often require notice of an incident involving the customer's data, sometimes within a fixed number of hours. Check the contract, not your memory of it.
• The AI vendor. They may need to act: revoke a key, delete data, fix a fault.
• Serious incidents under the EU AI Act. These duties concern high-risk AI systems. If you deploy one, find out now what you would have to report and to whom.
• Your insurer. Most cyber policies require prompt notice of anything that may lead to a claim.

"Considered, does not apply, because no personal data was involved" is a perfectly good entry. An empty line is not. Take advice where you are unsure. This list is a prompt, not a legal opinion.

Closing, and looking back

Do not let an incident be closed without a closing note. An incident with no account of how it ended has not been closed. It has been forgotten.

Then, once a quarter, read the register as a whole. Look for the same tool appearing repeatedly, the same team, the same kind of data. Look at the time between occurrence and detection, and at corrective actions that are overdue. Three near misses with one unapproved tool is not three incidents. It is one decision you have not made yet: approve a proper alternative, or block it.

Share the summary with whoever owns your AI policy. A register that changes the policy is doing its job.

What to leave out

A register should hold enough to understand and evidence an incident, and no more. Do not paste the exposed data into it. Do not record more about the individuals involved than is needed to act. Keep it readable by the people who need it and not by everyone, and decide how long entries are kept.

How GhostAudit helps

The incident register in GhostAudit holds the fields described here, with the open, contained, resolved and closed workflow, an append-only timeline, containment and corrective actions, and a notification checklist. It will not close an incident without a closing note, and it generates an incident report from the record for review and approval.