What Is an Audit Log?

Last verified on Nov 8, 2026.

An audit log is a chronological record of actions taken in a system: who did what, to which resource, when, from where, and whether it worked. You use it to answer questions after something has changed, such as who made this repository public, who read this secret, or who attached an admin policy to a role. It is a record of accountability more than a record of how the software is running.

How It Differs From an Application Log

OWASP draws the line directly. Process monitoring, audit, and transaction logs are usually collected for different purposes than security event logging, and often should be kept separate, because the events and details differ. It describes an audit log as a chronological record that gives an independently verifiable trail, allowing someone to reconstruct and examine the original sequence of attributable transactions.

NIST SP 800-92 describes audit records in an operating system as security events: successful and failed authentication attempts, file accesses, security policy changes, account changes such as creation and privilege assignment, and use of privileges.

What Each Entry Needs

Every entry has to carry enough to attribute an action. A practical minimum is the actor, the action, the target, the time, the source address, and the outcome. OWASP's general rule is to record when, where, who, and what.

An AWS CloudTrail Example

CloudTrail records actions taken by a user, role, or AWS service, including those from the console, the CLI, and SDKs and APIs. An abbreviated management event, with illustrative values, looks like this:

{
  "eventTime": "2026-11-08T06:44:27Z",
  "eventSource": "iam.amazonaws.com",
  "eventName": "AttachRolePolicy",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "198.51.100.45",
  "userIdentity": {
    "type": "IAMUser",
    "arn": "arn:aws:iam::123456789012:user/Alice",
    "userName": "Alice"
  }
}

userIdentity says who, eventName and eventSource say what and where, sourceIPAddress says from where, and errorCode appears when the request failed. For a walkthrough of reading these, see CloudTrail investigation and the AWS CloudTrail integration.

A Kubernetes Example

Kubernetes audit answers six questions: what happened, when, who initiated it, on what, where it was observed, and from where it was initiated. A policy decides what is recorded, using four levels: None, Metadata, Request, and RequestResponse. If you do not pass a policy file to the API server, no events are logged, so a cluster can have auditing available and still record nothing. See Kubernetes audit logs.

Other Common Sources

• Linux auditd records logins, authentication, sudo commands, and changes to watched files in /var/log/audit/audit.log.
• GitHub's enterprise audit log covers repository visibility and permission changes, personal access token and deploy key activity, Actions secret changes, and membership changes. See GitHub audit log.
• Application-level trails for data additions, changes, deletions, and exports, which OWASP lists among the events to log.

Protecting an Audit Log

Anyone who can edit the audit log can erase what they did. OWASP asks for tamper detection so you know if a record was modified or deleted, and for protection from tampering in transit and from unauthorized access, modification, and deletion at rest. Send a copy off the host that generates it, restrict delete rights, and watch for logging that stops. Your log retention policy sets how long records stay, and log aggregation puts a second copy somewhere an attacker on the source host cannot reach. For a broader checklist, see security logging and privilege change detection.

Audit Logs in Sazabi

Sazabi, an AI-native observability and security platform, has sources for several of these. The GitHub audit log stream stores GitHub's JSON and puts fields such as github.audit.action and github.audit.actor into attributes. GitHub does not audit reads of Actions secrets, so that gap stays in any destination. CloudTrail, auditd, and Kubernetes audit logs also have setup pages in the Sazabi docs. Search them with the same log search you use for application logs. Related terms: SIEM and syslog.