The setup
A few years back we had a routine supplier swap on a Class II delivery catheter component. The old supplier's stainless tube was being end-of-lifed. The new supplier offered a comparable grade with tighter tolerances, at lower cost. On paper: an easy change. In practice it kicked off what I'd call a risk assessment death spiral, and it's the mistake I keep coaching newer engineers out of.
What I thought the standard required
When the change request landed on my desk, my first instinct was that the risk management file had to be re-baselined. We had roughly 400 pages of hazard analysis, FMEA, risk-benefit reasoning, post-production data — all cross-referenced to the old supplier's material spec and process windows. If a single component changes, my mental model said, all of it gets touched.
So I started the work. Every hazard entry that mentioned "supplier X tubing" got flagged. Every FMEA line that referenced the old process got a re-evaluation. Every post-production row in the risk management report got reviewed against the new supplier's incoming data. Three weeks in, I was deep into a re-baselined file and still hadn't reached the FMEA appendix.
The cascade
The worst part wasn't the time. It was the cascading audit trail. Every paragraph I updated referenced three or four other documents. Every other document had its own approval workflow. The change control record alone ran into dozens of linked items. DHF cross-references needed re-validation. Training records for the team that had approved the old version — what was the plan there?
We weren't doing risk management anymore. We were doing paperwork gymnastics with a defensible-looking audit trail that didn't actually say anything new about risk. The defensibility was fake, and an experienced auditor would have spotted it.
What the standard actually says
The reset moment was rereading ISO 14971 carefully — clause 9 specifically, and the production and post-production loop it requires. The standard does not ask you to rewrite the risk management file when a component changes. It asks you to:
- Determine whether the change introduces new hazards, or changes the risk acceptability of existing ones
- Evaluate the impact on previously-implemented risk control measures
- Update only the affected sections, with a written rationale for what you did not update
- Feed the new supplier's post-production information back into the same loop
ISO 13485 reinforces the same thing from the purchasing side — clause 7.4 requires evaluation of changes that affect product, but it doesn't require a wholesale re-validation of every linked document.
The 400 pages didn't need a re-baseline. They needed an impact-based assessment with a written rationale for why the unchanged sections were still valid.
What I do now
Three things changed in how I handle supplier-driven risk file updates.
- Lead with an impact map, not a re-review. Before touching the file I sketch which hazards the change could plausibly affect — material biocompatibility, process variance, sterilization compatibility, mechanical performance. The list is usually short. That list drives the scope.
- Write the rationale up front. A one-page memo stating which sections the change affects, which it doesn't, and why. The memo is the actual deliverable the auditor wants to see, and it makes the rest of the work mechanical.
- Let the unchanged sections stay unchanged. Don't re-version them. Don't re-approve them. The audit trail gets dramatically cleaner when you can point at what changed, what didn't, and the documented reason for the call.
What I'd still like to figure out
The thing I haven't gotten comfortable with is how much evidence the "no impact" call actually needs. A short impact memo feels under-defended for a 400-page file. A long formal justification feels like the same death spiral from the other direction — volume that doesn't add defensibility.
How are you handling this in your own risk files — short impact memo, or a longer formal write-up? And how do you decide what level of evidence the "no impact" reasoning needs to hold up at audit?
Top comments (0)