GxP Computerized Systems: LIMS, CDS, ELN, MES, CTMS, and More, A Complete Map

Pharmaceutical, biotech, and medical device companies run on software. A single regulated facility can operate dozens of distinct computerized systems, and almost every one of them generates GxP data that has to be managed, validated, and protected for the life of the product. If you are new to quality or validation, the sheer number of acronyms is the first thing that hits you: LIMS, CDS, ELN, MES, SCADA, eQMS, EDC, CTMS. They start to blur together.

This article maps the major system categories so they stop blurring. For each one, you get a plain description of what it does, the records it produces, who uses it, and the validation and data integrity questions that follow. The goal is to give you a mental model of the whole system environment, not a vendor shopping list. Product names are included only as neutral examples, because the same category often goes by three or four different commercial names and the names get used loosely on the floor.

Two ideas hold the whole map together. First, a computerized system is regulated based on what it does, not what it is called. A spreadsheet that calculates a release result carries more regulatory weight than an expensive platform that only schedules meetings. Second, the controlling question for every system is always the same: can you trust the data it produces, and can you prove it? That is the data integrity question, and it shows up in slightly different clothing in every category below. If you want the underlying principles before reading the system tour, start with data integrity foundations and ALCOA+ in detail.

This is a beginner-tier map. Once you can name the systems and the records they own, the next move is to learn how each one is validated and operated day to day. The cross-links throughout point you there.

How to read a system: the five questions

Before the category-by-category tour, here is a frame you can apply to any system, including ones not listed here. When a system lands on your desk for assessment, ask:

1. What GxP decision does its output drive? Batch release, sample disposition, patient safety reporting, stability conclusions, device design verification. If the answer is “none,” the validation burden drops sharply.
2. Where is the original record, and what format is it in? The raw data file, the database row, the time-series stream. The original record, including its metadata, is what you have to protect. See data lifecycle and metadata for why metadata travels with the record.
3. Who can change the data, and is every change captured? This is the audit trail question. Default settings rarely answer it well.
4. How does someone sign or approve in the system? Electronic signatures bring 21 CFR Part 11 and EU Annex 11 into scope.
5. What happens when it fails or is decommissioned? Backup, restore, business continuity, and long-term readable retention.

Hold these five questions in mind as you read. Every “validation scope” and “DI risk” note below is really just one of these five questions applied to a specific system. The discipline of asking them in order, and writing down the answers, is the skeleton of a system risk assessment. The formal method behind it is in CSV risk assessment methodology and data criticality and data risk.

The regulatory backbone behind all five questions

Two regulations sit under nearly every answer, and you should be able to recite their scope cold in an interview.

21 CFR Part 11 (Electronic Records; Electronic Signatures), effective 1997, sets the U.S. requirements for when electronic records and signatures are trustworthy and equivalent to paper and handwritten signatures. It applies whenever a regulated record required by a predicate rule is created, modified, maintained, archived, retrieved, or transmitted electronically.

EU Annex 11 (Computerised Systems), in force in its current form since 2011, is the European counterpart. It applies to any computerized system used as part of a GMP-regulated activity, and is built around risk management, validation, data integrity, and the supplier relationship.

The phrase to remember is “predicate rule.” Part 11 is not a standalone obligation. It attaches to the underlying GMP, GLP, or GCP requirement that says the record must exist in the first place. A system holding a record that no predicate rule requires is out of Part 11 scope, though Annex 11 in Europe casts a slightly wider net. A full side-by-side reading is worth the time; see 21 CFR Part 11 and EU Annex 11 and the Part 11 and Annex 11 practical guide.

Laboratory Information Management System (LIMS)

What it does: The LIMS is the central system for managing laboratory samples, tests, and results. When a raw material arrives at a facility, a LIMS entry is created, samples are assigned, tests are scheduled, results are entered, specifications are checked automatically, and a disposition recommendation is generated. The LIMS knows where every sample is, what tests have run, and whether results are pending, passing, or failing.

Why it is regulated: The LIMS makes or supports the disposition decision, the single most consequential quality decision in the building. Under 21 CFR 211.165 and 211.194, every batch must be tested against specifications and the results recorded before release. When the LIMS holds those specifications and those results, it holds the evidence that the batch met its release criteria. A wrong limit or an unattributed edit in the LIMS is, in effect, a falsified release record. See what is GMP and CFR 210/211 cGMP walkthrough for the predicate rules.

Key data generated: Sample records, test results, disposition decisions, certificates of analysis, environmental monitoring results, stability testing schedules and results, out-of-specification flags.

Primary users: QC analysts, QA, manufacturing (for in-process results), supply chain (for raw material status).

Validation scope: A LIMS is typically a Category 4 (configured) or Category 5 (custom) system under GAMP 5, requiring a full lifecycle approach with installation, operational, and performance qualification. Critical validated functions include sample tracking and traceability, result capture and specification comparison, automatic limit checks, audit trail completeness, and access control enforcement. The specification limits themselves are configured data that must be verified and change-controlled, because a transcription error in a limit table silently passes failing product.

How to validate it, in sequence:

1. Write user requirements that name every GxP function (limit checking, disposition logic, audit trail, e-signature) and trace each to a test. See user requirements and traceability.
2. Risk-assess each function. Limit checking and disposition are high risk. A label-printing convenience function is low risk.
3. Qualify the infrastructure and install the application (IQ).
4. Verify configured functions against requirements (OQ), with a heavy focus on the high-risk functions identified in step 2.
5. Confirm the system works in the real laboratory workflow with real users and real data (PQ).
6. Independently verify every configured specification limit against the approved source method or monograph, with a second-person check. This is the step teams most often shortchange.
7. Place the configuration under change control so no limit changes without review.

Acceptance criteria: Requirements all traced and tested with documented evidence. Audit trail captures user, timestamp, old value, and new value for every result and limit change, and cannot be disabled by an ordinary user. Access is role-based with segregation between the analyst who enters and the reviewer who approves. Every configured limit reconciles to its approved source. Disposition logic produces the correct recommendation on a deliberately failing test case.

Common systems (neutral examples): LabVantage, LabWare, STARLIMS, Thermo SampleManager.

Worked example: A QC analyst tests an incoming excipient. The result is 99.2 percent assay against a 98.0 to 102.0 percent specification. The LIMS compares the entered value to the configured limits, marks it passing, and rolls it into a disposition recommendation. The validation question is not whether the chemistry is right, that is the method’s job. It is whether the LIMS reliably enforced the right limits, attributed the entry to the right analyst with the right timestamp, and prevented anyone from quietly editing 99.2 to 99.8 without leaving a trace. That is why audit trail review on result changes is part of batch record review.

Common mistakes inspectors find: Configured limits that were never independently verified against the method. Audit trail switched on for results but not for the limit tables. Analysts with rights to both enter and approve their own results. Manual results typed in from an instrument without a documented transcription check. For a full implementation walkthrough, see LIMS implementation and validation.

Chromatography Data System (CDS)

What it does: The CDS controls chromatography instruments such as HPLC, GC, UHPLC, and LC-MS, and captures the raw data they generate. An analyst runs a sample, the instrument produces a chromatogram (detector response over time), and the CDS applies an integration method to calculate peak areas and, from those, concentrations or purity values. The CDS is where raw chromatographic data lives.

Key data generated: Raw instrument data files, chromatograms, integration results, sequence files, method files, injection logs. The raw data file is the original record. Processed results derived from it are secondary and must always be traceable back to the raw file.

Primary users: QC analysts, method development scientists, the stability group.

Validation scope: The CDS is one of the most inspection-scrutinized categories because it is where many data integrity failures happen. Audit trail configuration matters most here. The system must capture integration parameter changes with prior values, and the ability to reprocess, reintegrate, or delete data must be restricted by role. Integration event logs must be reviewable, and the review of those logs needs to be a defined step, not an afterthought. The qualification of the connected instrument is a separate, parallel activity covered in analytical instrument qualification.

Common systems (neutral examples): Waters Empower, Agilent OpenLab CDS, Thermo Chromeleon, Shimadzu LabSolutions.

DI risk note: CDS is consistently among the most common sources of audit trail and data integrity citations in FDA warning letters. The recurring patterns are well documented in agency guidance: testing into compliance, using “trial” or unofficial injections that are not reviewed, sharing logins so changes cannot be attributed, and audit trails that were never switched on. The default configuration of many platforms does not capture old value and new value for integration changes until someone deliberately configures it. The audit trail must capture, at minimum, the event, user ID, timestamp, field name, prior value, and new value. The FDA guidance “Data Integrity and Compliance With Drug CGMP” (final, December 2018) and the MHRA “GXP Data Integrity Guidance and Definitions” (March 2018) both treat this as baseline expectation. For how to design and review these trails, see audit trail design and review.

Worked example of a CDS audit trail review: An analyst runs a six-injection sequence for an assay. During review, QA opens the integration audit trail and sees the table below.

The manual reintegration at 10:02 is not automatically wrong, but it demands a documented reason. Did baseline noise justify it, and is that consistent with the method? The reviewer’s job is to confirm the reason is recorded, the change is method-allowed, and no earlier passing result was overwritten. An audit trail that showed several deletions before the printed result, or injections with no corresponding result, is the classic falsification pattern. The full treatment is in chromatography data system integrity.

How to lock down a CDS: Use unique named accounts with no shared logins. Disable local administrator rights for analysts. Force audit trail on and prevent its disabling. Restrict reprocess and delete permissions to a small reviewer role. Store data on a server, not a local workstation, so it survives a disk wipe. Make integration-trail review a checked step in the batch record review workflow.

Electronic Laboratory Notebook (ELN)

What it does: The ELN replaces the paper lab notebook. Scientists record experiments, method development data, observations, and calculations in a structured electronic format. In a GxP context, the ELN can be a primary data source for research, development, and some quality activities. It also appears in GLP nonclinical work, where it serves as the contemporaneous study record.

Key data generated: Experimental records, calculations, observations, raw data from attached instruments, scientist signatures and dates, witness signatures where used.

Primary users: R&D scientists, analytical development, formulation scientists, nonclinical study staff.

Why it is regulated, and under what: In a GMP lab the ELN holds method-development or release-supporting data, so 21 CFR Part 11 applies. In a nonclinical lab it sits under GLP, 21 CFR Part 58, where the contemporaneous and attributable nature of the study record is the whole point. See GLP under 21 CFR Part 58 for nonclinical studies.

Validation scope: For GxP use, ELN validation focuses on record integrity, audit trail, electronic signature compliance, and the ability to export records in a human-readable format. Many ELN platforms are built first for scientific workflow and collaboration, so the GxP-compliant configuration takes deliberate attention to access controls, locking of signed records, and audit settings. A common gap is calculation integrity: if the ELN runs embedded calculations or pulls in spreadsheet logic, that logic is a configured object that needs verification, the same way a standalone spreadsheet would under infrastructure qualification and spreadsheet validation.

Acceptance criteria: Signed records lock and cannot be silently edited after signature. Witnessing, where used, is a true second-person review and not a rubber stamp. Embedded formulas are tested with known inputs and expected outputs. Records export to PDF or another readable format with the audit trail intact, so a record survives the platform.

Common systems (neutral examples): Benchling, Dotmatics, IDBS E-WorkBook, LabArchives, Revvity Signals Notebook.

Common mistakes: Treating the ELN as a research tool exempt from GxP when its data later supports a regulatory submission. Embedded calculation templates that were never verified. No record locking, so a signed page can be edited.

Manufacturing Execution System (MES)

What it does: The MES manages and records the manufacturing process in real time. An electronic batch record in the MES guides operators through each step of the procedure, captures electronic signatures at critical steps, records process parameters, and flags deviations when parameters fall out of range. The completed electronic batch record replaces or supplements the paper batch manufacturing record.

Key data generated: Electronic batch records, process parameter logs, in-process test results, operator electronic signatures, deviation flags, material consumption and batch genealogy records.

Primary users: Manufacturing operators, manufacturing management, QA for batch release review.

Validation scope: An MES is typically a highly configured Category 4 or custom Category 5 system, and one of the most complex in the facility. Electronic signature compliance under 21 CFR Part 11 is non-negotiable, and the signature manifestation must show the printed name, date, time, and meaning of each signature. The electronic batch record workflow must enforce the intended sequence of operations so an operator cannot skip or backfill a step. Process parameter alarms and any limit overrides must be captured with prior values in the audit trail. Because the MES sits between control systems below and the quality system above, its interfaces are a major part of validation effort. The detailed integrity expectations are covered in MES, EBR, and SCADA data integrity and GxP manufacturing systems.

The signature manifestation, concretely: Part 11 §11.50 requires every signed electronic record to display the signer’s printed name, the date and time of signing, and the meaning of the signature (such as review, approval, responsibility, or authorship). A correct MES signature line looks like this:

Approved by: Maria Chen, 18-Jul-2025 14:32 EDT, Meaning: Verified addition of Buffer A per step 7.

A signature that shows only a user ID and a timestamp, with no printed name and no meaning, is a finding. Recipe steps are built on the ISA-88 batch model; see ISA-88 batch control and recipes.

Acceptance criteria: Step sequencing is enforced, tested by attempting to skip and to backfill a step and confirming the system blocks it. Every critical-step signature shows name, date, time, and meaning. Parameter overrides are captured with old and new values and a reason. Batch genealogy ties finished lot to every component lot. Interface tests confirm data passes correctly to and from the historian, LIMS, and ERP.

Common systems (neutral examples): Rockwell PharmaSuite, Werum PAS-X, Körber Werum, Apprentice, Tulip; deviation handoff often goes to a separate quality system such as TrackWise.

Common mistakes: Workflow that allows backfilling a missed signature after the fact. Overrides recorded without a reason. Interface failures that silently drop or duplicate records between MES and ERP.

Process Analytical Technology (PAT) and Data Historians

What it does: Process historians capture time-series data from manufacturing equipment: temperature, pressure, pH, dissolved oxygen, agitation speed, flow rates. In bioreactor-based manufacturing, a historian can record thousands of data points per batch, building the continuous process record that demonstrates the batch ran within validated parameters. The same pattern appears in synthesis, fill and finish, and utility systems. PAT extends this idea toward real-time measurement and control of quality attributes during the process itself, an approach the FDA encouraged in its 2004 guidance “PAT, A Framework for Innovative Pharmaceutical Development, Manufacturing, and Quality Assurance.”

Key data generated: Continuous time-series records of critical and non-critical process parameters for every batch, plus the configuration that defines tags, sampling rates, and data compression.

Primary users: Process development, manufacturing, QA for batch review.

Validation scope: Historians are usually fed by SCADA or distributed control systems, so the integrity requirements apply at several layers: the sensor and PLC level, the control and historian level, and the reporting layer. Two issues recur. First, many historians compress data to save storage, and aggressive compression can discard meaningful detail, so the compression settings are a validated configuration, not an IT convenience. Second, audit trails for tag and configuration changes are often weak in process systems and need deliberate remediation. Time synchronization across these layers also matters, because a contemporaneous record with the wrong clock is not really contemporaneous.

Worked example of why compression is a validated setting: A bioreactor temperature tag samples every second. A swinging-door compression algorithm set to a 0.5 degree deviation band may store only one point every several minutes when the temperature is stable. If a brief 1.5 degree excursion lasted 20 seconds, a coarse 3 degree band can swallow it entirely, and your continuous record now shows a flat line over a real deviation. That is why the compression band is reviewed against the criticality of the parameter and locked under change control. The deeper treatment is in process historian data integrity.

Acceptance criteria: Tag configuration and compression settings documented and change-controlled. Clocks across PLC, historian, and reporting layer synchronized to one trusted source. Critical-parameter trends reproduce a known excursion rather than smoothing it away. Time stamps survive review against time stamps and system clock control.

Common systems (neutral examples): AVEVA PI (formerly OSIsoft PI), AspenTech InfoPlus.21, GE Proficy Historian.

SCADA and Distributed Control Systems (DCS)

What it does: SCADA (Supervisory Control and Data Acquisition) and DCS systems control automated manufacturing processes. They read data from field instruments, compare it to setpoints, and send control signals to actuators such as valves, pumps, and agitators. In pharmaceutical manufacturing they run fermentation, purification, environmental systems, utilities, and fill and finish operations. The same control layer runs device assembly lines and packaging.

Key data generated: Real-time and historical process control data, alarm and event records, operator change and setpoint records.

Primary users: Process operators, automation engineers, manufacturing, QA for batch review.

GxP consideration: These systems are often engineered for process reliability and efficiency rather than GxP record-keeping, and it shows. Their audit trails frequently do not capture prior values, do not maintain individual user attribution for setpoint changes (shared operator consoles are common), and can be hard to export in a readable form. The agency has cited control-system data integrity gaps in drug manufacturing contexts. Changes to PLC programs and SCADA setpoint tables are configuration changes that must go through validated change control, and the validation approach for the whole layer is laid out in automation validation for PLC, SCADA, and DCS.

How attribution gets fixed on a shared console: The common real-world problem is one operator account left logged in at a station all shift, so every setpoint change is attributed to a generic “operator1.” The fix is either individual login at the point of action, or a separate access-control layer that requires the operator to authenticate before a GxP-relevant change is committed, even if the console session is shared. The fundamentals are in PLC, DCS, and HMI fundamentals.

Acceptance criteria: Setpoint and recipe changes attributed to a named individual with old and new values. Alarm and event records complete and exportable. PLC and SCADA configuration under change control with version identification.

Building Management System (BMS) and Environmental Monitoring System (EMS)

What it does: A Building Management System controls facility-level building services, HVAC, differential pressure between rooms, humidity, and often lighting and access schedules, across manufacturing suites, laboratories, warehouses, and cleanrooms. An Environmental Monitoring System, in the software sense used here (distinct from the environmental monitoring program that also includes viable and non-viable microbiological sampling), continuously logs temperature, humidity, differential pressure, and sometimes particle counts from probes placed in classified rooms, cold storage, stability chambers, and warehouse zones, and raises an alarm when a reading drifts outside its qualified range. The distinction that matters: a BMS actively controls, it opens a damper or adjusts a setpoint, while an EMS passively records and alarms. Some facilities run one integrated platform that does both; others deliberately keep them separate, because the facility-automation BMS was never built with a GxP-grade audit trail and alarm handling in mind, so a dedicated EMS layer sits on top of it for the rooms and chambers that matter most.

Key data generated: Continuous temperature, humidity, differential pressure, and particle trend data; alarm and acknowledgment records; setpoint and configuration change history; probe calibration status and due dates.

Primary users: Facilities and engineering, the environmental monitoring or microbiology group for classified spaces, QA, and warehouse operations for cold-storage zones.

Why it is regulated: This system’s data directly supports storage-condition claims under 21 CFR 211.142 (warehousing) and 211.150 (distribution), the classification and control basis for cleanrooms under EU GMP Annex 1, and the qualified operating range of stability chambers. An excursion that is not captured, alarmed, or acted on is simultaneously a data integrity gap and a product-quality event, because the two failures share the same root cause: nobody can show the room stayed in range. See designing an environmental monitoring program for the microbiological program this data supports, and Annex 1 and contamination control strategy for the classification basis behind the setpoints.

Validation scope: Probes and sensors are qualified and calibrated under a metrology program, and calibration due dates need to be tracked somewhere QA actually reviews, not a spreadsheet that only the technician who built it maintains. Alarm setpoints and escalation rules are configured data under change control, the same way a LIMS specification limit is. The audit trail must capture setpoint changes and alarm acknowledgments with individual attribution, and historical trend data must remain retrievable for the full retention period, including for rooms or chambers that have since been decommissioned or repurposed. Interfaces to a BMS that also controls the space are validated in both directions: the EMS has to see what the BMS actually did, not just what it was told to do.

Acceptance criteria: A deliberately induced test excursion is captured, alarmed, and routed to a named individual, with escalation timing matching the defined procedure. Alarm acknowledgment records who acknowledged, when, and why, and does not silently clear the underlying event. Probe calibration status is current for every point in continuous use, with no gaps in the record around the due date. Trend history for a decommissioned room or chamber remains retrievable in a readable form.

Common systems (neutral examples): Vaisala viewLinc, Rees Scientific, Kaye (Amphenol Advanced Sensors) ValProbe, Siemens Desigo, Honeywell building and environmental monitoring platforms.

Common mistakes inspectors find: Alarms routed to an inbox nobody monitors overnight or on weekends. A warehouse zone with no continuous monitoring at all, only a manual min/max thermometer reading once a shift. Alarm acknowledgment that clears the alarm without recording who acknowledged it or why. Probe calibration overdue because the due-date tracking lives in an unowned spreadsheet rather than the system of record. A validated EMS that everyone quietly stopped trusting after repeated false alarms, so a real excursion gets the same shrug as the false ones.

Worked example: classifying an ambiguous system with the five questions

Ambiguous cases are the norm, not the exception, and it is worth walking one all the way through so the five questions from the opening section stop being an abstraction. Take a real scenario: a distribution site adopts a cloud-based SaaS platform that continuously logs temperature and humidity from wireless probes in a cold-storage room holding released, saleable drug product awaiting shipment. Is it GxP, and if so, what is it?

Question 1, what GxP decision does its output drive? Ask concretely: if a probe shows a two-hour excursion above the qualified range, does anyone act on that reading, hold the affected stock, or open an investigation? If yes, the system’s output drives a product-quality decision. If the honest answer is that the room also has a separately validated, wired monitoring system that is what the site actually relies on, and this SaaS platform is a pilot nobody has cut over to yet, the determination goes a different way, shown in the second branch below.

Questions 2 through 5, applied to the GxP path. The original record lives in the vendor’s cloud database, not in a PDF report someone downloads weekly, so the contract has to guarantee readable export for the full retention period, including after the relationship ends (question 2). Alarm setpoints and any manual override of a probe reading need a captured audit trail with attribution, not just an event log the vendor’s support team can pull on request (question 3). If the platform captures an operator’s acknowledgment of an alarm as part of the investigation record, that acknowledgment functions as a signature and Part 11 applies to it (question 4). And because the platform is SaaS, the failure and decommissioning question is really a vendor question: what happens to five years of trend data if the contract ends or the vendor is acquired, and has anyone actually tested an export (question 5).

The determination: a lightly configured cloud platform that is the genuine system of record for a GxP storage location is typically GAMP Category 3 or 4 depending on how much alarm logic was configured beyond the vendor defaults, and its data criticality is High, because a missed excursion on released product is a patient-facing risk, not a paperwork gap. Write the determination, the rationale, and the evidence you checked into the system inventory; the mechanics for doing that formally are in the GxP system inventory and classification.

Enterprise Resource Planning (ERP) and its GxP intersections

What it does: ERP systems manage business processes including purchasing, inventory, order management, and finance. Common platforms are SAP, Oracle, and Microsoft Dynamics. In pharmaceutical operations, ERP touches GxP mainly through inventory management: lot tracking, expiry management, quarantine and release status, and batch genealogy. Serialization and track-and-trace functions under the U.S. Drug Supply Chain Security Act (DSCSA, 2013) often live here too.

GxP consideration: You almost never validate the entire ERP. You validate the slices of it that drive GxP decisions, such as material status flags, batch disposition data, and expiry logic, plus the interfaces that move that data to and from validated systems like the LIMS and MES. A status field that wrongly flips a quarantined lot to “available” is a patient-safety event, so the controls around that field, and the interface that populates it, are where the validation effort concentrates. Scoping this well is an exercise in risk assessment; see CSV risk assessment methodology.

How to scope a partial ERP validation:

1. List the GxP-relevant transactions: goods receipt with quarantine status, status change to released, status change to rejected, expiry calculation, recall hold.
2. Trace where each status is set. Is it manual, an interface from LIMS, or a workflow rule?
3. Validate those transactions and the interfaces feeding them. Leave finance, HR, and procurement reporting out of GxP scope unless they touch a GxP decision.
4. Confirm a quarantined lot cannot be consumed or shipped, by testing the block, not assuming it.

Acceptance criteria: A quarantined or rejected lot is provably blocked from shipment and consumption. Expiry logic produces the correct date on test cases including edge cases like retest-date materials. Interfaces from LIMS and MES move status correctly and fail safe (a failed interface holds the lot rather than releasing it). DSCSA serialization data is complete and exchangeable; see DSCSA serialization and track and trace and supply chain data integrity.

Common systems (neutral examples): SAP, Oracle, Microsoft Dynamics.

Warehouse Management System (WMS) and its GxP touchpoints

What it does: A WMS manages the physical movement of inventory inside a warehouse or distribution center: putaway, picking, cycle counting, and location tracking. Some organizations run warehouse management as a module inside the ERP; larger distribution operations run a dedicated WMS that interfaces to the ERP for material master data and to the LIMS or eQMS for disposition status.

GxP touchpoints: The touchpoints that pull a WMS into GxP scope are quarantine and release enforcement (a quarantined lot has to be both physically segregated and systemically blocked from picking), FEFO or FIFO enforcement so expiry-sensitive stock ships in the correct order, lot and serial tracking that supports recall capability, and temperature-zone assignment that ties a storage location to its qualified condition.

Key data generated: Location and movement transactions, pick confirmations, cycle count records, quarantine and hold flags at the location level, and lot genealogy for outbound shipments.

Primary users: Warehouse operations, supply chain, and QA for release-to-ship confirmation.

Validation scope: As with ERP, you rarely validate the entire WMS platform. You validate the transactions and interfaces that drive a GxP decision: the quarantine and release block, the FEFO or FIFO picking logic, and the interface that receives disposition status from the LIMS, eQMS, or ERP. The block on a quarantined lot has to be tested directly, by attempting to pick it, not inferred from a status flag that merely looks correct on screen.

Acceptance criteria: Attempting to pick a quarantined or rejected lot is blocked by the system, tested directly rather than assumed. FEFO or FIFO logic selects the correct lot on a test case built with mixed expiry dates. A failed interface from the disposition system leaves the affected WMS status held or unresolved rather than defaulting the lot to available.

Common mistakes: WMS location status and LIMS or eQMS disposition status drifting out of sync because the interface between them fails silently, so the two systems disagree about whether a lot is releasable. A lot physically moved into a quarantine cage while the WMS record still shows it available, so a picker can select it by system even though it is fenced off physically, or the reverse: the system blocks it correctly but nobody moved the physical stock, so someone works around the block by hand.

Common systems (neutral examples): SAP EWM, Manhattan Associates, Blue Yonder (formerly JDA), Körber Supply Chain.

For the distribution-side controls that pick up once product leaves the warehouse, see Good Distribution Practice, cold chain, and serialization.

Track-and-trace and serialization systems

What it does: These systems assign a unique identifier, a serial number, to each saleable unit, link units into aggregation hierarchies (unit into case into pallet), and exchange transaction and verification data with trading partners so a product’s chain of custody can be authenticated and a suspect or illegitimate product identified and quarantined before it reaches a patient. In the United States this exists to meet the Drug Supply Chain Security Act (DSCSA, 2013). The European equivalent runs through the Falsified Medicines Directive framework, implemented technically as Delegated Regulation (EU) 2016/161, which became applicable in February 2019 and requires a unique identifier plus a tamper-evidence feature, verified against a central hub at the point of dispensing rather than through the wholesaler-level verification model DSCSA uses.

Key data generated: Serial number assignment and commissioning records, aggregation hierarchies linking unit to case to pallet, EPCIS (Electronic Product Code Information Services) events such as commission, pack, ship, and receive, verification transaction logs, and suspect or illegitimate product investigation records.

Primary users: Packaging and serialization operations, supply chain, QA, and the trading-partner-facing compliance function that handles verification requests and exceptions.

Why it is regulated: A broken or incomplete aggregation record cannot support the transaction history a trading partner or a regulator may demand during an investigation, and a verification step that returns a false negative or false positive touches patient safety directly, either by blocking legitimate product or letting an illegitimate product pass.

Validation scope: Serialization line integration, the printer and vision system tied to the line controller, is validated alongside the packaging line itself. Aggregation accuracy gets tested with deliberate mis-scans and exception cases, not only the clean happy path, because the happy path is not where aggregation actually breaks. The EPCIS repository and its interface to trading partners or a national or regional hub is validated for message completeness and format compliance. Exception and suspect-product workflows are tested end to end, including who gets notified and how a hold is released.

Acceptance criteria: The aggregation hierarchy for a test batch reconciles completely, including a deliberately mis-scanned unit that routes correctly to exception handling rather than continuing down the line unresolved. EPCIS events transmit in the required format and remain retrievable for the applicable regulatory retention period. A verification request against a decommissioned, already-shipped, or unknown serial number is correctly rejected rather than defaulting to a pass.

Common mistakes: Aggregation gaps where a case ships with fewer unit serials linked to it than were physically packed, discovered only when a downstream partner cannot verify the contents. Exception handling that logs a mis-scan as an event but allows the unit to continue down the line without resolution. Data captured correctly at the line but never reconciled against what the central repository or hub actually received, so a gap sits undetected until an audit or an investigation surfaces it.

Common systems (neutral examples): TraceLink, Systech, Antares Vision (including the former rfxcel), SAP Advanced Track and Trace, Optel.

The full regulatory and technical treatment is in DSCSA and serialization: track-and-trace, EPCIS, and interoperability.

Clinical Trial Management System (CTMS)

What it does: The CTMS manages the operational side of running clinical trials: site selection and activation, enrollment tracking, visit scheduling, monitoring visit reports, protocol deviation logging, and study team coordination. In clinical operations it is the logistics backbone of a study.

Key data generated: Site activation records, enrollment and visit milestones, monitoring visit reports, protocol deviation logs, study team and delegation records.

Primary users: Clinical operations, clinical monitors (CRAs), study managers, clinical QA.

GxP regulation: A CTMS sits under Good Clinical Practice, principally ICH E6(R2) “Good Clinical Practice” (2016), rather than GMP. The data integrity principles are the same, but the regulatory framework and inspection focus differ. The revised ICH E6(R3) GCP guideline, which the ICH adopted in early 2025, sharpens expectations around computerized systems and risk-based oversight in trials, so CTMS and related clinical platforms are getting more attention, not less. See ICH E6 Good Clinical Practice.

Validation scope: Focus on the records that feed oversight and inspection: deviation logging completeness, monitoring report integrity, access control by role and study, and the audit trail on those records. The CTMS is rarely the regulatory source for participant data (that is the EDC), so its validation centers on operational integrity and traceability rather than primary clinical data.

Acceptance criteria: Deviation log captures every logged deviation with attribution and timestamp, with no silent deletion. Access is restricted by study and role. Monitoring reports lock after sign-off.

Common systems (neutral examples): Veeva Vault CTMS, Oracle Siebel CTMS, Medidata, IQVIA platforms.

For the broader clinical picture, see clinical systems and GCP digital quality and clinical QA and GCP data integrity.

Electronic Data Capture (EDC) and the eCRF

What it does: EDC systems capture clinical trial data from study sites. Investigators and coordinators enter participant data into electronic case report forms through the EDC, which runs edit checks at the point of entry, records timestamps and user IDs, manages queries, and maintains a full audit trail of every entry, correction, and resolution.

Key data generated: eCRF entries, edit-check flags, data queries and their resolutions, electronic signatures, and a full change audit trail. The EDC database is the structured clinical dataset that feeds the statistical analysis and the submission.

Primary users: Site investigators and coordinators, clinical data managers, monitors, biostatisticians.

GxP regulation: Good Clinical Practice. EDC data integrity has long been a focus of FDA review during marketing applications, and the agency’s expectations for electronic source data are described in its 2013 guidance “Electronic Source Data in Clinical Investigations.” A recurring inspection theme is whether the source is the EDC entry itself or a separate paper or device record, and whether the path from true source to database is documented and controlled. See source data and source data verification.

The source question, made concrete: If a site nurse measures blood pressure, writes it on paper, then types it into the EDC the next day, the paper is the source and the EDC is a transcription, so the paper must be retained and the transcription controlled. If the nurse types directly into the EDC at the point of measurement and there is no paper, the EDC entry is the source. A data management plan must declare which is which, field by field, before the trial opens. Getting this wrong is one of the most common GCP computerized-system findings. Related: clinical data management and CDISC, econsent and decentralized trials, and electronic trial master file.

Acceptance criteria: Edit checks fire correctly on out-of-range and missing values. Every change carries user, timestamp, old value, new value, and reason. The query lifecycle from raise to resolution is fully traceable. The database lock process is controlled, with no edits after lock without a documented, approved database unlock.

Common systems (neutral examples): Medidata Rave EDC, Oracle Clinical One, Veeva Vault EDC, Castor, REDCap (academic, with limited use in regulated submissions).

Quality Management System (eQMS)

What it does: The eQMS is the electronic platform that runs the quality system itself: document control, deviations, CAPA, change control, training records, audits, supplier management, and complaints. A well-configured eQMS links these processes, so a deviation can generate a CAPA, an approved CAPA can trigger an SOP revision, and a new SOP version can issue training assignments to affected staff automatically. For a combination product, the same platform has to carry both the drug-side quality records and the device-constituent records under one quality system; see combination products and cGMP under Part 4.

Key data generated: Controlled documents and their version history, deviation records, CAPA records, change-control records, training completions, audit findings, complaint records, supplier qualification status.

Primary users: QA, document control, all functions that raise or own quality records, and management for management review under ICH Q10.

Validation scope: The eQMS is a validated system, and because it holds the records that prove the quality system works, its audit trail and record-locking controls carry particular weight. It must prevent unauthorized modification of closed quality records, enforce approval workflows, and keep signatures bound to the records they apply to. Workflow configuration is the heart of the validation effort, since most of the risk lives in how the system routes, locks, and escalates records rather than in the underlying platform code. The processes it automates are described in deviation management, what is a CAPA, document control fundamentals, and the wider pharmaceutical quality system.

Acceptance criteria: Closed records lock and cannot be edited. Approval workflows enforce the intended approver roles and sequence. Overdue records escalate. Training assignments trigger on document effective dates and block effective use until trained where required. Reports used for quality metrics and KPIs reconcile to the underlying records.

Common mistakes: Workflow that lets a record reach “closed” without the required approvals. Reporting that miscounts open versus closed records, which then misleads management review. Effective dates that do not drive training, so people work to an old SOP.

Common systems (neutral examples): Veeva Vault QMS, MasterControl, TrackWise, ETQ Reliance, AssurX.

Document Management System (DMS), and where it differs from eQMS

What it does: A Document Management System, often called an eDMS, manages the lifecycle of controlled documents: authoring, review, versioning, approval routing, distribution, and archival, covering SOPs, work instructions, specifications, validation protocols and reports, and regulatory submission content. Some organizations run document control as a module inside a broader eQMS platform. Others run a dedicated DMS, sometimes the same platform used for regulatory submission publishing, and interface it to a separate eQMS that owns deviations, CAPA, and change control.

The distinction that matters: An eQMS owns the quality process record, the deviation, the CAPA, the change control record, and the workflow that routes and approves it. A DMS owns the document itself as a controlled object, its version history, its effective date, its distribution and read-and-understood tracking, and its retirement. The two are tightly linked in practice. A CAPA logged in the eQMS can require an SOP revision that only exists in the DMS, and an SOP’s new effective date in the DMS should trigger training assignments that may live in the DMS, the eQMS, or a separate LMS depending on the platform choice, but the two systems are answering different questions: is the process complete and approved, versus is this the current, controlled version of the document. When one vendor platform genuinely performs both functions as a single integrated system, list it once in the inventory with both functions named rather than forcing an artificial two-system split.

Key data generated: Document version history, approval and effective-date records, read-and-understood or acknowledgment records, distribution lists, and the retired or superseded document archive.

Primary users: Document control, QA, and every function that owns or must follow a controlled document.

Validation scope: Focus on version control integrity: only the current effective version is retrievable through the normal access path, and a superseded version is clearly marked and access-restricted rather than silently overwritten. The approval workflow must enforce the intended sequence and roles before a document can go effective. The link to training assignment, whether manual or a system interface, needs to actually fire when a document’s effective date changes, not just exist as a documented intention. See document control fundamentals for the process this system automates.

Acceptance criteria: A superseded document cannot be presented as current through any normal access path, tested by attempting to retrieve it the way a user actually would. The approval workflow blocks an effective date from being set before every required approval is complete. Read-and-understood or training-linkage records are retrievable and tie back to the correct document version, not just the document title.

Common mistakes: A DMS and an eQMS that are technically separate platforms but were never interfaced, so a document’s effective-date change does not reliably trigger training and people learn about a revised SOP by word of mouth. Local copies of controlled documents saved to a shared drive or a desktop that persist and keep circulating after the master copy is superseded.

Common systems (neutral examples): Veeva Vault QualityDocs, MasterControl Documents, OpenText, and validated configurations of SharePoint.

A close cousin: the Learning Management System (LMS)

A document’s effective date in the DMS should trigger a training assignment, and that assignment usually lives in a Learning Management System, whether that LMS is a module of the DMS, a module of the eQMS, or a standalone platform. The LMS itself, how to design a training matrix, choose training methods, check training effectiveness, and validate the platform, is covered in full in GxP training program design. This map stops at naming the touchpoint: if a DMS effective-date change does not reliably reach the LMS, people keep working to a document they were never trained on, and that gap hides until an inspector asks someone to explain a step they clearly do not know.

Laboratory automation and robotics

What it does: Automated liquid handlers, high-throughput screening platforms, and robotic sample processors take over repetitive laboratory tasks. Automated cell culture and processing platforms are now common in biologics and advanced therapy manufacturing, and automated dispensing is routine across many modalities.

Key data generated: Run logs, method execution records, instrument-generated results, interruption and error events, and the audit trail of who started and modified each run.

Primary users: QC and development laboratory staff, automation engineers, manufacturing science.

Validation considerations: These are software-driven systems, so they get validated like other software, but with extra dimensions. Installation qualification covers both hardware and software, because mechanical setup affects results. Method transfer matters: the automated method has to demonstrate equivalence to the manual method it replaces, which overlaps with analytical method transfer. System suitability checks run before each batch of work, and the audit trail for an automated run must capture who started it, any interruptions, and any deviations the system detected mid-run.

Acceptance criteria: Documented equivalence between automated and manual method on the same samples. IQ covering mechanical setup and calibration of the liquid-handling components. Run-level audit trail capturing start, operator, interruptions, and detected errors. System suitability gating each run.

For advanced-therapy specifics where these platforms are most prevalent, see cell and gene therapy data integrity and the related data integrity in gene therapy.

Spreadsheets, scripts, and low-code: the systems that hide

The most cited “systems” in some inspections are not platforms at all. They are spreadsheets that calculate a result, a script that transforms data, or a low-code app someone built to fill a gap. They drive GxP decisions yet often escape the validation program because nobody calls them systems.

The rule from the five questions still applies. If a spreadsheet calculates a release result, it is a Category 5 custom system with a small footprint, and its formulas, cell protection, and version control must be qualified. Treat them under infrastructure qualification and spreadsheet validation, validating scripts and low-code analytics, and validating RPA automation. The common finding is a result-calculating spreadsheet with no formula verification, no cell locking, and a different version on every analyst’s desktop.

A quick reference across the categories

The table below summarizes the map. Treat the GAMP category as typical, not fixed: the same product can land in a different category depending on how heavily it is configured or customized.

The GAMP 5 software categories referenced in that table are worth memorizing for any validation interview. In plain terms: Category 1 covers the underlying platform layer, the operating systems and database engines other applications run on. Category 3 covers a commercial product you run essentially as it ships, without tailoring its function. Category 4 covers a commercial product you adapt to your process through configuration. Category 5 covers software written specifically for you, whether built in-house or by a vendor. GAMP dropped the old Category 2 (firmware) in the first edition revision, so do not cite it as current. The framework is detailed in the GAMP 5 CSV framework.

The two regulations that cut across nearly every row are 21 CFR Part 11 (electronic records and electronic signatures) in the United States and EU Annex 11 (computerised systems) in Europe. Wherever a system holds an electronic record used for a GxP decision, or captures an electronic signature, these apply.

Roles and responsibilities across the system environment

A computerized system has more owners than people expect, and an inspector will ask who does what. The clean way to describe it:

The separation that matters most: the person who administers user accounts should not also be a routine user who could grant themselves rights and cover the change. And QA must be independent of the people who build and run the system. Roles are covered more fully in GxP roles and responsibilities and data governance roles and careers.

Integration and interface pitfalls across systems

No system in this map operates alone. A surprising share of data integrity failures live in the seams between systems rather than inside any single one, because every interface adds a translation, a timing gap, or an assumption that the two systems agree on a definition they were never actually configured to share. A few pairings recur often enough to name directly.

LIMS and CDS. A common interface pulls only the final reported result from the CDS into the LIMS, with no link back to the raw chromatographic data, the specific injection, or the method version that produced it. If that result is questioned later, reconstructing its provenance means going back into the CDS by hand rather than following a system-maintained link.

MES and ERP. Batch genealogy and material consumption records need to move in both directions faithfully. A common pitfall is an interface that transmits genealogy only in one direction, or that silently drops a mid-batch component substitution, so ERP inventory reconciles cleanly while the genealogy an investigator needs during a recall does not actually trace to what was physically consumed.

Historian and MES. Process parameter values get pulled into the electronic batch record as supporting evidence, and a clock or time-zone mismatch between the historian and the MES server can shift a parameter that was genuinely within the batch window just outside it once the two records are reconciled, an artifact of the interface rather than the process.

EDC and safety databases. Adverse event data flows from the clinical database to pharmacovigilance systems, and a mapping change on one side, a new eCRF field, for example, that is not propagated to the transfer specification, can silently stop a field from populating. Nobody notices until a periodic reconciliation catches it, if one is scheduled at all.

ERP or WMS and LIMS or eQMS. Quarantine and release status has to move correctly between the system that holds the disposition decision and the system that controls physical or logistical access to the lot, covered in more detail in the warehouse management section above.

The pattern behind all five is the same, and it is worth stating as a standing rule: every interface needs a documented, field-level data-flow map, a defined failure behavior that fails safe rather than silently dropping or defaulting to a permissive state, and a periodic reconciliation between source and target record counts, not only a one-time test at validation. Building that map is its own discipline; see building a GxP data flow map for how to do it system by system.

Common inspection findings, across all categories

These patterns repeat regardless of system type, and recognizing them is half the job:

• Shared or generic logins, so changes cannot be attributed to a person. This breaks the “attributable” in ALCOA+ at the root.
• Audit trail disabled or never reviewed. Having an audit trail no one looks at is not a control; the operationalizing audit trail review discipline is what inspectors test.
• Configuration not under change control, so limits, recipes, or workflows drift without review.
• No periodic review, so a system validated at go-live silently decays as patches, users, and configurations change over years. See validation master plan and periodic review.
• Backup that was never test-restored. A backup you have never restored is a hope, not a control. See backup, restore, and disaster recovery validation.
• System time not controlled, so timestamps cannot be trusted as contemporaneous.
• Legacy systems with no validation evidence, addressed through retroactive validation of legacy systems.

The pattern-spotting skill behind these is in FDA warning letters patterns and the CSV/CSA audit checklist.

Building the right validation strategy across systems

Not every system needs the same treatment, and trying to validate them all to the same depth wastes effort that should go to the systems that actually carry risk. GAMP 5 Second Edition (ISPE, 2022) and the FDA’s “Computer Software Assurance for Production and Quality Management System Software,” issued as a draft in 2022 and finalized in September 2025 (both then titled ”…Production and Quality System Software”), with the current version issued 3 February 2026, both push the same point: scale the effort to the risk. Three factors drive the call.

1. Business and patient-safety criticality. Does the system directly affect product quality, patient safety, or the integrity of GxP records? A LIMS does. An internal HR system does not. The criticality of the function, not the price of the software, sets the floor for rigor.
2. System complexity and novelty. Is this an off-the-shelf product used as configured, or a heavily configured or custom system doing something with little prior precedent? More configuration and more novelty mean more to verify and more that can go wrong.
3. Existing evidence and supplier maturity. Does the vendor run a credible quality system with documented testing you can review and rely on? Relying on supplier evidence, backed by a real supplier and vendor qualification, can replace large amounts of duplicated testing. Cloud and software-as-a-service systems lean heavily on this, which is why cloud and SaaS validation treats vendor assessment as a core deliverable.

Combine these and the strategy writes itself. A standard LIMS from a mature vendor, used with default configuration for a well-understood function, earns a lighter, assurance-focused approach with critical thinking applied to the high-risk functions. A custom MES running a novel manufacturing process with no regulatory precedent earns a deeper, document-everything approach. The frameworks for doing this consistently are in the GAMP 5 CSV framework and computer software assurance.

The CSA shift is worth understanding because interviewers ask about it. Computer Software Assurance reframes the question from “have you documented every test” to “have you put critical thinking where the risk is and unscripted or exploratory testing where it adds more value than another screenshot.” It does not lower the bar for high-risk functions. It moves effort off low-risk functions that traditional CSV over-documented. The companion practice is software supplier assessment under CSA.

Two cross-cutting disciplines apply to every system regardless of category. The first is data governance: someone has to own the policies, the periodic reviews, and the audit trail review cadence that keep these systems trustworthy over years, not just at go-live. See data governance framework and DI program architecture. The second is the system’s whole life: how it is patched, how it stays in a validated state through change, how it is backed up and recovered, and how its records stay readable when it is finally retired. Those topics live in change control for validated systems, backup, restore, and disaster recovery validation, and data migration validation.

Interview questions on this topic, and how to answer them

These come up in validation, QA, and data integrity interviews. Short, concrete answers win.

“A computerized system lands on your desk. How do you decide how much to validate it?” Run the five questions: what GxP decision does its output drive, where is the original record, who can change the data and is every change captured, how are signatures handled, and what happens on failure or retirement. Then risk-assess the functions and scale the effort to criticality, complexity, and supplier maturity. Cite GAMP 5 Second Edition and the CSA guidance finalized in 2025 and revised 3 February 2026.

“Why is the CDS the most scrutinized system in the lab?” Because it owns the raw chromatographic data behind release decisions, and its default configuration often does not capture old and new values for integration changes, and it allows reprocessing and deletion. The classic findings are shared logins, unreviewed trial injections, testing into compliance, and audit trails switched off. The fix is unique accounts, restricted reprocess and delete rights, forced audit trail, and a defined integration-trail review step.

“What does GAMP Category 4 versus 5 mean, and give an example of each?” Category 4 is a configured off-the-shelf product, such as a LIMS or eQMS configured to your processes. Category 5 is custom or bespoke software, such as a custom MES module or a result-calculating spreadsheet. Note that Category 2 (firmware) no longer exists in current GAMP.

“When does 21 CFR Part 11 apply?” When a record required by a predicate rule is created, modified, maintained, archived, retrieved, or transmitted electronically, or when an electronic signature is applied to a regulated record. Without a predicate-rule requirement behind it, the record is outside Part 11 scope.

“How do you handle a shared operator console where setpoint changes all come from one generic account?” That breaks attribution. The fix is individual authentication at the point of a GxP-relevant change, even if the console session is shared, plus an audit trail that records the named individual with old and new values for every setpoint change.

“What is the difference between source data in an EDC and a transcription?” If data is captured directly into the EDC at the point of observation with no prior record, the EDC entry is the source. If it is written somewhere first and typed in later, that first record is the source and must be retained and controlled. The data management plan must declare which is which, field by field, before the trial opens.

“Name three findings you would expect to see across these systems.” Shared logins that break attribution, audit trails that exist but are never reviewed, and backups that have never been test-restored. Each maps to a specific ALCOA+ principle and a specific control.

For a fuller bank of questions and a study plan, see GxP quality interview preparation and, if you are entering the field, breaking into GxP quality and career guide GxP validation.

Practical tips

• Build a system inventory before anything else. You cannot govern what you have not listed. Every GxP system, its owner, its category, its validation status, and its records.
• Walk the data, not the org chart. Follow a release result from the instrument through the CDS, into the LIMS, into the disposition, into ERP. The seams between systems are where integrity breaks.
• Audit trail review is a job, not a checkbox. Decide what gets reviewed, how often, and by whom, and make it risk-based so the CDS and MES get more attention than the meeting scheduler.
• Treat spreadsheets and scripts as systems. They are the ones that hide, and they calculate release results.
• Keep the configuration under change control from day one. Most decay happens through small, unreviewed config changes, not through code defects.

Understanding the system environment is the first step, and it is a real step, not a formality. Knowing what each system does, what records it owns, and how it tends to fail gives you the foundation to build a coherent validation program across all of them, and to walk an inspector through it without surprises. From here, the natural next reads are GxP computerized systems operations for the day-to-day running of these systems, and the GxP CSV data integrity glossary when an acronym still trips you up.