What Should an AI Incident Report Include? A Complete Checklist for Teams

An AI incident report should let an independent reader reconstruct what happened, identify the AI system’s role, understand who or what was affected, assess the evidence, see how the team contained the problem, and verify how recurrence will be prevented. Record facts with timestamps, separate confirmed harm from potential harm, preserve supporting evidence under appropriate access controls, and assign owners and deadlines to every follow-up action.

This checklist is an internal reporting aid, not a substitute for a country’s legal, regulatory, safety, privacy, security or contractual notification rules. The OECD’s 2025 common framework is designed to complement—not replace—national reporting systems.

#	Preview	Product	Price
1		Blue Team Handbook: Incident Response, 3rd Edition: A condensed field guide for the Cyber Security...	$39.00	Buy on Amazon
2		Threat Intelligence & Incident Response Handbook: Detect, Investigate, and Contain Cyber Attacks...	$24.99	Buy on Amazon
3		Blue Team Handbook: Incident Response	$65.99	Buy on Amazon
4		Incident Response Handbook: Preparing IR Policies | Tabletop Exercises & Drills | Lessons Learned...	$20.99	Buy on Amazon
5		Incident Response Handbook: A Practical Guide for Operations and Security Professionals	$19.99	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

Start by defining what you are recording

Use precise status labels. An incident is an event, circumstance or series of events in which developing, deploying, using or malfunctioning an AI system directly or indirectly results in specified actual harm. A hazard is a plausible path to that harm before it materializes. A near miss belongs in the record even when no injury, loss or rights violation has been confirmed.

Potential harm can include injury or health effects, disruption to critical infrastructure, violations of fundamental, labour or intellectual-property protections, and damage to property, communities or the environment. Mark each harm as actual, suspected or potential. Do not turn an unverified causal theory into a fact.

#1 Best Overall

Sale

Blue Team Handbook: Incident Response, 3rd Edition: A condensed field guide for the Cyber Security Incident Responder.

$39.00

Buy on Amazon

Choose one current status and retain the history when it changes:

• Hazard or near miss
• Incident under investigation
• Confirmed incident
• Contained or recovering
• Closed, with follow-up monitoring still required where applicable

The OECD terminology is intended to support comparison across contexts while leaving room for domestic rules. Your organization should therefore preserve its own records even when it also submits information to an external register.

1. Give the report a stable identity

The first block should identify the record, not attempt to explain the whole event. Include:

• A unique internal reference number
• A short, neutral title that names the affected function rather than assigning blame
• The date and time the report was first created, with time zone
• The reporter’s role, team and contact route
• The current status
• Version number, revision date and a change history

Keep the original version and record who changed each material field. A stable reference allows incident, security, privacy, legal and operational records to be joined without copying sensitive content into every system.

2. Build a time-stamped event timeline

Use one time zone consistently and identify the source of each time. The timeline should show both the event and the response:

• When the relevant input, model behavior or action began
• When the issue was first detected and by whom or what alert
• When the system was paused, restricted, rolled back or placed under heightened monitoring
• When affected users, workers, customers, vendors, executives or authorities were notified
• Key decisions, approvals and handoffs
• When service or functionality was restored
• What remains unknown and the next time at which it will be reviewed

Do not fill a missing time with an estimate disguised as a precise value. Write “approximately” or “unknown,” explain the basis, and update the entry when logs or witness accounts establish a better time.

3. Describe the AI system and its relationship to the event

System identity

Record the product or service name, model and provider, model or deployment version, relevant configuration changes, and the affected component or downstream workflow. If a provider version is unknown, say so and identify where that information is being sought.

Rank #2

Threat Intelligence & Incident Response Handbook: Detect, Investigate, and Contain Cyber Attacks Using Modern SOC Analysis, Threat Hunting, and Security Monitoring Techniques

$24.99

Buy on Amazon

Intended and actual use

State the intended task, the actual task at the time, the level of autonomy, and the human-oversight arrangement. Note whether people could review, override or appeal the output before it affected someone. Record whether the system was modified, connected to an unexpected tool or operating outside its documented conditions.

Evidence-based role assessment

Classify the system’s role as directly causing harm, contributing to it, or merely being present during the event. Explain the evidence for that assessment and its confidence. The report should not assume that the presence of an AI component proves causation; another process, person, vendor or environmental condition may have been decisive.

4. Capture deployment context and exposure

Context determines both severity and reporting obligations. Record:

• The organization, business unit and operational setting
• Sector and country or region
• Intended users and affected stakeholders
• Scale of exposure, such as number of decisions, users, records or facilities, when supportable
• Whether critical services, vulnerable groups or protected rights were involved
• Whether the event crossed organizational or vendor boundaries

If the scale is not yet known, write “unknown” rather than zero. A zero means the team has evidence that no exposure occurred; an unknown means the investigation is incomplete.

5. Record inputs, model, task and outputs

This section lets another investigator reproduce the relevant path without putting unrestricted sensitive data into the report. Include:

• Input or data source and the relevant time window
• Model type, version and material changes
• The task or instruction supplied to the system
• The output, recommendation or external action generated
• Confidence, uncertainty or abstention information shown to the operator, if any
• Relevant prompts, configuration, retrieval results, tool calls and downstream transformations

Preserve original logs, prompts and output snapshots in an access-controlled evidence store. In the general report, link to the evidence location and describe the access restrictions instead of reproducing personal data, secrets, security-sensitive content or protected intellectual property.

6. Separate harm, severity and duration

Harm categories

List actual, suspected and potential harms separately. For each, identify the affected people, groups, assets, services or environment; the type of harm; when it began; how long it lasted; and whether it is reversible. Include economic loss, operational interruption, privacy or security impact, physical or psychological injury, discrimination or other rights concerns where relevant.

Rank #3

Blue Team Handbook: Incident Response

$65.99

Buy on Amazon

Severity and scope

Use the organization’s established severity scale if one exists, and define the level in the report. Quantify affected records, decisions, users, sites, downtime or financial impact only when the number is supported. Record uncertainty and the method used to estimate it. Note explicitly if critical infrastructure or protected rights may be implicated.

Potential harm in a near miss

For a near miss, describe the credible outcome that was avoided, the barrier that prevented it, and whether that barrier was deliberate, accidental or temporary. Do not report a prevented outcome as actual harm.

7. Preserve evidence and state confidence

List each material source and its time range: application and model logs, output captures, alerts, tickets, access records, customer or worker submissions, witness accounts and relevant policy or configuration versions. Record who collected it, when, where it is stored and who has accessed it when chain of custody matters.

Label statements as one of the following:

• Observed fact: directly supported by a retained record
• Third-party account: reported by a user, vendor or witness and not yet independently confirmed
• Hypothesis: a plausible explanation under investigation
• Confirmed conclusion: supported by the completed investigation

Apply privacy, security, legal-hold and intellectual-property controls to both the report and its attachments. The public or broadly shared version may need de-identification, while the restricted evidence set retains the detail needed for accountability.

8. Document containment, support and recovery

For every response action, record the owner, approval where required, start time, end time and verification evidence. Cover:

• Immediate steps that protected people, services, data or property
• Whether the system or feature was paused, rolled back, rate-limited, isolated or restricted to supervised use
• Manual review or compensating controls applied during the investigation
• Support offered to affected customers, workers or users
• Restoration steps and tests showing that service was safe to resume
• Residual risk and monitoring requirements after recovery

A statement such as “fixed” is not enough. Identify the check that demonstrated containment and the condition that would trigger renewed escalation.

9. Investigate causes without assigning them prematurely

Record known and suspected contributing factors across technical, data, process, human, vendor and organizational categories. Possible areas include data drift, an untested model or prompt change, an integration failure, inadequate human review, unclear ownership, a supplier change, a training gap or deployment outside intended conditions.

Rank #4

Incident Response Handbook: Preparing IR Policies | Tabletop Exercises & Drills | Lessons Learned from Cybersecurity Incident Response | Cybersecurity Playbooks for IT and Security Teams

$20.99

Buy on Amazon

State the investigation method—for example, log correlation, replay, sampling, interviews or control testing—along with confidence, conflicting evidence and unresolved questions. “Root cause” should be reserved for a conclusion supported by the investigation; early reports should use “suspected contributor” when the evidence is incomplete.

10. Track notifications and obligations

List internal escalation paths, affected-party communications, provider or vendor contacts, and any regulator or authority contact. For each item, record the reporting channel, deadline, responsible person, date sent and confirmation received.

Whether an external notification is required depends on the specific country, sector, system, contract and event. Verify the applicable rule rather than relying on a generic AI threshold. The OECD common framework is complementary guidance, not a universal legal filing form.

11. Turn findings into corrective and preventive actions

Each action should have:

• A precise change, not a broad intention
• An accountable owner
• A due date and priority
• Verification evidence, such as a test result, audit record or monitoring metric
• Expected residual risk
• Criteria for closure

Actions may involve model or data changes, evaluation and red-team testing, monitoring and alert thresholds, access controls, human-approval gates, vendor management, documentation, training, governance or deployment architecture. Link every action to the contributing factor it addresses and do not close the report merely because the immediate symptom disappeared.

12. Capture learning and decide what can be shared

Record lessons that apply to similar systems, products or locations. Decide whether a de-identified summary can be shared internally, with a provider, with affected parties or publicly. Identify required approvals and restrictions before disclosure, especially where privacy, security, legal privilege or intellectual property is involved.

Set a review date. New evidence, repeated near misses or a change in law or system design may require the severity, cause assessment or disclosure decision to be updated.

A practical report layout

How to choose or align a reporting framework

When comparing an internal form with an external framework, assess eight dimensions:

Best Value

Incident Response Handbook: A Practical Guide for Operations and Security Professionals

$19.99

Buy on Amazon

1. Jurisdiction and sector fit
2. Definitions of incident, hazard and near miss
3. Required versus optional fields
4. Treatment of harm, severity and affected stakeholders
5. Technical detail about data, model, task and output
6. Privacy, security and intellectual-property controls
7. Escalation, submission channels and deadlines
8. Comparability across systems, teams and locations

The OECD’s 2025 common reporting framework selected 29 criteria: seven mandatory within that proposed framework and 22 optional. During development, 88 candidate criteria were grouped into eight dimensions: incident metadata; harm details; people and planet; economic context; data and input; AI model; task and output; and other incident information. These are framework counts, not measurements of how often incidents occur or how severe they are.

NIST’s AI Risk Management Framework Playbook offers voluntary prompts under Govern, Map, Measure and Manage. NIST expressly cautions that the Playbook is neither a checklist nor a set of steps that must be followed in full. Use it to improve risk-management questions, while keeping your incident record focused on the event and its evidence.

A repeatable workflow for teams

1. Open the record immediately. Assign the reference, status, owner and time zone; preserve volatile logs and outputs.
2. Protect people and services first. Apply containment and document each action while the event is active.
3. Establish the factual spine. Build the timeline, identify the system and separate observed facts from accounts and hypotheses.
4. Assess impact. Classify actual, suspected and potential harm; quantify only supported scope and mark unknowns.
5. Check obligations. Involve legal, privacy, security, safety and contractual owners for the relevant jurisdiction and sector.
6. Investigate and correct. Test contributing factors, assign preventive actions and define verification.
7. Review and disclose appropriately. Approve any de-identified sharing, update the assessment when facts change and close only when criteria are met.

Common reporting failures to avoid

• Calling every anomaly an incident without stating whether harm occurred or was only possible
• Using “AI error” as a cause without identifying the model behavior, human decision or process failure involved
• Recording a single severity score while omitting duration, affected groups or critical-service impact
• Copying sensitive prompts, personal data or secrets into an unrestricted ticket
• Overwriting the original account instead of keeping versions and change history
• Reporting “zero affected” when the investigation has not yet established the scope
• Closing the ticket after rollback without testing recovery or addressing the contributing control failure
• Assuming that an internal record alone satisfies a regulator, contract or safety authority

Frequently Asked Questions

Should a near miss receive an AI incident report?

Yes. Record it as a hazard or near miss, describe the credible potential harm, explain which barrier prevented it, and keep the causal assessment appropriately uncertain.

Does every AI incident have to be reported to a regulator?

Not necessarily. Notification depends on the country, sector, system, contract and facts of the event. Check the applicable rule and deadline with the responsible legal, privacy, safety or regulatory team.

How should sensitive prompts and personal data be handled?

Keep them in an access-controlled evidence store, record their location and collection details in the report, and share only the minimum de-identified material needed for each audience.

When can an AI incident report be closed?

Close it only after containment and recovery are verified, required notifications are addressed, corrective actions have owners and due dates, residual risk is accepted, and the stated closure criteria are met.

Quick Recap

SaleBestseller No. 1

Blue Team Handbook: Incident Response, 3rd Edition: A condensed field guide for the Cyber Security Incident Responder.

$39.00

Bestseller No. 2

Threat Intelligence & Incident Response Handbook: Detect, Investigate, and Contain Cyber Attacks Using Modern SOC Analysis, Threat Hunting, and Security Monitoring Techniques

$24.99

Bestseller No. 3

Blue Team Handbook: Incident Response

$65.99

Bestseller No. 4

Incident Response Handbook: Preparing IR Policies | Tabletop Exercises & Drills | Lessons Learned from Cybersecurity Incident Response | Cybersecurity Playbooks for IT and Security Teams

$20.99

Bestseller No. 5

Incident Response Handbook: A Practical Guide for Operations and Security Professionals

$19.99

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

AI governanceAI risk managementArtificial Intelligencecomplianceincident responseNIST AI RMFOECD