An audit trail has two halves, and almost everyone concentrates on one of them.
Recording gets the attention: capture every action, stamp the user and the time, make it impossible to alter, never allow a deletion. That is what 21 CFR Part 11 is generally understood to be about, and it is what gets designed carefully, reviewed and validated.
Retrieval gets assumed. Of course you can read it back — the records are right there.
Why retrieval is a real risk, not a formality
Part 11 does not only require that records be created. It requires that they be available for agency review and copying throughout the retention period.
A record the system cannot produce is not available. If an inspector asks for every login in a period and the screen returns a list missing some of them, with nothing indicating anything is missing, “it is only a display problem” is not a description that survives the conversation.
And the absence of a warning is what makes it serious. A screen that says “1,204 records could not be displayed” is a defect with a workaround. A screen that silently returns a shorter list produces a document somebody signs.
How this happens: the lookup drifts
Here is the shape it takes in practice, and it is worth understanding because every part involved can be individually correct.
Audit records usually do not store the action name as text. They store a reference to a master list of action types — the right design, because it keeps the records compact and the vocabulary controlled.
Now consider a platform where each customer has their own separate database, which is normal and correct for regulated software. Recording an action looks up its name in one master list. The screen builds its filter from a master list and searches on what it finds there. If those two master lists are not guaranteed to be identical, they will drift apart — quietly, customer by customer, in proportion to how long that customer has been live and how many capabilities they use.
The result is audit records that were captured correctly and cannot be displayed. Not in the filter. Excluded by every other selection. Present in the database, invisible on the screen.
Nothing in that chain is wrong on its own terms. The records carry the right reference. The screen searches correctly. The filter is built accurately from what it can see. The defect lives in an assumption held between two parts — and where there is only one database, that assumption is trivially true, which is why it survives design review.
Why the usual testing does not catch it
Both halves pass their own tests, because both halves are correct.
Testing runs against a freshly created database, which by definition has a complete master list. The problem only appears in a customer environment that has been live long enough for the two lists to diverge — which is to say, in production, and never where testing happens.
This is the shape of the most expensive class of defect in this kind of software: correct parts, an assumption that spans them, and a test environment where the assumption happens to hold.
How to test for it
The good news is that it is cheap to check.
- Count the audit records whose action type does not appear in the list your screen reads from. A single check. The number is either zero, or it is a finding.
- Confirm that recording and reading use the same master list. If one uses a central list and the other uses the customer’s own, you have this problem waiting to happen.
- Run it for every customer, not just the one you demonstrate with. The whole point is that it drifts customer by customer.
DnXT runs this as a standing check across every customer environment rather than as a one-off, because a problem that appears through drift will reappear through drift.
Make an unreadable record loud
The design rule that matters most here is not about the lookup at all.
A screen should say that a record could not be displayed rather than leaving it out. Silently leaving it out is what turns a technical defect into a compliance exposure, because it removes the only signal that anything is wrong. The same principle governs the rest of the platform — a check that did not run is never shown as passed, a failed search is never shown as no results — and the audit trail is where it counts most.
And if you find something, repair by adding only
One more rule, for anyone who runs the check above and does not like the answer.
A repair to an audit trail must only ever add. Complete the master list so the existing records can be found. Never change or delete the audit records themselves — a repair that modifies audit data is not something anyone should be willing to run, whatever it claims to do. The records were right; the list they are read through was incomplete, and only that should be touched.
And resist the urge to reach zero. If one record genuinely refers to something that no longer exists anywhere, leave it and document it. Inventing an entry so a number reaches zero is manufacturing evidence rather than repairing it. One unexplained record, explained, is a better position than a clean report resting on something you made up.
The uncomfortable summary
An audit trail is only as good as your ability to read it back, and almost nobody tests that against real production data.
Check that what you recorded can still be produced — for every customer, not just the one in the demonstration environment. It is an hour of work, and it is the difference between having records and being able to show them.
DnXT builds eCTD publishing, submission planning, document management and dossier review software for regulatory operations teams. Book a demo to see an audit trail you can actually produce on request against your own submissions.
