MDR GSPR Checklist: The Essential 2026 Guide to Annex I Safety and Performance Requirements

An MDR GSPR checklist is the table that shows, requirement by requirement, how a medical device meets the general safety and performance requirements in Annex I of Regulation (EU) 2017/745. It is a required part of the technical documentation, and a notified body reviewer will usually read it early.

Annex I has three chapters and 23 numbered requirements. For each one that applies, the manufacturer must state the method used to demonstrate conformity, the standards or common specifications applied and the evidence, such as test reports or risk management outputs. Requirements that do not apply must be justified.

This guide explains how to structure the checklist and what to record. The European Commission proposed amendments to the MDR and IVDR in December 2025, so check the current consolidated text on EUR-Lex before you finalize your documents.

What an MDR GSPR checklist must show

The regulation requires manufacturers to demonstrate conformity with the applicable general safety and performance requirements. The checklist is where that demonstration is organized. Annex II, which lists the technical documentation, requires a section on the requirements and the solutions adopted, including the standards, common specifications or other solutions applied and the evidence.

For each requirement, the checklist should answer four questions: does it apply, how is it met, what evidence proves it and where is that evidence found in the technical file. A reviewer should be able to follow each line to a document without guessing.

The legal text is on EUR-Lex at Regulation (EU) 2017/745 on EUR-Lex. Our overview of EU MDR gives the wider context, and MDR technical documentation explains how the checklist fits into the file.

Chapter I: general requirements

Chapter I sets the tone. Devices must achieve the performance intended by the manufacturer and be designed and manufactured so that, under normal conditions of use, they are suitable for their intended purpose and safe. Risks must be reduced as far as possible without adversely affecting the benefit-risk ratio.

It requires a risk management system established, implemented, documented and maintained throughout the life cycle, with risk control measures that follow a defined order of priority. It also covers usability, the lifetime of the device, transport and storage, and the requirement that any undesirable side effects are acceptable against the benefits. Requirement 9 addresses devices without an intended medical purpose listed in Annex XVI.

For each line, reference your risk management file, your clinical evaluation and your usability engineering file. The link to standards is explained in MDR harmonised standards.

Annex I part	Requirements	Typical content
Chapter I	1 to 9: general requirements	Performance, risk management, benefit-risk, lifetime
Chapter II	10 to 22: design and manufacturing	Materials, infection, software, electrical, radiation, lay use
Chapter III	23: information supplied	Labelling, instructions for use, symbols

Chapter II: design and manufacturing requirements

Chapter II has requirements 10 to 22 and is the longest section. It covers chemical, physical and biological properties, infection and microbial contamination, substances and materials of biological origin, construction and interaction with the environment, devices with a measuring function, radiation, programmable electronic systems and software, active and connected devices, mechanical and thermal risks, energy or substance delivery and lay-use devices.

Not all will apply to a given device. A simple passive device may exclude software, radiation and energy supply, but each exclusion needs a one-line reason. Do not leave blanks. A reviewer cannot tell whether a blank means not applicable or overlooked.

For software and connected devices, requirement 17 brings in software life cycle, risk management, verification, validation and cybersecurity. Cross-reference your software documentation and security files.

Chapter III: information supplied with the device

Requirement 23 covers labels, instructions for use and other information. It is long and includes sub-sections on the label, the packaging, instructions for use and information for implant cards. It also addresses symbols and identification colors and the language requirements of Member States.

The evidence here is the actual label and instructions, plus the usability studies showing users understand them. Include a label matrix if you market in several countries.

Link the checklist to the unique device identification work, which is described in unique device identification, and to registration in the EU database, covered in EUDAMED registration.

How to write each line of the checklist

Keep the wording consistent. A typical line reads: requirement number and title, applicability, method of conformity, standards or specifications applied with version, evidence document references and status. Use a stable document numbering system so references do not break when files are updated.

Cite standards precisely, with edition and year. Where you use harmonised standards, note whether the harmonisation covers the whole requirement or only part of it. Where you do not apply a standard, describe the alternative solution and its justification.

Avoid vague statements such as “complies with requirement” with no evidence. The notified body expects to see objective evidence, not a claim.

Keep the checklist alive after certification

The checklist is part of a living file. Update it when the design changes, when standards are revised, when post-market data shows new risks or when the clinical evidence changes. A change that affects a requirement should trigger a checklist review.

Feed post-market information back into it. Serious incidents, complaints and trend reports, discussed in MDR serious incident reporting and MDR PSUR, may show that a requirement is not as well met as you thought.

Name the person responsible. The person responsible for regulatory compliance should confirm that the documentation is complete and up to date.

A short MDR GSPR checklist example

Consider a Class IIa reusable surgical instrument. Requirement 11 on infection and microbial contamination applies, and the conformity method is validated cleaning and sterilization instructions, supported by test reports under the relevant standards and a packaging validation. Requirement 10 on biological properties applies, with a biological evaluation report. Requirement 17 on software does not apply, and the line states why.

Requirement 23 on information applies, with the label, the instructions and a usability file. The checklist links each line to a document number. A gap appears: the cleaning validation covers one detergent but the instructions list two. The team adds the second validation before submission. The example is illustrative, but it shows how an MDR GSPR checklist exposes mismatches between claims and evidence.

Always review the completed checklist against the instructions for use, since the two documents must agree.

Costs, timing and notified body review

The checklist takes time to prepare properly, and it is reviewed along with the rest of the documentation during conformity assessment. Planning matters because notified body capacity and fees affect your schedule. See notified body fees for what to expect, and EU MDR transition deadlines for the legacy device timeline.

Transition provisions and proposals to amend the regulation continue to change, so always confirm the current position on the Commission website and EUR-Lex.

Build in time for internal review before submission. A second person who did not write the checklist should check every line against the evidence.

Common gaps found in an MDR GSPR checklist

Reviewers see the same gaps again and again. Lines that cite a standard but not its version. Evidence references that point to documents that no longer exist. Not-applicable entries with no reason. Requirements on software and cybersecurity that are left thin because the software team never saw the checklist. Labels and instructions that say something different from the claims in the clinical evaluation.

A second group of gaps appears after changes: a new supplier, a modified material or a software update changes the evidence, but the MDR GSPR checklist is not revised. The simplest defense is a change control step that asks, for every change, which requirements are affected and whether the evidence is still valid.

A third gap is ownership. If one person writes the whole checklist, other functions do not check their own areas. Assign each chapter or requirement group to a named owner, such as design, regulatory, quality, clinical and software, and have them sign their section.

Building your first MDR GSPR checklist step by step

Start with the regulation text and copy every requirement into a table, including sub-paragraphs. Decide applicability for your device and write the reason. Identify the standards you already follow and map them to lines. Fill in the evidence references. Then run a review meeting where each owner walks through their lines and confirms the links.

Do this early in design, not at the end. Many requirements, such as usability and biocompatibility, drive design choices, and finding a gap late is expensive. A draft MDR GSPR checklist created at design inputs becomes a planning tool as well as a record.

Using a ready-made MDR GSPR checklist

Creating the table, the procedures and the linked documents from scratch is slow. A prepared template set provides a structure to adapt.

The EU MDR Toolkit provides 68 templates covering technical documentation under Annexes II and III, the GSPR conformity checklist, classification, conformity assessment, clinical evaluation, PMCF, UDI and EUDAMED. Adapt each item to your device and keep the evidence references current.

Whichever format you use, treat the MDR GSPR checklist as a working document that changes with your product.

MDR GSPR checklist FAQ

What is the GSPR checklist?

It is a table in the technical documentation that shows how a device meets each applicable general safety and performance requirement in Annex I of the MDR, with methods and evidence.

How many requirements are there?

Annex I contains 23 numbered requirements across three chapters, although many devices will find some do not apply.

Can I mark a requirement not applicable?

Yes, but you must justify it. Blank lines without a reason are a common cause of reviewer questions.

Is the GSPR checklist mandatory?

Yes. Annex II requires technical documentation to show conformity with the general safety and performance requirements, and the checklist is the standard way to present it.

Who reviews it?

The notified body reviews it for devices that need its involvement, and the competent authority can request it at any time.