This is a ready-to-use configuration checklist for a chromatography data system (CDS). The CDS is one of the most frequently cited systems in data-integrity enforcement, and almost every finding traces to a configuration that technically permitted the wrong behavior. Work through each item, mark pass, fail, or N/A, attach evidence, and resolve every fail before the system is used for GMP work. Replace <<FILL: ...>> placeholders, and confirm each cited regulation against the current source. A filled specimen follows.
Control header
| Field | Entry |
|---|---|
| System name / ID | <<FILL: SYSTEM NAME / ID>> |
| Software / version | <<FILL>> |
| Instruments in scope | <<FILL: HPLC-xx, GC-xx, ...>> |
| Assessed by | <<FILL: name / role>> |
| Date | <<FILL>> |
| QA reviewed by | <<FILL: name, signature, date>> |
How to use
Each item is a configuration control. Mark Pass only with objective evidence (a screenshot, an exported audit-trail extract, or a system report) showing the control is in effect. A Fail is a gap to remediate and re-check; record it on the action log. N/A requires a one-line justification.
1. Audit trail
| # | Control | Pass / Fail / N/A | Evidence ref |
|---|---|---|---|
| 1.1 | The audit trail is enabled at the system or project level and cannot be turned off by an analyst. | <<FILL>> | <<FILL>> |
| 1.2 | The audit trail captures integration-parameter changes, not just events. | <<FILL>> | <<FILL>> |
| 1.3 | For a changed result, the audit trail returns the prior value, the new value, the user, the date/time, and the reason. Verified by making a change and retrieving the original. | <<FILL>> | <<FILL>> |
| 1.4 | The audit trail cannot be edited or deleted by any user. | <<FILL>> | <<FILL>> |
| 1.5 | Reason-for-change is forced on any manual modification of a result or integration. | <<FILL>> | <<FILL>> |
2. Reprocessing and integration
| # | Control | Pass / Fail / N/A | Evidence ref |
|---|---|---|---|
| 2.1 | Reprocessing of raw data requires a documented justification. | <<FILL>> | <<FILL>> |
| 2.2 | A reprocessed result requires a second-person review before it is accepted as the reported result. | <<FILL>> | <<FILL>> |
| 2.3 | The original result and each reprocessed version are retained; none is overwritten. | <<FILL>> | <<FILL>> |
| 2.4 | The basis for selecting the reported result from among versions is clear and traceable. | <<FILL>> | <<FILL>> |
| 2.5 | Manual integration is controlled (allowed only with justification and second review), not a routine unrecorded habit. | <<FILL>> | <<FILL>> |
3. Injection and sequence visibility
| # | Control | Pass / Fail / N/A | Evidence ref |
|---|---|---|---|
| 3.1 | Every injection, including aborted, failing, and “test” injections, is visible in the sequence/injection log. | <<FILL>> | <<FILL>> |
| 3.2 | Standalone or unofficial projects cannot be used to run injections that then disappear (no orphaned or hidden project path). | <<FILL>> | <<FILL>> |
| 3.3 | Deleting a data file, project, or sequence is prevented for analysts, or is fully traced if a privileged role does it. | <<FILL>> | <<FILL>> |
| 3.4 | The link from raw data file to reported result is unambiguous and traceable. | <<FILL>> | <<FILL>> |
4. Access control and privileges
| # | Control | Pass / Fail / N/A | Evidence ref |
|---|---|---|---|
| 4.1 | Each user has an individual account; no shared or generic analyst logins. | <<FILL>> | <<FILL>> |
| 4.2 | Analysts do not hold local or application administrator rights. | <<FILL>> | <<FILL>> |
| 4.3 | System administration (user management, audit-trail settings) is a separated role, not held by anyone who runs analyses. | <<FILL>> | <<FILL>> |
| 4.4 | Roles enforce that the person who generates a result is not the sole approver of its release. | <<FILL>> | <<FILL>> |
5. Clock and environment
| # | Control | Pass / Fail / N/A | Evidence ref |
|---|---|---|---|
| 5.1 | Analysts cannot change the system clock, time zone, or date format. | <<FILL>> | <<FILL>> |
| 5.2 | The clock is synchronized to the site’s validated time source. | <<FILL>> | <<FILL>> |
| 5.3 | Data is stored to a controlled, backed-up location, not a local drive an analyst can clear. | <<FILL>> | <<FILL>> |
| 5.4 | Retention and archival preserve the dynamic (reprocessable) nature of the raw data, not just a static PDF. | <<FILL>> | <<FILL>> |
6. Review process
| # | Control | Pass / Fail / N/A | Evidence ref |
|---|---|---|---|
| 6.1 | The second-person review procedure includes checking the sequence/injection log for aborted or hidden runs. | <<FILL>> | <<FILL>> |
| 6.2 | Audit-trail review is defined and performed at a risk-based frequency (see audit trail review SOP). | <<FILL>> | <<FILL>> |
| 6.3 | Reintegration to bring a failing result into specification without documented, reviewed justification is prevented and detectable. | <<FILL>> | <<FILL>> |
Action log
| Item # | Gap found | Action | Owner | Due | Re-check result |
|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Signoff
| Role | Name | Signature | Date |
|---|---|---|---|
| Assessor | <<FILL>> | ||
| QC management | <<FILL>> | ||
| QA | <<FILL>> |
References
21 CFR 211.194 (laboratory records) and 21 CFR Part 11. EU GMP Annex 11 (computerised systems), audit-trail and access-control expectations. FDA and MHRA data-integrity guidance for the original-record, true-copy, and audit-trail-review principles. Related reading: GxP manufacturing and laboratory systems, chromatography data system integrity.
Confirm the current version and clause numbers of each reference before issue.
Filled specimen
The following shows items 1.3 and 3.1 completed for an example CDS, so you can see the evidence expected. The values are illustrative.
| # | Control | Pass / Fail / N/A | Evidence ref |
|---|---|---|---|
| 1.3 | Prior value retrievable on a changed result | Pass | Changed amount from 99.1 to 99.3, retrieved original 99.1 with user, time, reason; screenshot EV-CDS-007 |
| 3.1 | All injections including aborts visible | Fail | Aborted injection on HPLC-07 did not appear in the default sequence view; action A-3 opened to enable full injection history |
In this example the audit-trail prior-value control passed, but the injection-visibility control failed because aborted injections were hidden in the default view. The assessor did not mark item 3.1 pass on the vendor’s assurance; they ran an abort and checked whether it showed. The failed item went to the action log and was re-checked after the configuration change. Testing the control rather than trusting the default is what turns a checklist into evidence.
Common inspection findings this checklist prevents
- Audit trail logging events but not prior values, so a changed result cannot be traced to its original.
- Aborted, failing, or “test” injections hidden from the reviewer.
- Analysts holding administrator rights that let them delete data or change the clock.
- Reprocessing to move a result into specification with no justification or second review.
- Reviewer checking only the reported result and never the sequence log.
How to adapt this checklist
- Set the system ID, software version, and instruments in the header.
- Add any platform-specific controls your CDS supports (for example project-level lock settings or e-signature meanings).
- Attach real evidence references for every pass; do not mark pass without them.
- Route every fail through your CAPA or change-control process and re-check.
- Confirm every regulation against the current published version before issue.