Evidence and audit trails: how a control becomes provable
An audit trail records what happened; evidence is the proof a control works.
An audit is an independent review and examination of records and activities to assess the adequacy of system controls and to ensure compliance with policy. The thing it examines is the audit trail: a record of who accessed a system and what they did. But the record is not the proof. A log entry becomes evidence only when it says what happened, when and by whom, is protected from change, is kept as long as it may be needed, and is actually read. This sheet is about generating a record versus defending a claim with it — a governance question, not a logging configuration.
The model: from an event to a defensible claim
event in a system
↓
audit record (what, when, where, source, outcome, who)
↓
protected, time-sourced storage (cannot be altered or deleted quietly)
↓
retention (kept for as long as the investigation may need it)
↓
review (someone reads and analyses it)
↓
defensible claim ("the control operated — here is how we know")Each link is a condition. An event is an observable occurrence in a system; the audit record is what the system writes about it; the audit trail is those records over time. Break any one link — a record with no time, an unprotected store, an expired archive, a review that never happens — and what is left is data, not evidence.
What an audit is, and the control set it names
SP 800-12 Rev. 1 §10.3 defines an audit as “an independent review and examination of records and activities to assess the adequacy of system controls and ensure compliance with established policies and operational procedures”. It defines an audit trail, separately, as “a record of individuals who have accessed a system as well as what operations the user has performed during a given period”. The trail is the trace the system produces; the audit is the examination performed on it.
The section names the controls that make the trail usable — audit events, time stamps, non-repudiation, protection of audit information, audit record retention and session audit — and states the purpose: create, protect and retain audit records to monitor, analyse, investigate and report unlawful, unauthorised or inappropriate activity, and make sure individual users’ actions are uniquely traceable to them so they can be held accountable.
Log management is a process, not a product
SP 800-92 defines log management as “the process for generating, transmitting, storing, analyzing, and disposing of computer security log data”. Generating the record is one of five verbs; the other four carry as much governance weight as the first. The same guide says why records exist: routine analysis is “beneficial for identifying security incidents, policy violations, fraudulent activity, and operational problems”, and logs also serve auditing, forensics, internal investigations, baselines and compliance with legislation. Its recurring difficulty is protecting logs’ confidentiality, integrity and availability, and reconciling sources whose formats and timestamps disagree.
The conditions a record must satisfy to serve as evidence
SP 800-53 Rev. 5 turns the same idea into controls, each mapping to a condition an audit record must meet before it supports a claim.
| Control | Condition | What it buys the claim |
|---|---|---|
| AU-2 Event Logging | Events to log are selected, coordinated with those who need audit information, justified as adequate for after-the-fact investigation, and reviewed | the record captures the events that matter, and the choice can be defended |
| AU-3 Content of Audit Records | What happened, when, where, source, outcome, and the identity associated with it | a record that can actually answer a question |
| AU-9 Protection of Audit Information | Audit information and the logging tools are protected from unauthorised access, modification and deletion, with an alert on detection | a record no one can quietly change |
| AU-11 Audit Record Retention | Retained for an organisation-defined period consistent with records-retention policy, to support after-the-fact investigations | the record still exists when it is needed |
| AU-12 Audit Record Generation | The generation capability exists on the system components that must produce it | the mechanism is present, not assumed |
Two consequences follow. “When” is a condition in its own right: an event with no reliable time, or sources whose clocks disagree, cannot be placed in sequence. And retention is a decision, not a constant — SP 800-53 leaves the period as an organisation-defined value tied to records-retention policy and to the investigations and legal or regulatory purposes the records may serve. There is no universal number.
The common misconception: “we have logs, so we have evidence”
Generating logs and holding evidence are two different states, and the gap between them is where most programmes are weak. SP 800-92 observes that log analysis is often treated as reactive — done after a problem is found by other means — and that “without sound processes for analyzing logs, the value of the logs is significantly reduced”. A trail that is never reviewed, stored where it can be altered, or deleted before the investigation reaches it proves nothing.
The second half of the misconception is that evidence is a screenshot for the auditor. The auditor reads the trail the system produced, not a picture taken at audit time.
What makes a claim defensible
SP 800-53A Rev. 5 treats this as building an assurance case: compiling evidence that the controls are “implemented correctly, operating as intended, and producing the desired outcome”. An assurance case is “a body of evidence organized into an argument demonstrating that some claim about a system holds” — an argument with evidence attached, not an assertion. CIS Control 8 states the same expectation in one line: “Collect, alert, review, and retain audit logs of events that could help detect, understand, or recover from an attack.”
What to remember
- An audit is an independent review of records and activities; the audit trail is the record it examines.
- Log management is a process — generating, transmitting, storing, analysing, disposing — not a switch.
- A record becomes evidence only if content, time, protection, retention and review conditions hold.
- “We have logs” is not “we have evidence”: an unanalysed, unprotected or expired trail supports no claim.
Level and prerequisites
L1 — the concepts of audit, audit trail and evidence, and the conditions a record must satisfy; no procedure, no configuration and no retention figure. Prerequisites: none.
Where to go next
- Cybersecurity Governance — the area this sheet belongs to.
- The technical side — log generation, collectors, a SIEM and time synchronisation — belongs to Networking and to Server & Virtualization, not here.
References
- NIST, SP 800-12 Rev. 1, An Introduction to Information Security — the definitions of audit and audit trail and the audit-and-accountability control set (§10.3).
- NIST, SP 800-92, Guide to Computer Security Log Management — log management as a process, why records are kept, the challenge of protecting and correlating them, and the cost of not analysing them.
- NIST, SP 800-53 Rev. 5, Security and Privacy Controls — AU-2, AU-3, AU-9, AU-11 and AU-12 as the conditions an audit record must meet.
- NIST, SP 800-53A Rev. 5, Assessing Security and Privacy Controls — the assurance case and the compiling of evidence into an argument.
- CIS, CIS Critical Security Controls v8.1 — Control 8, Audit Log Management.