AI Control Library / CF-05: Data Governance & Privacy
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Provide authorized recovery of keys needed for AI service continuity and retained-data access, using protected recovery material and tested procedures. Tailor recovery to key purpose and security state rather than recovering every key indiscriminately.
Why this matters
A backup is unusable if its required decryption key cannot be restored. Recovery can also reintroduce compromised material or give custodians broader authority than the original control allowed.
How the control types work together
Operational controls define scope, authority and the actions required when conditions are not met. Technical controls produce evidence or enforce the relevant boundaries. Both must apply to the same deployment and operating conditions.
When it applies
Keys with justified recoverability needs, especially data-decryption or wrapping keys and relevant managed-service dependencies.
Define the assessed boundary, dependencies and evidence limitations. Tailor depth and review frequency to potential impact, and document why a particular safeguard or exclusion is appropriate to the actual deployment.
Ownership
The key and continuity owners establish the capability; custodians execute recovery under the required approval and separation.
Implementation guidance
- Define recoverable key types, objectives and authorization, excluding cases where recovering secret material would contradict the security purpose.
- Protect backups or recovery mechanisms with appropriate separation, custody and access, retaining necessary metadata and dependencies.
- Exercise recovery in a controlled environment, verifying the key’s trust state and ability to access the intended data.
- Record recovery actions and reconcile versions, privileges and temporary access before returning services to normal operation.
How to verify it
Use representative records and authorized controlled tests. Identify the relevant version, operating conditions and expected result before testing, and retain enough evidence to support the conclusion.
| Test | Expected result |
|---|---|
| Recover a representative retained-data key | Authorized data access is restored within approved recovery conditions. |
| Attempt unauthorized recovery | Approval and technical restrictions prevent it. |
| Review a compromised-key scenario | Recovery does not silently restore untrusted operational use. |
Record a finding when required results cannot be demonstrated or practice differs materially from the approved conditions. Missing evidence limits the conclusion; it should not be treated as a successful test.
Evidence to retain
- Recovery scope and authority
- Protected recovery arrangement
- Recovery and trust-state tests
- Access reconciliation and approval records
Protect evidence according to its sensitivity, access needs and retention rules. Avoid unnecessary copies of personal information, secrets or confidential material, while preserving the records needed for authorized review.
If the control fails
Escalate failed or unauthorized recovery to security and continuity owners. Use the approved reduced-service route while a trusted recovery or data-loss decision is established.
Example in practice
Hypothetical example: A recovery drill restores an encrypted retrieval store and its required key under controlled access. Temporary operator grants are removed after the service owner verifies the result.
Related controls
- CF05-S13: AI Encryption Key Archival
- CF05-S14: AI Encryption Key Compromise Response
- CF01-S11: AI System Backup
Framework mappings
- CSA AICM (CEK-20)
- 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 relevant changes, incidents or failed assessments. Update affected procedures and configuration, address evidence gaps and verify corrective action before closing findings.
Back to Data Governance & Privacy
Version 1.0