Integrating Your Risk Management File with the Technical Documentation

The integration problem most teams encounter

Under MDD, many manufacturers treated risk management as a QMS obligation that was referenced in the technical file rather than embedded in it. The technical file pointed to the risk management file; the risk management file was maintained separately. Under EU MDR, that separation is no longer sustainable. The regulation requires a tighter connection: your residual risks must feed into the benefit-risk assessment, which is part of the technical file. If they live in separate processes, the connection is usually missing or thin — and Notified Bodies have learned to look for it.

This is not just an administrative requirement. The MDR's approach reflects an actual change in expectation: the risk management process is supposed to be the mechanism by which you demonstrate that risks are acceptable. The technical file is where you show that. If those two things are out of alignment, you cannot satisfy either requirement properly.

What Annex I actually requires from the risk-benefit link

Section 1 of Annex I states that devices must be designed and manufactured to be safe and to perform as intended, and that any risks associated with their use must constitute acceptable risks in relation to the benefits. This is not a general principle — it has to be demonstrated in the technical file. The benefit-risk assessment in the technical file must draw on the residual risk data from the risk management process.

What this means in practice: the risk management file is not complete until you have evaluated residual risks against the benefit context. And the technical file benefit-risk section is not complete unless it is grounded in the actual residual risk picture from the risk management file. The two documents need to tell the same story, in compatible terms, with cross-references that work.

The points where they connect

GSPR 1 — benefit-risk analysis The GSPR matrix entry for GSPR 1 needs to reference both the risk management file (for the residual risk data) and the clinical evaluation (for the benefit data). A GSPR 1 entry that says "ISO 14971 risk management file ref RM-001 rev 3" is incomplete if it does not also reference the benefit-risk analysis document where those residual risks are weighed against clinical benefits.

GSPR 3 — risk minimisation The risk controls in the risk management file feed directly into the design and manufacturing documentation. If your risk management file says a design feature eliminates a hazard, that feature needs to exist in the device description and specification and be traceable to a design output. Risk controls that are documented in the risk management file but not traceable to design, manufacturing, or labelling documents are audit findings.

GSPR 6 — use errors and foreseeable misuse The usability engineering file (typically built to IEC 62366-1) should be formally linked to the risk management process. Hazards identified through usability analysis feed into the risk management file; risk controls that address use errors should be traceable back to the usability study. Many teams keep these in parallel without explicit cross-references — which means when an auditor follows the chain, it breaks.

Post-market feedback loop Post-market surveillance data can change the risk picture. If post-market data identifies a new hazard, or if incident rates suggest residual risk is higher than estimated, the risk management file needs to be updated — and that update needs to flow back into the GSPR 1 benefit-risk assessment and the clinical evaluation summary. This is where a lot of technical files quietly become outdated: the risk management file is updated, but the benefit-risk analysis in the technical file is not.

How to build the connection in practice

The most reliable approach is to design the two documents to reference each other explicitly from the start rather than retrofitting the connection later:

• The risk management plan should define the criteria for acceptable residual risk in benefit-risk terms, and reference the clinical evaluation as the source of benefit data.
• The risk management report should include a summary of residual risks by category, with explicit statements that each residual risk category is acceptable given the documented clinical benefits.
• The benefit-risk analysis in the technical file should reference the risk management report summary, not just the risk management file generally.
• When either document is updated, a review of the other should be a documented step in your change control process.

If you are reviewing an existing technical file for this connection: check whether the benefit-risk analysis section references specific sections or version numbers of the risk management file. If it just says "see risk management file" without a reference to the residual risk summary, the connection is probably superficial and will be challenged.

The version alignment issue

One of the most common and most avoidable problems is version misalignment. The risk management file is at revision 4; the benefit-risk analysis in the technical file was written based on revision 2. The GSPR matrix references revision 3. The auditor pulls all three documents and finds three different residual risk profiles because the versions do not match.

A clean technical file has consistent version references throughout. When the risk management file is updated, the documents that reference it — the GSPR matrix, the benefit-risk analysis, the clinical evaluation summary — should all be reviewed and their version references updated, even if the referenced content from the risk management file has not materially changed. The review itself, with a sign-off, is what gives an auditor confidence that the documents are in sync.