Skip to main content

AIGO — AI Governance Operating Framework

AI Risk Acceptance Template

Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-TPL-008 Document Type: AI Risk Acceptance Template Template Purpose: Controlled Acceptance, Escalation, and Review of Residual AI Risk

1. Template Purpose

This template provides the controlled structure for documenting a decision to accept residual AI risk within the AIGO AI Governance Operating Framework. Risk acceptance is used only after the organization has:
  • identified the AI risk;
  • assessed the risk;
  • considered treatment options;
  • evaluated applicable controls;
  • determined residual risk;
  • considered applicable requirements;
  • determined that acceptance is within authorized tolerance;
  • identified an appropriate acceptance authority;
  • established monitoring and review requirements.
Risk acceptance does not mean that the risk has been eliminated. It means that an authorized decision-maker has consciously accepted the remaining risk under defined conditions. This template does not replace the organization’s approved AIGO AI Risk Acceptance Procedure.

2. Acceptance Instructions

Complete all applicable sections. Where information is not available, record: Pending — [reason] Where a section does not apply, record: Not Applicable — [reason] Every accepted risk should have a unique Risk ID. Where possible, maintain traceability to:
  • AI System ID;
  • Risk Assessment ID;
  • Risk ID;
  • Control ID;
  • Treatment ID;
  • Approval ID;
  • Evidence ID;
  • Monitoring ID;
  • Incident ID;
  • Change ID;
  • Assurance ID;
  • Management Review ID.
Risk acceptance should be time-bounded or subject to defined review unless the organization’s approved methodology explicitly permits otherwise.

3. Risk Acceptance Record

3.1 Identification

AI System ID: Risk Acceptance ID: Risk ID: Risk Assessment ID: Acceptance Version: Acceptance Status:
  • Draft
  • Under Review
  • Pending Approval
  • Approved
  • Approved with Conditions
  • Deferred
  • Rejected
  • Expired
  • Revoked
  • Closed
Risk Owner: Acceptance Owner: Prepared By: Reviewer: Approval Authority: Date Prepared: Decision Date: Effective Date: Review Date: Expiry Date:

4. AI System Context

4.1 AI System

System Name: System Version: System Owner: Business Owner: Technical Owner: Current Lifecycle Stage: AIGO Classification:

4.2 Intended Purpose

Approved Intended Purpose:

4.3 Operating Context

Relevant Operating Context:

5. Risk Being Accepted

5.1 Risk Statement

Risk Title: Risk Statement:

5.2 Risk Cause

Cause(s):

5.3 Risk Event

Risk Event:

5.4 Potential Consequence

Potential Consequence(s):

5.5 Affected Stakeholders

Affected Stakeholders / Persons:

5.6 Potential Harm

Potential Harm:

6. Risk Assessment

6.1 Assessment Reference

Risk Assessment ID: Assessment Date: Assessment Owner:

6.2 Inherent Risk

Likelihood Score: Likelihood Level: Impact Score: Impact Level: Inherent Risk Score: Inherent Risk Level: Inherent Risk Rationale:

6.3 Residual Risk

Residual Likelihood Score: Residual Likelihood Level: Residual Impact Score: Residual Impact Level: Residual Risk Score: Residual Risk Level: Residual Risk Rationale:

7. Risk Treatment Review

7.1 Treatment Options Considered

Options may include:
  • Avoid
  • Reduce
  • Mitigate
  • Transfer
  • Restrict
  • Share
  • Accept
  • Suspend
  • Retire
Treatment Options Considered:

7.2 Selected Treatment

Selected Treatment:

7.3 Treatment Rationale

Why this treatment was selected:

7.4 Treatment Status

Treatment Status:
  • Complete
  • Substantially Complete
  • Partially Complete
  • Outstanding
  • Not Applicable
Rationale:

8. Controls Applied

8.1 Existing Controls

8.2 Critical Controls

Critical Controls:

8.3 Control Assessment

Control Assessment ID: Assessment Date: Overall Control Effectiveness:

8.4 Control Limitations

Known Control Limitations:

9. Why Risk Remains

Residual risk may remain because of:
  • technical limitations;
  • uncertainty;
  • incomplete information;
  • unavoidable exposure;
  • business necessity;
  • cost / proportionality;
  • limitations in available controls;
  • third-party dependency;
  • operational constraints;
  • residual uncertainty.
Reason Residual Risk Remains:

10. Alternatives Considered

10.1 Alternative Treatment Options

10.2 Alternatives Rejected

Rejected Alternatives:

10.3 Rejection Rationale

Rationale:

11. Risk Tolerance Assessment

11.1 Organizational Risk Appetite

Applicable AI Risk Appetite:

11.2 Risk Tolerance

Applicable Risk Tolerance:

11.3 Within Tolerance?

Is the residual risk within authorized tolerance?
  • Yes
  • No
  • Conditional
  • Unclear
Rationale:

11.4 Risk Acceptance Authority

Authority Required to Accept This Risk: Authority Basis / Delegation Reference:

12. Regulatory and Legal Review

12.1 Applicable Requirements

Does any requirement prohibit or materially restrict acceptance of this risk?
  • Yes
  • No
  • Pending Review
Rationale: Reviewer: Result: Date: Evidence ID:

13. Human Impact Review

13.1 Affected Persons

Affected Persons:

13.2 Potential Harm

Potential Harm:

13.3 Reversibility

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

13.4 Human Oversight

Human Oversight Available: Human Oversight Adequacy: Evidence ID:

14. Uncertainty Review

14.1 Known Uncertainties

Uncertainties:

14.2 Uncertainty Significance

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

14.3 Unknowns Affecting Acceptance

Material Unknowns:

14.4 Uncertainty Monitoring

Monitoring Requirements:

15. Third-Party and Supply-Chain Considerations

15.1 Third-Party Dependency

Relevant Third Parties:

15.2 Supplier Risk

Supplier Risk Level:

15.3 Supplier Controls

Controls:

15.4 Supplier Assurance

Evidence / Assurance Reference:

15.5 Supplier Change Risk

Supplier Change Considerations:

16. Monitoring Requirements

Risk acceptance should include monitoring sufficient to determine whether the accepted risk remains within tolerance.

16.1 Risk Indicators

16.2 Monitoring Owner

Monitoring Owner:

16.3 Monitoring Frequency

Frequency:

16.4 Threshold Breach

Required Action if Threshold Is Breached:

17. Acceptance Conditions

Risk acceptance may be subject to conditions.

17.1 Mandatory Conditions

Conditions that must remain satisfied:

17.2 Condition Failure

Action if a condition is not satisfied:

18. Escalation Requirements

18.1 Escalation Triggers

Escalation may be required when:
  • residual risk exceeds tolerance;
  • a critical control fails;
  • a material incident occurs;
  • monitoring thresholds are breached;
  • new harm is identified;
  • system context changes;
  • classification changes;
  • legal or regulatory requirements change;
  • risk treatment becomes ineffective.
Applicable Triggers:

18.2 Escalation Path

Escalation Path:

18.3 Escalation Authority

Escalation Authority:

19. Acceptance Period

19.1 Effective Period

Effective From: Effective Until:

19.2 Review Frequency

Review Frequency:

19.3 Automatic Expiry

Does the acceptance automatically expire?
  • Yes
  • No
Expiry Rule:

19.4 Renewal

Renewal Requirements:

20. Approval Decision

20.1 Decision Options

  • Approved
  • Approved with Conditions
  • Deferred
  • Rejected
  • Escalated
  • Suspended
  • Revoked

20.2 Final Decision

Decision:

20.3 Decision Rationale

Rationale:

20.4 Approved Risk Position

Approved Residual Risk Level:

20.5 Approved Scope

Scope of Acceptance:

20.6 Restrictions

Restrictions:

21. Acceptance Authority

21.1 Decision Authority

Acceptance Authority: Role:

21.2 Authority Basis

Authority Basis / Delegation Reference:

21.3 Authority Verification

Authority Verified By: Verification Date:

22. Segregation of Duties

Where practical, risk acceptance should separate:
  • risk identification;
  • risk assessment;
  • treatment recommendation;
  • risk acceptance;
  • independent assurance.

22.1 Role Separation


23. Evidence

23.1 Evidence Repository

Evidence Repository: Evidence Owner:

23.2 Supporting Evidence

23.3 Evidence Completeness

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

23.4 Evidence Quality

Evidence Quality:
  • Strong
  • Adequate
  • Moderate
  • Weak
  • Insufficient
Rationale:

24. Monitoring and Review Results

24.1 Latest Review

Review Date: Reviewer: Risk Status: Control Status: Monitoring Status:

24.2 Review Result

Result:
  • Continue Acceptance
  • Modify Conditions
  • Reduce Risk Further
  • Escalate
  • Suspend Acceptance
  • Revoke Acceptance
  • Close Acceptance
Rationale:

25. Triggered Reassessment

25.1 Trigger

Was this acceptance triggered by an incident, change, monitoring result, or other event?
  • Yes
  • No
Trigger Type: Reference ID:

25.2 Reassessment

Reassessment Required: Reassessment ID: Outcome:

26. Incident Relationship

26.2 Incident Impact

Impact of Related Incidents on Acceptance:

27. Change Relationship

27.2 Change Impact on Acceptance

Impact:

28. Assurance Relationship

28.2 Assurance Findings

Open Assurance Findings Affecting This Acceptance:

29. Management Review

29.1 Management Review Required

Required:

29.2 Review Reference

Management Review ID: Review Date:

29.3 Management Review Outcome

Outcome:

29.4 Management Actions

Actions:

30. Acceptance Lifecycle

The risk acceptance should be managed through a controlled lifecycle.

31. Acceptance-to-Risk Traceability


32. Acceptance-to-Control Traceability


33. Acceptance-to-Evidence Traceability


34. Acceptance Decision Quality Review

Before final approval, verify:
  • Risk is clearly identified
  • Risk assessment is current
  • Inherent risk is documented
  • Controls are identified
  • Control effectiveness is assessed
  • Residual risk is documented
  • Treatment options were considered
  • Alternatives were considered
  • Applicable requirements were reviewed
  • Human impact was considered
  • Uncertainty was considered
  • Third-party dependency was considered where applicable
  • Monitoring requirements are defined
  • Acceptance conditions are defined
  • Escalation triggers are defined
  • Acceptance period is defined
  • Acceptance authority is authorized
  • Segregation of duties is considered
  • Evidence is sufficient
  • Related incidents are reviewed
  • Related changes are reviewed
  • Assurance findings are reviewed
  • Management review is completed where required
  • Final decision is recorded
  • Review date is established
  • Related AIGO records are linked

35. Acceptance Review and Reapproval

35.1 Periodic Review

Review Frequency: Next Review Date: Review Owner:

35.2 Reapproval Triggers

Reapproval should be considered after:
  • material changes;
  • significant incidents;
  • material monitoring deviations;
  • significant increases in residual risk;
  • control failures;
  • classification changes;
  • new legal or regulatory requirements;
  • changes in risk appetite;
  • expiration of acceptance period.
Additional Triggers:

36. Acceptance Change History


37. Final Acceptance Record

AI System ID: Risk ID: Risk Acceptance ID: Residual Risk: Decision: Conditions: Risk Owner: Acceptance Authority: Effective Date: Expiry Date: Next Review Date: Monitoring Requirement: Status:

38. Template Usage Instructions

This template should be completed according to the organization’s approved AIGO AI Risk Acceptance Procedure. Risk acceptance should only be used where the organization has first evaluated reasonable treatment options. Acceptance should not be used to bypass:
  • mandatory legal requirements;
  • required controls;
  • required approvals;
  • prohibited uses;
  • unacceptable risks;
  • mandatory incident response;
  • required human oversight.
The acceptance authority should have sufficient authority for the level of residual risk being accepted. Where residual risk exceeds the authority’s tolerance or delegated authority, the risk should be escalated. Risk acceptance should be reviewed when the accepted risk, system, controls, operating context, or applicable requirements materially change.

39. Template Governance

39.1 Template Owner

Template Owner:

39.2 Template Review

Review Frequency: Next Review Date:

39.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 Risk Acceptance Procedure;
  • AI Risk Assessment;
  • AI System Profile;
  • AI Classification;
  • Control Assessment;
  • Approval;
  • Monitoring;
  • Incident Management;
  • Change Management;
  • Assurance;
  • Management Review;
  • schemas;
  • mappings;
  • tools.

40. Document Control


41. Template Status

Document: AIGO — AI Risk Acceptance Template Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-TPL-008 Document Type: AI Risk Acceptance Template This template provides the controlled structure for documenting, approving, monitoring, reviewing, renewing, modifying, suspending, or revoking acceptance of residual AI risk within the AIGO AI Governance Operating Framework.

42. End of Template

AIGO — AI Risk Acceptance Template Document ID: AIGO-TPL-008 Version: 0.1 Status: Draft End of Template