CDS audit trail review: examples, priorities and decisions

The audit trail report shows no anomalies, yet the CDS contains an interrupted sequence that the report omits. The problem is more than reading the rows carefully: the review scope must demonstrably cover the relevant history. An available record, a performed review and a completed investigation are three different pieces of evidence.

1. Start with the dataset and distinguish the records

Define the decision supported by the review and its samples, sequences, injections, methods and results. Then identify necessary records: acquisition, processing, configuration and security may be distributed across different views or repositories. An access log alone does not reconstruct integration changes; the results report does not document every event.

For each relevant event, connect object identifier, user, date and time, action, previous and subsequent values or versions, and the relevant reason. Understand the time zone and timestamp meaning; sorting an export by date does not by itself establish the correct chronology.

The general foundations of audit trails are covered separately. Here the goal is reconstructing the path of a specific chromatographic dataset without treating every system event as a presumed analytical anomaly.

2. Set scope, responsibilities and frequency

First identify applicable record-review requirements. FDA's 2018 guidance Q7–8 links review of changes to record review and calls for adherence to frequencies specified in relevant CGMP rules. Where frequency is unspecified, risk assessment considers criticality, controls and product impact. Risk does not authorize postponing a required check.

Assign reviewers trained in the method and CDS, with sufficient evidence access and appropriate independence from those who generated or modified the data. QA need not perform the entire review: define departmental activities and quality-unit oversight under the quality system and applicable requirements.

Distinguish operation-related review from periodic review of system events, configurations and privileges. If a system event may affect the dataset under review, connect it to the current assessment; assigning it to a future check is insufficient. No single frequency suits every CDS.

3. Verify that filters and reports do not hide events

Document the sources queried, time interval, time zones, users, projects, statuses and included or excluded event types. Check whether the report shows only completed sequences, approved results or current versions. Also assess pagination, export limits and the ability to return to the original event and data.

An editorial test example uses five known synthetic events: completed acquisition, interruption, reprocessing, method change and authorized role change. Before applying a filter, establish which events must appear in the report and which are reviewed through another record. Compare expected and observed coverage and document differences, not merely row counts.

Design this test in an isolated, authorized environment; it requires neither data deletion nor disabling audit trails. Repeat it when changes to queries, configuration or version affect coverage. Review by exception requires justified criteria and demonstrated reliability: “no exceptions” is meaningful only if selection works.

4. Link each event to a question and action

This original matrix guides review without replacing the procedure or predetermining its outcome. An event may be satisfactorily explained, require more information or trigger an investigation; the software's wording alone does not decide.

To assess peak reprocessing, read the log alongside the signal and method. Repetition, exclusions or post-review changes require context. A failed login, however, does not automatically demonstrate data manipulation: assess identity, subsequent activity and controls.

5. Simulated case and recording the conclusion

A summary shows a completed sequence. Comparison with the acquisition list reveals an earlier interrupted sequence on the same samples. The reviewer checks the filter: it selected only “completed” status. They preserve both sequences and reconstruct performed injections, the interruption reason, restart and results used.

If reconstruction is complete, document the analytical outcome and correct the reporting process through controlled changes. Also assess which earlier reviews may have been affected. If data or reasons are missing, keep the anomaly open and activate the defined escalation. Do not declare review complete because the final sequence passes.

Record scope, sources, report version or search criteria, reviewer, date, evidence consulted, questions, answers, conclusion and investigation links. A signature without scope does not make the check reproducible. Closing a review question does not automatically close an investigation or release a batch.

Periodically reassess the process: changed filters, unrecognized events, training and recurring issues may require updates. Assess conclusion quality and coverage rather than measuring effectiveness solely by rows read.

6. References and applicability

Sources checked on 1–2 October 2026. GMP laboratory context for human medicinal products; simulated examples, no activities on real systems. Operational details depend on the CDS and approved procedures.

• FDA — Data Integrity and Compliance With Drug CGMP, final December 2018, Q1c and Q7–8: definition, responsibilities and frequency. Nonbinding guidance, to be read with applicable CGMP rules.
• European Commission — Annex 11, January 2011 revision, in operation from 30 June 2011, §§9, 12–13: audit trails, security and incidents. The 2025 proposal remains distinct from the adopted text.
• PIC/S — PI 041-1, final 1 July 2021, §9.6: audit-trail configuration, understanding and review. GMP/GDP inspectorate guidance; the matrix above is original and does not reproduce the PIC/S matrix.