Your whole team does not need to be regulatory experts, but everyone who touches the device, the code, the clinical claims, or the documentation needs baseline MDR literacy — enough to recognise when a decision has regulatory consequences and escalate it to the right owner. EN ISO 13485:2016+A11:2021 clause 6.2 requires personnel performing work that affects product quality to be competent on the basis of education, training, skills, and experience, and requires that competence be documented. MDR Article 10 places the manufacturer obligations on the legal entity, which means the CEO is accountable for the training. The curriculum that actually works has three tiers: a baseline every role must pass, a deeper curriculum for QA, RA, and the PRRC, and a role-specific layer for engineers, clinical, and customer-facing staff. The training has to be real, not ceremonial — and the competence records have to survive an auditor who knows what to look for.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • EN ISO 13485:2016+A11:2021 clause 6.2 requires every person whose work affects product quality to be competent on the basis of education, training, skills, and experience, with documented evidence.
  • MDR Article 10 places the manufacturer obligations on the legal entity, and in a startup the CEO is ultimately accountable for training under the QMS.
  • The curriculum has three tiers. Baseline literacy for every role. Deeper training for QA, RA, and the PRRC. Role-specific modules for engineers, clinical staff, and customer-facing staff.
  • Baseline literacy means: what the MDR is, what the QMS is, what intended purpose means, how to recognise a regulatory-relevant decision, and who to escalate it to.
  • Training records that satisfy clause 6.2 are specific, dated, signed, and effective — not a PowerPoint attendance sheet.
  • Onboarding is the single highest-leverage training moment. New hires who learn regulatory habits in week one carry them forever. New hires who learn bad habits in week one take years to unlearn them.
  • The most common failure is "training theatre" — signed attendance lists, shelf-ware slides, no evidence the content landed. Notified Body auditors see through it in minutes.

Why training matters more than founders think

A common scene in MedTech startups we have coached: an engineer pushes a software change on a Wednesday afternoon. The change is small in code terms. It modifies how a threshold is calculated in a module that feeds the main clinical output. The engineer tests it, passes it, and moves on. Nobody in the weekly design review learns about it because the engineer did not think it was worth mentioning. Two months later, the RA lead is reviewing the technical file and notices the change only because a test record does not match. The change was, in regulatory terms, a design change affecting a risk control measure. It should have triggered an impact assessment, a risk file update, and possibly a Notified Body notification if the device was already on the market.

The engineer was not lazy and not incompetent. The engineer was untrained. Nobody had ever told them, in practical terms, which kinds of changes are regulatory-relevant. The training gap was the failure mode, not the engineer.

This is the pattern we see over and over. Training in MedTech startups is treated as a checklist item — a slide deck shown in week one, an attendance sheet signed, a folder closed. The actual goal of training, which is to change daily behaviour, is quietly skipped. The Notified Body auditor who opens the clause 6.2 competence file a year later knows the difference between real training and training theatre, and so does the device, because the device behaves like the people building it were trained to behave.

The clause 6.2 training requirement

EN ISO 13485:2016+A11:2021 clause 6.2 — human resources — is the standard's answer to the training question. The clause requires that personnel performing work affecting product quality be competent on the basis of appropriate education, training, skills, and experience. It requires that the organisation determine the necessary competence for each role, provide training or take other actions to achieve that competence, evaluate the effectiveness of the actions taken, ensure that personnel are aware of the relevance and importance of their activities, and maintain records of education, training, skills, and experience.

Read that list carefully. The clause does not say "show a slide deck." It says determine, provide, evaluate effectiveness, ensure awareness, maintain records. Five separate obligations, each one checkable by an auditor. And the last one — maintain records — means the competence file has to exist as an actual file, not as a collective memory held by the founders.

MDR Article 10 reinforces this at the manufacturer level. The manufacturer is responsible for the device placed on the market and for the QMS that produces it. Article 10(9) requires the QMS to cover, among other areas, resource management including training. The training obligation is not optional. It is not proportional in the sense that you can skip it at small scale. It is proportional in the sense that the depth scales to the risk — but the requirement exists at every size of company.

The practical test is this. If an auditor opens the competence file for any person in the company and asks "how do you know this person is competent to do what they do?", the file must answer the question specifically. Not with a title. Not with a CV. With a documented path: education, training completed, skills demonstrated, experience captured, and — crucially — evidence that the training was effective, not just delivered.

The minimum baseline every role must have

Not everyone needs to be a regulatory expert. Everyone needs baseline MDR literacy. The baseline we teach in the companies we work with covers six things, and it takes roughly half a day to deliver properly.

What the MDR is and why it exists. Regulation (EU) 2017/745, the legal instrument, its applicability date, and the principle that the manufacturer is responsible for the device on the market. Not the full text — just enough that every person understands they work for a legal manufacturer with legal obligations, not just a tech company that happens to build medical products.

What the QMS is and how it shapes daily work. EN ISO 13485:2016+A11:2021 as the operating system of the company. Document control. Training records. Change control. CAPA. The point is not to memorise the clauses but to recognise that every procedure in the company exists because a clause requires it, and that deviations are not a personal preference.

What intended purpose is and why it is so leveraged. The single most important sentence in the regulatory file, and why changes to product claims, marketing wording, or clinical descriptions ripple into classification and the technical file. Every non-RA person should know that "that is just a marketing tweak" is a sentence that can cost the company six months.

How to recognise a regulatory-relevant decision. The practical list. Design changes to anything that touches risk control, clinical output, or intended purpose. Supplier changes. Changes to software that affect classification-relevant modules. New clinical claims. Anything that touches labelling or IFU. New markets. The rule of thumb: if in doubt, ask.

Who to escalate to and how. Every person in the company must know, by name, who the quality and regulatory lead is, who the PRRC is, and how to flag a concern. Not a form. A Slack channel, a recurring meeting, a named person.

The red lines that are never crossed. No unvalidated software in clinical use. No device shipped without release. No off-label testing on patients. No quiet workarounds to process gaps. The baseline must explicitly teach the red lines, because a red line that has not been named is a red line that will be crossed by someone who did not know it existed.

That is the minimum. Half a day of real content, delivered in small groups with space for questions, with an exit check that demonstrates the content landed. Not a slide deck emailed as a PDF.

Deeper training for QA, RA, and the PRRC

Baseline literacy is not enough for the people whose whole job is the QMS, the regulation, or the PRRC function under MDR Article 15. These roles need a substantially deeper curriculum, and the curriculum is specific to each seat.

QA — the QMS operator. Detailed training on EN ISO 13485:2016+A11:2021 clause by clause, with emphasis on the clauses they own day-to-day: clause 4 (QMS), clause 5 (management responsibility), clause 7 (product realisation), clause 8 (measurement, analysis and improvement). Internal auditor training to a recognised curriculum. CAPA methodology training. Document control training specific to the tool in use. Management review facilitation. Supplier qualification and monitoring.

RA — the regulation interpreter. Detailed training on the MDR article by article, starting with Articles 1–22 and the annexes that govern classification (Annex VIII), technical documentation (Annex II), GSPR (Annex I), and clinical evaluation (Annex XIV). Training on the harmonised standards relevant to the specific device — EN ISO 14971 for risk management, EN 62304 for software lifecycle, EN 62366-1 for usability, EN 60601-1 for electrical safety, and so on. Training on MDCG guidance documents as they apply. Training on Notified Body interaction — how submissions are structured, how deficiencies are answered, how audits are survived. The RA curriculum is the largest, and it is never "finished" because the regulatory environment keeps moving.

PRRC — the legally defined role. Training on MDR Article 15 itself, including the specific tasks listed in Article 15(3) — conformity check before release, technical documentation, PMS, vigilance reporting, and investigational device statements. Training on Article 15(6) protection and how to exercise it. Training on the specific areas where the PRRC is personally accountable and where they can be challenged at inspection. See the hub post The MedTech Startup Team and Building a Quality Team in a Startup for how this seat connects to the rest of the quality function.

The deeper curriculum cannot be delivered in half a day. It takes weeks of structured learning, supplemented by real work, supplemented by mentorship. The most effective version we have seen is a written training plan per person, reviewed quarterly, updated as gaps are discovered, and signed off as competence milestones are reached.

Onboarding — where the habits are set

The single highest-leverage training moment in the entire life of a MedTech startup is the first week of each new hire. Not because the content is more important in week one than in month six, but because the habits set in week one compound for years. A new engineer who learns in week one that every design change gets mentioned in the weekly cross-functional review will do it automatically forever. A new engineer who learns in week one that "small changes" can be skipped will keep skipping them.

A real onboarding programme for a MedTech startup looks like this. Day one: the baseline half-day (MDR, QMS, intended purpose, regulatory-relevant decisions, escalation, red lines). Day two: role-specific orientation — the QMS procedures the person will actually use, the tools (document control system, CAPA system, design review cadence), and a walk-through of the technical file structure. Day three to end of week one: shadowing the team in the real meetings — the weekly cross-functional design review (see Cross-Functional Teams in MedTech), the monthly regulatory review if it falls in the window, any ongoing CAPAs. Week two: the first actual work with a defined sign-off from the quality and regulatory lead that the person has understood the relevant procedures. Week three to six: gradual ramp, with explicit check-ins.

Onboarding is also where competence records start. A competence file opened on day one, populated as the training happens, signed as milestones are reached, is a file that survives an audit. A competence file opened retroactively six months later, when someone realises the clause 6.2 requirement applies, is a file that will not.

Competence records — what clause 6.2 actually expects

The competence file for each person should contain, at minimum, six things. First, the person's education — diplomas, degrees, certifications, with copies on file. Second, their prior experience relevant to the role — the CV plus any specific evidence that maps experience to the current seat. Third, the training plan for the role, written at the start of employment and updated as it runs. Fourth, the training records — dated, specific, signed, with content titles and effectiveness evidence, not just attendance. Fifth, the skills evidence — examples of work done, internal audits passed, reviews completed. Sixth, the competence assessment itself — a dated statement by a qualified assessor that the person meets the competence requirement for the role, with the basis for that statement.

Effectiveness evidence is the element most startups skip and most auditors check. Clause 6.2 requires the organisation to evaluate the effectiveness of the training, not just deliver it. Effectiveness evidence can take several forms. A post-training quiz or exit check that the person passed. A short practical task the person completed under observation. A sign-off by the quality and regulatory lead after a defined probationary period. A reference to a specific piece of work the person then did correctly. Whichever form, the effectiveness evidence has to exist and has to be specific to the person and the training. A generic statement that "training is evaluated by management" is not effectiveness evidence. It is wording.

Training records should also be version-controlled and dated. A training on the intended purpose procedure as it existed in March 2025 is not the same as a training on the procedure as it exists now if the procedure has been revised. When procedures change, people have to be re-trained on the changes, and the re-training has to be captured. This is the element that catches most startups at the first surveillance audit — the procedure moved, the training did not, and the gap is visible in the file.

Common failure modes in MedTech training

Five patterns we see repeatedly.

Training theatre. Slide decks delivered once, attendance signed, nothing changes in daily behaviour. The record exists, the competence does not. Detectable at audit within minutes.

Missing role-specific training. Baseline literacy delivered to everyone, nothing specific to the engineer or clinical specialist or customer-facing role. The baseline is necessary but not sufficient. Each role needs the role-specific layer.

Records without effectiveness evidence. The training happened, the attendance is logged, the effectiveness is not. Clause 6.2 specifically requires effectiveness evaluation, and skipping it is a direct non-conformity.

Onboarding compressed into a single hour. New hire shown a deck, sent to work. Habits set by default instead of by design. Six months later the habits are compounded and hard to change.

Re-training skipped when procedures change. Procedures move, training records do not. The gap shows up at the next audit, and it shows up for every procedure that moved.

The fix for all five is discipline. Training has to be treated as real work with real outcomes, not as an administrative task, and the competence file has to be curated as carefully as the technical file. A company that treats training as ceremony will produce a device that was built by people who treated the regulation as ceremony, and the device will reflect it.

The Subtract to Ship angle

The Subtract to Ship framework applied to training means: do not invent a bloated training programme, and do not skip the training that actually matters. The smallest training programme that satisfies clause 6.2 and changes real behaviour is the goal. That usually means a half-day baseline done properly, a role-specific module per seat, a real onboarding programme, and a competence file that exists as a living document. What comes out is the ten-module corporate training library that no one reads, the annual refresher that is a formality, and the generic e-learning platforms bought because the sales person was convincing.

The test is the same as every other Subtract to Ship decision. For every piece of training, can you point to the clause 6.2 requirement it satisfies and the behavioural change it produces? If yes, keep it. If the answer is "because we have always done it," cut it. If the answer is "because the platform came with it," cut it harder.

Reality Check — Where do you stand?

  1. Can you open the competence file for any person in your company and find education, training records with dates and content, effectiveness evidence, and a dated competence assessment — for that specific person?
  2. Has every person in the company completed a baseline MDR literacy module that covers the six elements in this post, or is baseline literacy assumed?
  3. Do your engineers know, specifically, which kinds of design changes are regulatory-relevant and how to escalate them?
  4. When a procedure in your QMS is revised, do you have a process that ensures everyone affected is re-trained and the re-training is documented?
  5. Does your onboarding programme run for at least the first week, with real shadowing and a defined competence sign-off, or is it compressed into a single orientation session?
  6. Do your PRRC, QA lead, and RA lead each have a written training plan that is updated quarterly, or is their training ad hoc?
  7. If a Notified Body auditor opened your competence file for three random people tomorrow, how confident are you in what they would find?
  8. When was the last time a training was cancelled or shortened because of schedule pressure, and what was the consequence?

Frequently Asked Questions

Does everyone in a MedTech startup need MDR training? Everyone whose work affects product quality needs training appropriate to their role, under EN ISO 13485:2016+A11:2021 clause 6.2. In practice, that is everyone in a MedTech startup, because there are very few roles that do not touch the device, the documentation, the clinical claims, or the customer interface in some way. The depth of training varies by role, but the baseline MDR literacy module applies to everyone.

What does EN ISO 13485 clause 6.2 actually require? Clause 6.2 requires the organisation to determine the necessary competence for each role, provide training or take other actions to achieve that competence, evaluate the effectiveness of the actions taken, ensure personnel are aware of the relevance and importance of their activities, and maintain records of education, training, skills, and experience. Five separate obligations, each one checkable at audit.

How long should baseline MDR training take for a new engineer? The baseline literacy module we recommend takes about half a day if delivered properly, with space for questions and an exit check. That covers what the MDR is, what the QMS is, what intended purpose means, how to recognise a regulatory-relevant decision, who to escalate to, and the red lines that are never crossed. The role-specific training for the engineer then runs on top of that, spanning the first week to six weeks depending on the role depth.

What counts as training effectiveness evidence? A post-training quiz or exit check that the person passed. A short practical task completed under observation. A sign-off by a qualified assessor after a defined probationary period. A reference to a specific piece of work the person then completed correctly. What does not count is a generic statement that "training is evaluated by management" or a signed attendance sheet. Clause 6.2 effectiveness evidence has to be specific to the person and the training.

Do we need to re-train people when QMS procedures change? Yes. If a procedure that affects a person's work is revised in a way that changes what the person has to do, the person has to be re-trained on the revised procedure and the re-training has to be captured in the competence file. Skipping this is the single most common training non-conformity in surveillance audits, and it is visible because the procedure version in the training record does not match the current procedure version.

Can an external trainer deliver the MDR baseline for a startup? Yes, and it is often the fastest way to get a credible baseline in place if nobody internal has the depth to deliver it yet. The external trainer must be qualified — documented experience teaching the relevant content — and the training record must capture that qualification as part of the effectiveness evidence. Over time, the internal quality and regulatory lead should take over delivery as their own competence deepens, because internal delivery reinforces the internal training culture.

What is the biggest training mistake MedTech startups make? Training theatre — delivering a slide deck once, signing attendance, and treating the obligation as satisfied. The behaviour does not change. The records exist but are thin. The Notified Body auditor sees through it within minutes of opening the competence file. The fix is to treat training as real work with real outcomes, deliver it in small groups with space for questions, capture effectiveness evidence specifically, and re-train when procedures change.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10 (general obligations of manufacturers), Article 10(9) (quality management system, resource management, and the list of areas the QMS shall address). Official Journal L 117, 5.5.2017.
  2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clause 6.2 (human resources — competence and training, including determination of competence, provision of training, evaluation of effectiveness, awareness, and documented records).

This post is part of the Team Building, Operations & Scaling category in the Subtract to Ship: MDR blog, under the Training and Competence subcategory. Authored by Felix Lenhard and Tibor Zechmeister. If your company's competence file is thinner than your technical file, this is the post to read before the next surveillance audit — and then sit down with the quality and regulatory lead and open the file honestly.