Resources / Records, Audits & Public Accountability / Audit trail requirements

What does an audit trail actually have to show?

The short answer

An audit trail is a chronological record of who did something, when they did it, and what the result was, for a specific document or decision. On paper, in email, or in a system that doesn't route the work itself, that record depends on someone remembering to write it down, which means it's usually incomplete before anyone needs it. The gap doesn't show up during a normal week. It shows up the day a records request arrives, an auditor asks for documentation, or a decision gets challenged and there's a hole exactly where the proof should be. Doing it well means the trail exists automatically, because it's a byproduct of how the work already moves, not a separate record someone has to maintain.

On this page

Why an audit trail usually has a hole exactly where you need it How most offices actually keep track today Where it falls apart

What doing it well actually requires Common questions How Flow Forms handles it

Why an audit trail usually has a hole exactly where you need it

Most audit trails are a log of the parts someone remembered to record, not a record built into how the work moves. A spreadsheet tracks who signed off, until the week someone forgets to update it. Even a system that does log actions usually built that log to serve its own function, not to answer a records request or survive an audit, so it turns out to be thin exactly where a real challenge would test it.

How most offices actually keep track today

In practice, the trail behind an internal approval is scattered across whoever handled each step: an email confirming a signature, a printed form in a folder, a note on a desk, a spreadsheet someone updates by hand when they remember to. Each person knows their own piece of it. Nobody has actually put the whole sequence together into one record, because nothing has needed it to exist yet.

Where it falls apart

It falls apart the day someone needs the trail to be complete: a citizen files a public records request, a state auditor asks for documentation, or a decision gets challenged and someone has to show exactly who approved what and when. That turns a scattered trail into hours of reconstruction work, tracking down whoever handled each step and hoping they remember or kept a copy. Sometimes the record simply doesn't exist, because nobody thought a routine approval would ever need one.

What doing it well actually requires

A usable audit trail has three properties, and they're the ones a manually kept record usually can't guarantee.

It names who did it, not just that it happened

Every step routed through Flow Forms carries the person who took the action and the exact time, to the minute, that they took it. That isn't a setting someone has to remember to turn on. It's what happens by default when an approval routes through the system instead of around it.

It exists whether or not anyone thought to ask for it yet

Because the record is a byproduct of how the work already moves, not a separate log someone maintains, it's already there before the request arrives. Nothing has to be reconstructed afterward from memory or scattered paperwork.

It can be handed over as a record, not walked through as a story

When a more formal record is actually needed, whether that's an audit, a dispute, or a records request, the full history behind any submission can be pulled and exported as a batch file. It's a document someone can hand over, not an explanation someone has to give.

Common questions

Questions we hear from every office that has to prove what happened.

Does an audit trail need to show who did something, or is it enough to know that it happened?

For most purposes that matter, who did it is the actual answer being asked for. Knowing a step occurred tells you the process moved. The moment someone disputes a decision or a request asks who approved something, the record needs a named person and a time attached to the action, not just a status.

Why isn't keeping the paperwork the same as having an audit trail?

The paperwork shows what was decided. It doesn't usually show the sequence: who saw it first, how long it sat, who acted on it next, and when. An audit trail is that sequence, not the document that came out of it.

Can an audit trail be put together after the fact, if nobody was tracking it in real time?

Sometimes, from whatever fragments still exist: emails, printed copies, someone's memory of the order things happened. Reconstructing it after the fact takes real time and depends on which fragments survived. A trail generated automatically as part of the routing itself doesn't need to be rebuilt, because it was already there.

Does Flow Forms apply the same level of detail to every approval, or can it be adjusted for higher-stakes processes?

The baseline record, who did it, when, and what happened, applies to everything by default. What can be adjusted is what additional information gets captured for a specific process, a setup decision an office makes once, not something handled case by case as approvals come through.

How Flow Forms handles it

Every approval routed through Flow Forms already carries this history: the person, the action, and the exact time, recorded automatically as part of how the process moves, not as a separate step someone has to remember. When a formal record is needed, that history can be pulled and exported as a complete file, ready to hand over rather than reconstructed from scratch.

See how it would work for your office →