ISO 13485 software validation requirements

What does ISO 13485 require for software validation?

Three clauses, and they are three separate obligations. FDA's MDSAP Audit Approach names the applicable clauses for Task 15, validation of software used for the control of the production and service process, as ISO 13485:2016 4.1.6, 7.5.6 and 7.6. It instructs the auditor that if the selected process is software controlled, or if software is used in production equipment or the quality management system, the software is to be verified as validated for its intended use.

Two of the three announce their subject in their own titles: clause 7.5.6, Validation of processes for production and service provision and clause 7.6, Control of monitoring and measuring equipment. clause 4.1.6 is the third. It is a subclause of 4.1 General requirements, cited by the MDSAP regulators in both validation tasks, Task 7 and Task 15. ISO's published Contents pages do not enumerate the subclauses of 4.1, so this page gives 4.1.6 by number and says nothing about its wording.

What the validation has to produce is set out by the regulators who audit to this standard. MDSAP Task 15 expects a software requirements document stating the intended uses and user needs, a validation protocol describing the activities that demonstrate those requirements can be met, records of the results of those activities, and records that changes to the software are controlled. For off the shelf quality system software and for software controlled production or test equipment it may not be possible, practical or necessary to review the code, and validation against a protocol with predetermined acceptance criteria is still expected.

One piece of ISO's own wording decides how much of this counts. Introduction 0.2 states that when the standard requires something to be documented, it also requires it to be established, implemented and maintained. A validation protocol that exists as a file and was never executed satisfies none of the three.

Which edition are you being audited against?

ISO 13485:2016, third edition, dated 2016-03-01 on the cover. ISO's catalogue records the standard as published and confirmed, stage 90.93, with the note that it was last reviewed and confirmed in 2025 and remains current. Two documents are routinely cited that do not mean what the citation implies.

Designations cited as ISO 13485, from the 2016 ISO edition to an Amd 1:2021 that ISO has no record of, with publisher and status.

Designation	Published by	What it is
ISO 13485:2016	ISO	The third edition. Published 2016-03, systematic review closed 2025-06-05, confirmed 2025-10-31
EN ISO 13485:2016	CEN	The ISO text approved without any changes, superseding EN ISO 13485:2012
EN ISO 13485:2016/A11:2021	CEN	A European amendment dated 16 September 2021, after the corrigenda AC:2016 and AC:2018
ISO 13485:2016/Amd 1:2021	Nobody	No such record exists. ISO's life cycle block lists no amendment to the 2016 edition

The second correction concerns your planning horizon. ISO/TC 210 has no revision project for ISO 13485 open at any stage. The only 13485 item under development in the committee catalogue is ISO/CD TS 23485, a guideline for applying the 2016 edition, at stage 30.99. A decision to postpone work until the next edition lands buys nothing and loses the year.

Why is ISO 13485 now the citation a US investigator uses?

21 CFR part 820 is now the Quality Management System Regulation, and section 820.7(b) incorporates ISO 13485:2016(E) by reference. The final rule, 89 FR 7496, was published on 2 February 2024 with an effective date of 2 February 2026. A follow-up rule of technical amendments, 90 FR 55978, published 4 December 2025 and effective the same day, changed references from the QSR to the QMSR across 179 sections in 18 parts of Title 21.

For a company shipping software, three provisions carry the consequences.

Section 820.10(c) requires manufacturers of class II, class III and listed class I devices, including devices automated with computer software, to comply with Clause 7.3 Design and Development and its subclauses. A class I product that would otherwise sit outside design controls is pulled in by the software in it.

Section 820.10(b) pins named ISO clauses to US regulations that stay in force beside them: Clause 7.5.8 with part 830 for UDI, Clause 8.2.3 with part 803 for reporting, Clauses 7.2.3, 8.2.3 and 8.3.3 with part 806 for advisory notices. Section 820.35 adds record content on top of Clause 4.2.5.

Section 820.1(b) settles what happens when the two disagree: where a clause of ISO 13485 conflicts with the Federal Food, Drug, and Cosmetic Act or its other implementing regulations, the Act and those regulations control. How much validation effort each of those clauses justifies is the question FDA answers separately in computer software assurance.

What can testing check here, and what can it not?

Testing produces the evidence that sits underneath the validation records. No test technique is named anywhere in ISO 13485, because the subject of the standard is the quality management system rather than the software inside a device. What it asks for is that the software you rely on was shown to do what you said it does, in writing, against criteria fixed in advance.

Two limits follow. Certification is issued by a certification body or notified body to your organisation after it audits your system, so no test report from any supplier produces one. And the life cycle of the software inside your device is a different subject, governed by IEC 62304. Deciding which record belongs in which file is the practical work, and the split between the two standards is where a design history file usually leaks.

Which artefacts will the auditor ask for?

The auditor asks for the six artefacts in the list below, in that order. The inventory comes first because it decides how many of the other five exist: one protocol per software item, scoped to the clause that item falls under.

Several clause titles name a record: 4.2.3 Medical device file, 4.2.4 Control of documents, 4.2.5 Control of records, 7.3.10 Design and development files, 8.2.4 Internal audit. Those titles tell you where the records live. The requirement text behind them sits behind ISO's paywall, and this page does not paraphrase a requirement from a title.

Which findings come back most often?

• The production process is validated and the quality system tools have no protocol at all, which leaves the 4.1.6 part of Task 15 with no evidence behind it.
• The electronic QMS is validated by its vendor, and the organisation holds no protocol of its own stating its own intended use.
• Acceptance criteria are written after the run, from the result. MDSAP asks for criteria set in advance, and an order of dates the records cannot show is treated as criteria written to fit the outcome.
• A validated tool is upgraded several times after the protocol is executed, with no change records, which fails the fourth of the four record types Task 15 lists.
• A class I device with software is scoped without design controls, although 820.10(c) names devices automated with computer software.
• The quality manual cites the European amendment while the FDA incorporation at 820.7(b) cites only ISO 13485:2016(E), third edition, 1 March 2016.

How do we close ISO 13485 software validation?

The inventory and the clause split come first, before any test plan. Each item then gets its intended use, a protocol with criteria fixed in advance, an executed run with results tied to a version, and a change record that keeps the validation current after the next upgrade. What you hold at the end is the six artefacts listed below, one set per software item, indexed by the clause each item answers to.

The record side of this is validation documentation, and the protocols and executed runs are FDA software validation. Where the software in scope is your own test tooling, test automation in a validated environment covers how to keep a suite validated while it changes every sprint. Where validating a tool means working inside a system that holds PHI, the terms come first, and they are raised at how we work with protected health information.

Every clause number on this page comes from the Contents pages of ISO's published preview of ISO 13485:2016. The edition, the status and the amendment history come from the ISO catalogue entry, read on 2 September 2026.