A GSPR checklist points to evidence, not intentions

Annex I of the EU MDR lists the general safety and performance requirements every device has to meet before it can carry a CE mark — construction, chemical and biological properties, labeling, the rest. Annex II, point 4, is where a manufacturer proves it did. The word most teams use for that proof, “checklist,” undersells what point 4 actually asks for: not a yes in every row, but the name of the specific document that earns the yes.

A list of requirements is not a list of proofs

Annex I states obligations — general requirements informed by risk management, requirements on chemical and physical properties, on infection and microbial contamination, on devices with a measuring or diagnostic function, on labeling and instructions for use, and more. Nothing in Annex I itself asks a manufacturer to show its work; it's a list of what the device has to be true of, not a template for demonstrating that it is. That demonstration lives one annex over, in the technical documentation structure Annex II sets out, specifically in the section labeled General Safety and Performance Requirements at point 4.

Four things point 4 actually asks for

Point 4 doesn't ask for a single column. It asks the documentation to include: which general safety and performance requirements apply to the device, with an explanation of why any others don't; the method or methods used to demonstrate conformity with each applicable requirement; the harmonised standards, common specifications, or other solutions actually applied; and the precise identification of the controlled documents offering evidence of conformity with each one. A table built to satisfy point 4 has to carry all four, requirement by requirement — not a single applicable/not-applicable column with a narrative summary bolted on afterward.

Citing a standard is not the same as citing the evidence

Most GSPR tables get as far as the third column and stop: a row that lists the requirement, marks it applicable, and names the harmonised standard used to address it — IEC 60601-1, ISO 10993-1, whatever fits. That's the method, not the proof the method was actually carried out and passed. Point 4(d) asks for something more specific than a standard's number: the precise identity of the controlled document — a test report, a validation record, a risk analysis section — that actually shows the work happened. A row that cites a standard with no document reference behind it has answered what method was chosen, not where the evidence that it worked can be found. A notified body auditor reading the file is checking for the second answer, not the first.

The table also has to mirror the device it describes

IVDR mirrors this same structure in its own Annex I and Annex II, point 4 — the pairing isn't unique to devices under MDR, and a GSPR table built for one regulation transfers cleanly to the other's parallel clause. What doesn't transfer automatically is currency: a table's rows go stale the moment a cited standard is revised, a design change moves the evidence a row was built on — the same reopening a design change owes the risk file — or a referenced document gets superseded without its row being touched. A template goes stale the same way any working document does: quietly, through drift the format itself doesn't force anyone to notice. A GSPR checklist that's only ever additive, never revisited against what it already claimed, is the clearest version of that failure mode — which is why the version previewed in the launch catalog ties each row to the document it depends on, not just the requirement it answers. If your team tracks that dependency differently, the contribution page is open for exactly that comparison.