Half an hour into a Technical File review last spring, a notified body auditor wrote four words in the margin that I keep taped to my monitor: "evidence of effectiveness?". That sentence has cost me more weekends than any single article of MDR.
Here is the uncomfortable truth about ISO 14971 in practice: most of the time we treat risk control measures like a checkbox. We add the alarm, update the risk table, tick the row, move on. The standard asks for something harder. Per ISO 14971:2019, clause 7.2, once a risk control measure has been implemented it has to be verified. Not implemented and assumed good. Implemented and proven good.
So "we added the alarm" is half the sentence. The other half is "and here is the test record proving the alarm fires when it should, at the threshold it should, and that the operator can actually perceive it." Skip that half and you have not closed the loop. You have just shifted the residual risk estimate onto vibes.
What verification actually means in 14971 terms
The standard's wording is deliberate and I would encourage anyone drafting a Risk Management File to read it with a highlighter and a coffee. Implementation is the act of putting the control in place. Verification is the activity that demonstrates the implemented control actually reduces the risk it was selected to reduce.
For a hardware control that might be a bench test, a type-test report, or a sample build. For a labelling or training control it might be a usability study, comprehension data, or a training completion rate above some defined threshold. For a software control, it is typically the software verification and validation activities linked to that specific risk control function — and yes, the auditor will want to follow the trace from the risk table row, into the software requirement, into the test case, into the executed result.
The hierarchy in 14971 still applies — inherent safe design first, then protective measures, then information for safety — but every rung of the ladder needs its own evidence.
The traps I have actually walked into
Three failure modes come up again and again when I look at Risk Management Files from companies that have just transitioned to MDR or are preparing for their first notified body audit under the new rules.
- Implementing a control that nobody can demonstrate actually mitigates the identified hazard. The alarm exists on the BOM. The test record that shows the alarm threshold and the failure mode it addresses does not exist, or exists for a different firmware revision.
- Verifying the control on a non-representative sample. A single bench unit tested in a clean lab by an engineer who designed it is not a substitute for verification. The auditor will want to know how representative the verification conditions were of the intended use environment.
- Burying the verification evidence somewhere unrelated. The risk table says "see verification report VR-042". VR-042 is in a different folder, references a different design version, and was last revised eight months before the control was even added. Traceability breaks the moment you decouple the risk row from the artefact that proves it.
Grant you, the third one is almost always a process artefact rather than malice — different teams, different document repositories, a QMS that is more of a shared drive than a system. But the auditor does not care why the evidence is unreachable. The auditor cares that it is unreachable. Genau that is the problem.
What "good" looks like
A defensible Risk Management File treats verification as a first-class activity rather than an afterthought. The pattern I try to build into every file I touch now looks roughly like this:
- Each risk control measure has a one-to-one link to a verification artefact — a test report, a V&V protocol result, a usability evaluation, a comprehension study.
- The verification artefact names the specific risk control it is verifying, references the design version or build it was performed on, and states a pass/fail criterion up front.
- Failures during verification become new risks, or feed back into the design iteration, rather than being quietly re-run until they pass.
- The risk table is updated only after verification has been completed, not after the design change has been implemented.
That last point matters more than people realise. If you update the risk reduction estimate and tick the row as "verified" while the test is still scheduled, you have told the auditor you have evidence you do not yet have. Even a placeholder field is fine if it is clearly a placeholder. A green tick is not.
The half-sentence that travels with you
In practice this means risk control is two activities stitched tightly together, not one activity with a follow-up email about the follow-up. The control exists. The control has been shown to do what you said it does. Both halves are written down, both halves are traceable to the same design version, and both halves survive the next software update, the next supplier change, and the next notified body audit.
I am still rebuilding older files to this standard and I will be for a while. The cost of doing it now is a fraction of the cost of doing it in front of an auditor with a pen. So ist das halt.
For those of you working through Risk Management Files day to day — what is the verification artefact that has been hardest for you to produce, and what made it hard? Is it the usability data, the software V&V linkage, or something else entirely?
Top comments (0)