How to read a risk management file

A risk management file is supposed to answer one question for every hazard a device could present: what could go wrong, what did you do about it, and how do you know the fix actually works? Reading one well means following that chain all the way through, not confirming that a risk analysis exists somewhere in the record.

What holds the chain together

Start with the hazard: a foreseeable sequence of events that could lead to harm. From there, the file has to estimate the risk (how severe the harm could be, how likely that sequence is), choose a control measure in the right order — inherent safety by design first, a protective measure second, information for safety only when the first two aren’t possible — and then verify that the control was actually built as intended before validating that it actually reduces the risk in practice. What’s left over is the residual risk, and it has to be judged against acceptability criteria that were written down before the analysis started, not adjusted afterward to match the result. Every one of those links has to hold for a reviewer or an auditor to trace a single hazard from start to finish without a gap. This file doesn’t stand alone: it threads through the design history file, and the use-related slice of it is exactly what a human factors validation report exists to prove for the tasks a real user could get wrong.

What a thin file looks like

A few patterns show up reliably in files that don’t survive a close read. A hazard is identified, but the control listed next to it doesn’t actually address that hazard — it addresses something adjacent and easier. A residual risk is marked acceptable with no stated acceptability criterion behind it, or with one that reads like it was written after the fact to justify the answer already reached. Verification evidence shows the control exists but never shows it working under realistic conditions, which confirms the wrong thing. And the file was never revisited after a documented design change, so a change that introduced a new hazard shows up in the design history but nowhere in the risk analysis that’s supposed to track it.

None of this is unique to risk management, and that’s exactly why it’s a useful test of a device team’s whole quality system. A broken link in the risk file is rarely an isolated problem — it’s usually a symptom of the same break showing up in verification, in change control, or in how postmarket data actually gets used.