AI Control Library / CF-05: Data Governance & Privacy
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Evaluate and, where appropriate, implement customer-managed keys for AI services with clear scope, authority, availability and recovery. Verify what customer key control changes and what remains accessible to the provider during authorized processing.
Why this matters
Customer-managed keys can improve control over certain stored data, but may not cover every service component or prevent a provider from processing plaintext. Revocation can also disrupt service without removing existing plaintext or every copy.
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 services offering customer-controlled key integration, including external-key arrangements when supported and justified.
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 data and service owners approve the arrangement; security and key-service operators implement and verify it.
Implementation guidance
- Identify the protection objective and service components covered, including replicas, logs, derived stores and backups.
- Define key custody, provider grants, administrative authority and separation, checking actual service behavior rather than branding.
- Assess key-service outage, revocation, rotation and recovery effects on data access and availability.
- Test authorized use and loss of key availability with representative workloads, documenting scope limits and operational response.
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 coverage | Evidence identifies protected components and exclusions. |
| Revoke or suspend access in a controlled test | Observed service effects match the approved objective and limitations. |
| Test recovery | Authorized access can be restored without granting broader permanent privilege. |
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
- Key-ownership and coverage decision
- Grant and integration configuration
- Revocation and outage tests
- Recovery and limitation 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 unexpected provider access or loss of availability to security and service owners. Adjust grants, contain the affected path and restore only under approved conditions.
Example in practice
Hypothetical example: A hosted model service supports a customer key for stored files but not every diagnostic record. The buyer restricts diagnostics separately instead of claiming that key ownership protects all service data.
Related controls
- CF05-017: AI Data Encryption at Rest & in Transit
- CF05-S10: AI Encryption Key Revocation
- CF05-S15: AI Encryption Key Recovery
Framework mappings
- CSA AICM (CEK-08)
- NIST AI RMF (MAP 1.1)
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