AI Control Library / CF-05: Data Governance & Privacy
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Maintain a current inventory of AI cryptographic keys and relevant versions, purposes, owners, states, locations, authorized identities and protected assets without exposing the secret material itself.
Why this matters
Without dependency records, rotation and deletion can cause outages or leave data beyond the intended control boundary. Inventory connects lifecycle decisions to real services and retained information.
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, logs, artifacts, transfers and backups across organizational and provider-managed arrangements.
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 maintains records; service and data owners confirm asset relationships and lifecycle needs.
Implementation guidance
- Record key identifiers, type, purpose, owner, service, lifecycle state and approved operations with appropriate sensitivity.
- Link versions to workloads, stores, backups, archived data and delegated grants, identifying provider visibility limits.
- Reconcile the register against approved key services, configuration and actual use, detecting unmanaged or orphaned keys.
- Update after lifecycle transitions and retirement, retaining history needed to explain past protection and access.
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 protected asset | Its active and required historical key dependencies are identifiable. |
| Inspect an observed key operation | The key and authorized purpose appear in the inventory. |
| Propose destruction or rotation | The inventory supports impact assessment across dependent services. |
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 and version inventory
- Asset and authorization relationships
- Service reconciliation results
- Lifecycle and retirement history
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 unknown keys, unclear owners or missing dependencies to security and service authorities. Hold irreversible lifecycle actions until affected data and services are understood.
Example in practice
Hypothetical example: A key marked unused still protects an infrequently accessed archive. Inventory reconciliation identifies the dependency before an automated cleanup job schedules irreversible removal.
Related controls
- CF05-S02: AI Encryption Roles & Responsibilities
- CF05-S09: AI Encryption Key Rotation
- CF05-S11: AI Encryption Key Destruction
Framework mappings
- CSA AICM (CEK-21)
- 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