AI Control Library / CF-05: Data Governance & Privacy
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Control key lifecycle states and transitions, including activation, suspension and deactivation, with defined authority, permitted operations and dependency checks. Verify that service behavior matches the intended state.
Why this matters
A key can exist without being authorized for new encryption, or be retained only for processing historical data. Lifecycle labels need operational meaning rather than being treated as interchangeable on/off settings.
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
AI cryptographic services and their key versions, where supported state transitions affect new protection, existing-data access and recovery.
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-management owner defines transitions; authorized operators execute them and service owners validate impact.
Implementation guidance
- Define key states and allowed operations according to the key type and service, including temporary suspension and historical-use conditions.
- Assign transition authority, approval, audit and dependency requirements, with emergency handling for compromise.
- Implement supported state and policy controls, checking how applications, caches and version references behave.
- Test permitted and denied operations after transitions and reconcile actual state with the inventory and recovery requirements.
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 |
|---|---|
| Activate a prepared test key | Only approved identities and purposes gain the intended capability. |
| Suspend or deactivate it | Observed operations match the defined state and service limits. |
| Resume use where permitted | Authorization and integrity checks precede the transition. |
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
- Lifecycle state and transition model
- Approval and service configuration
- State-operation tests
- Inventory and recovery reconciliation
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 unauthorized transitions or unexpected operation in a restricted state to security and key owners. Contain dependent access and correct the state or service policy.
Example in practice
Hypothetical example: A rotated key remains authorized to decrypt historical documents but not protect new ones. Testing verifies both behaviors rather than assuming a generic inactive label has the desired meaning.
Related controls
- CF05-S08: AI Encryption Key Purpose Restriction
- CF05-S09: AI Encryption Key Rotation
- CF05-S10: AI Encryption Key Revocation
Framework mappings
- CSA AICM (CEK-15, CEK-16, CEK-17)
- 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