Verification vs validation in medical software

What does the difference actually decide?

It decides which document is missing when somebody outside your company reads the file. IEC 62304 Edition 1.1 closes subclause 1.2, Field of application, with one sentence: "This standard does not cover validation and final release of the MEDICAL DEVICE, even when the MEDICAL DEVICE consists entirely of software." The capitals are IEC's convention for terms defined in Clause 3. The sentence is not an Amendment 1 addition; the same words appear in the 2006 first edition.

NOTE 1 to the same subclause pushes further: where the software is itself a medical device, additional development activities are needed at system level before it can be placed into service, and "These system activities are not covered by this standard". The note points at IEC 82304-1, which is a different standard with its own scope, and the system-level activities it names are not answered by anything in the software life cycle file.

A team that closes every clause of IEC 62304 therefore holds a complete software verification record and, from that standard, nothing that speaks to intended use. Which clauses bind at which safety class, and what each of them asks for, is set out on IEC 62304 software testing requirements. The release condition inside the standard points the same way: clause 5.8.1, Ensure software VERIFICATION is complete binds at classes A, B and C, and it asks that verification activities are complete and their results evaluated before release.

The obligation the exclusion leaves behind sits in the quality system. ISO 13485:2016 lists clause 7.3.6, Design and development verification and clause 7.3.7, Design and development validation as two consecutive and separate subclauses of 7.3. Two subclauses mean two records, two sets of acceptance criteria and two decisions about who signs. What that standard expects of software in the quality system is covered on ISO 13485 software validation.

Which evidence does each activity produce?

The two measure against different baselines, so they produce different documents.

Verification under IEC 62304 set against validation under ISO 13485:2016, by baseline, clause, meaning of a pass, source of evidence and effect of a failure.

The reviewer's question	Verification answers with	Validation answers with
What was the baseline?	The approved software requirement, at a stated revision	The intended use and the user need the product was built for
Which clause carries it?	IEC 62304 5.7.4, which asks that every software requirement has been tested or otherwise verified and that the traceability is recorded, at classes A, B and C	ISO 13485:2016 7.3.7, Design and development validation, a subclause distinct from 7.3.6
What does a pass mean?	The build behaves as the specification says	The specified behaviour is fit for the use claimed
What can produce the evidence?	An executed test against a written expected result	Evidence from use, which ISO/TR 24971:2020 says can include clinical data and usability studies
What does a failure change?	The code, or the test	The requirement, and often the claim

For software used in production or in the quality management system, the record set is named directly by the regulators auditing to ISO 13485. The MDSAP audit approach expects a software requirements document describing the intended uses and user needs, an established validation protocol describing the activities needed to demonstrate the requirements can be met, records of the results of those activities, and records that software changes are controlled. It also tells the auditor, for a software-controlled process, to "verify that the software is validated for its intended use".

The intended use document comes first in that list because the protocol has to be built against it. A validation protocol drafted from the software requirements specification alone has no baseline of its own.

Why does a product that passes every verification still fail validation?

Because the requirement can be implemented perfectly and still be the wrong requirement. ISO 14971:2019 makes this explicit for anything safety related: subclause 7.2 is titled "Implementation of risk control measures", and it puts two distinct verification obligations on each measure, one on the implementation and one on the effectiveness.

The two halves close on different evidence. Design review and the approval of a specification can settle the implementation half. For the other half, ISO/TR 24971:2020 says in 4.4.7 that verification of effectiveness "can require the collection of clinical data, usability studies, etc., as part of design and development validation in a quality management system".

One shape this takes in a shipped product: an alert fires when a measurement crosses a configured threshold, the requirement says exactly that, the unit test asserts exactly that, and the integration test asserts exactly that. Every result is green. The threshold was chosen without evidence, the alert fires so often that the ward mutes the channel, and the risk control measure that the file relies on has been verified as implemented and never shown to be effective. No test run against the specification can raise that, because the specification is what it is being run against. How the risk file and the test evidence join up is covered on ISO 14971 risk management and software testing.

FDA has been saying the same thing about software generally since 2002. The computer software assurance guidance restates the position of the General Principles of Software Validation: software testing alone is often insufficient to establish confidence that software is fit for its intended use, and quality assurance should focus on preventing defects from entering development.

Who may perform each, and what may they test against?

ISO 13485:2016 keeps the two records apart at 7.3.6 and 7.3.7, and the second of them often rests on evidence produced by people who are not engineers: clinicians, participants in a usability study, or a data set collected in use.

For production and quality management system software, FDA's computer software assurance guidance permits a manufacturer to leverage validation activities performed by other entities such as developers, suppliers and cloud service providers, and on the same page puts design and development verification or validation for device software functions outside its own scope. The routes it names for assessing such a vendor, and the record it still expects, are on FDA computer software assurance.

Evidence from use is where somebody proposes a copy of the production database. We do not need production PHI to test. Environments run on synthetic and de-identified data. Where a test needs a real-world shape, the route to it is agreed in writing before an environment exists and de-identification is verified, on the terms set out at how we work with protected health information.

When does work called validation produce only verification evidence?

When the acceptance criteria were copied from the document the software was built from. FDA describes the habit in its own account of why it wrote the computer software assurance guidance: software validation "has often been accomplished via software testing and other verification activities conducted at each stage of the software development life cycle", and manufacturers asked for a more iterative approach.

Five shapes of that mistake, each of which produces a thick file and no validation argument:

• A validation protocol whose expected results were pasted from the software requirements specification. It can only report whether the build matches the specification.
• IEC 62304 conformance filed as the validation evidence, when subclause 1.2 excludes device validation by its own words.
• An end-to-end automated suite renamed "validation run" at release. The suite asserts written expectations, and the tooling then carries obligations of its own, set out in test automation inside a validated environment.
• 21 CFR Part 11 system validation cited as device validation. section 11.10(a) names four objectives, "accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records", and those are properties of the record system.
• A supplier's validation package accepted for a tool your process depends on, with no statement of your own intended use for it to be measured against.

What does a changed requirement reopen on each side?

Each side reopens on its own trigger. The verification side reopens by rule: 5.7.3 of IEC 62304 Edition 1.1 is the retest obligation, and Edition 1.1 reaches class A software with it as well as class B and class C. How the reopened set gets chosen and then defended is the subject of regression testing for regulated software, and this page does not repeat it.

On the validation side the trigger is a judgement, and no diff produces it. The question is whether the change moved the intended use, the user need or the claim. ISO 13485:2016 gives that its own subclause, clause 7.3.9, Control of design and development changes, which sits alongside 7.3.7 rather than inside the verification subclause. A change can leave every existing test valid and still invalidate the argument the tests were run to support, because the argument rested on evidence from use that the change made obsolete.

For production and quality management system software on an approved PMA or HDE, FDA ties the reporting route to the same distinction: a change that may result in a quality problem that foreseeably compromises safety should generally be submitted in a 30-day notice, and one that would not may be appropriate in an annual report. The example the guidance gives is a manufacturing execution system that manages workflow and alerts, against one that automatically controls and adjusts established critical production parameters such as temperature, pressure and process time.

What changes in your test plan once the two are separated?

Four changes, and each one is a decision you make once and reuse every release.

Step 2 is the one that changes a file most. Once the labels exist, the rows whose baseline is the specification and the rows whose baseline is the intended use can be counted, and a file that is entirely the first kind is visible on the first page instead of at the audit. Assembling both sets so a reviewer can enter at either baseline is the work described at validation documentation and requirements traceability.

Sources for this page. The quoted sentence from subclause 1.2, NOTE 1, the class markers on 5.7.3 and 5.8.1 and the clause titles of IEC 62304 are read in Edition 1.1, checked against IEC's own preview of the consolidated version on 2 September 2026. The ISO 13485:2016 subclause numbers and titles come from the Contents of ISO's preview of that standard, and the record expectations from the MDSAP audit approach. The ISO 14971:2019 subclause title and the quoted passage on verification of effectiveness are read in that standard and in ISO/TR 24971:2020, 4.4.7. The FDA material is the final guidance Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026, which is nonbinding on its face.