Skip to main content

AIGO — AI Governance Operating Framework

AI Risk Assessment Template

Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-TPL-005 Document Type: AI Risk Assessment Template Template Purpose: Controlled Identification, Analysis, Evaluation, Treatment, and Acceptance of AI Risk

1. Template Purpose

This template provides the controlled structure for assessing AI-related risks within the AIGO AI Governance Operating Framework. The risk assessment should establish traceability between:
  • AI system;
  • intended purpose;
  • operating context;
  • stakeholders;
  • affected persons;
  • risk scenarios;
  • potential harms;
  • likelihood;
  • impact;
  • inherent risk;
  • controls;
  • treatment;
  • control effectiveness;
  • residual risk;
  • risk acceptance;
  • escalation;
  • monitoring;
  • reassessment;
  • evidence;
  • governance decisions.
This template does not replace the organization’s approved AI Risk Assessment Procedure. Risk assessment should be performed throughout the AI lifecycle and updated when material changes, incidents, monitoring findings, or changes in context require reassessment.

2. Assessment Instructions

Complete all applicable sections. Where information is not yet available, record: Pending — [reason] Where a field does not apply, record: Not Applicable — [reason] Each material risk should have a unique Risk ID. Recommended identifiers include:
  • AI System ID;
  • Risk Assessment ID;
  • Risk ID;
  • Control ID;
  • Treatment ID;
  • Evidence ID;
  • Decision ID;
  • Incident ID;
  • Change ID;
  • Monitoring ID.
Risk ratings and acceptance thresholds should follow the organization’s approved risk methodology.

3. Assessment Record

3.1 Identification

AI System ID: Risk Assessment ID: Assessment Version: Assessment Type:
  • Initial
  • Periodic
  • Triggered
  • Post-Incident
  • Post-Change
  • Reassessment
  • Retirement
Assessment Status:
  • Draft
  • In Progress
  • Under Review
  • Approved
  • Approved with Conditions
  • Reassessment Required
  • Closed
Assessment Owner: Risk Owner: Lead Assessor: Reviewer: Approval Authority: Assessment Date: Effective Date: Next Review Date:

4. AI System Context

4.1 System Information

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

4.2 Intended Purpose

Approved Intended Purpose:

4.3 Intended Use

Approved Intended Use:

4.4 Restricted / Prohibited Use

Restricted Uses: Prohibited Uses:

4.5 Business Process

Business Process Supported:

4.6 Operating Environment

Operating Environment:

5. Assessment Scope

5.1 Scope

Assessment Scope:

5.2 Lifecycle Scope

Select applicable lifecycle stages:
  • Govern
  • Identify
  • Classify
  • Assess
  • Treat
  • Approve
  • Deploy
  • Operate
  • Monitor
  • Assure
  • Improve
  • Change
  • Continue
  • Retire
Applicable Lifecycle Stages:

5.3 Geographic Scope

Jurisdictions / Locations:

5.4 Organizational Scope

Business Units / Functions Covered:

5.5 Exclusions

Excluded Areas: Exclusion Rationale:

6. Assessment Context

6.1 Organizational Context

Relevant Organizational Context:

6.2 AI-System Context

Relevant AI-System Context:

6.3 External Context

Consider:
  • laws;
  • regulations;
  • standards;
  • contractual requirements;
  • market conditions;
  • threat environment;
  • stakeholder expectations.
Relevant External Context:

6.4 Assumptions

Assessment Assumptions:

6.5 Constraints

Assessment Constraints:

7. Stakeholder and Affected-Person Assessment

7.1 Stakeholders

7.2 Affected Persons

Affected Persons:

7.3 Affected Groups

Potentially Affected Groups:

7.4 Potential Harm

Potential harms may include:
  • financial harm;
  • physical harm;
  • psychological harm;
  • privacy harm;
  • security harm;
  • discrimination;
  • loss of opportunity;
  • operational harm;
  • legal harm;
  • reputational harm;
  • societal harm.
Potential Harm Areas:

7.5 Stakeholder Input

Stakeholder Consultation / Input: Supporting Evidence IDs:

8. Risk Assessment Methodology

8.1 Risk Methodology

Approved Risk Methodology:

8.2 Risk Model

Risk Calculation Method: Example: Risk Score = Likelihood × Impact

8.3 Likelihood Scale

Organization-Specific Modifications:

8.4 Impact Scale

Organization-Specific Modifications:

8.5 Risk Levels

Approved Threshold Reference:

9. Risk Identification

9.1 Risk Identification Methods

Applicable methods may include:
  • workshops;
  • interviews;
  • stakeholder consultation;
  • process analysis;
  • technical analysis;
  • data analysis;
  • model testing;
  • incident review;
  • monitoring;
  • assurance;
  • regulatory analysis;
  • expert assessment.
Methods Used:

9.2 Risk Taxonomy

Potential categories include:
  • Governance
  • Strategic
  • Legal / Regulatory
  • Privacy
  • Security
  • Fairness
  • Discrimination
  • Safety
  • Reliability
  • Robustness
  • Resilience
  • Transparency
  • Explainability
  • Human Oversight
  • Data
  • Model
  • Operational
  • Third Party
  • Supply Chain
  • Reputational
  • Financial
  • Societal
  • Other
Applicable Categories:

10. Risk Statement Structure

Each material risk should be expressed in a structured manner. Recommended structure: Cause → Risk Event → Consequence

10.1 Example

Cause: Risk Event: Potential Consequence: Complete Risk Statement:

11. Risk Register


12. Individual Risk Assessment

12.1 Risk Identification

Risk ID: Risk Title: Risk Category: Lifecycle Stage: Risk Owner: Control Owner(s):

12.2 Cause

Risk Cause(s):

12.3 Risk Event

Risk Event:

12.4 Consequence

Potential Consequence(s):

12.5 Affected Stakeholders

Affected Stakeholders / Persons:

12.6 Potential Harm

Potential Harm:

13. Inherent Risk Assessment

Inherent risk represents the level of risk before considering the effectiveness of controls.

13.1 Likelihood

Likelihood Score: Likelihood Level: Likelihood Rationale:

13.2 Impact

Impact Score: Impact Level: Impact Rationale:

13.3 Inherent Risk

Inherent Risk Score: Inherent Risk Level: Inherent Risk Rationale:

14. Inherent Risk Factors

Additional factors may be considered where relevant.

15. Existing Controls

15.1 Controls Addressing the Risk

15.2 Preventive Controls

Preventive Controls:

15.3 Detective Controls

Detective Controls:

15.4 Corrective Controls

Corrective Controls:

16. Control Effectiveness

16.1 Control Design

Design Effectiveness:
  • Effective
  • Partially Effective
  • Ineffective
  • Not Assessed
Rationale:

16.2 Control Implementation

Implementation Status:
  • Implemented
  • Partially Implemented
  • Not Implemented
  • Not Verified
Rationale:

16.3 Operating Effectiveness

Operating Effectiveness:
  • Effective
  • Partially Effective
  • Ineffective
  • Not Tested
Rationale:

16.4 Evidence Quality

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

17. Risk Treatment

17.1 Treatment Decision

Possible treatment options include:
  • Avoid
  • Reduce
  • Mitigate
  • Transfer
  • Restrict
  • Accept
  • Suspend
  • Retire
  • Other
Selected Treatment:

17.2 Treatment Rationale

Rationale:

17.3 Treatment Objective

Treatment Objective:

17.4 Treatment Owner

Treatment Owner:

18. Treatment Plan


19. Additional Controls

Where existing controls are insufficient, identify additional controls.

20. Residual Risk Assessment

Residual risk represents the risk remaining after considering implemented or committed controls and treatment.

20.1 Residual Likelihood

Likelihood Score: Likelihood Level: Rationale:

20.2 Residual Impact

Impact Score: Impact Level: Rationale:

20.3 Residual Risk

Residual Risk Score: Residual Risk Level: Rationale:

21. Residual Risk Comparison

Risk Reduction Summary:

22. Risk Acceptance

22.1 Acceptance Required

Is Formal Risk Acceptance Required?
  • Yes
  • No
  • To Be Determined

22.2 Acceptance Criteria

Risk acceptance should consider:
  • risk appetite;
  • risk tolerance;
  • potential harm;
  • legal and regulatory requirements;
  • control effectiveness;
  • evidence quality;
  • reversibility;
  • uncertainty;
  • availability of safer alternatives.
Acceptance Analysis:

22.3 Acceptance Authority

Risk Acceptance Authority:

22.4 Acceptance Record

Risk Acceptance Record ID: Acceptance Date: Acceptance Status: Acceptance Conditions: Expiry / Review Date:

23. Risk Escalation

23.1 Escalation Trigger

Potential triggers include:
  • critical risk;
  • risk above tolerance;
  • ineffective critical control;
  • material incident;
  • significant change;
  • monitoring threshold breach;
  • legal or regulatory concern;
  • unresolved uncertainty.
Applicable Trigger:

23.2 Escalation Path

Escalation Path:

23.3 Escalation Authority

Escalation Authority:

23.4 Escalation Decision

Decision:
  • Treat
  • Restrict
  • Accept
  • Escalate Further
  • Suspend
  • Retire
  • Other
Decision Rationale:

24. Risk Monitoring

24.1 Risk Indicators

24.2 Monitoring Requirements

Monitoring Requirements:

24.3 Trigger Conditions

Risk reassessment should occur when:
  • material incidents occur;
  • material changes occur;
  • risk indicators deteriorate;
  • control effectiveness declines;
  • system context changes;
  • new stakeholders become affected;
  • regulatory requirements change.
Additional Triggers:

25. Risk Reassessment

25.1 Reassessment Trigger

Reason for Reassessment:

25.2 Reassessment Date

Date:

25.3 Reassessment Result

Result:
  • No Material Change
  • Risk Increased
  • Risk Decreased
  • New Risk Identified
  • Control Effectiveness Changed
  • Classification Review Required
  • Other

25.4 Reassessment Actions

Required Actions:

26. Scenario Analysis

Where appropriate, assess different plausible operating scenarios.

27. Uncertainty Assessment

27.1 Sources of Uncertainty

Potential sources include:
  • incomplete data;
  • model limitations;
  • limited testing;
  • emergent behavior;
  • changing environment;
  • unknown dependencies;
  • insufficient historical evidence.
Applicable Uncertainties:

27.2 Uncertainty Significance

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

27.3 Uncertainty Treatment

Treatment:

28. Third-Party and Supply-Chain Risk

28.1 Third-Party Dependencies

Relevant Providers / Suppliers:

28.2 Third-Party Risks

Third-Party Risk:

28.3 Supplier Controls

Applicable Controls:

28.4 Supplier Evidence

Evidence IDs:

29. Data Risk

Potential risks include:
  • inaccurate data;
  • incomplete data;
  • biased data;
  • unrepresentative data;
  • poor provenance;
  • inappropriate data use;
  • privacy issues;
  • security exposure;
  • data drift.
Applicable Data Risks:

29.2 Data Risk Controls

Applicable Controls:

30. Model Risk

Potential risks include:
  • poor accuracy;
  • robustness weakness;
  • drift;
  • unexpected behavior;
  • model failure;
  • inappropriate generalization;
  • dependency on external models.
Applicable Model Risks:

30.2 Model Risk Controls

Applicable Controls:

31. Human Oversight Risk

31.1 Human Oversight Risks

Potential risks include:
  • automation bias;
  • inadequate competence;
  • insufficient information;
  • inability to override;
  • unclear responsibility;
  • failure to review outputs.
Applicable Risks:

31.2 Human Oversight Controls

Applicable Controls:

32. Fairness and Impact Risk

32.1 Fairness Risks

Potential Fairness / Discrimination Risks:

32.2 Impact Assessment

Relevant Impact Assessment ID:

32.3 Fairness Controls

Applicable Controls:

33. Privacy Risk

33.1 Privacy Risks

Potential Privacy Risks:

33.2 Privacy Controls

Applicable Controls:

33.3 Privacy Assessment

Privacy Assessment ID:

34. Security Risk

34.1 Security Risks

Potential Security Risks:

34.2 Security Controls

Applicable Controls:

34.3 Security Assessment

Security Assessment ID:

35. Safety and Reliability Risk

35.1 Safety Risks

Potential Safety Risks:

35.2 Reliability Risks

Potential Reliability Risks:

35.3 Safety / Reliability Controls

Applicable Controls:

36. Lifecycle Risk

Risk should be considered across applicable lifecycle stages.

37. Risk-to-Control Traceability

37.1 Traceability Matrix


38. Risk-to-Lifecycle Traceability


39. Risk-to-Evidence Traceability


40. Incident Relationship

40.2 Incident-Driven Reassessment

Did an incident trigger this assessment?
  • Yes
  • No
Incident Reference:

41. Change Relationship

41.2 Change-Driven Reassessment

Did a change trigger this assessment?
  • Yes
  • No
Change Reference:

42. Assurance Relationship

42.2 Assurance Findings

Open Findings Affecting This Risk Assessment:

43. Evidence Profile

43.1 Evidence Repository

Evidence Repository: Evidence Owner:

43.2 Supporting Evidence

43.3 Evidence Quality

Overall Evidence Quality:
  • Strong
  • Adequate
  • Moderate
  • Weak
  • Missing
Rationale:

43.4 Evidence Gaps

Evidence Gaps:

44. Risk Assessment Findings

44.1 Findings

44.2 Critical Findings

Critical Findings:

45. Risk Decision

45.1 Overall Risk Decision

Decision:
  • Accept
  • Accept with Conditions
  • Treat Further
  • Restrict
  • Escalate
  • Suspend
  • Retire
  • Other

45.2 Decision Rationale

Rationale:

45.3 Decision Authority

Decision Authority:

45.4 Decision Date

Date:

46. Management Review

46.1 Management Review Required

Required:

46.2 Management Review Reference

Review ID: Review Date:

46.3 Management Review Outcome

Outcome:

46.4 Management Actions

Actions:

47. Overall Assessment Conclusion

Overall Assessment Conclusion:

47.1 Key Findings

47.2 Key Risks

47.3 Key Controls

47.4 Residual Risk Position

Overall Residual Risk Position: Recommendation:

48. Assessment Approval

48.1 Prepared By

Name: Role: Date:

48.2 Reviewed By

Name: Role: Date:

48.3 Approved By

Name: Role: Date:

48.4 Approval Decision

Decision:
  • Approved
  • Approved with Conditions
  • Returned for Reassessment
  • Deferred
  • Rejected
Conditions:

49. Assessment Review and Reassessment Schedule

49.1 Scheduled Review

Review Frequency: Next Review Date: Review Owner:

49.2 Triggered Reassessment

Required Triggers:
  • material incident;
  • material change;
  • significant monitoring deviation;
  • control failure;
  • classification change;
  • regulatory change;
  • material context change.
Additional Triggers:

50. Assessment Change History


51. Assessment Traceability

The assessment should maintain links to relevant AIGO records.

52. Risk Assessment Completion Checklist

  • Assessment ID assigned
  • AI System ID identified
  • Assessment type identified
  • Scope documented
  • Organizational context assessed
  • AI-system context documented
  • Stakeholders identified
  • Affected persons identified
  • Potential harms assessed
  • Risk methodology identified
  • Risk taxonomy applied
  • Risks identified
  • Risk statements documented
  • Inherent likelihood assessed
  • Inherent impact assessed
  • Inherent risk determined
  • Existing controls identified
  • Control effectiveness assessed
  • Treatment determined
  • Additional controls identified
  • Residual likelihood assessed
  • Residual impact assessed
  • Residual risk determined
  • Risk acceptance assessed
  • Escalation requirements assessed
  • Monitoring requirements established
  • Reassessment triggers established
  • Relevant specialist risks assessed
  • Incident relationships reviewed
  • Change relationships reviewed
  • Assurance relationships reviewed
  • Evidence reviewed
  • Evidence gaps recorded
  • Findings recorded
  • Overall risk decision recorded
  • Management review completed where required
  • Assessment approved
  • Next review date established
  • Related AIGO records linked

53. Template Usage Instructions

This template should be completed according to the organization’s approved AIGO AI Risk Assessment Procedure. The risk assessment should be:
  • evidence-based;
  • risk-based;
  • lifecycle-aware;
  • proportional to the AI system;
  • documented;
  • attributable;
  • reviewable;
  • periodically reassessed.
Risk assessment should be updated when:
  • material changes occur;
  • significant incidents occur;
  • monitoring identifies material deviations;
  • controls change;
  • control effectiveness changes;
  • affected stakeholders change;
  • the operating context changes;
  • classification changes;
  • legal or regulatory requirements change.
A risk assessment should not be treated as permanently valid simply because the AI system has already received approval.

54. Template Governance

54.1 Template Owner

Template Owner:

54.2 Template Review

Review Frequency: Next Review Date:

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

55. Document Control


56. Template Status

Document: AIGO — AI Risk Assessment Template Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-TPL-005 Document Type: AI Risk Assessment Template This template provides the controlled structure for identifying, analyzing, evaluating, treating, accepting, monitoring, and reassessing AI risks throughout the AIGO AI governance lifecycle.

57. End of Template

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