AI Control Library / CF-01: Lifecycle Governance
Designation: Supplemental | Control types represented: Operational and Technical
A plan may look complete while relying on unavailable keys, incompatible backups or a provider that cannot meet the assumed timeline. Practical exercises expose recovery dependencies that paperwork alone misses.
Control requirement
Exercise AI disaster recovery plans against representative major failures, measuring restoration capability, dependency coordination and safe return to service. Record limitations and verify correction of critical failures.
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
Disaster plans for important AI services, with a mix of technical recovery and coordinated response exercises suited to risk.
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 disaster exercise lead coordinates; technical, security, supplier and business owners validate results and remediation.
Implementation guidance
- Select scenarios that challenge recovery assumptions, such as loss of a primary environment, identity outage or unusable recovery artifacts.
- Define measurable objectives, safe test boundaries, required participants and a clean-up plan before execution.
- Restore representative components and verify permissions, model behavior, data reconciliation and service dependencies, not infrastructure availability alone.
- Document actual recovery times and gaps, assign corrective actions and retest failed critical steps before accepting readiness claims.
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 |
|---|---|
| Execute a representative restoration | Measured outcomes meet approved criteria or produce explicit gaps. |
| Inspect recovered AI behavior and access | The restored service conforms to its approved baseline. |
| Trace a failed prerequisite | Corrective action is implemented and verified by retest. |
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
- Exercise scenario and safeguards
- Recovery timings and verification results
- Dependency and supplier observations
- Findings and retest records
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 failure to restore critical service safely to disaster and business owners. Adjust recovery commitments and interim service restrictions until capability is demonstrated.
Example in practice
Hypothetical example: An exercise restores model files quickly but cannot retrieve the encryption keys for the document store. Recovery is not marked successful; key access is corrected and the complete path is exercised again.
Related controls
Framework mappings
- CSA AICM (BCR-10)
- NIST AI RMF (MANAGE 4.1)
- 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