Skip to main content
Identity Authority
Category: Governance & Compliance

Audit Log

Also known as: Audit Trail, Audit History
Simply put

An audit log is a chronological record of activities and events that occur within a system, such as who accessed data, what actions they performed, and what was created or changed. It provides a documentary history that organizations can review after the fact to understand what happened and when. In identity and access systems, this typically includes records of system access and operations performed over a given period.

Formal definition

An audit log is a chronological, typically append-only record of system activities, capturing events such as accesses, operations, and changes to data or configuration along with associated context (for example the acting principal, action, target, and timestamp). In IAM contexts it commonly documents authentication events, authorization decisions, provisioning and deprovisioning actions, and administrative changes, supporting after-the-fact investigation, access certification, and segregation-of-duties review rather than real-time enforcement. The specific events captured, retention, and record structure vary by system and configuration; some platforms (for example Microsoft 365) provide a unified audit log that consolidates activities across services for search and export. An audit log is a governance and forensic artifact and is distinct from runtime enforcement components such as a PDP or PEP.

Why it matters

Audit logs are the primary documentary evidence organizations rely on to reconstruct what happened within identity and access systems after an event has occurred. When an account is compromised, a privileged change is made, or data is accessed inappropriately, the audit log is typically the artifact investigators consult to establish who did what, to which target, and when. Without a reliable chronological record, after-the-fact investigation becomes speculative, and organizations lose the ability to demonstrate accountability for access decisions and administrative actions.

In IAM governance specifically, audit logs underpin access certification and segregation-of-duties review. Certifiers reviewing whether a principal still needs a given entitlement, or auditors testing whether conflicting duties were ever exercised by the same individual, depend on a trustworthy history of authentication events, authorization decisions, and provisioning and deprovisioning actions. The value of the log depends heavily on what events are captured and how records are protected; a typically append-only design helps preserve integrity, but coverage, retention, and record structure vary by system and configuration, and gaps in any of these can undermine an investigation or a compliance attestation.

It is important to keep the audit log's role in scope. It is a governance and forensic artifact, not a runtime enforcement mechanism. An audit log does not itself prevent an unauthorized action; that is the function of enforcement components such as a PDP or PEP. Treating logging as if it were a control that blocks access, rather than a record that documents access, is a common conceptual error that can leave organizations exposed while assuming they are protected.

Who it's relevant to

Compliance officers and auditors
Audit logs provide the documentary history used to demonstrate accountability, support access certification, and test for segregation-of-duties violations. These reviewers depend on complete coverage and appropriate retention to substantiate that access decisions and administrative changes can be reconstructed after the fact.
Identity governance leads
Governance teams use audit logs during access reviews and certifications to verify who accessed what and which provisioning or deprovisioning actions were performed. Because the log is a governance artifact distinct from runtime enforcement, governance leads should ensure the events they need for review are actually captured rather than assuming the log records everything by default.
Security architects and incident responders
During investigations, audit logs are typically the chronological source used to establish the acting principal, action, target, and timing of events. Architects should design logging so that authentication events, authorization decisions, and administrative changes are captured with sufficient context, and should treat the typically append-only nature of the log as a means of preserving evidentiary integrity.
System administrators
Administrators configure which events are captured, how long records are retained, and how logs are searched and exported. On consolidated platforms such as Microsoft 365, this includes working with a unified audit log to search for specific events across services, while recognizing that captured events and retention vary by configuration.

Inside Audit Log

Event timestamp
The recorded time at which an event occurred, typically synchronized to a reliable time source and often stored in UTC to enable correlation across systems. Accuracy depends on clock synchronization in the deployment.
Actor / principal identity
The identifier of the subject that performed or triggered the event, such as a user, service account, or workload. This reflects identification and authentication outcomes but should not be assumed to convey the authorization decision on its own.
Action / event type
A description of what took place, for example an authentication attempt, a token issuance, a provisioning change, or an access certification decision. The vocabulary and granularity vary by vendor and configuration.
Target / resource
The object acted upon, such as an account, group, role assignment, application, or protected resource. In access enforcement contexts this may reference the resource evaluated by a PDP or protected by a PEP.
Outcome / result
Whether the event succeeded, failed, or was denied, and where available a reason code. For access events this distinguishes an authentication failure from an authorization denial, which are separate conditions.
Source context
Contextual metadata such as source IP address, device or user-agent information, session identifiers, and originating system. Availability of these fields depends on the emitting component and configuration.
Correlation identifiers
Values such as request, session, or transaction IDs that allow a single logical operation to be traced across multiple systems and log entries.
Integrity metadata
Attributes that support tamper-evidence, such as sequence numbers, hashes, or signatures. Whether logs are signed, encrypted, or otherwise protected depends on the deployment; signing establishes tamper-evidence but is distinct from encrypting the log contents.

Common questions

Answers to the questions practitioners most commonly ask about Audit Log.

Is an audit log the same thing as an application or system log?
No. Although both are event records, they typically serve different purposes. An audit log is intended to capture security- and governance-relevant events, such as authentication attempts, authorization decisions, privilege changes, and access grants or revocations, in a manner that supports accountability and, in many deployments, tamper-evidence and non-repudiation. General application or system logs are usually oriented toward debugging, performance, and operational troubleshooting, and are not necessarily retained, protected, or structured to meet audit or compliance requirements. Depending on configuration, a system may write both, and some events may appear in both, but treating a general log as an audit log can leave governance requirements unmet.
Does having an audit log by itself satisfy compliance or provide access control?
No. An audit log is a detective control, it records what happened so that events can be reviewed after the fact. It does not enforce access decisions at runtime; that is the role of enforcement components such as a PEP and PDP. It also does not, on its own, constitute compliance. Depending on the applicable framework, meeting an audit requirement typically also depends on factors such as which events are captured, retention periods, protection against tampering, and whether the logs are actually reviewed. The audit log is evidence and an input to governance processes like access reviews and certification, not a substitute for enforcement or for the review activity itself.
Which identity and access events should typically be captured in an audit log?
The specific set depends on the applicable requirements and deployment, but security-relevant events are commonly included: authentication events (successes and failures, and often the factors or methods used), authorization decisions where feasible, session creation and termination, privilege and role assignments or removals, provisioning and deprovisioning actions, changes to policies or configurations, and administrative actions on the identity system itself. Where enforcement components emit them, PDP decisions can be valuable. Scoping is a balance: capturing too little undermines accountability, while capturing too much can raise storage, performance, and privacy concerns.
How can audit log integrity be protected against tampering?
Approaches vary by deployment and typically combine several measures. Common techniques include forwarding events promptly to a separate, write-restricted destination such as a SIEM or dedicated log store, applying strict access controls so that the accounts generating events cannot alter historical records, and using integrity mechanisms such as cryptographic hashing, hash chaining, or signing to make tampering detectable. Note that signing or hashing provides tamper-evidence, not confidentiality; protecting sensitive contents may additionally require encryption at rest and in transit. The appropriate combination depends on the threat model and any applicable regulatory requirements.
How should audit log retention periods be determined?
Retention is generally driven by the applicable legal, regulatory, contractual, and internal policy requirements rather than by a single universal value, so periods vary considerably by industry and jurisdiction. In most deployments, organizations balance the need to support investigations, access certifications, and audits over time against storage costs and data-minimization or privacy obligations. It is common to tier retention, keeping recent logs readily searchable and archiving older logs in cheaper, still-protected storage, while ensuring the chosen period is documented and consistently enforced.
What should be considered to keep audit logs useful without exposing sensitive data?
Useful audit logs typically record enough context to reconstruct events, such as the acting principal's identifier, the action, the target resource, a timestamp, source information, and the outcome, while avoiding unnecessary capture of sensitive data. In many deployments this means excluding secrets such as passwords, tokens, and other credentials from log contents, and considering redaction, pseudonymization, or field-level controls for personal data subject to privacy requirements. Consistent, structured formatting and reliable, synchronized timestamps improve correlation and searchability. Access to the logs themselves should also be governed, since audit data can be sensitive.

Common misconceptions

An audit log records what a user was authorized to do.
An audit log records events that occurred, including identification, authentication, and authorization outcomes as separate facts. The presence of an actor in a log entry does not by itself indicate the authorization decision; the outcome field, where present, distinguishes an authentication failure from an authorization denial.
Audit logs and IGA activity records are the same thing as real-time access enforcement.
Audit logs capture a historical record of events, which may include both governance activities such as provisioning and certification and runtime enforcement events such as token validation. Recording an event is a separate concern from the runtime decision made by a PDP or enforced by a PEP; logging happens after or alongside enforcement, not as a substitute for it.
A signed audit log is a confidential audit log.
Signing provides tamper-evidence and integrity assurance, but it does not conceal the contents. Confidentiality requires encryption, which is a separate control. Whether either is applied depends on configuration and deployment requirements.

Best practices

Synchronize clocks across all logging sources to a reliable time reference and store timestamps in a consistent timezone, typically UTC, so events can be correlated across systems.
Capture distinct fields for identification, authentication outcome, and authorization outcome so that an authentication failure can be told apart from an authorization denial during analysis.
Include correlation identifiers such as request, session, or transaction IDs to trace a single logical operation across multiple components and log entries.
Protect log integrity with tamper-evident mechanisms such as signing or append-only storage, and separately apply encryption where confidentiality of log contents is required by the deployment.
Record both governance events, such as provisioning and access certification decisions, and runtime enforcement events, such as token validation, while keeping their sources and semantics clearly distinguished.
Define and enforce retention, access control, and review procedures for audit logs consistent with applicable compliance requirements, and restrict who can read or modify them.
Promotional banner highlighting failures found in PCI audits and how to spot the gaps