AI Control Library / CF-01: Lifecycle Governance
Designation: Core | Control types represented: Operational and Technical
Reverting code may leave changed data, completed transactions or incompatible indexes behind. Restoration must account for the complete service and its consequences, including cases where containment is safer than a return to the prior version.
Control requirement
Provide a tested method to restore an AI system to an approved operating state after a failed or harmful change. Address models, configurations, retrieval state, permissions and downstream effects, and define when rollback is unsafe or insufficient.
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 define the process and decision authority; Technical controls enforce boundaries or produce the system evidence needed to verify it.
When it applies
Consequential AI changes and recovery decisions, including vendor updates where the prior model may no longer be available.
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 system owner sets restoration criteria; platform teams implement recovery and the designated authority approves resumed operation.
Implementation guidance
- Identify recoverable components, dependencies and changes that cannot be reversed; define a safe fallback when rollback is unavailable.
- Retain the approved prior baseline and compatible artifacts, access settings and recovery instructions.
- Test restoration with representative state and downstream dependencies; reconcile actions already completed by the failed version.
- Define rollback triggers, decision authority and post-restoration checks, including monitoring for recurrence or compatibility failures.
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 |
|---|---|
| Restore a failed release in a controlled environment | The approved service state and permissions are verified. |
| Include writes made after deployment | Completed effects are reconciled rather than assumed reversed. |
| Remove access to the old provider version in a scenario | An evaluated fallback or safe suspension path remains available. |
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
- Restoration procedure and triggers
- Retained baseline artifacts
- Recovery tests and reconciliation
- Authorization and post-restoration checks
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
Invoke incident response when rollback cannot contain ongoing harm. Use the approved fallback or suspend consequential functions; resume only after authority confirms restoration and residual effects.
Example in practice
Hypothetical example: A model update writes incorrect case tags. Restoring the prior model stops new errors, but recovery also identifies and corrects tags already written. The system is not declared restored merely because the model version has reverted.
Related controls
- CF01-012: AI System Baseline Management
- CF01-S11: AI System Backup
- CF01-S12: AI Disaster Response Plan
Framework mappings
- CSA AICM (CCC-09)
- NIST AI RMF (MANAGE 4.2)
- EU AI Act (Art. 9(2)(d))
- 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