The Audit Trail: Who Changed What, and When
An audit trail is not a security feature you switch on and forget. It is a record that only earns its keep when somebody reads it — and the question it answers is almost never "who stole something", but "what actually happened to this record between Tuesday and Friday".
The typical reason a business goes looking for an audit trail is disappointingly ordinary. A supplier invoice was approved at a figure nobody now recognises. A stock adjustment removed forty units and the note says "correction". A customer's credit limit is double what the credit committee agreed. Nobody is accused of anything; everybody genuinely does not remember.
That is the real job of an audit trail. Not catching thieves — that is rare and usually found another way — but reconstructing a sequence of small, forgotten, individually reasonable actions that added up to a number somebody is now questioning.
What a usable trail records
A log that records only "record updated" tells you nothing you could not have guessed. The value is in the specificity, and there is a short list of fields that decide whether an entry can answer a question a year later.
| Recorded | The question it answers |
|---|---|
| Actor — id, name and email at the time | Who did it, even if that person has since left and the account is gone |
| Action and module | What kind of thing happened, and to which part of the business |
| Subject type and id | Which exact record — this purchase order, not purchase orders generally |
| Route and HTTP method | Through which screen or endpoint, which distinguishes a UI edit from an import or an API call |
| IP address and user agent | From where and on what, which is what turns "impossible, I was on leave" into a checkable claim |
| Session id | Whether a burst of changes was one sitting or several |
| Timestamp | The sequence — usually the single most valuable field |
| Description and metadata | The human sentence, plus the structured detail behind it |
The one people underestimate is the actor's name and email stored at the time of the action. Systems that store only a user id produce logs that go blank the moment an employee is deleted — which is exactly when you most need to read them.
Reads matter, not only writes
Most logs record changes. But a meaningful share of the incidents an organization actually has are not changes at all — they are somebody taking a copy of something. A departing salesperson exporting the customer list. A payroll report opened by a person who has no business in payroll. Nothing was modified, so a write-only log is silent.
The honest position is that logging every read of every screen is noise that nobody will ever page through. The useful compromise is to log the reads that matter — exports, reports, generated documents and receipts — and leave ordinary navigation unlogged. That is the line we draw: item exports, report views, workflow log exports, invoice PDFs and POS receipts are recorded even though they only read data.
Document access is logged separately
Files in the document vault carry their own access log, because "who opened the signed contract" is a different question from "who edited the contract record" and is usually asked by a different person.
A log nobody reads is a log that does not work
This is where most audit-trail projects quietly fail. The logging is switched on, the entries accumulate, and the first time anyone opens the screen is during an investigation eighteen months later — at which point there are two million rows and no idea what normal looks like.
The value of an audit trail is not that it exists. It is that somebody looked at it recently enough to know what normal looks like.
-
Pick four questions and answer them monthly
Who deleted anything last month. Who exported anything sensitive. Which records were edited after approval. Which administrative permissions changed. Four filters, fifteen minutes, once a month.
-
Read after every unusual event, not only during audits
A resignation, a dispute, a variance that was written off, a customer complaint about a price. Open the trail while people can still explain what you find.
-
Let people know the trail is read
Not as a threat — as a fact stated once in an induction. The deterrent value of a log comes almost entirely from people knowing it is looked at, and none of it from the log existing quietly.
-
Investigate with the sequence, not the single entry
One edit is rarely the story. The story is that the order was approved at 4:52pm, edited at 4:58pm and received at 9:03am the next morning, all by two people who sit together.
The edit-after-approval pattern
If you only ever run one audit-log query, run this one. It is the single most productive question in operational governance, and it is invisible without a trail.
What the sequence looks like when it matters
Illustrative, in KES. Nothing here is hidden and nothing is obviously fraudulent — an edit is a legitimate action and a receipt is a legitimate action. What makes it visible is a trail that puts the approval and the edit in order, six minutes apart. Whether your system re-triggers approval after an edit is a question worth asking out loud; where it does not, this query is your control.
What we do and do not do
What AWRA OpsHub does today
- An audit log entry per recorded action, carrying actor id, actor name and email as at the time, action, module, subject type and id, route, HTTP method, URL, IP address, user agent, session id, a description and structured metadata.
- Selected read actions logged, not only writes — item exports, report views, workflow log exports, invoice PDFs and POS receipts.
- A separate document vault access log, so file opens are traceable independently of record edits.
- Security signals and incidents surfaced in a security control centre rather than left buried in the raw log.
- Login and session activity queryable and summarisable, which is what makes "was that really them" answerable.
- Retention policies per module, so the trail is kept for a period you choose rather than forever by accident.
What it does not do
- Not a full before-and-after field diff on every model. The log records the action, the subject and its metadata — it is a record of what happened, not a universal version history you can roll a record back to.
- No tamper-proof or write-once storage. The log lives in your database. An administrator with database access is outside what any application-level log can defend against.
- No automatic anomaly alerting on the audit log itself. Reading it is a rhythm you keep; there is no rule engine watching the log and paging you.
- Not a substitute for approval controls. A trail tells you what happened afterwards. It does not stop anything at the moment it happens.
The last one is the important one. Organizations regularly present an audit trail to a board as a control. It is evidence, which is a different and less protective thing than a control.
How long to keep it
Longer than you think for anything money touches, shorter than forever for everything else. The competing pressures are real: audits and disputes reach back years, while data-protection practice pushes towards keeping personal data no longer than you need it. Retention policies are set per module for exactly that reason — the sensible answer for financial records and the sensible answer for support tickets are not the same number.
Pick the periods deliberately, write down why, and revisit them when your auditor or your data-protection obligations change. A retention period nobody chose is still a decision — it is just one you made by accident. The Kenyan angle on that decision is covered in data protection, retention and deletion.
Our take
Switch the trail on, then schedule fifteen minutes a month to actually read four queries against it — deletions, sensitive exports, edits after approval, and permission changes. A trail nobody reads is a compliance decoration. A trail somebody reads monthly is the cheapest control in the business.
See the security operations view
Audit logging across modules, login and session activity, document access logs and a security control centre that surfaces signals instead of raw rows.
Explore security operationsFrequently asked questions
What is the difference between an audit log and an activity feed?
An activity feed is a convenience for users — it shows recent movement on records they care about, and it is designed to be glanced at. An audit log is evidence: it records the actor, the route, the IP address, the session and the time, it is not editable by ordinary users, and it is designed to be queried long after everyone has forgotten the event. Businesses often mistake a friendly activity feed for an audit trail and discover the difference during an investigation.
Does the audit log show what a field was changed from and to?
Not universally. Entries carry the action, the subject and structured metadata about it, which answers "what happened and to which record" — but this is not a full field-level version history across every model, and you should not design a control that assumes you can diff any record at any point in time. Where before-and-after detail matters to you specifically, say so; it is a scoping question, not a setting.
Can an administrator delete audit entries?
The log lives in your database, so anyone with direct database access is outside what an application can protect against — that is true of every system of this kind, and any vendor claiming otherwise is describing an append-only or externally shipped log, which is a different architecture. What the application gives you is that ordinary users, including most administrative users, work through screens that write to the log rather than edit it. If tamper-evidence is a hard requirement in your sector, raise it explicitly.
How often should we actually read it?
Monthly, for fifteen minutes, against four standing questions: who deleted anything, who exported anything sensitive, which records were edited after approval, and which permissions changed. Plus immediately after any unusual event — a resignation, a dispute, a written-off variance — while the people involved can still explain what you find. The monthly habit matters more than the depth, because it is what teaches you what normal looks like.
Are reports and exports logged, or only edits?
Both, but selectively. Logging every screen view would produce noise nobody reads, so ordinary navigation is not recorded — while the reads that carry risk are: item exports, report views, workflow log exports, invoice PDFs and POS receipts. Document vault files additionally have their own access log. If your concern is data walking out rather than data being changed, those are the entries to filter on.
