What Auditors Look For in an ISO 14971 Risk Management File

Risk management files rarely fail because the team misjudged a hazard. They fail because the file cannot demonstrate that a process happened. An auditor is not primarily assessing whether your risk estimates are correct — they are testing whether the reasoning is complete, traceable, and still alive.

The file is a system, not a document

ISO 14971 does not require a single bound document. It requires that records demonstrating the whole process — plan, analysis, evaluation, control, overall residual risk, review, and production and post-production activity — exist and are traceable. In most companies they are scattered across a risk management plan, one or more FMEAs, a hazard analysis, design verification reports, the usability file, and a risk management report.

That distribution is entirely acceptable. What is not acceptable is being unable to navigate it. If an auditor picks one hazard and cannot follow it end to end without a guided tour from the person who wrote it, the file has a traceability problem regardless of how good the underlying engineering was.

Finding 1: broken traceability

The standard's logic runs along a specific chain, and auditors test it by picking a row and walking it:

Two links break most often. The first is the middle: files that jump straight from "sharp edge" to "laceration" without articulating the sequence of events that exposes anyone to it. Without that sequence, probability estimates have no basis — you are assigning a number to an event you never described.

The second is the end: a control listed as "mitigated by design" with no reference to the drawing, specification, or test report that proves it exists and works. Every control needs a pointer to objective evidence.

Finding 2: risk control options applied out of order

This is the most frequent substantive finding, and it is entirely preventable. ISO 14971 requires risk control options to be considered in a specific priority order:

1. Inherently safe design and manufacture — eliminate the hazard, or reduce its probability, by design.
2. Protective measures in the device itself or in manufacturing — guards, alarms, interlocks, fail-safes.
3. Information for safety — warnings, instructions for use, training.

The order is not advisory. A file in which a high-severity risk is controlled by a warning in the IFU, with no record that design and protective measures were considered and found impracticable, is a finding. Labelling is the weakest form of control because it depends entirely on a human reading and complying.

Finding 3: verification of effectiveness treated as one step

The standard requires two distinct verifications for each risk control, and files routinely conflate them:

• Verification of implementation — the control actually exists in the released design, process, or labelling. Evidence: a released drawing, an approved specification, the final IFU.
• Verification of effectiveness — the control actually reduces the risk it was intended to reduce. Evidence: a test result, a validation report, a usability study outcome.

Confirming that a warning was printed is implementation. Demonstrating that users notice, understand, and act on it is effectiveness — and for use-related risks, that is what a usability evaluation under IEC 62366 provides. A file that stops at implementation has answered only half the requirement.

Finding 4: risks introduced by risk controls

Controls are design changes, and design changes create hazards. An interlock can fail closed and prevent therapy. An alarm can contribute to alarm fatigue. A protective coating can introduce a leachable. Additional warnings can bury the critical one in noise.

The standard explicitly requires that risks arising from risk control measures be assessed, yet many files show controls added with no corresponding re-analysis. Auditors find this quickly by asking, of any control: "what new failure modes did this introduce, and where did you assess them?"

Finding 5: a thin overall residual risk evaluation

After all individual risks are controlled, the standard requires a separate evaluation of the overall residual risk of the device, against criteria defined in the risk management plan. This is not a sum, and it is not a restatement that every individual risk was accepted.

The question it answers is different: taken together, and in light of the device's clinical benefit, is the total residual risk acceptable? It should consider the cumulative effect of many individually acceptable risks, interactions between them, and the overall benefit-risk position — informed by clinical evidence, literature, and post-market data where available.

In many files this appears as a single sentence: "All individual risks have been reduced to acceptable levels; therefore overall residual risk is acceptable." That is a restatement, not an evaluation, and experienced auditors are alert to it. Where residual risk remains meaningful, a documented benefit-risk analysis is what carries the conclusion.

Finding 6: no production and post-production feedback loop

This is the most consequential systemic failure. ISO 14971 requires an active system to collect and review information from production and post-production — complaints, service data, CAPA, field performance, literature, similar devices on the market — and to feed it back into the risk management file, updating estimates and controls where warranted.

The tell is a file whose revision history ends at design transfer. If a device has been on the market for three years, generated complaints, and the risk file has not been revised, one of two things is true: either nothing was learned, or the loop is not working. Auditors reliably ask which.

What good practice looks like: complaint categories mapped to hazards in the risk file; a defined periodic review; a documented trigger for when post-market data forces re-estimation; and revision history showing the file has actually changed in response to real-world data. This is also where risk management and CAPA connect, and where an auditor tests whether your quality system is genuinely integrated.

Details from the 2019 revision that still trip people

• Risk reduction "as far as possible," not "as low as reasonably practicable." The shift away from the ALARP framing matters because reasonableness invited cost balancing. The current expectation is reduction as far as possible.
• Economic considerations are not a basis for accepting risk. "Not commercially viable to mitigate" is not an acceptable rationale in the file. Feasibility arguments must be technical.
• Benefit-risk analysis has a defined role. It is what you rely on when residual risk is not acceptable against your criteria but the clinical benefit justifies it — and it must be documented, not assumed.
• "Reasonably foreseeable misuse" replaces "abnormal use." A broader obligation: you are expected to anticipate predictable off-label handling, not only correct use.
• Acceptability criteria must be defined in the plan, in advance. Criteria that appear only in the conclusion invite the suspicion that they were reverse-engineered to fit the results.

A pre-audit self-check

Pick three risks from your file — the highest-severity one, one controlled by information for safety, and one added late in development. For each, try to answer without asking the author:

1. What is the hazard, the sequence of events, the hazardous situation, and the harm?
2. What are the severity and probability, and on what basis were they assigned?
3. Which control options were considered, and why was the chosen one selected over higher-priority options?
4. Where is the evidence the control was implemented? Where is the evidence it is effective?
5. What new risks did the control introduce, and where were they assessed?
6. Has any post-market data touched this risk? If so, where is that reflected?

If any answer requires a verbal explanation that is not written anywhere, that is precisely the gap an auditor will find — and it is far cheaper to close it now than during an inspection.

This article is general information, not regulatory advice, and is not a substitute for the standard itself. Risk management must be performed by competent personnel with reference to ISO 14971 and applicable guidance for your specific device and market.