---
title: The Risk Management File: Contents and Organisation
description: Risk management file contents MDR requires: plan, analysis, evaluation, controls, residual risk, verification, PMS feedback, report. Structured as a living set.
authors: Tibor Zechmeister, Felix Lenhard
category: Risk Management Under MDR
primary_keyword: risk management file contents MDR
canonical_url: https://zechmeister-solutions.com/en/blog/risk-management-file-contents
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# The Risk Management File: Contents and Organisation

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **The risk management file is not a single document. EN ISO 14971:2019+A11:2021 Clause 4.5 defines it as the set of records and other documents that are produced by the risk management process, traceable to the requirements in Clauses 4 through 9. For a compliant MDR file that means plan, analyses, evaluations, controls, residual risk, verification records, benefit-risk statement, production and post-production information, and the final risk management report, all organised for traceability.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- EN ISO 14971:2019+A11:2021 Clause 4.5 defines the risk management file as the set of records and documents produced by the risk management process.
- The file is not one document. It is a structured set with traceability from hazard to harm to control to verification to residual risk to report.
- Tibor's worst audit encounter in this area: an entire company convinced that four PowerPoint slides constituted risk management. The four slides were about 5% of what ISO 14971 actually requires.
- The file is a living artifact. It updates when the design changes, when complaints arrive, when PMS data shifts probabilities, when new standards apply.
- Traceability is the audit test. An auditor who cannot trace a single hazard end to end will find the file non-compliant regardless of its page count.
- MDR Annex II §5 requires the benefit-risk analysis and risk management results to live in the technical documentation, which means the file feeds directly into the document the notified body reviews.

## Why this matters

Tibor keeps the four-slide story close, because it captures everything wrong with how risk management gets treated in early-stage MedTech. The company was past startup. They were making an optical medical device. When the risk management approach was requested, the founder handed over four PowerPoint slides. The slides said, in essence: "do an Excel sheet with a risk analysis, mark each line tolerable or not tolerable, and you are done". The founder was not trying to deceive anyone. The founder genuinely believed that was risk management.

That is perhaps 5% of what EN ISO 14971:2019+A11:2021 actually requires. The worst part was not that the approach had slipped past anyone. The worst part was that the entire company had organised itself around the belief that four slides and an Excel line item per hazard was the full job. Every downstream decision was built on that foundation. Rebuilding it cost months.

The risk management file is the antidote. Not because it is long, but because it is structured. The file forces the team to produce and maintain a traceable set of records. You cannot fake traceability. Either the hazard connects to the analysis, the analysis connects to the control, the control connects to the verification, the verification connects to the residual risk, and the residual risk feeds the report, or it does not. An auditor with thirty minutes can determine which.

## What MDR actually says

MDR Annex I §3 establishes the risk management system requirement across the whole lifecycle and demands that it be documented. MDR Annex II §5, the technical documentation requirements, then requires the technical file to contain information on the benefit-risk analysis referred to in GSPR 1 and 8 and on the risk management as referred to in Annex I §3. In other words, the risk management file must exist, must be complete, and must feed the technical documentation that the notified body reviews.

EN ISO 14971:2019+A11:2021 Clause 4.5 defines the risk management file itself. The manufacturer must establish and maintain a risk management file. For each identified hazard, records and documents produced by the risk management process must be traceable in that file to: the risk analysis, the risk evaluation, the implementation and verification of risk control measures, and the evaluation of the acceptability of any residual risks. The clause does not prescribe a single format. It prescribes traceability.

Annex ZA of the A11:2021 amendment ties the file back to the MDR GSPRs. Every GSPR conclusion in the technical documentation should be supported by a traceable thread through the risk file.

## A worked example

Consider a startup building an electromechanical infusion assist device. The team produces the following records through the ISO 14971 process. A five-page risk management plan. A use specification document decomposing the device into cleaning, setup, normal use, alarm response, and disposal. A hazard list with 94 entries covering mechanical, electrical, software, usability, biocompatibility, environmental and cybersecurity hazard types. A risk estimation table giving severity, probability and initial risk for each hazardous situation. A risk control implementation log linking each residual risk above the acceptability threshold to a specific design choice, protective measure or information element. A verification matrix linking each control to a design verification test, a process validation, or a usability summative result. A residual risk table showing post-control risk for each hazard. A benefit-risk statement drawing on clinical evaluation data. A production and post-production monitoring log tied to PMS data sources. A signed risk management report.

That is the file. Eleven linked artifacts. The infusion startup that tried the four-slide approach would produce zero of those artifacts. The auditor reviewing the file starts by picking three random hazards from the list and tracing each one end to end. If the three traces complete in under ten minutes, the file is credible. If any trace breaks, the whole file is suspect until proven otherwise.

Felix's coaching rule: build the traceability on the first pass. Retrofitting traceability into an existing pile of documents costs five times what building it in from the start costs. The team that builds traceability as a habit produces a file that survives audits without rework.

## The Subtract to Ship playbook

The file is a structured set. Structure it once, populate it as the process runs, maintain it as the device lives. Felix's minimum file index has twelve entries.

**1. Index and revision history.** A one-page document listing every artifact in the file with its current revision and date. The first thing the auditor asks for, the first thing the team should hand over.

**2. Risk management plan.** The device-specific plan written before the analysis starts. Covered in detail in the companion post on writing a risk management plan.

**3. Use specification / intended use document.** A decomposition of the device into every real-world procedure: installation, cleaning, normal operation, alarm handling, transport, disposal, reasonably foreseeable misuse. This is the document that feeds credible hazard identification. A use specification that only covers the marketing pitch is the source of half of all missed hazards.

**4. Hazard and hazardous situation list.** Every known and foreseeable hazard, linked to the sequences of events that could produce harm. Multidisciplinary team input is visible in this document by design. A hazard list produced by one engineer is a hazard list that is missing the biocompatibility and the use-environment hazards.

**5. Risk analysis table.** Severity category, probability category, initial risk estimate for each hazardous situation. Rationale for the probability estimate. This is where spreadsheets are appropriate, but the rationale column is where the spreadsheet becomes a document instead of a score.

**6. Risk control implementation records.** For each risk above the acceptability threshold, the control measure, the level in the hierarchy (inherent, protective, information), and the justification for why a higher level of the hierarchy was not achievable. Tibor's audit discipline: read the justification column. If the column is empty, the controls have not been thought through.

**7. Verification records, by traceability.** A matrix linking each control to verification evidence. Design verification test reports. Usability summative results. Process validation reports. Software verification test reports for software controls. The matrix does not contain the evidence itself. It points to it. The evidence lives where it was produced.

**8. Residual risk table.** Post-control severity, probability and residual risk for each hazardous situation. Justification for acceptability under the MDR "as far as possible" rule, not just under the ISO 14971 line.

**9. Overall residual risk and benefit-risk statement.** The aggregate evaluation. The statement that overall residual risk is acceptable in view of the device's benefit, supported by clinical evaluation data and state-of-the-art comparisons.

**10. Production and post-production information plan and log.** How field data is collected, triaged, and fed back into the file. What data sources. What cadence. Evidence that the loop has actually run: complaint entries, PMS signals, software crash reports, vigilance reports, whatever applies. A file with no evidence of the post-production loop having run is a file that is dying.

**11. Risk management report.** The signed summary stating that the plan was implemented, that risks are acceptable, that overall residual risk is acceptable, and that appropriate post-production activities are in place. This is the document the auditor reads first.

**12. Change log.** Every update to the file tied to the trigger: design change, complaint, PMS signal, literature update, new standard edition. Dated and signed.

Two Subtract to Ship moves that Felix applies consistently. First, keep every artifact in one place with one index. Hunting across six SharePoint folders during an audit is a failure mode that starts with disorganised storage. Second, enforce one-hop traceability. Every document in the file points to the next document in the chain with a document ID and a revision number, not a "see the verification report" handwave. One-hop traceability is the discipline that keeps the file audit-ready between audits.

## Reality Check

1. Does the file have a single index page listing every artifact with current revision and date?
2. Pick three hazards at random from the hazard list. Can the team trace each one to analysis, control, verification, residual risk and report in under five minutes?
3. Does the use specification decompose the device into real-world procedures, or does it only describe marketed use?
4. Is every risk control tied to a verification record by document ID, not by narrative reference?
5. Is the residual risk evaluation justified under the MDR "as far as possible" rule?
6. Is there evidence that the post-production feedback loop has actually run, with complaint or PMS entries feeding file updates?
7. Is the risk management report signed, dated, and aligned with the current revision of every upstream artifact?
8. Could the team, today, hand the file to a notified body auditor without any preparation?

## Frequently Asked Questions

**Is the risk management file the same as the technical documentation?**
No. The technical documentation under MDR Annex II contains the risk management outputs: benefit-risk analysis, risk management summary, and references into the file. The risk management file is the working set of records that produces those outputs. The file feeds the technical documentation. They are two layers of the same system.

**Can the file be kept in an eQMS or does it need to be PDF?**
An eQMS is fine and often better. The auditor cares about traceability, completeness, signature integrity and version control. A well-configured eQMS gives all of those. A pile of PDFs in a shared drive rarely does.

**Does every change to the device require a file update?**
Every change that affects hazards, controls, verification, residual risk or benefit-risk analysis triggers a file update. Trivial changes that do not touch the risk picture are recorded in the change control system but do not force a file revision. The change log in the file is where those decisions are documented.

**What if the device uses off-the-shelf components?**
SOUP components, subassemblies and OEM parts are in scope. The file must address the hazards those components introduce and the controls that mitigate them. Supplier data, component datasheets, and supplier risk assessments feed the analysis. Outsourcing a component does not outsource the risk.

**How big is a typical risk management file for a Class IIa device?**
Tens of megabytes of linked documents is common. Hundreds of pages across all artifacts is common. Page count is not the metric. Traceability and current-ness are the metrics.

**What does a bad file look like at a glance?**
A single Excel sheet. Or a single PowerPoint deck. Or a folder of documents with no index. Or a file where the latest revision date is more than a year old and the device has been on the market the whole time. Tibor's four-slide story is the extreme case, but weaker versions of the same pattern are common.

## Related reading
- [The MDR Risk Management Process: Using ISO 14971](/blog/mdr-risk-management-process-iso-14971). the six-step lifecycle that produces the file.
- [Writing a Risk Management Plan Under MDR](/blog/risk-management-plan-iso-14971). the plan that anchors the file.
- [MDR Annex I GSPR Explained](/blog/mdr-annex-i-gspr). the requirements the file demonstrates conformity against.
- [Benefit-Risk Analysis in Technical Documentation](/blog/benefit-risk-analysis-technical-documentation). how the file feeds the Annex II documentation.
- [PMS Feedback into Risk Management](/blog/pms-feedback-risk-management). how post-market data keeps the file alive.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §3, GSPR 1 and 8, Annex II §5.
2. EN ISO 14971:2019+A11:2021, Medical devices – Application of risk management to medical devices, Clauses 4.5 and 4 through 9, Annex ZA.

---

*This post is part of the [Risk Management Under MDR](https://zechmeister-solutions.com/en/blog/category/risk-management) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*