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

What Annex I contains, and who it applies to.

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; almost everything else in the MDR is 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. In practice most of them break into lettered and numbered sub-clauses (GSPR 23 alone runs for pages), so a fully expanded checklist usually ends up with well over a hundred rows, and every row needs an answer.

The four things Annex II, Section 4 requires you to 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. Our advice: 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; writing the word in a cell adds nothing.

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 that it's still current when the file is reviewed. A superseded edition in your matrix invites a finding even when the work itself was sound.

The findings reviewers raise most often.

• "Complies" with nothing behind it. A row that says the device complies with GSPR 10, with no standard, no test report and no document reference behind it, is the single most common finding. Every applicable row needs an evidence pointer that resolves.
• 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, and under the MDR they cross-read more than ever.
• A matrix written the month before submission. Opened early, the checklist doubles as a gap analysis: it shows you which testing and documentation you still owe while there is still time to plan for it. Opened at the end, all it can do is deliver bad news.

The real work starts after the first version.

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.

In our experience, 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 what actually eats your quality engineer's quarter. It's also exactly the kind of bookkeeping that should happen by construction, with each row linked to the live document it cites rather than to a copy-pasted reference.

Common questions.