eQMS Validation: How to Complete IQ, OQ, and PQ for a Medical Device Quality System
What You Need to Know
> **Validation is a legal requirement, not a best practice.** 21 CFR 820.70(i) requires manufacturers to validate computer software used as part of production or the quality system for its intended use. If your eQMS manages quality records, documents, CAPAs, or training, it falls under this requirement.
> **IQ, OQ, and PQ are the three qualification phases.** Installation Qualification confirms the system is installed correctly. Operational Qualification confirms it functions as specified. Performance Qualification confirms it performs reliably under real-world conditions in your environment. Together they produce documented evidence that the system is fit for its intended use.
> **The FDA's approach to validation changed in 2025.** The FDA finalized its Computer Software Assurance (CSA) guidance on September 24, 2025. CSA does not eliminate IQ/OQ/PQ. It changes how the effort is scaled: assurance activities must be proportionate to the risk each software function poses to product quality and patient safety. Low-risk functions require less testing and less documentation than high-risk ones.
> **Vendor-supplied validation packages reduce your burden significantly.** A reputable eQMS vendor will supply an Installation Qualification protocol, Operational Qualification test scripts, a Validation Master Plan, and a traceability matrix linking test cases to user requirements. Your obligation is to execute the tests in your environment, document the results, and make the validation evidence your own.
> **Validation is not a one-time event.** It must be maintained throughout the system lifecycle. Software updates, configuration changes, and integrations with other systems all trigger re-validation of affected functionality. A validated system that has undergone undocumented changes is not in a validated state.
> **EU manufacturers face equivalent obligations.** The EU does not have a direct equivalent of 21 CFR Part 11 for medical device manufacturers, but the EU MDR QMS requirements under Annex IX and the ISO 13485 quality system framework both require that software used as part of the QMS be controlled and validated. The validation evidence requirements are consistent with IQ/OQ/PQ principles.
---
When a medical device manufacturer deploys an eQMS, the system becomes part of the regulated quality infrastructure. It stores controlled documents, generates audit trails, manages CAPAs, assigns training, and produces records that FDA inspectors and notified body auditors will examine. That status means the system itself must be validated: there must be documented evidence that it was installed correctly, operates as specified, and performs reliably under the conditions in which it is actually used.
Most quality teams understand that eQMS validation is required. Far fewer understand what it involves in practice, how much of the work their vendor should be doing, what the FDA's updated Computer Software Assurance guidance means for how that work is structured, and what ongoing responsibilities exist once the system goes live.
This article covers all of it: the regulatory basis, the IQ/OQ/PQ framework in detail, what the CSA guidance changes, how to work with vendor-supplied validation packages, what re-validation triggers look like, and what your validation documentation needs to contain to withstand an FDA inspection.
---
The Regulatory Basis for eQMS Validation
The primary regulatory requirement for validating quality system software in the U.S. is 21 CFR 820.70(i), which states that manufacturers shall validate computer software for its intended use according to an established protocol when it is used as part of production or the quality system. This provision appears in both the legacy QSR and the QMSR that replaced it on February 2, 2026.
The QMSR incorporates ISO 13485:2016 by reference, and ISO 13485 Clause 7.5.6 independently requires that software used in production and service provision be validated prior to initial use and, as appropriate, after changes. This parallel requirement means that regardless of whether a manufacturer is operating under the FDA framework, the EU MDR framework, or both, the obligation to validate quality system software exists.
21 CFR Part 11 adds a second layer of obligation for U.S. manufacturers using electronic records and signatures. The regulation requires that electronic record systems be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. The controls required under Part 11, including electronic signatures, audit trails, access controls, and record retention, must all be verified during validation. Validation under 820.70(i) and compliance with Part 11 are related but distinct obligations. Both must be addressed.
The FDA's 2003 guidance on the scope and application of Part 11 clarified that validation requirements apply to systems that are subject to predicate rules: the regulations that require records to be kept in the first place. For an eQMS managing quality records under 21 CFR Part 820, that condition is clearly satisfied. The validation must be commensurate with the risk and complexity of the system.
---
The Shift from CSV to CSA: What Changed in 2025
For many years, Computer System Validation (CSV) was the industry standard approach to validating quality system software. CSV applied a comprehensive, document-intensive methodology: extensive test scripts, large binders of evidence, and a tendency toward validating all system functionality regardless of its actual relevance to quality or patient safety.
The FDA recognized that this approach, while generating voluminous documentation, had a significant downside. It discouraged manufacturers from adopting newer, better software because the perceived validation burden made system changes costly and time-consuming. Companies were running outdated software versions rather than accepting the re-validation burden that upgrades would trigger.
On September 24, 2025, the FDA issued its final guidance titled "Computer Software Assurance for Production and Quality System Software." CSA is a risk-based approach for establishing and maintaining confidence that software is fit for its intended use. CSA does not replace Computer System Validation; it clarifies how validation activities may be executed more effectively.
The CSA framework operates as a four-step process: identify the intended use of the software, determine the risk of failure for each function, plan assurance activities proportionate to that risk, and establish an appropriate record of what was done and why. A key element of the CSA approach is that focus should be on what matters: patient safety, product quality, and data integrity.
In practical terms, this means that for an eQMS, the electronic signature function that approves a controlled document carries higher risk than a dashboard that displays CAPA trend data. The validation effort for the signature function should be more rigorous: more detailed test scripts, more specific pass/fail criteria, more thorough documentation. The dashboard may require less. Under CSA, approximately 80 percent of validation effort is directed toward meaningful, risk-based testing of the most critical system functions, and only 20 percent toward documentation. This is a significant reversal of the traditional CSV ratio.
IQ, OQ, and PQ remain valid and widely used qualification phases within a CSA-compatible framework. The difference is that the depth of each phase is now explicitly risk-calibrated rather than uniformly applied to all functionality.
---
The Three Qualification Phases in Detail
### Installation Qualification (IQ)
IQ establishes documented evidence that the eQMS has been delivered and installed in accordance with the vendor's specifications and the manufacturer's defined requirements. The purpose is to confirm that the correct system, in the correct version, is running on the correct infrastructure before any operational testing begins.
A complete IQ protocol for an eQMS addresses the following:
**System identification.** The software name, version number, and unique identifier must be documented. For cloud-hosted SaaS eQMS platforms, this includes confirmation of the specific tenant environment, the version deployed to that environment, and the vendor's confirmation of the deployment configuration.
**Infrastructure verification.** Hardware specifications, operating system versions, network configuration, browser or client requirements, and database configuration must be verified against the system requirements documented in the vendor's specifications. Any deviations from specification must be identified and resolved or formally accepted before proceeding.
**Installation verification.** Confirmation that all components of the system are present and accessible as specified. For a cloud SaaS eQMS, this typically involves confirming that all licensed modules are available, that user accounts have been created with the correct roles and permissions, and that integrations with other systems (SSO, ERP, LIMS) are functioning.
**Baseline documentation.** The IQ report must capture the system configuration at the point of installation, creating a documented baseline against which future changes can be assessed. Any subsequent changes to infrastructure or configuration that are not reflected in the IQ documentation create a gap in the validated state.
IQ deviations, instances where the actual installation does not match the specification, must be documented, assessed for impact on the validation, and resolved. A deviation that affects the system's ability to perform a quality-critical function cannot be accepted without a documented impact assessment and remediation.
### Operational Qualification (OQ)
OQ establishes documented evidence that the eQMS operates as specified across its functional requirements. Where IQ asks "is the system installed correctly," OQ asks "does the system do what it is supposed to do."
For a risk-based OQ under CSA principles, the test scope should be organized around the system's quality-critical functions: those whose failure would have a direct impact on data integrity, record accuracy, access control, audit trail completeness, or the enforceability of quality processes.
For a typical eQMS, the quality-critical functions that require rigorous OQ testing include:
**Document control.** Version control must prevent unauthorized changes to approved documents. Approval workflows must enforce the defined sequence of reviews and approvals. Electronic signatures must be uniquely tied to the signing user's identity and cannot be delegated or falsified. Version history must be immutable and complete.
**Audit trail.** Every create, modify, approve, delete, and retrieve action on a controlled record must generate an audit trail entry that captures the user identity, timestamp, action type, and the content before and after the change. The audit trail must be tamper-evident: no user, including administrators, should be able to delete or modify audit trail entries.
**Access controls.** Role-based permissions must restrict access to records and functions consistent with the defined role matrix. A user assigned to a read-only role must not be able to approve documents or close CAPAs. Tests must verify both that permitted actions are accessible and that restricted actions are blocked.
**Electronic signatures.** Under 21 CFR Part 11, electronic signatures must be linked to the signer's identity through a unique combination of identification code and password or biometric. The signature must include the printed name of the signer, the date and time of signing, and the meaning of the signature (author, reviewer, approver). OQ must verify all these elements for each signature type in the system.
**CAPA and nonconformance workflows.** Workflow logic must enforce required fields, defined sequencing, and mandatory steps. A CAPA record must not be closeable without a documented effectiveness check date. A nonconformance must not be dispositioned without a documented rationale. Test scripts must attempt to bypass required steps and verify that the system prevents it.
**Training assignment and completion tracking.** The system must correctly auto-assign training based on role changes and document updates. Completion records must be immutable once signed. Overdue training must trigger the configured reminders and escalations.
For lower-risk functions such as reporting dashboards, search functionality, and notification emails, a lighter OQ treatment is appropriate under CSA principles. Fewer test cases, simpler pass/fail criteria, and less detailed documentation are acceptable where the consequence of function failure is a minor operational inconvenience rather than a data integrity or compliance risk.
Each OQ test must have a documented protocol with a test objective, preconditions, step-by-step procedure, expected result, actual result, pass/fail determination, and the identity of the tester and the test date. Deviations must be documented and resolved before OQ is considered complete.
### Performance Qualification (PQ)
PQ establishes documented evidence that the eQMS performs reliably and consistently under actual operating conditions in your environment, with your data, your users, and your processes. Where OQ tests whether the system works according to specification, PQ tests whether it works for you.
PQ is the qualification phase most closely tied to your specific use case, and it is the phase most commonly underexecuted. Generic OQ test scripts supplied by the vendor test the system against its specification. PQ tests the system against your validated QMS processes.
A thorough PQ for an eQMS covers the following:
**Process walkthroughs with real users.** Each core QMS process (document approval, CAPA lifecycle, training assignment, change control, internal audit, supplier qualification) should be walked through end-to-end by the staff who will use it in production, using representative data. The objective is to verify that the system supports the process as designed, not just that the individual functions work in isolation.
**User acceptance testing (UAT).** Formal UAT by process owners, not just the IT or validation team, confirms that the system meets user requirements and that the workflows are configured correctly. UAT findings must be documented and resolved before go-live.
**Performance under load.** For organizations with large user populations or high document volumes, testing the system's performance under representative load conditions is appropriate. Response times, concurrent user handling, and system behavior during peak demand should be assessed.
**Data integrity under failure conditions.** Where technically feasible, testing the system's behavior during connectivity failures, session timeouts, and incomplete transactions verifies that partial data entries do not corrupt records and that the system recovers to a consistent state.
The PQ report must document the testing performed, the results, any deviations, and a conclusion that the system is suitable for its intended use in production. This conclusion, supported by the IQ, OQ, and PQ reports together, forms the validation record that demonstrates compliance with 820.70(i) and Part 11.
---
Working with Vendor-Supplied Validation Packages
Most reputable eQMS vendors will provide a validation support package that includes some combination of the following: a Validation Master Plan, IQ protocol template, OQ test scripts, a traceability matrix linking test cases to functional requirements and regulatory requirements, and a Validation Summary Report template.
This vendor-supplied material is a starting point, not a finished validation. The validation must be executed in your environment, on your infrastructure, with your configuration, and documented as your organization's evidence. A vendor-supplied test script that was executed by the vendor in their test environment does not constitute validation of your deployment.
When evaluating vendor validation support, ask for the following specifically:
Whether the IQ/OQ/PQ protocols reference your specific configuration or are generic templates that require significant customization. Generic templates are acceptable but require more effort to tailor.
Whether the OQ test scripts cover the Part 11 controls (electronic signatures, audit trail, access controls) explicitly, with specific pass/fail criteria. If the test scripts say "verify that an audit trail is maintained" without specifying what the audit trail entry must contain, they are insufficient.
Whether the traceability matrix maps each test case back to a specific user requirement and a specific regulatory requirement (the Part 11 provision or 820.70(i) citation it is designed to verify). A traceability matrix that only maps test cases to functional requirements without regulatory references leaves a gap in the compliance argument.
Whether the vendor provides validation support services, meaning qualified personnel who can assist with protocol execution, deviation management, and report writing. For organizations validating a complex eQMS for the first time, this support significantly reduces risk.
Whether the vendor maintains a pre-validated, locked baseline version that it guarantees against unplanned changes during your validation window. Cloud SaaS vendors that push automatic updates can invalidate in-progress validation work if updates occur during testing.
---
What Triggers Re-Validation
Validation is a lifecycle obligation. The following events require assessment of whether re-validation is needed, and if so, what scope of re-validation is appropriate:
**Software version upgrades.** When the eQMS vendor releases a new version, the manufacturer must assess the changes against the existing validated state. Minor updates that affect only cosmetic elements or low-risk functions may require only a documented assessment and regression testing. Major updates that affect quality-critical functions (signature logic, audit trail structure, workflow enforcement) require formal re-qualification of affected areas.
**Configuration changes.** Changes to workflow configuration, role assignments, document templates, or module settings that affect quality-critical functions must be assessed under change control and re-validated as appropriate. The change control process should include a validation impact assessment as a required step.
**Infrastructure changes.** Changes to the server environment, database, network configuration, or operating system that affect the eQMS require IQ-level re-verification of the affected components.
**Integration changes.** When new integrations are established or existing integrations are modified (SSO configuration, ERP data feeds, LIMS connections), the integration points that affect quality records or audit trails require re-validation.
**Identified deviations in production.** If a user identifies behavior in the production system that does not match the validated specification, this is a deviation that must be investigated through the CAPA system. Depending on the root cause, re-validation of affected functionality may be required.
The change control and CAPA procedures in your QMS should explicitly reference the validation impact assessment process. Without that explicit linkage, configuration changes that affect the validated state may proceed without the required re-validation assessment.
---
The Validation Documentation Set
A complete validation documentation set for an eQMS includes the following records, which must all be maintained under document control:
The **Validation Master Plan (VMP)** defines the scope, approach, responsibilities, and acceptance criteria for the validation. It references the applicable regulatory requirements, the systems and modules in scope, the qualification phases to be executed, and the criteria that must be met before the system is released for production use.
The **User Requirements Specification (URS)** documents what the system must do to support the QMS processes and regulatory obligations. It is the baseline against which OQ and PQ testing is measured. Each requirement in the URS should have a unique identifier that appears in the traceability matrix.
The **IQ Protocol and Report** document the installation verification activities and their results.
The **OQ Protocol and Report** document the functional testing activities, test results, deviations, and the conclusion on whether the system operates as specified.
The **PQ Protocol and Report** document the process-level testing activities, user acceptance testing, and the conclusion on whether the system performs reliably in the production environment.
The **Traceability Matrix** links each URS requirement to one or more OQ or PQ test cases, and links each test case to the regulatory requirement it demonstrates compliance with.
The **Validation Summary Report** consolidates the outputs of IQ, OQ, and PQ into a single document that states the validation conclusion: the system has been validated for its intended use and is approved for production use. This report is the document that an FDA inspector or notified body auditor will ask to see first.
All validation records must be retained for the life of the system and must be available for inspection. Under the QMSR and Part 11, validation records are not exempt from inspection. They are primary evidence of compliance.
---
Validation for EU MDR Manufacturers
EU MDR manufacturers face equivalent obligations through a different regulatory pathway. EU MDR Annex IX requires that the QMS include appropriate systems for post-market surveillance, risk management, and clinical evaluation. All of these processes, when managed in an eQMS, depend on the system functioning correctly and maintaining data integrity. ISO 13485 Clause 7.5.6 independently requires validation of quality system software.
While the EU does not have a direct equivalent of 21 CFR Part 11 for medical device manufacturers (EU GMP Annex 11 applies primarily to pharmaceutical manufacturers), notified bodies assess whether the eQMS is controlled and validated as part of their QMS audit under Annex IX. They will ask to see evidence that the system was validated before use, that changes are controlled, and that the audit trail is complete and tamper-evident. The IQ/OQ/PQ documentation set described in this article satisfies those expectations regardless of whether the primary regulatory framework is FDA or EU MDR.
---
Common Validation Failures in FDA Inspections
Based on 21 CFR Part 11 inspection patterns and the FDA's published enforcement data, the following are the most common validation-related findings:
**No validation documentation at all.** Organizations that deployed a commercial eQMS without conducting formal IQ/OQ/PQ and have no validation records. This is a direct citation under 820.70(i).
**Vendor-supplied test scripts accepted without execution.** Organizations that received a vendor validation package and filed it without executing the tests in their own environment. The validation must be performed by the manufacturer, not the vendor.
**Audit trail gaps or modifications.** Audit trail records that are incomplete, can be modified by administrators, or do not capture all required data elements. This is both a Part 11 finding and a data integrity finding.
**Undocumented configuration changes.** Changes to workflow configuration, role assignments, or system settings that were made without a change control record and without a re-validation assessment. The system is no longer in its validated state.
**Validation records not under document control.** Validation protocols and reports stored outside the document management system without version control, approval records, or access controls. Validation records are quality records and must be treated as such.
**No re-validation after software updates.** Organizations that accepted automatic software updates from their SaaS vendor without assessing the impact on the validated state or executing regression testing. For quality-critical functions, this may constitute operation of an unvalidated system.
---
Final Thoughts
eQMS validation is not a bureaucratic obstacle between your team and a working quality system. It is the process by which you establish, and can prove to any inspector or auditor, that the system you are relying on to manage your quality records actually works as intended, consistently, in your environment.
The FDA's CSA guidance, finalized in September 2025, makes this process more efficient by focusing effort where risk is highest. But it does not reduce the fundamental obligation: there must be documented evidence that quality-critical software functions have been tested, that the system performs as required, and that changes are controlled throughout the system's operational life.
Teams that approach validation as a quality activity rather than a compliance exercise, focusing on proving the system works rather than generating paper, produce validation records that are genuinely useful during inspections and that reflect actual system behavior rather than hypothetical test scenarios.
HAVGATE provides a complete vendor validation package with every deployment, including a Validation Master Plan, IQ/OQ/PQ protocols mapped to 21 CFR Part 11 and ISO 13485 Clause 7.5.6, a regulatory traceability matrix, and a Validation Summary Report template. Create an account to access the validation package and begin your eQMS implementation with the documentation infrastructure already in place.
---
*Regulatory note: This article is written for educational purposes. It reflects the requirements of 21 CFR 820.70(i), 21 CFR Part 11, the FDA Quality Management System Regulation (QMSR, effective February 2, 2026), ISO 13485:2016 Clause 7.5.6, the FDA Computer Software Assurance final guidance (September 24, 2025), and EU MDR 2017/745 Annex IX, as published by their respective regulatory authorities. Always consult the original regulatory texts and qualified regulatory professionals for compliance decisions specific to your systems and operations.*