The GSPR checklist: your Annex I matrix, done properly.

Twenty-three requirements. Three chapters. No exemptions.

The General Safety and Performance Requirements live in Annex I of EU MDR 2017/745. They are the regulation's actual demands on your device — everything else in the MDR is largely about proving you meet them. They replaced the old MDD "Essential Requirements," and they apply to every device placed on the EU market, from a Class III implant down to a self-certified Class I app.

Annex I is organised in three chapters:

Twenty-three numbered requirements sounds manageable. But most break into lettered and numbered sub-clauses — GSPR 23 alone runs for pages — so a fully expanded checklist typically has well over a hundred rows that each need an answer.

Annex II, Section 4 — the four things you must show.

The MDR never says "checklist." What it says, in Annex II Section 4, is that your technical documentation must contain the information needed to demonstrate conformity with the GSPRs, including:

• Which GSPRs apply to your device — and an explanation of why the others do not. Silence on a requirement is not an option; every line gets either evidence or a justification.
• The method used to demonstrate conformity with each applicable GSPR — testing against a standard, your risk management process, a usability study, a clinical evaluation, a benefit-risk analysis.
• The harmonised standards, common specifications or other solutions applied. With editions. "ISO 14971" without a year is an incomplete citation.
• The precise identity of the controlled documents offering evidence — document ID, version, and where to find it in the technical documentation.

A matrix with one row per requirement is simply the only sane format for that information, which is why every notified body expects one and why most provide their own preferred template. If yours does, use theirs — the content below is the same either way.

The anatomy of a row that survives review.

Here is what a single completed row looks like for a software device, against GSPR 17.2 — the requirement that software be developed in accordance with the state of the art, taking into account the development lifecycle and risk management:

Notice what the row does not say: "complies." Compliance is the conclusion the reviewer draws from the evidence — it isn't itself evidence.

Harmonised, state of the art, and the order to reach for them.

Column four has a hierarchy. Work down it:

1. Common specifications first. Where the Commission has adopted a common specification (Article 9), you comply with it — or you carry the burden of justifying that your solution is at least equivalent.
2. Harmonised standards next. Standards cited in the Official Journal under the MDR (the EN editions, with their Z-annexes mapping clauses to GSPRs) give you a formal presumption of conformity (Article 8) for the requirements they cover. EN ISO 14971:2019/A11:2021 and EN ISO 13485:2016/A11:2021 are the workhorses.
3. State of the art for everything else. The MDR's harmonised list is far shorter than the old MDD list, so widely used standards — IEC 62304 among them — are typically applied as state of the art. You get no presumption, but a recognised standard, applied in full and cited by edition, is exactly the conformity argument reviewers expect.
4. In-house methods last. Legitimate where no standard exists, but expect to defend the method itself, not just the results.

Whatever you cite, cite the edition you actually used — and check it's still current when the file is reviewed, because a superseded edition in your matrix invites a finding even when the work itself was sound.

The five deficiencies reviewers see constantly.

• "Complies" with nothing behind it. A row that says the device complies with GSPR 10 — no standard, no test report, no document reference — is the single most common finding. Every applicable row needs a resolvable evidence pointer.
• Unjustified N/As. "Not applicable" without a device-specific rationale is read as "didn't look." The justification can be one sentence; it has to exist and it has to be defensible.
• Stale or wrong standard editions. Citing the MDD-era harmonised edition, an undated standard, or a standard that doesn't actually cover the clause it sits next to.
• A matrix that disagrees with the rest of the file. Claims in the IFU that the clinical evaluation doesn't support; risks in the matrix the risk file doesn't contain; document versions that don't match the documents. Reviewers cross-read — under MDR they cross-read more than ever.
• A matrix written the month before submission. The GSPR checklist is a gap-analysis tool. Started early in design, it tells you which testing and documentation you still owe while you can still plan for it. Written last, it can only report the gaps you no longer have time to close.

A living document, not a submission artefact.

The matrix decays the moment anything it points at changes: a design change makes a row's evidence stale, a new standard edition lands in the Official Journal, a post-market finding rewrites part of the risk file. Whoever owns the technical file needs a routine — at design changes and at a fixed review interval — for re-checking that every evidence pointer still resolves to a current document.

This is the part teams underestimate. Building the matrix once is a few weeks of focused work. Keeping a hundred-plus rows synchronised with a moving technical file, by hand, in a spreadsheet, is the part that quietly eats your quality engineer's quarter — and it's exactly the kind of bookkeeping that should be done by construction, with each row linked to the live document it cites rather than to a copy-pasted reference.

Common questions.