AI Control Library / CF-05: Data Governance & Privacy
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Restrict cryptographic keys to approved purposes, workloads and operations, using enforceable authorization and separation where appropriate. Prevent unrelated uses from inheriting authority merely because a workload can reference the key.
Why this matters
Reusing a key across unrelated data or operations can widen the effects of misuse and complicate retirement. Purpose restrictions must apply to the service calls, not just a descriptive key name.
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
Keys protecting AI data and services, including wrapping, storage, backup and other cryptographic uses governed by the approved architecture.
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 approves use; identity and platform teams enforce scope and security reviews exceptions.
Implementation guidance
- Record the key’s purpose, protected assets, permitted identities and allowed cryptographic operations.
- Configure service policies and available context restrictions, separating incompatible purposes and environments as required.
- Prevent broad grants and unmanaged application reuse, reviewing delegated or service-issued permissions.
- Test disallowed operations and access from unrelated workloads, then reassess when integrations or key scope change.
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 |
|---|---|
| Call the key from an unrelated identity in a controlled test | Authorization denies the operation. |
| Attempt an unapproved cryptographic operation | Purpose or service restrictions prevent it. |
| Inspect a new grant | Its scope and asset relationship match owner approval. |
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 purpose and asset register
- Policy and grant configuration
- Negative authorization tests
- Use and exception reviews
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 unauthorized key use or scope expansion to security and the key owner. Revoke excessive grants and assess affected data without assuming renaming a key corrects its authorization.
Example in practice
Hypothetical example: A testing service attempts to use a production document key. Environment and identity restrictions deny access even though both workloads belong to the same organization.
Related controls
- CF05-S02: AI Encryption Roles & Responsibilities
- CF05-S07: AI Encryption Key Generation
- CF05-S16: AI Encryption Key Inventory Management
Framework mappings
- CSA AICM (CEK-11)
- 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