Annex I of the MDR is the single most important annex for any medical device manufacturer. It contains the General Safety and Performance Requirements. The GSPRs. That every medical device must satisfy. Your entire technical documentation exists to demonstrate that your device meets these requirements. Your risk management, clinical evaluation, labeling, and design verification all trace back to Annex I.
Here is what the GSPRs require and how to approach them without drowning in compliance paperwork.
What Are the General Safety and Performance Requirements?
The GSPRs are the fundamental requirements that every medical device placed on the EU market must meet. They replaced the "Essential Requirements" of the old MDD (which were in Annex I of Directive 93/42/EEC).
Annex I of the MDR is organized into three chapters:
Chapter I: General Requirements (Sections 1–9). These apply to all medical devices regardless of type. They cover the overarching principles: devices must be safe and perform as intended, risks must be reduced as far as possible, and the benefit-risk ratio must be acceptable.
Chapter II: Requirements Regarding Design and Manufacture (Sections 10–22). These cover specific design and manufacturing requirements: chemical, physical, and biological properties; infection and microbial contamination; devices incorporating substances; devices with energy sources; software; connected and networked devices; active implantable devices; and protection against mechanical and thermal risks.
Chapter III: Requirements Regarding the Information Supplied with the Device (Section 23). This covers labeling, instructions for use, and all information provided with the device.
How Should a Startup Approach the GSPRs?
The most common mistake startups make with Annex I is treating it as a checkbox exercise. Going through each section, writing "compliant" or "not applicable," and moving on. This is exactly what Notified Body auditors flag as a non-conformity. Tibor has reviewed hundreds of GSPR assessments, and the difference between ones that pass audit and ones that do not is depth, not breadth.
Here is the systematic approach:
Step 1: Create Your GSPR Checklist
Go through every section and subsection of Annex I. For each requirement, determine one of three statuses:
- Applicable. This requirement applies to your device, and you must demonstrate compliance
- Not applicable. This requirement does not apply to your device, and you must document why
- Partially applicable. Parts of this requirement apply, and you must address which parts and why
The "not applicable" justifications matter as much as the compliance demonstrations. An auditor who sees "N/A" without explanation will question whether you actually analyzed the requirement or simply skipped it.
Step 2: Map Each Applicable Requirement to Evidence
For every applicable GSPR, identify the specific evidence that demonstrates compliance. This evidence can include:
- Harmonized standards: If you followed a harmonized standard that covers the requirement, reference the specific clause. This creates a "presumption of conformity."
- Test reports: Results from verification and validation testing
- Risk management documentation: Risk analyses that address the specific hazard the GSPR is concerned with
- Clinical evaluation: Clinical evidence demonstrating safety and performance
- Design documentation: Design specifications, design verification, and design validation records
- Literature: Published scientific literature supporting your approach
Step 3: Build the Traceability Matrix
Create a matrix that links each GSPR to the specific evidence in your technical documentation. This is not optional. It is the document your Notified Body auditor will use to navigate your submission. A good traceability matrix saves auditor time and demonstrates that you have thought systematically about every requirement.
What Are the Key GSPRs That Startups Must Get Right?
While every GSPR matters, certain sections cause disproportionate problems for startups:
Section 1: Safety and Performance
The overarching principle: devices must achieve the performance intended by the manufacturer and must be designed and manufactured in such a way that, during normal conditions of use, they are suitable for their intended purpose. They must be safe and effective and shall not compromise the clinical condition or the safety of patients.
This is not a motherhood statement. It is a legally binding requirement. Your clinical evaluation and performance testing must directly demonstrate that your device achieves its intended performance claims.
Section 2: Risk Management
The MDR requires that manufacturers establish, implement, document, and maintain a system for risk management, as described in Annex I, Section 3 . EN ISO 14971 is the harmonized standard for risk management, and following it creates a presumption of conformity with this requirement.
For startups, risk management is not a separate activity from product development. It is integrated into every design decision. Every hazard identified, every risk estimated, every mitigation measure implemented must be documented and traceable.
Section 3: Benefit-Risk Determination
Devices must be designed and manufactured such that residual risks are acceptable when weighed against the intended benefits. The benefit-risk determination must be based on: - The intended purpose and performance of the device - The state of the art in the relevant field - Available alternative treatments or devices - The severity and probability of harms
This is where many startups falter. "Our device is beneficial" is not a benefit-risk determination. You need a structured methodology that identifies specific benefits, quantifies them where possible, identifies specific residual risks, and demonstrates that the benefits outweigh the risks for the intended patient population.
Section 14: Software Requirements
For software-based devices, Section 14 requires that software is developed and manufactured in accordance with the state of the art, taking into account the principles of development life cycle, risk management, including information security, verification, and validation . IEC 62304 is the applicable standard for software lifecycle processes.
Section 14 also requires that software intended to be used in combination with mobile computing platforms is designed and manufactured taking into account the specific features of the mobile platform and the external factors related to their use.
Section 17: Electronic Programmable Systems and Software
For devices that incorporate electronic programmable systems, including software, Annex I requires that the software be validated according to the state of the art, taking into account the principles of development lifecycle, risk management, verification, and validation .
Section 23: Labeling and Instructions for Use
The information requirements are extensive. Labels must include the manufacturer's name and address, the device name, the UDI carrier, the lot number or serial number, the CE marking, and much more. Instructions for use must include the intended purpose, the intended user population, contraindications, warnings, precautions, and detailed usage instructions.
For startups, labeling is often treated as the last step. This is a mistake. Labeling requirements affect your product design, your packaging design, and your user interface. Address them early.
How Do GSPRs Relate to Harmonized Standards?
Harmonized standards provide the technical detail that the GSPRs require but do not specify. When the MDR says "devices must be designed and manufactured to reduce risks as far as possible," harmonized standards define what "as far as possible" means in practice for specific risk areas.
Key mappings: - Risk management (GSPRs Section 2–3) → EN ISO 14971 - Biocompatibility (GSPRs Section 10) → ISO 10993 series - Software lifecycle (GSPRs Section 14, 17) → IEC 62304 - Usability (GSPRs Section 5) → IEC 62366-1 - Electrical safety (applicable sections) → IEC 60601-1 series - Sterilization (GSPRs Section 11) → ISO 11135, ISO 11137 series
Using harmonized standards is not mandatory, but it creates a presumption of conformity. Meaning the burden shifts from you proving compliance to the auditor proving non-compliance. For a startup, this is a significant advantage. See How to Use Harmonized Standards to Demonstrate MDR Compliance.
What Does a Good GSPR Assessment Look Like?
A GSPR assessment that will survive audit has these characteristics:
- Every section is addressed. Applicable, not applicable, or partially applicable, with justification
- Evidence is specific. Not "see technical file" but "see Test Report TR-2026-014, Section 3.2, which demonstrates compliance with electrical leakage limits per IEC 60601-1 clause 8.7"
- Risk-based reasoning is visible. For sections related to safety, the assessment references specific risk analyses and mitigation measures
- State of the art is addressed. Where relevant, the assessment demonstrates awareness of current best practice in the field
- Non-applicable justifications are substantive. "Not applicable because this device does not contact the patient's body and therefore biocompatibility requirements per Section 10 do not apply" is substantive. "N/A" is not.
The GSPR assessment is the backbone of your technical documentation. Take it seriously from the start.
Next: Essential Requirements vs. General Safety and Performance Requirements: What Changed from MDD to MDR.