AI Control Library / CF-05: Data Governance & Privacy
Designation: Core | Control types represented: Operational
Control requirement
Document how information moves through AI workflows, identifying collection, transformation, storage, retrieval, model calls, tool actions, logging, supplier processing and disposal boundaries. Keep the representation aligned with actual operation.
Why this matters
An architecture diagram can show components without revealing which data leaves the organization or where copies persist. Data-flow documentation should support specific privacy, security and operational decisions.
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 workflows processing organizational data, including external assistants, multi-provider applications and delegated agent tools.
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 system owner maintains the flow with engineering, data stewards and privacy or security reviewers.
Implementation guidance
- Map relevant inputs, outputs and intermediates, identifying sensitivity, purpose and processing at each stage.
- Record identities, trust boundaries, destinations, regions, transfers and retention points, including observability and support paths.
- Validate the map against configuration and authorized traces rather than relying only on intended design.
- Revise it after material changes and use it in impact assessments, supplier review, incident handling and deletion planning.
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 non-sensitive test request | Observed material destinations match the documented flow. |
| Inspect a logging or support path | Data content, recipient and retention are identified. |
| Review a connector change | The map and affected handling decisions are updated before expanded use. |
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
- Versioned data-flow map
- Data-category and trust-boundary annotations
- Configuration and trace comparisons
- Review and change records
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 undocumented sensitive transfers or unclear processing to system, privacy and security owners. Suspend the affected path until its purpose and handling can be assessed.
Example in practice
Hypothetical example: A model service uses a second API for translation. Flow tracing reveals that the original language content crosses an additional supplier boundary omitted from the application diagram.
Related controls
- CF05-002: AI Data Inventory
- CF03-012: AI Supply Chain Data Security Assessment
- CF05-018: AI Data Sub-processing Controls
Framework mappings
- CSA AICM (DSP-05)
- NIST AI RMF (MAP 1.1)
- EU AI Act (Art. 10, Art. 13)
- ISO 42001 (Cl. 8.2, A7.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