WMS Validation in GDP: Data Integrity and Audit Trail for the Responsible Person
Share

WMS Validation in GDP: Data Integrity and Audit Trail — what the inspector really asks for
If, during an inspection, they ask you: “Who changed the expiry date of this batch, and why?”, they are not testing the warehouse operator. They are testing your system.
And that is the point: today, in GDP, compliance is no longer decided only by cold rooms and delivery notes. It is decided by electronic records, audit trails, and IT governance.
In 30 seconds
A WMS is not “GDP-compliant” because it works. It is GDP-compliant when it can prove what happened, who did it, and when.
CSV (Computer System Validation) in logistics almost always fails for the same reasons: weak URS, superficial testing, overly broad access rights, and an audit trail that exists but is never reviewed.
The dangerous myth is: “We print a PDF and we are covered.”
Spoiler: no.
The vocabulary you see in findings (LSI “inspector language”)
In the digital GDP space, be ready to hear, and to demonstrate: CSV, URS, traceability matrix, IQ/OQ/PQ, GAMP 5, EU Annex 11, 21 CFR Part 11, ALCOA+, audit trail review, RBAC (role-based access control), segregation of duties, change impact assessment, backup/restore test, disaster recovery.
Which WMS data are truly “GDP-critical”
In an audit, the implicit question is always:
“If this data were wrong or manipulated, could I lose traceability or release unsuitable product?”
Table: critical data and expected controls
| Data / object in WMS/ERP | GDP risk if wrong | Expected “audit-proof” control |
|---|---|---|
| Lot / batch | incomplete recall, broken traceability | active audit trail, one-step-back/forward reports, inbound controls |
| Expiry date | distorted FEFO, shipment of expired product | logical block, audit trail on changes, approval workflow |
| Stock status (quarantine/released/blocked) | improper release | electronic quarantine, segregated authorizations, event log |
| Quantities moved | inventory mismatch, undetected internal theft | reconciliations, exception reports, controls on adjustments |
| Operation timestamps | unreliable event reconstruction | time sync (NTP), timezone governance, controls on clock drift |
| Interfaces (order portal, serialization, TMS) | data loss or alteration | interface validation, completeness checks, error handling |
From a manufacturing perspective, the WMS is often seen as “outside the GMP perimeter.” In a GDP audit, however, it becomes a quality system: if it is not governed, the Responsible Person is left without objective evidence.
CSV in GDP: how to do it without “papier-mâché validation”
In audits, the most common issue I see is this: companies with a nice “Validation Report,” but no risk logic, no traceability from requirements to tests, and tests that do not cover the real failure modes.
A practical approach that holds up in inspection
1) GxP scoping and risk assessment
Identify GxP-impact functions, such as:
- expiry blocking
- quarantine
- traceability
- serial integration
Classify the system using a GAMP 5-style logic: configured, customized, SaaS?
2) Robust URS — not “the system must work”
Example of a useful URS:
“The system must prevent shipment of batches with expiry date earlier than shipment date and must record the event in the audit trail.”
3) Traceability matrix
Each URS must end up in one or more test cases. If that link is missing, it is an audit gap.
4) IQ/OQ/PQ testing — including “dirty” cases
- IQ: installation / environment
- OQ: functions and controls, such as roles, blocks, audit trail, timestamps
- PQ: real processes, such as receiving → storage → picking → shipping → rework
5) Data migration and master data governance
If you import master data, product data, or expiry data, you need evidence that you did not “contaminate” the data.
This is where incidents often start, such as:
unit of measure interpreted incorrectly, box vs pack → wrong shipments.
6) Go-live with a quality gate
IT should not decide alone. Go-live must have a quality gate, with minimum evidence formally closed.
Remember this
A WMS is not validated because the vendor says it is.
It is validated when you can demonstrate that the configuration and the use of the system in your GDP process are under control.
Audit trail: enabling it is not enough — it must be reviewed
Contrarian insight, common myth:
“We switch the audit trail on, and if needed, we will look at it later.”
This is an outdated practice because it:
- turns the audit trail into a reactive tool, not a control mechanism
- leaves the door open to data integrity drift, meaning repeated errors or opportunistic behavior
What “audit trail review” means in practice
First, define critical fields:
- expiry date
- batch
- status
- quantity adjustments
- override of blocks
Then define a risk-based review frequency:
- monthly on samples
- quarterly on trends
- ad hoc on specific events
Look for typical patterns:
- repeated changes to expiry dates
- abnormal deletions or overrides
- “out-of-hours” activity without justification
- excessive use of admin profiles
In an audit, the killer question is:
“Can you show me evidence that the audit trail is reviewed before a problem turns into a recall?”
Access, roles, and segregation: even good companies fail here
The most common problem I see in audits is a shared handheld account such as “WAREHOUSE1”, or profiles that are too powerful “for convenience.”
Countermeasures that really work
- RBAC: minimum necessary roles
picking ≠ master data ≠ release/quarantine - Joiner–Mover–Leaver process: to create, modify, and deactivate access
- Periodic user access review: at least annually, better every six months for critical roles
- MFA where possible, especially for remote access and admin roles
- Segregation of duties: the person creating or updating master data should not approve exceptions
Patches and upgrades: when IT “improves” and GDP gets worse
Updating a system is normal. Doing it without control is a GDP risk.
Practical checklist
- every patch or upgrade goes through a change impact assessment
- there is a separate TEST environment
- you perform regression testing on GDP-critical processes
- results and release are documented
- for SaaS: vendor qualification plus evidence of release notes and impact assessment
From an IT perspective, a software change is often “routine.”
From a GDP perspective, it can be the origin of:
- expiry blocks no longer working
- degraded audit trail
- traceability reports that are no longer reproducible
Takeaway box
- GDP CSV = process + evidence, not a PDF in a shared folder
- Audit trail = active + protected + reviewed
- The 3 audit killers: access rights, lack of review, uncontrolled IT changes
- If you lose data integrity, you also lose the ability to execute an effective recall
FAQ
Is 21 CFR Part 11 required in an EU company?
Not always as a direct legal obligation. However, the underlying concepts, such as audit trail, electronic signatures, and access controls, are often expected as best practice when managing GxP-relevant electronic records.
Which systems should I validate for GDP?
All systems that impact traceability, stock status, expiry dates, temperature, serialization, and recall reporting. Typically:
- WMS / ERP
- temperature monitoring systems
- serialization modules
- order interfaces
How often should audit trail review be performed?
The best approach is risk-based: monthly on samples for critical fields, more frequently if you have many exceptions.
