Classification and Validation of Computerized Systems Used in GMP

Computerized systems used in Good Manufacturing Practice (GMP) environments can be broadly classified into four major categories. Understanding these categories is critical because the validation approach differs significantly for each type. However, in practice, there are very few experts who are thoroughly familiar with all four categories.

Four Categories of GMP Computerized Systems

The four categories of computerized systems used in GMP are:

1. Process Control (Production Equipment)
2. Laboratory Systems
3. IT Applications
4. Infrastructure

Each of these system types requires different validation methodologies and approaches. The validation strategy must be carefully tailored to the specific characteristics and risks associated with each category.

Validation of Production Equipment

Production equipment includes reaction vessels and fermentation tanks in active pharmaceutical ingredient (API) facilities, as well as granulation machines, tablet presses, freeze dryers, weighing equipment, autoclaves, coating machines, and blister packaging machines in formulation facilities.

Characteristics of Production Equipment

A distinctive characteristic of production equipment is that its quality can be intuitively assessed. Validation can be achieved by conducting process validation and verifying the quality of products actually manufactured. The functionality of production equipment can be directly confirmed through the quality of the output products it produces.

GAMP Software Categories and Production Equipment

According to the GAMP 5 framework (now in its Second Edition as of 2022), most production equipment falls into what was historically called Category 3 systems. However, it is important to note that the GAMP 5 Second Edition emphasizes that categories should be viewed as a continuum rather than rigid classifications. The Second Edition states that “computerized systems are generally made up of a combination of components from different categories; the categories should be viewed as a continuum.”

Production equipment typically features limited intended use with programs provided by hardware vendors as fixed general-purpose functionality, where functions are realized by setting parameters. Many production equipment systems are controlled by relatively small programs such as Programmable Logic Controllers (PLCs) and firmware.

Historical Note on GAMP Categories

It should be noted that Category 2 (firmware) was removed when GAMP transitioned from Version 4 to Version 5. Currently, only Categories 1, 3, 4, and 5 exist in the GAMP 5 framework. The numbering was retained to maintain consistency with existing documentation, but Category 2 is no longer in use as firmware has evolved and is now typically classified as Category 3, 4, or 5 depending on its characteristics.

Qualification Approach

In most cases, suppliers are responsible for conducting Installation Qualification (IQ) and Operational Qualification (OQ), commonly combined as IOQ. However, complex or user-modified PLCs may be classified as Category 5, though the boundary between Categories 3 and 5 can be ambiguous and should be determined through critical thinking based on risk assessment.

In recent years, production equipment is increasingly managed centrally through IT applications such as Supervisory Control and Data Acquisition (SCADA) systems or Distributed Control Systems (DCS).

Equipment Qualification vs. Software Validation

Production equipment generally undergoes qualification activities including Design Qualification (DQ), Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ). This is because production equipment represents “GMP hardware” where the physical equipment and its intended function are the primary focus.

Functional Specifications and Production Equipment

Typically, a single piece of production equipment has only one function. For example, a granulation machine performs granulation, and a tablet press performs tablet compression. In other words, one system equals one function equals one process. Therefore, functional specification documents are generally not created (or cannot be created) for such equipment, as the function is inherently defined by the equipment’s design.

This is reflected in the Japanese Ministry of Health, Labour and Welfare’s Computer System Proper Management Guidelines, which do not provide detailed descriptions regarding functional specifications. Through my experience working with many suppliers, I have found that most vendors do not know how to write functional specification documents for production equipment.

Functional specification documents are generally created for systems with relatively complex functions, such as IT applications, where multiple interrelated functions must be clearly defined and validated.

Validation of Quality Control Laboratory Systems

The Reality of Laboratory Equipment Validation

Consider this question: When you purchase a personal computer, do you perform validation? Most likely, you trust the manufacturer’s quality assurance and do not conduct validation activities. The same principle applies to analytical instruments.

In most cases, analytical instruments are commercial off-the-shelf (COTS) products (historically Category 3, though the GAMP 5 Second Edition emphasizes a continuum approach). For such equipment, extensive Computer System Validation (CSV) activities such as detailed IQ and OQ are generally not necessary, particularly when the software category is considered within a risk-based framework.

Data Integrity in Laboratory Systems

However, quality test records have a significant impact on release decisions, and assurance of reliability regarding electronic records and electronic signatures (ER/ES) is critical. Since most analytical instruments still lack password protection capabilities, physical security measures such as laboratory access control and entry/exit management become crucial.

Modern Approach: Computer Software Assurance

The regulatory landscape has evolved significantly since the Japanese guidelines were issued. In 2022, the U.S. FDA released draft guidance on Computer Software Assurance (CSA) for Production and Quality System Software, which was finalized in September 2025. This guidance represents a fundamental shift from traditional CSV to a more risk-based CSA approach. The CSA framework emphasizes critical thinking, leveraging supplier documentation, and focusing validation efforts based on the actual risk to patient safety, product quality, and data integrity.

Adapting Traditional Guidelines to Laboratory Equipment

The Japanese Ministry of Health, Labour and Welfare’s Computer System Proper Management Guidelines were written with a primary focus on production equipment. When applied to QC laboratories (analytical instruments, spreadsheet software, etc.), the following adaptations are necessary:

Periodic Inspections and Self-Inspections: These can be substituted with “calibration” activities. Calibration serves as the primary means of ensuring instrument accuracy and reliability.

IQ and OQ for Analytical Instruments: Detailed IQ and OQ protocols as traditionally understood for production equipment are generally not performed for analytical instruments. Instead:

• IQ: Confirms installation and records version numbers, serial numbers, and other identifying information
• PQ: For simple systems, calibration can substitute for PQ

Risks Associated with Spreadsheet Software

A commonly observed practice is the use of spreadsheet software such as MS-Excel to create test reports and other critical documentation. While MS-Excel is inexpensive and readily available, if it is used to create test results, test reports, and release decision documents, it handles high-risk data and requires appropriate validation.

Organizations must establish and document validation procedures for MS-Excel and similar spreadsheet applications. However, if MS-Excel is used only as a word processor (i.e., for typing input only, without using formulas or performing calculations), validation is not necessary. The key determining factor is whether the software is being used to perform GxP-critical calculations or data transformations.

Considerations for Spreadsheet Validation

When spreadsheet software is used for GxP-critical activities:

• The intended use must be clearly defined
• Risk assessment should determine the level of validation required
• Formula validation and testing should be conducted
• Access controls and change management procedures should be implemented
• Version control should be maintained
• Training should be provided to users

Validation of IT Applications

Characteristics of IT Applications

IT applications include systems such as Enterprise Resource Planning (ERP), Manufacturing Execution Systems (MES), Laboratory Information Management Systems (LIMS), and Electronic Document Management Systems (EDMS). These are software applications that create and manage electronic records (data) rather than manufacturing physical products.

The Challenge of Validating Electronic Records

How can we ensure the reliability of electronic records? Ensuring the reliability of electronic records (validation) is significantly more difficult than ensuring the quality of production equipment. While production equipment can be validated by examining the physical products it creates, IT applications require a different approach.

Modern Context: Computer Software Assurance

The FDA’s CSA guidance (finalized in September 2025) represents the evolution of thinking about software validation. CSA is described as “a risk-based approach to establish confidence in the automation used for production or quality systems” and focuses on four key steps: identifying intended use, determining a risk-based approach, determining appropriate assurance activities, and establishing appropriate records.

Testing Strategy for IT Applications

IT application validation relies heavily on repeated testing, including unit testing, integration testing, system testing, and user acceptance testing (UAT). Testing is conducted using a hypothesis-validation approach (black-box testing) by preparing sufficient test data and comparing actual results with expected results.

This testing process is extremely time-consuming, difficult, and inherently incomplete. Therefore, early planning is essential to ensure efficient and effective validation. Proper risk assessment should guide the extent and depth of testing required.

The Limitations of Software Testing

Software testing has inherent limitations. Except for very simple programs, software cannot be exhaustively tested. It is impossible to test software with every possible input data, and it is equally impossible to test every conditional branch during program execution. There is no methodology that can exhaustively test any given software.

Testing all functions does not mean that all program code has been tested. Furthermore, a test that finds no errors should not be interpreted as proof that no errors exist in the software, as the testing may have been superficial. No matter how extensive the testing, bugs will inevitably remain in IT applications—this is a fundamental characteristic of complex software systems.

Modern Approaches: Leveraging Supplier Documentation

The GAMP 5 Second Edition and FDA CSA guidance both emphasize the importance of leveraging supplier testing, documentation, and quality management systems. Rather than duplicating all supplier testing, regulated companies should:

• Assess supplier quality systems and development practices
• Review supplier test documentation
• Focus internal testing on configuration, interfaces, and business process requirements
• Use risk-based approaches to determine the depth of additional testing needed

Common Misconception: IQ, OQ, PQ for Software

Some companies still conduct IQ, OQ, and PQ for IT applications (software), but this approach is fundamentally incorrect. Qualification activities (IQ, OQ, PQ) are intended for production equipment—that is, “GMP hardware.” Software validation requires a different approach focused on testing functionality, data integrity, and business process requirements.

The confusion arises because the Japanese Ministry of Health, Labour and Welfare’s guidelines were written primarily with production equipment in mind. However, international best practices clearly distinguish between equipment qualification and software validation. The GAMP 5 framework and FDA guidance provide clear direction that software should be validated through appropriate testing strategies rather than through equipment qualification protocols.

Critical Thinking in Software Validation

The GAMP 5 Second Edition strongly emphasizes the use of critical thinking by knowledgeable subject matter experts (SMEs) rather than following prescriptive, checklist-based approaches. Validation strategies should be based on:

• The intended use of the software
• The complexity of the system
• The novelty of the technology
• The risk to patient safety, product quality, and data integrity
• The business process criticality

Validation of Infrastructure

Types of Infrastructure Systems

Infrastructure systems include automated warehouses, purified water distribution systems, Heating, Ventilation, and Air Conditioning (HVAC) systems, and material handling systems. These systems provide the fundamental utilities and environmental conditions necessary for GMP operations.

Intuitive Validation Approach

Infrastructure validation can be conducted relatively intuitively and is comparatively easy to implement. Unlike IT applications where data integrity must be validated through complex testing, infrastructure systems can be validated by measuring and confirming their physical performance parameters.

For example:

• Water systems can be validated by testing water quality parameters
• HVAC systems can be validated by measuring temperature, humidity, pressure differentials, and air quality
• Automated warehouses can be validated by confirming storage and retrieval accuracy

Infrastructure typically undergoes qualification activities (DQ, IQ, OQ, PQ) similar to production equipment, as these systems have direct, measurable impacts on the manufacturing environment and product quality.

Modern Validation Approaches: Risk-Based and Scalable

Evolution of Regulatory Thinking

The regulatory landscape for computerized system validation has evolved significantly. The GAMP 5 Second Edition (2022) and FDA’s Computer Software Assurance guidance (finalized 2025) represent a paradigm shift toward:

1. Risk-based approaches: Validation effort should be commensurate with risk
2. Critical thinking: Use of expert judgment rather than prescriptive checklists
3. Leveraging supplier documentation: Avoiding duplication of supplier validation work
4. Modern development practices: Accommodation of Agile and iterative development
5. Emerging technologies: Guidance on cloud computing, AI/ML, and Software as a Service (SaaS)

The Importance of Understanding System Differences

Understanding the differences among the four categories of GMP systems is crucial because:

• CSV implementation methods differ significantly across categories
• Standard Operating Procedures (SOPs) for CSV must account for these differences
• Resource allocation and expertise requirements vary by system type
• Risk management strategies must be tailored to each system category
• Documentation requirements and approaches differ substantially

Integration with Quality Management Systems

Modern approaches emphasize that computerized system validation should be integrated into the overall Quality Management System (QMS) rather than being treated as a separate, parallel activity. All lifecycle stages of computerized systems should be defined within the QMS and aligned with:

• ICH Q9 (Quality Risk Management)
• ICH Q10 (Pharmaceutical Quality System)
• Data integrity principles (ALCOA+ principles)
• Relevant regulatory requirements (21 CFR Part 11, EU Annex 11, PIC/S guidelines)

Summary Table: System Categories and Validation Approaches

System Category	Examples	Primary Validation Method	Key Considerations	Typical Lifecycle Approach
Process Control (Production Equipment)	Tablet presses, granulators, reactors, autoclaves	Qualification (DQ, IQ, OQ, PQ)	Physical equipment; quality verified through product testing	Equipment-focused; supplier IOQ + user PQ
Laboratory Systems	Analytical instruments, balances, HPLC, spectrophotometers	Calibration + limited qualification	Calibration is primary control; ER/ES for data integrity	Vendor qualification + calibration programs
IT Applications	ERP, MES, LIMS, EDMS	Software validation through testing (not IQ/OQ/PQ)	Complex functionality; data integrity critical; leverage supplier documentation	Risk-based testing; CSA approach; functional testing
Infrastructure	HVAC systems, water systems, automated warehouses	Qualification (DQ, IQ, OQ, PQ)	Environmental parameters; measurable performance	System-focused qualification

Key Principles for Modern Computerized System Validation

1. Apply Critical Thinking

Rather than following rigid, prescriptive approaches, validation teams should:

• Understand the intended use of the system
• Assess actual risks to patient safety, product quality, and data integrity
• Scale validation efforts appropriately
• Leverage all available information, including supplier documentation

2. Embrace Risk-Based Approaches

The level of validation effort should be determined by:

• Potential impact on product quality
• Potential impact on patient safety
• Potential impact on data integrity
• System complexity and novelty
• Supplier quality and reliability

3. Avoid Common Pitfalls

• Do not apply equipment qualification approaches (IQ, OQ, PQ) to software
• Do not treat GAMP categories as rigid classifications
• Do not duplicate supplier validation work unnecessarily
• Do not create excessive documentation that does not add value
• Do not ignore the importance of data integrity controls

4. Leverage Modern Technologies and Practices

• Utilize automated testing tools where appropriate
• Adopt Agile and iterative development practices when suitable
• Implement continuous monitoring and detection capabilities
• Use digital records, audit trails, and automated traceability
• Consider cloud-based solutions with appropriate controls

5. Maintain Validated State

Validation is not a one-time activity but an ongoing process:

• Implement robust change control procedures
• Conduct periodic reviews
• Maintain system documentation
• Ensure continuing training
• Monitor system performance
• Plan for system retirement when appropriate

Conclusion

The validation of computerized systems in GMP environments requires a thorough understanding of the four major system categories and their unique characteristics. As technology and regulatory expectations evolve, organizations must adopt modern, risk-based approaches that leverage critical thinking and supplier expertise while maintaining focus on what truly matters: patient safety, product quality, and data integrity.

The transition from traditional Computer System Validation (CSV) to Computer Software Assurance (CSA) represents a significant evolution in regulatory thinking. Organizations should embrace these modern approaches while maintaining the fundamental principle that all systems must be fit for their intended use and maintain a validated state throughout their lifecycle.

By understanding the distinctions among production equipment, laboratory systems, IT applications, and infrastructure—and by applying appropriate validation methodologies to each—organizations can achieve effective and efficient compliance while supporting innovation and operational excellence in pharmaceutical manufacturing.