A compliance audit trail is a record that lets someone reconstruct what happened, in order. For a research supplier, that means being able to show, for any order, which controls were in force, what the buyer declared and signed, whether the order was held and who released it, and what was paid, shipped and refunded. It also means showing who changed the controls themselves, and when.
This guide covers what to record, when, who should be named in each entry, and how to keep the result consistent and easy to review.
What an audit trail is for
NIST's glossary defines an audit trail as a chronological record that allows the sequence of activities surrounding an operation or event to be reconstructed and examined from beginning to end. The key words are chronological and reconstruct. A folder of screenshots is not an audit trail unless someone can put the events in order and see how each one led to the next.
You will use it in a few situations: answering a dispute, responding to a processor's questions, checking your own controls, and working out what went wrong when something does. In each case the reader wants two things: to follow one order from start to finish, and to see which rules applied at the time.
What to record
Order-level events
- Site entry. Any declarations the visitor confirmed at a researcher gate, with the time and the version of the wording.
- Buyer details and checks. What the buyer provided, such as organization, role and ship-to address, and the result of each check.
- Signed statements. The exact statement signed at checkout, its version and the time of signature. See buyer attestations, explained.
- Holds and reviews. Which rule held the order, who reviewed it, what they looked at, what they decided and why.
- Payment events. Authorization, capture, refund and dispute events, each with the processor's reference.
- Fulfillment. Ship date, carrier, tracking number and lot.
- Communications. Messages with the buyer that relate to the order.
Control-level events
- Compliance settings. Changes to who you sell to, gate settings, statement wording and hold rules.
- Storefront content. Changes to product pages and policies.
- Access. People added or removed, and role changes.
Some of this already exists in the tools you use. Stripe's user roles documentation lists security history audit logs that several Dashboard roles can view, and Radar keeps a rule activity log showing when a rule was created, edited, enabled or disabled and by which user. Know where those logs are and how far back they go, and link to them rather than copying them by hand.
When to record
Record each event when it happens, automatically where you can. Records written up later from memory are less reliable and harder to defend.
- Use one consistent time zone for timestamps, and say which one.
- If you need to add context afterwards, add a new note marked with the date it was written. Do not edit the original entry.
- Record decisions at the moment they are made, including the reason, not just the outcome.
Who: name the actor
Every entry should say who or what did it: a named person, or a named system such as the checkout or a monitoring job. That only works if each person has their own login. Shared admin accounts make it impossible to tell who approved an order or changed a rule.
Give people the access their job needs and no more. Compliance roles for small teams sets out a simple owner, admin and reviewer split that works even with two or three people.
Keep records consistent
- Same fields every time. A hold record should always have the rule, the reviewer, the decision, the reason and the time.
- Same reasons. Use a short, fixed list of reasons for holds, refusals and refunds, with free text for detail.
- Same identifiers. Link every record to the order ID and the processor's payment ID, so nothing has to be matched by name or date.
- Versions, not overwrites. When policy or statement wording changes, keep the old version and record which version each order saw. See versioning your policies and checkout statements.
Make records reviewable
A record nobody else can read is not much use in a review. Stripe's dispute evidence guidance gives advice that works well beyond disputes: present events in chronological order, group evidence by type, include a brief summary of what each item shows, and make sure text and images are legible.
- Make sure you can export any date range without manual editing.
- Pair raw records with a short summary of the controls in force during that period.
- Protect the record from quiet editing. An append-only, tamper-evident log shows whether entries were changed after the fact. Tamper-evident records, explained covers how that works.
Common gaps
- Only the current state is kept, such as today's policy text, with no history.
- Admin actions happen under a shared login.
- Records are spread across email, spreadsheets and store plugins, with no common order ID.
- Review decisions are recorded without reasons.
- Notes are edited in place, with no record of the original.
What an audit trail cannot do
An audit trail records what happened. It does not make a weak control strong, and it does not turn a buyer's self-declaration into verification. If a record shows that consumers regularly passed your checks, the trail has done its job by showing you the problem. The fix is to change the control.
Claddr stores every step, from buyer checks and signatures to holds and payments, against the order, and chains each entry to the one before it so a later change breaks the chain. Admin actions are logged too. How Claddr's audit record works explains the export format.