--- title: Known and Foreseeable Hazards Under MDR Annex I description: Known foreseeable hazards MDR Annex I §3 demands. How to map the Annex I hazard list into the ISO 14971 risk file explicitly, with no blind spots. authors: Tibor Zechmeister, Felix Lenhard category: Risk Management Under MDR primary_keyword: known foreseeable hazards MDR Annex I canonical_url: https://zechmeister-solutions.com/en/blog/known-foreseeable-hazards-annex-i source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # Known and Foreseeable Hazards Under MDR Annex I *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **MDR Annex I §3(a) requires manufacturers to identify and analyse the known and foreseeable hazards associated with each device. That is not a throwaway phrase. It means every hazard family that MDR Annex I spells out, from mechanical risks to ionising radiation to software failures, has to be explicitly mapped into the ISO 14971 risk file. A file that only covers what the development team happened to think about is not compliant.** **By Tibor Zechmeister and Felix Lenhard.** ## TL;DR - MDR Annex I §3(a) demands identification and analysis of "known and foreseeable hazards" for every device. - Annex I GSPR 1-9 and the chapter on design and manufacture (§14 onwards) contain an implicit checklist of hazard families the risk file must address. - "Known" means hazards that the state of the art already documents. "Foreseeable" covers reasonable misuse and environmental conditions the device will meet in real use. - EN ISO 14971:2019+A11:2021 Annex C lists hazard categories that map directly to Annex I. Using Annex C as a scaffold closes most coverage gaps. - In Tibor's audit experience, the most common finding is a hazard family that exists in Annex I and is not mentioned anywhere in the risk file. - The fix is a single traceability table that proves every Annex I hazard family has been considered and either analysed or justified as not applicable. ## Why this matters Tibor has opened hundreds of risk files. A recurring pattern. The file looks thorough. Thirty, fifty, even two hundred rows of hazards, causes, sequences of events, controls. Then the auditor opens Annex I of the MDR, reads §10 on chemical, physical and biological properties, and asks the founder to point to where in the file those hazards were considered. Silence. The file covered what the team thought about. It did not cover what Annex I required them to think about. That is the trap. A risk file is not a brainstorm that happened to be long. It is a document that has to demonstrate coverage of every hazard family MDR Annex I names. Felix has coached founders through this exact situation. The rebuild is painful when it happens at stage 2 audit. It is much less painful when it happens at the start of development. ## What MDR actually says MDR Annex I §3 sets out the manufacturer's risk management obligations. Subparagraph (a) is explicit: the manufacturer shall "establish and document a risk management plan for each device" and shall "identify and analyse the known and foreseeable hazards associated with each device". Subparagraph (b) requires estimation and evaluation of risks associated with intended use and "reasonably foreseeable misuse". Subparagraph (c) requires elimination or reduction of those risks using the hierarchy laid out in §4. "Known" is not optional knowledge. It is what the published state of the art, harmonised standards, MDCG guidance and the manufacturer's own post-market experience already describe. If ISO 14971 Annex C lists a hazard category relevant to the device, that category is known. "Foreseeable" is broader. It reaches reasonably foreseeable misuse under Annex I §5 and the hazards that arise from the real environment of use. An outdoor device has to consider outdoor hazards. A device used by elderly patients at home has to consider home-use hazards. A device handed between patients has to consider cross-contamination. The rest of Annex I, especially the design and manufacture chapter (§14 onwards), then lists the hazard families that must be addressed where relevant: chemical and physical properties, infection and microbial contamination, devices incorporating substances of biological origin, construction and interaction with the environment, devices with measurement function, protection against radiation, electronic programmable systems and software, active devices, mechanical and thermal risks, devices delivering energy or substances, protection against risks posed to the patient or user. The harmonised standard is EN ISO 14971:2019+A11:2021. Its informative Annex C is the most practical tool a startup has. Annex C lists hazard categories across energy, biological and chemical, operational, information, and other sources. It is not a regulatory list, but it is close to a superset of what Annex I cares about. ## A worked example Consider a wearable patch for outpatient cardiac monitoring. Battery powered, adhesive to the skin, Bluetooth to a companion app, worn for up to fourteen days. The development team's first risk file has fifty rows. Mostly electrical and software. Tibor walks the Annex I hazard families with them, one by one. **§10 chemical, physical and biological properties.** The adhesive has prolonged skin contact. Biocompatibility under EN ISO 10993-1:2025 is required. Skin irritation and sensitisation have to be in the risk file. Row count goes up. **§11 infection and microbial contamination.** The device is single patient use but the inspection tool used at setup is not. Cross-contamination is now on the list. **§14 construction and environmental interaction.** The patient takes a shower. Moisture ingress was never analysed. The patient travels on a plane. Altitude and cabin pressure were never analysed. A child at home touches it. Small part ingestion was never analysed. **§15 measurement function.** ECG readings with a claimed accuracy. Measurement error propagating into clinical decisions was in a separate spreadsheet, not linked to the risk file. **§16 radiation protection.** Not applicable, but that conclusion has to be documented, not assumed. **§17 electronic programmable systems.** Software failure modes, cybersecurity hazards linked to EN IEC 81001-5-1:2022, SOUP vulnerabilities. Partially present, partially missing. **§18 active devices and connection to energy.** Battery thermal runaway. On a patch worn against skin for fourteen days. Missing. **§22 protection against mechanical and thermal risks.** Battery heat, impact during a fall, edge sharpness on the housing. Mostly missing. By the end of the session the risk file has grown by forty rows and has a traceability table that points every Annex I hazard family to either rows in the risk file or a documented "not applicable" justification. The file is now audit ready. The device is also genuinely safer, because the team has looked at hazards they would not have found on their own. ## The Subtract to Ship playbook Felix coaches founders to treat the Annex I hazard mapping as a one-page artefact that locks the scope of the risk file. One artefact. High leverage. Subtract the rest. **1. Build an Annex I hazard map.** List every hazard family named in Annex I §10 through §22. Next to each, note "applicable" or "not applicable". For every "applicable", reference the section of the risk file that covers it. For every "not applicable", write one sentence justifying why. Tibor's rule: if the justification does not fit in one sentence, the family is probably applicable and the team is reaching. **2. Cross-reference ISO 14971 Annex C.** Walk Annex C hazard categories: energy (electrical, thermal, mechanical, radiation, fire), biological and chemical, operational, information, and other. Any category not already in the map gets added. This step usually doubles coverage for first-time teams. **3. Cover foreseeable misuse explicitly.** Annex I §3(b) demands reasonably foreseeable misuse. Create a named section of the risk file for misuse scenarios. Patient uses it outdoors when the label says indoors. Patient cleans it with a solvent the materials were never tested against. Elderly patient cannot see the screen and guesses. Tibor's Q3 bee story from the usability chapter belongs here. The mouthpiece colour attracted bees outdoors because the use specification only covered indoors. Foreseeable misuse surfaced the hazard only when the auditor forced the team to think about it. **4. Pull environmental conditions in.** Temperature, humidity, altitude, vibration, moisture, electromagnetic environment, power quality. Annex I §14 and §17 reach these implicitly. Make them explicit rows in the file. **5. Link to state of the art.** For every hazard family, cite the harmonised standard, MDCG guidance, or scientific literature that establishes the known state of the art. Annex I §3 requires the known part of "known and foreseeable". That means traceable, not assumed. **6. Review with a multidisciplinary team.** Tibor's Q5 lesson. One person with a checklist will miss half the hazards. A room with RA, development, clinical, quality, marketing and sales will find the hazards that matter. AI-assisted hazard brainstorming is emerging state of the art and a legitimate supplement. **7. Update on every change.** New material, new use environment, new user group, new software release: the Annex I hazard map is reviewed. If a hazard family becomes applicable that used to be not applicable, the risk file expands. ## Reality Check 1. Does the risk file contain a traceability table that maps every Annex I hazard family (§10 through §22) to rows in the file or to a justified "not applicable"? 2. Has foreseeable misuse been analysed as a named section, not scattered through general hazards? 3. Is every "not applicable" claim justifiable to an auditor in one sentence? 4. Has a multidisciplinary team reviewed the hazard identification, not just one engineer? 5. Is the state of the art cited for each hazard family by standard, guidance, or literature? 6. Have environmental conditions (temperature, humidity, moisture, EMC, altitude) been treated as explicit hazards where relevant? 7. Is the hazard map reviewed on every design change, not just at release? 8. Would Tibor's audit test pass: pick any Annex I paragraph at random and find the corresponding coverage in under sixty seconds? ## Frequently Asked Questions **Is the ISO 14971 Annex C list legally binding?** No. Annex C is informative, not normative. It is a checklist to help ensure coverage. The legally binding list is MDR Annex I itself. Annex C is a scaffold for meeting that obligation. **What counts as "reasonably foreseeable" misuse?** Any misuse a manufacturer with a realistic understanding of the use environment should anticipate. Not every possible misuse. Misuse that an average user, in the intended setting, could plausibly commit. Tibor's rule: if a similar device has had the same misuse reported in the literature or in vigilance databases, it is foreseeable. **How do I document a "not applicable" hazard family without looking lazy?** Write one sentence that references the device characteristics: "The device has no active energy source, so hazards under Annex I §18 are not applicable." If the sentence does not write itself, the family is probably applicable. **Does this apply to Class I devices?** Yes. MDR Annex I applies to all devices regardless of class. Class I devices need the same hazard mapping. The depth of analysis scales with risk, but the obligation to identify known and foreseeable hazards does not. **Where does the manufacturer find the "known" hazards?** Harmonised standards, MDCG guidance, MEDDEV documents, incident databases, competitor IFUs, scientific literature, and the manufacturer's own post-market data from legacy products. If a hazard is published somewhere and is not in the file, it is a known hazard that was missed. ## Related reading - [The MDR Risk Management Process: Using ISO 14971](/blog/mdr-risk-management-process-iso-14971): how Annex I §3 and ISO 14971 lock together across the lifecycle - [MDR Annex I GSPR](/blog/mdr-annex-i-gspr): the full General Safety and Performance Requirements map - [Risk Management for Medical Devices: A Startup Primer](/blog/risk-management-medical-devices-startup-primer): entry point for founders new to ISO 14971 ## Sources 1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §3, Annex I GSPR 1-9, Annex I §10-22. 2. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices. Annex C hazard categories. 3. EN ISO 10993-1:2025, Biological evaluation of medical devices, Part 1. --- *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).*