ISO 14971: The Risk Management File, Benefit-Risk Determination, and the ISO/TR 24971 Cross-Walk

ISO 14971:2019 is the international standard for applying risk management to medical devices, including in vitro diagnostic (IVD) devices. A procurement-oriented summary of ISO 14971 is also maintained in LAC Health’s compliance glossary. Almost every explanation of it stops at the risk table — a spreadsheet of hazards, severity scores, probability scores and a colour-coded product. That table is not the deliverable. The deliverable is a risk management file whose structure a notified body auditor or an FDA reviewer can walk backwards, hazard by hazard, from a claim of acceptable residual risk to the evidence that supports it.

This page covers what that file has to contain, how a benefit-risk determination differs from a risk score, and — the part most treatments skip — which clauses of ISO 14971 are deliberately thin and where ISO/TR 24971:2020 supplies the missing method. 14971 tells you what the process must produce; TR 24971 is the companion technical report that explains how. Reading one without the other is the most common reason a risk management file looks complete internally and still generates findings.

ISO standards are copyrighted and sold, not published openly. Nothing below reproduces the text of ISO 14971 or ISO/TR 24971. This page describes the requirements, cites clause numbers, and sources every regulatory-status claim to a document you can read for free — chiefly the U.S. FDA’s Recognized Consensus Standards database.

Edition and status: what “current” actually means in 2026

Four documents circulate under variations of the same number, and they are not interchangeable.

Designation	What it is	Status
ISO 14971:2019 (Third edition, dated 2019-12)	The normative international standard. Requirements only.	Current edition.
ANSI/AAMI/ISO 14971:2019	The U.S. national adoption.	Recorded by FDA as an identical adoption of the ISO third edition.
EN ISO 14971:2019/A11:2021	The European version. The A11 amendment is a CEN common modification that adds informative Annexes ZA and ZB mapping the standard to the EU MDR and IVDR. It does not change the normative requirements.	Cited in the Official Journal as a harmonised standard for Regulation (EU) 2017/745 — see the caveat below.
ISO/TR 24971:2020 (Second edition, dated 2020-06)	A technical report giving guidance on applying 14971. Informative, not normative. Adopted in the U.S. as AAMI/ISO TIR24971:2020.	Current companion document.

The FDA recognition, verified

FDA recognises ISO 14971 Third edition 2019-12 under recognition number 5-125, entered on 23 December 2019 on Federal Register recognition list 053, assigned to the General I (QS/RM) specialty task group. The extent of recognition is “Complete standard” — FDA has not carved out any clause. The same database record names ISO/TR 24971 Second edition 2020-06 and AAMI/ISO TIR24971:2020 as supportive publications, which is FDA telling you, in its own file, that the technical report is part of how it expects the standard to be read. (Verified 26 August 2026 against the FDA Recognized Consensus Standards database record, standard identification no. 41349; the record’s own page-updated stamp is 25 May 2026.)

“Complete” recognition means a manufacturer may submit a declaration of conformity to the whole standard in a premarket submission rather than the underlying data. It does not mean FDA has approved your risk management file, and it does not replace the device-specific risk information a 510(k) or PMA reviewer asks for — see 510(k) vs PMA for how the two pathways differ in what they demand.

One recognition note almost nobody carries: risk is probabilistic, except for security

FDA’s supplementary information sheet for recognition 5-125 attaches a note with real design consequences. ISO 14971:2019 defines risk (definition 3.18) as the combination of the probability of occurrence of harm and the severity of that harm. FDA’s premarket cybersecurity guidance states that this probabilistic model does not apply to cybersecurity risk, and substitutes exploitability — the feasibility and technical means by which a vulnerability can be exploited — as the operative basis for security risk estimation. The note directs that standards referencing risk for cybersecurity purposes should reflect that distinction.

Practically: if your risk management file scores a security vulnerability with a probability-of-harm estimate borrowed from your safety risk matrix, you have used the wrong model, and FDA has said so in the recognition record itself rather than only in guidance. Security risk belongs in a parallel analysis keyed to exploitability, cross-referenced from the risk management file. This matters most for software as a medical device and for connected instruments, and it interacts with a predetermined change control plan where one is in place.

The risk management file is an index, not a document

Clause 4.5 of ISO 14971:2019 requires a risk management file for the device under consideration. The single most consequential misreading of the standard is treating that as an instruction to write a document called “Risk Management File”. It is not. The file is a defined, traceable set of records — the records may live in your PLM system, your design history file, your test reports and your post-market database, so long as the file provides traceability to each of them for every identified hazard.

The traceability obligation is what turns a spreadsheet into a file. For each identified hazard, the file must let a reader follow an unbroken chain:

1. Risk analysis — the hazard, the sequence of events, the hazardous situation, the harm, and the estimate of risk.
2. Risk evaluation — the decision, against your pre-stated criteria, on whether risk reduction is required.
3. Implementation of risk control measures — what you actually changed, with a record of implementation.
4. Verification of the implementation — evidence the measure is genuinely in the product or process, not just in the design intent.
5. Verification of the effectiveness of that measure — evidence it does what it was supposed to do to the risk. This is a separate verification from step 4 and is the one most often missing.
6. Residual risk evaluation, and where required, the benefit-risk determination.

Steps 4 and 5 are two obligations, not one phrasing of the same obligation. “The alarm was added and the drawing was updated” is implementation. “The alarm annunciates within the time required for a user to intervene, demonstrated under the conditions of the hazardous situation” is effectiveness. A file that verifies implementation everywhere and effectiveness nowhere is internally consistent and still non-compliant.

The file, the plan, and the report are three different objects

Object	Clause	What it is
Risk management plan	4.4	Written before the analysis. Defines scope, responsibilities, review requirements, the criteria for risk acceptability, verification activities, and how production and post-production information will be collected and reviewed. It is part of the file.
Risk management file	4.5	The whole traceable record set for the device, maintained across the lifecycle. Not a single document.
Risk management report	9	The output of the review conducted before release: the conclusion that the plan was implemented, that overall residual risk is acceptable, and that appropriate methods are in place for production and post-production information. Also part of the file.

The criteria for risk acceptability go in the plan, and they derive from a risk management policy set by top management under clause 4.2 — before you know your results. Writing acceptability criteria after the analysis, so that the criteria happen to accommodate the risks you found, is the failure this sequencing exists to prevent, and it is visible in a file’s document dates.

Clause by clause: what each part of the process must produce

Clause	Obligation in one line	Evidence it generates
4 — General requirements	Establish the risk management process, management responsibilities, competence of personnel, the plan, and the file.	Policy, plan, competence records, file index.
5 — Risk analysis	Define intended use and reasonably foreseeable misuse; identify characteristics related to safety; identify hazards and hazardous situations; estimate risk for each.	Intended-use statement, safety characteristics list, hazard analysis, risk estimates.
6 — Risk evaluation	Decide, against the criteria in the plan, whether risk reduction is required for each hazardous situation.	Documented evaluation decisions.
7 — Risk control	Option analysis in a required order of priority; implement; verify implementation and effectiveness; evaluate residual risk; benefit-risk analysis where residual risk is not acceptable; check for new risks introduced by the controls; confirm completeness.	Control option rationale, V&V records, residual risk records, benefit-risk determinations.
8 — Overall residual risk	Evaluate the residual risk of the device as a whole, against criteria in the plan, after all controls.	A separate, whole-device evaluation — not a sum of the individual ones.
9 — Risk management review	Review before release; confirm plan implementation, overall residual risk acceptability, and post-production methods.	The risk management report.
10 — Production and post-production activities	Collect and review production and post-market information; act when it changes the risk picture.	A running, dated feedback loop with defined triggers.

Intended use and “reasonably foreseeable misuse” are load-bearing, not preamble

Clause 5.2 requires both. Reasonably foreseeable misuse — use that departs from the instructions but that a manufacturer can predict from how people actually behave — is the boundary that determines which use errors you are obliged to analyse. Set it too narrowly and every use-related finding becomes “off-label, out of scope”, which is the position that collapses first under an auditor’s questions and under post-market complaint data. Use-related risk analysis is where 14971 meets usability engineering; FDA’s human factors and usability engineering guidance covers what a use-error analysis has to demonstrate on the U.S. side.

Hazard, hazardous situation, harm: the three-part chain people collapse into two

ISO 14971 distinguishes a hazard (a potential source of harm), a hazardous situation (circumstances in which people, property or the environment are exposed to one or more hazards), and harm (injury or damage). Risk is estimated for the hazardous situation, not for the hazard in the abstract — which is precisely why a two-column “hazard / harm” table cannot support a risk estimate. Without the sequence of events that produces exposure, there is nothing to assign a probability to.

The probability of harm is itself commonly decomposed into two parts: the probability that the sequence of events leading to the hazardous situation occurs (P1), and the probability that the hazardous situation then leads to harm (P2). ISO/TR 24971 discusses this decomposition; it is the practical answer to the objection that “you cannot estimate probability for a novel device”. You often can estimate P1 from field or process data even when P2 has to be argued from clinical literature.

Illustrative worked chain

The following is an illustrative composite, written to show the structure of the chain. It is not drawn from any real manufacturer’s risk management file and does not describe a real product.

Element	Illustrative content
Hazard	Electrical energy at the patient-applied part.
Sequence of events	Insulation degrades over the service life → a single-fault condition goes undetected because the self-test runs only at power-on → the device is used in a procedure lasting several hours.
Hazardous situation	The patient is in contact with an applied part carrying leakage current above the permitted limit.
Harm	Burn at the contact site; in the worst credible case, arrhythmia.
P1 / P2	P1 from insulation ageing and self-test coverage data; P2 from the clinical literature on the relationship between the current level and injury.
Risk control (in priority order)	Inherent safety first — redesign the insulation system and add continuous rather than power-on-only monitoring. Only then a protective measure (alarm and automatic shutdown). Information for safety in the IFU is the last resort, not the first.
Verification of implementation	Design output, drawings, and build records show continuous monitoring is present in the released configuration.
Verification of effectiveness	Testing demonstrates detection and shutdown within a time short enough to prevent the harm, under the conditions of the hazardous situation.

Risk control: the order of priority is mandatory, not advisory

Clause 7.1 requires risk control option analysis in a defined order of priority:

1. Inherently safe design and manufacture.
2. Protective measures in the device itself or in the manufacturing process — guards, interlocks, alarms, automatic shutdown.
3. Information for safety — labelling, instructions for use, warnings — and, where appropriate, training.

Two consequences follow that a risk table does not capture. First, jumping to option 3 requires a documented rationale that options 1 and 2 were considered and found not practicable — an absent rationale is a finding regardless of how low the resulting risk score looks. Second, information for safety does not reduce the probability of harm; treating a warning as a probability-reducing control and re-scoring the risk downwards on that basis is the single most common way a risk file inflates its own performance.

The EU takes the harder line explicitly. Annex I, Chapter I of Regulation (EU) 2017/745 (the MDR) requires manufacturers to establish, implement, document and maintain a risk management system (point 3) and sets essentially the same order of priority for risk control (point 4): eliminate or reduce risks as far as possible through safe design and manufacture; then adequate protection measures including alarms where necessary; then information for safety and, where appropriate, training. The MDR is emphatic that the third tier does not substitute for the first two.

ALARP or AFAP: the migration trap, stated carefully

This is the point on which secondary commentary is least reliable, so it is worth separating what is verifiable from what is not.

What the EU requires is not in doubt. MDR Annex I, Chapter I requires risks to be reduced as far as possible (AFAP) without adversely affecting the benefit-risk ratio. “As far as possible” admits no cost or practicability trade-off. That is a stricter test than as low as reasonably practicable (ALARP), which by construction permits a judgement that further reduction is disproportionate to the effort or cost involved. A manufacturer applying an ALARP-shaped acceptability policy in an EU submission is applying the wrong test, whatever the standard says.

What changed between the 2007 and 2019 editions is where commentary diverges. The 2007 edition carried an informative Annex D on risk concepts, including a D.8 discussion of ALARP and a “negligible risk” region. The third edition moved most of the informative annex material out of the standard and into ISO/TR 24971:2020 — that relocation is well attested and is consistent with FDA listing the technical report as a supportive publication. Beyond that, published commentary genuinely disagrees: some analyses state that the concept of ALARP was removed from both the standard and the guidance; others state that a note in the clause on management responsibilities still acknowledges ALARP, ALARA and AFAP as recognised approaches to acceptability criteria. We could not resolve this against the source text, because the standard is paywalled and iso.org blocks automated retrieval; see the verification note at the end of this page.

The operational conclusion does not depend on resolving it. If you are migrating a risk management file built under the 2007 edition, do not assume your acceptability policy transfers. Restate the policy explicitly under clause 4.2, and if the device is going to the EU, state it in AFAP terms with the benefit-risk qualifier from MDR Annex I — not in ALARP terms inherited from a 2007-era template. The transferable defect is the template, not the standard.

Benefit-risk determination is a written argument, not a score

Two distinct evaluations in the standard are routinely merged, and merging them is why benefit-risk records so often read as circular.

• Individual residual risk (clause 7.3, with 7.4). After the controls, is the residual risk for this hazardous situation acceptable against the criteria in the plan? If it is not, clause 7.4 requires a benefit-risk analysis: do the medical benefits of the intended use outweigh this residual risk? If they do, the risk may be judged acceptable — and the reasoning must be recorded. If they do not, the risk stays unacceptable and the design must change or the intended use must narrow.
• Overall residual risk (clause 8). After all risk control measures, is the residual risk of the device as a whole acceptable? This is not the arithmetic of the individual rows. Many individually-acceptable risks can combine — through the same user, the same procedure, the same failure mode of attention — into an unacceptable whole. A file that answers clause 8 with “all individual risks were found acceptable, therefore the overall residual risk is acceptable” has not performed the clause 8 evaluation.

A benefit-risk determination that will survive review has, at minimum: the medical benefit stated in terms a clinician would recognise (magnitude, probability, duration of the benefit — not “improves outcomes”); the residual risk stated in the same currency (severity and probability of the specific harm); the alternatives considered, including available alternative treatments or devices; the population in which the trade-off is being made; and the evidence base for each side, cited. Where the device is used in research rather than routine care, the significant-risk determination under 21 CFR 812 is a separate regulatory judgement with its own criteria and should not be conflated with the clause 7.4 record.

Note the scope limit that makes this necessary: ISO 14971 does not specify acceptable levels of risk, and states that it does not apply to clinical decision making. It obliges you to set criteria and to argue against them; it does not tell you where the line sits. Nobody outside your organisation set that threshold for you, which is exactly why the policy under clause 4.2 has to be defensible on its own terms.

What ISO/TR 24971:2020 adds where ISO 14971 is thin

This is the cross-walk that most treatments of the standard omit. ISO/TR 24971 is guidance — informative, not normative — so an auditor cannot raise a finding against the technical report itself. What an auditor can and does do is expect the rationale in your file to be consistent with it, because it is the published explanation of the intent behind clauses that the standard states in a single sentence.

Where 14971 is brief	What TR 24971 supplies
The risk management policy and the criteria for risk acceptability (clause 4.2 / 4.4). 14971 requires a policy and criteria but does not tell you how to derive them.	An annex devoted to the relationship between policy, acceptability criteria, risk control and risk evaluation — including how the state of the art, applicable regulatory requirements and relevant standards feed into where the criteria are set. This is the guidance that stops “criteria” from being an unsourced colour matrix.
Identification of characteristics related to safety and of hazards (clauses 5.3, 5.4). The standard requires identification; it does not enumerate.	The structured prompt list that used to sit in 14971’s own annex — questions about energy, biological and chemical hazards, operational and use-related hazards, information hazards — plus worked hazard/hazardous-situation examples. Using it as a checklist is the single fastest way to expose gaps in an existing hazard analysis.
Techniques for risk analysis. 14971 names no method as required.	Descriptions of the applicable techniques and, critically, their limits: preliminary hazard analysis (PHA), fault tree analysis (FTA), failure mode and effects analysis (FMEA/FMECA), HAZOP and HACCP, with guidance on which questions each can and cannot answer.
Information for safety (clause 7.1, third tier) and disclosure of residual risk.	Guidance on what information for safety can realistically achieve, how residual risk is disclosed to users, and why disclosure is not itself a risk reduction.
Security-related risk. 14971 addresses safety, and its probabilistic risk model does not transfer cleanly to security.	Guidance on the relationship between safety risk and security risk, and on handling security in a way that connects to — rather than contaminates — the safety file. Read alongside FDA’s recognition note above.
Application to IVD medical devices. IVDs are in 14971’s scope but the harm pathway is indirect: a wrong result, then a clinical decision, then harm.	IVD-specific guidance on hazards, hazardous situations and the false-result harm pathway. Essential if you are writing a file for a diagnostic assay rather than a therapeutic device — see also ISO 14155 for clinical investigation of devices, which is a different standard for a different obligation.
The role of product and process standards. 14971 does not tell you what compliance with a safety standard buys you.	Guidance on how conformity with an international product or process safety standard relates to risk control — and on why “we meet IEC 60601-1” is evidence toward specific risk controls, not a substitute for the analysis.

The structural point: TR 24971’s clause numbering mirrors 14971’s clauses 4 through 10, so it can be read side by side. If a clause of your risk management procedure was written from 14971 alone and consists of a restatement of the requirement, the corresponding TR 24971 clause is where the method you are missing is described.

FMEA is a technique, not a risk management file

Neither ISO 14971 nor ISO/TR 24971 mandates FMEA. It is one technique among several, and it has specific blind spots that matter for device risk:

• FMEA is bottom-up and single-fault. It starts from a component or process step failing, which means it structurally cannot find hazardous situations that arise with no component failing — normal use, use error, a correct result misread, a foreseeable environment of use.
• It handles combinations of failures poorly. Fault tree analysis is top-down from an undesired event and is the better instrument for combinations and for common-cause failure.
• RPN thresholds are not acceptability criteria. An RPN cut-off derived from multiplying ordinal scales has no defensible relationship to the criteria required by clause 4.4, and detectability — the D in RPN — is not part of 14971’s definition of risk at all. Using RPN as the acceptability test is one of the most reliably challenged constructs in a device risk file.

Used properly, FMEA feeds the hazard analysis; it does not constitute it. The standard’s requirement is that hazards and hazardous situations are identified for both normal and fault conditions — FMEA covers part of the second and almost none of the first.

Two neighbouring things called by similar names — disambiguated

Search results for FMEA and “risk assessment” mix three distinct practices that share vocabulary and share nothing else:

• Healthcare FMEA, as run inside a hospital quality programme, analyses a clinical process — medication administration, patient handoff — prospectively, and is typically documented within a quality assurance and performance improvement programme. If that is what you are looking for, see the QAPI plan, report and PIP write-up. It is a different unit of analysis: a care process, not a manufactured product, and it does not produce an ISO 14971 risk management file.
• Laboratory hazard risk assessment scores occupational hazards to workers at the bench — see the risk assessment matrix for laboratory hazards. The harm recipient is a worker, and the governing requirements are occupational, not device, regulation.
• ISO 14971 risk management analyses harm to patients, users and others arising from a device across its lifecycle. This page.

In pharmaceutical quality, the parallel framework is ICH Q9 quality risk management — closely related in philosophy, aimed at product quality and patient risk in manufacturing, and not a substitute for a device risk management file.

Clause 10: the part that keeps the file alive after release

Clause 10 requires a system to collect and review production and post-production information, and to act on it — with defined triggers for revisiting the analysis. This is the clause that converts risk management from a pre-market exercise into a lifecycle obligation, and it is the clause most likely to be nominally present and practically inert.

What “acting on it” has to include: whether previously unrecognised hazards or hazardous situations have appeared; whether an estimated risk is no longer supported by the field data; and whether the overall residual risk conclusion still holds. If any of those change, the risk management file is updated and the changes flow into CAPA where corrective or preventive action is warranted.

The regulatory hooks are on both sides of the Atlantic. In the EU, this clause is the standard’s meeting point with the MDR’s post-market surveillance obligations — the PMS plan, the periodic safety update report, and vigilance reporting. In the U.S., the same information stream drives complaint handling and medical device reporting — note the unfortunate collision of acronyms: “MDR” means the EU Medical Device Regulation in one sentence and Medical Device Reporting to FDA in the next. Traceability of the units in the field, via unique device identification, is what makes the post-market loop actionable rather than anecdotal.

How ISO 14971 sits alongside the QMS standard and the U.S. regulation

ISO 14971 requires a process, and explicitly does not require the manufacturer to have a quality management system — although risk management can be, and in practice is, integrated into one. The relationships are worth stating precisely because each of these is a separate obligation, not a rebranding of the others:

• ISO 13485 is the QMS standard. It requires risk management to be applied across product realisation and cross-references ISO 14971 directly, but it does not itself contain the risk management method. 14971 is where the method lives; 13485 is where the process is controlled, resourced and audited.
• 21 CFR Part 820 is the U.S. regulation, restructured under the Quality Management System Regulation to incorporate ISO 13485 by reference. That change alters how a U.S. inspection reaches risk management evidence; it does not change what 14971 requires of the file.
• The EU MDR’s general safety and performance requirements in Annex I are the legal requirement; EN ISO 14971:2019/A11:2021’s Annexes ZA and ZB are the map from the standard’s clauses to those requirements, which is what confers presumption of conformity when the standard is applied.
• GxP frameworks and ISO/IEC 17025 govern different objects entirely — regulated practice and laboratory competence respectively — and neither substitutes for device risk management. Confusing certification to a management-system standard with a regulatory approval is the same category error in all of these directions.

All of the above sit within the wider laboratory compliance and quality cluster, which maps how accreditation, GxP, device quality and data integrity frameworks relate to one another.

Where files actually fail: a review checklist

1. Acceptability criteria are stated in the risk management plan, sourced to a policy, and dated before the analysis they judge.
2. Every hazard traces to a hazardous situation with an explicit sequence of events — no two-column hazard/harm tables.
3. Both verifications exist for every risk control: implementation and effectiveness, separately evidenced.
4. Risk control option analysis records why the higher-priority options were not used, wherever information for safety is the chosen control.
5. No control that is purely informational is credited with reducing the probability of harm.
6. Clause 8 overall residual risk is a genuine whole-device evaluation with its own reasoning, not a summary of clause 7 outcomes.
7. Benefit-risk determinations name the benefit in clinical terms, cite evidence on both sides, and identify the population.
8. Risks introduced by risk control measures are analysed (clause 7.5) — the mitigation that creates a new failure mode is a recurring finding.
9. Security risk is assessed on an exploitability basis, not folded into the probabilistic safety matrix.
10. Clause 10 has named triggers, an owner, and dated evidence that reviews actually happened after release.
11. The file’s traceability holds after design changes — the commonest way a compliant file becomes non-compliant is a change control that updates the design and not the analysis.

What we could not verify, and where to check

Stated plainly, because the alternative is guessing:

• The text of ISO 14971:2019 and ISO/TR 24971:2020. Both are copyrighted and sold by ISO and its national members; iso.org blocks automated retrieval. Clause numbers and structural descriptions on this page reflect the standard’s published structure and are consistent across FDA’s recognition record and multiple independent technical analyses, but no wording here is quoted from either document, and readers who need the normative text must buy it from ISO or a national standards body (ANSI/AAMI in the U.S., BSI in the UK, and so on).
• Whether the 2019 edition retains any reference to ALARP. Commentary conflicts, as described above. We have not asserted either reading.
• The exact Official Journal citation for EN ISO 14971:2019/A11:2021. The amendment was cited in the OJ in 2022 by an implementing decision amending Commission Implementing Decision (EU) 2021/1182, the first list of harmonised standards for the MDR. EUR-Lex returned an automated-access challenge rather than the document on the date of writing, so we have not printed the amending decision’s number. Check the Commission’s current list of harmonised standards for Regulation (EU) 2017/745 before relying on a citation — the list is amended repeatedly and the version cited in the OJ is the one that confers presumption of conformity.
• MDR Annex I point numbering is given above for the risk management system (point 3) and the risk control priority order (point 4); the surrounding points are described rather than numbered, for the same access reason. The authoritative text is Regulation (EU) 2017/745 on EUR-Lex.

Everything attributed to FDA on this page — recognition number 5-125, recognition list 053, the 23 December 2019 entry date, “complete standard” extent, the identical ANSI/AAMI adoption, the ISO/TR 24971:2020 supportive-publication listing, and the cybersecurity note — was read directly from the FDA Recognized Consensus Standards database record on 26 August 2026 and is free to verify there.

Frequently asked questions

Is ISO 14971 mandatory?

Not as a standard — standards are voluntary. The obligation is mandatory. EU MDR Annex I requires a risk management system, and applying the harmonised EN version gives presumption of conformity with the relevant general safety and performance requirements. In the U.S., FDA recognises ISO 14971:2019 completely, so conformity can be declared in a premarket submission; risk analysis is expected in device submissions regardless of which standard you cite. In practice, a device manufacturer without a 14971-shaped risk management file is defending an unusual position in both jurisdictions.

What is the current version of ISO 14971?

ISO 14971:2019, the third edition, dated 2019-12. The European version is EN ISO 14971:2019/A11:2021, where A11 adds Annexes ZA and ZB for the MDR and IVDR without changing the requirements. ISO/TR 24971:2020, second edition, is the companion guidance.

What is the difference between ISO 14971 and ISO/TR 24971?

14971 is normative: it states what the risk management process must do, and it can be audited and certified against. TR 24971 is a technical report — guidance on how, including the hazard identification prompts, the analysis techniques and their limits, the derivation of acceptability criteria, and IVD-specific application. You can be found non-conformant against 14971; you cannot against TR 24971. You will still be expected to have read it.

Is a risk management file the same as a risk management report?

No. The file (clause 4.5) is the whole traceable record set maintained across the lifecycle. The report (clause 9) is the pre-release review output that concludes the plan was implemented and overall residual risk is acceptable. The report is one item inside the file.

Does ISO 14971 require FMEA?

No. It requires that hazards and hazardous situations be identified and risks estimated; it names no mandatory technique. FMEA is bottom-up and single-fault, so it cannot by itself satisfy the requirement to consider hazards arising in normal use with no component failing. RPN thresholds are not acceptability criteria under clause 4.4.

What is the difference between ISO 14971 and ISO 13485?

14971 is the risk management method for a device; 13485 is the quality management system for the organisation making it. 13485 requires risk management throughout product realisation and points at 14971 for how. Certification is to 13485; 14971 conformity is declared and evidenced in the risk management file.

What does “as far as possible” mean in practice?

It means risk reduction is not subject to a cost-versus-benefit trade-off in the EU: MDR Annex I requires risks to be reduced as far as possible without adversely affecting the benefit-risk ratio. The qualifier is about the benefit-risk ratio, not about expense or convenience. A policy written in ALARP terms — permitting a judgement that further reduction is not reasonably practicable — applies a different and weaker test.

Where can I read the text of ISO 14971:2019?

It has to be purchased, from ISO or a national member body (ANSI or AAMI in the U.S., BSI in the UK). FDA’s Recognized Consensus Standards database entry is free and gives the recognition number, extent, scope abstract and supportive publications, but not the standard’s text.

Related CASRAI resources

• Laboratory compliance and quality — the cluster hub, including how device quality, GxP and accreditation frameworks relate.
• ISO 13485 — the device QMS standard that cross-references this one, clause by clause.
• 21 CFR Part 820 and the QMSR transition — the U.S. regulation and how it now incorporates ISO 13485.
• Software as a medical device — where the security-versus-safety risk model distinction bites hardest.
• Human factors and usability engineering — use-related risk analysis and reasonably foreseeable misuse.
• 510(k) vs PMA — what each premarket pathway expects in the way of risk evidence.
• IDE and the significant-risk determination — the separate regulatory risk judgement for investigational device studies.
• ICH Q9 — the pharmaceutical parallel to this standard.
• Unique device identification — what makes the clause 10 post-market loop traceable.