Chromatography Data System Audit Trails: What Must Be Captured, and Review by Exception

A chromatography data system (CDS) audit trail has to answer a narrower question than a general electronic-record audit trail: not just “who touched this record,” but “does the final reported result reflect every injection that was actually run, and every change made to how those injections were integrated.” That distinction is why CDS audit trails draw a disproportionate share of FDA 483 observations and warning-letter citations relative to other lab systems — the failure mode isn’t usually a missing signature, it’s a chromatogram that was run, didn’t give the desired result, and never made it into the reviewed record. This guide sets out what a CDS audit trail specifically has to capture, where manual integration is legitimate versus where it becomes data manipulation, and how a risk-based review-by-exception programme — the approach regulators actually accept, as opposed to a literal reading of “review the audit trail” as reviewing every entry — is built and documented.

For the general electronic-records/signatures rule this all sits under, see 21 CFR Part 11 and FDA’s Data Integrity Guidance for cGMP, which covers the audit-trail definition and review-frequency principle in general terms. This page applies that framework specifically to chromatography software (Empower, Chromeleon, OpenLab, LabSolutions and equivalents) rather than restating it generically.

The regulatory basis, applied to a CDS specifically

21 CFR 11.10(e) requires closed systems to use secure, computer-generated, time-stamped audit trails that independently record the date, time, and content of operator entries and actions that create, modify, or delete an electronic record — retained for as long as the underlying record and available for inspection. EU GMP Annex 11 §9 frames the same expectation in risk-based terms: “consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions,” with the trail “available and convertible to a generally intelligible form and regularly reviewed.” Neither clause is chromatography-specific — both were written for electronic records generally — but a CDS is one of the systems inspectors check most literally against them, because a chromatographic result is unusually easy to alter without leaving an obvious trace on the final report: reprocessing a peak with a different baseline, or simply not saving an injection that failed, changes the number without changing anything a reviewer sees unless the underlying electronic record — not the printed or PDF report — is what gets reviewed.

FDA’s own framing of this, from its December 2018 Data Integrity and Compliance With Drug CGMP: Questions and Answers guidance, is the clearest single sentence connecting paper and electronic practice: “Audit trail review is similar to assessing cross-outs on paper when reviewing data.” The audit trail definition it uses is worth quoting directly too, since it’s the standard a CDS’s own audit-trail feature is measured against: “a secure, computer-generated, time-stamped electronic record that allows for reconstruction of the course of events relating to the creation, modification, or deletion of an electronic record.” A CDS audit trail that can be disabled, that doesn’t independently timestamp, or that can be edited by the same account it’s recording, does not meet that bar regardless of what the vendor’s marketing calls it.

What a CDS audit trail actually has to capture

A defensible CDS audit trail configuration captures, at minimum, all of the following as discrete, attributable, timestamped entries — not just a change log summary:

• The full injection sequence, including every injection that was run — not only the injections that made it into the final reported set. An aborted run, a system-suitability failure, a “trial” or “test” injection run before the official sequence, and an injection later excluded from quantitation all need to remain visible in the electronic record with a reason for exclusion, not simply be absent from the results the analyst reports.
• Processing method identity and version for every result — which processing method was applied, when it was last modified, and by whom. A result is not traceable if the processing method used to generate it can change after the fact without the change being tied to the specific result it affected.
• Integration parameter changes — peak start/stop thresholds, baseline placement, noise and slope-sensitivity settings, smoothing — logged individually rather than as an undifferentiated “method edited” entry, so a reviewer can see exactly what changed between one integration and the next.
• Manual integration events, flagged distinctly from automatic (method-driven) integration, each with the operator, timestamp, and a recorded justification — see the section below on why this specific entry type gets the most inspection attention.
• Reprocessing and reintegration events, linked back to the original result rather than replacing it — the original integration has to remain retrievable, not be overwritten, so a reviewer can compare before and after.
• Sequence and sample-set changes — reordering, renaming, or deleting a sample within a run sequence after acquisition.
• System-level events that affect the trail’s own integrity: instrument or workstation clock changes, user account and privilege changes, and any change to the audit trail configuration itself (which fields it logs, whether it can be turned off for a given module).
• User identity and role for every entry — a shared login, or an audit trail that records only “System” as the actor, defeats the independence requirement in 11.10(e) regardless of how complete the rest of the log is.

The common thread across FDA and MHRA data-integrity findings in this area is that the electronic record — the acquired chromatogram plus its full processing and audit-trail history inside the CDS — is the raw data, and a PDF or printed report generated from it is a report, not the record. A quality system that reviews only the printed report and never opens the CDS to check what else exists behind it cannot detect an unreported injection or an unexplained reintegration, because neither leaves a mark on the printout.

Manual integration: where it’s legitimate, and how to control it

Manual integration is not itself a data-integrity violation — chromatographic peaks routinely need a human decision at shoulders, tailing, co-elution, or baseline noise that an automatic algorithm handles poorly. What separates a legitimate manual integration from a finding is whether it’s controlled and justified rather than undisclosed and outcome-driven. A defensible SOP for manual integration typically requires:

• Automatic (processing-method-driven) integration as the default, with method parameters set and locked wherever a compound’s peak shape allows it, so manual intervention is the exception rather than the routine path to a result.
• A documented, scientifically sound reason recorded at the point of manual integration — not added retrospectively — describing the chromatographic feature that required it.
• Retention of both the original (automatic) and the final (manually adjusted) integration, so a reviewer can see the delta, not just the outcome.
• Independent second-person review of manually integrated chromatograms specifically, rather than folding them into the same spot-check rate applied to automatically integrated results.
• Periodic trending of how often manual integration is used, by analyst and by method — a rate that climbs for one analyst or one method, or that correlates with which direction it pushes results (toward passing), is the pattern an inspector looks for and a quality unit should be looking for first.

What turns manual integration into a data-integrity problem is testing into compliance: reintegrating a peak specifically because the first result was out of specification, without a chromatographic justification independent of the numeric outcome, and without documenting the earlier attempt. The audit trail is what makes that pattern visible — which is the whole argument for reviewing it, and for reviewing it in a way that’s actually practical to sustain.

Review-by-exception: what regulators actually accept

Read literally, “the audit trail must be reviewed” sounds like every logged entry needs a human to look at it before a batch releases. For a busy CDS instance generating thousands of timestamped entries a day, that’s not a documentation nicety regulators expect — it’s operationally impossible, and neither FDA’s nor PIC/S’s guidance asks for it. FDA’s December 2018 Q&A ties audit-trail review frequency to whatever frequency CGMP already prescribes for the underlying record — for example, review at each significant manufacturing or testing step, or before batch release — and where no frequency is prescribed, to a documented risk assessment covering data criticality and the control mechanisms already in place. PIC/S PI 041-1 (Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments) sets out the same risk-based expectation for the wider GMP/GDP data landscape. Neither document asks for a manual read of the complete raw log.

A review-by-exception programme is how that gets satisfied in practice: instead of a reviewer reading every audit-trail entry, the CDS (or a connected data-review layer) is configured to surface only the entries that are actually decision-relevant, and the human review is targeted at those. For chromatography specifically, that exception set typically includes:

• Every manual integration event, with its recorded justification, for the reviewer to assess against the chromatography rather than re-derive from scratch.
• Every reprocessing/reintegration event, paired with the original result.
• Deleted, aborted, or excluded injections, and the stated reason for exclusion.
• Processing method changes made after the official run, and any change to a locked or GMP-relevant method.
• System-clock changes and any change to the audit-trail configuration itself.
• Failed system-suitability or out-of-specification results and what happened to the sequence afterward.

Everything outside that set — routine, expected, automatic-integration entries that never deviated from the locked method — doesn’t need individual sign-off; its presence in an intact, tamper-evident trail is itself the assurance. What has to be documented is the review that did happen: who performed it, against which exception criteria, for which batch or result set, and what (if anything) it found — a review-by-exception SOP that exists but produces no retrievable record of having been executed is functionally the same, to an inspector, as no review at all.

Two structural choices decide whether review-by-exception is sustainable rather than theoretical. First, the reviewer has to be independent of the analyst who generated the data — typically QA, not the same bench scientist who ran the sequence — so the review isn’t self-certifying. Second, the CDS itself needs the exception-reporting capability built in (most modern platforms — Empower, Chromeleon, OpenLab CDS — support a configurable audit-trail or exception report filtered to event type); where a CDS lacks that capability, review-by-exception either has to be assembled through a validated report query or the site is, in practice, still doing a full manual read regardless of what the SOP claims. That capability question belongs in the system’s own validation documentation — see computer system validation (CSV/GAMP 5/IQ-OQ-PQ) and, for the requirement that should have specified it up front, writing a user requirements specification.

Building this into the validation and quality system

Audit-trail review-by-exception isn’t a standalone SOP floating separately from the rest of a CDS’s compliance documentation — it belongs inside the same structure that governs everything else about the system:

• The CDS’s own validation should confirm the audit trail cannot be disabled by a standard user role, that entries are independently timestamped from a controlled system clock, and that the exception-report function itself produces complete, accurate output — tested, not assumed. See computer system validation for the IQ/OQ/PQ structure this typically sits inside, and IQ/OQ/PQ for the underlying terms.
• The site’s validation master plan should list the CDS as an inventoried GMP-relevant system with its own periodic-review cadence, rather than treating audit-trail review as a one-time validation deliverable. See the VMP guide.
• Where the CDS runs under an EU framework rather than (or alongside) FDA jurisdiction, the audit-trail expectations map to Annex 11 §9 and §12.4 rather than 11.10(e) directly — see EU GMP Annex 11 and Annex 15 for how the two frameworks compare.
• If the lab is also validating an electronic lab notebook alongside the CDS, the same review-by-exception logic — and the same “audit trail that can be disabled defeats the point” caution — applies there too; see ELN validation under 21 CFR Part 11.

None of this replaces general chromatographic method competence — see the HPLC guide and HPLC method development for the underlying technique — but a method that’s scientifically sound and a CDS configuration that’s data-integrity-sound are two separate things to get right, and an inspection finding usually lands on the second even when the first was never in question.

FAQ

Is manual integration prohibited under GMP?

No. It’s a normal part of chromatographic data review when a peak’s shape genuinely requires human judgment. What’s expected is that it be the exception rather than the default path to a result, justified in writing at the time it happens, retained alongside the original automatic integration for comparison, and independently reviewed — not that it never happen.

What counts as “raw data” for a chromatography result?

The acquired chromatogram together with its full processing history and audit trail inside the CDS — not the PDF or printed report generated from it. A report can look complete and correct while omitting an injection that was run and excluded, or a reintegration that changed the reported value; only the underlying electronic record shows that.

Does every audit-trail entry need to be reviewed before batch release?

No — and FDA’s own December 2018 data-integrity guidance doesn’t ask for that. Review frequency should match whatever CGMP already prescribes for the underlying record, or a documented risk assessment where none is prescribed. A well-built review-by-exception programme, scoped to manual integrations, reprocessing events, deletions/exclusions, and configuration changes, is what regulators accept in place of a full manual read of every logged entry.

Who should perform CDS audit-trail review?

Someone independent of the analyst who generated the data — typically QA rather than the bench analyst — so the review isn’t self-certifying. The review itself, including who performed it and against what criteria, needs to be documented and retrievable; an SOP that exists on paper but leaves no record of having been executed doesn’t satisfy the requirement.

Does every CDS support review-by-exception out of the box?

Most current major platforms (Empower, Chromeleon, OpenLab CDS and equivalents) offer a configurable audit-trail or exception report that can be filtered to specific event types. Where that capability is absent or unvalidated, a site attempting review-by-exception without it is, in practice, either doing a full manual read or leaving gaps — verifying the exception-report function itself belongs in the system’s own validation, not assumed from the vendor’s feature list.