Computerized System Types, Intended Use, and GxP Classification

Computerized systems support manufacturing, laboratory, quality, engineering, warehousing, and regulatory processes throughout pharmaceutical operations. They may control equipment, perform calculations, manage workflows, create electronic records, transfer data, or provide information used for product-quality decisions.

A computerized system should not be classified by its product name alone. The same software platform can be used for a nonregulated administrative purpose at one site and for a critical Good Practice (GxP) process at another. Classification must therefore begin with the business process, intended use, regulated records, and consequences of system failure.

The objective is not to place every system into a generic high-, medium-, or low-risk category and assign a predetermined validation package. The objective is to understand the system, determine its GxP relevance, identify the functions and records that matter, and establish a proportionate validation and lifecycle-control strategy.

What Constitutes a Computerized System?

A computerized system is more than an installed software application. It includes the components and controlled activities needed to perform its intended function reliably. The system may include:

• application software;
• configured workflows and business rules;
• custom code, scripts, or macros;
• hardware and instruments;
• servers, virtual machines, and cloud infrastructure;
• operating systems;
• databases;
• networks and storage;
• identity and authentication services;
• system interfaces;
• data and metadata;
• reports and electronic records;
• users and administrators;
• operating procedures;
• supplier services;
• backup and recovery functions; and
• supporting documentation.

FDA’s Data Integrity and Compliance With Drug CGMP guidance explains that validation controls should address software, hardware, personnel, and documentation. System evaluation limited to the application software can therefore omit infrastructure, interfaces, user practices, and records that determine whether the complete process remains controlled.

For example, a laboratory information management system (LIMS) may depend on:

• the configured LIMS application;
• the application and database servers;
• laboratory master data;
• instrument interfaces;
• enterprise-system interfaces;
• authentication services;
• electronic-signature controls;
• reporting tools;
• backup infrastructure;
• procedures;
• trained users; and
• supplier or cloud-provider services.

Failure of any of these elements can affect the intended process even when the core application software operates as designed.

System Inventory

A controlled system inventory provides the starting point for governance, classification, validation planning, periodic review, and retirement.

The inventory should identify, as applicable:

• unique system name and identification number;
• application and platform;
• version;
• system description;
• business process;
• intended use;
• operating location;
• production status;
• system owner;
• process owner;
• technical owner;
• quality oversight;
• supplier;
• hosting model;
• GxP applicability;
• regulated record types;
• system of record;
• interfaces;
• software category;
• system-impact classification;
• validation status;
• Part 11 applicability;
• data-retention requirements;
• support status;
• periodic-review status; and
• retirement status.

The inventory should be maintained under defined ownership and change control. New applications, modules, interfaces, instruments, infrastructure services, and end-user applications should be assessed before regulated use.

An incomplete inventory creates several lifecycle risks. Systems may operate without a documented GxP assessment, interfaces may remain outside the validation boundary, unsupported applications may not be identified, and regulated records may be stored without adequate retention or recovery controls.

The inventory should also identify inactive and legacy systems that retain regulated data. A system does not cease to be GxP-relevant merely because it no longer processes new transactions.

Business Process Comes Before Technology

Classification should begin with the business process supported by the system. The assessment should describe:

• what process is performed;
• why the process is required;
• which users and departments participate;
• what information enters the process;
• what calculations or transformations occur;
• what decisions are made;
• what outputs are produced;
• what records are created;
• which other systems receive the information; and
• what could happen if the process or its records are incorrect or unavailable.

Typical computerized-system applications include:

• manufacturing execution;
• process control;
• laboratory testing;
• environmental monitoring;
• quality-event management;
• document control;
• training management;
• calibration and maintenance;
• materials management;
• warehouse control;
• batch release;
• stability management;
• labeling;
• serialization;
• complaint management;
• supplier quality management;
• regulatory information management; and
• business reporting.

Technology should be evaluated in the context of the process it supports. A database storing cafeteria menus and the same database product storing approved product specifications do not have the same GxP relevance, even though the underlying software may be identical.

Intended Use

The intended-use statement defines what the organization relies on the system to do. A useful intended-use statement should identify:

• the regulated business process;
• the principal users;
• the functions relied upon;
• the records created or maintained;
• the decisions supported;
• relevant interfaces;
• the operating environment; and
• important exclusions or limitations.

A weak intended-use statement might state: The application is used by the Quality department.

That statement does not explain what the system does or why its operation matters.

A stronger statement might state: The configured application is used by Quality personnel to initiate, investigate, approve, and retain deviation and corrective-action records supporting GMP operations. It controls workflow status, required approvals, due dates, electronic signatures, audit trails, and approved record retention.

The intended-use statement establishes the basis for:

• GxP applicability;
• system boundaries;
• requirements;
• risk assessment;
• supplier evaluation;
• validation scope;
• test coverage;
• security;
• data-integrity controls;
• release;
• change control; and
• periodic review.

Validation should address the actual functions used and relied upon. Unused supplier functionality does not automatically require the same verification as configured functions supporting regulated decisions. Conversely, a standard commercial feature becomes significant when the regulated process depends on it.

GxP Applicability

A system is GxP-relevant when it supports a regulated process, performs a regulated function, or creates, modifies, maintains, archives, retrieves, or transmits records required by applicable regulations or quality-system procedures.

The applicability assessment should consider whether the system:

• controls or monitors a manufacturing process;
• controls critical process parameters;
• controls equipment, utilities, or facilities;
• manages specifications or approved methods;
• performs or supports laboratory testing;
• performs calculations used in regulated decisions;
• determines acceptance or rejection;
• supports material or product status;
• supports batch release;
• creates or maintains GMP records;
• manages deviations, investigations, or corrective actions;
• manages training or qualification records;
• schedules or records calibration and maintenance;
• generates labels or product-identification information;
• transfers regulated data between systems;
• supports regulatory reporting; or
• protects the availability or integrity of regulated records.

Relevant US requirements depend on the system’s intended use. For drug manufacturing, 21 CFR 211.68 addresses automatic, mechanical, electronic, computer, and related systems, including accuracy of inputs and outputs, authorized changes, backup data, and appropriate validation evidence.

Where electronic records or signatures are used to meet applicable regulatory requirements, a documented assessment should determine the applicability of 21 CFR Part 11. Part 11 applicability is related to, but separate from, the broader GxP classification.

A system can be GxP-relevant without using electronic signatures. Likewise, a Part 11 assessment should not replace the complete evaluation of system functionality, data integrity, availability, interfaces, and process risk.

Non-GxP and Business-Controlled Systems

A system may be classified as non-GxP when it does not perform a regulated function, create or maintain a required record, control a regulated process, or provide information relied upon for a GxP decision.

Examples may include systems used exclusively for:

• general office administration;
• cafeteria management;
• nonregulated marketing;
• general-purpose communication;
• employee social activities; or
• financial functions without a regulated product or quality-system role.

The classification should still be documented when the system operates near a GxP process or exchanges information with regulated systems.

A non-GxP classification does not mean the system requires no controls. Business continuity, cybersecurity, privacy, financial, contractual, and corporate requirements may still apply. These controls are outside the GxP validation determination but remain part of responsible system governance.

A system initially classified as non-GxP should be reassessed before its use is expanded to support regulated data or decisions.

Computerized System Types

Computerized systems may be grouped by their business or technical role. System type helps organize the inventory and identify common controls, but it does not establish validation scope by itself.

Manufacturing and Process-Control Systems

Examples include:

• manufacturing execution systems;
• distributed control systems;
• supervisory control and data-acquisition systems;
• programmable logic controllers;
• human-machine interfaces;
• recipe-management systems;
• automated filling or packaging systems;
• building-management systems;
• environmental-monitoring systems; and
• equipment control systems.

These systems may control process parameters, sequences, alarms, interlocks, equipment status, electronic batch records, or material movement.

Laboratory and Analytical Systems

Examples include:

• laboratory information management systems;
• chromatography data systems;
• spectroscopy software;
• dissolution systems;
• microbial identification systems;
• laboratory execution systems;
• electronic laboratory notebooks;
• stability-management systems; and
• instrument data systems.

These systems may acquire raw data, execute analytical methods, process results, perform calculations, manage samples, control specifications, or support product-release decisions.

Quality-Management Systems

Examples include systems used for:

• deviations;
• investigations;
• corrective and preventive actions;
• change control;
• complaints;
• audits;
• document control;
• training;
• supplier quality;
• risk management; and
• quality metrics.

Their significance frequently results from the records, workflows, approvals, and decisions they control rather than from direct interaction with manufacturing equipment.

Enterprise and Business Systems

Enterprise resource planning and warehouse-management systems may manage:

• material identity;
• supplier status;
• inventory;
• lot status;
• production orders;
• bills of material;
• expiry dates;
• distribution;
• and product disposition.

An enterprise system should not be classified as non-GxP merely because it is also used for financial or administrative purposes. The assessment should identify the specific modules, functions, data, and interfaces supporting regulated operations.

Infrastructure and Platform Services

Examples include:

• operating systems;
• databases;
• virtual environments;
• cloud platforms;
• networks;
• storage;
• domain services;
• identity services;
• time services;
• backup systems;
• middleware; and
• monitoring tools.

Infrastructure may not perform the regulated business process directly, but it can affect system availability, security, record integrity, time attribution, data transfer, and recovery.

End-User Applications

Spreadsheets, databases, scripts, statistical packages, reporting tools, and low-code applications may perform calculations or manage regulated information.

Their apparent simplicity does not determine their significance. A spreadsheet used only to prepare a meeting schedule differs materially from a spreadsheet that calculates product acceptance results.

System Boundary

The system boundary defines what is included in the validated computerized system and what is controlled through interfaces, supplier agreements, infrastructure qualification, or related procedures.

The boundary should be based on the complete intended process and data flow.

It should identify:

• application modules;
• configured functions;
• custom components;
• hardware and instruments;
• servers or cloud services;
• databases;
• storage;
• middleware;
• authentication services;
• time synchronization;
• interfaces;
• reporting tools;
• backup and recovery services;
• administrative tools;
• procedures;
• users;
• suppliers; and
• retained records.

The boundary should also identify exclusions and explain how excluded components are controlled.

For example, an identity-management service may be qualified as shared infrastructure rather than retested completely within every application. Its dependency and required functions should still be identified within each application’s system architecture and risk assessment.

A narrow boundary can leave critical data paths or control services unassessed. An excessively broad boundary can create unnecessary duplication. The appropriate boundary includes the components whose operation or failure can affect the system’s intended GxP use.

Interfaces and Connected Systems

Interfaces should be included in the assessment because system classification cannot be determined reliably from one application in isolation.

The interface inventory should identify:

• source and destination systems;
• transfer direction;
• data or records transferred;
• authoritative source;
• transfer trigger;
• mapping or transformation;
• acknowledgments;
• exception handling;
• reconciliation;
• security;
• technical logs; and
• retained evidence.

A system may have limited standalone significance but become GxP-relevant because it transforms or transmits critical data to another system.

For example, middleware that maps laboratory results into LIMS may not approve the results, but incorrect mapping could associate a result with the wrong sample, alter a unit, change numerical precision, or lose a rejected transaction. Its indirect role can therefore be significant.

Authoritative Record Source

The classification assessment should identify the authoritative source for each critical record or data element.

The authoritative source is the controlled location relied upon to represent the official record or approved value. It may be:

• the system where the record originates;
• a receiving system after a validated transfer;
• an approved repository;
• a retained native electronic record;
• or a defined combination of systems.

For each critical data element, the assessment should determine:

• where it is created;
• where it may be changed;
• where it is reviewed and approved;
• where its audit trail resides;
• where it is retained;
• which system controls its status;
• which system supplies it to downstream processes; and
• which copy is relied upon during investigation or inspection.

A final report is not necessarily the complete authoritative record. Raw data, metadata, processing methods, audit trails, electronic signatures, and review history may remain in the originating system.

Competing authoritative sources should be avoided. If the same field can be modified independently in several systems, ownership, synchronization, reconciliation, and conflict-resolution rules should be defined.

Direct and Indirect GxP Impact

Direct and indirect impact describe how a system can affect regulated operations. These terms should support analysis rather than serve as labels that automatically determine a validation package.

Direct Impact

A system may have direct impact when it:

• controls a critical manufacturing or utility parameter;
• performs a critical calculation;
• determines acceptance or rejection;
• manages specifications or approved methods;
• controls product or material status;
• creates a record used directly for release;
• generates a regulated label;
• controls an automated inspection or rejection function; or
• performs another function whose failure can directly affect product quality, patient safety, or a regulated decision.

Indirect Impact

A system may have indirect impact when it supports a directly impactful system or regulated process through:

• infrastructure;
• data transfer;
• identity management;
• time synchronization;
• backup and recovery;
• monitoring;
• maintenance scheduling;
• calibration scheduling;
• reporting;
• or another supporting service.

Indirect impact does not mean insignificant impact. Failure of a network, database, authentication service, or interface can compromise critical operations or records even when the component does not make the final product decision.

The assessment should identify the failure effect and existing controls instead of assuming that all indirectly impactful systems require minimal assurance.

Product-Quality and Patient Impact

Classification should evaluate credible system failures and their possible effects.

Relevant questions include:

• Could failure cause an incorrect formulation, process step, or parameter?
• Could failure prevent detection of an adverse process condition?
• Could incorrect information lead to acceptance of nonconforming material or product?
• Could the system generate an incorrect label or identification?
• Could failure compromise sterility, identity, strength, quality, or purity?
• Could a calculation error affect a specification or release decision?
• Could system unavailability prevent a required control from being performed?
• Could unauthorized activity change a regulated record or configuration?
• Could an interface associate information with the wrong material, batch, sample, or product?
• Could failure conceal a discrepancy or prevent investigation?

The assessment should consider both the severity of the effect and the likelihood that other independent controls would prevent or detect it before a regulated decision is made.

Classification should not be based solely on the department using the system. A Quality department application is not automatically high impact, and an infrastructure component is not automatically low impact.

Data Criticality

Data criticality addresses the significance of the records created, processed, stored, or transferred by the system.

Critical data may include information used to:

• establish product quality;
• demonstrate process control;
• determine material or product status;
• support batch release;
• establish compliance with specifications;
• document deviations or investigations;
• establish traceability;
• demonstrate calibration or maintenance status;
• support stability conclusions;
• support regulatory submissions;
• or reconstruct a regulated activity.

The assessment should consider whether the system:

• creates original data;
• retains required metadata;
• performs calculations or transformations;
• allows data changes;
• supports review or approval;
• assigns status;
• transfers data;
• generates reports;
• retains audit trails;
• archives records; or
• provides the only readable or retrievable copy.

A system that stores critical records without changing them can still require extensive controls for security, retention, backup, retrieval, and migration.

Data volume is not the same as data criticality. A system containing millions of low-impact transactions may be less significant than a small spreadsheet performing one critical release calculation.

Control and Failure Analysis

Classification should evaluate not only potential consequences but also the controls that prevent or detect failure.

Controls may include:

• independent verification;
• automated input validation;
• range and format checks;
• workflow approval;
• segregation of duties;
• audit trails;
• exception reports;
• reconciliation;
• alarms;
• equipment interlocks;
• review of source records;
• backup and restoration;
• interface monitoring;
• periodic access review;
• and procedural checks.

The assessment should determine whether these controls are:

• independent of the function being evaluated;
• capable of detecting the relevant failure;
• performed before the affected decision;
• documented;
• routinely executed;
• and themselves reliable.

A second display of the same incorrect calculated value is not an independent control. A manual review is not an effective mitigation unless the reviewer receives the information necessary to detect the error and the review is consistently documented.

Documented Classification and Rationale

The classification record should provide a clear, reproducible rationale.

At minimum, it should document:

• system identification;
• business process;
• intended use;
• system boundary;
• GxP applicability;
• applicable regulated records;
• Part 11 applicability;
• system type;
• direct or indirect impact;
• product and patient impact;
• data criticality;
• principal failure scenarios;
• existing independent controls;
• software category;
• supplier involvement;
• classification conclusion;
• validation consequences;
• lifecycle controls;
• approvers;
• and reassessment triggers.

The rationale is more important than the category label. Terms such as critical, major, supporting, direct, indirect, high, medium, or low should be defined in the governing procedure and applied consistently.

Classification should not be reduced to a numerical score without explanation. A total score can conceal a severe failure scenario or imply precision that the assessment does not support.

System-Impact Classification Versus GAMP Software Category

System-impact classification and GAMP software categorization answer different questions.

System-Impact Classification

System-impact classification asks:

• What regulated process does the system support?
• What product, patient, or data consequences could result from failure?
• Which records and decisions depend on the system?
• What controls prevent or detect failure?
• How significant is the system’s intended GxP use?

GAMP Software Category

GAMP software categorization asks:

• What type of software component is being used?
• Is it infrastructure, a nonconfigured product, a configured product, or a custom application?
• How much behavior is determined by configuration?
• Is custom code present?
• How complex is the component?
• What supplier evidence may be available?
• What specifications and technical verification are appropriate?

A configurable commercial application can support a critical process. A custom application can support a limited-risk administrative function. Software category therefore does not establish GxP impact.

Both assessments inform the validation strategy:

• system impact identifies what matters and why;
• software category helps determine how the system is developed, specified, configured, tested, and maintained;
• supplier capability determines what evidence may be leveraged;
• intended use defines the functions that require assurance;
• risk assessment identifies the required control and verification depth.

The principles are explored further in GAMP 5 Principles for Computerized System Validation and GAMP 5 Software Categories and Validation Strategy.

Validation Consequences

Classification should influence validation planning, but it should not mechanically assign a standard set of protocols. The assessment should help determine:

• validation-plan depth;
• requirements detail;
• specification needs;
• supplier-assessment depth;
• acceptable use of supplier evidence;
• configuration documentation;
• risk-assessment depth;
• test objectives;
• scripted versus unscripted testing;
• positive, negative, and boundary testing;
• interface testing;
• security and data-integrity testing;
• migration verification;
• traceability;
• release evidence;
• change-control rigor;
• periodic-review scope;
• and retirement controls.

A simple application with one critical calculation may require focused but rigorous calculation verification. A complex platform with many unused features may require detailed boundary and configuration control but testing focused on the functions actually used.

Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) may be used where they fit the organization’s lifecycle model. They should not be prescribed automatically from a classification label.

The underlying objectives are to verify:

• the system and operating environment are correctly established;
• configured functions and controls operate as intended;
• representative business processes perform reliably;
• required records remain complete and protected;
• interfaces function correctly;
• users and support processes are ready; and
• the system is suitable for authorized release.

The validation approach should be documented in the Computerized System Validation Planning and Strategy article’s deliverables rather than inferred from a classification score alone.

Ownership and Responsibilities

Classification should be performed through coordinated business, technical, validation, and quality input.

Process Owner

The process owner should:

• define the business process;
• approve intended use;
• identify regulated decisions;
• define process requirements;
• identify failure consequences;
• ensure procedures and users are ready; and
• accept the system for operational use.

System Owner

The system owner should:

• maintain the system inventory;
• coordinate classification;
• define the system boundary;
• maintain system documentation;
• control access and configuration;
• coordinate validation and changes;
• monitor support and performance;
• support periodic review; and
• manage retirement.

Technical Owner or Information Technology

Technical personnel should:

• define infrastructure and architecture;
• identify technical dependencies;
• manage environments;
• control technical access;
• support security;
• manage backup and recovery;
• assess infrastructure changes;
• monitor capacity and availability; and
• maintain technical records.

Quality Unit

The Quality unit should provide appropriate oversight of:

• GxP applicability;
• classification methodology;
• regulated requirements;
• validation strategy;
• risk acceptance;
• deviations;
• release;
• significant changes;
• periodic review;
• and retirement.

Supplier

The supplier may provide:

• product information;
• architecture;
• development and testing evidence;
• configuration guidance;
• security information;
• release documentation;
• known defects;
• backup and recovery information;
• and lifecycle support.

Supplier evidence should be evaluated before use and should not replace verification of the site-specific intended use, configuration, interfaces, data, controls, and operating procedures. This relationship is addressed further in Computerized System Supplier Assessment and Evidence Leverage.

Classification Review and Change Control

Classification is not a one-time document.

It should be reviewed when changes affect:

• intended use;
• business process;
• regulated records;
• system boundaries;
• application modules;
• software category;
• configuration;
• custom code;
• interfaces;
• calculations;
• reports;
• infrastructure;
• hosting model;
• supplier responsibilities;
• data retention;
• security;
• or system ownership.

A system originally used for a non-GxP purpose may become GxP-relevant when a regulated department begins relying on its data. A supporting system may gain direct impact when it begins performing an acceptance calculation or assigning product status.

Periodic review should confirm that:

• the inventory remains accurate;
• intended use remains current;
• the boundary remains complete;
• GxP and Part 11 assessments remain valid;
• interfaces are documented;
• critical records remain controlled;
• supplier and software status remain acceptable;
• and the validation strategy remains proportionate.

Practical Classification Outcome

A useful classification process produces more than a label.

Its outputs should establish:

• why the system is or is not GxP-relevant;
• which functions and records are regulated;
• where the system boundary lies;
• which components and interfaces require control;
• which system is authoritative for critical data;
• what failures matter;
• which controls manage those failures;
• what supplier evidence may be used;
• what validation evidence is required;
• how changes will be assessed;
• and how the system will be reviewed and retired.

The central classification question is not whether the software appears complex or belongs to a particular product family. It is whether the complete computerized system, as configured and used, can affect product quality, patient safety, regulated records, or GxP decisions—and what evidence is needed to establish and maintain confidence in that intended use.