Medical Device Verification and Validation: Design Controls, Testing, and Documentation

Verification proves that a design output meets its specified requirements. Validation proves that the finished product meets user needs and its intended use under actual or simulated conditions. The distinction sounds simple, but teams that plan these activities late - or conflate them - end up with rework cycles, failed audits, and delayed market entry. This guide walks through how medical device verification and validation fit inside design controls, what testing and documentation look like in practice for software and connected devices, and what evidence package you should expect from a development partner.

Verification vs validation in medical device development

The confusion between verification and validation persists because both involve testing, both generate evidence, and both feed into the Design History File (DHF). But they answer different questions at different stages.

Verification asks: "Did we build the product right?" It compares design outputs against design inputs - the documented requirements. A verification test might confirm that a sensor module returns readings within a specified tolerance, or that a software function calculates a dosage correctly per the requirements specification.

Validation asks: "Did we build the right product?" It compares the finished device against user needs and intended use. A validation activity might involve clinicians using a production-equivalent unit in a simulated clinical workflow to confirm the device performs safely and effectively for its intended patient population.

One practical consequence of this distinction: you cannot validate a device that has not been verified. Verification failures caught during validation are expensive because they force you back through design changes, re-verification, and potentially new validation protocols.

Where V&V fits inside design controls

Medical device design controls form a structured development framework required by FDA's Quality Management System Regulation (QMSR) and ISO 13485:2016. Verification and validation are not standalone activities bolted on at the end. They are embedded checkpoints within the design control process.

The design control sequence

1. User needs - Captured from clinical stakeholders, patients, and intended-use scenarios. These are the foundation that validation will eventually test against.
2. Design inputs - Translated from user needs into measurable, testable requirements. Ambiguous inputs produce unverifiable outputs, so business analysis services at this stage pay for themselves many times over.
3. Design outputs - Specifications, drawings, software builds, labeling, and manufacturing procedures that respond to design inputs.
4. Design verification - Confirms each output satisfies its corresponding input. Traceability between inputs and verification evidence must be explicit.
5. Design reviews - Formal, documented reviews at defined stages. Reviews are not approvals; they are structured evaluations of progress, risks, and open issues.
6. Design validation - Confirms the device, as built, meets user needs and intended use. Performed on production-equivalent units under actual or simulated conditions of use.
7. Design transfer - Handoff to manufacturing with verified and validated specifications.
8. Design History File (DHF) - The complete record of the design control process, including all plans, inputs, outputs, reviews, verification records, validation records, and change orders.

Traceability matrix

A requirements traceability matrix links every user need to its design input, every design input to its design output, every output to its verification evidence, and every user need to its validation evidence. Without this matrix, auditors cannot confirm coverage, and your team cannot confirm completeness.

The 2026 QMSR update

The FDA QMSR became effective February 2, 2026, incorporating ISO 13485:2016 into 21 CFR Part 820. This means FDA inspections now reference ISO 13485 requirements directly. According to the FDA QMSR FAQ, records created before February 2, 2026 may still be reviewed during QMSR inspections, and manufacturers may find a comparative analysis between their existing QMS documentation and the updated regulation useful. If your DHF and design control procedures were built around the old Part 820 language, now is the time to perform that gap analysis.

Risk management integration

Risk management under ISO 14971 runs in parallel with design controls. Verification activities should confirm that risk mitigations are implemented correctly. Validation activities should confirm that residual risks are acceptable in the context of actual use. Risk management outputs - the risk file, FMEA, fault tree analyses - feed directly into verification and validation planning.

How to plan verification for software and connected devices

Software verification for medical devices and SaMD products follows the same principle as hardware verification - confirm outputs meet inputs - but the methods, tools, and regulatory expectations differ.

Start with requirements quality

Verification is only as good as the requirements it tests against. Each design input should be:

• Specific enough to write a pass/fail test against
• Traceable to a user need
• Unambiguous - if two engineers could interpret a requirement differently, it needs rewriting
• Testable - if you cannot define acceptance criteria, the requirement is not ready

Investing in requirements engineering before coding begins reduces the volume of verification rework downstream. Teams that treat requirements as living documents and manage them in a structured backlog - rather than static Word files - tend to maintain traceability more reliably through iterative development cycles.

Verification testing layers

For software-intensive medical devices, verification typically spans multiple layers:

• Unit testing - Tests individual functions or modules against their specifications. Automated unit tests with defined coverage targets (statement, branch, MC/DC depending on risk class) provide repeatable evidence.
• Integration testing - Confirms that modules interact correctly. For connected devices, this includes communication protocols, API contracts, and data exchange between subsystems.
• System testing - Validates the complete software system against the software requirements specification. This includes functional testing, performance testing, boundary testing, and error handling.
• Static analysis - Automated code analysis tools identify coding standard violations, potential null pointer dereferences, memory leaks, and other defects without executing the code. For higher-risk devices, static analysis results become part of the verification record.
• Regression testing - Confirms that changes have not introduced new defects. Automated regression suites are practically mandatory for any device that will receive software updates postmarket.

Structured QA and testing services should produce documented test protocols, expected results, actual results, and pass/fail dispositions for each verification activity.

Cybersecurity verification

For connected medical devices and SaMD, FDA cybersecurity guidance places cybersecurity squarely inside the device safety and quality system. For cyber devices, software validation and risk management may need to incorporate cybersecurity risk management and validation processes. In practice, this means:

• Threat modeling during design inputs
• Security requirements traced alongside functional requirements
• Verification activities that include vulnerability scanning, fuzz testing, and penetration testing services
• Evidence that security controls (authentication, encryption, access control, software update integrity) function as specified

Cybersecurity verification evidence belongs in the DHF alongside functional verification records.

Acceptance criteria and traceability

Every verification test needs predefined acceptance criteria documented before execution. Post-hoc rationalization of test results is a common audit finding. The traceability matrix should link each test case to its design input, and each test execution record to its test case. Gaps in this chain are gaps in your regulatory submission.

How to plan validation with real users and real workflows

Design validation confirms that the device, as a complete system, meets user needs and intended use. For software-based medical devices, this goes beyond functional correctness into usability, clinical workflow integration, and real-world performance.

Production-equivalent units

Validation must be performed on units that are representative of production. For SaMD, this means the released software build running on the intended platform or deployment environment - not a developer's laptop running a debug build. For connected devices with hardware, this means units manufactured using production processes, not hand-built prototypes.

Simulated-use and actual-use testing

The FDA General Principles of Software Validation guidance describes validation under actual or simulated conditions of use. The choice depends on the device and its risk profile:

• Simulated-use testing - Recreates the clinical environment, patient scenarios, and user workflows in a controlled setting. Appropriate when actual clinical use before clearance is not feasible or ethical.
• Actual-use testing - Performed in the real clinical environment with real users and, where applicable, real patients. Often part of clinical studies for higher-risk devices.

Usability validation

Human factors and usability engineering (IEC 62366-1) require summative usability testing as part of design validation. This involves representative users performing representative tasks with the production-equivalent device. The goal is to identify use errors that could cause harm - not to gather feature feedback. Usability validation protocols define:

• Representative user groups (e.g., nurses, physicians, home users)
• Representative use scenarios derived from the use specification
• Performance criteria (task completion, critical errors, close calls)
• The testing environment setup

Labeling and training validation

If the device relies on labeling (instructions for use, quick-start guides, on-screen instructions) or training to ensure safe use, those materials must be validated alongside the device. A device that performs correctly but whose labeling leads users to misinterpret results has a validation gap.

Handoff to postmarket

Validation does not end at market release. The validation plan should define how postmarket surveillance data - complaint trends, adverse events, software anomaly reports - feeds back into the design control process. Postmarket evidence can trigger design changes that require re-verification and re-validation.

Evidence package buyers should expect from a development partner

Whether you are building in-house or working with a healthcare software development partner, the deliverables that matter are the ones an auditor will ask for. A polished demo is not evidence. A passing CI pipeline is not a DHF.

What the evidence package should contain

• Verification and validation plans - Written before testing begins. Define scope, methods, acceptance criteria, responsibilities, and the statistical rationale for sample sizes where applicable.
• Requirements traceability matrix - Complete bidirectional traceability from user needs through design inputs, outputs, verification, and validation.
• Test protocols and reports - For each verification and validation activity: protocol (what will be tested, how, acceptance criteria), raw data, results, pass/fail disposition, and signatures.
• Risk management file - Hazard analysis, risk evaluation, risk control measures, verification of risk controls, and residual risk evaluation. Linked to the traceability matrix.
• Software documentation - Software development plan, software requirements specification, architecture design document, detailed design, unit test records, integration test records, system test records, release notes.
• Defect disposition records - Every defect found during V&V must be documented with its disposition: fixed, deferred with rationale, or determined not to be a defect. Open critical defects at release are a red flag.
• Design review records - Minutes, attendees, action items, and closure evidence for each formal design review.
• Release criteria - Predefined criteria that must be met before the device can be released. These should reference verification completion, validation completion, open defect status, and risk acceptability.

Questions to ask a development partner

Before engaging a custom software development services provider for a medical device project, ask:

1. How do you manage requirements traceability through iterative development sprints?
2. What is your process for defining and reviewing acceptance criteria before test execution?
3. Can you show a sample DHF or design control deliverable set from a previous project (redacted)?
4. How do you handle design changes after verification - what triggers re-verification, and how is the scope determined?
5. Who owns the risk management file, and how is it updated as the design evolves?
6. What cybersecurity testing do you perform, and how is it documented in the verification record?
7. How do you support the transition from design validation to postmarket surveillance?
8. What QMS do you operate under, and is it certified to ISO 13485?

A partner who cannot answer these questions with specifics - referencing their own procedures, templates, and past project evidence - is not ready for regulated medical device work.

Practical next steps

If you are planning a medical device or SaMD build, remediating an existing design control gap, or preparing for an audit under the updated QMSR, here is where to focus:

1. Run a gap analysis against the 2026 QMSR requirements. Compare your current QMS documentation and design control procedures to ISO 13485:2016 as incorporated by the QMSR. The FDA FAQ explicitly suggests this comparative analysis.
2. Audit your requirements for testability. Pull your design inputs and ask: can each one be verified with a defined test and a pass/fail criterion? Requirements that fail this check need rewriting before you invest in verification testing.
3. Build the traceability matrix now, not later. Retrofitting traceability after development is complete takes three to five times longer than maintaining it during development. Start the matrix when you write your first design input.
4. Define your validation strategy early. Identify your representative user groups, use scenarios, and simulated-use environment during design planning - not after verification is complete. Validation logistics (recruiting users, setting up environments, IRB approvals if needed) have long lead times.
5. Evaluate your development partner on evidence, not demos. Ask for sample deliverables. Review their defect disposition process. Confirm they can produce the documentation your regulatory submission requires, in the format your notified body or FDA reviewer expects.

The cost of getting verification and validation right during development is a fraction of the cost of remediation after a failed audit or a field safety corrective action. Start with the gap analysis, lock down your requirements, and build the evidence as you go.

Vladimir Terekhov

Co-founder and CEO at Attract Group