AI Incident Log and Tracking
Maintain a centralized, structured log of all AI incidents, near-misses, and governance concerns, accessible to the AI governance function.
Objective
Enable trend analysis, governance reporting, and regulatory audit responses by maintaining a complete and accessible AI incident record.
Maturity Levels
Initial
AI incidents are not centrally logged; records exist only in individual email threads or chat channels.
Developing
Incidents are logged in a shared document or ticketing system but without a consistent structure.
Defined
A defined incident log schema is consistently used; all incidents above a threshold are logged with key fields completed.
Managed
Incident trends are analyzed quarterly and reported to governance bodies; the log informs risk assessments.
Optimizing
The incident log feeds automated risk dashboards; log completeness is audited periodically.
Evidence Requirements
What an auditor or assessor would expect to see for this control.
- —Centralized incident log with all required fields populated for every recorded incident and near-miss
- —Near-miss reporting records demonstrating the logging process captures sub-threshold events, not just confirmed incidents
- —Governance committee reporting records showing the incident log is reviewed on a defined cadence
- —Log completeness audit records confirming all incidents above the reporting threshold are present in the log
- —Retention records confirming the incident log is maintained for the required period
Implementation Notes
Key steps
- Define the minimum fields for every incident record: date, system, incident type, severity, timeline of events, resolution, and post-incident review status.
- Log near-misses with the same rigor as incidents — they are your cheapest source of governance intelligence.
- Restrict write access to incident records after they are closed to preserve their integrity as audit evidence.
- Review the incident log as a standing agenda item at AI governance committee meetings.
Example Implementation
AI governance team maintaining a centralized incident register across five production AI systems
AI Incident Log Schema
Required fields for every incident entry:
| Field | Type | Description |
|---|---|---|
| incident_id | String | IRC-YYYY-NNNN format |
| system | String | AI system affected |
| incident_type | Enum | MODEL_FAILURE, DISCRIMINATORY_OUTPUT, DATA_EXPOSURE, ADVERSARIAL_ATTACK, AGENTIC_SCOPE_VIOLATION, HALLUCINATION_HARM, NEAR_MISS |
| severity | Enum | P1, P2, P3, P4 |
| detected_at | ISO-8601 | When incident was first detected |
| detected_by | String | Person/system that detected it |
| resolution_at | ISO-8601 | When incident was resolved |
| root_cause_summary | Text | Brief root cause (required for P1/P2) |
| pir_status | Enum | NOT_REQUIRED, SCHEDULED, COMPLETED |
| notification_required | Boolean | Whether regulatory/user notification was assessed |
| notification_status | Text | Outcome of notification assessment |
Quarterly trend report (standing AI Governance Committee agenda item):
- Incident count by type and severity
- Mean time to resolution by severity
- Open action items from post-incident reviews
- Near-miss analysis: were there precursors we should have caught earlier?
Control Details
- Control ID
- IRC-005
- Domain
- Incident Response
- Typical owner
- AI Governance Team
- Implementation effort
- Low effort
- Agent-relevant
- Yes