Connecting Risk Management to GSPR Traceability

Why these two things have to talk to each other

The General Safety and Performance Requirements in Annex I of MDR set out what every device on the EU market must demonstrate. Risk management under ISO 14971 is the process by which a manufacturer demonstrates it. These are not parallel tracks — they are the same journey viewed from two different angles, and your documentation needs to show how they connect.

The problem that shows up repeatedly in technical file reviews: the GSPR checklist exists in one place, and the risk management file exists in another, and the connection between them is implicit at best. A reviewer looking at the GSPR checklist wants to see, for each applicable requirement, how that requirement was addressed — and risk management is usually a significant part of the answer. If you can't point from a GSPR to the risk controls, design decisions, or test records that satisfy it, the documentation has a gap.

What the GSPR traceability matrix actually needs to contain

For each GSPR in Annex I, your matrix needs to record: whether the requirement applies to your device and why (or why not, if you're claiming it doesn't apply), how the requirement was addressed, and where the evidence lives. The evidence references are the part most teams underdo — vague pointers like "see risk management file" are not adequate. You need a specific reference: which document, which section, which record.

For requirements addressed through risk management, the reference should connect to a specific risk control or a residual risk acceptance in your risk management file. For requirements addressed through design (e.g., biocompatibility, usability, sterility), the reference should point to the specific verification or validation record. Harmonised standards matter here — where you've applied a harmonised standard to address a GSPR, record which edition of the standard and where in your technical file the evidence of application sits.

The integration points that get missed

Several GSPR requirements have a particularly direct relationship with risk management that teams often fail to make explicit.

GSPR 1 (the general safety and performance obligation) and GSPR 8 (risk management integration into design and manufacture) are the two that most directly require risk management as the mechanism. For GSPR 1, your benefit-risk determination from the ISO 14971 process is the core evidence. For GSPR 8, the evidence is your integrated risk management process itself — documented in the risk management plan, applied through design controls, referenced in the design history file.

GSPR 23 (labelling) and GSPR 14 (devices with a measuring function) are examples where risk management informs the requirement but isn't always connected in the matrix. If your labelling decisions were driven by risk controls (e.g., warnings added because certain uses were identified as hazardous), that connection should be visible.

Post-market data obligations in GSPRs 20–22 are another area where the link to risk management is required but often absent. Your post-market surveillance outputs — complaints, trends, signal detection — should be feeding into your risk management updates, and that feedback loop should be traceable in both directions.

Practical structure for your traceability matrix

A workable matrix format lists each GSPR requirement in order, with columns for: applicability (yes/no/N-A with justification), method of demonstration, and document reference. For requirements addressed through risk management, the document reference should cite specific sections of your risk management file. For requirements addressed through harmonised standards, list the standard number, edition, and the corresponding test or verification report.

One approach that works well for complex devices: maintain the GSPR matrix as a living document within the technical file, cross-referenced from both the risk management file and the design history file. When a design change is made, the GSPR matrix is reviewed alongside the risk management file — both get updated together. This prevents the drift where the GSPR matrix reflects the original design and the risk management file reflects the current one.

What changes when you update your risk management file

This is the part that catches people after first certification. When post-market data triggers a risk management update — say, a new hazard is identified or a risk control needs strengthening — the impact on the GSPR traceability should be reviewed at the same time. If the change affects how a GSPR is satisfied (e.g., new labelling is added as a risk control, changing your GSPR 23 evidence), the matrix needs to reflect that.

Notified Bodies conducting surveillance audits look specifically for consistency between the current state of the risk management file and the current state of the GSPR matrix. A risk management file updated after a field incident, with a GSPR matrix that hasn't been touched since certification, is a finding waiting to happen.