AI Control Library / CF-05: Data Governance & Privacy
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Generate cryptographic keys for AI using approved maintained mechanisms, appropriate strength and protected entropy sources. Control creation authority and ensure key material is not exposed through application code, logs or handling.
Why this matters
A strong algorithm cannot compensate for predictable or exposed keys. Generation needs trustworthy mechanisms and custody from the moment the key is created.
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
Encryption, wrapping and other relevant cryptographic keys created or imported for AI data and supporting services.
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-management owner defines generation standards; authorized operators use approved services and security verifies controls.
Implementation guidance
- Define approved key types, strengths, generation services and export restrictions for each purpose.
- Use validated or otherwise appropriately assured cryptographic mechanisms as required, avoiding application-made randomness or hardcoded key material.
- Restrict creation and import authority, record provenance and transfer imported keys through protected approved paths.
- Verify key metadata, allowed uses and custody, recording generation events without collecting the secret value as evidence.
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 a generated key | Approved service, purpose and strength are documented. |
| Review application and logging paths | Secret material is not exposed by generation or setup routines. |
| Attempt unauthorized creation or export | Access restrictions and required audit records operate. |
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 generation standard
- Service and authority configuration
- Generation and provenance metadata
- Export and exposure tests
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 weak or exposed generation to security and key owners. Stop using affected keys and assess the need for replacement and data protection review.
Example in practice
Hypothetical example: A developer proposes an application-generated encryption string. The platform instead provisions a key through the approved service and supplies only the authorized key reference to the workload.
Related controls
- CF05-S01: AI Encryption & Key Management Policy
- CF05-S08: AI Encryption Key Purpose Restriction
- CF04-S02: AI Key Lifecycle Audit Logging
Framework mappings
- CSA AICM (CEK-10)
- 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