I keep seeing the same shorthand in risk files: "Added alarm for high temp — complete." That sentence is only half the story. Under ISO 14971 (and as incorporated into ISO 13485), risk control isn't a design tick-box — it's a chain: choose the control, implement it, then verify it actually does what you intended. The "and here's the test record proving the alarm works" half is the part people skip until an auditor or root-cause investigation shows up.
I've worked on several Class II products where a single missing verification artifact turned a routine design change into a CAPA and weeks of rework. Here are practical things that helped me close that gap.
Why verification matters (practical compliance reasons)
- ISO 14971 requires you to reduce risk and evaluate residual risk; you can't evaluate reduction without evidence the control was effective.
- Notified bodies and the FDA expect traceable evidence: design inputs -> design outputs -> verification/validation.
- In the field, when a control fails (alarm didn't trigger, label misunderstood), the first question is: where's the verification that it worked in development?
Verification proves the control does what you expect; validation proves the overall intended use is safe. Both are needed, but they serve distinct purposes.
What “verification” actually looks like (by control type)
Don't treat all controls the same. Tailor the verification to the control class.
-
Hardware changes (e.g., new temperature sensor, alarm buzzer)
- Bench functional tests: stimulate sensor inputs across range, assert alarm thresholds and timing
- EMC/environmental checks if relevant
- Test protocol, raw data, calibrated equipment logs, pass/fail criteria
-
Software alarms and UI cues
- Unit/integration tests for alarm logic (CI where possible)
- HIL (hardware-in-loop) or simulated sensor feeds to trigger alarms
- Timestamped logs/screenshots showing alarm states and recoveries
- Test coverage notes and any manual exploratory test session records
-
Protective measures or procedural controls (e.g., lockouts, workflows)
- SOPs and training records paired with competency checks or observed use sessions
- Simulated misuse tests to show procedures fail-safe as intended
-
Information for safety (labels, IFU)
- Readability/comprehension tests or moderated usability sessions
- Marked-up copies of the final IFU showing the tested versions
- Evidence of version control and incorporation of test feedback
Minimal artifact checklist I require before closing a risk control
I use a lightweight template so nothing is left to "we tested it" vagueness:
- Clear statement of the risk control and intended effect (link to hazard ID)
- Verification protocol with:
- Acceptance criteria (quantitative where possible)
- Test setup and inputs (including calibration or simulation tools)
- Pass/fail rules (what counts as success)
- Executed test records:
- Raw data / logs / screenshots / videos
- Tester name, date, environment, equipment calibration references
- Test report summarizing results and verdict
- Traceability link in the Risk Management File (RMS) to the Design History File (DHF) artifact(s)
- Sign-off by reviewer(s) and versioned document control
Common failure modes I've seen (so you can avoid them)
- Acceptance criteria not defined. If you don't define objective pass/fail, you'll end up arguing in audits.
- Test executed in ideal lab conditions only. That misses integration failures — do system-level tests.
- Verification evidence stored as email or loose files with no trace to the risk ID. Use a unique ID and link it in the RMS.
- Skipped negative testing. You must also show the control behaves correctly under failure conditions (false positives/negatives).
- Human factors treated as “validation only.” If a label is the control, verify comprehension first.
Making verification less painful (practical tips)
- Write acceptance criteria while writing the risk control — it's easier up front.
- Automate what you can:
- Software alarm logic should have unit/integration tests in CI, with artifacts exported to your QMS or test repo.
- Parameterized test scripts speed up regression for hardware-in-loop runs.
- Create small verification templates per control type — saves rework and ensures calibration/equipment fields aren’t forgotten.
- Link artifacts by ID, not by file name — a traceability matrix or export from your eQMS makes audits smoother.
- Include calibration and environmental context in the record. An alarm may pass at 20°C and fail at 60°C; auditors will want the context.
Where this feeds into post-market and CAPA
When an incident points back to a failed control, your verification artifacts are the first line of defense. If you don't have them, you may have to:
- Re-execute verification under controlled deviation
- Open CAPA to investigate why controls weren't verified
- Potentially notify customers or regulators if the risk was underestimated
Documented verification shortens investigations and helps you prove that the issue was isolated rather than systemic.
Final thought
In a small QMS team, it's tempting to treat verification as paperwork. It really isn't — it's evidence that your risk strategy worked. Treat it like the product feature it is.
How do you link verification artifacts to risk controls in your eQMS today? Any automation patterns or templates you've found that make auditors and engineers both happier?
Top comments (0)