Skip to main content

GxP System Inventory
Frequently Asked Questions

The GxP System Inventory is the controlled register that tells regulators — and the organisation itself — exactly what computerised systems are operating in a GxP environment and whether each one is validated. These questions cover what the inventory must contain, how systems are classified, what inspectors look for, how to handle unregistered systems, cloud tools, and spreadsheets, and why lapsed periodic review dates are one of the most cited inventory findings.

Written by: Sundar ·Published: July 23, 2026 ·Last updated: July 23, 2026
Quick Answer

What is the first question a GxP Inventory must be able to answer during an inspection?

Is every system currently processing GxP-regulated data listed here, and is each one validated? If the inventory is current and accurate, that answer takes minutes. If it is stale or on a spreadsheet, it requires days of reconstruction under inspection pressure — which is precisely why inventory currency is one of the first things regulators assess when they arrive on site.

EU GMP Annex 11; GAMP 5 Second Edition; FDA General Principles of Software Validation

A GxP System Inventory is a controlled register of every computerised system, application, and automated tool operating at a site that has a direct or indirect impact on product quality, patient safety, or data integrity. It is required because regulators expect organisations to know what is in their GxP environment before they can demonstrate it is all controlled and validated. Without a current, accurate inventory, an inspector cannot confirm that undiscovered systems are not processing regulated data outside a validated state.

Each inventory entry should capture: a unique system identifier, system name and vendor, current software version and patch level, system owner and department, GxP impact classification (direct, indirect, or no impact), GAMP 5 software category, current validation status (validated, conditionally released, pending revalidation, or retired), the applicable Validation Master Plan reference, the System Release Certificate reference, the next periodic review due date, and the date the entry was last reviewed and by whom. Incomplete entries make the inventory unreliable as a compliance dashboard.

Every system that creates, processes, stores, archives, retrieves, or transmits data used to make decisions about product quality, patient safety, regulatory submissions, or that controls a GxP-regulated process should be included. The starting point is a site-wide system survey cross-checked against process maps and data flow diagrams — not a self-reported list from individual departments. Commonly overlooked systems include laboratory instruments with embedded software, spreadsheets used for batch release calculations, and cloud-based document management tools accessed for GxP records.

An IT Asset Register records every hardware and software asset for IT management purposes — procurement, licensing, support lifecycle, and cost — regardless of GxP relevance. A GxP Inventory is a quality-controlled subset focused on compliance information: GxP impact, GAMP category, validation status, periodic review schedule, and SRC references. A system may appear in both, but the GxP Inventory contains the compliance attributes that the IT register does not hold, and it is a controlled GMP document subject to change control and QA approval.

The inventory should be reviewed and formally updated at minimum annually as part of the site's quality management review cycle, and immediately when any of the following occur: a new system enters GxP service, an existing system is upgraded or significantly changed, a system is retired or decommissioned, a periodic review changes a system's validation status, or a risk reclassification is triggered by a regulatory guidance change. An inventory reviewed only annually without interim updates will be out of date within months on any active pharmaceutical site.

An unregistered system found operating in a GxP context must be immediately assessed: a GxP impact evaluation determines whether it should have been in the inventory, and if so, a retrospective impact assessment determines whether its current use has created a compliance gap. If validated data has been produced on an unregistered, unvalidated system, a deviation should be raised, the data reviewed for integrity, and remediation planned. The system must then be registered, risk-classified, and validated before continued GxP use.

Retired systems should not be deleted from the inventory — they should be marked as Retired with the decommissioning date, a reference to the decommissioning record, and a note on data archival status. Retaining retired system records is essential because inspectors reviewing historical GxP data may need to verify that the system which produced those records was validly released and in a controlled state at the time. Deleting inventory entries for retired systems removes this backward traceability permanently.

Inspectors assess currency, completeness, and coherence. They check whether the inventory reflects systems actually observed in use during the inspection walk-through — any system in operation not listed in the inventory is an immediate finding. They verify that validation status entries are consistent with available VSRs and SRCs, that periodic review dates have not lapsed, and that version information matches what is running in production. A well-maintained inventory accelerates inspections; a stale or incomplete one signals a systemic gap in the quality system.

The GxP Inventory is the operational list that populates the VMP's scope — the VMP describes how each category of system in the inventory will be validated, while the inventory tracks the individual system entries and their current status. The two documents must be consistent: a system in the inventory must be addressable under the validation approach described in the VMP, and the VMP's scope exclusions must match the inventory's classification decisions. Inspectors routinely cross-check both documents to identify scope discrepancies.

Yes. Recording the GAMP 5 category for each system in the inventory serves two practical purposes: it documents the rationale behind the validation approach chosen (lower-category systems justify lighter-touch validation), and it allows the site to demonstrate risk-based proportionality when inspectors ask why a particular system was validated to a specific depth. If a Category 3 system was validated using a Category 5 approach — or vice versa — without documented rationale, inconsistency between inventory classification and validation evidence will be visible during cross-checking.

Each system should have a documented impact classification — Direct (system directly controls a critical process parameter or generates GxP records), Indirect (system supports a direct-impact system without itself touching product or records), or No GxP Impact — based on a formal impact assessment. Classification can change: a reporting module initially classified as indirect may become direct if it is used to generate batch release decisions. Any reclassification should go through change control and trigger a review of whether the existing validation scope remains adequate for the new classification.

Yes. The same enterprise system — an ERP or LIMS, for example — may be classified differently across sites if its use differs. At one site it may directly control a batch release function and be classified as direct impact; at another site it may be used only for logistics tracking with no GxP impact. Each site's inventory should reflect that site's actual use of the system, and validation should be conducted at the appropriate depth for each classification independently, even if the underlying platform is shared.

The inventory entry is a summary record — a controlled register line that holds key attributes and status information for a system. The validation file is the complete collection of GMP documents for that system: URS, risk assessments, protocols, executed test reports, deviation records, VSR, and SRC. The inventory entry references the validation file; it does not contain it. Think of the inventory as the table of contents for the site's validation programme, with the validation file being the full document set for each individual chapter.

Cloud and SaaS systems should be registered in the GxP Inventory using the same fields as on-premises systems — with additional entries recording the hosting model (cloud/SaaS), the vendor's data centre location, whether a supplier quality audit or qualification has been completed, and who is responsible for infrastructure qualification versus application validation. The fact that infrastructure is vendor-managed does not reduce the organisation's obligation to maintain a validated, documented state for GxP data processed on that platform.

Each inventory entry should carry a Next Periodic Review Due date, calculated based on the system's risk classification — typically annually for high-risk direct-impact systems and biannually for lower-risk systems. When a periodic review is completed, the inventory entry is updated with the review completion date, the reviewer's identity, the outcome (no change required, revalidation triggered, or status change), and the revised next due date. Lapsed periodic review dates in the inventory are one of the most common inspection observations for sites with large system portfolios.

Yes, if a spreadsheet is used to create, process, or report GxP-relevant data — for example, a macro-enabled Excel file used to calculate batch release decisions or generate specification tables included in regulatory submissions. Spreadsheets used for GxP purposes are computerised systems and are subject to the same validation and data integrity requirements as any other system, including version control, change control, and access restrictions. Excluding spreadsheets from the inventory because they "are just Excel" is a frequently cited inspection finding.

The inventory should capture the vendor name, their quality system assessment or audit status with the most recent date, whether the vendor holds relevant certifications (ISO 9001, ISO 27001, SOC 2), and whether a Quality Technical Agreement is in place. For cloud-hosted systems, the data processing agreement and sub-processor information should be referenced. Supplier information in the inventory enables rapid assessment during change management — when a vendor releases a new version, the inventory immediately shows whether that vendor's quality system has been assessed and at what level.

Status values should be unambiguous and cover all possible states: Validated (full SRC issued with no open conditions), Conditionally Released (SRC issued with tracked open conditions), Pending Validation (impact assessed, validation in progress), Retrospective Validation Required (system in use, validation gap identified), Pending Periodic Review (review overdue or in progress), Pending Revalidation (change triggered revalidation not yet complete), and Retired. Vague statuses like "In Progress" or "Under Review" hide whether a system is currently in a validated state or not — which is the single most important question the inventory must answer.

A current, accurate inventory gives the site a real-time answer to the inspector's first question: "Show me every GxP system you operate and confirm each one is validated." If the inventory is live and accurate, this answer takes minutes. If the inventory is outdated or on paper, the answer requires days of reconstruction under inspection pressure. Organisations with digital, live inventories also detect drift automatically — lapsed periodic reviews, unregistered new systems, and version mismatches surface as alerts rather than inspection surprises.

A digital platform maintains the inventory as a live, linked record — when a VSR is approved, the system's inventory status updates automatically; when a periodic review date lapses, an alert is raised; when a new system is registered, the platform routes it through the impact assessment and classification workflow before it appears in the inventory. Spreadsheet inventories require manual updates that are missed under operational pressure, have no automated escalation for lapsed reviews, and carry no audit trail showing who changed a status entry or why.