AI Control Library / CF-05: Data Governance & Privacy
Designation: Supplemental | Control types represented: Operational
Control requirement
Assess and manage risks in AI encryption and key arrangements, including access, algorithm or service support, protection lifetime, key compromise, dependency failure and recovery. Link treatment to the relevant data and workloads.
Why this matters
Encryption can be strong while key access or recovery is weak. Risk review must consider the complete protection arrangement and the time information needs confidentiality, not a product’s encryption label alone.
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 cryptographic services and data paths, including long-lived records, external key services and shared provider dependencies.
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 cryptographic risk owner assesses with security and service specialists; business owners accept residual exposure.
Implementation guidance
- Map data sensitivity, confidentiality lifetime, keys, identities and cryptographic dependencies.
- Assess compromise and availability scenarios, maintenance support, key custody and relevant technology-transition needs.
- Evaluate existing protections and evidence, assigning treatment for weak access, unsupported services or untested recovery.
- Review risks after material cryptographic changes, incidents and changed information lifetime or dependency conditions.
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 |
|---|---|
| Trace a sensitive workload | Its key and recovery risks are evaluated together. |
| Inspect an unsupported protection component | Treatment and an accountable deadline exist. |
| Review a new dependency or incident | The risk decision is reassessed before prior acceptance is reused. |
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 risk assessment
- Dependency and data-lifetime analysis
- Treatment and acceptance records
- Review and recovery evidence
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 material risk outside tolerance to security and business authorities. Restrict affected use or migrate through an approved plan while interim safeguards operate.
Example in practice
Hypothetical example: An archive needs confidentiality well beyond the current service contract. The assessment considers long-term key access and protection transitions rather than assuming today’s provider setting covers the entire retention period.
Related controls
- CF05-S01: AI Encryption & Key Management Policy
- CF05-S04: Encryption Change Cost-Benefit Analysis
- CF05-S14: AI Encryption Key Compromise Response
Framework mappings
- CSA AICM (CEK-07)
- NIST AI RMF (MAP 1.1)
- ISO 42001 (Cl. 6.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