Validation and Verification Compliance Requirements

Validation and verification (V&V) are distinct but interdependent compliance obligations that apply across regulated industries including medical devices, pharmaceuticals, aerospace, automotive, and software-intensive systems. Regulatory bodies such as the U.S. Food and Drug Administration (FDA), the Federal Aviation Administration (FAA), and the Department of Defense (DoD) each impose formal V&V requirements tied to product approval, market authorization, and continued operational licensing. Failures in V&V documentation represent one of the leading categories of FDA Warning Letters and 483 Observations, making procedural clarity a high-stakes operational necessity.

• Definition and Scope
• Core Mechanics or Structure
• Causal Relationships or Drivers
• Classification Boundaries
• Tradeoffs and Tensions
• Common Misconceptions
• Checklist or Steps
• Reference Table or Matrix

Definition and Scope

Verification answers the question: Was the product built correctly? Validation answers the question: Was the correct product built? This distinction, formalized in ISO 9000:2015 and echoed in FDA regulations, is not semantic — it drives entirely different test protocols, evidence requirements, and regulatory submissions.

Verification is the systematic examination of objective evidence confirming that specified requirements have been fulfilled at a given stage of development. It is typically performed against design inputs — drawings, specifications, standards — using inspection, analysis, demonstration, or test.

Validation is the confirmation, through objective evidence, that the requirements for a specific intended use or application have been fulfilled. For medical devices, this is codified under 21 CFR Part 820.30(g), which requires device design validation to include testing of actual or simulated use conditions.

The scope of V&V obligations extends across the product development lifecycle and into manufacturing process control. For pharmaceutical manufacturing, 21 CFR Part 211 requires process validation before distribution of drug products. For software used in medical devices, the FDA's guidance document General Principles of Software Validation (2002) establishes a framework requiring both verification of code against specifications and validation of the software system against user needs.

Broader applicability includes AS9100 Rev D for aerospace and defense, IATF 16949:2016 for automotive, and ISO/IEC 12207 for software lifecycle processes. Each standard frames V&V obligations differently but retains the core verification-versus-validation split as its organizing principle. For a broader view of how V&V fits within the quality management system, see Quality Management System Compliance.

Core Mechanics or Structure

V&V compliance operates through a structured sequence of planning, execution, and documentation artifacts. Each phase generates records that collectively constitute the evidence package submitted to regulators or auditors.

V&V Plan
The plan identifies what will be verified or validated, the methods to be used, the acceptance criteria, the responsible personnel, and the schedule. Under 21 CFR Part 820.30(j), the design history file (DHF) must contain the procedures and results of all verification and validation activities.

Protocols
Protocols are pre-approved, formal documents that specify test conditions, sample sizes, equipment calibration requirements, and step-by-step execution instructions. The FDA's process validation guidance (January 2011, FDA Process Validation Guidance) defines three stages of process validation: Stage 1 (Process Design), Stage 2 (Process Qualification), and Stage 3 (Continued Process Verification). Each stage has distinct protocol requirements.

Execution and Data Collection
Execution must follow the approved protocol without deviation. Any deviation triggers a formal exception record. Raw data must be retained in a format that demonstrates traceability from test result back to requirement.

Report and Closure
A V&V report summarizes execution results against acceptance criteria, documents deviations, assesses their impact, and makes a pass/fail determination. Open deviations that do not meet acceptance criteria must route into the corrective and preventive action (CAPA) system before validation closure.

Causal Relationships or Drivers

V&V requirements do not arise in a vacuum — they are driven by demonstrable failure modes, regulatory enforcement history, and international harmonization pressures.

Product Harm Events
Inadequate validation of manufacturing processes has been directly linked to product failures and patient harm. The FDA's recall database shows process-related failures as a persistent cause of Class II and Class III medical device recalls. This enforcement history directly shaped the tightening of 21 CFR Part 820 requirements and the subsequent Quality System Regulation (QSR) modernization under the FDA's Quality Management System Regulation (QMSR), effective February 2026, which aligns Part 820 with ISO 13485:2016.

Regulatory Harmonization
The International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use (ICH) guideline ICH Q10 established a pharmaceutical quality system model that embeds continued process verification as a lifecycle requirement, not a one-time activity. This drove the FDA's 2011 shift away from a single pre-approval validation event toward the three-stage process validation model.

Software Complexity Growth
As software content in regulated products increased, purely hardware-focused V&V frameworks proved inadequate. The FDA's recognition of IEC 62304 as a consensus standard for medical device software development lifecycles created a pathway where software verification activities (unit testing, integration testing, system testing) must be documented and traceable to software requirements specifications.

Classification Boundaries

V&V requirements vary substantially based on product risk class, regulatory jurisdiction, and development methodology. Understanding classification boundaries determines which specific V&V elements are mandatory.

By Risk Class (FDA Medical Devices)
- Class I devices (lowest risk, e.g., bandages): generally exempt from 510(k) premarket notification; V&V requirements still apply under Part 820 for design-controlled devices.
- Class II devices (moderate risk): require 510(k) clearance; substantial equivalence must be supported by V&V data demonstrating performance equivalence to a predicate device.
- Class III devices (highest risk, e.g., implantable cardiac devices): require Premarket Approval (PMA); full design V&V data is part of the PMA submission reviewed by FDA.

By Activity Type
- Installation Qualification (IQ): Verifies that equipment is installed according to manufacturer specifications.
- Operational Qualification (OQ): Verifies that equipment operates within defined parameters across its operating range.
- Performance Qualification (PQ): Validates that the process, using qualified equipment, consistently produces acceptable product under actual production conditions.

By Development Paradigm
Waterfall-based development generates V&V evidence sequentially, matching phases to a V-model. Agile development creates a challenge: iterative delivery compresses or eliminates distinct V&V phases, requiring adapted frameworks such as those described in the FDA's draft guidance on Agile for SaMD (Software as a Medical Device).

Inspection and testing compliance frameworks overlap with verification activities at the component and subsystem level and require coordination to avoid duplication of records.

Tradeoffs and Tensions

V&V compliance is not free of internal conflicts. Practitioners and regulatory authors have acknowledged persistent tensions in how these requirements are applied.

Rigor Versus Speed
Full V&V protocols — particularly three-stage process validation — are time-intensive. A Stage 2 Process Qualification for a sterile injectable drug can require 30 or more consecutive conforming runs before commercial production may begin. Compressed timelines create pressure to reduce protocol stringency, which regulators view as a compliance risk.

Predetermined Acceptance Criteria
A fundamental principle of valid V&V is that acceptance criteria must be set before execution, not after reviewing results. Post-hoc criteria setting — adjusting limits to accommodate observed data — is considered data integrity fraud under FDA expectations and has resulted in Warning Letters and consent decrees. This tension is acute when product performance differs from historical assumptions.

Continued Process Verification Burden
The ICH Q10 and FDA 2011 frameworks require ongoing statistical monitoring of validated processes. This generates a sustained data collection and analysis burden that scales with product portfolio size. Organizations operating 50 or more validated processes face significant resource allocation challenges in maintaining CPV programs.

Software V&V Scope Creep
IEC 62304 assigns software safety classes (A, B, C) to software items, with Class C requiring the most stringent V&V evidence. When software architecture decisions push functionality into higher safety class items without corresponding V&V planning, scope and cost expand mid-project.

Common Misconceptions

Misconception 1: Verification and validation are interchangeable terms.
They are not. Verification confirms conformance to specifications; validation confirms fitness for intended use. Using the terms interchangeably in regulatory submissions or design history files signals to FDA reviewers a lack of procedural understanding.

Misconception 2: A single successful test run constitutes validation.
Process validation requires demonstration of consistency, not a single event. The FDA's 2011 process validation guidance explicitly states that the number of runs must be justified based on process variability and that statistical rationale should support sample sizes.

Misconception 3: V&V is a one-time pre-launch activity.
Continued Process Verification (Stage 3 of the FDA framework) and post-market surveillance requirements under 21 CFR Part 820.100 establish V&V as a lifecycle obligation. Any change to materials, equipment, facilities, or procedures may trigger revalidation under 21 CFR Part 820.75.

Misconception 4: Software testing is software validation.
Software testing is a component of software verification (confirming the code performs per specification). Software validation requires evidence that the software, in its intended deployment environment, meets user needs. The FDA's 2002 General Principles of Software Validation guidance explicitly distinguishes these activities and requires both.

Misconception 5: V&V only applies to the final product.
Manufacturing process validation, equipment qualification, and software tool validation each constitute independent V&V obligations. Computerized systems used in production or quality management — including LIMS, ERP, and MES systems — require validation under FDA 21 CFR Part 11 and EU Annex 11 equivalents.

Checklist or Steps

The following elements constitute a V&V compliance program structure as reflected in FDA, ISO 13485, and ICH guidance frameworks. This is a reference enumeration, not professional advice.

1. Establish V&V policy and procedure — Document the organizational scope, definitions of verification and validation, roles and responsibilities, and triggers for V&V activities.
2. Define design inputs — Capture intended use, user needs, and performance requirements before verification activities begin. Design inputs are the reference baseline for verification.
3. Develop V&V Plan — Identify what will be tested, by whom, using what method, against which acceptance criteria, and by what schedule.
4. Author protocols before execution — Write and obtain approval for all protocols prior to any test execution. Document protocol version control and approval signatures.
5. Execute protocols as written — Assign qualified personnel. Record execution dates, equipment identifiers (with calibration status), environmental conditions, and raw data.
6. Document deviations in real time — Any departure from the approved protocol must be recorded immediately, assessed for impact, and escalated per deviation procedure.
7. Prepare V&V report — Summarize results against acceptance criteria. Include statistical analysis where required. Document disposition of deviations.
8. Route failures through CAPA — Unacceptable results must enter the formal CAPA system. Revalidation may be required after root cause correction.
9. Archive in the Design History File or equivalent — Store plan, protocols, raw data, deviations, and report in the designated controlled record location per 21 CFR Part 820.30(j).
10. Establish continued verification triggers — Define change control thresholds that require revalidation: material supplier changes, equipment replacement, facility relocation, software updates, and process parameter drift.

Reference Table or Matrix

References

• FDA — 21 CFR Part 820 (Quality System Regulation / QMSR)
• FDA — 21 CFR Part 211 (Current Good Manufacturing Practice for Finished Pharmaceuticals)
• FDA — Process Validation: General Principles and Practices (January 2011)
• FDA — General Principles of Software Validation (January 2002)
• FDA — Quality Management System Regulation (QMSR) Final Rule
• FDA — 21 CFR Part 11 (Electronic Records; Electronic Signatures)
• [ISO 9000:2