AI Control Library / CF-01: Lifecycle Governance
Designation: Core | Control types represented: Governance and Operational
A framework name in a crosswalk does not establish compliance. Obligations depend on the organization’s role, jurisdiction, system purpose and relevant dates; broad associations can hide unmet requirements.
Control requirement
Maintain a versioned register of AI-related external obligations and chosen standards, with documented applicability, accountable owners and links to supporting controls and evidence. Distinguish binding requirements from voluntary guidance and internal policy choices.
Why this matters
The control is effective when its required decisions and safeguards can be demonstrated in the actual workflow. An approved document or completed form alone is insufficient if the described actions are not performed.
How the control types work together
Governance controls establish binding external rules. Operational controls determine applicability, translate obligations into work and maintain evidence.
When it applies
AI systems and services subject to legal, regulatory, contractual or adopted-standard requirements across their actual operating locations.
Tailor depth and review frequency to potential impact, system authority and uncertainty. Document the reason for any exclusion; a supplemental designation does not make an otherwise applicable safeguard optional.
Ownership
Legal or compliance validates applicability; the AI program lead maintains mappings and system owners supply implementation evidence.
Implementation guidance
- Inventory jurisdictions, organizational roles, intended uses and contractual commitments; identify the primary text and version for each obligation.
- Record applicable provisions, scope, effective dates and reasons for exclusion; have qualified reviewers resolve interpretation and uncertainty.
- Map each obligation to specific controls and evidence, explaining whether the relationship is direct, partial or supporting; record gaps explicitly.
- Monitor authoritative changes and trigger reassessment when obligations, system roles or deployment locations change; preserve historical decisions.
How to verify it
Use a representative sample of actual records or an authorized controlled exercise. A reviewer with suitable expertise should compare observed practice with the approved scope and acceptance criteria.
| Test | Expected result |
|---|---|
| Inspect a binding requirement | Its applicability rationale, authoritative source and responsible owner are recorded. |
| Trace a partial mapping | Uncovered elements remain visible with a treatment decision. |
| Change a deployment jurisdiction in a review scenario | Applicability is reassessed before the new use begins. |
Record a finding when a required result is absent, evidence cannot substantiate the claim, or practice differs materially from the approved conditions. An exception may record accepted risk, but does not turn a failed safeguard into an effective one.
Evidence to retain
- Obligation and standards register
- Applicability decisions
- Reviewed mappings and gap records
- Change-monitoring history
Protect evidence according to its sensitivity and approved retention requirements. Retain enough detail to substantiate the assessment without unnecessarily duplicating confidential or personal information.
If the control fails
Escalate unresolved applicability or conflicting duties to legal and the accountable risk owner. Restrict affected deployment where required conditions cannot be demonstrated; do not assume an internal exception waives an external duty.
Example in practice
Hypothetical example: A supplier labels a product “AI compliant.” The buyer instead records its own deployment role and use, checks the applicable obligations and identifies required evidence that the supplier’s generic claim does not provide.
Related controls
- CF01-002: AI Risk Management Program
- CF01-004: Policy Exception Process
- CF01-016: AI Model Documentation Requirements
Framework mappings
- CSA AICM (GRC-07)
- NIST AI RMF (GOVERN 1.1)
- EU AI Act (Art. 9(2)(b))
- ISO 42001 (Cl. 4.2)
Review and maintenance
Review at the interval approved by the control owner and after a material change, relevant incident or failed assessment. Reassess the affected scope, update records and verify corrective actions before closing findings.
Version 1.0