Skip to main content

​
Incidents

The Incidents workspace records AI-related incidents and the governance response throughout the AI system lifecycle.

​
When to use it

Use Incidents when an event affecting an AI system requires recording, triage, containment, investigation, remediation, recovery, resumption, or governance follow-up. An incident may also trigger risk reassessment, control action, change management, assurance, validation, enhanced monitoring, or related governance decisions.

​
What to enter

​
Incident definition

Record the core incident information:
  • Incident Title — concise name for the incident.
  • Incident Type — the type of event, such as model performance, data quality, privacy, security, safety, human oversight, governance, control failure, or operational.
  • Status — current incident lifecycle state.
  • Severity — current severity from informational through critical.
  • Performed by — the person who performed the governance action, when recorded.
  • Description — factual description of the incident.
  • Severity Rationale — reasoning supporting the selected severity.
  • Expected Condition — what should have occurred.
  • Actual Condition — what occurred.
Incident Title, Description, and Detected At are required.

​
Detection

Record:
  • Detected At — date and time the incident was detected.
  • Detection Source — how the incident was identified.
  • Source Description — additional detection context.
  • Initial Observation — the initial observed condition.

​
Immediate Risk

Record the immediate governance concern, including:
  • Risk Level
  • Potential Harms
  • Risk Description
  • Risk Rationale
Use this section to capture the immediate risk context before the full investigation is complete.

​
Incident lifecycle

After an incident has been created, Studio provides additional response and follow-up sections:
  • Containment — whether containment is required, its status, actions, owner, and completion.
  • Investigation — investigation status, objective, findings, and owner.
  • Root Cause — root-cause status, findings, and owner.
  • Impact Assessment — assessment status, findings, and owner.
  • Risk Reassessment — updated risk findings and responsible owner.
  • Notifications — notification status, whether notification is required, recipients, date, and notes.
  • Corrective Actions — corrective action, owner, status, target date, and notes.
  • Remediation — remediation status, plan, owner, target date, and notes.
  • Retesting — retesting status, owner, result, date, and notes.
  • Recovery — recovery status, owner, actions, date, and notes.
  • Enhanced Monitoring — monitoring status, owner, plan, duration, and notes.
  • Resumption — resumption status, approver, date, conditions, and notes.
Complete the sections that apply to the incident. The lifecycle should reflect the organization’s incident response and governance process. Use the Related Records section to connect the incident to other governance records:
  • Risk IDs
  • Control IDs
  • Evidence IDs
  • Change IDs
  • Assurance IDs
  • Related Incident IDs
These relationships provide traceability between the incident and the governance actions or records created in response.

​
Incident History

The Incident History section lists recorded incidents and provides:
  • View Details to inspect the recorded incident and response information.
  • Edit Details to update the incident record.
  • Delete to remove an incident record when appropriate under the organization’s record-management process.
The details view provides a consolidated record of the incident, including its status, type, severity, actor attribution, detection, conditions, immediate risk, lifecycle response, and related records.

​
What the result means

An incident record provides a traceable governance history of the event, response, investigation, findings, decisions, corrective actions, recovery, and follow-up. Incident records may result in changes to risks, controls, AI system configuration, governance decisions, validation, assurance, monitoring, or reassessment. Recording an incident does not itself establish legal reporting, compliance, certification, accreditation, or conformity assessment. Any external reporting obligations must be handled through the organization’s applicable processes.

​
What comes next

Complete the response and corrective actions applicable to the incident. Where the incident is governance-significant, use the related governance workspaces to address resulting risks, controls, changes, evidence, assurance, validation, monitoring, or reassessment needs.

​
Framework reference

Follow the applicable AIGO Framework guidance for incident management, risk management, change management, evidence, assurance, monitoring, reassessment, and continuous improvement.