How should audit trails and activity history work?
An audit trail records who changed what, when, and what the value was before. Its interface should answer those questions from the record the user is looking at, without an export.
Enterprise buyers and auditors ask about it early, so it affects sales as well as compliance.
Key facts
- An audit trail answers four questions: who, what, when and the previous value.
- Corrections are shown as separate entries linked to the original.
- For electronic records subject to 21 CFR Part 11 in closed systems, 21 CFR 11.10(e) requires secure, computer-generated, time-stamped audit trails, and record changes shall not obscure previously recorded information.
- Logging changes with no screen to read them is a common mistake.
- Enterprise buyers ask about audit early, so its absence can stop a sale.
What it covers
- History reachable from every record
- Old and new values side by side
- Corrections shown as separate entries linked to the original
- Filters by user, date and field
- Exports in a format auditors accept
- A record of permission changes
Who uses it
| Role | Why they open the history |
|---|---|
| Auditor | Works backwards over a past period and needs to know who recorded what, when, and what it was before correction |
| Quality team | Checks a nonconformance or a correction |
| Administrator | Checks who changed permissions or settings |
| Enterprise buyer | Asks during evaluation whether the product can show it |
What makes it hard to design
Logging and reading are different jobs. Logging is done by the backend. The design work is the screen where a person reads the history and understands it.
Labels. Technical field names in the history make it unreadable for business users and auditors.
Corrections. A correction is its own entry, linked to the original. Overwriting values keeps only the latest and destroys the evidence.
Regulated requirements. For electronic records subject to 21 CFR Part 11 in closed systems, the audit trail has to be computer-generated, secure and time-stamped, and record changes shall not obscure previously recorded information.
Auditors and quality teams open history rarely, often with a deadline. Provide clear labels, useful defaults and contextual guidance; training and saved filters can support more complex work.
Trade-offs
Keeping the history of every field is safe, but the timeline gets long and noisy. Grouping changes by action reads better once the team agrees what counts as one action.
Common mistakes
- Logging changes with no screen to read them
- Showing technical field names in place of labels
- Overwriting values so only the latest is kept
- When audit logging is introduced later, check for gaps in historical records and validate coverage of required actions from that point on.
Sources: eCFR, 21 CFR 11.10