What Are Audit Logs? Sources, Retention, and Use

Six weeks after the breach, the only question that matters is "what did they touch?" The answer is either sitting in your audit logs or it is gone. An audit log entry that reads DeleteTrail from an IAM role that has never called it before, at 02:14, from an IP in a country you do not operate in, is the difference between scoping an incident in hours and guessing for months. That single record names the actor, the action, the time, and the source. That is the whole job of an audit log.

An audit log is the authoritative record of who did what on a system. Not what a user saw, not how fast the app ran, but the security-relevant actions taken against the system itself: a permission changed, an account created, a record deleted, a configuration rewritten. When an investigation, an alert, or an auditor asks "who did this and when," the audit log is the source you go to.

This guide covers what an audit log is and how it differs from other log types, exactly what it records, the sources that produce it (operating systems, cloud control planes, databases, applications), how those records feed a SIEM for detection, forensics, and compliance, the retention rules that real regulations impose, and how to keep the logs themselves tamper-evident. It is written for the blue team: SOC analysts, threat hunters, and DFIR responders who have to read these records under pressure.

What is an audit log?

An audit log, sometimes called an audit trail, is a chronological record of the security-relevant actions performed on a system, capturing who took the action, what they did, when, and where. Its purpose is accountability: to reconstruct the sequence of changes to a system and attribute each one to an actor, whether that actor is a user, a service account, or an automated process.

The defining trait is that an audit log records actions against the system, not the routine output of the system doing its job. A web server log records that someone requested a page. An audit log records that someone changed who is allowed to request that page. The first tells you about traffic; the second tells you about control. That distinction is why audit logs are the primary evidence in almost every security investigation and the artifact regulators ask to see first.

Three jobs ride on the same data. For detection, audit logs feed the rules that fire when a privileged action happens where it should not. For forensics, they are the timeline you rebuild an intrusion from. For compliance, they are the proof that access was controlled and changes were authorized. The same 4720 (account created) event answers an alert, a court, and an auditor.

An audit log is not a product. It is a category of record that systems emit when configured to, collected and made queryable by other tooling. The work is turning it on deliberately, shipping it somewhere safe, and being able to read it when it counts.

Audit logs vs. other log types

Logs get lumped together, but a defender has to know which one answers which question. The split is about what each record is *about*.

The lines blur in practice. A Windows Security log carries authentication events that are squarely audit data, while a Linux auth.log mixes audit-grade sudo and SSH records with routine service noise. The useful test is not the file name but the question: if the record attributes a deliberate action to an actor for accountability, treat it as audit data and protect it accordingly. A failed sudo attempt and a successful one both belong in the audit story; a kernel driver reload usually does not.

This is why audit logs draw tighter handling than other logs. A dropped application log line is a gap in troubleshooting. A dropped or altered audit log line is a gap in the chain of evidence, and that is the thing an attacker most wants to create.

What an audit log records

A usable audit log entry answers four questions about every action. Miss one and the record loses most of its evidentiary value.

• Who. The identity that performed the action: user account, service account, role, or session. In the cloud this is the IAM principal; on Windows it is the security identifier and account name; in a database it is the connecting user.
• What. The action taken and the object it touched: DeleteObject on a specific bucket, GRANT ALL on a table, member added to Domain Admins, file deleted at a path.
• When. A precise, trustworthy timestamp. This is the field correlation depends on, which is why synchronized time across sources is a prerequisite, not a nicety. Sources that disagree on the clock produce a false sequence of events.
• Where. The origin and target: source IP, hostname, region, the resource affected. This is what separates the on-call engineer at the office from the attacker logging in from a residential proxy.

Two more fields decide whether the entry is worth keeping. The outcome, success or failure, because a string of failures followed by a success is the shape of a working brute force. And enough context to interpret it: the logon type on a Windows 4624, the request parameters on a cloud API call, the prior value on a configuration change. A record that says "configuration changed" without saying from what to what answers the question only halfway.

The standard the field uses for what to capture is NIST SP 800-92, the Guide to Computer Security Log Management, which has anchored security log practice for years. Its core point holds: a log you cannot attribute, time, or trust is not evidence.

Key sources of audit logs

Audit data comes from every layer of the stack, and a real investigation usually crosses several. These are the sources a defender pulls from most.

A few of these carry more weight than their volume suggests.

The Windows Security log is the identity-layer record for any AD environment. The events that matter (logon 4624, special privileges 4672, account created 4720, group membership change 4728) come from configuring audit policy deliberately. Turn the wrong subcategories on and the log floods; turn them off and the most damaging half of an intrusion happens unrecorded.

Cloud control-plane logs are the cloud equivalent of the Security log, and the single most important source in a cloud environment. AWS CloudTrail records every API call against the account: a console login, an S3 bucket made public, an IAM policy attached, a trail deleted. One caution that catches teams out: CloudTrail Event history retains only the last 90 days of management events by default and cannot be extended. To keep cloud audit data for the months an investigation or a regulation needs, you create a trail that delivers events to an S3 bucket you control.

Database audit logs sit closest to the data that gets stolen. A SELECT pulling an entire customer table at 3 a.m. from a service account is something only the database audit log sees. These are off by default in most engines because they cost performance, so the defender has to turn them on for the sensitive tables that matter.

How audit logs feed a SIEM

A Security log on one domain controller, a CloudTrail trail in one account, and a database audit file on one host answer nothing together while they sit apart. Audit logs become detection only when they leave their source and land in a SIEM where they can be correlated across systems and over time.

The pipeline has four stages.

• Collect. Ship audit records off every source: Windows Event Forwarding or a SIEM agent for the Security log, a CloudTrail-to-S3-to-SIEM path for cloud, agents or native export for database and application logs. Records that stay on the host are lost the moment the host is wiped, which is exactly what an attacker does on the way out.
• Normalize. Parse each vendor format into common fields, so a "user" from CloudTrail, a "user" from a Windows event, and a "user" from a database log mean the same thing and can be joined. This is what makes a who-did-what question answerable across the whole estate at once. It is the same log analysis discipline every source depends on.
• Correlate. Stitch related actions into a story. A cloud ConsoleLogin from a new country, followed minutes later by CreateAccessKey and PutBucketPolicy opening a bucket to the internet, is three benign-looking API calls that together are an account takeover and exfiltration setup.
• Alert and retain. Fire detections on the patterns that matter, and keep the raw records long enough to investigate and to satisfy retention rules. Audit-relevant compromises are routinely found weeks late, so retention is part of detection, not a separate filing problem.

Volume is the constant pressure. A busy AWS account or a large domain produces millions of audit events a day, almost all benign. The answer is the same at every source: filter the predictable noise (baselined machine-account logons, automated read calls) at the point of collection, normalize so detections run cheaply, and alert on deviation from a known-good baseline rather than the raw presence of an event. That filtering and rule-writing is where audit logs become detection engineering instead of storage cost.

What to monitor in audit logs

Not every audit event deserves an alert, but a short list of actions is high-signal almost everywhere. These are the ones worth a rule because they are rare, privileged, and exactly what an attacker does.

• Privilege and group changes. An account added to Domain Admins, an IAM role granted AdministratorAccess, a database GRANT of elevated rights. This is the cheapest privilege escalation an attacker has, and it shows up as a single clean event.
• Account lifecycle. Account creation, enabling, or password changes outside a change window. Attackers create or revive accounts for persistence.
• Authentication anomalies. Bursts of failed logons followed by a success, logons from new geographies, impossible-travel sign-ins, a spike in legacy-protocol authentication.
• Logging tampering. A CloudTrail StopLogging or DeleteTrail, a Windows 1102 (audit log cleared), an audit policy change. An attacker who disables logging is announcing the next move; this should be one of your loudest alerts.
• Sensitive data access. Bulk reads or exports from a database or SaaS app, especially by an account that does not normally touch that data.
• Configuration changes. Security-group rules opened, MFA disabled on an account, a key policy rewritten.

The common thread is that each has a benign twin. Admins do legitimately add users to privileged groups and clear logs during maintenance. The detection is therefore about context (who, when, from where, against a baseline), not the bare presence of the event. The strongest signal of all is the one with no legitimate twin in your environment: nobody should be turning your logging off.

Retention and the compliance clock

How long you keep audit logs is partly a detection decision and partly a legal one, and the legal floor is concrete. Regulations set retention because audit logs are the evidence that access was controlled.

Two of these are precise and worth getting right. PCI DSS 4.0 requirement 10.5.1 requires retaining audit log history for at least twelve months, with the most recent three months immediately available for analysis. That "immediately available" clause is why teams keep three months hot in the SIEM and archive the remaining nine to cheaper storage. HIPAA does not set a single audit-log retention number; its six-year clock is the 45 CFR 164.316(b)(2) requirement for documentation, and because audit records evidence the activity that rule covers, organizations commonly retain them for the full six years.

Retention is a security decision before it is a compliance one. An intrusion discovered weeks after it began can only be scoped from logs kept long enough to still hold the evidence, and Mandiant's M-Trends 2026 report puts the global median attacker dwell time at 14 days. A retention window shorter than your realistic time-to-detection erases the answer before anyone asks the question. The practical pattern across most teams: hot storage in the SIEM for fast querying over recent months, cheaper cold storage for the long compliance tail.

Keeping audit logs trustworthy

An audit log is only evidence if it has not been tampered with, and tampering with it is a named attacker objective. The MITRE ATT&CK technique Indicator Removal covers clearing Windows event logs (T1070.001) and deleting cloud trails, precisely because erasing the record buys an attacker time and breaks the investigation. Protecting the integrity of the logs is as important as collecting them.

Four controls do most of the work.

• Get the logs off the box, fast. The single most effective protection is forwarding audit records to a central store the moment they are written. An attacker who clears a local Windows Security log cannot reach the copy already in the SIEM. The forwarding itself is the integrity control.
• Write-once and access-controlled storage. Store the central copy where it cannot be edited or deleted by the accounts that generate it. Object-lock or write-once-read-many (WORM) storage, and tight, separate permissions on the log store, mean a compromised production account cannot reach back and rewrite history.
• Log the logging. Alert on the events that indicate tampering: log cleared (1102), CloudTrail StopLogging and DeleteTrail, audit policy changes. You cannot always prevent a privileged attacker from disabling logging, but you can make sure they cannot do it quietly.
• Integrity verification. CloudTrail log file validation produces a signed digest so you can prove a delivered log was not altered. Hashing or signing archived logs serves the same purpose: it lets you demonstrate, later, that the evidence is what it was when written.

The order matters. Forwarding off the host defeats the most common attack (clearing a local log) outright, because the attacker never had access to the copy that counts. The rest hardens the central store against a deeper compromise.

How blue teams use audit logs

Audit logs are connective tissue across the SOC, the same data serving three jobs.

Detection and triage. Audit events feed the rules an analyst triages. A privileged group change or a logging-disabled event maps straight to a detection, and the audit fields (who, where, outcome) are what an analyst reads first to decide if an alert is real.

Incident response. When something fires, audit logs are the timeline. Incident response reconstructs an intrusion by walking the audit trail: which account, what it touched, how far it reached, when it started. The quality of that reconstruction is capped by the quality of the audit logging that was in place before the incident.

Threat hunting and compliance. Hunters query audit logs for the privileged actions no rule fired on, the access that fits a known attacker technique but slipped the alerts. The same records, unchanged, are what an auditor reviews to confirm access was controlled. One well-collected audit trail answers the hunt and the audit both.

The fastest way to learn to read audit logs is to read them under fire. Reconstructing a real intrusion from its audit trail (which account logged in, what it changed, where the logs were cleared) is the same loop a SOC analyst runs daily.

The bottom line

An audit log is the authoritative answer to "who did what, when, and where" on a system. It records deliberate actions against the system (access, privilege use, configuration and account changes) and attributes each to an actor, which is what separates it from the system, application, and access logs that record everything else. That single property is why audit logs are the first evidence in an investigation and the first artifact an auditor asks for.

The work is in the discipline around them: collect from every layer (Windows Security log, cloud control planes like CloudTrail, database and application audit logs), ship them into a SIEM where they can be correlated, retain them past your realistic time-to-detection and your compliance floor, and keep them tamper-evident by getting them off the host and into write-once storage. Auditing everything buries the few events that matter, so monitor the high-signal actions (privilege changes, account creation, and anyone turning logging off) and alert on deviation from a baseline.