--- title: Risk Management Checklist for MedTech Startups description: Risk management checklist startup MedTech teams can execute end to end: plan, analysis, controls, residual, report, PMS feedback. The close-out reference. authors: Tibor Zechmeister, Felix Lenhard category: Risk Management Under MDR primary_keyword: risk management checklist startup canonical_url: https://zechmeister-solutions.com/en/blog/risk-management-checklist-startup source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # Risk Management Checklist for MedTech Startups *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **A startup-sized checklist for MDR-compliant risk management from first plan to post-market feedback, covering every required step under Annex I §3, §4 and §8 and every clause of EN ISO 14971:2019+A11:2021 that actually matters for a small team. Built from Tibor's audit experience and Felix's startup coaching. Use this as the close-out reference for the whole risk management cluster.** **By Tibor Zechmeister and Felix Lenhard.** ## TL;DR - Risk management for a MedTech startup has seven deliverables: plan, hazard analysis, risk evaluation, risk controls, residual risk evaluation, risk management report, post-production feedback log. - The plan defines scope, method, acceptability language using MDR "as far as possible" under Annex I §4, and the PMS feedback path under Articles 83-86. - Hazard identification needs a multidisciplinary team, not one person with a checklist. - Controls follow the Annex I §4 hierarchy. Inherent design first. Protective measures second. Information for safety last. - Residual risks get disclosed in the IFU. The benefit-risk conclusion references the clinical evaluation. - Post-market surveillance data feeds back into the file on a continuous cadence, documented in the feedback log. - Work the checklist in order. Every step closed properly prevents a finding an auditor would otherwise raise. ## Why this matters The preceding posts in this cluster explained the process, the ISO 14971 gaps, the Annex I hazard map, the auditor's review order, and the state of the art. This post consolidates all of that into a single reference a founder can work top to bottom. Felix uses a version of this checklist with every startup he coaches. Tibor uses a version of this checklist to audit the same startups eighteen months later. The checklist is not a substitute for reading the regulation and the standard. It is a working document that keeps the team honest about which steps are done, which are partial, and which are still open. Treat it as a living artefact during development, not a one-time box-ticker. ## What MDR actually says MDR Annex I §3 requires a documented risk management system across the entire device lifecycle. The process must include: a risk management plan, identification and analysis of known and foreseeable hazards, estimation and evaluation of risks including reasonably foreseeable misuse, elimination or control of risks following the hierarchy in §4, evaluation of residual risks and overall benefit-risk under §8, and review based on production and post-production information. MDR Annex I §4 defines the control hierarchy: (a) inherent safe design and manufacture, (b) protective measures, (c) information for safety. The order is not optional. MDR Annex I §8 requires the overall residual risk to be judged acceptable when weighed against the benefits. MDR Articles 83 to 86 require a PMS system with proactive data collection, analysis, and feedback into technical documentation, risk management, and clinical evaluation. EN ISO 14971:2019+A11:2021 is the harmonised standard. Annex ZA maps it to MDR and flags the "as far as possible" gap versus ISO's Section 6 "initially acceptable" language. Apply Annex ZA, not ISO 14971 in isolation. ## A worked example A three-person startup building a Class IIa ambulatory monitoring wearable works the checklist over twelve weeks alongside design. Here is what Felix sees in the cadence. Week 1-2: the plan gets drafted and the multidisciplinary workshop is scheduled. Week 3-4: the first hazard analysis session surfaces thirty-five hazards across mechanical, biological, electrical, software, cybersecurity and use error categories. Week 5: risk evaluation against the MDR "as far as possible" criterion forces the team to revisit three design decisions. Week 6-7: controls are implemented in the Annex I §4 hierarchy, with two inherent design changes, four protective measures, and the rest documented as information for safety where appropriate. Week 8-9: residual risk evaluation and benefit-risk conclusion, drawing on the early clinical evaluation draft. Week 10: the risk management report is written. Week 11: residual risks are added to the IFU. Week 12: the PMS feedback log is set up with a quarterly review cadence and stored alongside the risk file. The deliverables at week 12 are all seven artefacts, current, linked, and audit-ready. The design has also changed for the better in three places because the risk process surfaced things nobody would have caught otherwise. ## The Subtract to Ship playbook The checklist is the playbook. Work it in order. Subtract anything that does not belong to one of the seven artefacts or their supporting evidence. ### Deliverable 1: Risk Management Plan (ISO 14971 Clause 4) - [ ] Scope: device, intended purpose, intended users, intended use environment documented. - [ ] Responsibilities: named risk manager, named approver, named reviewer from each relevant discipline. - [ ] Method: reference to ISO 14971 clauses, chosen analysis techniques (PHA, FMEA, HAZOP, fault tree). - [ ] Acceptability criteria: written in MDR "as far as possible" language under Annex I §4, not ISO 14971 Section 6 ALARP. - [ ] Verification activities: how implementation of controls will be verified. - [ ] Post-production information path: how PMS data flows back into the file under MDR Articles 83-86. - [ ] Review cadence: how often the file is reviewed absent triggering events. - [ ] Approved by top management. ### Deliverable 2: Hazard Analysis (ISO 14971 Clause 5) - [ ] Intended use and reasonably foreseeable misuse documented. - [ ] Annex I hazard map: every Annex I §10-22 hazard family addressed or justified as not applicable. - [ ] ISO 14971 Annex C categories walked: energy, biological and chemical, operational, information, other. - [ ] Multidisciplinary session held with attendance recorded. Minimum disciplines: RA, development, clinical, quality, marketing or sales. - [ ] Foreseeable misuse scenarios explicitly listed (not buried in general hazards). - [ ] Use environment hazards covered: indoor, outdoor, home, hospital, travel, cleaning. - [ ] Cybersecurity hazards linked to EN IEC 81001-5-1:2022 threat model where applicable. - [ ] Usability-related hazards linked to EN 62366-1:2015+A1:2020 analysis. ### Deliverable 3: Risk Evaluation (ISO 14971 Clause 6) - [ ] Every hazard has estimated severity and probability. - [ ] Every hazard compared against acceptability criteria from the plan. - [ ] Language uses "as far as possible", not "acceptable yes or no". - [ ] State of the art cited where a hazard is deemed unreducible. ### Deliverable 4: Risk Controls (ISO 14971 Clause 7, Annex I §4) - [ ] Controls follow the Annex I §4 hierarchy: (a) inherent design, (b) protective measures, (c) information for safety. - [ ] Each control annotated with the hierarchy level it satisfies. - [ ] Where information for safety is used instead of a stronger control, a technical infeasibility or greater-risk justification is documented. - [ ] Verification records linking each control to its implementation and effectiveness evidence. - [ ] New hazards introduced by controls analysed and addressed. ### Deliverable 5: Residual Risk Evaluation (ISO 14971 Clause 8) - [ ] Individual residual risks evaluated after controls. - [ ] Overall residual risk evaluated under Annex I §8. - [ ] Benefit-risk conclusion written with reference to clinical evaluation. - [ ] Both direct and indirect benefits documented (quantitative where possible, qualitative where appropriate). - [ ] Residual risks disclosed in the IFU per Annex I §4(c). ### Deliverable 6: Risk Management Report (ISO 14971 Clause 9) - [ ] Summary of hazards identified, controls implemented, residual risks. - [ ] Confirmation that the risk management plan was executed. - [ ] Confirmation that overall residual risk is acceptable under Annex I §8. - [ ] Approved by top management before release of the device. ### Deliverable 7: Post-Production Feedback Log (ISO 14971 Clause 10, MDR Articles 83-86) - [ ] Log structure: date, input source, affected hazard, updated severity or probability, updated file version. - [ ] Cadence: at least quarterly review, continuous logging of triggering events. - [ ] Integration with PMS plan, PSUR or PMS report, and CAPA system. - [ ] Evidence of at least one update triggered by PMS data in the last twelve months post-launch. ## Reality Check 1. Are all seven deliverables current and signed off? 2. Does the plan use MDR "as far as possible" language and cite Annex I §4 explicitly? 3. Has the hazard analysis been done by a multidisciplinary team with attendance recorded? 4. Does every Annex I hazard family from §10 through §22 have a mapped entry or a documented not-applicable justification? 5. Are all controls annotated with the Annex I §4 hierarchy level and defended where information for safety was used instead of design? 6. Does the benefit-risk conclusion cite the clinical evaluation and include indirect benefits where appropriate? 7. Is the PMS feedback log live and has it triggered at least one risk file update in the last twelve months? 8. If Tibor opened this file tomorrow, would the first forty minutes of review produce zero findings? ## Frequently Asked Questions **Is this checklist specific to one device class?** No. The seven deliverables apply to every device class under MDR. The depth of each deliverable scales with risk. A Class I device can have shorter documents. A Class III implant needs depth and evidence at every step. **Can a small team actually execute all of this?** Yes. The three-person startup example in this post did it in twelve weeks alongside design. The condition is that risk management runs parallel to development, not at the end. Felix has never seen a team succeed when the risk file was started in the last month before notified body submission. **Which deliverable is the most often skipped?** The risk management plan and the post-production feedback log. Teams jump straight to hazard analysis and never write the plan. Teams ship the device and never set up the feedback log. Both are findings waiting to happen at the first surveillance audit. **How does this checklist interact with the QMS?** The risk management process is a QMS process under EN ISO 13485:2016+A11:2021 clause 7. The checklist deliverables live inside the QMS document structure. The plan references the QMS risk management SOP. The report feeds the management review. The feedback log feeds CAPA. **What about AI-assisted hazard identification?** Emerging state of the art. Tibor's view: AI is a legitimate supplement to the multidisciplinary workshop for surfacing hazards humans miss. It is not a replacement. Use both. ## Related reading - [The MDR Risk Management Process: Using ISO 14971](/blog/mdr-risk-management-process-iso-14971): the full process walkthrough - [Common MDR Risk Management Mistakes](/blog/common-risk-management-mistakes-iso-14971): the anti-patterns this checklist prevents - [The Auditor's Guide to Reviewing Risk Management Files](/blog/auditor-guide-reviewing-risk-files): how Tibor reviews the file this checklist produces ## Sources 1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §3, §4, §8, Articles 83-86. 2. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices. Annex ZA. 3. MDCG 2025-10 (December 2025), Guidance on post-market surveillance. --- *This post is part of the [Risk Management Under MDR](https://zechmeister-solutions.com/en/blog/category/risk-management) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*