GSPR: General Safety and Performance Requirements (MDR & IVDR)

GSPR stands for General Safety and Performance Requirements: the list of requirements in Annex I of the EU MDR (2017/745) and IVDR (2017/746) that every medical device and in-vitro diagnostic must meet before it can carry a CE mark. You demonstrate compliance in your technical documentation, almost always in the form of a GSPR checklist — a table which states, for each requirement, whether it applies, how you conform, which standards you applied and where the evidence lives.

There is no shortage of vague GSPR explainers online. This guide covers what auditors actually look at: how Annex I is structured, what the checklist must contain (the regulation is surprisingly specific about this), and how to fill it out without creating problems for your future self. If you just want to start writing, download our free GSPR checklist template — it contains all MDR Annex I requirements pre-filled with typical standards and evidence documents for software medical devices.

From Essential Requirements to GSPRs

If you find references to an "Essential Requirements checklist" or "ER checklist", that is the same concept under the old Medical Device Directive (MDD). The MDR replaced the MDD's 13 Essential Requirements with 23 General Safety and Performance Requirements and renumbered everything in the process.

This matters for legacy devices: an MDD-era ER checklist cannot be relabelled as a GSPR checklist. The MDR added entirely new requirements — software lifecycle and IT security expectations, requirements for devices used by lay persons, expanded labelling content — and moved the old ones around. Transitioning a legacy device means re-mapping your evidence against Annex I of the MDR, not renaming a column header.

How Annex I Is Structured

MDR Annex I contains 23 numbered requirements in three chapters:

Chapter I applies to every device, no exceptions. Requirement 1 sets the tone: devices must achieve their intended performance and be safe under normal conditions of use, with any residual risks acceptable against the benefits — judged against the state of the art. Requirement 3 requires a documented risk management system over the whole lifecycle, which in practice means an ISO 14971 risk management process.

Chapter II is where the "not applicable" entries accumulate. A pure software product has no biological-safety or radiation profile, so requirements like 11 (infection) or 16 (radiation) will not apply — but you must say so explicitly, with a rationale. Requirement 17 (electronic programmable systems) is the software chapter: development lifecycle, repeatability and reliability, IT security, and mobile-platform considerations.

Chapter III is a single requirement, but a long one. It defines the mandatory content of your label and instructions for use, and it is one of the most common sources of notified body findings because its sub-requirements are detailed and easy to skip.

The GSPR Checklist

The MDR never uses the word "checklist". What it requires — in Annex II, Section 4, which defines your technical documentation — is information demonstrating conformity with Annex I, and it names four things your documentation must include:

1. the GSPRs that apply to the device, and an explanation as to why others do not apply;
2. the method or methods used to demonstrate conformity with each applicable requirement;
3. the harmonised standards, common specifications or other solutions applied; and
4. the precise identity of the controlled documents offering evidence of conformity, with cross-references to their location in the technical documentation.

A table with one row per requirement is simply the only sensible way to present those four things, which is why every manufacturer and notified body works with a checklist. The European Commission itself publishes one as a form: Annex 6 of MDCG 2021-8, its GSPR checklist template for clinical investigation applications.

The four Annex II items map directly onto checklist columns. Our template uses this structure:

How to Fill It Out

Work through the checklist in this order, not row by row from a blank page:

1. Decide applicability first. Go through all 23 requirements and mark each one applicable or not, based on your device's characteristics. Write the rationale for every "not applicable" immediately — "Not applicable: the device is standalone software and emits no radiation" is enough, silence is not.

2. Assign your method of conformity. For most requirements this is compliance with a standard. Where no standard fits, describe your own solution — testing, analysis, design measures. This is what Annex II means by "methods": a reviewer must be able to see how you claim conformity, not just that you claim it.

3. Cite standards precisely. Harmonised standards (published in the Official Journal of the EU) give you a presumption of conformity, so prefer them where they exist. Many relevant standards are not (yet) harmonised under the MDR — IEC 62304 for software lifecycle is a prominent example — and you can still cite them as state of the art. Either way, record the exact version and amendment, e.g. EN ISO 14971:2019/A11:2021, and check the current OJEU listing rather than copying versions from an old checklist.

4. Reference evidence by document ID. Annex II asks for the "precise identity" of the evidence. "See risk management documentation" will earn you a finding; "Risk Management Report, doc ID RMR-001, section 4" will not. Every referenced document must exist, be under document control and match the version you submitted.

5. Review the checklist against the evidence, not the other way around. The most useful internal review question is: if I open the referenced document, does it actually demonstrate what this row claims?

Three example rows for a software medical device:

Common Pitfalls

Marking everything applicable "to be safe". Every "yes" needs a standard or method and evidence. Claiming conformity with requirements that cannot apply to your device signals that nobody thought about applicability, and it multiplies your evidence burden for no benefit.

Empty rationales for "not applicable". Annex II explicitly requires an explanation of why requirements do not apply. This is the single easiest finding for a reviewer to write.

Superseded standard versions. Checklists inherited from older projects routinely cite EN ISO 14971:2012 or other withdrawn versions. Standards and their harmonisation status change; the checklist has to track them.

Recycled MDD checklists. As above — the numbering, scope and content changed. A checklist with 13 rows is an ER checklist, whatever its title says.

Vague evidence references. Rows pointing at "technical file" or "QMS records" fail the "precise identity" requirement. Reference controlled documents by ID, and keep the references current when documents are renamed or split.

Treating it as a one-time exercise. The GSPR checklist is a living part of your technical documentation. New standard versions, design changes and post-market findings all trigger updates.

GSPRs Under the IVDR

The IVDR follows the same architecture with its own Annex I: 20 requirements in three chapters, with Chapter II titled "performance, design and manufacture" to reflect the central role of performance characteristics (requirement 9) for diagnostics, and software addressed in requirement 16. The Annex II technical-documentation logic — applicability, methods, standards, precise evidence references — is identical, so everything above applies to IVD manufacturers with different requirement numbers.

Software-based IVDs raise their own mapping questions; see our Q&A on addressing IVDR Annex I performance requirements for SaMD-IVDs in the GSPR checklist.

Frequently Asked Questions

What does GSPR stand for?

General Safety and Performance Requirements — Annex I of the EU MDR 2017/745 and IVDR 2017/746. The plural "GSPRs" refers to the individual requirements.

Is a GSPR checklist mandatory?

No specific form is mandatory, but the content is: Annex II, Section 4 requires your technical documentation to state which requirements apply, why others do not, your methods of conformity, the standards applied and precise evidence references. A checklist is the universally accepted way to do that, and notified bodies expect one.

Who reviews the GSPR checklist?

For devices of class IIa and above, your notified body reviews it as part of the technical documentation assessment. Class I manufacturers self-declare conformity — the checklist still has to exist in the technical documentation and a competent authority can ask for it.

How many GSPRs are there?

MDR Annex I contains 23 numbered requirements across three chapters; IVDR Annex I contains 20. Most have sub-requirements, so a complete checklist typically runs to well over a hundred rows.

Start With the Template

Writing a GSPR checklist from the raw Annex I text is slow and error-prone. Our free GSPR checklist template contains every MDR Annex I requirement with applicability, standards and evidence columns pre-filled for a typical software medical device — edit the rationale and evidence references to match your device instead of starting from a blank table.

If you want the surrounding technical documentation handled too, Formwork, our eQMS, ships these templates pre-loaded with document control, so your checklist references point at documents that actually exist.

Sources

• MDR (EU) 2017/745, Annex I: the General Safety and Performance Requirements. Annex II, Section 4 defines the required demonstration of conformity.
• IVDR (EU) 2017/746, Annex I: the IVD General Safety and Performance Requirements.
• MDCG 2021-8, Annex 6: the Commission's GSPR checklist template for clinical investigation applications.
• European Commission: harmonised standards for medical devices: current OJEU harmonisation status. Checked on 4 September 2026; verify before relying on a presumption of conformity.