What Is General Safety and Performance Requirements (GSPR)? What You Need To Know

A well-structured GSPR checklist can make the difference between a smooth audit and weeks of scrambling to rebuild evidence chains. Most teams get the initial checklist right. The hard part is keeping it current as the device changes, standards get updated, and post-market data rolls in.

This guide covers what GSPR is, how Annex I is structured, what auditors expect, and where documentation typically breaks down.

What Is General Safety and Performance Requirements (GSPR)?

General Safety and Performance Requirements (GSPR) are the legal obligations your medical device must satisfy to be placed on the EU market under the Medical Device Regulation (MDR) 2017/745 or the In Vitro Diagnostic Regulation (IVDR) 2017/746.

A GSPR defines the outcome your device must deliver. A harmonized standard is one way to prove you meet that outcome. The regulation itself makes this distinction clear. Devices must comply with the safety and performance requirements of the applicable legislation, not necessarily with the clauses of a specific standard.

Teams sometimes treat harmonized standards as the requirement itself. When that happens, the GSPR checklist ends up mapping to standards instead of mapping standards back to legal obligations, and auditors notice.

Where Do GSPRs Live in the Regulation?

When an auditor asks where your conformity claim is grounded, the answer starts in Annex I. Both the MDR and IVDR require devices to comply with the GSPR set out there. For in vitro diagnostics, Article 56 of the IVDR governs the performance evaluation process.

The technical documentation needed to demonstrate conformity is described in Annex II, Section 4. Most teams organize this as a GSPR checklist that includes:

• Applicable GSPRs: Which requirements apply to your device, and why others do not.
• Conformity methods: How you demonstrate conformity with each requirement.
• Standards applied: Which harmonized standards or Common Specifications you used.
• Document references: The specific controlled documents and their locations in your technical file.

That last item, the cross-reference to specific document locations, is where traceability usually starts to break. A general pointer to “the risk management file” is not enough. Auditors expect a specific document, version, and location within that document for each GSPR row.

What Changed From Essential Requirements to GSPR?

Before the MDR, these obligations were called Essential Requirements (ERs) under the older Medical Device Directive (MDD). The MDR replaced that framework with GSPR, and the change was more than a rename.

The biggest practical change is the “state of the art” obligation in Section 1. Your device must be designed and manufactured using what the industry currently considers current practice. That means your GSPR checklist has to reflect the latest applicable standards, even if those have changed since your original certification.

The Three Chapters of GSPR in Annex I

Annex I of the MDR is organized into three chapters covering 23 sections. Chapters I and III apply broadly to medical devices. Chapter II depends on your device’s specific characteristics, and you need to document why any section does not apply.

Chapter I: General Safety and Performance (Sections 1-9)

These sections set the baseline for your safety argument. Devices must be safe and effective, with residual risks acceptable when weighed against patient benefits. Section 8 covers risk management, requiring that all known and foreseeable risks be minimized and acceptable relative to the device’s benefits. ISO 14971:2019 is the standard most teams use for this section.

Chapter II: Device-Specific Requirements (Sections 10-22)

These sections map to your device’s physical, chemical, biological, and software characteristics. If your device includes software, Section 17 is where traceability requirements increase. It maps to IEC 62304 for software lifecycle processes and introduces cybersecurity requirements under Section 17.2 that had no explicit equivalent under the MDD. Section 18.8 adds a related requirement for devices to be designed against unauthorized access that could interfere with intended function.

Chapter III: Labeling and Instructions for Use (Section 23)

Section 23 has four subparts, not three. Teams sometimes miss Section 23.3 and end up with incomplete traceability in their GSPR checklist. Auditors expect each subpart of Section 23 to be traced separately, with specific justification for any subpart marked as not applicable.

What You Need To Demonstrate for GSPR Conformity

Building the checklist is the easy part. Keeping the evidence current as the device and its standards evolve is where teams get stuck. The MDR requires continuous compliance, so your technical documentation has to reflect the current state of the device throughout its entire market life.

Your Risk File Has To Cover the Full Lifecycle

ISO 14971:2019 follows the device from design through production and post-production. Your risk management file pulls together the plan, analysis, control measures, benefit-risk determination, and final report.

What makes the MDR different from the older directive is the mandatory feedback loop. Post-market surveillance (PMS) data feeds into the clinical evaluation report, which feeds into the risk management file, which feeds back into your GSPR conformity claims. If one of those links breaks, the whole argument weakens.

Clinical Evidence Has To Map Back To Specific GSPRs

Article 61(1) of the MDR requires clinical data to support Sections 1 and 8 of Annex I at minimum. Your Clinical Evaluation Plan must identify which specific GSPRs need clinical evidence.

For Class III and implantable devices, the post-market clinical follow-up report and Summary of Safety and Clinical Performance must be updated at least annually. The connection between clinical data and specific GSPR rows needs to stay valid through every report cycle, including years after the original filing.

PMS Has To Feed Back Directly Into GSPR Conformity

Your PMS system runs continuously. The MDR requires it to actively gather, record, and analyze data on your device’s quality, performance, and safety throughout its lifetime. Class IIa through III devices require Periodic Safety Update Reports (PSURs) that cover:

• Benefit-risk conclusions: Current conclusions on the benefit-risk determination.
• Post-market clinical follow-up findings: Key findings from ongoing clinical follow-up.
• Corrective actions: Any preventive or corrective actions taken.

A PSUR finding that shifts the benefit-risk profile may require updating the evidence behind specific GSPR rows. That makes the update cycle a traceability event, not a routine reporting exercise.

How GSPR Connects to Product Traceability

The traceability challenge with GSPR is a scale problem. Each checklist row needs cross-references to specific controlled documents, and that multiplies across product families, design changes, and standard transitions.

The bidirectional traceability chain that auditors expect runs from user needs through design inputs, design outputs, and verification and validation evidence, down to specific GSPR rows and the standards used as evidence. Each row needs a specific evidence reference, not a vague file-level citation.

In practice, the problem is whether a change upstream is visible everywhere downstream before the next audit. When an upstream requirement changes, every downstream artifact needs to be flagged for review.

Jama Connect® is a requirements management and traceability platform built for regulated industries. Its pre-built medical device framework keeps design controls, risk traceability, and verification evidence connected in a single platform, so documentation reflects live data instead of manual assembly.

Where GSPR Documentation Breaks Down

Most documentation gaps are not caused by missing records. They come from documentation that was complete at one point but fell out of sync with the current device, the evidence, or the standards it references.

When Static Documents Fall Behind the Device

The typical failure mode is a GSPR checklist that was accurate at initial certification but has not kept pace with changes. A material change, a software update, or a manufacturing process modification each affects different GSPR sections. Unless your change control procedure explicitly triggers a GSPR impact assessment, the checklist goes stale. Outdated verification and validation documentation is one of the first gaps auditors surface during submission review.

When Standards Get Superseded

Standard transitions create a cascading update problem. When a harmonized standard is withdrawn or replaced, every GSPR checklist entry that references it needs to be identified, the gap between old and new versions analyzed, and the evidence cross-references updated. For teams with multiple devices on the market, that means finding the affected reference in every GSPR row, for every device.

The state-of-the-art obligation adds another layer. Even when you are using a current harmonized standard, if a newer version represents current practice, you may need to justify continued use of the older version.

Building GSPR Compliance That Survives Audits

The shift from MDD to MDR is a structural change in how you demonstrate and maintain conformity. Risk management feeds clinical evaluation, which feeds post-market surveillance, which feeds back into the GSPR checklist. Every link in that chain needs to stay current and auditable.

Jama Connect supports this continuous conformity workflow by keeping design controls, risk files, and GSPR evidence connected to live project data as the device and its regulatory context evolve. Start a free 30-day trial and see how the framework fits your team’s conformity workflow.

Frequently Asked Questions About GSPR

What is a GSPR checklist under EU MDR?

A GSPR checklist is the Annex I conformity matrix in your technical documentation. It identifies which GSPRs apply, describes the methods used to demonstrate conformity, lists the standards applied, and provides references to the specific controlled documents that contain the evidence.

Why do auditors find gaps in GSPR documentation?

The documentation usually existed at some point. The checklist, evidence references, and standards citations just fell out of sync over time as the device went through design changes or standard transitions. Static documents make that drift hard to detect until an auditor starts tracing evidence chains.

What kind of evidence should each GSPR row reference?

Each row needs a specific controlled document reference and its location in the technical file. Pointing to a general file like the risk management folder is not enough. Each row must identify the specific document, its version, and where within that document the evidence can be found.

When should a GSPR checklist be updated?

The checklist needs updating when standards are withdrawn or replaced, when design or intended-purpose changes occur, when new clinical or performance data changes the evidence base, or when post-market findings affect the benefit-risk profile. Any change that touches the controlled documents referenced in a GSPR row should trigger a review of that row’s evidence chain.