AI Control Library / CF-05: Data Governance & Privacy
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Rotate AI cryptographic keys according to approved risk-based cryptoperiods and event triggers, preserving authorized access and verifying protection of new and retained data. Distinguish key replacement from re-encryption or rewrapping.
Why this matters
Rotating a key may change future writes without changing existing ciphertext. The organization must understand version behavior, old-key access and recovery before reporting that retained information now uses the replacement protection.
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 used by AI stores, integrations and backups where rotation is required, supported and appropriate to purpose.
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 owner approves rotation policy; platform operators execute and service owners verify dependent workloads.
Implementation guidance
- Define rotation intervals and triggers by key type, exposure and data lifetime, with emergency paths for suspected compromise.
- Map dependent services and version behavior, identifying data that requires re-encryption, rewrapping or continued old-key access.
- Test and authorize rotation, coordinating caches, schedules and recovery needs.
- Verify new operations use the approved key version and retained data remains appropriately protected and accessible before retiring older keys.
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 |
|---|---|
| Rotate a test key | New writes use the intended version and authorized reads still work. |
| Inspect older ciphertext | Its key dependency and treatment are understood. |
| Test an overlooked batch or recovery path | Rotation does not silently leave required processing broken. |
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
- Rotation policy and dependency plan
- Change approval and execution
- Version and retained-data verification
- Recovery and retirement decisions
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 rotation or unexplained old-key use to key and service owners. Contain exposure and choose an approved recovery path, avoiding unreviewed deletion of keys still needed for retained data.
Example in practice
Hypothetical example: A storage service rotates its wrapping key but does not rewrite existing objects. Verification records which data still depends on older versions and tests access before any retirement decision.
Related controls
- CF05-S03: AI Encryption Change Management
- CF05-S10: AI Encryption Key Revocation
- CF05-S13: AI Encryption Key Archival
Framework mappings
- CSA AICM (CEK-12)
- NIST AI RMF (MAP 1.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