---
title: How to Document General Safety and Performance Requirements (Annex I Checklist)
description: The GSPR checklist maps every MDR Annex I requirement to the evidence in your technical file. Here is how to build one auditors will accept.
authors: Tibor Zechmeister, Felix Lenhard
category: Technical Documentation & Labeling
primary_keyword: GSPR Annex I checklist MDR
canonical_url: https://zechmeister-solutions.com/en/blog/document-gspr-annex-i-checklist
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# How to Document General Safety and Performance Requirements (Annex I Checklist)

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **A GSPR checklist is the table in section 4 of your MDR Annex II technical documentation that lists every General Safety and Performance Requirement in Annex I of Regulation (EU) 2017/745, marks each as applicable or not applicable with a reasoned justification, names the method used to demonstrate conformity (typically a harmonised standard, an in-house test, or a literature-based argument), and points to the specific evidence elsewhere in the technical file that proves it. Article 5(2) makes conformity with the Annex I GSPR a legal condition for placing a device on the market. The checklist is how you show it. A working checklist covers Annex I Chapter I (requirements 1 to 9, general requirements), Chapter II (requirements 10 to 22, design and manufacture), and Chapter III (requirement 23, information supplied with the device), with working bidirectional cross-references into the rest of the file. Build it early, keep it live, and an auditor can walk your entire conformity argument from this one table.**

**By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.**

---

## TL;DR

- MDR Article 5(2) requires that a device placed on the EU market meets the General Safety and Performance Requirements set out in Annex I of Regulation (EU) 2017/745. There is no path to CE marking that avoids this.
- Annex II section 4 is the location inside the technical documentation where the GSPR conformity argument lives. It is commonly built as a table — the GSPR checklist.
- Annex I is divided into three chapters: Chapter I (general requirements, 1 to 9), Chapter II (requirements regarding design and manufacture, 10 to 22), and Chapter III (requirements regarding the information supplied with the device, 23 with its sub-points).
- Every row in the checklist has four parts: the requirement text or reference, the applicability decision with justification, the method of demonstration, and the evidence pointer into the rest of the technical file.
- Harmonised standards cited in the Official Journal under MDR Article 8 provide presumption of conformity for the specific requirements they cover. Used correctly, they are the cheapest path to most Chapter II rows.
- The auditor will sample this table hard. If a row points to evidence that does not exist or does not say what the row claims, it is a nonconformity. Integrity of cross-references matters more here than anywhere else in the file.

---

## Why the GSPR checklist is the centre of the technical file

The GSPR checklist is not paperwork. It is the legal hinge of the entire conformity assessment. MDR Article 5(2) states the rule plainly: a device shall meet the General Safety and Performance Requirements set out in Annex I which apply to it, taking into account its intended purpose. Article 10(1) repeats the obligation on manufacturers: manufacturers shall ensure that their devices have been designed and manufactured in accordance with the requirements of the Regulation. Annex II section 4 then specifies that the technical documentation must contain the information demonstrating conformity with those general safety and performance requirements — including a justification, validation, and verification of the solutions adopted to meet them.

In practice that means one thing. Somewhere in your technical file there is either a GSPR checklist that covers every requirement in Annex I, or you do not have a defensible submission. Notified Body auditors sample this section more heavily than any other because it is the map into the entire file. Pick a row, follow the reference, read the evidence, judge whether the evidence demonstrates what the row claims. If the chain holds, the file holds. If the chain breaks, the file breaks.

The seven steps below describe how to build a checklist that holds.

## Step 1 — Structure the checklist to Annex I Chapter I (general requirements 1 to 9)

Annex I Chapter I contains the foundational general requirements. Number 1 requires that devices achieve the performance intended by their manufacturer and be designed and manufactured so that they are suitable for their intended purpose — safe and effective, and not compromising the clinical condition or safety of patients or users under normal conditions of use. The remaining requirements in Chapter I cover the reduction of risks as far as possible, risk management as a continuous iterative process, the benefit-risk ratio that must remain acceptable, the elimination or reduction of risks through safe design, protective measures, and information for safety — and the requirement that the characteristics and performance of the device not be adversely affected during the lifetime of the device.

Your checklist starts with one row per requirement in Chapter I. Do not paraphrase the requirement into your own language inside the row — quote the Annex I numbering and use the official wording or a tight, accurate summary of it. The auditor is reading against the Regulation, not against your interpretation of it.

Chapter I is where the benefit-risk determination lives (GSPR 1 and 8), where the continuous risk management process is anchored (GSPR 3), and where the hierarchy of risk control is set out (GSPR 4) — eliminate or reduce risks as far as possible through safe design and manufacture first, then adequate protective measures, and only then information for safety. Every subsequent row in your file traces back into Chapter I through this hierarchy. Get Chapter I right and Chapter II becomes much easier to structure.

## Step 2 — Cover Annex I Chapter II (design and manufacture 10 to 22)

Annex I Chapter II is the longest chapter. It runs from requirement 10 to requirement 22 and covers chemical, physical, and biological properties (10), infection and microbial contamination (11), devices incorporating a substance considered to be a medicinal product (12), devices incorporating materials of biological origin (13), construction of devices and interaction with their environment (14), devices with a diagnostic or measuring function (15), protection against radiation (16), electronic programmable systems including software (17), active devices and devices connected to them (18), particular requirements for active implantable devices and their connected devices (19), protection against mechanical and thermal risks (20), protection against risks posed to the patient or user by devices supplying energy or substances (21), and protection against risks posed by devices intended for use by lay persons (22).

Most startup devices do not touch every Chapter II requirement. A pure software-as-a-medical-device will have very little to say under 10, 11, 13, or 20 but will have a great deal to say under 14 and 17. An electromechanical device with patient contact will have dense content under 10, 14, 17, 18, and 20. A non-active diagnostic device with a measuring function will have a specific obligation under 15 that its software sibling does not. Work through the chapter requirement by requirement, deciding applicability for each.

The common mistake is to fold all of Chapter II into a single block and hope the auditor reads it as coverage. Do the opposite. One row per numbered requirement — and for long requirements with sub-points (17 on software is the most common example), one row per sub-point. The rows are cheap. The granularity is free. The findability is the whole point.

## Step 3 — Cover Annex I Chapter III (information supplied with the device, requirement 23)

Annex I Chapter III contains a single numbered requirement — number 23 — on the information supplied with the device. It is a long one. Its sub-points cover the general requirements for information supplied by the manufacturer, the information on the label, the information in the instructions for use, and the specific requirements for each of those for different categories of device.

A short Chapter III checklist is almost always a broken Chapter III checklist. Chapter III is where your label content, your IFU content, your symbols, your warnings, and your user-facing safety information get their legal anchor. Every warning on the label should trace back to a specific 23 sub-point and to a specific risk control in the risk management file. Every IFU passage that carries a safety function should trace the same way. If Chapter III in your checklist is two rows, you have not read 23 carefully enough.

Cross-reference Chapter III rows into Annex II section 2 (information supplied by the manufacturer — the labels and IFU) and into section 5 (risk management file, where the information-for-safety controls originate). A working Chapter III checklist makes labelling changes cheap because the trace is already in place. A broken one makes every labelling change a small crisis.

## Step 4 — For each item, mark applicable or not applicable with a reasoned justification

Every row in the checklist has an applicability decision. "Applicable" means the row affects this device and evidence exists somewhere in the file. "Not applicable" means the row does not affect this device, and the reason is written down.

"Not applicable" without a reason is a blank. Auditors treat blanks as findings. The justification does not need to be long — it needs to be specific. "Not applicable: the device has no patient contact and does not deliver energy, so requirement 21 on energy and substance supply does not apply" is a valid justification. "N/A" is not.

The justification should reference the intended purpose and the device description from section 1 of Annex II, because applicability is decided against what the device actually is and what it actually does, not against a generic device class. A device that looks like it should not touch a biocompatibility requirement because "it is software" may still touch one if the software controls a connected piece of hardware with patient contact. Think through applicability carefully, and write the reasoning down so the auditor can follow it without asking you.

A useful discipline: when in doubt, mark applicable. Applicable with a short justification and a reference to the risk management file is always defensible. Not applicable that turns out to be wrong is a finding and sometimes a major one.

## Step 5 — For each applicable item, point to specific evidence

Every applicable row needs a method of demonstration and an evidence pointer. The method is one of a small set: conformity with a harmonised standard, conformity with an in-house test or engineering analysis, conformity demonstrated through the risk management file under EN ISO 14971:2019+A11:2021, conformity demonstrated through the clinical evaluation, or a combination.

The evidence pointer is the part that breaks most checklists. The pointer must name a specific document with a stable identifier (not a page number or a file name that can change), the version of that document, and — ideally — the specific section or clause inside it. A pointer that says "see risk file" is not a pointer. A pointer that says "RMF-001 v3.2, section 7.4.2, hazard H-034 and its control C-051" is a pointer.

The cross-reference has to work in both directions. The GSPR row points into the evidence document. The evidence document (or the master index) knows which GSPR rows depend on it. When the evidence document is updated, every dependent row in the checklist is reviewed in the same change. This bidirectional discipline is where the file either holds together or falls apart across revisions.

Auditors sample this heavily. They pick three or five rows, follow the chain, and form an impression of the whole file from what they find. A broken chain in one row casts doubt on every other row. An intact chain in the sampled rows builds confidence quickly. Integrity here is leverage.

## Step 6 — Use harmonised standards for presumption of conformity

MDR Article 8 establishes the role of harmonised standards. A device in conformity with a harmonised standard — or the relevant parts of one — is presumed to be in conformity with the requirements of the Regulation covered by that standard or parts of it, provided the references of the standard have been published in the Official Journal of the European Union.

This is the single most useful sentence in the Regulation for a startup building a GSPR checklist. Where a harmonised standard exists for a requirement and you can demonstrate conformity with that standard, you get presumption of conformity for the specific requirements the standard covers. That is cheaper, faster, and more defensible than inventing your own test methods and arguing them from scratch.

The practical move is to work Chapter II of Annex I against the current list of harmonised standards published in the Official Journal under MDR Article 8. For each applicable requirement, ask whether a standard covers it. For requirement 10 on chemical, physical, and biological properties, the biological evaluation standard EN ISO 10993-1:2025 is commonly used for the biological side. For requirement 14 and related aspects of design, EN ISO 14971:2019+A11:2021 on risk management supports the risk-based arguments. EN ISO 13485:2016+A11:2021 anchors the QMS obligations around the file. For software in requirement 17, EN 62304:2006+A1:2015 supports the software lifecycle claim. For usability aspects, EN 62366-1:2015+A1:2020 supports the usability engineering argument. For medical electrical equipment, the EN 60601 series supports safety and EMC.

Two cautions. First, harmonised status can change — always check the current Official Journal listing for the standard and edition before relying on it for presumption of conformity. A standard that was harmonised two years ago may not be today, and a standard that was not harmonised may now be. Second, presumption of conformity is not the same as coverage of everything in a requirement. A standard covers what it covers. Read the standard's scope and map it to the specific GSPR sub-point. Do not assume that citing ISO 13485 makes the whole file presumptively conformant — it does not.

Used carefully, harmonised standards turn Chapter II from a writing exercise into a mapping exercise. That is usually the fastest and safest path through most of the checklist.

## Step 7 — Keep the checklist current with design changes

The checklist is a living document. Every design change that could affect a GSPR row triggers a review of that row. Every new test report that lands in the file updates the evidence pointer. Every label change updates a Chapter III row. Every risk control change updates the cross-reference from Chapter I and Chapter II into the risk management file.

The common failure mode is building the checklist once, submitting it to the Notified Body, and treating it as frozen. Devices evolve. Standards get updated. New evidence comes in from post-market data. The checklist that was accurate on submission day is out of date six months later unless it is actively maintained. A stale checklist looks exactly like a broken checklist to the next auditor who opens it.

Wire the checklist into the QMS change control process under EN ISO 13485:2016+A11:2021. Every change request that touches design, manufacturing, labelling, IFU, or risk control names the GSPR rows it affects. Every affected row is reviewed before the change closes. This is not extra work. It is the work that keeps the file true.

## Common gaps we see in startup GSPR checklists

Across the checklists we have reviewed in startup audits, the same gaps repeat.

- **Silent "not applicable" rows.** Requirements marked N/A with no justification, or with a one-word justification that does not stand up to reading.
- **Evidence pointers that name no document.** Rows that say "see technical file" or "covered by risk management" without a specific document and version.
- **Harmonised standard citations without version.** "EN ISO 14971" without the year and amendment, used for presumption of conformity — the presumption applies to the harmonised edition, not to whatever the team had on the shelf.
- **Chapter III collapsed into a single row.** Requirement 23 has substantial sub-structure and a one-row treatment almost always hides gaps in label and IFU coverage.
- **Unidirectional cross-references.** The checklist points into the evidence, but the evidence has no idea which rows depend on it. When the evidence changes, the checklist rots silently.
- **Rows locked to page numbers.** Document gets re-paginated, every pointer breaks at once.
- **Copy-paste rows from a template that describe a different device.** The placeholder content was not fully replaced and the row does not actually apply to the product at hand.

Every one of these is preventable. Each of them produces an audit finding that is pure friction — not a problem with the product, just a problem with how the product's conformity argument was written down.

## The Subtract to Ship angle

A GSPR checklist invites padding. Every team member wants to add rows for extra safety, sub-rows for internal processes, columns for project-management metadata, notes for future reference. The padded checklist then becomes hard to update, hard to audit, and internally inconsistent.

The Subtract to Ship move is to keep the checklist to exactly the structure of Annex I, with the four columns it needs — requirement, applicability with justification, method of demonstration, evidence pointer — and nothing else. Project metadata lives in the QMS, not in the checklist. Internal review history lives in the document control system, not in the checklist. The checklist stays tight and legible, and every row earns its place by tracing to an Annex I item.

The full methodology behind this discipline is in [the Subtract to Ship framework for MDR](/blog/subtract-to-ship-framework-mdr). Applied to the GSPR checklist, the rule is simple: the checklist is Annex I, your applicability decisions, and your evidence map. Nothing else belongs in it.

## Reality Check — Where do you stand?

1. Does your GSPR checklist have a row for every numbered requirement in Annex I Chapter I (1 to 9), Chapter II (10 to 22), and Chapter III (23 with its sub-points) — and for the sub-points within long requirements such as 17 on software?
2. For every row marked "not applicable," is there a reasoned justification that references the intended purpose and the device description?
3. For every applicable row, does the evidence pointer name a specific document with a stable identifier and a version, not a page number or a file name?
4. Where you rely on a harmonised standard for presumption of conformity, have you checked the current Official Journal listing to confirm the standard and edition are still harmonised?
5. Are cross-references between the checklist and the risk management file bidirectional, or does the risk file have no idea which GSPR rows depend on it?
6. Is Chapter III in your checklist a single row or a proper expansion against the sub-points of requirement 23?
7. When was the last time a design change triggered a review of the affected GSPR rows — and do you have a record of the review?
8. If the auditor picked three rows at random tomorrow, could they follow the chain to working evidence in under ten minutes?

## Frequently Asked Questions

**Is a GSPR checklist legally required under the MDR?**
The MDR does not literally say "you must have a GSPR checklist." It says in Article 5(2) and Article 10(1) that the device must meet the General Safety and Performance Requirements in Annex I, and in Annex II section 4 that the technical documentation must contain the information demonstrating conformity with those requirements — including a justification, validation, and verification of the solutions adopted. In practice every Notified Body expects this section to take the form of a checklist or table, because any other form is harder to audit. You are not obliged to call it a checklist, but you are obliged to demonstrate conformity row by row against Annex I.

**Where in Annex II does the GSPR checklist live?**
Annex II section 4 of Regulation (EU) 2017/745 is titled "general safety and performance requirements" and is the location for the checklist. Section 1 holds the device description, section 2 holds the labels and IFU, section 3 holds design and manufacturing information, section 5 holds the benefit-risk analysis and risk management file, and section 6 holds verification and validation. The GSPR checklist in section 4 cross-references into all of the others.

**How does presumption of conformity actually work?**
MDR Article 8 says that a device in conformity with the relevant harmonised standards — whose references have been published in the Official Journal of the European Union — is presumed to be in conformity with the requirements of the Regulation covered by those standards. Presumption of conformity means the burden of proof shifts. The Notified Body starts from the assumption that the device meets the covered requirements and only needs to check that you have actually complied with the standard. Without presumption, you have to argue conformity from first principles, which is slower and more exposed. The scope of presumption is limited to what the standard covers — it is never a blanket for the whole Regulation.

**Can I mark an entire chapter of Annex I as not applicable?**
Rarely. Chapter I (1 to 9) contains foundational requirements that apply to every device — the benefit-risk obligation, the risk management obligation, the requirement to reduce risks as far as possible. These do not get marked N/A. Chapter II has requirements that legitimately do not apply to many devices — a pure software device will not have a chemical, physical, and biological properties argument in the same sense an implant will — and these are marked N/A with a justification, one row at a time. Chapter III applies to any device that has labels or instructions for use, which is almost all of them. Blanket N/A decisions at the chapter level are almost always wrong.

**How detailed does the evidence pointer in each row need to be?**
Detailed enough that an auditor can open the referenced document and find the specific section that supports the row without asking you. A document name alone is too thin. A document name with a version and a section or clause is the right level. Identifiers must be stable across revisions — hence document IDs rather than page numbers.

**What happens if a harmonised standard we cited is withdrawn from the Official Journal?**
Presumption of conformity is tied to harmonised status. If the standard is withdrawn from the Official Journal, the presumption for citations to that edition goes with it. You can still use the standard as a technical reference, but the presumption argument is no longer available, and you have to either migrate to a new harmonised edition (if one exists) or demonstrate conformity by another method. This is why the cross-reference in the checklist must record the exact edition and why the checklist is reviewed whenever the harmonisation list changes. Always check the current Official Journal listing before relying on presumption.

**Should I build the GSPR checklist before or after the technical file?**
Before, and in parallel with the design. Building the checklist in the first month of the project forces every design decision to be traced to a GSPR item as it is made. The evidence columns will be full of "planned" and "TBD" early on — that is fine. The structure does the work of keeping the project honest against Annex I. A checklist built at the end of the project is a reconstruction, and reconstructions are where gaps hide.

## Related reading

- [Technical Documentation Under MDR: What It Is and Why Startups Get It Wrong](/blog/technical-documentation-under-mdr) — the hub post for the technical documentation cluster this checklist sits inside.
- [MDR Annex II: The Structure of Technical Documentation Explained](/blog/mdr-annex-ii-structure) — the full section-by-section walkthrough of the file the checklist belongs in.
- [How to Build Technical Documentation From Day One](/blog/build-technical-documentation-from-day-one) — the startup playbook for starting the file, and the checklist, on week one.
- [Device Description in Technical Documentation: What to Include](/blog/device-description-technical-documentation) — the section 1 content the checklist depends on for applicability decisions.
- [Common Technical Documentation Gaps Found in Startup Audits](/blog/common-tech-doc-gaps-startup-audits) — the pattern library of failures the disciplined checklist avoids.
- [Risk Management Under EN ISO 14971: A Startup Guide](/blog/risk-management-iso-14971-startup-guide) — the risk file the Chapter I and Chapter II rows cross-reference into.
- [How to Build a Risk Management File That Auditors Trust](/blog/risk-management-file-auditors-trust) — the bidirectional cross-reference discipline from the risk-file side.
- [Integrating Risk Management Into Design Controls](/blog/risk-management-design-controls-integration) — how Chapter I and Chapter II evidence is wired into the design from the first review.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology behind a lean, disciplined checklist.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 5(2) (devices placed on the market to meet the GSPR set out in Annex I), Article 8 (harmonised standards and presumption of conformity), Article 10(1) (manufacturer obligation on design and manufacture in accordance with the Regulation), Article 10(4) (technical documentation obligation), Annex I (General Safety and Performance Requirements — Chapter I, General requirements, 1 to 9; Chapter II, Requirements regarding design and manufacture, 10 to 22; Chapter III, Requirements regarding the information supplied with the device, 23), Annex II section 4 (general safety and performance requirements — location of the GSPR checklist inside the technical documentation). Official Journal L 117, 5.5.2017.
2. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.
3. EN ISO 14971:2019 + A11:2021 — Medical devices — Application of risk management to medical devices.

---

*This post is part of the Technical Documentation & Labeling series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Tibor has built and audited GSPR checklists on both sides of the Notified Body table. The discipline described here is the discipline that turns Annex II section 4 from the hardest part of the file into the easiest part of the audit.*

---

*This post is part of the [Technical Documentation & Labeling](https://zechmeister-solutions.com/en/blog/category/technical-documentation) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*