Audit trail design for internal processes

Direct answer

An audit trail is a record the system writes by itself each time something important changes, so that "who did what and when" can be answered from the record instead of from memory. Designing one means deciding which events count, what each entry contains, who may read it, and how mistakes are corrected without erasing history. This page is a design checklist for internal tools. It is not a statement that any trail meets a legal, regulatory or certification standard; whether it does depends on your obligations and is a question for your own advisers.

Which events to record

Record changes that carry a decision or a risk, not every click:

• Approvals, rejections and returns
• Changes to status, owner or amount
• Changes to who has access, and to roles
• Deletions and restorations
• Sign-ins to sensitive areas, if your team needs that
• Exports of records

Actor, time, before and after

Each entry should hold four things: the person or system that acted, the time, what changed, and the value before and after. The time comes from the server, not from the user's device. If automation makes a change, record it as the actor, so you can tell a human decision from a rule. Without the before value, an entry says something happened but not what was lost.

What to keep out

A trail is itself a store of sensitive information, so be deliberate. Avoid copying passwords, tokens, full payment details or unnecessary personal data into it. Where a value is sensitive, record that it changed rather than what it was. Keep free-text notes short and decide who may write them. The less the trail holds, the lower the cost of protecting it.

Who can read it

Reading the trail is a permission of its own. Most staff do not need it; a manager may see the trail for their own area; an owner or administrator may see all of it. Nobody should be able to edit or delete entries through the normal interface. This ties directly to how you set up roles and permissions.

Corrections versus deletions

When a record is wrong, the fix is a new entry that corrects it, with a reason, not a rewrite of the old one. Deleting an entry defeats the purpose. If some data must eventually be removed, that is a separate, documented action that is itself recorded.

Export and retention

Decide how the trail can be exported, for example for a review or a dispute, and who may do it. How long entries are kept is a decision for your organisation and its advisers, not something we set. We build the trail so that whatever period you choose can be applied. See internal approval workflow automation for how approvals produce the entries.