AI Control Library / CF-04: Auditability & Evidence
Designation: Core | Control types represented: Operational and Technical
Control requirement
Define and implement the event scope and schema needed to reconstruct relevant AI activity across application, model, tool and human boundaries. Establish identifiers, source attribution, outcomes and coverage tests for required events.
Why this matters
Without consistent event definitions, one component may report a proposed action while another reports only completion. Investigation needs to distinguish intention, authorization, attempt, result and failure without assuming these are the same event.
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
AI workflows requiring traceability, including retrieval, delegated agents, tools, human approvals, administrative changes and provider interactions.
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 defines coverage with security and assurance reviewers; engineering implements schemas, propagation and collection.
Implementation guidance
- Map the workflow and identify consequential decisions, permission checks, retrievals, tool calls, approvals and changes requiring events.
- Specify fields for event type, source, actor, system version, correlation, timing, outcome and relevant references, minimizing content exposure.
- Propagate request and delegation identifiers through relevant boundaries, recording failed, denied and abandoned actions as well as successes.
- Test event coverage and schema interpretation under normal operation, retries, partial failure and material workflow changes.
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 |
|---|---|
| Reconstruct a representative tool action | Proposal, authorization, execution and outcome are distinguishable where required. |
| Exercise a denied or retried request | Records preserve the attempt and relationship without counting a retry as a separate completed business action. |
| Trace delegated work | Correlation identifies the child activity and responsible identities across the assessed boundary. |
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
- Event coverage map and schema
- Identifier and propagation design
- Representative event records
- Coverage and failure-path 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 missing consequential events or ambiguous attribution to engineering and the system owner. Limit affected assurance conclusions or action-taking capability until required visibility is established.
Example in practice
Hypothetical example: An agent proposes a payment that policy denies. Separate proposal and denial events prevent a reviewer from interpreting generated payment details as evidence that money was actually transferred.
Related controls
- CF04-007: AI Logging & Monitoring Policy
- CF04-014: AI Decision Record & Traceability
- CF09-011: Agentic System Action Monitoring
Framework mappings
- CSA AICM (LOG-07, LOG-08)
- NIST AI RMF (MANAGE 4.1)
- EU AI Act (Art. 12(1))
- ISO 42001 (Cl. 9.1)
- OWASP LLM Top 10
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 Auditability & Evidence
Version 1.0