Audit logging is the feature nobody asks for during a build and everybody needs during an incident.
The questions it answers are always asked at bad moments: who changed that price, who deleted that record, who accessed that customer's file, when did this figure become wrong.
The moments you will need it
A dispute with a customer
They say they were quoted a different figure. Without a log, it is their memory against your colleague's. With one, you can see the quote, the date, who prepared it and what changed afterwards.
This is not about catching customers out. Frequently the log confirms the customer is right, which lets you resolve it immediately rather than after a fortnight of argument.
A mistake nobody owns
A price has been wrong for three months. Somebody changed it. Nobody remembers doing so, and probably nobody is lying — it was a Tuesday in March.
The log tells you when, which tells you which orders were affected, which is the information you actually need.
A departing employee
Somebody leaves for a competitor. Did they export the customer list? Without access logging you cannot know, and you cannot act.
This is the case that most often makes businesses wish they had implemented it, and it requires logging reads as well as changes.
A data protection request or breach
Under UK GDPR you may need to demonstrate who accessed personal data and to identify what was affected in a breach. "We do not know" is a poor position with a regulator and a worse one with customers.
An audit or a tender
Financial audits, industry accreditations and larger customers' procurement questionnaires increasingly ask whether administrative actions are logged. It is becoming a condition of doing business rather than good practice.
Audit logging costs a little to build in and a great deal to add later, because the history you needed does not exist retrospectively.
What to record
For each entry: who, what, which record, when, and from where.
Who means the actual person, not "the system". Where somebody acted on behalf of another — support staff impersonating a user for troubleshooting — record both.
What in business terms rather than technical ones. "Changed the credit limit from £5,000 to £15,000" is useful. A database statement is not, to the person who will read it.
Before and after values for anything financial, contractual or sensitive. Knowing something changed is much less useful than knowing what it changed from.
Reads, for sensitive data. Customer records, personal data, financial information. This is the part most often omitted and it is what answers the departing-employee question.
Failed attempts. Someone repeatedly trying to access something they are not permitted to see is worth knowing about.
What makes a log trustworthy
It must be append-only. If the people it records can edit it, it proves nothing. Ordinary users, including administrators, should not be able to alter entries.
It must be separate from the data it describes. A log stored in the same table as the records is lost when those records are deleted.
It must be complete. A log covering the web interface but not the API, or not scripts run by IT, has gaps precisely where the interesting activity happens. Log at the data layer so nothing bypasses it.
It must be searchable by a human. A log nobody can query is a log nobody uses. "Show me everything user X did last Thursday" and "show me every change to this record" should both be straightforward.
Retention
Decide deliberately rather than by default.
A year is a sensible minimum for most business systems. Financial records typically need longer, driven by the same requirements as your accounting retention. Regulated activities may specify a period.
Remember that audit logs frequently contain personal data themselves — names, addresses, actions by identifiable individuals. They are subject to the same retention discipline as anything else, covered in the CRM data worth capturing.
The common objections
"It will slow the system down." Written properly, the overhead is negligible. Written badly — synchronously, to the same database, on every read — it can be noticeable, which is an argument for doing it well rather than not doing it.
"Staff will feel monitored." Frame it honestly, because it is honest: the log protects them as much as it protects the business. When a customer disputes what was said, the log is what defends your colleague.
"We are too small to need it." Small businesses have the same disputes and the same obligations, with fewer people who might remember what happened.
Where to start
If you are commissioning a system, put it in the requirements. It is a small addition at build time and a substantial project afterwards.
If you are buying, ask what is logged, whether reads are included, how long it is retained, and whether administrators can delete entries. The answers vary considerably between products, and vendors do not volunteer the limits.
If you have systems already, find out what they log today. Most business software records more than people realise and less than they assume, and the gap is worth knowing before you need it.
Our web applications team builds audit logging into systems for UK businesses as standard, including access to sensitive records. Start a conversation.
