The risk management report is the top-of-stack summary of everything in the risk management file. EN ISO 14971:2019+A11:2021 clause 9 requires it as the output of the risk management review. Notified body auditors open it before they open any other risk document, because it tells them in ten minutes whether the rest of the file is worth reading.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • The risk management report is required by EN ISO 14971:2019+A11:2021 clause 9 as the documented output of the risk management review.
  • It summarises that the risk management plan has been appropriately implemented, that the overall residual risk is acceptable, and that appropriate methods are in place to obtain relevant production and post-production information.
  • MDR Annex I GSPR 3 requires the risk management process to cover the entire lifecycle, and the report is the artefact that proves this cycle has been closed.
  • Auditors read the risk management report first. If it is coherent, they sample the underlying file. If it is vague or contradictory, they dig until they find the failure.
  • A good risk management report is short, traceable, signed, and dated. It points outward to the underlying evidence rather than repeating it.

Why auditors read the report first

Tibor has been a notified body lead auditor long enough to know that the first document he opens is almost never the risk management file itself. The file is often hundreds of pages of hazard analysis tables, fault trees, FMEAs, and risk control traces. You cannot audit that cold. You audit it by starting at the summary and working down.

The risk management report is that summary. In a well-managed submission, it reads as a clean, honest, short account of what the risk management process produced. Which risks were identified. Which were controlled to acceptable levels. Which residual risks remain and why they are acceptable. What the overall residual risk evaluation concluded. Whether the production and post-production information loop is in place. The report links to the underlying evidence but does not try to replicate it.

In a poorly managed submission, the report is either missing, auto-generated from a template, or filled with generic language that could describe any device. When that happens, Tibor's audit shifts from sampling to investigation. He opens the hazard analysis, cross-references it against the design outputs, and usually finds inconsistencies the team never noticed. The short report that took an afternoon to draft would have saved the file a week of findings.

Felix sees the same pattern from the startup side. Teams that treat the risk management report as an afterthought produce files that audit poorly, even when the underlying engineering work was sound. The report is the interface between the team's work and the auditor's interpretation. Get the interface right and the audit gets faster.

What EN ISO 14971 actually requires

EN ISO 14971:2019+A11:2021 clause 9 covers the risk management review. The review must take place before commercial distribution of the medical device. The output of the review is the risk management report, and clause 9 specifies that the report must establish three things.

First, that the risk management plan has been appropriately implemented. That is, the activities planned at the start of the project (clauses 4 through 8) actually took place, in the way they were planned, and any deviations are documented.

Second, that the overall residual risk is acceptable. This ties to clause 8, the evaluation of overall residual risk, and it ties to MDR Annex I GSPR 1 and GSPR 8, which require that risks be acceptable when weighed against benefits.

Third, that appropriate methods are in place to obtain relevant production and post-production information. This ties to clause 10 of EN ISO 14971 and to MDR Articles 83 to 86 on post-market surveillance. The risk management process does not stop at product release. The report has to confirm that the loop is in place to keep the risk management file current as field data arrives.

The report is signed by those with the responsibility and authority defined in the risk management plan. Typically this includes top management, because top management is responsible for ensuring adequate resources and competence for risk management under clause 4.2. A risk management report signed only by an engineer, with no top-management signature, is a clue to auditors that the risk management policy has not been operationalised.

MDR Annex II requires that the technical documentation include information on the risk management process. The risk management report is the document that satisfies this requirement at the summary level and provides the entry point into the full risk management file.

What the report must contain

Tibor uses a simple structure for every risk management report he reviews. It is not the only valid structure, but it covers every clause 9 requirement and every MDR Annex I touchpoint that matters.

Section 1. Scope and reference to the risk management plan. Which device, which version, which risk management plan revision. The report applies to a specific configuration, not to a family.

Section 2. Summary of hazard identification. A short statement of how hazards were identified, the disciplines involved (design, usability, clinical, manufacturing, service), and a pointer to the hazard analysis document.

Section 3. Summary of risk estimation and evaluation. The severity and probability framework used, the risk acceptability criteria defined in the risk management policy, and a pointer to the risk analysis records.

Section 4. Summary of risk control. Which controls were applied and in what order of priority (inherently safe design, protective measures, information for safety, per EN ISO 14971 clause 7 and MDR Annex I GSPR 4). Evidence that risk controls did not introduce new hazards (clause 7.5).

Section 5. Evaluation of overall residual risk. The conclusion from clause 8, explicitly weighing the residual risks against the evaluated benefits. Pointer to the benefit-risk analysis.

Section 6. Risk management review conclusion. The clause 9 determination that the plan was implemented, residual risk is acceptable, and post-production information methods are in place.

Section 7. Production and post-production information methods. What data will be collected, from which sources, with what cadence, and how it will be triaged back into the risk management file. This ties directly to MDR Articles 83 to 86 and the post-market surveillance plan.

Section 8. Signatures. Top management, risk management representative, and any other signatories required by the risk management plan.

A report that covers these eight sections, with real references to the underlying evidence, usually runs between eight and twenty pages. Anything much shorter is probably hiding something. Anything much longer has started duplicating the file instead of summarising it.

A worked example: how the report earns its keep

Consider a Class IIb active device. During development, the team ran two formative usability studies, a summative usability study, a bench verification campaign, and a clinical performance study. The risk management file contains a hazard analysis with 84 identified hazardous situations, an FMEA with 112 failure modes, a fault tree for the safety-critical control loop, and a risk-benefit appendix.

The auditor arrives and has two days for the risk management review. Day one opens with the risk management report. The auditor reads the eight sections in under an hour. He notes that the report states overall residual risk is acceptable and references the benefit-risk analysis. He notes that the post-production information section lists six data sources with defined cadences. He notes that the top-management signature is present and dated two weeks before the CE declaration date.

He then samples. He picks three hazardous situations from the hazard summary and traces them into the hazard analysis, into the design outputs, and into the verification records. Everything matches. He picks one residual risk flagged as acceptable and traces it into the benefit-risk analysis and into the clinical evaluation. The reasoning is consistent. He picks one post-production data source and checks whether the PMS plan (Annex III) actually references it. It does.

Day two is spent on other sections of the file. The risk management report survived the audit because it was accurate, short, and traceable. If any of the traces had failed, the audit would have reopened the report and the auditor would have stopped sampling and started investigating.

The Subtract to Ship playbook for the risk management report

Felix coached a Class IIa software startup through their first notified body audit. Their risk management file was solid, but their risk management report was a single paragraph stating that the device was safe. The team rewrote the report in two days using the eight-section structure above. During the audit, the lead auditor noted that the report was the clearest entry point he had seen in that review cycle. The rest of the file was sampled efficiently.

Subtract what is not a summary. Do not repeat the full hazard analysis in the report. Link to it. Do not repeat the full FMEA. Link to it. The report is a summary. Every paragraph that duplicates the file is a paragraph that dilutes the report.

Ship the report before the technical documentation summary. The risk management report feeds the technical documentation summary under MDR Annex II. If the risk management report is written last, the technical documentation summary tends to drift from it. Write the risk management report first, then derive the technical documentation summary language from it.

Sign with top management. A signed risk management report with only an engineer on it signals that clause 4.2 has not been operationalised. Get the top-management signature. If top management is not willing to sign, ask why.

Keep the report alive. The risk management report is not a launch artefact. Under EN ISO 14971 clause 10 and MDR Articles 83 to 86, the risk management process continues across the lifecycle. The report needs a revision history and should be updated whenever significant new post-production information changes the overall residual risk conclusion.

Reality Check

  1. Does your risk management report exist as a distinct document, or is it a paragraph at the end of the risk management file?
  2. Does it cover all three clause 9 determinations: plan implemented, overall residual risk acceptable, post-production information methods in place?
  3. Is it signed by top management, with a date that precedes the CE declaration?
  4. Does it reference the benefit-risk analysis explicitly, or does it assert acceptability without a link?
  5. Does it describe the production and post-production information methods concretely, with data sources, cadences, and feedback paths?
  6. Is it short enough that an auditor can read it in an hour?
  7. Does the technical documentation summary language for risk management derive from the report, or does it drift from it?
  8. When you last updated the risk management file, did you also update the report, or did the report stay frozen?

Frequently Asked Questions

Is the risk management report the same as the risk management file? No. The file is the full set of records generated by the risk management process. The report is the top-level summary. EN ISO 14971 distinguishes them explicitly in clauses 4.5 and 9.

How long should the risk management report be? For a typical startup Class IIa or IIb device, eight to twenty pages is normal. Much shorter usually means it is hiding something. Much longer usually means it is duplicating the file.

Who signs the risk management report? At minimum the risk management representative and top management, as defined in the risk management plan under clause 4.2. For startups, this often means the CEO and the RA lead.

Does the risk management report need to be in the technical documentation submitted to the notified body? Yes. MDR Annex II requires information on the risk management process to be included in the technical documentation, and the risk management report is the natural entry point.

How often should the report be updated? Whenever significant new production or post-production information changes the overall residual risk conclusion, or whenever the risk management file undergoes a material revision. Many teams also schedule a routine annual review.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I General Safety and Performance Requirements 1, 2, 3, 4, 8. Annex II (technical documentation). Articles 83 to 86 (post-market surveillance).
  2. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices. Clauses 4 (General requirements), 7 (Risk control), 8 (Evaluation of overall residual risk), 9 (Risk management review), 10 (Production and post-production activities).
  3. EN ISO 14971:2019+A11:2021, Annex Z relating to MDR Annex I General Safety and Performance Requirements.