If you read FDA warning letters to quality control laboratories, the same system keeps appearing: the chromatography data system. Not because CDS software is unusually weak, but because it sits right where data integrity pressure is highest, at the point where a result decides whether a batch is released.
This is a practical view of what CDS validation needs to cover, and where it usually falls short.
Why CDS gets so much attention
A chromatography result goes through several steps where a person can influence it: setting up the sequence, choosing integration parameters, reprocessing, and deciding which runs count. Each step is legitimate. Each can also be misused, and from the outside the misuse can look identical to normal work.
So inspectors look less at whether the software calculates correctly, which it almost always does, and more at whether the configuration and the way people use it keep the data honest.
Configuration is the real validation work
Most CDS products are configurable off-the-shelf software. The vendor has tested the calculations. Your job is to show that your configuration is right and that it stays that way. The settings that matter most:
- Audit trail switched on for everything, with no user able to turn it off.
- Individual accounts for every user. No shared logins, ever, including the instrument PC.
- Roles that separate who acquires data, who processes it and who administers the system.
- Results saved automatically, so data cannot be collected and discarded before anyone sees it.
- Clock and time zone controlled by the system, not by the user.
Write down why each setting is what it is. A configuration specification that records the reasoning is far easier to defend than a screenshot.
Trial injections and reprocessing
Two findings come up again and again. The first is unofficial test injections run before the official sequence, which in the worst cases means testing into compliance. The second is reprocessing with different integration until a result passes.
Validation should show the system makes both visible. Every injection is captured and retained. Every reprocessing is recorded with a reason. Then your procedures need to say when each is acceptable, and someone needs to actually look.
Audit trail review that means something
Reviewing the full audit trail for every result is not realistic. Reviewing none of it is not acceptable. The practical middle is a risk-based review focused on what could change a result: manual integration, reprocessing, aborted runs, deleted or renamed files, and changes to methods.
Most CDS products can report these events. Set the reports up during validation, so audit trail review is a defined step in result approval rather than something people do from memory. Our guide to audit trail review goes into how to scope it.
Standalone instrument PCs
The weak point is often not the networked CDS at all. It is the standalone workstation attached to one instrument, with a local administrator account, local data storage and a backup someone runs when they remember.
Bring these into scope explicitly. If they cannot be networked, document how data is protected, backed up and reviewed, and test the restore. Our LIMS validation and data integrity pages cover the lab side more broadly.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.