I used to open our ISO 14971 risk file and feel guilty. The spreadsheet had rows of mitigations, old test references, and half‑resolved notes from three product generations ago. To be fair, a compliant risk management system on paper is easy to show a notified body. The hard part is proving those risks are actively controlled and that mitigations are tested and fed by real field feedback. Naja — dusty records are a credibility problem, not a history lesson.
This walkthrough is what I do when I inherit an ageing risk archive and need to make it auditable, actionable, and tied to customer feedback and real tests. I also put together a short screencast demonstrating the steps (link above) — the article below explains the method and the reasoning I use when preparing for an audit or a PSUR/PMCF update.
The aim: linked, tested, and traceable risk items
Per ISO 14971 and MDR Annex I, risk control measures must be implemented and verified. In practice this means:
- Every mitigation in the risk file should point to a verification/validation artefact (test protocol, bench report, software unit test, clinical dataset).
- Known field issues and complaints should be linked back to the identified hazards and to any residual risk decisions.
- Changes that affect a risk control must create a traceable change record and, where needed, a CAPA and re‑verification.
If your risk file is an archive, the goal is to convert it into a living map that answers: what control exists, how was it tested, is it still effective in the field?
Quick triage (30–60 minutes)
Start with a lightweight pass to prioritise work. You won't re‑do everything at once.
- Filter the risk file for:
- Open or “monitor” items with no linked verification documents.
- Controls tied to obsolete drawings/firmware.
- Items referencing customer complaints, vigilance cases, or recent production changes.
- Create three buckets: Immediate (affects safety or field failures), Medium (uncertain evidence), Backlog (documentation only).
This triage is deliberately pragmatic. To be fair, you need to demonstrate prioritisation to a notified body more than perfection.
Make links: from hazard to test to field data
The single biggest audit failure I see is unsupported mitigations. Fix it by creating explicit links.
- For each Immediate/Medium item:
- Locate the verification artefact: bench test report, software regression test, clinical evaluation appendix, or a supplier QMS certificate.
- Annotate the risk file with the test name, date, and outcome. If the test doesn't exist, create a short test protocol and schedule it.
- Cross‑reference complaints and non‑conformances: paste the complaint ID, date, and short summary into the risk item.
- If a control was never verified, treat that as a gap. Raise a change request or CAPA depending on root cause.
In practice this means you end the audit conversation with a checklist: "here is hazard X, control Y, tested by report Z, and we saw no repeat complaints in the field." Genau.
Use CAPA and change control where evidence is weak
Dusty data often reveals weak controls, intermittent field signals, or supplier degradation. Those are CAPA workstreams, not filing tasks.
- If the field shows recurrence or the verification fails, open a CAPA with:
- Root cause hypothesis,
- Containment actions,
- Planned corrective actions (with owners and dates),
- Re‑verification plan and acceptance criteria.
- Keep CAPA documentation linked in the risk file: CAPA ID, date opened, status, closure evidence.
Granting resources to CAPA is always the hard part. Automated CAPAs and AI‑assisted triage can help you prioritise signals, but the corrective actions still need human judgement and sign‑off.
Tie to PMCF/PSUR and regulatory evidence
Once risk items are verified and field‑linked, fold them into your post‑market artefacts.
- Use the verified risk items and complaint trends as inputs to:
- PSUR narrative (for Class IIa/IIb devices) and any required safety reporting,
- PMCF plan updates or targeted studies if clinical uncertainty remains.
- Archive the traceability trail: risk item → test protocol → test report → complaint(s) → CAPA → PMCF/PSUR entry.
Notified bodies will look for this chain. If you show that a field signal triggered a CAPA and re‑verification, you are speaking their language.
Practical tips that save hours
- Add a “verification link” column in your risk spreadsheet (or link field in your eQMS). Make it mandatory for any risk marked “control implemented.”
- Use change impact mapping (your eQMS should have a Change Impact Mapping tab) to see which risk items are affected when a BOM, firmware, or supplier changes.
- Create a small dashboard: number of unlinked mitigations, age of last verification, and open CAPAs with risk impact. This is gold in an audit.
- Keep notes short and factual: “test X executed 2025‑03‑12; result: pass; acceptance criteria met; no field recurrence.” Auditors read fast.
Connected workflow is not a magic trick — it’s paperwork that actually helps engineers find what to test next.
Expect pushback — and be ready for it
Engineers will say “we tested that ages ago” or “that field issue was a one‑off.” To be fair, often they are right. You need evidence.
- If evidence exists but is hard to find, put a process in place: move test reports into a central controlled folder and link them to the risk item.
- If evidence does not exist, insist on a proportionate re‑verification. For software, that might be a regression test suite run and report; for hardware, a short bench test protocol and execution.
Closing the loop
The final step is discipline: every complaint or supplier deviation that could affect safety updates the risk file within your defined timeframe. If that sounds aspirational, lean on process automation — controlled assistance like automated CAPAs to flag risks — but maintain reviewability and sign‑offs.
I made a short walkthrough showing these steps in a live example (link above). It’s about the practical moves I use when my next notified‑body audit is three months away and the risk file looks ancient.
How do you prevent your risk archive from going back to sleep after you tidy it up — what small habit or control keeps the file alive in your team?
Top comments (0)