MDR Annex I §4 and EN ISO 14971:2019+A11:2021 clause 7 require manufacturers to apply risk control options in a fixed order: first inherent safety by design, then protective measures, then information for safety. Startups routinely skip the first two tiers and rely on warnings in the instructions for use. Notified body auditors challenge this pattern every time they see it.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • MDR Annex I §4 requires manufacturers to reduce risks as far as possible without adverse impact on the benefit-risk ratio.
  • EN ISO 14971:2019+A11:2021 clause 7 defines three risk control options, applied in the order written: (1) inherent safety by design and manufacture, (2) protective measures in the device or in the manufacturing process, (3) information for safety and, where appropriate, training.
  • The order is mandatory, not preferential. A manufacturer cannot select option 3 because it is cheaper if option 1 or option 2 was technically feasible.
  • A warning in the instructions for use is the weakest control. Auditors treat heavy reliance on information for safety as a signal that the earlier tiers were never genuinely explored.
  • The risk management file must document, for every hazardous situation, which tiers were considered, why earlier tiers were rejected, and what residual risk remains after the chosen control.

Why the hierarchy exists (Hook)

In Tibor's audit practice, the most common finding against early-stage risk files is not a missing hazard. It is a risk control table where every single entry resolves with "warning in IFU". The device is dangerous in twelve ways, and twelve times the manufacturer has written a warning sentence. Nothing in the hardware changed. Nothing in the software changed. The control column is a wall of text.

That pattern tells an auditor two things at once. It tells them the team wrote the risk file after the device was already finished, which means risk management was not used as a design input. And it tells them the team does not understand the hierarchy that clause 7 of EN ISO 14971:2019+A11:2021 actually requires.

The three-step approach exists because decades of safety engineering, in medical devices and in other regulated domains, have shown that warnings are the least reliable control. Users do not read IFUs. Clinical environments are chaotic. The operator the manufacturer imagined is not the operator the device actually meets. A warning that must be read, understood, remembered, and acted on under time pressure is a control that fails when it is needed most. A hazard that was engineered out of the device cannot fail that way, because it is not there.

What MDR and ISO 14971 actually say (Surface)

MDR Annex I §4 sets the legal requirement. Manufacturers must reduce risks as far as possible without adversely affecting the benefit-risk ratio, and they must apply risk control measures in accordance with the principles of safety integrated into the design.

MDR Annex I §2 states that the solutions adopted by the manufacturer for the design and manufacture of the devices shall conform to safety principles, taking account of the generally acknowledged state of the art. When risk reduction is required, manufacturers shall control the risks so that the residual risk associated with each hazard is judged acceptable, applying risk control measures in the following priority order.

MDR Annex I §8 covers the specific case of information for safety: warnings, precautions and contraindications included in the instructions for use are considered the last resort and cannot substitute for design measures where those are feasible.

EN ISO 14971:2019+A11:2021 clause 7.1 then formalises the three options in the order Tibor's audit findings are measured against:

  1. Inherent safety by design and manufacture.
  2. Protective measures in the medical device itself or in the manufacturing process.
  3. Information for safety and, where appropriate, training to users.

Clause 7.1 is explicit that these options shall be considered in the order listed. The standard does not offer a menu. It offers a sequence.

The "as far as possible" ratchet

There is one trap worth flagging for startups who learn ISO 14971 in isolation from MDR. Clause 8 of ISO 14971 permits residual risks to be accepted once they fall below a defined acceptability criterion. The MDR does not allow that framing. MDR Annex I §4 requires reduction "as far as possible", not "as far as reasonably possible" and not "until the risk is judged acceptable". In Tibor's experience, a founder who copies the ISO 14971 text into the QMS without adjusting for MDR will fail a regulatory audit on this point alone. The risk control hierarchy is the mechanism that delivers "as far as possible". Skipping tiers breaks the mechanism.

A worked example (Test)

Consider a portable rehabilitation device with an electric motor that drives a patient-facing actuator. During internal testing the team identifies a hazardous situation: under fault conditions, the motor housing can exceed 60 degrees Celsius within ninety seconds, creating a burn risk on prolonged skin contact.

A naive first draft of the risk control column might read: "Instructions for use will warn the user not to touch the motor housing during operation."

Run that through the hierarchy.

Tier 1, inherent safety by design. Can the hazard be eliminated by design? The team re-examines the motor selection. A brushless motor with a higher efficiency rating produces less waste heat. The housing in steady-state testing peaks at 42 degrees Celsius, well below the burn threshold. Under fault conditions the peak drops to 51 degrees. The hazard has not disappeared, but it has been reduced by a design decision, not a warning.

Tier 2, protective measures. What protective measures can the device itself enforce? The team adds a temperature sensor on the motor housing with a software interlock. If the surface temperature exceeds 48 degrees Celsius, the motor is automatically disabled and the user is notified via the device display. The fault condition that produced 51 degrees is now caught at 48. The device does not rely on the user noticing anything.

Tier 3, information for safety. Only now, after the first two tiers are exhausted, does the IFU enter the picture. The instructions note that if the device displays an overheat warning the user should stop the session and let the device cool. This is not the primary control. It is a residual backstop to a control that was already engineered into the hardware and the software.

The risk management file records all three considerations. When the notified body reviews the file, they see a hazard that was controlled by tier 1 and tier 2, with tier 3 as a supplementary information element. That is a defensible residual risk. The original "warn the user" approach was not.

The Subtract to Ship playbook (Ship)

Felix has coached forty-four startups through early regulatory scoping, and the risk control hierarchy is one of the few places where the Subtract to Ship mental model maps directly onto a standard requirement. Subtract to Ship says: do not add a feature, a document, or a mitigation until you have exhausted the option of removing the underlying problem. Clause 7.1 of EN ISO 14971:2019+A11:2021 says exactly the same thing with different vocabulary.

The playbook has six steps.

Step 1. Write the hazard list before the design is frozen. If the risk file is a post-hoc document, tier 1 is already dead. Inherent safety by design requires that the design is still being decided when the hazard is identified. In practice this means a first-pass hazard analysis during concept design, not after the bill of materials is locked.

Step 2. For every hazardous situation, force yourself to propose a tier 1 control first. Write it down even if you reject it. "Eliminate the hazard by not using this voltage." "Eliminate the hazard by selecting a biocompatible material that does not require surface coating." "Eliminate the hazard by moving the processing off-device so the device never stores patient data." If the tier 1 option is rejected, the reason must be written in the risk file. A rejection without a reason is an audit finding.

Step 3. Only then move to tier 2. Protective measures are things the device does for itself: interlocks, guards, emergency shutdowns, fail-safe defaults, automatic monitoring. Tier 2 controls should be testable in verification. If you cannot define a test case for the control, it is not really a tier 2 control.

Step 4. Treat tier 3 as residual, not primary. Information for safety is real, it is legitimate, and it belongs in the IFU. But if more than roughly one in four of your risk controls is a tier 3 IFU warning, the auditor will ask why the earlier tiers were not applied. Felix has seen review-stage panics on exactly this question. Rewriting risk files in the two weeks before a notified body audit is a well-known failure pattern.

Step 5. Document the reasoning chain. For every risk control entry, the file should answer three questions: what was the tier 1 option, why was it rejected or adopted, and what residual risk remains. The chain is the audit artefact. The decision alone is not.

Step 6. Feed post-market surveillance back into the hierarchy. When a PMS signal changes probability or severity, the hierarchy gets re-run. A hazard that was previously controlled by tier 3 may need a tier 2 or tier 1 update. The risk management file is not a launch document. It is a live file for the entire product lifetime.

Reality Check

Work through these questions honestly against your current risk management file.

  1. Pick five risk control entries at random. How many are tier 1, tier 2, tier 3? If four or five are tier 3, the hierarchy was not applied.
  2. For each of those five entries, can you point to the written rejection reason for the tier 1 option? If the rejection reason is not in the file, the auditor will ask for it.
  3. When was the risk file first created? If it was after design freeze, tier 1 is structurally missing and the file needs a rebuild.
  4. Are your tier 2 controls testable in verification? Can you name the test case number for each one?
  5. Has any PMS signal in the last twelve months triggered a re-run of the hierarchy for an affected hazard? If PMS data flows in but the risk file never changes, the loop is broken.
  6. Does your risk file explicitly state that residual risks have been reduced "as far as possible" per MDR Annex I §4, not merely "as low as reasonably practicable"?
  7. If a notified body auditor opened your risk file tomorrow, which hazard would you least want them to focus on? That is the hazard to fix first.

Frequently Asked Questions

Is the order of the three risk control options really mandatory, or is it a recommendation? The order is mandatory. EN ISO 14971:2019+A11:2021 clause 7.1 states that the options shall be considered in the listed order, and MDR Annex I §4 and §2 reinforce the priority. A manufacturer who selects tier 3 without documenting why tiers 1 and 2 were rejected has not met the requirement.

Can a startup ever rely primarily on information for safety? Only when tiers 1 and 2 are genuinely not feasible. That feasibility assessment must be documented in the risk file with technical reasoning, not a one-line rejection. In Tibor's audit experience, genuine "tier 3 only" cases are rare for active devices and slightly more common for passive accessories where no design variable exists to engineer against.

How does the hierarchy interact with usability engineering under EN 62366-1:2015+A1:2020? Usability risks follow the same hierarchy. An intuitive design that prevents the use error is a tier 1 control. A device interlock that blocks the wrong action is tier 2. A warning in the IFU is tier 3. Training users is also tier 3 and should be treated as a last resort, not a first response.

What if a tier 1 change would make the device unaffordable for a startup? Cost is not an acceptable reason to skip a tier under MDR. The risk file must address technical feasibility and benefit-risk impact, not budget. If a tier 1 control is technically feasible but fiscally inconvenient, the correct answer is a different product strategy, not a weaker control.

How much detail does the risk file need for each rejected tier? Enough for a reviewer to reconstruct the reasoning. Two to four sentences per rejection is usually adequate, linked to the design input, design output, or verification record that supports the decision.

Does the hierarchy apply to manufacturing process risks as well? Yes. Clause 7.1 of EN ISO 14971:2019+A11:2021 explicitly includes protective measures in the manufacturing process as a tier 2 option. A sterilisation cycle interlock, for example, is a tier 2 control for a manufacturing hazard.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §2, §4, §8.
  2. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices, clause 7 (risk control).
  3. EN 62366-1:2015+A1:2020, Medical devices, Application of usability engineering to medical devices (cross-reference for use-error hierarchy).