EU MDR Annex I: Building the GSPR Compliance Matrix

Every EU MDR technical file needs a General Safety and Performance Requirements checklist, and most teams treat it as paperwork — a table to fill in once the design is finished, not a document that shapes the design. That gets the structure backwards. Annex I sets out 23 requirements across three chapters, and Annex II specifies exactly what the checklist has to show for each one. Get the format wrong and a Notified Body doesn't send back comments on your device — it sends back comments on your paperwork, on a file you thought was done.

The three chapters, and which ones you can't skip

Annex I organizes the General Safety and Performance Requirements into three chapters. Chapter I (sections 1–9) sets the general requirements every device has to meet: an acceptable benefit-risk ratio, a risk management system run across the device's whole lifecycle, performance for its intended purpose, and safety that holds up over the device's stated lifetime. Chapter III (section 23) covers the information supplied with the device — labelling and instructions for use. Both apply to every device, full stop. Chapter II (sections 10–22) is where the requirements get device-specific: chemical, physical, and biological properties; infection and microbial contamination; devices with a measuring function; protection against radiation; requirements for software and electronic programmable systems; and more. These apply only insofar as they're relevant to the device in question — but "not relevant" is a claim that needs a documented justification, not a section left blank.

Building the checklist Annex II actually asks for

Annex II, Section 4 of the technical documentation requirements doesn't leave the checklist format to interpretation. For each GSPR, the documentation has to state: which requirements apply to the device, and an explanation for any that don't; the method or methods used to demonstrate conformity with each applicable requirement; the harmonised standards, common specifications, or other solutions applied; and the precise identity of the controlled documents offering evidence of conformity, cross-referenced to where they sit in the technical file. A checklist that just marks each row "complies" skips every one of those four columns — it's an assertion, not the evidence Annex II requires.

A GSPR checklist that only says "complies" is not evidence — it's an assertion a Notified Body has no reason to accept. Why the four-column format isn't optional

Harmonised standards give a presumption, not a shortcut

Under Article 8, a harmonised standard published in the Official Journal gives a presumption of conformity — but only for the specific clauses of the GSPR that the standard actually covers. A design or bench-testing standard rarely closes the benefit-risk and clinical-performance requirements in Chapter I on its own; that's where the clinical evidence that has to sit behind the performance requirements does the work a standard can't. Treating a certificate of standard compliance as if it closes the whole GSPR row, rather than the specific clauses it addresses, is one of the most common gaps a Notified Body finds on review — not because the standard was applied incorrectly, but because it was asked to cover ground it was never scoped to cover.

Not the same question as Annex XVI

It's worth being precise about scope: the GSPR checklist under Annex I applies to every medical device on the market under MDR. It has nothing to do with the separate Annex XVI common-specifications question, which brings a fixed list of products without an intended medical purpose — dermal fillers, coloured contact lenses, high-intensity lasers among them — into scope under their own Commission-defined common specifications. A device already on the market under a GSPR checklist doesn't need an Annex XVI assessment unless it's one of the specifically listed product groups, and an Annex XVI product still needs its own GSPR checklist on top of the common specifications that apply to it. Conflating the two names in a submission is a fast way to raise a question that didn't need to exist.

None of this is exotic once the format is right, but it has to be right from the start — a GSPR checklist built as an afterthought creates rework across the whole technical file, not just one section. Our EU MDR technical documentation strategy work builds the checklist alongside the design and evidence plan, not after it, and our clinical evaluation report support closes the performance and benefit-risk requirements a design standard alone can't reach.