AI Control Library / CF-05: Data Governance & Privacy
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Revoke cryptographic key use or related access when authority ends or security requires it, verifying effects across grants, cached material and dependent services. Distinguish revocation from destruction and deletion of existing data.
Why this matters
Revoking a key grant may not invalidate plaintext already obtained or every cached data key. Effective containment depends on the actual service architecture and the precise authority being removed.
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
Key access termination, incident response and service retirement across AI workloads and provider integrations.
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 authorizes revocation; security and platform teams execute containment and service owners manage impact.
Implementation guidance
- Define revocation triggers and authority, identifying key, grant, identity and service relationships.
- Assess propagation, caches, outstanding jobs and recovery consequences before routine revocation; use emergency containment when warranted.
- Revoke relevant authority through approved mechanisms and block dependent access paths as needed.
- Test effective denial and residual access, preserving audit evidence and documenting whether restoration or permanent retirement is intended.
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 |
|---|---|
| Revoke access for a test workload | New unauthorized operations are denied within the approved conditions. |
| Inspect cached or delegated access | Residual capability is assessed rather than assumed absent. |
| Review restoration | It requires a new authorized decision and appropriate trust checks. |
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
- Revocation triggers and approvals
- Key and grant dependency records
- Denial and residual-access tests
- Containment and restoration 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 persistent unauthorized access to security and service owners. Apply independent identity or workload isolation where key revocation alone does not contain exposure.
Example in practice
Hypothetical example: An agent’s key-service grant is removed, but its running worker has decrypted data in memory. The response also stops the worker rather than treating grant revocation as removal of every existing copy.
Related controls
- CF05-S06: Customer-Managed Encryption Keys for AI
- CF05-S12: AI Encryption Key Lifecycle Management (Activation/Suspension/Deactivation)
- CF05-S14: AI Encryption Key Compromise Response
Framework mappings
- CSA AICM (CEK-13)
- 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