ISO 14971 risk management and software testing

What does ISO 14971 require?

A process, run across the whole life of the device, and records showing you ran it. The 2019 edition is 36 pages and ten clauses, and the requirements live in clauses 4 to 10. Annexes A, B and C are all marked informative, so nothing in them is a requirement you can be audited against.

Clauses 4 to 10 of ISO 14971 and their titles, from general requirements for the risk management system to production and post-production activities.

Clause	Title
4	General requirements for risk management system
5	Risk analysis
6	Risk evaluation
7	Risk control
8	Evaluation of overall residual risk
9	Risk management review
10	Production and post-production activities

Only sentences using "shall" are auditable. The Introduction sets the verbal forms from Clause 7 of the ISO/IEC Directives Part 2:2018: "should" is a recommendation, "may" is permission, "can" expresses possibility, and "must" marks an external constraint that the document itself does not impose. A finding is written against a "shall".

The standard depends on nothing else. clause 2, Normative references reads in full: "There are no normative references in this document." The Foreword records that the clause was added in this edition only to satisfy the ISO/IEC Directives.

Two things in the 2019 text put clinical software squarely inside the process. The scope names the risks it covers "such as risks related to biocompatibility, data and systems security, electricity, moving parts, radiation, and usability", and the Foreword records that the third edition explains the process can be used for managing risks related to data and systems security. Definition 3.3 defines harm as "injury or damage to the health of people, or damage to property or the environment", and the Introduction extends property to "objects, data, other equipment". A corrupted record or a lost result is therefore harm under this standard, and belongs in the risk file rather than in a defect tracker.

Which version binds in your market?

One ISO text, recognised twice over. In the EU the harmonised standard is EN ISO 14971:2019 with its amendment EN ISO 14971:2019/A11:2021, entered as No 16 on the MDR harmonised standards list by Commission Implementing Decision (EU) 2022/757 of 11 May 2022, and as No 10 on the IVDR list by Decision (EU) 2022/729 of the same day. The consolidated MDR list as at 30 January 2026 still carries entry No 16, so conformity with it still confers presumption of conformity under Article 8(1) of Regulation (EU) 2017/745. Teams working through that route will find the sequence in EU MDR software market entry testing.

In the US, FDA recognises the complete standard: recognition number 5-125, recognition list 053, entered 23 December 2019, with ANSI/AAMI/ISO 14971:2019 named as the identical adoption.

A11 exists because CEN and Cenelec revised the EN under the standardisation request in Commission Implementing Decision C(2021) 2406 of 14 April 2021, to adapt it to Regulation (EU) 2017/745. It is a European adaptation layer and it does not change the ISO text. Its European annexes are not readable in any public preview, so a clause-to-requirement mapping table handed to you by a consultant is that consultant's claim to defend, and you cannot check it against the free extract.

Who decides what risk is acceptable?

You do, and the standard says so explicitly, which means nobody can hand you a number. The scope clause states: "This document requires manufacturers to establish objective criteria for risk acceptability but does not specify acceptable risk levels."

Nothing in the 36 pages supplies a matrix or a probability threshold you could adopt. clause 4.2, Management responsibilities puts the origin of those criteria at the top of the company. ISO's own guidance itemises the requirement: top management provides adequate resources, assigns competent personnel, defines and documents a policy for establishing the criteria for risk acceptability, and reviews the suitability of the risk management process. ISO/TR 24971:2020 subclause 4.2.2 adds that the policy also has to give guidelines for the criteria for acceptability of the overall residual risk.

Two consequences for a chief executive. The acceptability criteria are a decision your board signs, and an auditor traces them back to a policy rather than to a spreadsheet. A vendor offering you a ready-made acceptability threshold is offering to make that decision on your behalf, and the standard assigns it to your management.

The scope also fences off two areas. The document "does not apply to" either "decisions on the use of a medical device in the context of any particular clinical procedure" or "business risk management". The Introduction is blunter than the scope on the first: such decisions "can be made only by a qualified medical practitioner with knowledge of the state of health of an individual patient or the patient's own opinion". Your risk file answers for the device and does not answer for the clinical decision taken with it.

The second exclusion is the one that damages files in practice. Schedule slip, recall cost and reputational exposure are business risks, and a register that mixes them with patient harm produces a document an auditor has to disentangle before they can assess it.

Which part of this does testing produce evidence for?

clause 7.2, Implementation of risk control measures is the hinge between the risk process and the test plan, and it carries two obligations rather than one. ISO/TR 24971:2020 states it flatly at subclause 4.4.7: "The risk management plan specifies how the two verification activities required per 7.2 of ISO 14971:2019 are carried out."

The two activities ask different questions and produce different records.

The two ISO 14971 risk control verifications, implementation and effectiveness, with the question each answers and where ISO guidance places it.

Verification	The question it answers	Where ISO's guidance places it
Implementation	Is the control present in the product?	Design review, approval of specifications, or design and development verification
Effectiveness	Did the risk it was chosen for go down?	Design and development verification; can require clinical data or usability studies as part of design and development validation

Most risk files fill the first row and leave the second one implied. A test case asserting that an alarm fires when a value crosses its limit verifies implementation. Evidence that the alarm reaches a user who then acts in time is a different exercise, and ISO/TR 24971 subclause 4.4.7 names usability studies and the collection of clinical data among the ways to produce it. If the boundary between those two questions is unfamiliar, verification versus validation in medical software sets out how the terms are used.

The plan carries more than the verification methods. ISO/TS 24971-2:2026 subclause 4.4 itemises what ISO 14971 obliges the risk management plan to include: the scope of the risk management activities, responsibilities and authorities, requirements for review, the criteria for risk acceptability, the method for evaluating overall residual risk with the criteria for its acceptability, the verification activities for implementation and effectiveness, and the activities for collecting and reviewing production and post-production information. ISO/TR 24971 subclause 4.4.6 notes that placing the overall residual risk method and its criteria in the plan is an obligation the 2019 edition introduced.

Where does software risk behave differently?

Security risk is estimated on a different basis from everything else in the file. FDA's recognition record for this standard carries a caveat: definition 3.18 puts risk as the combination of the probability of occurrence of harm and the severity of that harm, and FDA's premarket cybersecurity guidance, issued February 2026, states that this probabilistic model does not apply to cybersecurity, substituting exploitability, the feasibility and technical means by which a vulnerability can be exploited. Security test evidence reported as a probability figure will not line up with what a US reviewer expects. Medical device cybersecurity testing under FDA 524B covers what that evidence looks like instead.

Machine learning has ISO guidance and generative AI has none. ISO/TS 24971-2:2026, published June 2026, applies the ISO 14971 process to machine-learning enabled medical devices and states that it "does not provide a new risk management process, nor does it expand the requirements of ISO 14971." Its scope excludes devices "employing large language models (LLM) or generative AI", so a team shipping an LLM feature applies ISO 14971 with no ISO-published guidance written for it and has to justify its own method. Validating an AI model in clinical software covers how that evidence is built.

How does this join up with IEC 62304?

Through a single normative reference. IEC 62304 Edition 1.1 lists exactly one normative reference, ISO 14971, and that reference is undated, so the edition which applies is the current one. Its Introduction gives the reasoning: the risk management process "is already very well addressed by the International Standard ISO 14971. Therefore IEC 62304 makes use of this advantage simply by a normative reference to ISO 14971." It adds that the software risk management process of its clause 7 "has to be embedded in the device RISK MANAGEMENT PROCESS according to ISO 14971."

The join is clause to clause. IEC 62304 clause 7.3, Verification of risk control measures, is the software-side counterpart of ISO 14971 clause 7.2, Implementation of risk control measures. What the software standard adds is the identification of software factors contributing to hazards; the acceptability criteria those factors are judged against still come from the ISO 14971 process above them. The clause set and the safety classification are covered in IEC 62304 software testing requirements.

The ISO 14971 scope names "software as a medical device" explicitly, so an SaMD product runs this process in its own right rather than as a component inside somebody else's device. How a regulator expects that product's risk to be categorised is a separate exercise, described in SaMD risk categorization under IMDRF.

Which records make up the risk management file?

Whichever records the individual clauses call for, plus the traceability that connects them. ISO/TR 24971:2020 subclause 4.5 states that "the individual clauses in ISO 14971:2019 specify what records and related documents are to be maintained as part of the risk management file", and that the file "is a logical construct": the records may sit in the quality management system or elsewhere, in any format, provided they can be produced.

The traceability obligation is the part teams underestimate. ISO/TR 24971 subclause 4.5 again: "ISO 14971:2019 requires traceability for each identified hazard to the risk analysis, risk evaluation, implementation and verification of risk control measures, and the evaluation of residual risk. Traceability is a requirement to prove that all identified hazards have been completely addressed in the risk management process." One row per hazard, ending at the residual risk that remains.

ISO 14971 risk management file contents by clause, from the 4.4 risk management plan to production and post-production records under clause 10.

Clause	What has to exist
4.4 Risk management plan	A plan for the particular device, with every change to it recorded in the risk management file
4.5 Risk management file	The file itself, and the hazard traceability running through it
5 Risk analysis	The recorded results of the planned risk analysis activities
7.2 Implementation of risk control measures	Verification records for implementation, and separate ones for effectiveness
8 Evaluation of overall residual risk	The result, judged against the method and criteria the plan stated in advance
9 Risk management review	The risk management report, produced before commercial distribution
10 Production and post-production activities	Records of a system that actively collects field information and reviews it for relevance to safety

Where do ISO 14971 risk files fail an audit?

• Every risk control has an implementation record and none has an effectiveness record, so half of clause 7.2 has no evidence behind it.
• The criteria for risk acceptability appear inside the risk file and in no management policy, so the comparison made in clause 6, Risk evaluation, traces back to nobody.
• The method for evaluating overall residual risk is picked while clause 8 is being written, although the 2019 edition requires it to be stated in the plan for the particular device.
• Business risks share a register with patient harm, although the scope excludes business risk management outright.
• Traceability runs from hazard to risk control and stops there, with no link forward to the residual risk that remains.
• Field information arrives as complaints and is never reviewed for relevance to safety, so clause 10 has an inbox and no record.
• The risk management plan is revised during the project and the changes are never recorded in the risk management file.

How do we close this on a project?

We work outward from the hazard list. Each identified hazard becomes a row. Each risk control on that row gets two test outputs, one for implementation and one for effectiveness. Each row ends at the residual risk with the evidence that supports it. The output is the artefact list above, in a state where an auditor picks a hazard at random and walks it to the end without anyone explaining the file to them.

Effectiveness is where the effort concentrates, because it is the column a unit test cannot fill. Deciding what evidence can show that a control worked belongs at planning time, since ISO/TR 24971 subclause 4.4.7 places usability studies and clinical data among the answers, and both take longer to arrange than a test cycle.

Competence is itself part of the file. ISO/TR 24971 subclause 4.3 says the required competence should be documented along with objective evidence that it is met, and says so explicitly for external consultants and specialists. An outside test team therefore appears in your risk management file by name and with evidence of its qualifications. How that team is cleared to handle PHI is a separate question with its own paperwork. The record side of the work is described in validation documentation.

Every clause number and clause title on this page was checked on 2 September 2026 against the ISO catalogue entry and the publisher's preview of ISO 14971:2019. Statements attributed to ISO/TR 24971:2020 and ISO/TS 24971-2:2026 are quoted from those documents, which restate a requirement before giving guidance on it.