Audit Log

An audit log is a chronological, append-only record of the events that occur in a system: who performed an action, what they acted on, when, and what the result was. Each entry is written once and never edited, so the log can be trusted as evidence after the fact. It answers questions about the past that the current state of a system cannot.

Why Audit Logs Matter

An audit log is the only record of how a system reached its current state.

Current data shows what a record contains now. It does not show that a campaign’s destination URL was changed at 02:14 by an account dormant for six months. Without a log that change is invisible: the field simply holds a different value than yesterday.

Three uses follow. Investigation: after an incident, the log reconstructs the actions that caused it. Accountability: actions tie to an individual rather than a shared login. Evidence: an external auditor accepts a log entry as proof that a control operated, and accepts almost nothing else.

What an Audit Log Records

Every usable entry answers five questions: who, what, when, where, and outcome.

• Actor. The authenticated identity, not the service account it ran under: [email protected], not api-worker.
• Action. A verb from a fixed set: create, update, delete, login, export.
• Object. The record affected, by stable ID rather than display name.
• Timestamp. The moment of the event in UTC, to at least second precision.
• Source. IP address, session or request ID, and the client.
• Outcome. Success or failure. Failed attempts matter more in a security investigation.

A typical entry, in the JSON structure most systems emit:

{
  "timestamp": "2026-09-23T02:14:07Z",
  "actor": "[email protected]",
  "action": "update",
  "object": "link/9f21c4",
  "field": "destination_url",
  "before": "https://example.com/pricing",
  "after": "https://example.com/pricing-2026",
  "source_ip": "203.0.113.42",
  "outcome": "success"
}

The before and after pair separates an audit log from an activity feed. Knowing a link was edited is nearly useless. Knowing what it changed from and to is the point.

Audit Log vs Audit Trail

An audit log is the record. An audit trail is the sequence you reconstruct from it.

	Audit log	Audit trail
What it is	A store of event entries	A reconstructed path for one entity
Scope	Everything the system records	One record, user, or transaction
Produced by	The system, continuously	An investigator or report, on demand
Answers	“What happened in this system?”	“Everything that happened to invoice 4471”

In everyday use the terms are synonyms, and most compliance frameworks use “audit trail” loosely to mean the log itself. The distinction matters when designing one: a log that cannot be filtered by object ID produces no trail, because nobody can extract one record’s history from it.

Types of Audit Logs

• System logs. Operating system and infrastructure events: service restarts, configuration changes, privilege escalations.
• Application audit logs. Business actions inside a product: a user changed a setting, exported a report, deleted a campaign.
• Access and authentication logs. Logins, failed logins, password resets, permission grants. The first place a breach investigation looks.
• Database change logs. Row-level before and after values, captured by triggers or change data capture.
• API logs. Calls made by integrations, with the token that authorized them.

The operational distinction is between debug and audit logs. Debug logs are verbose, short-lived, and safe to drop. Audit logs are selective, retained for years, and must not be droppable by the people they record.

Audit Trail Compliance Requirements

Most frameworks require logging, and several set explicit retention periods.

• PCI DSS Requirement 10 covers logging access to cardholder data. Version 4.0 requires audit log history retained for at least 12 months, with the most recent 3 months immediately available for analysis.
• HIPAA Security Rule §164.312(b) mandates audit controls: mechanisms that record and examine activity in systems holding electronic protected health information.
• ISO/IEC 27001:2022 Annex A control 8.15 requires logs of activities, exceptions, and faults to be produced, stored, and protected.
• SOC 2 examines logging under the Common Criteria for monitoring (CC7.2), where the evidence an auditor asks for is the log itself.

NIST SP 800-92, the guide to computer security log management, is the better design reference. The requirement common to all: a log the investigated administrator can edit satisfies nothing. A log records what happened; an approval workflow records who authorized it beforehand.

Audit Log Best Practices

1. Make entries immutable. Append-only storage, with write access separated from the application generating events.
2. Log the human, not the service. Record the authenticated user behind an automated action, or everything attributes to one API key.
3. Use UTC and synchronized clocks. Clocks differing by 40 seconds make sequence impossible to establish.
4. Never log secrets. Passwords, tokens, and card numbers in a log create a second, less protected copy.
5. Set retention deliberately. Pick the period the strictest applicable framework requires, then enforce deletion afterwards.
6. Test retrieval, not just capture. A log nobody can query within the window an auditor allows is functionally absent.

In marketing systems, the equivalent record is who created or changed each campaign link. linkutm’s team workspaces attribute every link to the member who created it, which is what lets a later UTM audit trace a broken parameter back to its source instead of only reporting that it exists.

Frequently Asked Questions

What is an audit log?

An audit log is a chronological, append-only record of events in a system, capturing who did what, to which object, when, and with what result. Entries are written once and never modified, which is what makes them usable as evidence. It answers questions current data cannot, such as who changed a value and what it was before.

What is the difference between an audit log and an audit trail?

The audit log is the stored record of events; the audit trail is the sequence reconstructed from it for one record, user, or transaction. The log is produced continuously; the trail is assembled on demand during an investigation. Most frameworks use the terms interchangeably, and the distinction only matters when designing a log that must support per-object filtering.

How long should audit logs be retained?

Retention is set by the strictest framework that applies. PCI DSS requires at least 12 months of audit log history with the most recent 3 months immediately available. Where no rule applies, one year is a common default, because most investigations begin well after the event. Retaining longer than required raises both storage cost and breach exposure.

Why do audit logs matter for compliance?

Auditors test whether a control operated, not whether it was documented, and the log is usually the only acceptable evidence. A policy stating that only administrators can export data proves nothing; a log showing every export with its actor proves the control worked. This is why frameworks specify protection as well as capture.

Every link built with the free UTM builder is saved as a traceable record, not a row in a spreadsheet you have to trust.