The Workbench · Craft

A warning label is the risk control of last resort

A risk file that closes most of its hazards with a warning in the instructions for use looks tidy on paper — every row has a control, every control has a citation to the instructions. ISO 14971:2019 Clause 7.1 doesn't let a warning stand in as an equal alternative to a design change or a physical safeguard. It ranks the three kinds of control in a fixed order, and asks a risk file to show its work climbed that order before settling on the bottom rung.

A priority order, not a menu

ISO 14971:2019 Clause 7.1 requires a manufacturer to identify risk control measures adequate to reduce each unacceptable risk, and it names three options in a fixed order of priority: inherently safe design and manufacture; protective measures in the device itself or in the manufacturing process; and information for safety — labelling, instructions, warnings — along with training where appropriate. The order isn't a suggestion for how to think about the problem. If a design change can eliminate or reduce a hazard at the source, the clause requires that option to be used ahead of a guard, an alarm, or a warning, and a protective measure has to be considered ahead of relying on information alone. A risk file that lists a warning as the control for a hazard a design change could have addressed hasn't chosen a weaker option among equals — it's skipped a tier the clause put ahead of it.

Skipping a tier has to be justified, not just noted

The hierarchy only works if “not practicable” means something more than convenient. Where a manufacturer moves past inherently safe design to a protective measure, or past a protective measure to information for safety, the file needs to show why the higher-priority option wasn't available — a cost or a schedule pressure doesn't answer that question the way a genuine design or physics constraint does. EU MDR's Annex I, point 4, states the identical three-tier order for devices under CE marking, in the same sequence — eliminate or reduce through safe design, then adequate protection measures including alarms where necessary, then information for safety and training — which means a risk file built to satisfy ISO 14971 answers this same question for the GSPR table's own risk-management row without having to reason through the priority order twice under two different names.

Information for safety is still a control, with a cost

Labelling a hazard's control as “information for safety” doesn't remove it from the risk file's accounting the way it can feel like it does. A warning still leaves a hazard's probability of harm dependent on a user reading, understanding, and acting on it correctly every time — a dependency neither an inherently safe design nor a physical guard carries. A warning in the instructions for use is only doing its job as a risk control if the file can show the residual risk it leaves behind was evaluated on that basis, not assumed away because the warning exists. A device whose risk file leans heavily on tier-three controls is a device whose aggregate residual risk carries more of that user-dependent uncertainty into the overall benefit-risk judgment Clause 8 has to make once every hazard's own acceptability call is in.

A control can create the next hazard on the list

Clause 7.5 requires evaluating the risks a control measure itself introduces or changes — a guard that creates a new pinch point, a software interlock that adds a failure mode of its own, an alarm threshold tuned so aggressively that operators learn to ignore it. Implementing a control isn't the end of that hazard's entry in the file; it can be the start of a new one, run back through the same analysis, evaluation, and control sequence as any hazard identified from scratch. A risk control record that closes a hazard the moment its control is implemented, without checking what the control itself might have introduced, has skipped a step the clause names explicitly rather than leaves implicit.

Where this meets the rest of the file

The priority order in Clause 7.1 is what a risk management file's own traceability chain has to be able to show for each hazard — not just which control was chosen, but that it was the highest-priority option available, or a documented reason why it wasn't. A risk-control worksheet built around the three-tier hierarchy, the justification a lower tier requires, and the follow-on check for risks a control measure introduces is previewed in the launch catalog. If your program applies this hierarchy differently, the shelf takes that correction directly.

The Regulatory Toolkit launches soon — a free shelf of source-mapped templates, checklists and browser-only tools for regulatory teams. Get one email when it opens, or contribute a template.

All Workbench notes