Article
Card image cap for article

Computerized System Validation, Medical Device Industry, GAMP, ISO/TR 80002-2, Lean Approaches

Medical Devices

4/4/2026

Executive Summary

Computerized System Validation (CSV) is the documented process of providing evidence that a software system consistently performs its intended function in conformance with predetermined specifications and quality standards.

In the medical device industry, CSV applies specifically to software used within Quality Management Systems (QMS), production, and monitoring and measurement activities - not to the device software itself.

With ISO 13485:2016 [1], CSV has become a regulatory necessity embedded in clauses 4.1.6, 7.5.6, and 7.6. Two major frameworks guide its practical implementation: GAMP 5 [2], borrowed and adapted from the pharmaceutical industry, and ISO/TR 80002-2:2017 [3], the purpose-built medical device technical report.

There are also leaner, risk-proportionate approaches - including the FDA's finalized Computer Software Assurance (CSA) guidance [4] - that reduce documentation overhead without compromising compliance integrity.

Why CSV Matters for Medical Device Companies

Medical device manufacturers rely on a growing ecosystem of digital tools: electronic QMS Documentation Management Systems (DMS), requirements engineering and risk management systems, Enterprise Resource Planning (ERP) systems, electronic batch records, complaint handling software, training platforms and calibration management tools.

If any of these systems malfunctions or produces erroneous data, it can directly or indirectly affect the quality and safety of the device reaching the patient. A misconfigured non-conformance workflow in an eQMS, for example, could cause staff to follow draft procedures rather than approved ones, potentially compromising manufacturing controls.

ISO 13485:2016 addresses this risk directly. Clause 4.1.6 requires documented procedures for validating software applications used in the QMS, validated before initial use and re-validated after changes, with the approach proportionate to the associated risk.

Clauses 7.5.6 and 7.6 extend these requirements to software used in production processes and monitoring or measurement activities. The FDA's Quality System Regulation (21 CFR Part 820) imposed comparable requirements in the United States before the QMSR was adopted early this year, making CSV a cross-jurisdictional obligation.

CSV Not Applicable for the Medical Device Itself

CSV is explicitly scoped to non-product software. It includes software supporting the QMS and manufacturing environment. It does not apply to software embedded in a device or software that is itself a medical device (SiMD or SaMD), which falls under IEC 62304 (medical device software lifecycle processes) and related standards.

The History and Evolution of GAMP

Good Automated Manufacturing Practice (GAMP) was founded in 1991 in the United Kingdom in direct response to evolving U.S. FDA expectations for GMP compliance of automated manufacturing systems. Its evolution reflects the maturing of both technology and regulatory science:

  • GAMP 1 (1994/1995): The first guideline, a supplier guide focused on basic documentation and lifecycle controls.
  • GAMP 2 (1996): Expanded supplier guidance, refining the original framework.
  • GAMP 3 (1998): Introduced formal risk analysis into the validation process.
  • GAMP 4 (2001): Moved toward risk assessment, establishing the famous five-category software classification and incorporating the V-model lifecycle. The FDA participated in its review, making it the de facto CSV standard of its era. It defined five software categories including Category 2 for firmware.
  • GAMP 5 (2008): Elevated the approach to risk management, replacing the rigid single-lifecycle model with category-dependent models, and removed Category 2 (firmware). It introduced science-based quality risk management aligned with ICH Q9.
  • GAMP 5, 2nd Edition (July 2022): A comprehensive update addressing cloud computing, agile/iterative development, AI/ML, blockchain, open-source software, and a new "Critical Thinking" appendix (M12). The 2nd Edition explicitly shifted the tone from compliance-checkbox thinking toward fitness for intended use.

GAMP is published by the International Society for Pharmaceutical Engineering (ISPE) and, while originating in pharma, has been widely adopted as the practical implementation framework for CSV across medical devices, biotechnology, and clinical research.

The GAMP Software Categories

GAMP 5 classifies software into four active categories:

Category Description Examples Key Validation Activities
1 Infrastructure Software: OS, databases, middleware, network services; forms the IT environment but does not directly process GxP data Windows Server, Oracle DB, antivirus software, network monitoring tools Document name, version, installation location; leverage vendor qualification; IQ only; minimal testing
2 (Removed in GAMP 5 - was Firmware in GAMP 4) - -
3 Non-configured (COTS) Software: off-the-shelf products used as-is, without configuration Word processors, PDF viewers, standard spreadsheets, simple standalone tools IQ, basic OQ; leverage vendor testing; verify key outputs; limited bespoke testing
4 Configured Software: commercial systems configured to meet user-specific needs LIMS, ERP, eQMS, TrackWise, MES Full IQ/OQ/PQ; documented configuration testing; risk assessment; traceability matrix URS to test
5 Custom (Bespoke) Software: developed from scratch for a specific purpose Custom-coded MES, proprietary data analysis tools, bespoke validation management tools Full lifecycle: URS, FRS, DS, IQ/OQ/PQ, code reviews, integration tests, complete traceability

The significance of this tiered classification is that validation rigor scales with complexity and configurability, not with system size. A Category 1 OS requires little more than documented installation verification, while a Category 5 custom application demands exhaustive lifecycle documentation, test protocols, and traceability from user requirements to performance test evidence.

This proportionality is the foundation of the GAMP risk-based approach, and it directly informs how resources are allocated during validation projects.

Avoid Confusion between GAMP Version and GAMP Category

A common point of confusion is that the current edition of the guideline is GAMP 5 and the highest software category it defines is also Category 5. They are coincidentally the same number, but the category system existed already in GAMP 4 (the previous version of the guideline), and the categories could in principle be renumbered without changing anything about the guideline version.

The GAMP Risk-Based Approach

GAMP 5's core principle is that validation effort should be commensurate with risk to patient safety, product quality, and data integrity. Rather than applying maximum effort to every system regardless of its impact, GAMP 5 requires organizations to first assess the GxP relevance of each system, then scale validation activities accordingly.

The risk-based approach proceeds through three dimensions:

  • GxP Impact Assessment: Does the system directly influence a GxP-regulated process? Could its failure lead to product defects, safety issues, or data integrity failures? Systems with no GxP impact may need only basic documentation.
  • Business Process Risk: What critical business processes does the system support? Which failures would propagate to patient risk?
  • Functional Risk Assessment: Within a validated system, which specific functions are critical? Only critical functions require intensive testing; non-critical functions may be tested at a lower level or rely on vendor evidence.

GAMP 5 also institutionalizes the principle of leveraging supplier quality: "Where the system has been appropriately tested by the supplier, there is no value in the regulated organization repeating those tests." This reduces duplication and focuses organizational effort on configuration, intended use, and business-process workflows rather than re-testing commercially validated code.

ISO/TR 80002-2:2017 - The Medical Device Framework

ISO/TR 80002-2:2017, Medical Device Software - Part 2: Validation of Software for Medical Device Quality Systems, is a Technical Report published in June 2017. It provides medical device-specific guidance on validating non-product software, translating the abstract requirements of ISO 13485 clauses 4.1.6, 7.5.6, and 7.6 into actionable steps.

Scope

  • Software used in the QMS (document control, CAPA, audit management, change control)
  • Software used in production and service provision (ERP)
  • Software used for monitoring and measurement (calibration management)

It explicitly excludes software that is itself a medical device (SaMD) or embedded in a device; those are governed by IEC 62304.

Lifecycle Approach

  • Concept Phase - Define intended use, user requirements, and initial supplier assessment
  • Project Phase - Planning, specifications, development/configuration, verification (testing), reporting and release
  • Operation Phase - Change management, periodic reviews, incident management, configuration management
  • Retirement Phase - System decommissioning treated as a change, with data migration and archiving considerations

The Technical Report deliberately avoids mandating any specific lifecycle model, stating that many models can be applied. It requires a controlled methodology but leaves the practitioner free to apply V-model, agile, spiral, or other approaches, provided the required deliverables and activities are addressed.

How GAMP 5 and ISO/TR 80002-2 Align and Differ

The relationship between GAMP 5 and ISO/TR 80002-2 is largely one of complementarity rather than conflict. Both share the risk-based approach as a foundational philosophy, and both define a software lifecycle spanning concept through retirement.

Dimension GAMP 5 ISO/TR 80002-2:2017
Origin ISPE, pharmaceutical industry ISO/TC 210, medical device industry
Nature Practical implementation guide (~400 pages) Technical Report (~84 pages) with principles and rules
Lifecycle model Defines specific lifecycle phases and deliverables, with category-dependent paths Describes lifecycle phases but does not advocate any specific model
Risk management Science-based QRM per ICH Q9; incorporated in all lifecycle phases (Chapter 5, Appendix M3) Risk-based approach required; references ISO 14971
Software categorization Explicit 4-category classification system driving validation depth No formal categorization; relies on risk assessment to scale effort
Incident management Explicitly defined within GAMP Not directly in ISO 80002-2; references ISO 13485
Data migration/retirement Explicit guidance on archiving, migration, and retrieval Lists issues to consider; treated as a change
Traceability Traceability matrix required: URS to requirements to verification Required; links business needs to requirements and verification
Regulatory alignment FDA 21 CFR Part 11, EU Annex 11, ICH Q9 ISO 13485:2016, ISO 14971, IEC 62304 (referenced)
Practicality Very detailed, operationally prescriptive More concise but requires interpretation

The key conclusion from comparative analysis is: a system properly set up according to GAMP 5 will be compliant with ISO/TR 80002-2:2017. GAMP 5 covers all required topics of ISO 80002-2 and adds additional guidance on areas such as incident management, data migration, and vendor qualification that ISO 80002-2 handles by reference to other standards.

The converse is also defensible: ISO 80002-2 alone is shorter and principles-based, but offering less operational guidance, which can leave practitioners uncertain about practical implementation.

For medical device companies already familiar with ISO standards, ISO/TR 80002-2 provides the regulatory anchor, while GAMP 5 serves as the practical "how-to" handbook. Neither is mandatory in a strict legal sense; what ISO 13485:2016 mandates is that validation be performed and proportionate to risk. The choice of which framework to follow is the manufacturer's.

Typical Process Steps

Qualification

Before a system can be validated, the equipment and infrastructure on which it runs must first be qualified. Qualification and validation are related but distinct activities, and the distinction matters both technically and regulatorily.

Qualification vs. Validation: The Core Distinction

Qualification focuses on the equipment, environment, and infrastructure: it demonstrates that physical and technical components are correctly installed and function within their specified parameters.

Validation, by contrast, focuses on the process or software system as a whole: it demonstrates that the system consistently delivers the intended result in the context of real business use.

A practical analogy: you qualify the oven before you validate the baking process. Qualification answers "Is this tool fit to be used?" Validation answers "Does the complete process, using this qualified tool, reliably produce the right outcome?"

  • IQ (Installation Qualification) confirms the system was delivered and installed correctly - the right software version, on the right hardware, in the right environment.
  • OQ (Operational Qualification) confirms the system operates as designed under controlled conditions, including boundary and negative test cases.
  • PQ (Performance Qualification) confirms the system performs reliably in actual business use, with real users executing representative workflows.

Skipping or weakening any one phase creates a gap in the compliance chain that an auditor or notified body will identify. ISO 13485:2016 clause 4.1.6 requires that software used in the QMS be validated before initial use and re-validated after changes. The IQ/OQ/PQ structure is the accepted operationalisation of that requirement for infrastructure-dependent computerized systems.

The Terms Come from Equipment, Not Software

IQ, OQ, and PQ were originally developed in the pharmaceutical and manufacturing industries for validating physical equipment - autoclaves, filling lines, tablet presses - long before anyone thought about computerized systems.

  • You "qualify" the equipment (IQ, OQ) to confirm it is properly built and operates correctly in isolation.
  • You "validate" the process that uses that equipment (PQ) to confirm it consistently produces a product meeting specifications.

So in classical manufacturing validation, IQ and OQ really were qualification steps, and only PQ was truly "validation" in the process sense.

How It Was Borrowed into CSV

When the pharmaceutical industry adapted this framework for software and computerized systems in the 1990s, they carried the entire IQ/OQ/PQ terminology across, even though the conceptual split between "qualifying hardware" and "validating the process" blurs considerably in software.

The result is the apparent paradox: all three phases are collectively called "the validation" (the overall project is a CSV project, and the output is a Validation Summary Report), but the individual phases are named after qualification.

Supplier Qualification

Supplier or vendor qualification is a mandatory element of the medical device quality system. ISO 13485:2016 clause 7.4.1 requires manufacturers to establish documented procedures for the evaluation, selection, performance monitoring, and re-evaluation of suppliers, with the depth of assessment proportional to the criticality of the supplied product or service and its potential impact on device quality and patient safety.

Why Supplier Qualification Is Critical for CSV

When a medical device company purchases or licenses a computerized system - an eQMS, ERP, or calibration management tool - the software vendor becomes a critical supplier. A failure of that vendor (undisclosed architecture change, inadequate support, incorrect software release) can directly undermine the validated state of the system.

Supplier qualification extends the organization's quality system boundary to encompass those third parties.

Supplier Qualification Process Steps

  • Supplier evaluation and selection: assess the supplier's QMS, regulatory compliance history, software development practices, financial stability, and ability to provide validation support documentation.
  • Approved Supplier List (ASL): Qualified suppliers are recorded on the ASL, a controlled QMS document subject to periodic review.
  • Quality Agreement: A written agreement with the supplier defines responsibilities for change notification, validation documentation, incident handling, and audit rights.
  • Supplier audit: Depending on criticality, a remote or on-site audit may be required.
  • Ongoing monitoring and re-evaluation: Track supplier performance through defect rates, change notification timeliness, and support quality.

Leveraging Supplier Evidence in CSV

GAMP 5 encourages organizations to leverage supplier-provided documentation to reduce redundant testing. A well-qualified supplier can provide IQ protocols, OQ scripts, and test evidence that the regulated company reviews and accepts, reducing internal effort.

Critical note: the regulated organization remains responsible for the validated state of the system regardless of what the supplier has provided. Supplier evidence supplements but does not replace the organization's own PQ and user requirements verification.

Validation Master Planning

A Validation Master Plan (VMP) is the top-level governing document that describes an organization's overall approach to computerized system validation. Where a Validation Plan (VP) covers a single system, the VMP covers the entire validated environment: all systems in scope, the validation policy and methodology, the risk framework, lifecycle models, documentation structure, and roles and responsibilities.

The VMP is particularly important for medical device companies managing multiple validated systems simultaneously. It ensures consistency of approach across all validation projects, facilitates regulatory inspections, and provides the organizational baseline against which individual Validation Plans are written.

Key elements of a VMP include: scope and objectives; applicable regulations and guidelines; system inventory and GAMP category assignments; risk classification methodology; lifecycle models per category; standard documentation set per category; deviation and change control approach; roles and responsibilities; and periodic review schedule.

User Requirements Specification (URS)

The business process is the starting point. The URS should also include the intended use of the computerized system.

Functional and Non-Functional Requirements

The URS should capture two classes of requirements. Functional requirements describe what the system must do: process steps, data flows, calculations, reporting outputs, and integration behaviour.

Non-functional requirements describe how well it must do it: performance under load, availability, response time, security controls, audit trail completeness, and backup frequency.

Acceptance criteria for each requirement must be defined in the URS itself, not deferred to the test phase. A requirement without a measurable acceptance criterion cannot be objectively tested.

Traceability

Traceability is built from the URS outward: every URS requirement must map to at least one test case in OQ or PQ. This bi-directional traceability is verified in the Traceability Matrix and is the primary evidence reviewed during audits.

Validation Planning

A Validation Plan (VP) is the cornerstone document that governs every CSV project. It must be written before validation activities begin and serves as the project charter for the validation effort.

According to both GAMP 5 and ISO/TR 80002-2, the VP should include:

  • Scope
  • Objectives
  • Regulatory and standards basis
  • System description and GAMP category
  • Acceptance criteria
  • Risk assessment approach
  • Roles and responsibilities
  • Deliverables and timeline
  • Change control and revalidation triggers

The VP is not a one-time document; it should be reviewed and updated as the project progresses and as the system scope evolves. In agile environments, the GAMP 5 2nd Edition now accommodates dynamic planning, where requirements and test cases are managed iteratively in appropriate tools rather than rigid document sets.

Impact Assessment

Before writing a VP, practitioners must perform an impact assessment for each software tool in use. This assessment answers the fundamental question: "Does this software have an impact on product quality, patient safety, or data integrity?"

  • Inventory all software tools used by the organization.
  • Describe the intended purpose of each tool.
  • Assess whether a failure of the tool could contribute to patient harm, device defects, or regulatory non-compliance.
  • Document the decision to validate (or not validate) with a rationale.
  • Assign a GAMP category as the basis for validation depth.

A well-maintained software inventory with documented impact rationales is the foundation of a defensible CSV program.

IQ, OQ, and PQ: The Qualification Phases

The three-phase qualification model - Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) - was adopted into CSV from traditional process and equipment validation frameworks in the 1990s. Although the GAMP 5 2nd Edition and the FDA's CSA guidance have moved toward a more flexible, risk-based verification paradigm, IQ/OQ/PQ remains widely used and well understood, particularly for Category 3 and 4 systems.

Installation Qualification (IQ)

IQ provides documented evidence that the system has been installed correctly according to vendor specifications and the organization's IT standards.

  • Verification of software version, license, and configuration settings
  • Confirmation of server/hardware specifications and environmental conditions
  • Documentation of security settings, user access controls, and network configuration
  • Confirmation that all required components are installed and operational

IQ answers the question: "Is the system installed as specified?"

Operational Qualification (OQ)

OQ verifies that the system performs its intended functions correctly under controlled conditions, within defined operating parameters.

  • Testing of audit trail generation and integrity
  • Verification of user access controls and permission hierarchies
  • Testing of alarm and alert notifications
  • Negative testing: confirming correct behaviour with invalid inputs or boundary conditions

OQ answers the question: "Does the system operate as designed?"

Performance Qualification (PQ)

PQ demonstrates that the system performs reliably in the actual business environment, simulating real-world workflows.

  • Executing representative end-to-end business processes
  • Involving end users in executing and verifying test scenarios
  • Confirming system performance under realistic load and data conditions

PQ answers the question: "Does the system consistently perform as intended in the operational context?"

Testing Strategy: Scripted, Exploratory, and Behaviour-Based Testing

Traditional CSV testing relies on pre-scripted test cases, which provide strong traceability and regulatory defensibility, but they can only detect what was anticipated during test design.

The FDA's Computer Software Assurance (CSA) guidance and GAMP 5 2nd Edition both explicitly recognise unscripted and exploratory testing as legitimate and valuable.

  • Exploratory testing: The tester is given a charter but no step-by-step script and actively probes the system for edge cases and unexpected behaviour.
  • Behaviour-based testing: Test cases are derived from observation of how actual users interact with the system in practice, including shortcuts and workarounds.

This is a systemic limitation of purely scripted CSV: it validates the system as designed, not necessarily the system as used.

Validation Summary Report (VSR)

The final deliverable is a Validation Summary Report (VSR), which consolidates all evidence, documents deviations and their dispositions, and issues a formal statement of fitness for use.

Handling Deviations During Validation

Deviations are departures from approved procedures, specifications, or test acceptance criteria that occur during validation execution.

  • Document the deviation immediately.
  • Classify by severity.
  • Investigate root cause.
  • Perform impact assessment.
  • Define Corrective and Preventive Actions (CAPA).
  • Re-execute affected tests.
  • Document in the Validation Summary Report.

A system with unresolved critical deviations must not be released for GxP use.

Lean and Simplified CSV in the Medical Device Industry

The medical device industry has increasingly recognized that full-blown GAMP 5 implementations carry a documentation overhead disproportionate to the risk profile of many systems.

FDA Computer Software Assurance (CSA)

In September 2022, the FDA released a draft guidance on Computer Software Assurance (CSA) for Production and Quality System Software, finalized in September 2025. CSA promotes a risk-based, least-burdensome approach focused on critical thinking rather than documentation volume.

  • Organizations rank software features by process risk.
  • High-risk features receive intensive testing; low-risk features may rely on vendor evidence and brief checks.
  • Unscripted, exploratory testing is explicitly recognized as legitimate.
  • The measure of compliance is evidence-based confidence that the system is fit for intended use.

Lean Principles Applied to CSV Lifecycles

  • Over-validation
  • Excessive documentation
  • Waiting
  • Re-work
  • Over-processing
  • Defects
  • Unused talent

Practical Efficiency: Parallel Execution of OQ and PQ

Overlapping OQ and PQ activities can substantially reduce validation timelines without compromising compliance, provided dependencies and deviations are managed properly.

Combining OQ and PQ into a Single Protocol

Many organizations validate each phase with individual plans, protocols, and reports. An alternative lean approach is to combine them into one integrated qualification protocol.

The benefits are tangible:

  • Reduced documentation overhead
  • Simpler intermediate specifications
  • Fewer samples and lower cost

The challenges should be acknowledged:

  • Technical complexity
  • Slightly higher risk of protocol failure

Examples of Poor Validation Testing and Common Failures

  • Testing the system manual, not the system
  • No negative testing
  • Acceptance criteria defined after test execution
  • Missing traceability
  • Validating non-critical functions at the expense of critical ones
  • Change without revalidation
  • Inadequate deviation management

Practical Implementation Guidance

For medical device companies building or maturing a CSV program, the following sequence reflects both GAMP 5 and ISO/TR 80002-2 best practices:

  • Establish a Software Validation SOP.
  • Build and maintain a software inventory.
  • Classify each system by GAMP category.
  • Write a Validation Plan for each in-scope system.
  • Execute IQ, OQ, PQ (or equivalent verification activities under CSA).
  • Document and resolve all deviations.
  • Maintain the validated state.

References

Go back