---
title: The Auditor's Guide to Reviewing Risk Management Files
description: Auditor review risk management file MDR: what a Notified Body Lead Auditor opens first, in what order, and what gets flagged. Tibor's own checklist.
authors: Tibor Zechmeister, Felix Lenhard
category: Risk Management Under MDR
primary_keyword: auditor review risk management file MDR
canonical_url: https://zechmeister-solutions.com/en/blog/auditor-guide-reviewing-risk-files
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# The Auditor's Guide to Reviewing Risk Management Files

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

> **When Tibor opens a risk management file as a notified body lead auditor, he checks five things in order. Is this a file or a one-page spreadsheet? Is the MDR "as far as possible" bar actually applied or is ISO 14971 Section 6 being used as a stop sign? Are the controls in the correct hierarchy order, or did the team jump to labels and warnings? Is post-market surveillance data genuinely flowing into the file? Is the benefit-risk conclusion a real analysis or a rubber stamp? If any one of those fails, the rest of the audit gets harder.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- Tibor's first check: is the risk management file a full file (plan, analysis, evaluation, controls, residual evaluation, report, feedback) or a spreadsheet dressed up to look like one?
- Second check: does the file apply MDR "as far as possible" under Annex I §4 or does it stop at ISO 14971 Section 6 "initially acceptable"? The second is a non-conformity.
- Third check: are risk controls in the correct hierarchy order under Annex I §4, with inherent design first and information for safety last?
- Fourth check: is there live evidence that PMS data under Articles 83 and 84 has triggered risk file updates in the last six to twelve months?
- Fifth check: does the benefit-risk conclusion cite real evidence of clinical benefit, including indirect benefits like time saved or improved triage, not just a rubber stamp?
- Knowing the auditor's review order lets founders build a file that passes on first reading.

## Why this matters

Tibor has audited hundreds of risk files across fifteen years as a notified body lead auditor. He has his own order. Most founders do not know what the order is. They assume an auditor flips through the document in the order the document was written. That is not what happens. Tibor opens the file and goes straight to the parts that most often fail. If those fail, the rest is examined under a harsher light. If those pass, the rest gets the benefit of the doubt.

Felix has watched founders spend weeks polishing the parts of their risk file that an auditor will glance at and ignore the parts the auditor opens first. Knowing the order is cheap information that changes the audit outcome.

## What MDR actually says

MDR Annex I §3 requires a documented risk management system across the full device lifecycle, updated based on production and post-production information. Annex I §4 defines the control hierarchy: eliminate or reduce risks as far as possible through safe design and manufacture, then take protective measures, then provide information for safety. Annex I §8 requires the overall residual risk to be judged acceptable when weighed against the benefits of the intended use.

MDR Articles 83 and 84 require a post-market surveillance system that actively and systematically collects data and feeds it back into the technical documentation, the risk management, the clinical evaluation, and the PSUR or PMS report.

EN ISO 14971:2019+A11:2021 is the harmonised standard. Annex ZA maps it to MDR and flags that the standard's Section 6 "initially acceptable" language is not sufficient under MDR.

Those are the provisions that drive the auditor's review order. Every check Tibor performs ties back to one of them.

## A worked example

A founder hands Tibor a risk file at stage 2 audit. Here is the walk-through, in the exact order Tibor opens things.

**Check 1 (first sixty seconds): is this a file or a checklist?** Tibor opens the table of contents. He looks for: risk management plan, hazard analysis, risk evaluation records, risk control records, residual risk evaluation, risk management report, post-production feedback records. Seven artefacts. If only two or three exist, the file fails the first check. Tibor notes it and moves on with lower trust.

**Check 2 (next five minutes): the "as far as possible" bar.** Tibor picks five hazards at random. For each, he looks at the controls column. If a hazard is marked "acceptable" with no controls and the text does not explain why further reduction was not possible, the file is applying ISO 14971 Section 6 as a stop sign. That is the single most common finding. Tibor writes it down immediately.

**Check 3 (next ten minutes): hierarchy of controls.** For each of the five hazards, Tibor checks whether the implemented controls follow the Annex I §4 hierarchy. Are any labels or warnings being used where an inherent design change was possible? Tibor's Q8 from the follow-up interview is this check. Safety by information is legitimate but weakest. Startups reaching for labels when design was available is a classic finding.

**Check 4 (next ten minutes): post-market feedback flow.** Tibor asks to see the version history of the risk file. When was it last updated? What triggered the update? Can the founder show a PMS record that fed back into a risk probability or severity change? If the last update was eighteen months ago and PMS data exists, the feedback loop is broken. Tibor writes the finding.

**Check 5 (next ten minutes): benefit-risk conclusion.** Tibor opens the risk management report and reads the benefit-risk section. Does it cite real clinical benefits, including indirect benefits where relevant (reduced waiting time, improved triage, reduced queuing) as Tibor's Q6 describes? Or is it a single paragraph saying "benefits outweigh risks"? A real analysis references the clinical evaluation, the residual risks, and the intended use. A rubber stamp does not.

By the end of forty minutes, Tibor has a clear view of whether the risk management file is genuine. The rest of the audit day confirms what the first forty minutes revealed.

## The Subtract to Ship playbook

Felix coaches founders to build the file in the order the auditor will review it. Build for Check 1 first. Then Check 2. Then Check 3. And so on.

**Build for Check 1: seven artefacts, no fewer.** Create a named document or section for each: risk management plan, hazard analysis, risk evaluation, risk controls, residual risk evaluation, risk management report, post-production feedback log. Seven is the minimum. Even if some are short, they have to exist. Tibor's trust test is satisfied in sixty seconds if all seven are named in the table of contents.

**Build for Check 2: kill the "acceptable" language.** Replace every "acceptable yes or no" column with controls documentation. For hazards where no further reduction was possible, write one sentence explaining why: technical infeasibility, greater risk introduced, state of the art limitation. Tibor's Q3: the Section 6 misread is the single most common finding. Close it by writing the justification explicitly for every row where no controls were implemented.

**Build for Check 3: hierarchy annotation per control.** For every implemented control, annotate which level of Annex I §4 it satisfies: (a) inherent safe design, (b) protective measure, (c) information for safety. If the annotation is (c) and the hazard is one where (a) or (b) was possible, document why. Tibor's audit finding rate on this check drops to near zero when the annotation is in place.

**Build for Check 4: a live PMS feedback log.** Maintain a log with date, PMS input, affected hazard, updated probability or severity, version of the risk file. Update at least quarterly. The log is the single piece of evidence that convinces Tibor the feedback loop is real. Tibor's Q9: the good case is continuous updates, the bad case is two or three year intervals.

**Build for Check 5: a real benefit-risk section in the report.** Write the benefit-risk conclusion as a full section, not a paragraph. Reference the clinical evaluation by section number. Name the direct benefits with quantitative data where available. Name the indirect benefits qualitatively where quantification is not appropriate. Name the residual risks that were judged acceptable. Tibor's Q6: quantitative alone is not always appropriate, but the qualitative framing still has to be documented.

**Build for Check 6 (the one Tibor adds late): traceability to Annex I.** A one-page map from every Annex I hazard family to the row or rationale in the file. Not regulatory required as a separate artefact, but a massive signal of quality. Tibor has never raised a finding on a file that had this map and stopped to admire the ones that did.

## Reality Check

1. Does the risk file have all seven named artefacts visible in the table of contents?
2. Can any "acceptable" language in the file survive the Annex ZA reading of ISO 14971?
3. Are all controls annotated with the Annex I §4 hierarchy level they satisfy?
4. Does the version history of the risk file show an update in the last six months triggered by PMS data?
5. Does the benefit-risk section of the risk management report cite the clinical evaluation by section number and name both direct and indirect benefits?
6. If Tibor picked five random hazards and traced each one from identification through control and residual evaluation, would every trace close?
7. Is the one-page Annex I traceability map present, even though it is not formally required?
8. Would the first forty minutes of a stage 2 audit give an auditor reasons to trust or distrust the rest of the day?

## Frequently Asked Questions

**Does Tibor actually follow this order every time?**
Yes. Fifteen years of audits produced the order. The first five checks surface the findings that matter. The rest of the audit confirms what those checks reveal. A file that passes all five is almost never found wanting elsewhere.

**What happens if Check 1 fails?**
The audit continues but with lower trust. Tibor spends more time on each subsequent check because the baseline confidence in the document system is lower. The audit takes longer. The findings rate is higher. The file that looked faster to produce has just cost more audit days than a proper file would have.

**Is the Annex I traceability map required?**
Not as a standalone document. MDR Annex I §3 requires the hazards to be identified, but does not prescribe a traceability table. Building one is voluntary. In Tibor's experience it pays back an order of magnitude in audit efficiency.

**How does this differ for Class I self-certification?**
Class I devices still have to meet Annex I §3 and §4. The depth of the file can be smaller, but the seven artefacts still have to exist. The auditor in a self-certification context is a future vigilance investigator or a market surveillance authority. The review order is the same.

**Can the plan and report be combined into one document?**
Technically yes, and for very small Class I devices Tibor has accepted combined documents. For anything Class IIa and above, the plan and the report serve different purposes at different points in the lifecycle. Separating them is the lower-risk choice.

## Related reading
- [The Notified Body Auditor's Perspective](/blog/notified-body-auditor-perspective): how Tibor approaches audits more broadly
- [Common MDR Risk Management Mistakes](/blog/common-risk-management-mistakes-iso-14971): the anti-patterns this review order catches
- [The MDR Risk Management Process: Using ISO 14971](/blog/mdr-risk-management-process-iso-14971): the full six-activity process

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §3, §4, §8, Articles 83-84.
2. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices. Annex ZA.
3. MDCG 2025-10 (December 2025), Guidance on post-market surveillance.

---

*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).*