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

Every GxP organisation using eLeaP to maintain electronic quality records has a validation obligation. That obligation is not delegated to the software vendor. It is owned by the regulated user, supported by the vendor’s documentation package, and sustained through the lifetime of the system through change control, periodic review, and eventual retirement or migration. This page covers what QMS software validation requires technically, how FDA’s Computer Software Assurance guidance applies to eLeaP, what eLeaP provides as part of the validation support package, what the customer must execute independently, and what the validation lifecycle requires beyond the initial qualification.

This is not an introductory treatment of computerized system validation. It assumes familiarity with the regulatory framework and is written for validation engineers, quality systems professionals, and IT managers who are evaluating eLeaP’s validation posture specifically. Readers who need a regulatory foundation first should review the GxP Compliance Software page and the 21 CFR Part 11 Software page for context.

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 covers administrative software with no direct product quality impact, requiring no formal validation. Category 2 covers software that indirectly impacts product quality and requires a risk-based approach with testing focused on intended use. Category 3 covers 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 like eLeaP, 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 for eLeaP 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 organisational 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 organisation: 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 for eLeaP.

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

The division of validation responsibility between eLeaP as the vendor and the regulated user as the 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.

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’s 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 notification of system updates 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.

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 companies 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 — an eLeaP 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 advanced 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 eLeaP 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 organisation 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

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 satisfy to be accepted as equivalent to paper records and handwritten signatures. System validation under 21 CFR Part 11.10(a) is the mechanism by which the regulated user demonstrates that their electronic records system satisfies the accuracy, reliability, consistent performance, and record integrity requirements of Part 11.

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 authorised 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.

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

A validation engineer evaluating eLeaP’s validation support package against the customer’s regulatory obligations should ask these five questions. Generic affirmations that a system is ‘validated’ or ‘FDA compliant’ are not responsive to these questions. Technical documentation is the required answer to each.

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?
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?
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?
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?
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 at eleapsoftware.com.

Related resources: