AI Control Library / CF-04: Auditability & Evidence
Designation: Core | Control types represented: Operational and Technical
Control requirement
Maintain sufficiently reliable time references across AI event sources and logging infrastructure to support the required correlation and investigation. Monitor clock offset, preserve time semantics and document uncertainty where sources cannot be synchronized.
Why this matters
Events can appear out of order because source clocks differ or collection is delayed. A consistent time zone alone does not ensure accuracy, and receipt time must not be mistaken for the time an action occurred.
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
Application hosts, containers, tool services, collectors and external event sources used to reconstruct AI activity and interventions.
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 infrastructure time-service owner manages synchronization; observability teams define event timing and investigators account for known uncertainty.
Implementation guidance
- Define acceptable timing error and event-ordering needs from the workflow’s risk and investigation requirements rather than a universal threshold.
- Use approved reliable time sources and supported synchronization mechanisms, protecting configuration and monitoring material offset or source failure.
- Preserve source event time and collection or observation time where available, including time zone, source identity and precision limitations.
- Test correlation under offset, delay and restart scenarios; use identifiers and sequence evidence where timestamps alone cannot establish order.
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 |
|---|---|
| Introduce controlled clock offset | Monitoring detects the difference and flags affected timing confidence. |
| Delay collection of an event | The record distinguishes occurrence and observation rather than rewriting the sequence. |
| Correlate an external provider event | Its time assumptions and uncertainty are retained in the investigation. |
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
- Time-source and synchronization configuration
- Offset and source-health records
- Event timestamp specification
- Correlation and failure 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 material timing uncertainty to infrastructure and monitoring owners. Qualify affected ordering claims, use alternative evidence and restrict time-dependent automated responses where reliable operation cannot be supported.
Example in practice
Hypothetical example: A tool completion arrives after an emergency-stop event but carries an earlier source timestamp. Review uses both timestamps and request identifiers before deciding whether the tool acted after the stop was enforced.
Related controls
- CF04-008: AI System Logging Scope & Event Definition
- CF04-013: AI Monitoring System Failure Reporting
- CF04-014: AI Decision Record & Traceability
Framework mappings
- CSA AICM (LOG-06)
- NIST AI RMF (MANAGE 4.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.
Technical reference: OpenTelemetry Logs Data Model, including separate event and observation timestamps.
Back to Auditability & Evidence
Version 1.0