Computerized System Validation: CSV for QMS Software in Regulated Industries

Your validation. Our documentation. Clearly divided.

Computerized System Validation for QMS Software: IQ/OQ/PQ, FDA CSA Alignment, and the Vendor/User Responsibility Divide

Computerized system validation (CSV) is the documented process by which a regulated company demonstrates that a software system consistently performs its intended functions and produces accurate, reliable records. For any organization in a GxP environment — pharmaceutical, medical device, biotech, CDMO, or other FDA-regulated industry — CSV is not optional. It is a regulatory obligation that begins before go-live and continues for the lifetime of the system.

For QMS software specifically, validation is the mechanism that makes electronic quality records legally defensible. A CAPA record, a change control approval, a training completion — none of these carry regulatory weight unless the system that generated them has been validated to operate accurately and with an intact, tamper-evident audit trail. Audit observations and warning letters frequently cite inadequate computerized system validation as a contributing factor when electronic records fail to satisfy FDA inspection requirements.

This page covers the technical requirements of QMS software validation in detail: how FDA’s 2022 Computer Software Assurance guidance applies to QMS platforms, what the IQ/OQ/PQ framework means for a hosted SaaS system, how validation responsibility is divided between vendor and user, and what the validation lifecycle requires beyond initial qualification. It is written for validation engineers, quality systems professionals, and IT managers evaluating a QMS platform’s validation posture and the documentation it provides. Readers who need a broader regulatory foundation first should review the GxP Compliance Software and 21 CFR Part 11 Software pages for context.

What Is Computerized System Validation — and Why QMS Software Requires It

Computerized system validation is the collection of documented activities that establish and maintain confidence that a software system does what it is designed to do, consistently, accurately, and with records that cannot be altered without detection. The regulatory basis for CSV in FDA-regulated industries derives from multiple sources: 21 CFR Part 11.10(a) requires validation of systems used to maintain electronic records; 21 CFR Part 211.68 requires validation of computer systems used in drug manufacturing; 21 CFR Part 820 (now harmonized with ISO 13485 through QMSR, effective February 2, 2026) requires validation of software used in quality system applications; and ICH Q10 Section 3.2 describes the expectation for validated computerized systems within the pharmaceutical quality system.

The fundamental question validation answers is not whether the software works. It is whether the software works correctly for this organization’s specific intended uses, with documentation that would satisfy an FDA investigator that the organization understands what the system does and has confirmed it performs as expected. A vendor’s assurance that a system is ‘FDA compliant’ or ‘validated’ is not a substitute for the user’s own validation. The regulated user owns the validation obligation regardless of what documentation the vendor provides.

For QMS software, this means validation must cover the functions that generate and protect quality records: document control, CAPA management, audit management, training records, nonconformance handling, change control, and electronic batch records where applicable. Each of these functions interacts directly with 21 CFR Part 11 requirements, because each creates or manages electronic records and electronic signatures that must meet Part 11’s technical and procedural requirements to be accepted as the equivalent of paper records and handwritten signatures.

FDA’s Computer Software Assurance Guidance: Risk-Based Testing Applied to QMS Software

FDA’s 2022 Computer Software Assurance guidance for industry and FDA staff replaced the 2002 General Principles of Software Validation as the operative guidance for software used in FDA-regulated activities. The conceptual shift is from documentation-heavy sequential testing toward a risk-based assurance approach that calibrates testing rigor to the software’s intended use and the consequences of failure.

Under CSA, the critical determination is whether the software is used to make direct product quality decisions — an automated release decision, a real-time process control system, a laboratory information system that directly determines batch disposition — or whether it supports those decisions through documentation and workflow management. QMS software falls in the latter category for most of its functions. A CAPA record does not make a product quality decision. A document control workflow does not directly control a manufacturing parameter. A training completion record documents that a person was trained, but does not physically prevent an untrained person from performing a task.

CSA classifies software use into three categories:

Category 1: Administrative software with no direct product quality impact, requiring no formal validation.
Category 2: Software that indirectly impacts product quality, requiring a risk-based approach with testing focused on intended use.
Category 3: Software that directly impacts product quality, requiring full validation with extensive testing.

eLeaP QMS functions fall predominantly in Category 2. The electronic batch record module, where system-enforced step sequencing and out-of-range flagging have a direct relationship to batch execution quality, has Category 3 characteristics for those specific functions.

The practical consequence for the customer’s validation approach is that the validation package for eLeaP QMS functions should be risk-stratified. Core quality record management functions — document control, CAPA, audit management, training records — require testing demonstrating that the system correctly performs its intended functions, with testing depth proportionate to the risk of failure in each function. EBR execution functions that gate production steps require more rigorous testing. Access control and audit trail functions that support 21 CFR Part 11 compliance require testing that demonstrates the Part 11 requirements are met by the system’s architecture, not by configuration alone.

IQ, OQ, and PQ for QMS Software: What Each Phase Covers in the eLeaP Context

The IQ/OQ/PQ qualification framework originated in equipment qualification and has been applied to computerized systems by established convention and regulatory expectation. For a hosted SaaS QMS platform, each phase has a specific scope that differs from the equipment qualification analogy in important ways.

Installation Qualification: Confirming the Hosting Environment Meets Specifications

For a hosted SaaS application, the IQ scope covers the hosting infrastructure rather than an on-premises installation. The IQ confirms that the application is deployed on hosting infrastructure meeting the defined specifications for availability, security architecture, data isolation, backup frequency and retention, disaster recovery capability, and access control at the infrastructure layer. It also confirms that the application version deployed matches the version described in the OQ protocols and that the hosting environment configuration matches the design specification.

eLeaP executes the IQ against its hosting infrastructure and provides the executed IQ report to customers as part of the validation support package. The customer reviews and accepts the IQ, but does not execute the IQ against eLeaP’s hosted infrastructure — that execution is eLeaP’s responsibility as the system operator.

Operational Qualification: Demonstrating Core System Functions Perform as Specified

The OQ for QMS software covers the application’s core functions against documented functional specifications. For eLeaP, the OQ test library covers:

Document lifecycle management including version control, approval routing with electronic signatures, supersession, and access control enforcement
CAPA workflow execution including stage gating, effectiveness verification requirements, and CAPA-to-training integration
Training matrix assignment and automatic retraining trigger on document revision
Audit trail generation and tamper-evidence demonstration
Electronic signature two-component authentication and cryptographic binding to records
Nonconformance record creation and disposition routing
User access control enforcement at record type, workflow stage, and organizational unit levels

eLeaP executes OQ testing against the base product before each major release and provides the executed OQ test results and a test summary report to customers as part of the validation support package. The OQ test scripts and their mapping to functional specifications and 21 CFR Part 11 requirements are included in the package, allowing the customer’s validation team to review the OQ coverage and identify any gaps relative to their specific risk assessment. The OQ tests are written in a format that the customer can reuse as regression test scripts for subsequent change assessments where retesting is required.

Performance Qualification: Validating Configured Workflows Against Actual Intended Use

The PQ is the customer’s responsibility, executed by the customer’s validation team against the customer’s specific eLeaP configuration and intended use. The PQ scope covers the workflows as configured for the customer’s organization: the document approval routing configured for the customer’s document hierarchy; the CAPA workflow configured with the customer’s escalation logic; the training matrix configured for the customer’s role structure; and the access controls configured against the customer’s org chart. The PQ tests should be written and executed by personnel who represent the user population for each workflow — production operators for batch record execution tests, quality engineers for CAPA workflow tests, and document control personnel for document lifecycle tests.

eLeaP provides PQ protocol templates for each major system function as part of the validation support package. The templates are structured around the customer’s use case scenarios rather than the system’s functions — they test from the user’s perspective rather than the developer’s perspective, which is the orientation FDA’s CSA guidance favors. Each PQ template includes the intended use scenario, the test steps written for the user population who will execute them, the expected result, and the acceptance criteria. The customer populates the templates with their specific configuration parameters, executes the tests, and documents the results. The executed PQ protocols, test results, and a validation summary report signed by the quality unit constitute the customer’s validation package.

Vendor vs. User Responsibilities: The Practical Division That Determines Validation Scope

The division of validation responsibility between the QMS vendor and the regulated user as system owner is the most practically useful framing for a validation engineer planning the validation project scope and budget. Misunderstanding this division leads to one of two failure modes: over-reliance on vendor documentation without executing the required customer validation activities, or duplication of vendor testing that inflates validation effort without adding regulatory value.

What eLeaP Provides

Executed IQ report confirming the hosting infrastructure was installed and configured per the design specification, including hosting environment specifications, security architecture documentation, backup and recovery configuration, and infrastructure access controls.
OQ test library with executed test results for core application functions, including all Part 11-relevant functions: audit trail generation and tamper-evidence, electronic signature authentication and record binding, access control enforcement, and record retention and retrieval.
21 CFR Part 11 compliance traceability matrix mapping each Part 11 requirement clause to the system capability and OQ test that demonstrates compliance.
CSA risk classification documentation covering eLeaP QMS functions by CSA category, supporting the customer’s risk-based validation approach.
PQ protocol templates structured around use case scenarios for each major system function, in the user-perspective format aligned with FDA CSA guidance.
Advance change notification with change assessment documentation identifying affected functions, CSA risk category of the change, and recommended testing scope for the customer’s change control evaluation.
System design documentation, including data flow architecture, security model, API documentation, and role permission matrix, supporting the customer’s risk assessment and gap analysis.

What the Customer Is Responsible For

Validation planning: conducting the risk assessment that determines the validation scope, identifying the intended uses of eLeaP in the customer’s GxP operations, classifying each use by CSA category, and documenting the validation approach in a validation plan that the quality unit approves before validation activities begin.
PQ execution: populating the PQ protocol templates with customer-specific configuration parameters, recruiting the user population who will execute the PQ tests, executing the test scripts against the production eLeaP environment configured for the customer, documenting test results including any deviations and their dispositions, and generating the executed PQ protocol package.
Validation summary report: the quality unit’s documented conclusion that eLeaP, as configured for the customer’s GxP operations, is suitable for its intended use, identifying the validation scope, the qualification phases completed, any limitations or exclusions, and the quality unit’s approval signature.
User access management: establishing and maintaining user accounts, role assignments, and access control configurations consistent with the validated system configuration; verifying user identities per 21 CFR Part 11.100(b) before account provisioning; and obtaining signed certifications from users that their electronic signatures are the legal equivalent of their handwritten signatures per Part 11.100(c).
Ongoing validation maintenance: processing eLeaP system updates through the customer’s change control procedure for computerized systems, executing regression testing per the scope determined by the change impact assessment, and maintaining the validation documentation package to reflect the current validated configuration.

The Validation Lifecycle Beyond IQ/OQ/PQ: Change Control, Periodic Review, and Retirement

Initial qualification is the beginning of the validation lifecycle, not the end. The validated state of a QMS software system is maintained or degraded by everything that happens after the validation summary report is signed: system updates, configuration changes, user access changes, and the passage of time. Most organizations invest adequately in initial qualification and underinvest in ongoing validation lifecycle management. The result is a validation package that describes the system as it existed at go-live, not as it exists today.

Change Control for Validated Systems

Every change to a validated system — a platform update, a workflow configuration change, an access control modification, a new module activation — requires assessment against the validated state before implementation. The change control procedure for computerized systems must define who performs the impact assessment, what documentation is required, and what testing must be completed before the change is implemented in the GxP environment.

An eLeaP platform update that adds new features to modules not currently in scope for the customer’s validation has no impact on the validated state and requires no testing. An update that modifies the behavior of a validated function — a change to audit trail capture logic, a change to electronic signature authentication, a change to workflow stage gating — requires at minimum a review of the affected OQ test cases and, where the change is significant, re-execution of those tests.

eLeaP’s advance change notification is designed to support the customer’s change control assessment. Each notification identifies the application version number, the release date, the functional areas affected, the CSA risk category of each change, and the OQ tests that cover the affected functions. The customer’s validation engineer can review the notification against their validation scope and determine the required testing response before the update is deployed to their production environment. eLeaP maintains the option for customers with extended change control timelines to remain on prior application versions during their change assessment period, within the version support window defined in the service agreement.

Periodic Review of Validated State

FDA’s expectation, reflected in the CSA guidance and in inspection practice, is that the validated state of a computerized system is periodically reviewed to confirm that the system continues to perform its intended functions correctly and that the validation documentation reflects the current configuration. Periodic review intervals are typically annual for Category 2 systems and more frequent for Category 3 functions.

The periodic review examines whether any system changes have been implemented without completing the required change control activities, whether the user access configuration reflects current personnel and role assignments, whether any anomalies or deviations have been observed in the system’s performance that may indicate a drift from the validated state, and whether the validation documentation package remains current and accurate.

eLeaP supports the periodic review with a current system configuration report that documents the application version, the active module configuration, the role and permission structure, and a summary of system changes since the last review. The customer’s validation team uses this report as the basis for the periodic review assessment, comparing the current configuration against the validated configuration documented in the validation summary report and identifying any gaps requiring remediation.

Retirement and Migration of Validated Systems

When a validated system is retired — because the organization is migrating to a new platform, consolidating quality systems, or discontinuing an application — the retirement requires a controlled process that preserves access to historical GxP records for the regulatory retention period. Records stored in eLeaP at the time of retirement must remain accessible and attributable — the audit trail and electronic signature records must be preserved in a retrievable format — for as long as the records are required to be retained under applicable regulations. The retirement plan must address how records will be archived, what format will be used, and how access will be maintained without requiring a licensed eLeaP instance.

eLeaP provides data export capabilities that produce records in structured formats suitable for archival, including audit trail records and electronic signature records in their associated form. The export format specifications are documented in the validation support package data export documentation. The customer’s retirement plan should address the export scope, the validation of the export function, the format in which exported records will be retained, and the access mechanism for retrieving archived records during the retention period.

21 CFR Part 11 and System Validation: The Prerequisite Relationship

The relationship is prerequisite: a system cannot maintain Part 11-compliant electronic records unless it has been validated. Validation is not sufficient to establish Part 11 compliance — the system must also have the technical capabilities that Part 11 requires, including tamper-evident audit trails, two-component electronic signatures, and cryptographic binding of signatures to records. But without validation, those technical capabilities cannot be relied upon as accurate and reliable, which is what Part 11 compliance requires.

The Part 11 compliance traceability matrix in eLeaP’s validation support package maps each Part 11 requirement to the system capability that addresses it and to the OQ test that demonstrates the capability performs correctly. This matrix serves two purposes: it supports the customer’s validation scope determination by identifying the Part 11 requirements that eLeaP’s architecture addresses, and it provides the evidence linkage that an FDA investigator will examine when reviewing the validation package to confirm Part 11 compliance is supported by testing, not just by architecture documentation.

Validation engineers reviewing the Part 11 compliance posture of eLeaP should focus on three areas where Part 11 compliance depends on both system architecture and correct configuration: access control, which requires that role assignments correctly restrict access to authorized individuals; audit trail scope, which requires that the customer confirm the audit trail is enabled for all GxP-applicable record types in their configuration; and electronic signature meaning, which requires that the signature meaning fields in each workflow configuration are populated with accurate descriptions of the action being signed rather than generic acknowledgment language.

CSV in Regulated Industries: Validation Scope Varies by Sector

While the regulatory framework for computerized system validation applies across FDA-regulated industries, the specific validation scope and risk classification decisions depend on how QMS software is used in each sector. Understanding the sector-specific context helps validation engineers calibrate their validation packages appropriately.

Pharmaceutical and CDMO Environments

In pharmaceutical manufacturing and contract development and manufacturing organizations, QMS software typically operates alongside validated process control and laboratory systems. The validation scope for QMS software in these environments must account for the interfaces between the QMS and those adjacent systems: does a nonconformance record in the QMS trigger any automated action in a process control system? Does a CAPA action item interact with a validated LIMS? Where interfaces exist, they require validation in their own right. The QMS validation must also align with the site’s Computer System Validation master plan and SOPs, which define the validation methodology, documentation requirements, and change control procedures that govern all computerized systems at the site.

Medical Device Manufacturers

Medical device manufacturers operate under QMSR (the Quality Management System Regulation, effective February 2, 2026, harmonized with ISO 13485). QMSR incorporates ISO 13485 requirements for software validation, including the requirement to validate software used in the quality management system before use. For device manufacturers, the validation of QMS software is also part of the design history file considerations when the QMS software is used to manage design and development records — the DHF depends on the integrity of the document control system that stores it. Validation documentation should address this dependency explicitly.

Biotech and Clinical-Stage Organizations

Biotech organizations at clinical stage frequently face validation obligations before they have established a full validation infrastructure. The CSA guidance’s risk-based approach is particularly relevant here: a clinical-stage organization can develop a proportionate validation package that addresses the functions actually in use and the records that are material to the clinical program, rather than attempting to validate every system function against a full enterprise deployment scope. The validation package can be extended as the organization’s systems use grows toward commercial manufacturing.

Evaluating a QMS Vendor’s Validation Support Package: Five Questions for Validation Engineers

When evaluating a QMS software vendor’s validation documentation, generic assurances that a system is validated or FDA compliant are not responsive to the actual regulatory requirements. Technical documentation is the required answer. A validation engineer evaluating any QMS vendor’s validation support package should ask these five questions:

Question 1: Does the vendor provide an executed IQ report confirming the hosting infrastructure configuration against documented specifications, or does the IQ documentation consist of a system description without executed test evidence?
Question 2: Does the OQ test library cover all Part 11-relevant functions — audit trail generation and tamper-evidence, electronic signature two-component authentication, cryptographic binding of signatures to records, and access control enforcement — with executed test results and a Part 11 traceability matrix mapping each requirement to the test that demonstrates compliance?
Question 3: Are PQ protocol templates provided in a use-case-scenario format aligned with FDA CSA guidance, or do the templates consist of the same test scripts as the OQ repackaged for the customer to re-execute?
Question 4: Does the vendor’s change notification documentation include the CSA risk category of each change and identify the OQ test cases affected, supporting the customer’s impact assessment, or does it provide a release notes document that describes new features without risk classification?
Question 5: Does the vendor provide a current system configuration report for periodic review support, and does the data export specification support the customer’s record archival obligation at system retirement?

eLeaP’s validation support package satisfies all five criteria. The package is available for review during the procurement evaluation phase — a validation engineer can assess the package against the customer’s validation requirements before the contract is signed. Request a validation package review session through the contact page at eleapsoftware.com.

Frequently Asked Questions: Computerized System Validation for QMS Software

What is computerized system validation for QMS software?

Computerized system validation (CSV) for QMS software is the documented process by which a regulated organization demonstrates that its quality management software consistently performs its intended functions, produces accurate and complete records, and maintains an intact audit trail. The regulatory basis includes 21 CFR Part 11.10(a) for electronic records, 21 CFR Part 211.68 for pharmaceutical manufacturing systems, and QMSR/ISO 13485 for medical device manufacturers. Validation is a user obligation — the regulated organization, not the software vendor, is responsible for executing and maintaining the validation.

Is QMS software Category 2 or Category 3 under FDA’s Computer Software Assurance guidance?

Most QMS software functions fall in CSA Category 2, which covers software that indirectly impacts product quality and requires a risk-based approach with testing focused on intended use. Functions like document control, CAPA management, training records, and audit management are Category 2 because they support quality decisions without making direct product quality decisions. Electronic batch record functions that gate production steps — where the system enforces step sequencing or prevents batch release based on out-of-range data — carry Category 3 characteristics for those specific functions and require more rigorous testing. A risk-stratified validation package addresses both categories within a single QMS platform.

Who is responsible for the PQ in a SaaS QMS deployment?

The Performance Qualification is always the customer’s responsibility. For a hosted SaaS QMS, the vendor executes and provides the IQ (confirming the hosting infrastructure) and the OQ (confirming the base application functions perform as specified). The PQ must be executed by the customer against the customer’s specific configuration and intended use — the workflows as configured for the customer’s organizational structure, the CAPA logic as configured for the customer’s escalation procedures, and the training matrix as configured for the customer’s role structure. Vendor-provided PQ templates accelerate this work, but the customer must populate, execute, and document the PQ results independently.

How does eLeaP support computerized system validation?

eLeaP provides a validation support package that includes an executed IQ report for the hosting infrastructure, an OQ test library with executed test results for all core application functions including all 21 CFR Part 11-relevant functions, a Part 11 compliance traceability matrix mapping each Part 11 requirement to the system capability and OQ test that demonstrates compliance, CSA risk classification documentation for all QMS functions, and PQ protocol templates structured around use case scenarios in the format aligned with FDA CSA guidance. eLeaP also provides advance change notification with CSA risk classification for each change, a current system configuration report for periodic review, and data export specifications for record archival at system retirement.

What is the difference between 21 CFR Part 11 compliance and computerized system validation?

21 CFR Part 11 compliance and computerized system validation are related but distinct obligations. Part 11 defines the technical and procedural requirements that electronic records and electronic signatures must meet to be accepted as equivalent to paper records and handwritten signatures — requirements like tamper-evident audit trails, two-component electronic signatures, and cryptographic binding of signatures to records. System validation under 21 CFR Part 11.10(a) is the mechanism by which a regulated organization demonstrates that its electronic records system actually satisfies those requirements accurately and reliably. The relationship is prerequisite: a system cannot be Part 11 compliant unless it has been validated, because without validation there is no demonstrated basis for trusting that the technical capabilities perform correctly.

How does change control work for a validated QMS system?

Every change to a validated QMS system — a software update, a workflow configuration change, an access control modification, or a new module activation — requires a documented change impact assessment before the change is implemented in the GxP environment. The impact assessment evaluates whether the change affects any validated function. Changes to functions outside the current validation scope require no testing. Changes that modify the behavior of validated functions require at minimum a review of the affected OQ test cases; significant changes require re-execution of those tests. eLeaP’s advance change notifications include the CSA risk category of each change and identify the OQ test cases affected, supporting the customer’s change control decision without requiring the customer to analyze the change from scratch.

How often does a validated QMS system require periodic review?

FDA’s expectation, reflected in the CSA guidance and in inspection practice, is that validated computerized systems are periodically reviewed to confirm that they continue to perform as intended and that validation documentation reflects the current configuration. For Category 2 systems, periodic review intervals are typically annual. Category 3 functions warrant more frequent review. The periodic review examines whether all changes since the last review went through proper change control, whether the current user access configuration matches the authorized configuration, whether any system anomalies suggest drift from the validated state, and whether the validation documentation package is current and accurate.

What happens to validated QMS records when a system is retired?

When a validated QMS system is retired or replaced, records must remain accessible and attributable for the full regulatory retention period applicable to each record type — which may extend years beyond the system retirement date. The audit trail and electronic signature records associated with each quality record must be preserved in a retrievable format that does not require a licensed instance of the original software. The retirement plan must address the export scope, the validation of the export function itself, the archive format, and the access mechanism for retrieval during the retention period. eLeaP provides structured data export capabilities with documented export specifications to support the customer’s retirement and archival planning.

Request a Validation Package Review

eLeaP’s validation support package — executed IQ report, OQ test library with Part 11 traceability matrix, CSA risk classification, and PQ protocol templates — is available for review during the procurement evaluation phase. A validation engineer can assess the complete package against the organization’s validation requirements before the contract is signed.

Contact eLeaP to schedule a validation package review session: eleapsoftware.com/contact

Related resources: