AI Control Library / CF-05: Data Governance & Privacy
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Control changes to AI encryption and key-management configurations through impact analysis, authorization, testing and recovery planning. Include policies, service identities, key references, algorithms and provider settings.
Why this matters
A small key-policy change can expose data or interrupt every dependent service. Encryption changes need evaluation of actual access and recovery rather than a syntax-only configuration check.
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
Cryptographic configurations and dependencies supporting AI, including migrations and changes performed by suppliers.
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 encryption service owner coordinates; security and affected service owners approve risk and release conditions.
Implementation guidance
- Identify changed keys, permissions, protection settings and dependent workloads, including backups and scheduled processing.
- Assess exposure, availability, compatibility and recovery impact, using a representative nonproduction environment where feasible.
- Approve the exact candidate configuration and execute through a controlled path with protected activity records.
- Verify protection and authorized access after the change, detecting drift and invoking approved restoration when criteria fail.
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 |
|---|---|
| Change key access in an authorized test | Required users retain access and unapproved identities do not gain it. |
| Inspect release evidence | Security and availability tests precede consequential implementation. |
| Exercise restoration | The prior safe state is achievable without silently reintroducing compromised access. |
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
- Encryption change and dependency analysis
- Approval and test evidence
- Deployment activity records
- Post-change verification and recovery results
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 unintended access or service failure to security and change authorities. Contain exposure and restore an approved state after assessing whether prior keys or permissions remain trustworthy.
Example in practice
Hypothetical example: A storage encryption migration updates the primary service but initially omits a batch processor. Pre-release testing reveals the dependency and prevents a production outage.
Related controls
- CF01-009: AI Change Management Policy & Procedures
- CF01-013: AI System Rollback & Restoration
- CF05-S16: AI Encryption Key Inventory Management
Framework mappings
- CSA AICM (CEK-05)
- 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