> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aigoframework.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 10 AIGO AI Incident Template v0.1

# 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

| Stakeholder | Role / Interest | Potential Impact | Notification Requirement |
| ----------- | --------------- | ---------------- | ------------------------ |
|             |                 |                  |                          |
|             |                 |                  |                          |
|             |                 |                  |                          |

## 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

| Timestamp | Event | Actor / System | Evidence | Significance |
| --------- | ----- | -------------- | -------- | ------------ |
|           |       |                |          |              |
|           |       |                |          |              |
|           |       |                |          |              |
|           |       |                |          |              |

## 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

| Role                      | Person / Function | Responsibility | Independence |
| ------------------------- | ----------------- | -------------- | ------------ |
| Incident Manager          |                   |                |              |
| System Owner              |                   |                |              |
| Technical Investigator    |                   |                |              |
| Risk Representative       |                   |                |              |
| Data Representative       |                   |                |              |
| Security Representative   |                   |                |              |
| Privacy Representative    |                   |                |              |
| Governance Representative |                   |                |              |
| Assurance Representative  |                   |                |              |

***

# 15. Investigation Evidence

## 15.1 Evidence Preservation

**Evidence Preservation Requirement:**

## 15.2 Preserved Evidence

| Evidence ID | Evidence Type | Description | Owner | Date Preserved | Location |
| ----------- | ------------- | ----------- | ----- | -------------- | -------- |
|             |               |             |       |                |          |
|             |               |             |       |                |          |
|             |               |             |       |                |          |

## 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.1 Related Controls

| Control ID | Control | Expected Operation | Actual Operation | Effectiveness | Impact |
| ---------- | ------- | ------------------ | ---------------- | ------------- | ------ |
|            |         |                    |                  |               |        |
|            |         |                    |                  |               |        |
|            |         |                    |                  |               |        |

## 24.2 Control Failure

**Control Failure Identified:**

* Yes
* No
* Unknown

**Description:**

## 24.3 Control Reassessment

**Control Assessment Required:**

**Assessment ID:**

***

# 25. Risk Reassessment

## 25.1 Related Risks

| Risk ID | Risk | Pre-Incident Level | Post-Incident Level | Status |
| ------- | ---- | ------------------ | ------------------- | ------ |
|         |      |                    |                     |        |
|         |      |                    |                     |        |
|         |      |                    |                     |        |

## 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

| Corrective Action ID | Action | Owner | Priority | Due Date | Status | Evidence |
| -------------------- | ------ | ----- | -------- | -------- | ------ | -------- |
|                      |        |       |          |          |        |          |
|                      |        |       |          |          |        |          |
|                      |        |       |          |          |        |          |

***

# 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

| Indicator | Threshold | Frequency | Owner | Status |
| --------- | --------- | --------- | ----- | ------ |
|           |           |           |       |        |
|           |           |           |       |        |

## 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

| Improvement ID | Lesson / Improvement | Owner | Priority | Target Date | Status |
| -------------- | -------------------- | ----- | -------- | ----------- | ------ |
|                |                      |       |          |             |        |
|                |                      |       |          |             |        |

***

# 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

| Evidence ID | Evidence Type | Description | Owner | Date | Location | Status |
| ----------- | ------------- | ----------- | ----- | ---- | -------- | ------ |
|             |               |             |       |      |          |        |
|             |               |             |       |      |          |        |
|             |               |             |       |      |          |        |

## 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.

| AIGO Record               | Identifier |
| ------------------------- | ---------- |
| Governance Record         |            |
| AI System Registration    |            |
| AI System Profile         |            |
| Classification Record     |            |
| Risk Assessment           |            |
| Control Assessment        |            |
| Monitoring Plan           |            |
| Change Record             |            |
| Approval Record           |            |
| Assurance Record          |            |
| Risk Acceptance Record    |            |
| Corrective Action Records |            |
| Improvement Records       |            |
| Evidence Records          |            |

***

# 42. Incident Traceability Model

```text theme={null}
AI System
   ↓
Lifecycle Stage
   ↓
Risk
   ↓
Control
   ↓
Monitoring
   ↓
Alert
   ↓
Incident
   ↓
Containment
   ↓
Investigation
   ↓
Root Cause
   ↓
Corrective Action
   ↓
Retest
   ↓
Residual Risk
   ↓
Recovery / Resumption
   ↓
Assurance
   ↓
Lessons Learned
   ↓
Continual Improvement
```

***

# 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

| Version | Date | Change                  | Changed By | Reviewer | Approval |
| ------- | ---- | ----------------------- | ---------- | -------- | -------- |
| 0.1     |      | Initial incident record |            |          |          |
|         |      |                         |            |          |          |

***

# 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

| Field               | Value                       |
| ------------------- | --------------------------- |
| Document            | AIGO — AI Incident Template |
| Version             | 0.1                         |
| Status              | Draft                       |
| Document Identifier | `AIGO-TPL-010`              |
| Document Type       | AI Incident Template        |
| Template Owner      |                             |
| Approved By         |                             |
| Approval Date       |                             |
| Effective Date      |                             |
| Next Review Date    |                             |

***

# 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**