AI Control Library / CF-01: Lifecycle Governance
Designation: Supplemental | Control types represented: Operational
A provider can alter behavior without changing the customer’s application code. Unclear change responsibilities leave customers unable to assess impacts or coordinate recovery.
Control requirement
Establish agreements for AI changes involving internal customers, providers or partners, defining change categories, notification, review rights, testing responsibilities, compatibility expectations and escalation when changes affect the service.
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
Operational controls provide the policies, decisions and recurring processes described here.
When it applies
AI services with changes controlled or implemented by another team or external organization, including managed and hosted models.
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
The service owner is accountable; procurement, legal and technical owners establish and maintain the agreed change arrangements.
Implementation guidance
- Identify parties able to change models, data processing, functionality, integrations or operating conditions.
- Agree which changes require notice, approval, evaluation or coordinated scheduling; distinguish enforceable commitments from provider practices.
- Define evidence exchange, version support, rollback limits and response paths when an unplanned change occurs.
- Verify that notification channels work and reassess agreements when the provider or deployment role changes.
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 material supplier update | The agreed notification and assessment path is followed. |
| Test the designated contacts | Responsible parties receive and acknowledge the notification. |
| Review an unavailable rollback option | The customer has a documented evaluated fallback or restriction. |
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
- Change agreements and service schedules
- Responsibility and contact records
- Notifications and assessments
- Provider limitation decisions
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 unannounced material change to the service owner and supplier contact. Assess impact and restrict affected reliance where behavior no longer matches the approved conditions.
Example in practice
Hypothetical example: A hosted classifier retires an older version. The agreement provides an evaluation window, but the buyer still tests the replacement and defines manual processing if acceptance criteria are not met.
Related controls
- CF01-009: AI Change Management Policy & Procedures
- CF01-013: AI System Rollback & Restoration
- CF03-007: AI Supply Chain Contractual Requirements
Framework mappings
- CSA AICM (CCC-05)
- NIST AI RMF (MANAGE 4.2)
- ISO 42001 (Cl. 8.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