Audit Trails: What Your System Should Be Recording Right Now

Nobody looks at an audit trail on a good day. You look at it on the day a client's general counsel asks who at your firm opened a document that was supposed to be walled off, or the day a departing associate's laptop turns up with a folder of matter files on it and you need to know what they actually pulled before they left, or the day a fee dispute lands and the client's position is that an entry on the invoice was edited after the fact. In every one of those situations the question is the same and it is brutally simple. Who did what, to what, and when. And the whole value of your practice management software in that moment comes down to whether it happened to be recording the thing you now need.

That is the uncomfortable part. An audit trail is not a feature you use, it is a feature you either had switched on and configured correctly months before the problem, or you did not. There is no retroactive capture. You cannot go back and ask the system to remember who viewed a matter in March if it was never storing read events in the first place, and you will not find that out until March matters. Firms discover the gap at the worst possible moment, in front of the person who is asking the question, with nothing to offer but a recollection.

So this is a piece about what should be in the log right now, before anyone asks. Not the marketing version of an audit trail, which usually means a page that shows the last few things somebody typed, but the version that actually holds up when a regulator, an insurer, a client or opposing counsel is the audience. That means reads as well as writes, corrections that stay visible instead of vanishing, identity attached to every entry, and a retention policy for the trail itself that outlives the matter it describes.

The question an audit trail actually has to answer

Start from the end and work backwards, because that is the only way to know what to capture. The questions that get asked of a law firm's records are narrow and repetitive. Did anyone outside the matter team access this file. Was this time entry created on the day the work was done or reconstructed six weeks later. Did the trust disbursement match the client's instruction at the time it was made, or was it adjusted afterwards. Was this document the version the client signed, or a later one with the same filename. Every one of those is answered by a record of an action, an actor, an object and a timestamp, and if any of the four is missing the answer is a shrug.

Most systems capture two of the four reasonably well. They know the object and roughly when something happened, because the record has a modified date on it. What they lose is the actor and the specific action, so you end up with a matter that says it was last updated on 14 August by "system" or by a shared login that four people use, which tells you nothing you can put in a letter. If your firm has a single admin account that the receptionist, the bookkeeper and the office manager all sign into, your audit trail has a hole in it the size of your back office, and no amount of logging fixes it, because the log is faithfully recording an identity that does not correspond to a person.

Reads are the half nobody records

Almost every practice management system logs writes, because writes change data and the database has to touch the row anyway. Far fewer log reads, and reads are exactly what you need in a confidentiality incident. When a client asks whether their file was accessed by someone who should not have seen it, or when you are trying to establish the scope of an internal breach, the write log is useless, because the person who improperly viewed a privileged memo did not change anything. They opened it, read it, and closed it, and in most systems that leaves no trace whatsoever.

This is the gap that turns a small internal problem into a large disclosure problem. Without read logging you cannot say what was accessed, so you are forced to assume the worst and notify on the widest possible basis, which is more painful, more expensive and more damaging to client relationships than a narrow, evidenced answer would have been. Read logging also does something quieter and more useful day to day, which is that it makes access boundaries testable. In Casely, ethical walls are enforced at the server and data-access layer rather than by hiding things in the interface, so a walled user genuinely cannot reach a restricted matter through search, the calendar, or a link a colleague forwarded them. The point of a read log alongside that is that you can demonstrate the wall held, rather than asserting it.

Write records are only useful if they say what changed and why

A log line that reads "document updated by J. Okafor at 09:41" is better than nothing and much worse than it looks. It tells you an event occurred. It does not tell you whether the change was a typo fix in a heading or the removal of an indemnity clause, and six months later, when the person who made the change has moved firms, nobody can reconstruct it from memory. A trail that records only that something happened forces you to diff two versions manually and guess at intent, which is exactly the work you were hoping the log would save you.

The fix is to capture the why alongside the what, at the moment of the change, from the person making it. Every document in Casely carries a comment field that records what changed and why it changed, attached to that version rather than floating in a separate notes area, so the reasoning travels with the file. It sounds like a small piece of discipline and it is the single highest-value habit a firm can build into its document workflow, because it converts an unreadable sequence of version numbers into a narrative that a partner, an insurer or a court can follow. Version history answers what the file looked like. The comment answers why anyone touched it.

Why voided beats deleted, every time

Here is the principle that separates a defensible system from a merely tidy one. When something is wrong, you correct it by adding a record, never by removing one. A deletion leaves a hole in the sequence and a hole is indistinguishable from concealment, no matter how innocent the original mistake was. A void leaves the original entry visible, marks it as reversed, records who reversed it and when, and adds the corrected entry alongside. Anyone reading the trail later sees the whole story, including the error, and an error you can see is far less alarming than a gap you cannot explain.

This matters most in the ledger, and it is worth understanding why regulators think this way. Accounting rules for client money in most common-law jurisdictions are built around the idea that the record is contemporaneous and continuous, so an entry that disappears is a bigger problem than an entry that was wrong. Casely enforces this structurally. Corrections to trust entries are voided and stay visible, never deleted, and the original remains part of the matter's isolated ledger with the correction sitting next to it. If you have ever sat through a reconciliation where somebody deleted a duplicate entry to "clean it up" and then could not explain why last month's closing balance no longer agrees with this month's opening figure, you already know what the alternative costs.

The trust ledger is where this gets tested first

If your firm ever faces a formal examination of its records, it will start with client money, and the audit trail on the trust side is examined harder than anything else you hold. Requirements differ significantly by jurisdiction, so confirm your own before you rely on any general statement. State bar trust accounting rules across the United States, the SRA Accounts Rules in England and Wales, provincial law society rules in Canada, and state and territory regulations in Australia all impose their own retention periods, reconciliation frequencies and record formats. What they share is an expectation that the ledger is complete, that every movement is traceable to an instruction, and that nothing was quietly removed.

That expectation is a lot easier to meet when the software makes the failure mode impossible rather than merely discouraged. Casely blocks any disbursement that exceeds a matter's actual trust balance at the database transaction level, not as a warning dialog that a tired bookkeeper can click through at six in the evening. The difference shows up in the audit trail. A system that warns produces a log full of overdrafts that somebody approved, and now you are explaining each one. A system that blocks at the transaction layer produces a log where the overdraft never happened, because the write was never committed, and the attempted action is what gets recorded instead. That is a much shorter conversation with an examiner.

Timestamps, identity and the boring metadata that decides a dispute

The metadata that wins arguments is the metadata nobody thinks about until it is missing. Time zone is the classic one. A firm in Toronto working with co-counsel in London and a client in Sydney will eventually argue about whether a filing or a signature landed before a deadline, and a log that stores local time without an offset cannot settle it. Store events in a single canonical time reference and display them in the viewer's local time, so the record is unambiguous even when the people reading it are not in the same country.

Identity needs the same rigour. An entry should carry the account that performed the action, not just a display name that can be edited later, so that renaming a user or reassigning a departed employee's account does not silently rewrite three years of history. And the trail should record the action's context, meaning the matter it belongs to and the route the request came through, because "accessed via the client portal" and "accessed by a firm user from the matter file" are materially different facts. Casely's client portal filters privilege automatically per document and handles e-signature inside the same login with no separate account, which keeps the client's side of the trail in one continuous sequence instead of scattered across a signing vendor's system and your own.

Retaining the trail itself, not just the file

Firms think hard about how long to keep client files and almost never think about how long to keep the log describing what happened to them. This is a real gap, because the trail is frequently the thing you need after the file has been closed and archived. A malpractice claim can surface years after a matter concludes, and the question at that point is often procedural rather than substantive, meaning who had access, when was the advice given, what was sent to the client and when. If your audit data was purged on a ninety-day rolling window because that was the default nobody changed, the file survives and the story around it does not.

Retention periods vary by jurisdiction and by the type of record, and trust records almost always carry a longer requirement than general matter files, so check your own regulator rather than adopting a number you read somewhere. The practical rule is that the audit trail should be retained at least as long as the records it describes, and preferably longer, because the trail is small and the cost of keeping it is trivial compared to the cost of not having it. Also confirm what happens to logs when you close a matter, when you offboard a user, and when you leave a vendor. A user deletion that cascades and removes that person's log entries is a catastrophic default, and more than one system has shipped exactly that.

The day you discover the trail was never captured

Every firm that has been through this describes the same sequence. Something happens, usually small. A client says they never received a document, or a partner notices a matter opened in a practice group it does not belong to, or the bookkeeper finds a transfer that nobody can attribute. Someone says, reasonably, let us just check the log. And the log turns out to contain the last thirty days, or only edits and not views, or entries attributed to an account four people share, and the thing you needed is simply not there. The problem stops being the original incident and becomes the fact that you cannot answer a straightforward question about your own systems.

What makes this worse is that it is not usually a vendor failure, it is a configuration decision made during onboarding by someone who had eleven other things to set up that week. Logging levels get left at default, retention gets left at default, everyone gets an admin role because it was faster than working out permissions on day one, and none of it is revisited because nothing goes wrong for two years. The fix is unglamorous. Open the audit log in your current system today, on a real matter, and try to answer a question you would actually be asked. If you cannot, you have found the gap while it is still cheap.

Who is allowed to read the audit log

An audit trail is sensitive material in its own right, and it deserves the same access discipline as the records it tracks. It shows who worked on what, when people were logged in, which clients a particular attorney has been looking at, and how long a matter sat untouched. In the wrong hands inside the firm, that is a performance-management weapon or a leak waiting to happen, and it can also cut straight through an ethical wall, because knowing that a colleague accessed matter 4471 fourteen times tells you something about matter 4471. Restrict log access to the small number of roles that genuinely need it, typically a managing partner, a firm administrator and whoever handles compliance.

There is a second-order point worth stating plainly. The people who can read the log should not be the people who can edit it, and ideally nobody can edit it at all. An audit trail that an administrator can amend is a document, not evidence, and the moment its contents are challenged the first question will be who had the ability to change it. Immutability is what gives the record its weight. Casely's document layer sits behind AES-256 encryption with a per-firm key, and the same principle applies to the trail, which is that the value comes from the record being tamper-evident and complete rather than from it being conveniently editable when the contents are inconvenient.

What good looks like on an ordinary Tuesday

None of this should feel like an exercise. On a normal week, a properly configured trail is invisible and does small useful things constantly. A paralegal wonders which version of an agreement went to the client and reads the comment on the version rather than emailing three people. A partner reviewing a matter before a hearing sees that a key document was updated two days ago and by whom, so the pre-hearing conversation starts from the current position. A bookkeeper reconciling client money sees a void with a reason attached instead of a mysterious balance change, and the reconciliation takes twenty minutes instead of an afternoon.

It also changes what happens when someone leaves. Offboarding an attorney with a clean trail means you can establish exactly what they accessed in their final weeks, hand over their matters with the history intact, and answer any client question about continuity with specifics rather than reassurance. Conflict checking in Casely searches the full contact and matter history including closed matters and every role a party played, and that same instinct, that history is an asset rather than clutter, is what an audit trail is for. The firms that treat the record as disposable are the ones that end up reconstructing it under pressure.

Go and look at your log this week

The honest summary is that audit trails are a preparedness problem dressed up as a technical one. The software either records reads, attributes actions to individuals, preserves corrections as voids, captures reasons alongside changes, and keeps all of it long enough to matter, or it does not, and the day you find out is the day it is already too late to change the answer. It takes about an hour to test this properly. Pick a matter, pick a document, pick a trust entry, and try to reconstruct their history from the log alone, then see which of the four elements, actor, action, object and time, your system actually gave you.

If the exercise turns up gaps, fix the cheap ones first. Individual logins, no shared accounts, a retention setting that matches your jurisdiction's record-keeping rules, and a habit of writing one line of reasoning whenever a document changes will move a firm further than any amount of software evaluation. Then look at whether your platform enforces the structural pieces or merely suggests them, particularly around client money, because that is where the standard is highest and the tolerance for a missing record is lowest. Our trust accounting software for law firms page covers how the void-not-delete rule and the transaction-level balance check work in practice, and the legal document management software page covers the version and comment side of the same idea.

Casely is cloud-native with nothing to install, there is a free plan to start at $0, and the fastest way to judge any of this is to open the audit log on a real matter and see whether it answers the question you would actually be asked. Rules on retention, trust records and client confidentiality differ across jurisdictions, so confirm the specifics with your own bar, law society or regulator before you finalise a policy. The trail is written long before you need it, which is exactly why it is worth checking today rather than on the day somebody asks.