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

# 05 AIGO AI Control Assessment Procedure v0.1

# AIGO — AI Governance Operating Framework

## AI Control Assessment Procedure

**Version:** 0.1\
**Status:** Draft\
**Working Name:** AIGO\
**Full Name:** AI Governance Operating Framework\
**Document Identifier:** AIGO-PROC-005

***

### 1. Purpose

This procedure defines the process for identifying, assessing, implementing, testing, documenting, and monitoring controls applicable to AI systems.

The procedure establishes how AIGO controls are translated into system-specific control requirements and how control effectiveness is evaluated throughout the AI system lifecycle.

***

### 2. Scope

This procedure applies to AI systems within the organization's AIGO governance scope.

It may apply to:

* internally developed AI systems;
* third-party AI systems;
* AI models;
* generative AI systems;
* AI agents;
* AI-enabled processes;
* AI components embedded in products or services; and
* material changes to existing AI systems.

***

### 3. Objectives

The objectives of control assessment are to:

* identify applicable controls;
* determine control ownership;
* assess control implementation;
* assess control effectiveness;
* identify control gaps;
* establish remediation requirements;
* support governance decisions;
* provide evidence for assurance; and
* maintain traceability between risks and controls.

***

### 4. Control Assessment Principles

Control assessment should be:

* risk-based;
* proportionate;
* evidence-based;
* repeatable;
* documented;
* traceable;
* lifecycle-oriented; and
* independently reviewable where required.

***

### 5. Control Assessment Authority

The organization should designate responsibility for control assessment.

Responsibilities may be assigned to:

* AI governance;
* control owners;
* risk management;
* security;
* privacy;
* compliance;
* technical teams; or
* assurance functions.

***

### 6. Control Assessment Triggers

A control assessment should be initiated when:

* a new AI system is introduced;
* an AI system is classified;
* a risk assessment identifies control requirements;
* a material system change occurs;
* a control changes;
* a significant incident occurs;
* a control failure is identified;
* an assurance review requires reassessment; or
* periodic review is due.

***

### 7. Control Sources

Applicable controls should be determined from relevant AIGO sources.

Sources may include:

* AIGO framework controls;
* AI System Profiles;
* risk assessments;
* organizational policies;
* legal requirements;
* regulatory requirements;
* contractual requirements;
* security requirements;
* privacy requirements; and
* domain-specific requirements.

***

### 8. Control Applicability

Each potentially applicable control should be evaluated for applicability.

The assessment should determine whether the control is:

* applicable;
* not applicable;
* conditionally applicable; or
* replaced by an equivalent control.

The rationale should be documented where a control is not applied.

***

### 9. Control Mapping

Applicable controls should be mapped to the relevant:

* AI system;
* risk;
* governance requirement;
* owner;
* implementation;
* evidence; and
* assurance activity.

A traceability relationship should be maintained.

***

### 10. Risk-to-Control Relationship

Controls should address identified risks where appropriate.

The organization should be able to demonstrate the relationship:

**Risk → Control → Implementation → Evidence → Effectiveness**

***

### 11. Control Ownership

Each applicable control should have an accountable owner.

The control owner should:

* understand the control objective;
* implement or coordinate implementation;
* maintain evidence;
* monitor effectiveness;
* address deficiencies; and
* support assurance.

***

### 12. Control Objectives

Each control should have a clearly understood objective.

The objective should describe the risk or governance outcome the control is intended to address.

***

### 13. Control Design

Control design should be evaluated before determining whether a control is effective.

Design assessment should consider:

* control objective;
* risk addressed;
* control mechanism;
* responsible owner;
* frequency;
* scope;
* dependencies; and
* expected evidence.

***

### 14. Control Implementation

The assessment should determine whether the control has actually been implemented.

Implementation status may include:

* not implemented;
* planned;
* partially implemented;
* implemented;
* implemented with limitations; or
* not applicable.

***

### 15. Control Operating Effectiveness

Where sufficient operating history exists, the organization should assess whether the control operates effectively.

Operating effectiveness should consider:

* execution;
* consistency;
* timeliness;
* completeness;
* exceptions;
* failures; and
* evidence.

***

### 16. Control Effectiveness Rating

Organizations may use a defined control effectiveness scale.

A representative scale is:

1. **Ineffective**
2. **Partially Effective**
3. **Effective**
4. **Highly Effective**

The organization should define criteria for each rating.

***

### 17. Control Evidence

Control owners should maintain sufficient evidence to demonstrate implementation and operation.

Evidence may include:

* policies;
* procedures;
* configurations;
* approvals;
* test results;
* logs;
* reports;
* monitoring records;
* training records; and
* review records.

***

### 18. Evidence Quality

Control evidence should be:

* relevant;
* sufficient;
* accurate;
* current;
* traceable;
* protected; and
* retrievable.

***

### 19. Control Testing

Controls should be tested where required by risk, classification, policy, assurance, or governance requirements.

Testing may include:

* inspection;
* inquiry;
* observation;
* technical testing;
* sampling;
* automated testing;
* walkthroughs; and
* independent assessment.

***

### 20. Test Scope

The control test should define:

* control being tested;
* test objective;
* test period;
* population;
* sample;
* test method;
* expected result; and
* evidence required.

***

### 21. Test Results

Test results should identify whether the control:

* passed;
* partially passed;
* failed;
* could not be tested; or
* requires further investigation.

Material findings should be documented.

***

### 22. Control Deficiencies

Control deficiencies should be recorded when:

* a control is absent;
* a control is poorly designed;
* a control is not implemented;
* a control does not operate effectively;
* evidence is insufficient; or
* the control no longer addresses the relevant risk.

***

### 23. Control Gap Assessment

Control gaps should be assessed for significance.

The assessment should consider:

* affected risk;
* likelihood;
* impact;
* classification;
* compensating controls;
* duration; and
* exposure.

***

### 24. Control Remediation

Material control gaps should result in remediation actions.

The remediation plan should identify:

* deficiency;
* required action;
* owner;
* priority;
* target date;
* expected outcome; and
* evidence of completion.

***

### 25. Compensating Controls

Where a primary control cannot be implemented immediately, a compensating control may be used where appropriate.

The compensating control should:

* address the relevant risk;
* be documented;
* have an accountable owner;
* be approved where required; and
* be reviewed periodically.

***

### 26. Control Exceptions

A control exception may be granted where an applicable control cannot reasonably be implemented or an approved alternative is used.

The exception should document:

* control;
* reason;
* risk;
* alternative measure;
* owner;
* approval;
* duration; and
* review date.

***

### 27. Control Waiver

A formal waiver should only be granted by an authorized authority.

A waiver should not be used to avoid risk assessment or governance requirements.

***

### 28. Control Dependencies

The assessment should identify material dependencies between controls.

Dependencies may include:

* security controls;
* privacy controls;
* data controls;
* infrastructure;
* third-party services;
* human oversight; and
* monitoring.

***

### 29. Automated Controls

Where controls are automated, the assessment should consider:

* configuration;
* reliability;
* system dependencies;
* change management;
* access;
* monitoring; and
* evidence generation.

***

### 30. Manual Controls

Where controls depend on human action, the assessment should consider:

* responsible personnel;
* competence;
* training;
* frequency;
* workload;
* documentation;
* escalation; and
* evidence.

***

### 31. Preventive Controls

Preventive controls should reduce the likelihood of an undesirable event occurring.

Examples may include:

* access restrictions;
* approval requirements;
* input validation;
* data restrictions;
* policy enforcement; and
* deployment gates.

***

### 32. Detective Controls

Detective controls should identify undesirable events or conditions.

Examples may include:

* monitoring;
* alerts;
* logging;
* testing;
* anomaly detection;
* review; and
* audit.

***

### 33. Corrective Controls

Corrective controls should support remediation after a failure or undesirable event.

Examples may include:

* rollback;
* remediation;
* model replacement;
* access removal;
* incident response; and
* corrective action.

***

### 34. Control Coverage

The control assessment should determine whether material risks are adequately covered.

The organization should identify:

* risks without controls;
* controls without identified risks;
* duplicated controls;
* weak controls; and
* control dependencies.

***

### 35. Control Prioritization

Control implementation should be prioritized according to:

* risk;
* classification;
* impact;
* regulatory requirements;
* implementation complexity;
* dependencies; and
* organizational priorities.

***

### 36. Control Baseline

The organization may establish control baselines for different AI System Profiles or classifications.

A baseline may define:

* mandatory controls;
* conditional controls;
* recommended controls;
* evidence requirements; and
* testing requirements.

***

### 37. Control Applicability Statement

Where appropriate, an AI system should maintain a control applicability statement.

The statement should identify:

* applicable controls;
* non-applicable controls;
* rationale;
* implementation status;
* exceptions; and
* evidence references.

***

### 38. Control Assessment Record

The control assessment record should contain, where applicable:

* AI system identifier;
* control identifier;
* control objective;
* risk reference;
* applicability;
* owner;
* implementation status;
* effectiveness rating;
* test result;
* evidence;
* deficiency;
* remediation; and
* review date.

***

### 39. Control Testing Frequency

Testing frequency should be proportionate to:

* risk;
* classification;
* control criticality;
* control volatility;
* incident history;
* regulatory requirements; and
* assurance requirements.

***

### 40. Control Monitoring

Controls should be monitored where appropriate.

Monitoring may identify:

* control failures;
* overdue activities;
* unusual behavior;
* policy violations;
* evidence gaps; and
* effectiveness changes.

***

### 41. Control Change Management

Changes to controls should be governed through appropriate change management.

Changes may include:

* control design;
* control owner;
* implementation method;
* frequency;
* technology;
* evidence requirements; and
* applicability.

***

### 42. AI Model Controls

Where relevant, control assessment should consider controls relating to:

* model selection;
* training;
* validation;
* testing;
* versioning;
* deployment;
* monitoring;
* drift;
* rollback; and
* retirement.

***

### 43. Data Controls

Where relevant, controls should address:

* data quality;
* data provenance;
* data access;
* data minimization;
* data retention;
* data security;
* data validation; and
* data usage restrictions.

***

### 44. Human Oversight Controls

Where human oversight is required, controls should address:

* assignment of responsibility;
* competence;
* review;
* intervention;
* override;
* escalation;
* workload; and
* documentation.

***

### 45. Security Controls

AI security controls may address:

* access;
* authentication;
* authorization;
* secrets;
* network security;
* model security;
* prompt injection;
* data protection;
* logging; and
* incident response.

***

### 46. Privacy Controls

Privacy controls may address:

* lawful processing;
* purpose limitation;
* data minimization;
* access;
* retention;
* disclosure;
* profiling;
* transparency; and
* privacy rights.

***

### 47. Third-Party Controls

Third-party AI controls should address relevant supplier risks.

These may include:

* due diligence;
* contractual requirements;
* security;
* privacy;
* service levels;
* provider changes;
* incident notification; and
* termination.

***

### 48. Control Assurance

Independent assurance should be considered for controls associated with higher-risk AI systems.

Assurance may include:

* internal audit;
* independent assessment;
* technical review;
* certification;
* testing; and
* external assurance.

***

### 49. Control Reporting

Control status should be reported to appropriate governance authorities.

Reporting may include:

* implementation status;
* effectiveness;
* deficiencies;
* overdue remediation;
* exceptions;
* failed tests; and
* emerging control risks.

***

### 50. Control Metrics

Organizations may establish control metrics.

Examples include:

* control implementation rate;
* control effectiveness;
* failed tests;
* overdue remediation;
* open exceptions;
* evidence completeness;
* testing completion; and
* repeat deficiencies.

***

### 51. Control Review

Controls should be reviewed periodically to determine whether they remain appropriate.

The review should consider:

* changes in risk;
* changes in technology;
* incidents;
* assurance findings;
* regulatory changes;
* control performance; and
* system changes.

***

### 52. Control Retirement

Controls may be retired when they are no longer applicable.

Retirement should consider:

* reason;
* affected risks;
* replacement controls;
* evidence;
* approval; and
* historical traceability.

***

### 53. Control Traceability

Control records should maintain traceability across the governance lifecycle.

The organization should be able to demonstrate:

**Requirement → Risk → Control → Owner → Evidence → Test → Result → Remediation**

***

### 54. Responsibilities

**AI System Owner**

* ensure applicable controls are addressed;
* support control implementation;
* notify material changes; and
* support remediation.

**Control Owner**

* implement the control;
* maintain evidence;
* monitor operation;
* address deficiencies; and
* support testing.

**AI Governance Function**

* maintain control governance;
* coordinate control assessment;
* oversee material deficiencies;
* manage exceptions; and
* report control status.

**Assurance Function**

* independently assess controls where required;
* report findings; and
* verify remediation.

***

### 55. Control Assessment Workflow

The standard workflow should be:

1. Identify assessment trigger.
2. Identify applicable requirements.
3. Map requirements to controls.
4. Determine control applicability.
5. Assign control owners.
6. Assess control design.
7. Assess implementation.
8. Collect evidence.
9. Test operating effectiveness where required.
10. Record deficiencies.
11. Define remediation.
12. Determine residual control risk.
13. Approve exceptions where required.
14. Report results.
15. Monitor and reassess.

***

### 56. Continuous Improvement

The control assessment process should be improved based on:

* control failures;
* incidents;
* assurance findings;
* audit findings;
* risk changes;
* regulatory developments;
* operational experience; and
* technology changes.

***

### 57. Procedure Review

This procedure should be reviewed periodically and when material changes occur.

Review triggers may include:

* changes to AIGO controls;
* changes to organizational control frameworks;
* new AI technologies;
* regulatory developments;
* significant incidents;
* assurance findings; and
* implementation experience.

Material changes should be versioned and approved according to applicable document governance requirements.

***

### 58. Procedure Status

**Document:** AIGO AI Control Assessment Procedure

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

**Document Identifier:** `AIGO-PROC-005`

**Document Type:** Operational Procedure

This procedure establishes the operational process for assessing and maintaining controls applicable to AI systems throughout their lifecycle under the AIGO framework.

***