What is an audit log?
An audit log is a time-ordered record of the significant things that happen in a system: who took an action, what the action was, when it happened, and which record it touched. It is kept so that, later, anyone with a legitimate reason can reconstruct exactly what took place. In a support tool, that means a trustworthy history of how a ticket was handled, from the moment it arrived to the moment it was closed.
The short answer
An audit log in one paragraph
An audit log is the system's memory of who did what. Each time something meaningful happens, an entry is written down that captures the actor, the action, the time, and the thing affected. Read back later, those entries let you answer questions such as "who changed this", "when did that happen", and "what was done to this ticket", without relying on anyone's recollection.
The point of writing actions down is that memory and good intentions are not enough on their own. People forget, busy days blur together, and the one moment you need to explain is usually the moment nobody can quite remember. An audit log replaces "I think Sam dealt with that" with a dated, attributable record, so the answer is a fact rather than a guess.
You will see two closely related terms used almost interchangeably. The audit log is the stored record itself, the running list of entries. The audit trail is the story you can follow through those entries, for example tracing one ticket from creation through every reply and status change to its close. The log is the data; the trail is the path you reconstruct from it. The difference is one of emphasis rather than substance, and most people use whichever feels natural.
The anatomy
What an audit trail records
A useful audit entry answers four plain questions. Get those four right and the log earns its keep; everything else is detail.
The deliberately modest goal of each entry is to capture enough to reconstruct the action later, and no more. The four staples are the actor, the action, the time, and the affected record. Together they turn a vague sense that "something changed" into a specific, attributable event you can point to.
The four questions every entry should answer
| Who | The actor who performed the action, identified by the account that did it, so the event can be attributed to a real person rather than left anonymous. |
|---|---|
| What | The action that took place, described as an event such as assigned, replied, status changed, tag added or setting updated. |
| When | The timestamp the action happened, so events can be put in order and the gap between them measured. |
| Which record | The specific thing affected, such as a particular ticket, contact or setting, so the entry is tied to the right place. |
A well-designed audit log records the meaningful events and skips the noise. Logins and permission changes, assignments and reassignments, status and priority changes, replies sent, tags added or removed, and configuration changes are the kind of things worth keeping. Trivial reads and routine background activity usually are not, because a log so full of noise that nobody reads it protects no one.
Crucially, an audit log is about the action, not the contents. To record that a reply was sent on a ticket at a given time by a given person, you do not need to copy the body of that reply into the log. The metadata, the who and what and when, answers the accountability question on its own. Storing the message itself would only duplicate sensitive content into a second place, which is more risk for no extra benefit.
Why it matters
Accountability you can point to
The first reason audit logs exist is accountability: making it possible to say, with confidence, who was responsible for an action and when it happened.
In a shared mailbox where several people answer from one address, accountability quietly disappears. If a customer is told the wrong thing, or a refund is promised that should not have been, there is often no reliable way to see who sent the reply. The reasonable question "who handled this" has no good answer, which is uncomfortable for the team and unfair on the customer. An audit log restores that answer.
Accountability is not only about catching mistakes. It protects the people doing the work just as much as it protects the business. When a customer claims they were never told something, or that a reply was rude, the record shows what was actually sent and by whom. A fair, dated history is a defence as well as a check, and most teams find it lowers the temperature of a dispute rather than raising it.
What accountability buys a team
- A clear answer to "who did this", instead of a guess or an awkward silence.
- A fair record when a customer's account of events and the team's differ.
- Evidence to resolve internal disagreements about what was actually done.
- A gentle, structural nudge towards care, because actions are attributable rather than anonymous.
- A way for a manager to understand how a tricky ticket was handled without interrogating anyone.
Why it matters
Security and data protection
The second reason audit logs exist is security. When access is misused or data is touched it should not be, the log is how you find out, and how you show what happened.
Security controls decide who is allowed to do what. An audit log is the record of what was actually done within those rules. The two work together: access control is the lock, and the audit log is the record of who turned the key and when. Without the log, a control failure can pass unnoticed, because nothing wrote down that the door was opened.
For UK businesses this is also a data-protection matter. Under UK GDPR, you are expected to handle personal data responsibly and to be able to demonstrate that you do. Being able to show who accessed or changed a customer's record, and when, is part of that accountability. If something does go wrong, a clear audit trail is the difference between explaining precisely what happened and admitting you cannot say.
How audit logs support good security practice
| Detection | Unusual or unauthorised activity leaves a trace that can be reviewed, rather than passing silently. |
|---|---|
| Investigation | If an incident occurs, the log lets you reconstruct the sequence of events and understand its scope. |
| Deterrence | When people know actions are recorded and attributable, casual misuse becomes far less likely. |
| Accountability | You can show, with dated entries, who accessed or changed personal data, which supports UK GDPR duties. |
| Integrity | An append-only record, not casually editable, is harder to quietly tamper with after the fact. |
A subtle but important property is that an audit log should be hard to alter after the event. A record that anyone can quietly rewrite is worth very little, because the moment it matters is exactly the moment someone might be tempted to change it. Treating the log as append-only, written once and not casually editable, is what makes it trustworthy as evidence rather than just a convenience.
Made concrete
An audit trail in action
The easiest way to see the value is to follow a single ticket through its log. Here is an ordinary support ticket, read back from its audit trail.
- A ticket is created when a customer emails the support address. The log records the event, the time, and the ticket it relates to.
- A teammate assigns the ticket to themselves. The entry shows who took ownership and when, so responsibility is now attributable.
- The priority is raised to high. The log notes who changed it and the time, so an escalation is never invisible.
- A reply is sent to the customer. The entry records who replied and when, without copying the message body into the log.
- The status moves to pending while the team waits on the customer, then back to open when they answer.
- The ticket is resolved and closed. The full sequence remains, so anyone reviewing later can reconstruct exactly how it was handled.
Notice what the trail gives you and what it leaves out. It tells you the whole shape of how the ticket was handled, every owner, every change, every reply, in order and with times. It does not tell you the contents of those replies, because it does not need to. That separation, a complete record of actions without a second copy of the words, is what a well-judged audit log is aiming for.
Where Solves fits
How Solves keeps a metadata-only audit history
Solves keeps an audit history of how every ticket is handled, and it does so on the same principle described above: record the actions, not the message bodies.
In Solves, the significant events in the life of a ticket are recorded as a history you can read back: assignments and reassignments, status and priority changes, tags added or removed, replies sent and notes added, alongside the account that performed each one and the time it happened. That gives a small team the accountability described above without anyone having to keep notes by hand.
The history is metadata-only by design. It records who did what and when, against which ticket, but it does not store the body of a customer message, an email address or a payload inside the log. That fits the wider way Solves works: customer support content is encrypted at rest, access is limited to authorised people, and the operational logs are metadata-only too, so sensitive content is not duplicated into places it does not belong.
The result is an audit trail that is genuinely useful for accountability and security, without becoming a second store of the very content you are trying to protect. You can answer "who handled this ticket and when" with confidence, while the words themselves stay where they should be.
Metadata, not message bodies
An audit log earns its value from recording the action, not the content. Solves follows that line: its audit history captures who did what and when on a ticket, while customer message bodies stay encrypted at rest and out of the log entirely.
Keep going
Related terms
A few neighbouring terms come up whenever audit logs are discussed, and they are worth knowing.
| Audit trail | The end-to-end story you can reconstruct from a log's entries, such as one ticket's journey from creation to close. |
|---|---|
| Metadata | Data about an action rather than its content: the who, what and when, without the message body itself. |
| Access control | The rules that decide who is allowed to do what. The audit log records what was actually done within those rules. |
| Encryption at rest | Protecting stored data so it is unreadable without the keys. It guards content; the audit log guards accountability. |
| Support ticket | The single record a help desk creates for one request, and the thing most audit entries are attached to. |
FAQ
Common questions about audit logs
What is an audit log?
An audit log is a time-ordered record of the significant actions taken in a system: who did something, what they did, when they did it, and which record it affected. It is kept so that, after the fact, anyone with a legitimate reason can reconstruct what happened. In a support tool that means tracking events such as a ticket being assigned, a reply being sent, a status changing or a setting being updated.
What is the difference between an audit log and an audit trail?
They are usually used to mean the same thing, with a small difference in emphasis. An audit log is the stored record itself, the list of entries written down as events happen. An audit trail is the end-to-end story those entries let you follow, for example tracing a single ticket from creation through every reply to closure. In short, the audit log is the data, and the audit trail is the path you can reconstruct from it.
What should an audit log record?
A good audit log records who performed the action, the action itself, the timestamp, and the specific record or setting affected. It should capture the meaningful events: logins, permission changes, assignments, status changes, replies sent and configuration changes. It does not need to store the contents of a customer message to be useful. Recording the metadata, who and what and when, is enough to answer most accountability and security questions.
Why are audit logs important for security?
Audit logs are important because they make actions accountable. If access is misused, a setting is changed, or data is touched it should not be, the log shows who did it and when, which both deters careless behaviour and supports an investigation if something goes wrong. They also support data-protection duties under UK GDPR, where being able to show who accessed or changed personal data is part of demonstrating you handle it responsibly.
Does an audit log need to contain the message itself?
No, and often it should not. An audit log is about the action, not the content. Knowing that a particular person sent a reply on a particular ticket at a particular time answers the accountability question without copying the customer message into a second place. Solves takes this approach: its audit history records the metadata of who did what and when, not the body of any message, which keeps the record useful and the customer content protected.
See an audit history that records actions, not message bodies
Solves keeps a metadata-only history of how every ticket is handled, so you always know who did what and when, while customer content stays encrypted at rest.