The line between GxP and non-GxP systems depends on what the software is used for, not on what kind of software it is. A system is in GxP scope when it creates, processes, stores, archives, retrieves or transmits data used for decisions about product quality, patient safety or regulatory submissions, or when it controls a GxP-regulated process. The regulated company makes that call and carries ultimate responsibility for the validation evidence at inspection. The same ERP or LIMS can land on either side of the line depending on how a given site uses it.
What is a GxP system, and what does the “x” in GxP stand for?
GxP is the collective name for the “good practice” regulations and guidelines covering medical products. The “x” stands in for the field: GLP (laboratory), GCP (clinical), GMP (manufacturing), GDP (distribution), GVP or GPvP (pharmacovigilance) and others. Each of these is its own separately codified set of rules, not a variant of one master document. No single global regulator owns GxP. Each country or region has its own guidelines and inspectors, although the requirements are broadly similar from one to the next.
A GxP system is a computerised system used in one of those regulated processes. When a company uses a computerised system for a GxP process, it must validate that system and operate it appropriately for its intended use. Annex 11 of the EU GMP Guide defines a computerised system as a set of software and hardware components that together fulfil certain functions, where the application is validated and the IT infrastructure qualified. If you want the wider picture of GxP as a quality discipline rather than a software question, our practical guide to GxP in pharma covers it.
GxP systems in pharma: LIMS, MES, QMS, ERP modules and the ones people forget
The usual suspects are systems that hold or control regulated records. Laboratory information management systems (LIMS), electronic lab notebooks (ELN) and instrument software all need documented validation and Part 11-compliant audit trails when they hold electronic records or signatures. FDA names LIMS and electronic batch record (EBR) systems as examples of systems that can be designed to meet CGMP documentation practices, for instance by saving automatically after each entry.
PIC/S PI 041-1 (2021) gives a useful list of critical systems to review:
- systems that control the purchasing and status of products and materials;
- systems for control and data acquisition in critical manufacturing processes;
- systems that generate, store or process data used to determine batch quality;
- systems that generate data included in batch processing or packaging records;
- systems used in the product release decision.
PIC/S PI 011-3 widens the lens to data systems for coding, randomisation, distribution, product recalls, clinical measures, patient records and laboratory data.
Then there are the systems nobody registered. A spreadsheet is a GxP system when it creates, processes or reports GxP-relevant data, such as a macro-enabled Excel file that calculates batch release decisions or produces specification tables for a submission, and it carries the same validation, version control and access requirements as any other system. Communications count as well: FDA treats an email authorising batch release as a CGMP record it may review.
GxP vs non-GxP systems: how the classification is decided
The test is impact, assessed against intended use. Annex 11 applies to all computerised systems used as part of GMP-regulated activities, and asks that risk management across the system lifecycle weigh patient safety, data integrity and product quality. PIC/S defines GxP-critical systems as those that can affect product quality and patient safety, either directly (control systems) or through the integrity of product-related information. An inspector assessing a system looks at the risks to product quality or data integrity that the regulated user has identified and documented.
On the US side, the question runs through predicate rules. FDA reads Part 11 narrowly: it applies to records required under predicate rules (such as the CGMP regulations) that are kept electronically in place of paper, and records not required by a predicate rule are not Part 11 records even if they are electronic. Business practice matters too: if you print a record but still rely on the electronic version to do the regulated work, FDA may treat you as using the electronic record.
For research and development, a third test applies: what the data will be used for. A toxicology study meant to support an IND must run under GLP wherever it happens, and the regulatory intent of the data, not the institution or the funding, decides whether GxP applies.
Direct, indirect or no impact
A formal impact assessment records the outcome as one of three impact classes. Direct impact means the system controls a critical process parameter or generates GxP records; indirect impact means it supports a direct-impact system without touching product or records itself; no GxP impact is the third class. PIC/S PI 041-1 gives direct GMP/GDP impact, indirect impact or none as examples of the criticality assessment its inventory should reference.
Systems that do both
FDA’s position is clear: when one system performs both CGMP and non-CGMP functions, the potential for the non-CGMP functions to affect CGMP operations has to be assessed and mitigated. We would map the data flows first and only then decide where the GxP boundary sits, because a boundary drawn on a feature list rarely survives a look at the interfaces. PI 041-1 supports that order of work: risk assessments should follow the business process and its data flows, not just IT functionality.
Which software and data flows fall inside GxP scope, and which stay outside
The table below is a quick scoping aid. Each row is a signal a team can check against a system’s actual use.
| Signal | Usual outcome | Basis |
|---|---|---|
| Generates or stores records required by a GxP predicate rule, kept electronically | In scope | FDA Part 11 scope guidance |
| Controls a critical manufacturing process or feeds batch release | In scope, critical | PIC/S PI 041-1 |
| Transfers GxP data between systems | In scope; the interface itself needs validation | WHO TRS 1033 Annex 4; PIC/S PI 041-1 |
| Supports a direct-impact system without touching product or records | Indirect impact | GxP inventory guidance |
| Spreadsheet calculating GxP results | In scope | GxP inventory guidance |
| Simple instrument with no configurable software or data retention (pH meter, balance) | May need only calibration rather than validation | MHRA 2018 |
| Word processor used only to draft SOPs | Validation not important, per FDA | FDA Part 11 guidance |
| Electronic records not required by any predicate rule | Not Part 11 records | FDA Part 11 guidance |
| Exploratory academic research not intended for a submission | Outside GLP, GCP and GMP | CASRAI |
| ERP used only for logistics tracking at a given site | No GxP impact at that site | GxP inventory guidance |
WHO expects transfer and migration procedures to be validated and audit-trailed, and warns that the challenge of keeping the full meaning of migrated records is often underestimated. Cloud infrastructure is not a way out either: FDA’s definition of computer or related systems explicitly includes cloud infrastructure, alongside hardware, software, networks, personnel and documentation.
Classification is also not permanent. PIC/S notes that retrospective validation may be justified when a non-GxP system is newly classified as GxP.
Recording the decision: inventory, impact class and GAMP 5 category
The inventory is where classification is recorded. Annex 11 asks for an up-to-date list of all relevant systems and their GMP functionality, and for critical systems a description of physical and logical arrangements, data flows and interfaces. PIC/S expects the inventory to cover ownership, supplier, functionality, links and validation status, plus a risk ranking. A typical entry records the system identifier, name, vendor, version, owner, GxP impact class, GAMP 5 software category, validation status, Validation Master Plan reference and the next periodic review date.
The GAMP 5 categories in brief
GAMP 5 Second Edition uses four software categories:
- Category 1: infrastructure software, tools and IT services, such as operating systems, database platforms and middleware.
- Category 3: standard components used as supplied, without material process-specific configuration.
- Category 4: standard software configured through supported settings or parameters to fit a particular process.
- Category 5: custom applications and components, including bespoke code, scripts or interfaces with GxP impact.
Category 2 is legacy terminology. The setup a site actually runs decides between Category 3 and 4, not the product brochure, and one system often combines several categories, so assessing component by component tells you more than a single label.
A category is a starting point, not a risk rating or a validation recipe. It describes the nature of the software and so informs how much supplier involvement and lifecycle evidence is appropriate, alongside GxP impact, complexity, novelty and data integrity risk. PIC/S made the same point years earlier: complex integrated systems span category levels, and critical systems need a holistic risk-based approach across the whole application.
Recording the category in the inventory does two practical jobs: it documents why a validation approach was chosen (lower-category systems justify lighter validation), and it lets the site show risk-based proportionality when an inspector asks why a system was validated to a given depth.
We would work to the adopted 2011 text of Annex 11 rather than to any draft wording.
Who owns the GxP classification decision: the regulated company, the vendor, or both?
The regulated company owns the decision. PIC/S states that regulated users define the relevant applications and impacted business units, and that they carry ultimate responsibility for making validation evidence available to inspectors. PI 041-1 puts it more bluntly: each regulated entity is responsible for fully evaluating and controlling all its computerised systems. Outsourcing does not move that responsibility; the regulated entity keeps it.
Vendors contribute evidence, not the verdict. AWS notes that no certification exists for GxP regulations, so each customer defines its own risk profile. Under the shared model AWS describes, the cloud supplier becomes responsible for qualifying its physical infrastructure, virtualisation and service layers, while the regulated company stays accountable. Google Cloud states that responsibility for GxP compliance ultimately lies with its life science customers, and Microsoft tells Azure customers to determine the GxP requirements for their systems based on intended use and to follow their own qualification and validation procedures.
The reason is structural. Classification depends on intended use. The MHRA says that accepting vendor-supplied validation data in isolation from the system’s configuration and the user’s intended use is not acceptable. Where cloud or virtual services are involved, a technical agreement or contract should define each party’s responsibilities and ensure timely access to data, metadata and audit trails for the data owner and regulators.
How a GxP system relates to GxP data and ALCOA+
The MHRA defines GxP data as all original records and true copies, including metadata and later transformations, generated or recorded at the time of the GxP activity, that allow the activity to be fully reconstructed. FDA adds that when data is generated to satisfy a CGMP requirement, it becomes a CGMP record.
That data must meet ALCOA+: attributable, legible, contemporaneous, original and accurate, plus complete, consistent, enduring and available throughout the data lifecycle for the retention period. The MHRA notes that expectations are the same whether ALCOA or ALCOA+ is used. WHO expects GxP systems to retain audit trails showing users, dates, times, original data, changes and reasons for changes, and it expects those audit trails to be enabled at installation and to stay enabled. For systems generating or storing GxP data, shared logins should not be used.
How much control each system needs depends on data criticality, which PI 041-1 frames as how much the data affects decisions and product quality: assay data for an oral tablet generally matters more than friability data, and batch release data more than warehouse cleaning records. For legacy systems that cannot support ALCOA+ by design, WHO allows justified mitigation such as add-on software or paper controls for defined temporary periods. Building and maintaining those controls is a validation question, and we cover it in GxP software validation and ALCOA+ data integrity.
For software teams, the practical consequence is that data integrity requirements belong in the initial stages of procurement, not at go-live. Teams building such systems with AI can see how TechnoLynx approaches validation-ready AI for GxP operations and AI engineering for life sciences and healthcare.
FAQ
What is the difference between GLP and GxP?
GLP (Good Laboratory Practice) is one member of the GxP family, covering nonclinical safety and toxicology studies used to support a regulatory submission. GxP is the umbrella term that also includes GCP, GMP, GDP, GVP and others.
What are the 21 CFR regulations relevant to pharmaceuticals?
In the US, drug CGMP sits in 21 CFR Parts 210 and 211, GLP in Part 58, medical device quality systems in Part 820, and electronic records and signatures in Part 11.
Who enforces GxP and CGMP requirements?
Regulators enforce them through routine and for-cause inspections and unannounced audits. Companies are also expected to verify the GxP compliance of partners in their supply chain.
