SOP: GxP Computerized System Inventory Management

This is a ready-to-use SOP for owning the one artifact the rest of your computerized-systems program hangs off: a current, classified inventory of every GxP system. It governs how systems are enumerated, scoped, classified, tiered, tracked through validation and periodic review, and retired, and how the inventory is kept from decaying. Replace every <<FILL: ...>> placeholder, set your document numbers and dates, and route it through your normal document control. A filled specimen follows. The full reasoning is in the GxP computerized system inventory and classification; verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> establishes and maintains a complete, current inventory of computerized systems used in GxP operations, and how each system is scoped, classified, risk-tiered, and tracked through its lifecycle. The objective is that, at any time, the company can show which systems it relies on for GxP decisions and, for each, whether it is in scope, how it was built, how much it matters, its validation status, its next review, and the disposition of its data.

2. Scope

This procedure covers all computerized systems that create, modify, store, transmit, or make decisions about GxP records or processes at the sites in the header, including enterprise applications, instrument and process control systems, spreadsheets and small tools, cloud and SaaS applications, and the infrastructure they run on. It covers the inventory itself and the classification decisions; the execution of validation, periodic review, and decommissioning is governed by <<FILL: SOP-IDs for validation, periodic review, decommissioning>>.

3. Responsibilities

4. Definitions

• Computerized system: the software plus the hardware it runs on, plus the controlled function or process it operates, plus the people and procedures around it.
• GxP scope: whether a system creates, controls, or decides on GxP records or processes such that predicate rules apply.
• GAMP category: the GAMP 5 software category (1 infrastructure, 3 non-configured, 4 configured, 5 custom) that scales effort to how much of the system you built or configured.
• Risk tier: the criticality class (High/Medium/Low) that scales effort to how much the system matters to product quality, patient safety, and data integrity.
• Shadow system: a GxP-relevant system in use but absent from the inventory and outside validation and change control.

5. Procedure

5.1 Enumerate

Discover systems by triangulating across at least these independent sources, because no single source is complete:

1. Walk each GxP business process and capture every point where a person or instrument touches data through software.
2. Mine procurement, license, and SaaS billing records for tools IT never provisioned.
3. Pull IT asset and identity records (CMDB, directory, network and endpoint lists).
4. Interview analysts, operators, and data managers for the tools they actually use.
5. Review instruments that produce, store, or control data, including firmware-driven ones.

Reconcile the lists and record a disposition (added, de-scoped, retired, duplicate) for every discrepancy. A named owner attests the population is current as of a stated date.

5.2 Decide GxP scope

Apply the documented scoping decision for each candidate. A system is in GxP scope if any of the following is true; record which trigger fired:

1. It creates, modifies, stores, or transmits a record required by a GxP predicate rule (GMP, GLP, GCP, GDP, GVP).
2. It controls or monitors a GxP process, equipment, or environment.
3. Its output feeds a quality decision (release, disposition, OOS, stability, safety).
4. It generates, manages, or reports an electronic signature or a Part 11 / Annex 11 record.

For “out of scope” systems, record the rationale. For partial-scope systems, name the in-scope functions.

5.3 Assign a GAMP category

Classify each in-scope system’s software as Category 1, 3, 4, or 5 per <<FILL: SOP-ID or worksheet for GAMP categorization>>. Where a system spans categories (a configured product with a custom interface), classify the parts honestly.

5.4 Assign a risk tier

Assign High, Medium, or Low based on impact to product quality, patient safety, and data integrity. The tier must drive real downstream behavior: validation depth, periodic-review frequency, change-control path, backup/DR posture, and whether the system owes an Annex 11 system description.

5.5 Record validation and periodic-review status

For each system, record its validation status (validated, in validation, legacy/retrospectively assessed, not-yet-validated-in-use, or retired) with the report reference and date, and its next periodic-review due date derived from its tier. A “not yet validated, in use” state triggers immediate risk assessment and a quality event, not a quiet inventory row.

5.6 Maintain the inventory

Wire currency into processes that already happen:

1. Make an inventory entry and a scoping decision a gating precondition for procuring or deploying any system.
2. Reconfirm inventory metadata at every periodic review.
3. Run a periodic (commonly annual) multi-source completeness reconciliation and document it.
4. Keep a single controlled, version-managed master; the controlled copy is the only trusted one.

5.7 Retire

Decommission systems under change control per <<FILL: SOP-ID for decommissioning>>: an approved plan, a dependency check, verified data disposition (validated migration or a retained readable archive), access removal, and a decommissioning summary. The system stays on the inventory marked retired, not deleted, because the data and the obligation persist.

6. Acceptance criteria

• Every GxP business process has been enumerated from at least three independent sources and reconciled, with a dated owner attestation.
• Every in-scope system has a recorded scope trigger, a GAMP category, and a risk tier applied consistently.
• The High-tier list reconciles with the systems that genuinely gate quality decisions; no critical system is parked in a lower tier.
• Each system carries a validation status with a report reference and a next-review due date; no reviews are silently overdue.
• Retired systems remain on the inventory with a decommissioning reference and verified, retrievable data.
• A single named owner is accountable for the master inventory’s currency.

7. Records generated

• The master computerized system inventory (controlled, versioned).
• Enumeration reconciliation records and the annual completeness reconciliation.
• Scoping decision records with the trigger or the out-of-scope rationale.
• Decommissioning summaries for retired systems.

8. References

21 CFR 211.68 (automatic equipment); 21 CFR Part 11 (electronic records and signatures). EU GMP Annex 11 (computerised systems) and Chapter 4 (documentation). A draft Annex 11 revision and a draft Annex 22 (AI) went to consultation on 7 July 2025 (Annex 11 consultation closed 7 October 2025) and remain drafts as of mid-2026; confirm the final text before citing. PIC/S PI 011 (computerised systems) and PI 041 (data management and integrity). ISPE GAMP 5 (second edition); describe by title, do not paste. ICH Q9 (Quality Risk Management), for the risk-based tiering.

Confirm the current version and clause numbers of each reference before issue.

9. Revision history

10. Approvals

Filled specimen: one governed inventory row

The following shows the inventory state this SOP produces for a single system, so you can see the level of detail expected. The company, system, and numbers are illustrative; replace them with your own.

In this example every field drives an action: the review date drives the schedule, the validation status plus its report is the evidence on demand, and the system-description revision confirms the deep documentation exists and is current. That is the difference between an inventory that runs the program and a list that merely names things.

Common inspection findings this SOP prevents

• No current inventory of GxP computerized systems, so validation and control cannot be demonstrated.
• A stale inventory missing recently deployed systems and still listing retired ones.
• Shadow systems (spreadsheets, SaaS, instruments) in use but never inventoried or validated.
• Risk tiers with no downstream consequence, so a High system gets the same light touch as a Low one.
• Overdue periodic reviews visible across the inventory.
• Retired systems whose records can no longer be read because retention was never verified.

How to adapt this SOP

1. Set your document number, owner, and effective date, and point the cross-references to your real validation, periodic-review, and decommissioning procedures.
2. Reference your GAMP categorization and risk-tiering tools where sections 5.3 and 5.4 call for them.
3. Confirm every regulation in section 8 against the current published version before issue, in particular the status of the Annex 11 revision.
4. Name a single accountable owner for the master inventory before you issue this SOP; without one, it will decay.