What is an Audit Log?
An audit log is a chronological, tamper-resistant record of who did what, when, and where inside a system. An audit log helps you prove later that an action happened and trace it back to a person or service.
Each entry captures a single event: the action, the timestamp, the user ID or API key behind it, the object that changed, and the source it came from (an IP address, host name, or device ID).
A series of these entries on one system forms an audit trail, which shows the full sequence of activity.
A regular application log helps an engineer debug an error, but it is noisy and short-lived. An audit log answers questions like who deleted the payroll record on March 3.
In other words, an audit log is written once and kept for future reference.
In a log monitoring setup, audit logs sit alongside operational logs. But they get stricter rules around access, retention, and integrity.
What Does an Audit Log Capture?
A useful audit log entry answers four questions in one line: who, what, when, and from where. If you miss any of these, the record loses its value in an investigation. A complete entry usually holds these fields.
Identity: The user ID, service account, or API key that initiated the event, such as jsmith or a Terraform service account.
Request type: The operation performed, such as create, read, update, delete, login, or permission change, written in a clear and consistent way so it remains understandable during future investigations.
Timestamp: The exact date and time of the event, ideally recorded in UTC to ensure consistency across systems and regions during analysis.
Resource: The object that was accessed or modified, such as a customer record, firewall rule, or cloud VM instance.
Origin: The source of the request, typically captured as an IP address, hostname, or device identifier, helping detect unusual or unexpected access locations.
A strong audit event records the caller identity, the action taken, the time, and the resource it touched. That is why teams route these records into a SIEM for review.
How Does Audit Logging Work?
Most tools in your stack can emit audit records once you turn the feature on. Most cloud platforms generate many audit events by default.
But you often have to enable auditing for specific services before the records you need start flowing. The common pattern runs in three steps.
Step 1: Generate a log entry
The source system writes an event the moment an action completes, such as a database recording every UPDATE against a customer table.
Step 2: Collect and centralize the logs
An agent or direct integration ships those events to one place, so records from servers, applications, and network gear are searchable together instead of scattered across hosts.
Step 3: Store and protect the logs
The platform writes records to append-only storage, applies role-based access control so only a few people can read them, and holds them for the retention window your policy demands.
Together, these steps ensure audit logs are consistently generated, centrally managed, and securely stored for investigation and compliance.
What are Audit Logs Used For?
Audit logs earn their keep in a few specific situations. Most teams adopt them for one of these reasons first.
Compliance evidence: Frameworks like HIPAA, PCI-DSS, GDPR, SOX, and SOC 2 require you to show who accessed sensitive data and when. PCI-DSS expects a record of every access to cardholder data, and the audit log is the artifact an auditor asks to see.
Security investigations: After a breach, the audit trail lets a security team reconstruct the timeline: which account logged in, what it touched, and when it stopped. Feeding those records through anomaly detection helps surface a login from an odd location before it turns into an incident.
Forensics and root cause: When a config change breaks production, the audit log shows the exact change and who made it, which speeds up root cause analysis instead of leaving the team to guess. People also behave differently when actions are recorded against their name, so the log deters careless or malicious changes.
Each of these use-cases assumes the same thing, that the record is accurate and no one has altered it. A log that can be edited after the fact proves none of them.
How to Keep Audit Logs Tamper-Resistant?
An audit log only counts as evidence if no one can quietly edit it. An attacker who breaks in will often try to delete or alter the records to hide their tracks. So integrity is the part you cannot skip.
A few controls protect that integrity.
Write-once or append-only storage: Records can be added but not changed or removed, so the history stays intact even if the source host is compromised.
Separation from the source system: Ship audit logs to a separate, hardened store rather than the machine they describe, so a breach of one server does not hand an attacker its own audit trail.
Encryption in transit and at rest: This protects records that may carry sensitive details like account numbers and stops anyone reading or changing them in flight.
Retention policies: Set how long records live based on the rule that applies to you, since SOX expects financial records kept for years while other data logging may need only months.
Where Do Audit Logs Fall Short?
The hardest part is deciding what to audit. A busy environment can produce terabytes of events a day, and recording every read gets expensive fast, so teams often log administrative actions but skip routine data reads.
Those gaps become blind spots, and a blind spot is where you lack proof during an investigation or a compliance check.
Retention pulls against cost. Keep everything for seven years and your storage bill climbs, but trim too aggressively and you fail an audit that asks for records you deleted.
No single setting satisfies both finance and the auditor, so the call is a judgment about risk.
Volume also makes manual review impractical. Nobody reads millions of lines by hand, so the value depends on correlation and alerting to surface the entries that matter.
Without that layer, an audit log is a record you open only after something has gone wrong, useful for forensics but no help in stopping the next incident.
Explore More IT Terms
Browse our comprehensive IT glossary to learn more about technology terminology.