Information for safety covers warnings, labels, instructions for use, and user training. Under MDR Annex I §8 and EN ISO 14971:2019+A11:2021, it is the third and weakest tier of the risk control hierarchy. Auditors challenge reliance on it whenever an inherent design control or a protective measure was technically feasible. Startups that lean on training or warnings as primary controls almost always lose that argument at audit.
By Tibor Zechmeister and Felix Lenhard.
TL;DR
- MDR Annex I §8 sets a strict priority order for risk control: inherent safe design first, protective measures second, information for safety last.
- EN ISO 14971:2019+A11:2021 clause 7.1 aligns with this hierarchy and treats information for safety as the lowest-priority option.
- Information for safety is a legitimate control, not a fake one. It appears on every device in some form. The problem is using it as a primary mitigation when an engineering control was available.
- Notified body auditors specifically probe the justification for each information-based control. They ask why a design change was not the answer.
- Tibor's audit experience is blunt on this point. The user training story is too simple as a concept, and treating training as a fix for a design flaw rarely survives an auditor's questioning.
- Training and warnings should reinforce good design, not substitute for it.
Why this matters
The most common risk management shortcut Tibor sees in startup files is a mitigation line that reads something like "user will be trained to avoid." The hazard is listed, the severity is rated, the probability is rated, the control is "training," and the residual risk is declared acceptable. The file moves on.
That line almost never survives a notified body audit without questions. The reason is not that training is forbidden. The reason is that the MDR and the harmonised risk management standard both place information-based controls at the bottom of a ranked hierarchy. An auditor who sees training listed as the sole control for a hazard will ask two questions, in order. Could the hazard have been designed out? If not, could a protective measure have been added? Only if both answers are genuinely no does training become an acceptable primary control.
A founder Felix coached had built a reusable instrument with a small but real burn risk from a heated tip. The risk file listed two controls. A warning label on the handle and a training module for operators. During stage 1 review, the notified body reviewer asked whether a mechanical guard or a temperature cutoff had been considered. They had not. The reviewer did not demand a specific solution. They demanded evidence that the team had considered engineering options and documented why they were rejected. The team had to reopen the risk file, run a design review, and implement a thermal cutoff. The warning label stayed. The training stayed. Neither was the primary control anymore.
What MDR and ISO 14971 actually say
MDR Annex I §8 sets the General Safety and Performance Requirement for risk control. Manufacturers shall, in the following order of priority:
- Eliminate or reduce risks as far as possible through safe design and manufacture.
- Where appropriate, take adequate protection measures, including alarms if necessary, in relation to risks that cannot be eliminated.
- Provide information for safety, including warnings, precautions, contra-indications, and, where appropriate, training to users.
The order is not a suggestion. It is a priority. The word priority in §8 is the word that auditors use when they push back on information-only controls.
MDR Annex I §23 (Information supplied with the device) sets the content requirements for labelling and instructions for use. It is extensive. This section is not the risk control mechanism itself. It is the specification for what the information-for-safety tier must contain when it is used. A warning that does not meet §23 is not even a valid third-tier control.
MDR Annex I §14 addresses risks related to the combination with other devices and around construction and interaction. Engineering-level language that reinforces the priority of inherent design.
EN ISO 14971:2019+A11:2021 clause 7.1 specifies the risk control option analysis. The standard requires that the manufacturer identify risk control measures using, in the stated order of priority:
- Inherent safety by design
- Protective measures in the device itself or in the manufacturing process
- Information for safety and, where appropriate, training to users
Clauses 7.2 and 7.3 cover implementation and verification of the selected control measures. Clauses 7.4 and 8 cover residual risk evaluation after controls are applied. The standard's text makes clear that information for safety is to be considered only after the first two options have been genuinely analysed and either implemented or shown to be infeasible.
Annex ZA of the EN version maps these clauses to the MDR GSPRs and reinforces the MDR's AFAP principle. The combination is blunt. If you can design it out, design it out. If you can add a guard, add the guard. If neither is feasible, document why and then rely on information for safety.
A worked example
A Class IIa home-use device delivers a measured dose of a cooling agent. The risk file identifies a hazard. If the user applies the agent to broken skin, local tissue damage can occur. The initial control proposal is a warning in the instructions for use and a contraindication label on the device itself.
Under clause 7.1 of EN ISO 14971:2019+A11:2021 and MDR Annex I §8, the analysis must proceed in priority order.
Option 1. Inherent safe design. Could the device be designed so that it cannot be applied to broken skin? A skin-contact sensor that detects impedance changes associated with open wounds is technically possible. The team considers this and finds it feasible but expensive and timeline-breaking for the first generation. They document the finding.
Option 2. Protective measure. Could a protective interlock be added without a full sensor? A mechanical cap that requires a two-step removal and exposes a clear contraindication pictogram is feasible. It is added. The cap itself becomes a second-tier control.
Option 3. Information for safety. A warning in the IFU and a contraindication on the label remain. They reinforce the second-tier control. They do not replace it. The IFU content is built to EN 62366-1:2015+A1:2020 usability requirements and validated through summative evaluation with intended users.
The final risk control record now has three entries. One rejected first-tier option with documented rationale. One implemented second-tier protective measure. One implemented third-tier information control. The residual risk evaluation, under clauses 7.4 and 8, then considers whether the remaining risk is acceptable with all three tiers in place.
This is what a defensible risk control record looks like. Not because training or warnings are wrong, but because the priority order was followed and documented.
The Subtract to Ship playbook
Felix's Subtract to Ship playbook for information-for-safety controls is built around four rules. Each traces back to the MDR and ISO 14971 text, not to opinion.
Rule 1. Never write "training" or "warning" as the first line of a risk control entry. If the risk control table lists training as the primary control for a hazard, the entry is almost certainly incomplete. The table should show the priority order explored. Design considered, outcome, protective measures considered, outcome, and information for safety as the remainder.
Rule 2. Document rejected design and protective controls explicitly. The notified body is not only checking what was done. It is checking what was considered and rejected. An empty rejection record looks like the options were never considered at all. A specific rejection record with technical rationale looks like a mature risk analysis. The auditor does not need to agree with the rejection. The auditor needs to see that the analysis happened.
Rule 3. Validate information-for-safety controls under EN 62366-1. Warnings that users do not notice are not controls. Contraindications that users do not understand are not controls. Usability engineering under EN 62366-1:2015+A1:2020 is how the manufacturer demonstrates that an information-for-safety control actually reaches the user. Summative evaluation with intended users is the test.
Rule 4. Update the hierarchy when post-market data contradicts the pre-market assumption. If a device is released with a training-based control and complaints show that users are still making the error, the risk file must reopen. The training did not work. The next question is whether a design or protective measure is now feasible. PMS data is not optional input. It is a trigger for reanalysis under clause 10 of EN ISO 14971:2019+A11:2021.
Tibor's experience with audit findings on this topic is consistent across sectors. The auditor's first probe is almost always the same. Show the rejected first-tier and second-tier options. Startups that have those records pass. Startups that do not, fail that line of questioning and walk out with a nonconformity on risk management that is very expensive to close.
Training is useful. Warnings are useful. Labels are useful. They are just not the primary place to absorb a known hazard when the engineering answer was on the table.
Reality Check
- For every hazard in your risk file with "training" listed as a control, can you point to the documented analysis of design and protective alternatives?
- Have you validated each information-for-safety control through EN 62366-1:2015+A1:2020 summative evaluation with intended users, not just internal reviewers?
- Are your warnings and IFU content specified to MDR Annex I §23 content requirements, with evidence of each required element?
- Have you checked that translated IFU versions carry the same warning weight as the source language, not a softened equivalent?
- Do your risk control records show the priority order explored, including rejected options with rationale, or only the selected control?
- Does your PMS feed back into risk control reanalysis when user errors show up in complaints or service data?
- If a notified body auditor asked why a given information-for-safety control was not replaced by a design change, could you answer in one sentence with a specific technical reason?
Frequently Asked Questions
Is training ever allowed as the only control for a hazard? Yes, but only when inherent design and protective measures have been genuinely analysed and documented as infeasible for specific technical reasons. The rarity of that situation is why auditors probe it hard.
What is the difference between a warning and information for safety? A warning is one form of information for safety. The category also includes precautions, contraindications, user training, IFU content, on-device labels, and on-screen alerts for software devices. MDR Annex I §23 sets content requirements for the labelling and IFU parts.
Do I have to use EN 62366-1 to validate my IFU? EN 62366-1:2015+A1:2020 is the harmonised usability engineering standard referenced by the MDR. Using it provides presumption of conformity with the usability-related General Safety and Performance Requirements. Alternative approaches are possible but the burden of proof shifts entirely to the manufacturer.
How does the notified body decide whether a rejected design option was "genuinely" rejected? Auditors look for specific technical rationale, design review records, and evidence that subject-matter experts were involved in the decision. Vague statements like "not feasible for our company size" are not sufficient. The test is technical feasibility, not commercial preference.
What is the relationship between clauses 7.1 and 7.4 of EN ISO 14971:2019+A11:2021? Clause 7.1 is the risk control option analysis where the hierarchy is applied. Clause 7.4 is the residual risk evaluation after the selected controls are implemented. Clause 8 is the overall residual risk acceptability. They form a sequence.
Can post-market data force me to replace an information-for-safety control? Yes. If post-market data shows that users are making the errors the information control was meant to prevent, the risk management file must reopen under clause 10 of the standard. The manufacturer then reassesses whether a design or protective control has become feasible.
Related reading
- The ISO 14971 Annex Z Trap. why the global ISO 14971 text alone is not enough under MDR.
- Benefit-Risk Analysis in the Technical Documentation. how residual risks roll up into the overall benefit-risk position.
- PMS Feedback into Risk Management. the loop that reopens information-only controls when they fail in the field.
- Writing MDR-Compliant Instructions for Use. the Annex I §23 requirements for the IFU itself.
- MDR Annex I GSPRs Overview. where §8 sits inside the General Safety and Performance Requirements.
Sources
- Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §8, §14, §23.
- EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices. Clauses 7.1, 7.2, 7.3, 7.4, 8, 10.
- EN 62366-1:2015+A1:2020, Medical devices, Application of usability engineering to medical devices.