Audit trail review that finds things

Most audit trail reviews fail in one of two ways. Either a reviewer scrolls through thousands of entries and signs to say they did, or nobody can say which entries were reviewed at all. Neither will survive the revised Annex 11, which expects audit trails to be reviewed in a targeted and timely way, normally before batch release, by someone who was not directly involved in the work.

Review by exception, done properly

Review by exception is not a shortcut. It is a design decision, documented and justified, about which events carry risk to the record. The system or a validated report pulls those events out; a person reviews each one and records a conclusion.

What belongs in the filter

• Changes to GMP data after first entry, with old and new values and the reason given.
• Deletions, invalidations and re-processing of results.
• Repeated failed logins and use of shared or generic accounts.
• Changes to system clocks, configuration, methods and user privileges.
• Results generated, then not reported.

The five decisions to write into the procedure

1. Scope. Which systems and which audit trails, ranked by their impact on release.
2. Content. The event types reviewed, and the risk reasoning behind the list.
3. Timing. Per batch before release, or periodically for system-level trails.
4. Reviewer. Independent of the work, trained, and able to read the trail in context.
5. Outcome. What is recorded, and when an entry becomes a deviation.

Connected systems need a joined-up trail

Where a result passes from instrument to LIMS to MES to the batch record, the review has to follow the data across systems. That only works if the clocks agree, which is why time synchronisation appears so often in data integrity findings and why we include it in every data flow assessment.