Building a GSPR Traceability Matrix That Holds Up Under Scrutiny

Why most GSPR matrices fail

The GSPR traceability matrix is theoretically straightforward: take Annex I of EU MDR, list its 23 general safety and performance requirements, and for each one document how your device complies. In practice, this is one of the most common sources of Notified Body findings. Not because teams skip requirements, but because they fill in the matrix without the substance behind it.

A row in the matrix that says "ISO 10993-1 — not applicable — implanted device" tells an auditor nothing useful. A row that says "ISO 10993-1 — biological evaluation plan dated [date] — biocompatibility evaluation report ref BD-BIO-003 rev 2 — all materials in contact with tissue assessed, residual risk acceptable" gives them something to verify. The difference between these two entries is the difference between a matrix that creates audit risk and one that closes it.

What each entry needs to contain

For every GSPR you list, the matrix entry should answer four questions:

Is this requirement applicable to your device? If not, document the rationale — one specific sentence explaining why it does not apply. "Not applicable" with no explanation is a finding waiting to happen. For example: "GSPR 10.4 (devices emitting ionising radiation) — not applicable — device contains no radiation-emitting components; no ionising radiation in intended use."

Which standard or guidance covers this requirement? List the harmonised standard by full title and publication date. If you use a non-harmonised standard or a non-standard approach, say so and explain why it gives equivalent assurance. Using an outdated version of a harmonised standard without documenting your rationale is a risk — the presumption of conformity does not automatically extend to older editions.

What is the evidence document? Reference the actual document that demonstrates compliance — test report number, design specification reference, analysis document, or risk management file section. Version number, date, and document ID. If the document does not yet exist (e.g., you are in development), the matrix should show its status and expected date. A Notified Body reviewing a technical file at submission should be able to pull every referenced document and find it.

Is the requirement fully met, partially met, or is residual risk documented? This is where many teams go silent. If there is a residual risk, it needs to be referenced to the risk management file. The GSPR matrix and the risk management file should cross-reference each other. Auditors who find residual risk in the risk management file with no mention of it in the GSPR matrix will note the gap.

Handling the 23 requirements in practice

Annex I is structured in three chapters: general requirements (GSPRs 1–9), requirements for design and manufacture (GSPRs 10–23), and specific requirements by device type. The specific requirements (GSPRs 14 onwards) are conditional — some apply only to devices with measuring functions, some only to devices that emit radiation, some only to devices that deliver medicinal substances. Do not mark these all as applicable by default and do not mark them all as not applicable without a documented review.

The requirements that catch most teams are:

• GSPR 1 (benefit-risk): requires a documented benefit-risk analysis, not just a reference to the risk management file summary. The analysis needs to be explicit.
• GSPR 6 (risks from use errors): requires consideration of the intended user population and use environment. Many teams rely on IEC 62366-1 for usability but do not explicitly link the usability file to GSPR 6 in the matrix.
• GSPR 23 (devices incorporating software): if any software is present — including software controlling device function — IEC 62304 and the MDR's software-specific requirements need to be addressed here. Teams that treat software as incidental to a hardware device and do not map it separately against GSPR 23 often get a finding.

Format and maintenance

The format of the matrix is not mandated — a table in a controlled document works. What matters is version control and that the matrix is a living document. A GSPR matrix that was built during initial certification and then never touched is a red flag in a surveillance audit. Post-market data may identify new hazards or change the benefit-risk picture, which should feed back into the GSPR demonstration. The matrix needs to reflect the current state of the device and its evidence, not the state at the time of the last submission.

One practical approach: embed the GSPR matrix in your technical file as a master controlled document that references all supporting documents. When a supporting document is updated, the matrix entry is reviewed and the matrix revision date is updated to reflect the review — even if the referenced document reference does not change. This gives auditors a clear audit trail showing the matrix has been actively maintained.

What auditors actually check

Notified Body auditors reviewing a GSPR matrix will typically sample 3–5 requirements and pull the referenced evidence documents. They are checking whether the documents exist, whether they are in the correct version, whether the test scope covers the actual device, and whether residual risks are captured in the risk management file. They will also check for internal consistency: if the device description says the device is a Class IIa and the GSPR matrix references standards appropriate for a Class III, that inconsistency will be flagged.

The practical takeaway: build your matrix to be verifiable, not just complete. Completeness gets you through a desktop review. Verifiability — meaning every entry can be followed to a real, current, device-specific document — is what survives an audit.