The benefit-risk analysis is the reasoned conclusion, inside Annex II Section 5 of Regulation (EU) 2017/745, that the benefits of your device outweigh the residual risks for the intended patient population and the intended purpose. It is required by Annex I General Safety and Performance Requirements 1 and 8. It is fed by the risk management file built under EN ISO 14971:2019+A11:2021 and by the clinical evaluation required under Article 61 and Annex XIV. It has to be findable, traceable, and written as a determination — not as a description. Present it as a short, structured, cross-referenced document that names the benefits, states the residual risks, and declares the judgement. Auditors scrutinise this section harder than almost any other in the file.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • The benefit-risk analysis lives in Annex II Section 5 of Regulation (EU) 2017/745 alongside the risk management documentation. The two are linked but distinct deliverables.
  • The legal basis for the analysis is Annex I General Safety and Performance Requirements 1 and 8 — the obligations that risks must be reduced as far as possible and that residual risks must be acceptable when weighed against the benefits.
  • Inputs come from the ISO 14971 risk management file (residual risks) and from the clinical evaluation under Article 61 and Annex XIV (the clinical benefits and the clinical context for the residual risks).
  • The output is a determination, not a description. A benefit-risk analysis that reads like a summary has missed the point. It has to conclude.
  • Auditors sample this section heavily because the conclusion is where weak evidence gets exposed. A well-structured analysis of three pages will survive scrutiny that a loose twenty-page narrative will not.

A short story about the conclusion that matters

There is a file Tibor remembers because the analysis was technically present and substantively absent. The risk management file was thick. The clinical evaluation report was thick. Section 5 of the technical documentation contained many pages that described the risks, described the benefits, and described the process by which the two had been considered. What it did not contain was a conclusion. The auditor read through the section and asked a single question at the end: so, does the benefit outweigh the risk? The team answered yes. The auditor asked where in the document that sentence lived. It did not live anywhere. Everything implied it. Nothing stated it. The finding was written on the spot.

The Lower Austria three-person team we have mentioned in the pillar post on technical documentation under MDR got the opposite right. Their Section 5 was short. The risk file was the risk file — a full ISO 14971 deliverable. The benefit-risk analysis was a three-page document with a clear structure: the intended purpose restated, the benefits enumerated, the residual risks listed with cross-references into the risk file, the clinical context drawn from the clinical evaluation, and a final paragraph that stated the determination in one sentence. The auditor read it and moved on. There was nothing to dig for.

The lesson is the one the Annex II structure post repeats in every section. Structure beats volume. A three-page document that concludes beats a twenty-page document that describes.

What a benefit-risk analysis is under MDR

Under Regulation (EU) 2017/745, the benefit-risk analysis is not a standalone exercise invented by the industry. It is a specific deliverable required by the Regulation itself and rooted in two provisions of Annex I — the General Safety and Performance Requirements.

The first is Annex I GSPR 1. Devices must achieve the performance intended by their manufacturer and be designed and manufactured in such a way that, during normal conditions of use, they are suitable for their intended purpose. They must be safe and effective and must not compromise the clinical condition or the safety of patients, or the safety and health of users or, where applicable, other persons, provided that any risks which may be associated with their use constitute acceptable risks when weighed against the benefits to the patient and are compatible with a high level of protection of health and safety. The phrase "when weighed against the benefits" is the legal hook for the analysis.

The second is Annex I GSPR 8. The manufacturer's solutions for the design and manufacture of the devices must conform to safety principles, and risks must be reduced as far as possible without adversely affecting the benefit-risk ratio. This obligation ties the weighing to every design decision: you cannot cut benefit to reduce risk, and you cannot tolerate a risk that could be reduced further without penalty to the benefit.

The benefit-risk analysis sits in Section 5 of Annex II — the section on benefit-risk analysis and risk management. It is one deliverable inside a section that also contains the risk management file. The two are linked — the analysis depends on the risk file for the residual risks and depends on the clinical evaluation for the benefits — but they are not the same document and cannot be merged without losing the conclusion that Section 5 exists to produce.

How ISO 14971 feeds the analysis

EN ISO 14971:2019+A11:2021 is the harmonised standard for the application of risk management to medical devices. It defines the process by which manufacturers identify hazards, estimate and evaluate risks, implement risk controls, evaluate residual risks, and monitor effectiveness in production and post-production. The output of that process is the risk management file — the full documentary record of the risk management activities.

The risk management file is the input to the benefit-risk analysis. Specifically, the analysis draws on three outputs of the ISO 14971 process. First, the list of residual risks after all risk control measures have been applied — the risks that remain because they cannot be eliminated without compromising the intended use. Second, the overall residual risk evaluation — the judgement on whether the cumulative residual risk is acceptable. Third, the production and post-production information plan — the monitoring commitments that will update the benefit-risk judgement as real-world data arrives.

The benefit-risk analysis is not a replacement for the risk file and it is not a summary of the risk file. It is a separate document that reaches a conclusion the risk file alone cannot reach, because the risk file does not contain the benefits. Benefits come from elsewhere — from the clinical evaluation and from the intended purpose statement. The analysis is where the two streams meet.

The common mistake is to treat Section 5 as the risk file plus a paragraph. The paragraph is not enough. The analysis is a distinct deliverable that names the benefits, names the residual risks, states the clinical context for the trade-off, and declares the determination. We cover the full mechanics of the ISO 14971 risk management file under MDR separately — the point for this post is that the risk file feeds the analysis and the analysis concludes what the risk file cannot.

What clinical data the analysis draws on

The benefits in a benefit-risk analysis are clinical benefits. They come from the clinical evaluation required under MDR Article 61 and Annex XIV of Regulation (EU) 2017/745. The clinical evaluation is the systematic and planned process by which clinical data relevant to the device is continuously generated, collected, analysed, and assessed in order to verify the safety and performance of the device, including its clinical benefits.

The clinical evaluation report is the output. For the purposes of the benefit-risk analysis, the report supplies three things. It supplies the identified clinical benefits of the device for the intended patient population — not marketing claims, but clinical outcomes supported by evidence. It supplies the clinical context for the residual risks — how likely and how severe the residual risks are in the clinical setting, and how they compare with the benefits the patient receives. And it supplies the state of the art for the condition or intended use — so that the benefits and risks of your device can be weighed not in a vacuum but against the alternatives available to the patient.

A benefit-risk analysis that is not connected to the clinical evaluation report is a benefit-risk analysis without benefits. It cannot reach a defensible conclusion. This is why the clinical evaluation plan and report for MDR is written before or in parallel with Section 5, not after — the analysis needs the evaluation's outputs to exist.

For devices that rely on literature or on equivalence rather than on a new clinical investigation, the same logic holds. The clinical benefits in the analysis are the benefits the literature or the equivalent device demonstrates, and the analysis has to make explicit which source supplies each benefit. A clinical evaluation by literature route for MDR startups post covers that pathway in more depth.

The conclusion that matters

The benefit-risk analysis ends in a determination. Not "the benefits were considered." Not "the risks were weighed." A determination: the benefits of the device for the intended patient population under the intended purpose outweigh the residual risks, and the residual risks are acceptable.

The determination is one sentence. The rest of the document exists to support that sentence. If you strip the document down to its load-bearing structure, what remains is: here are the benefits, here are the residual risks, here is the clinical context in which they are weighed, therefore the determination is X. An auditor reading Section 5 should be able to find that sentence without searching.

The determination also has to be signed. Under your QMS document control, the person with authority to sign off on the determination — typically the person responsible for regulatory compliance under MDR Article 15, together with the quality and clinical leads — signs the benefit-risk analysis as a controlled document. An unsigned determination is a determination nobody is accountable for, and in a regulated file, accountability is part of the evidence.

How to present it in Annex II

A working benefit-risk analysis in Section 5 of Annex II has a repeatable shape. The shape is short, structured, and cross-referenced. Inventing a custom layout for every device is the fastest way to lose the auditor's attention.

Start with the intended purpose, restated verbatim from Section 1 of the technical documentation. Do not paraphrase. Paraphrasing introduces drift between the sections that the auditor will notice.

Continue with the identified clinical benefits, each one tied to a specific source in the clinical evaluation report. Not "the device improves patient outcomes" — name the outcome, name the population, name the source. Each benefit is a claim supported by a reference.

Follow with the residual risks, each one tied to a specific entry in the risk management file. Use the same risk identifiers the risk file uses — if the risk file calls it RISK-034, the analysis calls it RISK-034. Stable identifiers across documents are the single most important cross-reference discipline in Section 5 and in the file as a whole, as we cover in the post on cross-referencing in technical documentation.

State the clinical context for the trade-off. This is where the clinical evaluation report's assessment of the state of the art becomes part of the analysis. How do the benefits and residual risks of your device compare with the alternatives a patient in the intended population has access to today?

Then state the determination. One sentence. Unambiguous. Signed.

Finish with the post-market commitments. The analysis is not a permanent judgement. It is a judgement at a point in time that has to be re-evaluated when the post-market surveillance data changes the inputs. Section 5 should explicitly reference the Annex III post-market surveillance plan and state the triggers under which the benefit-risk analysis would be re-opened. The post on Annex III post-market surveillance technical documentation covers the PMS side in detail.

A benefit-risk analysis built on this structure typically runs three to ten pages for a startup device, depending on class and complexity. Longer than that and the structure is fighting the clarity. Much shorter and the cross-references are probably missing.

Common failures

The same handful of failures appears across the files we have reviewed in startup audits.

  • No conclusion. The document describes the analysis but never states the determination. The auditor asks "so what is the judgement?" and the team cannot point to a sentence.
  • Determination without support. The determination exists but the cross-references to the risk file and the clinical evaluation are missing or broken. The conclusion is an assertion, not an argument.
  • Risk file masquerading as analysis. Section 5 contains a thick ISO 14971 risk file and a single paragraph pretending to be the benefit-risk analysis. The paragraph does not state the benefits.
  • Benefits without evidence. The benefits listed in the analysis are marketing claims or intended purpose language, not clinical outcomes supported by the clinical evaluation report. The analysis fails on the benefit side before the risk side is even considered.
  • Intended purpose drift. The intended purpose quoted in Section 5 is slightly different from the one in Section 1 or on the label. The difference is small. It is still a finding, because the determination applies to one version and the label applies to another.
  • Unsigned determination. The benefit-risk analysis exists as an uncontrolled draft and is never signed, leaving accountability undefined.
  • No post-market trigger. The analysis is a point-in-time judgement with no commitment to re-evaluation. Annex III and the PMS process are not connected.
  • Loose narrative instead of structure. Section 5 is written as prose without identifiers, headings, or cross-references. Each paragraph makes sense. Nothing traces.

Every one of these is preventable with a disciplined template applied from the first draft.

The Subtract to Ship angle

Section 5 is one of the places where the Subtract to Ship framework for MDR pays off most obviously. The instinct is to pad Section 5 with background, with context, with descriptions of the methods used. The padding does not help the conclusion. The conclusion is helped by a short, structured document that names the benefits, names the residual risks, cross-references cleanly, and declares the determination.

Subtract everything that is not load-bearing for the determination. Subtract the methodological introductions — they belong in the risk management plan and in the clinical evaluation plan, not in Section 5. Subtract the restatement of the risk file — the risk file speaks for itself and Section 5 references it. Subtract the soft language around the determination — "the benefits appear to outweigh" is not a determination. "The benefits outweigh" is. The discipline to cut is the discipline that makes the conclusion survive scrutiny.

Reality Check — Where do you stand?

  1. Does your Section 5 contain a benefit-risk analysis as a distinct document, or is it folded into the risk management file?
  2. Can you point to a single sentence in the analysis that states the determination — the benefits outweigh the residual risks — unambiguously?
  3. Is every listed benefit tied to a specific source in the clinical evaluation report, with a working reference?
  4. Is every listed residual risk tied to a specific entry in the ISO 14971 risk management file, using the same identifier the risk file uses?
  5. Is the intended purpose in Section 5 quoted verbatim from Section 1, or has it drifted?
  6. Is the benefit-risk determination signed under your QMS document control, with the PRRC and the quality and clinical leads as signatories?
  7. Does the analysis name explicit triggers under which it would be re-opened, and do those triggers connect to the Annex III post-market surveillance plan?
  8. If the auditor asked you to walk the chain from the determination backward to a single residual risk and its clinical context, could you do it in under five minutes?

Frequently Asked Questions

Is the benefit-risk analysis the same as the risk management file? No. The risk management file is the output of the ISO 14971 process and documents hazards, risks, controls, and residual risks. The benefit-risk analysis is a separate deliverable that takes the residual risks from the risk file, combines them with the clinical benefits from the clinical evaluation report, and reaches a determination. Annex II Section 5 contains both, but they are distinct documents with distinct purposes.

Where in the MDR is the benefit-risk analysis required? Annex II Section 5 of Regulation (EU) 2017/745 specifies that the technical documentation contains the benefit-risk analysis and the risk management file. The substantive obligation — that residual risks must be acceptable when weighed against the benefits — is in Annex I General Safety and Performance Requirements 1 and 8.

How long should the benefit-risk analysis be? There is no required length. In practice, a disciplined analysis for a startup device runs three to ten pages. The analysis should be long enough to state the benefits, the residual risks, the clinical context, and the determination with working cross-references — and no longer. Padding is not evidence.

Does the benefit-risk analysis need to be updated after certification? Yes. The analysis is a point-in-time judgement that has to be re-evaluated when the inputs change. Post-market surveillance data, new clinical evidence, changes to the state of the art, new risks identified in the field, and design changes are all triggers for re-opening the analysis. The Annex III post-market surveillance documentation is where the re-evaluation mechanism lives.

Can the benefit-risk analysis rely on literature or equivalence for the benefits? Yes, under the same conditions that the clinical evaluation relies on literature or equivalence. If the clinical evaluation report establishes the benefits from literature or from an equivalent device under MDR Article 61 and Annex XIV, the benefit-risk analysis can use those benefits as its inputs. The analysis has to be explicit about the source.

Who signs the benefit-risk analysis? Under the QMS document control process, the analysis is signed by the parties with authority over the determination — typically the person responsible for regulatory compliance under MDR Article 15, together with the quality and clinical leads. An unsigned analysis is not a controlled deliverable and will not withstand audit scrutiny.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex II Section 5 (benefit-risk analysis and risk management), Annex I General Safety and Performance Requirements 1 and 8 (safety, residual risk acceptability, and the obligation to reduce risks as far as possible without adversely affecting the benefit-risk ratio), Article 61 (clinical evaluation), Annex XIV (clinical evaluation and post-market clinical follow-up). Official Journal L 117, 5.5.2017.
  2. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.

This post is part of the Technical Documentation & Labeling series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Tibor has reviewed benefit-risk analyses on both sides of the Notified Body table — as the lead auditor scrutinising the determination and as a founder writing it. The determination that matters is the one that survives both perspectives.