Cybersecurity glossary
What is an Audit Log?
Learn what an audit log is in cybersecurity, how it differs from operational logs, which events to record, and how to keep trails tamper-resistant for investigations and compliance.
Definition
An audit log is a time-ordered, attributable record of security-relevant actions—who did what, to which object, with what outcome—designed for investigation, accountability, and compliance rather than routine troubleshooting.
Why audit logs decide investigations
When an incident starts, memory and screenshots are not evidence. An audit log answers the questions courts, insurers, and responders actually ask: which identity acted, on which resource, from where, at what time, and whether the action succeeded.
Without that trail, containment becomes guesswork and compliance reviews become theater.
What a useful audit record contains
Actor
User, service account, API key, or workload identity—not just an IP that many people share.
Action and object
A stable verb plus the resource (role grant, bucket policy, invoice export), not a free-text stack trace.
Outcome
Success, denial, or error. Denied attempts are often the first sign of probing.
Context
Timestamp with timezone, source, tenant, request or session ID, and enough geo or device detail to correlate later.
How audit trails get undermined
Events never exist
Admin consoles, scripts, and bulk APIs skip structured security events.
Identity is missing
Shared accounts and unattributed service tokens make every row anonymous.
Storage is writable
The same host that was compromised still owns the only copy of the log.
Clocks and formats drift
Unsynchronized time and inconsistent schemas break later correlation.
Nobody can query them
Logs sit in cold storage without search, retention policy, or access review.
Audit log vs neighboring log types
| Log kind | Primary purpose | Design for |
|---|---|---|
| Audit log | Accountability and investigation | Attribution, integrity, long retention |
| Application debug log | Diagnose bugs | Short life, high volume, no secrets |
| Access / web log | Traffic and performance | Request metadata, rate and error patterns |
| Security telemetry | Detection (EDR, IdP, cloud) | Behavior signals that detections consume |
- Define a catalog of must-audit events with required fields: actor, action, object, outcome, correlation ID.
- Ship events off-host immediately to append-only or WORM-capable storage.
- Prefer structured JSON over free-text so SIEM parsers stay stable.
- Synchronize clocks (NTP) and store timestamps in UTC.
- Alert when the logging pipeline stalls, drops volume, or loses integrity checks.
- Redact secrets and unnecessary PII while keeping forensic identifiers.
- Restrict and log access to the audit store itself—the trail of who queried the trail.
- Test restorability: can responders actually retrieve 90-day-old events during a drill?
The practical takeaway
An audit log is not a debug dump. It is the accountable history of security-relevant actions. Record the right events, protect them from the systems they describe, and keep them searchable—or every later detection and forensic step starts already incomplete.
Related security terms
Security Logging and Alerting Failures
OWASP category covering missing, unused, or tamperable logs.
Log Correlation
Joins audit events across systems into a single investigative story.
Security Information and Event Management (SIEM)
Central platform that stores, searches, and alerts on audit trails.
Forensic Analysis
Uses preserved audit records to reconstruct attacker activity.
Incident Response
Depends on trustworthy audit evidence to contain and explain incidents.
Frequently asked questions
What is an audit log in simple terms?
It is a durable diary of security-relevant actions: who logged in, who changed a permission, who exported data, and whether the action succeeded or was denied.
How is an audit log different from an application or debug log?
Debug logs help developers fix bugs and often contain noisy, short-lived detail. Audit logs record accountable events with identity, object, outcome, and integrity protections so they remain useful months later.
Which events should always be audited?
Authentication outcomes, MFA and password changes, privilege grants, admin configuration changes, access-control denials, bulk data exports, key or secret use, and deletions of records or logs themselves.
Can attackers erase audit logs?
They try. Local files on the compromised host are easy to wipe. Ship events immediately to append-only storage the host cannot rewrite, and alert on logging pipeline failures.
Do audit logs create privacy or disclosure risk?
Yes if they capture passwords, tokens, or unnecessary personal data. Record identifiers and outcomes, redact secrets, and restrict who can query the trail.
How long should audit logs be kept?
Long enough for investigations and legal or regulatory obligations—often months to years. Retention without integrity and access control is still a weak control.
Are audit logs enough for detection?
No. They are the evidence layer. Detection still needs rules, correlation, owners, and a response path, or the trail is only useful after someone else tells you that you were breached.
References
Explore authoritative guidance and frameworks related to audit log.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.