AI Control Library / CF-05: Data Governance & Privacy
Designation: Supplemental | Control types represented: Operational
Control requirement
Assign accountable roles for encryption and key lifecycle activities, separating sensitive powers where appropriate and providing authorized coverage for routine and emergency actions.
Why this matters
A key-management console can give one person the ability to grant access, delete keys and alter evidence. Responsibilities must address both misuse and the availability risks of unavailable custodians.
How the control types work together
Operational controls establish the assigned responsibilities, review processes and response decisions described here. Their effectiveness depends on performing the work and using evidence to guide action, rather than approving a document alone.
When it applies
AI encryption configuration, key administration, data use, approvals, monitoring and recovery across internal and provider roles.
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 security owner approves the model; key-service and business owners assign operators, approvers and deputies.
Implementation guidance
- Map generation, use, access grants, rotation, revocation, destruction and recovery to accountable and performing roles.
- Separate high-impact approval and execution where risk warrants it, including protected emergency access.
- Define provider duties, customer responsibilities and reachable deputies, ensuring access matches assigned authority.
- Review assignments after role or service changes and verify that critical actions remain possible without granting unnecessary standing privilege.
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 |
|---|---|
| Inspect destructive authority | Approval and execution follow the defined separation. |
| Exercise absence of a primary custodian | Authorized coverage supports the required response. |
| Review a role change | Obsolete key access is removed and responsibility transfers. |
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
- Cryptographic responsibility matrix
- Approvals and role configuration
- Coverage and emergency-access tests
- Access review and handover 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 unowned actions or excessive privilege to security and service owners. Limit sensitive authority and establish approved coverage before relying on the arrangement.
Example in practice
Hypothetical example: A data owner authorizes key retirement while a separate operator executes it. Recovery and compromise response have named alternates so separation does not make emergency intervention impossible.
Related controls
- CF05-S01: AI Encryption & Key Management Policy
- CF05-S12: AI Encryption Key Lifecycle Management (Activation/Suspension/Deactivation)
- CF04-S02: AI Key Lifecycle Audit Logging
Framework mappings
- CSA AICM (CEK-02)
- 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