Everyone who touches device design, software, labeling, or customer interaction needs baseline ISO 14971 literacy. That means the vocabulary (hazard, hazardous situation, harm), the MDR "as low as possible" ratchet from Annex I Chapter I, and the hierarchy of controls. Training has to be documented as competence evidence under EN ISO 13485:2016+A11:2021 clause 6.2, or a notified body auditor will treat it as if it never happened.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • Risk management is not a job title. It is a shared literacy that every contributor to the device needs at a working level.
  • The minimum curriculum covers EN ISO 14971:2019+A11:2021 vocabulary, the MDR Annex I Chapter I "as far as possible" reduction principle, and the risk control hierarchy (inherent safe design, protective measures, information for safety).
  • Training records are competence evidence under EN ISO 13485:2016+A11:2021 clause 6.2 and a standard audit sampling target.
  • Who needs it: founders, developers, software engineers, mechanical engineers, clinical, regulatory, quality, marketing, customer support, and anyone writing claims or instructions for use.
  • Felix has seen teams save weeks of rework by front-loading two hours of shared vocabulary before the first risk analysis workshop.
  • Training is not a substitute for engineered-out use errors. This is Tibor's Q7 lesson, and it applies to every training module ever written.

Why this matters

Tibor once reviewed the risk management approach of a mid-stage optical device company. The entire "approach" was four PowerPoint slides that said: do an Excel sheet with a risk analysis, mark each line tolerable or not tolerable, done. Maybe five percent of what EN ISO 14971:2019+A11:2021 actually asks for. The worst part was not that the file existed. It was that the whole company, not just one engineer, genuinely believed this was the correct way to do risk management.

That is a training problem, not a tooling problem. Nobody on the team had internalised the difference between a hazard and a hazardous situation, so nobody spotted the gap. A notified body auditor walked in, opened the competence records under EN ISO 13485:2016+A11:2021 clause 6.2, and found nothing connecting any team member to the risk management process. The file was fragile because the team was fragile.

Felix coaches founders on this constantly in Subtract to Ship sprints. The temptation is to hire one "risk person" and let that person own the risk file. It fails every time. Risks are created by the people making design decisions, writing code, drafting labels, and talking to customers. If those people do not speak the vocabulary, the risk file is always downstream of reality.

What MDR actually says

The MDR does not name training as a separate obligation, but it forces the issue in three places that founders should read together.

MDR Annex I, Chapter I, General Safety and Performance Requirements. The GSPRs require manufacturers to establish, implement, document, and maintain a risk management system, to eliminate or reduce risks as far as possible through safe design and construction, to take adequate protective measures, and to provide information for safety. This is the "as low as possible" ratchet that Tibor calls out as the single most misread part of risk management in startups. EN ISO 14971:2019+A11:2021 on its own follows an as-low-as-reasonably-practicable logic. The MDR does not. Annex Z of the harmonised version flags this exact deviation. Any team member who makes a trade-off decision needs to know the MDR ratchet is stricter than the raw standard.

MDR Article 10(9). Manufacturers must establish, document, implement, maintain, keep up to date, and continually improve a quality management system proportionate to the device risk class. EN ISO 13485:2016+A11:2021 is the harmonised route, and clause 6.2 of that standard requires personnel performing work affecting product quality to be competent on the basis of education, training, skills, and experience, with records maintained.

MDR Annex IX and the notified body audit. When an auditor samples competence, they want to see a linked chain: a job description or role definition that names risk management responsibilities, a training record showing the person received that training, evidence the training was effective (quiz, signed acknowledgement, observed application), and the person's signature on actual risk management deliverables. Break any link and the chain fails.

Plain-language translation: if your team cannot explain what a hazard is, the regulator does not care how good your template is.

A worked example

A four-person software-as-a-medical-device startup preparing for its first stage 1 audit. The device is a Class IIa symptom-triage app. The team: one CEO, one full-stack developer, one clinical lead (part-time physician), one external regulatory contractor. The regulatory contractor owns the risk file.

Before the audit, Felix runs a two-hour session with the full team. The agenda is the minimum curriculum the whole team shares.

Hour one, shared vocabulary. Hazard is a potential source of harm. Hazardous situation is a circumstance in which people, property, or the environment are exposed to one or more hazards. Harm is injury or damage to the health of people, or damage to property or the environment. A sequence of events turns a hazard into a hazardous situation into harm. The team rehearses this on three examples drawn from the app: a false-negative triage result, a server outage during a critical query, and a misread symptom list caused by a small font on a legacy Android device.

Hour two, the MDR ratchet and the hierarchy of controls. The team learns that "we decided the residual risk is acceptable" is not the same as "we reduced the risk as far as possible". They walk through the risk control hierarchy as Tibor teaches it:

  1. Inherent safety by design. Remove the hazard at source. The symptom-triage app cannot give a false-negative for a specific high-severity condition if that condition is hard-coded to always escalate to a human.
  2. Protective measures. If removal is impossible, add a protective mechanism. An automatic session timeout with a forced re-check of critical answers is a protective measure.
  3. Information for safety. Warnings, labels, and training materials for end users. This is last, not first.

Every team member signs the training log. The developer now refuses to accept a design decision that sits at level three when level one was available. That single refusal, repeated across a sprint, eliminates more risk than any audit ever will.

At stage 1, the auditor samples two competence records, walks the team through a risk on the file, and asks the developer to explain how the control was chosen. The developer passes because the vocabulary is real. That is what effective training looks like in an audit.

The Subtract to Ship playbook

Felix has seen enough founder-led risk management sessions to know that training does not need to be a two-day course. It needs to be concrete, recorded, and repeated. The playbook:

1. Define who needs training. Everyone whose work touches the device lifecycle. Founders, engineers (all disciplines), clinical, regulatory, quality, marketing, customer support, sales, and any contractor working inside the QMS. For startups that is typically the entire company. EN ISO 13485:2016+A11:2021 clause 6.2 applies to any person performing work affecting product quality, and risk management affects product quality by definition.

2. Write a one-page curriculum. Three sections: vocabulary, the MDR ratchet, the hierarchy of controls. Add a short fourth section on how to raise a new hazard when you spot one. Keep it to one page. A founder who cannot compress it to one page has not understood it yet.

3. Run the session, live. Two hours, not half a day. Use three real examples from the team's own device. Avoid generic textbook cases. The session lead walks through the vocabulary, then the team rehearses on the examples. The goal is that each participant can correctly say "this is a hazard, this is the hazardous situation, here is the harm, and here is where we sit on the control hierarchy" for one of their own device's risks by the end of the session.

4. Capture competence evidence. A dated training log with participant name, session title, curriculum reference, trainer name, and participant signature. A short written check (five to ten questions) that the participant completes and the trainer countersigns. Store both in the QMS under the competence records required by EN ISO 13485:2016+A11:2021 clause 6.2.

5. Link the training to job roles. Each job description should list the risk management responsibilities of that role. The training record closes the loop: this person holds this role, this role requires this training, this training was delivered on this date. An auditor can trace the chain in under a minute.

6. Repeat on changes. A new team member gets the session during onboarding, before they touch any design output. Any material change to EN ISO 14971 or to the device's intended purpose triggers a refresh for the whole team. Annual refresh is a reasonable cadence even when nothing changes, because vocabulary decays.

7. Treat training as the floor, not the ceiling. Tibor's Q7 lesson from the follow-up interview applies directly: training is not a substitute for engineered-out use errors. A device that requires extensive training to be used safely has failed the first level of the control hierarchy. The same logic applies internally. If your developers need constant reminding that a risk control must sit above level three, the curriculum is not the problem. The culture is. Fix the culture and the training becomes maintenance rather than rescue.

Reality Check

  1. Can every person on the team currently state the difference between a hazard, a hazardous situation, and a harm without looking it up?
  2. Does every team member know that EN ISO 14971:2019+A11:2021 alone is not sufficient under MDR Annex I, because MDR requires risk reduction "as far as possible" and the standard follows a different logic?
  3. Can every team member name the three levels of the risk control hierarchy in order?
  4. Do your job descriptions explicitly name risk management responsibilities for the roles that affect product quality?
  5. For every person on the team who touches design, do you hold a dated, signed training record with a linked competence check under EN ISO 13485:2016+A11:2021 clause 6.2?
  6. When a new hire joined last, did they receive risk management training before or after their first design contribution?
  7. When did the team last refresh its risk management training, and can you produce the record in under thirty seconds?
  8. If a notified body auditor asked your most junior developer to explain the risk control hierarchy using one real risk from the file, would they pass?

Frequently Asked Questions

Do we really need to train non-engineers on risk management? Yes. Marketing writes claims that shape the intended purpose and therefore the risk acceptance criteria. Customer support receives the post-market signals that feed the risk file. Sales makes representations about safety. All of these people are performing work affecting product quality under EN ISO 13485:2016+A11:2021 clause 6.2.

How long does baseline training need to be? Two hours for the initial session, repeated on onboarding and on any material change. Founders who try to stretch this into a two-day course usually lose attention by hour three and gain nothing.

What if our developers already took an EN ISO 14971 course at a previous job? Prior training counts as education and experience under clause 6.2, but you still need a record that names the current role and confirms the person has applied the standard to your device. A short session plus a signed acknowledgement closes the gap.

Does the training lead have to be a certified risk manager? No. The trainer has to be competent in the subject matter and documented as such. A founder who has genuinely read and applied EN ISO 14971:2019+A11:2021 can train the team on the basics. Tibor has seen this work cleanly at stage 1 audits.

Can we use an off-the-shelf e-learning module? An off-the-shelf module can be part of the record, but it cannot replace a session on your own device. Auditors want to see the team apply the vocabulary to the specific risks on the file, not generic examples.

What is the single most common training failure Tibor sees? Teams that complete training without ever practicing on their own risks. The paperwork exists, the vocabulary does not stick, and the risk file stays as fragile as it was before.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Chapter I (General Safety and Performance Requirements), Article 10(9).
  2. EN ISO 14971:2019+A11:2021, Medical devices. Application of risk management to medical devices. Including Annex Z showing deviations from MDR.
  3. EN ISO 13485:2016+A11:2021, Medical devices. Quality management systems. Requirements for regulatory purposes. Clause 6.2 (Human resources / competence).