Skip to main content

AIGO — AI Governance Operating Framework

AI Incident Template

Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-TPL-010 Document Type: AI Incident Template Template Purpose: Controlled Identification, Response, Investigation, Remediation, Closure, and Improvement of AI Incidents

1. Template Purpose

This template provides the controlled structure for identifying, recording, assessing, containing, investigating, resolving, closing, and learning from an AI-related incident under the AIGO AI Governance Operating Framework. An AI incident may involve:
  • harmful or unexpected AI behavior;
  • material performance failure;
  • fairness or discrimination concerns;
  • privacy events;
  • security events;
  • safety events;
  • unauthorized AI operation;
  • control failures;
  • material monitoring breaches;
  • uncontrolled changes;
  • supplier failures;
  • inappropriate AI use;
  • material stakeholder impact.
The incident record should establish traceability between:
  • AI system;
  • lifecycle stage;
  • incident;
  • risk;
  • control;
  • monitoring alert;
  • evidence;
  • containment;
  • investigation;
  • root cause;
  • corrective action;
  • residual risk;
  • recovery;
  • governance decision;
  • lessons learned.
This template does not replace the organization’s approved AIGO AI Incident Management Procedure.

2. Incident Management Instructions

Complete all applicable sections. Where information is not yet available, record: Pending — [reason] Where a field does not apply, record: Not Applicable — [reason] Do not delete material incident information merely because it is later determined to be incorrect. Corrections should remain attributable and traceable. Use controlled identifiers wherever possible. Recommended identifiers include:
  • AI System ID;
  • Incident ID;
  • Alert ID;
  • Risk ID;
  • Control ID;
  • Evidence ID;
  • Investigation ID;
  • Corrective Action ID;
  • Change ID;
  • Assurance ID;
  • Approval ID;
  • Closure ID.

3. Incident Record

3.1 Identification

Incident ID: AI System ID: Incident Version: Incident Title: Incident Type: Incident Status:
  • Detected
  • Reported
  • Registered
  • Under Triage
  • Contained
  • Under Investigation
  • Remediation
  • Recovery
  • Awaiting Closure
  • Closed
  • Reopened
Incident Owner: Incident Manager: System Owner: Risk Owner: Date / Time Detected: Date / Time Reported: Date / Time Registered: Last Updated:

4. Incident Classification

4.1 Incident Category

Select applicable categories:
  • Model Performance
  • Data Quality
  • Data Drift
  • Model Drift
  • Fairness / Discrimination
  • Privacy
  • Security
  • Safety
  • Reliability
  • Human Oversight
  • Transparency
  • Explainability
  • Unauthorized Use
  • Unauthorized Change
  • Governance
  • Control Failure
  • Third-Party / Supplier
  • Regulatory / Compliance
  • Operational
  • Other
Applicable Category / Categories:

4.2 Initial Severity

Initial Severity:
  • Informational
  • Low
  • Medium
  • High
  • Critical
Severity Rationale:

4.3 Severity Assessment

Consider:
  • potential harm;
  • actual harm;
  • number of affected persons;
  • duration;
  • scope;
  • reversibility;
  • likelihood of recurrence;
  • legal significance;
  • regulatory significance;
  • security significance;
  • privacy significance;
  • safety significance;
  • reputational impact.
Severity Assessment:

5. Detection

5.1 Detection Source

Detected By:
  • Automated Monitoring
  • User Report
  • Employee Report
  • Customer Report
  • Supplier Notification
  • Assurance
  • Audit
  • Risk Review
  • Control Assessment
  • Security Monitoring
  • Privacy Monitoring
  • Other
Detection Source:

5.2 Detection Reference

Alert ID / Source Reference:

5.3 Initial Observation

What was observed?

5.4 Detection Evidence

Evidence IDs:

6. Incident Description

6.1 Incident Summary

Describe what happened:

6.2 Expected Condition

What should have happened?

6.3 Actual Condition

What actually happened?

6.4 Difference

Describe the material difference between expected and actual behavior:

7. AI System Context

7.1 System Information

AI System Name: System Version: Model ID / Version: Business Owner: AI System Owner: Technical Owner: Current Lifecycle Stage: AIGO Classification:

7.2 Intended Purpose

Approved Intended Purpose:

7.3 Intended Use

Approved Intended Use:

7.4 Restricted / Prohibited Use

Relevant Restrictions:

8. Affected Stakeholders and Persons

8.1 Stakeholders

8.2 Affected Persons

Potentially / Actually Affected Persons:

8.3 Affected Groups

Affected Groups:

8.4 Estimated Scale

Estimated Number of Affected Persons / Records / Transactions: Scale Confidence:
  • Confirmed
  • Estimated
  • Unknown
  • Under Investigation

9. Incident Timeline

9.1 Timeline Summary

Summary:

10. Immediate Risk Assessment

10.1 Immediate Risk

Immediate Risk Description:

10.2 Potential Harm

Potential harm may include:
  • physical;
  • financial;
  • psychological;
  • privacy;
  • security;
  • discrimination;
  • employment;
  • legal;
  • operational;
  • safety;
  • reputational;
  • societal.
Potential Harm:

10.3 Immediate Risk Level

Risk Level:
  • Low
  • Medium
  • High
  • Critical
Rationale:

11. Containment

11.1 Containment Objective

Objective:

11.2 Immediate Containment Actions

11.3 System Restriction

System Restricted: Restricted Functionality: Restricted Users: Restriction Start:

11.4 Suspension

System / Function Suspended: Suspension Authority: Suspension Date:

11.5 Containment Evidence

Evidence IDs:

12. Business Continuity

12.1 Operational Impact

Business Impact:

12.2 Alternative Process

Alternative / Manual Process:

12.3 Continuity Status

Continuity Status:
  • Normal
  • Degraded
  • Manual Workaround
  • Major Disruption
  • Critical Disruption

12.4 Recovery Requirements

Recovery Requirements:

13. Investigation

13.1 Investigation Record

Investigation ID: Investigation Lead: Investigation Start: Investigation Status:
  • Not Started
  • In Progress
  • Suspended
  • Completed
  • Reopened

13.2 Investigation Objectives

Objectives:
  • determine what happened;
  • establish scope;
  • establish impact;
  • identify cause;
  • identify control failures;
  • determine whether other systems are affected;
  • determine required corrective action;
  • support governance decisions.

13.3 Investigation Questions

  • What happened?
  • When did it happen?
  • Which system / model / data was involved?
  • Which version was operating?
  • What changed?
  • Who or what was affected?
  • Which controls were expected to operate?
  • Did those controls operate?
  • Was the event previously detectable?
  • Did an unauthorized action occur?
  • Are other systems or stakeholders affected?

14. Investigation Team


15. Investigation Evidence

15.1 Evidence Preservation

Evidence Preservation Requirement:

15.2 Preserved Evidence

15.3 Evidence Integrity

Evidence Integrity Controls:

16. Technical Investigation

16.1 Technical Findings

Findings:

16.2 System / Model Condition

Relevant Technical Condition:

16.3 Model Version

Model Version at Time of Incident:

16.4 Configuration

Relevant Configuration:

16.5 Data Condition

Relevant Data Condition:

17. Data Investigation

17.1 Data Sources

Relevant Data Sources:

17.2 Data Change

Was there a relevant data change?
  • Yes
  • No
  • Unknown
  • Under Investigation
Description:

17.3 Data Quality

Data Quality Findings:

17.4 Data Drift

Data Drift Identified:
  • Yes
  • No
  • Unknown
Findings:

18. Model Investigation

18.1 Model Condition

Model Behavior / Condition:

18.2 Model Change

Was there a model change?
  • Yes
  • No
  • Unknown
Change Reference:

18.3 Model Performance

Performance Findings:

18.4 Model Drift

Model Drift Identified:
  • Yes
  • No
  • Unknown
Findings:

19. Human Oversight Investigation

19.1 Human Oversight

Was human oversight required?
  • Yes
  • No

19.2 Oversight Operation

Did human oversight operate as designed?
  • Yes
  • Partially
  • No
  • Unknown
Findings:

19.3 Human Decision Impact

Did a human decision-maker rely on the affected AI output?

19.4 Override

Was the AI output challenged or overridden?

20. Privacy Investigation

20.1 Privacy Impact

Privacy Impact Identified:
  • Yes
  • No
  • Unknown

20.2 Data Exposure

Potential / Actual Data Exposure:

20.3 Privacy Assessment

Privacy Assessment ID: Assessment Result:

20.4 Privacy Escalation

Privacy Escalation Required: Reference:

21. Security Investigation

21.1 Security Impact

Security Impact Identified:
  • Yes
  • No
  • Unknown

21.2 Security Condition

Security Findings:

21.3 Security Assessment

Security Assessment ID: Assessment Result:

21.4 Security Escalation

Security Escalation Required: Reference:

22. Fairness and Impact Investigation

22.1 Fairness Impact

Fairness / Discrimination Concern:
  • Yes
  • No
  • Unknown

22.2 Affected Groups

Potentially Affected Groups:

22.3 Impact Assessment

Impact Assessment ID: Assessment Result:

22.4 Fairness Analysis

Findings:

23. Root Cause Analysis

23.1 Root Cause

Primary Root Cause:

23.2 Contributing Causes

23.3 Root Cause Category

Potential categories:
  • Data
  • Model
  • Technology
  • Configuration
  • Process
  • Procedure
  • Control
  • Human
  • Supplier
  • Change Management
  • Monitoring
  • Governance
  • Other
Applicable Category:

23.4 Root Cause Confidence

Confidence:
  • High
  • Medium
  • Low
  • Preliminary
Rationale:

24. Control Failure Analysis

24.2 Control Failure

Control Failure Identified:
  • Yes
  • No
  • Unknown
Description:

24.3 Control Reassessment

Control Assessment Required: Assessment ID:

25. Risk Reassessment

25.2 Risk Change

Risk Change Summary:

25.3 Risk Treatment

Treatment Required:

25.4 Risk Acceptance

Risk Acceptance Required: Risk Acceptance ID:

26. Impact Assessment

26.1 Actual Impact

Known Actual Impact:

26.2 Potential Impact

Potential Impact:

26.3 Affected Records

Number of Affected Records:

26.4 Affected Decisions

Number / Type of Affected Decisions:

26.5 Reversibility

Impact Reversibility:
  • Fully Reversible
  • Substantially Reversible
  • Partially Reversible
  • Limited
  • Irreversible
Rationale:

27. Notification Assessment

27.1 Notification Applicability

Consider applicable:
  • internal notifications;
  • customer notifications;
  • stakeholder notifications;
  • supplier notifications;
  • contractual notifications;
  • regulatory notifications;
  • privacy notifications;
  • security notifications.
Applicable Notifications:

27.2 Notification Decision

Notification Required: Decision Authority: Decision Date:

27.3 Notification Evidence

Evidence IDs:

28. Corrective Action

28.1 Corrective Action Plan

Corrective actions may include:
  • technical correction;
  • data correction;
  • model correction;
  • control improvement;
  • monitoring improvement;
  • procedure update;
  • governance change;
  • training;
  • supplier action.
Required Actions:

28.2 Corrective Action Register


29. Remediation

29.1 Remediation Actions

Remediation Description:

29.2 Technical Remediation

Technical Actions:

29.3 Process Remediation

Process Actions:

29.4 Governance Remediation

Governance Actions:

29.5 Remediation Evidence

Evidence IDs:

30. Retesting

30.1 Retest Required

Retest Required:

30.2 Retest Record

Retest ID: Retest Owner: Retest Date:

30.3 Retest Scope

Scope:

30.4 Retest Result

Result:
  • Passed
  • Passed with Conditions
  • Failed
  • Inconclusive
Rationale:

30.5 Corrective Action Effectiveness

Corrective Actions Effective:
  • Yes
  • Partially
  • No
  • Not Yet Determined

31. Recovery

31.1 Recovery Readiness

Recovery Status:
  • Not Ready
  • Ready with Conditions
  • Ready
  • Completed

31.2 Recovery Conditions

Conditions:

31.3 Recovery Authorization

Recovery Authority: Authorization Date:

31.4 Recovery Evidence

Evidence IDs:

32. Enhanced Monitoring After Incident

32.1 Enhanced Monitoring Required

Yes / No:

32.2 Trigger

Reason:

32.3 Duration

Duration:

32.4 Indicators

32.5 Exit Criteria

Criteria for Returning to Normal Monitoring:

33. System Resumption

33.1 Resumption Decision

Decision:
  • Resume Fully
  • Resume with Conditions
  • Resume Restricted Functionality
  • Do Not Resume
  • Retire

33.2 Resumption Scope

Scope:

33.3 Resumption Conditions

Conditions:

33.4 Resumption Authority

Authority: Authorization Date:

34. Change Management Relationship

34.1 Change Required

Does the incident require a system / process change?
  • Yes
  • No
  • Pending

34.2 Change Record

Change ID:

34.3 Change Description

Description:

34.4 Change Approval

Approval Status:

35. Assurance Relationship

35.1 Assurance Required

Assurance Required:

35.2 Assurance Record

Assurance ID: Assurance Owner:

35.3 Assurance Scope

Scope:

35.4 Assurance Result

Result:

36. Lessons Learned

36.1 Lessons

Lessons Learned:

36.2 Framework Improvements

Potential improvement areas:
  • governance;
  • controls;
  • risk management;
  • monitoring;
  • procedures;
  • training;
  • evidence;
  • approval;
  • change management.
Required Improvements:

36.3 Improvement Records


37. Incident Closure

37.1 Closure Criteria

The incident should not be closed until applicable criteria have been satisfied.
  • Containment completed
  • Impact assessed
  • Investigation completed
  • Root cause identified or sufficiently understood
  • Required notifications addressed
  • Corrective actions assigned
  • Corrective actions completed where required
  • Retesting completed where required
  • Residual risk assessed
  • Recovery / resumption decision completed
  • Required change actions completed
  • Evidence preserved
  • Lessons learned documented
  • Governance review completed where required
  • Closure authority identified

38. Closure Decision

38.1 Closure Status

Status:
  • Closed
  • Closed with Conditions
  • Reopened
  • Closure Deferred

38.2 Closure Rationale

Rationale:

38.3 Closure Authority

Closure Authority: Closure Date: Closure Record ID:

39. Post-Incident Review

39.1 Review Required

Post-Incident Review Required:

39.2 Review Date

Date:

39.3 Review Owner

Owner:

39.4 Review Outcome

Outcome:

39.5 Additional Actions

Actions:

40. Incident Evidence

40.1 Evidence Repository

Evidence Repository: Evidence Owner:

40.2 Evidence Register

40.3 Evidence Completeness

Evidence Status:
  • Complete
  • Substantially Complete
  • Partially Complete
  • Incomplete
Evidence Gaps:

40.4 Evidence Integrity

Integrity Controls:

41. Incident Traceability

The incident should maintain traceability to relevant AIGO records.

42. Incident Traceability Model


43. Incident Communication

43.1 Internal Communication

Internal Stakeholders Notified:

43.2 External Communication

External Stakeholders Notified:

43.3 Communication Approval

Communication Authority: Approval Date:

43.4 Communication Evidence

Evidence IDs:

44. Incident Review and Approval

44.1 Prepared By

Name: Role: Date:

44.2 Reviewed By

Name: Role: Date:

44.3 Approved By

Name: Role: Date:

44.4 Incident Decision

Decision:
  • Continue Investigation
  • Contain
  • Remediate
  • Resume
  • Close
  • Reopen
  • Suspend
  • Retire
Conditions:

45. Incident Review Schedule

45.1 Periodic Follow-Up

Follow-Up Review Frequency: Next Review Date: Review Owner:

45.2 Triggered Follow-Up

Follow-up should be considered when:
  • corrective actions are overdue;
  • residual risk remains high;
  • monitoring remains under enhanced conditions;
  • control effectiveness remains uncertain;
  • additional incidents occur;
  • material changes occur.
Additional Triggers:

46. Incident Change History


47. Incident Completion Checklist

  • Incident ID assigned
  • AI System ID identified
  • Detection source recorded
  • Incident category assigned
  • Initial severity assigned
  • Incident description documented
  • Expected vs actual condition documented
  • Affected stakeholders identified
  • Affected persons assessed
  • Timeline established
  • Immediate risk assessed
  • Containment completed
  • Business continuity assessed
  • Investigation initiated
  • Investigation team assigned
  • Evidence preserved
  • Technical investigation completed
  • Data investigation completed where applicable
  • Model investigation completed where applicable
  • Human oversight reviewed
  • Privacy impact assessed where applicable
  • Security impact assessed where applicable
  • Fairness / impact assessed where applicable
  • Root cause assessed
  • Control failures assessed
  • Risk reassessed
  • Notification requirements assessed
  • Corrective actions assigned
  • Remediation completed where required
  • Retesting completed where required
  • Recovery decision made
  • Enhanced monitoring established where required
  • Resumption decision recorded
  • Change management assessed
  • Assurance requirement assessed
  • Lessons learned recorded
  • Evidence preserved
  • Closure criteria satisfied
  • Closure authority approved
  • Post-incident review completed where required
  • Related AIGO records linked

48. Template Usage Instructions

This template should be completed according to the organization’s approved AIGO AI Incident Management Procedure. AI incidents should be managed according to severity and potential impact. Incident handling should prioritize:
  1. protection of affected persons and stakeholders;
  2. containment of ongoing harm;
  3. preservation of evidence;
  4. accurate assessment;
  5. appropriate escalation;
  6. root-cause analysis;
  7. corrective action;
  8. verification;
  9. controlled recovery;
  10. continual improvement.
Incident closure should not be based solely on technical recovery. The organization should also consider:
  • residual risk;
  • control effectiveness;
  • affected stakeholders;
  • required notifications;
  • lessons learned;
  • required governance changes.
Material incidents should trigger appropriate review of:
  • risk;
  • classification;
  • controls;
  • monitoring;
  • change management;
  • approval;
  • assurance.

49. Template Governance

49.1 Template Owner

Template Owner:

49.2 Template Review

Review Frequency: Next Review Date:

49.3 Template Change Control

Changes to this template should be managed through the applicable AIGO document and change-management process. Material changes should consider their effect on:
  • AI Incident Management Procedure;
  • AI Risk Assessment;
  • AI Control Assessment;
  • AI Monitoring;
  • AI Change Management;
  • AI Approval;
  • AI Assurance;
  • Risk Acceptance;
  • Continuous Improvement;
  • schemas;
  • mappings;
  • tools.

50. Document Control


51. Template Status

Document: AIGO — AI Incident Template Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-TPL-010 Document Type: AI Incident Template This template provides the controlled structure for detecting, recording, assessing, containing, investigating, remediating, recovering from, closing, and learning from AI-related incidents throughout the AIGO AI Governance Operating Framework.

52. End of Template

AIGO — AI Incident Template Document ID: AIGO-TPL-010 Version: 0.1 Status: Draft End of Template