What is the GSPR checklist?

In short: The GSPRs (General Safety and Performance Requirements, MDR Annex I) are the requirements every device must meet. The GSPR checklist maps each applicable requirement to the standard you applied and the evidence proving conformity. It functions as the spine of the technical file — the index a Notified Body reviews against.

What the checklist actually contains

MDR Annex I lists the General Safety and Performance Requirements every device has to satisfy — covering everything from general design and manufacturing safety to specific requirements for devices with a measuring function or those incorporating software. Not every requirement applies to every device; the checklist's job is first to determine which ones apply to yours, then for each applicable requirement, record which harmonised standard, common specification, or other means you're using to demonstrate conformity, and where the supporting evidence lives in your technical file. Two practical nuances: requirements you mark as non-applicable need a documented justification for the exclusion — an "N/A" with no rationale is a common Notified Body finding — and only harmonised standards (those cited in the Official Journal) carry a formal presumption of conformity. The harmonised set under MDR is still relatively thin, so many devices legitimately rely on state-of-the-art standards that aren't formally harmonised.

Why it's the document to build first, not last

Because a Notified Body reviews your GSPR checklist as the index into the rest of the file, gaps here are disproportionately visible: a requirement marked applicable with no standard cited, or a standard cited with no evidence reference, reads as an unfinished file even if the underlying work exists elsewhere. Building the checklist early — before writing the detailed supporting sections — gives you a clear map of what evidence you still need to produce, rather than discovering gaps only once a reviewer finds them.

A practical habit

Revisit the checklist whenever a design change, new feature, or updated standard version affects an already-mapped requirement. Treating it as a living document, not a one-time exercise completed before submission, keeps your evidence current and avoids a scramble to reconcile the checklist with reality right before a Notified Body review.

Where next: Building an MDR Technical File and CER · What actually goes into a technical file?

Talk to us about building your GSPR checklist. Book an expert conversation →