Appendix L: AI Incident Report Template

Preserve the System State Before It Disappears

An assistant exposes a confidential paragraph to the wrong user. The team disables the connector quickly and rebuilds its index from a corrected source. That stops the visible failure—and destroys the easiest path to understanding it. The provider alias has advanced, prompt logs were sampled, and the old index is gone. Investigators have the harmful output but cannot determine which other tenants were exposed or prove that the replacement index removed the fault.

An AI incident report is both a response record and a learning mechanism. It must preserve the socio-technical state of the event: data, model, prompt, retrieval, tools, policy, interface, people, decisions, and external conditions. The report should support containment and remedy without turning uncertainty into blame or a plausible story into a proven root cause.

Open the Record Early

Create the report when the incident is declared, not after the investigation. Mark facts, observations, hypotheses, and decisions separately. Preserve volatile state alongside containment: capture what can be captured safely, but never keep harm running merely to improve the investigation. Restrict sensitive evidence while retaining enough versioned context to reproduce the event where safe. Follow the organization’s notification, legal-hold, privacy, labor, security, and sector-specific procedures; this template does not determine legal obligations.

Use a blameless analysis without erasing accountability. Ask why the system and organization allowed the outcome: which assumptions, interfaces, incentives, workload, controls, or change processes contributed? “The model hallucinated” describes behavior, not a root cause or prevention strategy.

AI Incident Report

INCIDENT IDENTITY
Incident ID and title:
Status: investigating / contained / monitoring / closed
Severity and rationale:
Date/time detected and detection source:
Estimated start and end time:
Incident commander:
Technical, product, risk, communications, and domain leads:
Evidence custodian and access classification:

SYSTEM AND VERSION SNAPSHOT
System and deployment environment:
Model provider, model ID, and immutable version if available:
Prompt, policy, guardrail, and orchestration versions:
Retrieval corpus / index and source-document versions:
Data and feature-pipeline versions:
Tools, permissions, identities, and external dependencies:
Application, interface, and workflow versions:
Recent changes and releases:

SUMMARY
What happened:
How it was detected:
Current state and containment:
What remains unknown:
Decision or help requested:

IMPACT
Users and affected people:
Observed harm or service effect:
Potential but unconfirmed impact:
Data, confidentiality, integrity, availability, safety, rights, or financial impact:
Scale, duration, regions, languages, and segments:
Whether impact is continuing or recoverable:
Correction, appeal, support, or remedy offered:

TIMELINE (repeat in one time zone)
Timestamp:
Observation, action, or decision:
Source / evidence link:
Owner:
Known at the time:

EVIDENCE PRESERVATION
[ ] User input / prompt and conversation context
[ ] Generated output and post-processing
[ ] Retrieved documents, ranks, and access decisions
[ ] Tool requests, approvals, results, and side effects
[ ] Model, prompt, policy, data, index, and code versions
[ ] Identity, permission, configuration, and deployment records
[ ] Service, quality, safety, security, and cost telemetry
[ ] Human review, escalation, support, and appeal records
[ ] Provider or supplier notices and external conditions
Integrity / chain-of-custody method:
Redaction, minimization, access, retention, and deletion controls:
Missing evidence and consequence:

CONTAINMENT AND RECOVERY
Immediate actions and times:
Traffic limit, feature disable, permission revocation, or isolation:
Fallback or rollback used:
Evidence that ongoing harm stopped:
New risk, evidence loss, or user impact created by containment:
Temporary controls and their expiry:
Recovery criteria and owner:

CAUSAL ANALYSIS
Observed failure mechanism:
Contributing data conditions:
Model or adaptation conditions:
Prompt, retrieval, tool, policy, interface, or workflow conditions:
Human workload, training, incentive, or escalation conditions:
Monitoring, testing, review, or change-management gaps:
Supplier or external-change conditions:
Assumptions disproved:
Alternative hypotheses considered and evidence:
Root or systemic causes supported by evidence:
Claims the evidence does not support:

COMMUNICATION AND NOTIFICATION
Internal stakeholders informed:
Users or affected people informed:
Correction and remedy instructions:
Contractual, insurer, supplier, or authority review route:
Notification decision owner, basis, and time:
Approved message and update cadence:

REMEDIATION ACTION (repeat)
Action and control type: preventive / detective / corrective
Failure or cause addressed:
Owner and due date:
Priority and dependency:
Verification method:
Regression test ID:
Deployment / change record:
Status and completion evidence:

VALIDATION AND CLOSURE
Reproduction result:
Fix evaluation and adverse-side-effect checks:
Regression suite result:
Production verification window and signals:
Residual risk and accepting owner:
Documentation, training, and playbooks updated:
Similar systems or populations reviewed:
Closure decision and approvers:
Follow-up audit date:

LEARNING REVIEW
What helped detection or containment:
What delayed or obscured response:
Which assumption or control failed:
What should become a design standard or reusable test:
How learning is shared without exposing protected evidence:

Set Severity From Impact and Urgency

Severity should reflect observed or credible harm, affected scale, sensitivity, reversibility, ongoing exposure, and containment urgency—not whether the failure looks novel. A single cross-tenant disclosure may outrank thousands of harmless malformed outputs. Reassess severity as evidence changes, and preserve the earlier decisions with their known-at-the-time rationale.

Closure is a governance decision, not the moment service returns. Temporary containment may justify restoration while remediation remains open, but the record must show who accepted that state, which monitoring protects it, when the temporary control expires, and what evidence is required for final closure.

Follow One Incident Through the Record

At 09:12, a customer administrator reports another tenant’s policy title in a citation. The responder saves the conversation and request identifier, blocks new queries to the affected connector, and snapshots the deployed configuration and index manifest before any rebuild. The report records that the connector is isolated at 09:19; it does not yet say that exposure has ended, because cached answers and prior requests remain unexamined.

The timeline then separates what the team knows from what it suspects. The offending chunk has an empty tenant field. A recent ingestion job writes tenant metadata after chunk indexing. The authorization layer treats an empty field as shared. Those observations support a failure mechanism, but they do not establish the incident’s full reach. A query over retained access decisions finds three other cross-tenant retrievals; support contacts those customers through the approved notification route. A gap in sampled prompt logs remains explicit, so the report gives a bounded confirmed impact and a larger period of unresolved potential exposure.

The model made the disclosure visible, but changing the model would not repair the path. The approved remediation makes missing ownership metadata deny by default, validates ownership before an index can publish, seeds a cross-tenant canary, and checks sibling connectors built by the same job. The team restores the connector only after replaying the preserved request against the candidate index, passing the canary, and watching permission-denial and empty-metadata signals through the stated verification window. The regression case links back to this incident; the remaining evidence gap has its own accepting owner and follow-up date.

Rehearse the First Hour Before You Need It

Give the response team the first report: one harmful output, an advancing provider alias, a mutable retrieval index, sampled logs, and a credible reason to restore service quickly. At each proposed action, ask what state it changes, what evidence it could erase, what continuing harm it stops, and who has authority to take it. Make the team record one observation, one hypothesis, and one decision with the information available at that time. If all three read as the same claim, the record will manufacture certainty during a real incident.

Then remove a dependency. Let the index snapshot fail, make the vendor version unavailable, or discover that the incident commander cannot access protected logs. The team should still be able to isolate the risky path, preserve the evidence it can reach, bound what remains unknown, route notifications for a decision, and name the conditions for safe recovery. Finish by tracing one corrective action into a regression test, a monitored production signal, an owner, and an expiry or follow-up date. A report is useful when another responder can reconstruct not only what happened, but why each consequential decision was reasonable—or mistaken—given what was known then.

Pair this report with Incident Response for AI Systems, the AI Monitoring Plan, and the AI Threat Model Worksheet.