Audit logs: who did what and when

An audit log records every significant action in a system with actor, time and change. What to log, how to keep it, and why it protects everyone.

3 minread 682words last updated

The short answer

An audit log is the system’s memory of who did what and when: every significant action, recorded with the actor, the time, the record affected, where it came from and, for changes, what it was before and after. It exists to answer the questions that only arise afterwards. Who changed this price last month? Who exported the customer list? Who approved this payment, and who deleted that record? It must be append-only and tamper-evident, retained for a defined period, searchable by the people entitled to search it, and free of secrets and unnecessary personal data. It protects the business, and it protects staff, because it shows what was done correctly as often as what was not.

What a good audit entry contains

FieldExample
WhoUser identifier and name at the time; or the system process
WhatThe action: created, changed, deleted, approved, exported, logged in, changed permission
Which recordThe type and identifier of the thing affected
WhenA precise timestamp in a fixed time zone
From whereSource such as the interface, API or import; and where reasonable, the network origin
Before and afterFor changes to important fields: the old and new values
ContextOn whose behalf, in which tenant, as part of which batch or approval

Designing it

  1. List the auditable actions with the business: what would someone want to know later?
  2. Record in one place, through one mechanism, so no action can bypass it.
  3. Store append-only, separate from operational data, with integrity protection where the stakes justify it.
  4. Set retention per the business and legal requirements, and automate deletion at the end of it.
  5. Keep secrets and unnecessary personal data out: never a password, a token or a full document body.
  6. Make it searchable by record, by person and by time, for the roles entitled to search.
  7. Log access to the log itself.
  8. Surface it where useful: a history tab on important records showing who changed what.

Why it protects everyone

When a customer disputes a change, the log shows what happened and who did it. When money moves, the log shows the approval chain. When a regulator asks, the log answers. When a staff member is wrongly suspected, the log clears them. When a compromise is investigated, the log shows what the attacker did with the access. Systems without one leave every such question to memory and argument.

What this means for you

Insist that your software keeps an audit log of significant actions: who, what, when, which record, from where, before and after, append-only, retained for a defined period, searchable by the right people and free of secrets. Decide the list of actions with your team. It is the feature nobody asks for at the start and everyone is grateful for the first time a question arises that only it can answer.

Written by the CivSec S.M.A.R.T team

We build and run websites, software and AI systems for businesses. We write about what we see in that work, in plain language, and we update articles when things change.

Last checked . Spotted something outdated? Tell us.

Frequently asked questions

Is an audit log the same as application logs?

No. Application logs are technical records for diagnosing problems: requests, errors, performance. An audit log is a business record of significant actions by people and systems, kept longer, structured for questions like who approved this, and protected against alteration. They overlap in mechanism and differ in purpose, retention and audience.

What actions should be audited?

Anything a person could later ask about: logins and failed logins, permission and role changes, creation, change and deletion of important records, approvals and rejections, exports, payments and refunds, configuration changes, access to sensitive data. Not every click; every action with consequence. Deciding the list with the business is part of the design.

Who can read the audit log?

Administrators and auditors, with their own access logged. Managers for their own area, in some systems. Never editable by anyone through the application. Reading the audit log is itself a sensitive action, and the log should record it.