How to Cross-Reference Documents in Your Technical File Efficiently

Q: Does MDR Annex II require a specific cross-reference format?

No. Regulation (EU) 2017/745 Annex II defines the sections the technical documentation must contain and requires that the evidence for each GSPR is identified, but it does not mandate a specific matrix format or document ID scheme. The obligation is that evidence for every applicable GSPR is traceable and complete. Any system that makes the evidence reachable for a reader satisfies the regulatory intent; the matrix and ID conventions described in this post are a working shape that Notified Bodies recognise and startups can actually maintain.

Q: Do document IDs have to follow a specific standard?

No standard mandates a specific format. EN ISO 13485:2016+A11:2021 requires that documents be identified and controlled — the ID scheme is the manufacturer's choice. What matters is that the IDs are stable across revisions, unique across the file, and readable enough that a reviewer can understand a reference without opening the document.

Q: Should I use a full eQMS or a spreadsheet for my GSPR matrix?

Use whichever one you will actually keep accurate. A spreadsheet that is always current beats an eQMS that the team bypasses. For a pre-submission startup, a spreadsheet under version control (with a stable document ID and a change history) is usually the right starting point. Migrate to a heavier tool when the team outgrows the spreadsheet, not before.

Q: What is the difference between the GSPR matrix and the risk control traceability thread?

The GSPR matrix is organised by Annex I requirement — each row is a GSPR item with its evidence. The risk control thread is organised by hazard — each hazard points to risk controls, verification evidence, and residual-risk acceptance. The two intersect heavily because GSPRs are risk-driven, but they answer different questions. The matrix answers "have we covered every GSPR?" The risk thread answers "is every hazard controlled and verified?" Both have to be maintained.

Q: How often should the cross-reference matrix be reviewed?

On every change to any document it references, and on a defined periodic review cycle (typically once a year for stable files, more often for products under active development). Each review updates the "last review date" column for the rows touched and produces a new matrix revision under document control. A matrix whose last review date is older than the most recent evidence document it cites is out of sync and should be reconciled before the next submission or audit.

Q: Can I generate the cross-reference matrix automatically from a requirements management tool?

Yes, if the tool has the discipline to track document IDs, GSPR links, and revisions cleanly. Automated generation is the right end state for teams that ship continuously. The risk of automation without discipline is that the tool produces a matrix that looks complete but references documents that do not exist or links that the team never reviewed. Generate from the tool, then review the output as a controlled document before it ships.

To cross-reference a technical file under Regulation (EU) 2017/745 efficiently, treat the file as a directed graph anchored on the Annex I GSPR checklist. Every general safety and performance requirement points to one or more evidence documents; every evidence document points back to the GSPR items it discharges and forward to the Annex II sections it populates. Give every document a stable ID that never changes, use one naming convention across the whole file, and maintain a single traceability matrix that is the source of truth for where things live. When an auditor asks "show me the evidence for GSPR 10.2" or "where is the verification for this risk control," the answer should take under two minutes, not two hours.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

MDR Annex II does not mandate a specific cross-reference format, but the Annex I GSPR checklist in Annex II Section 4 is the natural backbone every mature technical file uses.
Every document in the file needs a stable document ID that never changes across revisions, and a naming convention that makes the ID readable at a glance.
The GSPR-to-evidence matrix is a two-way map: each GSPR item lists the evidence that discharges it, and each evidence document lists the GSPR items it supports.
Risk controls from the EN ISO 14971:2019+A11:2021 risk file need a separate traceability thread linking each control to its verification and to the residual-risk acceptance.
An efficient cross-reference system is tested against one question: can an auditor land on any GSPR row, follow a pointer, and reach the evidence in under two minutes.

The auditor finding no one wants

A Class IIa manufacturer I was auditing had a reasonable technical file. Four binders, decent structure, clinical evaluation report in place, risk file in place, verification reports in place. We sat down, opened Annex II Section 4, and I picked a row — GSPR 14.2(d), the "software designed and manufactured in accordance with the state of the art" item. The column headed "Reference to evidence" said "See V&V documentation."

I asked which document. The quality manager said the verification plan. I asked for a document ID. The plan did not have one on its cover page — it had a title and a date. I asked which version was current. They pulled up a SharePoint folder with four files named "V&V Plan," "V&V Plan v2," "V&V Plan final," and "V&V Plan final v3." While they sorted that out, I picked another row — GSPR 10.2 on chemical and physical properties of materials — and asked for the evidence. "See biocompatibility report." Which report. "The one from the supplier." Which version. Which materials. Which of the three batches tested. We never got to an answer that day. The finding wrote itself: evidence not traceable to the GSPR checklist.

The company did not have a competency problem. They had a cross-reference problem. The evidence existed. Nobody could reach it in under two minutes. From a Notified Body perspective, evidence you cannot find is evidence that does not exist. The rest of this post is how to build a cross-reference system that does not generate that finding.

The technical file as a graph

The most useful mental model for a technical file is not a binder. It is a directed graph. The nodes are documents — the risk management file, the verification reports, the clinical evaluation, the IFU, the labels, the bill of materials, the supplier agreements, the biocompatibility dossier, the software lifecycle artefacts. The edges are cross-references — pointers between documents that tell a reader where to go next to follow an argument.

Regulation (EU) 2017/745 Annex II defines the sections the file must contain (device description, information supplied by the manufacturer, design and manufacturing, general safety and performance requirements, benefit-risk and risk management, product verification and validation, plus specific sections where relevant). It does not define how the documents inside those sections point to each other. That is the manufacturer's call, under EN ISO 13485:2016+A11:2021 document control.

The backbone of the graph is Annex II Section 4 — the GSPR checklist. Every general safety and performance requirement in Annex I of the MDR is listed in that checklist, with an applicability column (applicable / not applicable with reasoning), a compliance method column (how you meet it — harmonised standard, common specification, other solution), and an evidence reference column (the documents that prove it). The GSPR checklist is the index from which the rest of the file is reachable. If the cross-references out of the GSPR checklist are clean, the file is navigable. If they are not, nothing else saves it.

Document IDs that never change

Every document in the file gets an ID. The ID is stable — it does not change when the document is revised. The revision is tracked separately. Under EN ISO 13485:2016+A11:2021 document control, the combination of a stable ID and a current revision is what identifies the controlled version at any moment.

The format we use with startups is short, readable, and sortable. A prefix for document type, a sequence number, optionally a device-family code if the company has more than one product line. Examples:

RMF-001 — Risk Management File
CER-001 — Clinical Evaluation Report
VER-014 — Verification Report, item 14
VAL-003 — Validation Report, item 3
SOP-012 — Standard Operating Procedure, item 12
SPEC-001 — Device Specification
IFU-001-EN — Instructions for Use, English
BOM-001 — Bill of Materials
SBOM-001 — Software Bill of Materials
TF-TOC — Technical File Table of Contents

The ID prefix carries meaning. When a reviewer sees RMF-001 in a cross-reference, they know without looking that the pointer goes to the risk management file. When they see VER-014 §3.2 they know it is section 3.2 of verification report number 14. The cross-reference is readable before anyone opens a single file.

The rule that makes this work: the ID is stamped on the document cover page, on every header or footer, and in the file name. Three places. An auditor who reads a page and sees VER-014 rev 3 — 2026-02-15 knows exactly which artefact they are holding, without asking.

The GSPR-to-evidence matrix

The GSPR checklist in Annex II Section 4 is the master cross-reference table. For a Class IIa or IIb device it will have roughly 150–200 rows, depending on which Annex I items apply. For each row:

GSPR item — the Annex I reference (e.g. GSPR 10.2).
Applicability — applicable / not applicable with reasoning.
Compliance method — the harmonised standard, common specification, or other solution used to demonstrate conformity.
Evidence reference — the document IDs, with section pointers where relevant.
Last review date — when the row was last re-checked.

The evidence reference column is the core of the cross-reference system. It does not say "see V&V documentation." It says VER-014 §3.2; VER-015 §2.1; RMF-001 §4.3. A reader picks a document ID, finds it in the file table of contents, opens it, finds the section, and reads the evidence. Two minutes.

The matrix is two-way. Each evidence document has a header section that lists the GSPR items it supports. VER-014 has a line on its cover page that reads "Supports GSPR 14.2(d), 17.1, 17.2." If someone opens VER-014 directly, they know which GSPR rows depend on it without having to search the matrix backwards. When VER-014 is revised, the revision author checks those GSPR rows to confirm the evidence is still valid.

The technical documentation templates for startups post walks through the matrix template the startups we work with use; the how to document GSPR Annex I compliance post covers the GSPR checklist itself in more depth. For this post the point is that the matrix is the source of truth for where evidence lives, and every other cross-reference in the file derives from it.

Risk controls: a second traceability thread

The GSPR matrix is the primary backbone. There is a second thread running through the file that has to be traced separately: the risk controls from the EN ISO 14971:2019+A11:2021 risk management file.

Every identified hazard in the risk file leads to one or more risk control measures. Every risk control has to be verified (was the control implemented and does it work) and has to be traced to residual risk acceptance (does the remaining risk sit inside the acceptance criteria). The cross-references for this thread are:

Hazard ID → Risk control ID → Verification evidence ID → Residual risk record

Each link in the chain points at a specific document ID and section. HZ-027 points to RC-027a which points to VER-014 §3.2 which points to RMF-001 §6.5. A reader starting from any node can follow the thread in either direction. The risk file's internal document control enforces that every hazard has at least one control, every control has verification, and every residual risk is accepted.

This thread intersects the GSPR matrix. Most of the GSPR evidence references also appear in the risk control chain, because Annex I GSPRs are risk-driven in the first place. When the matrix and the risk chain disagree on where evidence lives, one of them is wrong. Reconciliation is part of the file review discipline.

Good and bad cross-references

Two examples from real startup files, with the identifying details changed.

Bad cross-reference (Annex II Section 4, row GSPR 10.2):

Applicable. Compliance demonstrated via biocompatibility testing. See biocompatibility documentation.

Nothing in that row is actionable. "Biocompatibility documentation" is not a document ID. No section pointer. No version. No standard cited. No link back to the materials in the bill of materials that the testing covered. An auditor spends thirty minutes trying to reach the evidence and writes a finding regardless of whether the evidence is good, because the traceability is broken.

Good cross-reference (same row):

Applicable. Compliance demonstrated per EN ISO 10993-1:2025 biological evaluation for surface-contacting device, limited contact (<24h). Evidence: BIO-001 rev 2 (biological evaluation plan), BIO-002 rev 4 (biological evaluation report), BIO-003 rev 1 (cytotoxicity test report, test lab ID XYZ, batch B-2025-14, materials per BOM-001 rev 7 items 3, 7, 12). Residual risk accepted in RMF-001 rev 5 §6.5.

A reader reaches the evidence in under two minutes. Every document ID is stable. Every section pointer is precise. The link to the bill of materials and to the risk file closes the loop. The auditor checks each artefact, finds it, and moves on.

The difference between the two rows is not regulatory interpretation. It is discipline about document IDs, section pointers, and the habit of filling the matrix with references that can actually be followed.

Ship: the matrix template and the tooling question

The matrix is a table. It can live in a spreadsheet, in a requirements management tool, in a dedicated eQMS, or in a plain markdown file inside a Git repository. The tool does not matter as long as three properties hold:

Single source of truth. One matrix, not four. If the spreadsheet and the eQMS disagree, the file is broken.
Document IDs resolve. Anyone reading the matrix can find the referenced document in under two minutes, without asking.
Version control. The matrix itself is a document under control, with its own ID (typically TF-GSPR-001 or similar), a revision number, a change history, and an approval signature per EN ISO 13485:2016+A11:2021.

For startups before the first Notified Body submission, a spreadsheet is usually the honest answer. It is cheap, visible, editable, and reviewable. The team that tries to adopt a full eQMS before they have a working file usually ends up with both — a half-configured eQMS and a shadow spreadsheet that is actually the source of truth. Pick one, make it the source of truth, and move on.

For teams shipping continuously, the matrix has to be updated on every change to the file. A risk control added to the risk file adds a row to the control chain and updates the GSPR reference. A verification report revised to cover a new test updates the GSPR rows it supports. The managing technical documentation with a small team post covers the operational rhythm — who updates the matrix, when, and how the update gets reviewed.

The test that tells you the system works is simple. Pick any GSPR row at random. Time how long it takes to reach the evidence and confirm it answers the requirement. Under two minutes, the system works. Over ten minutes, the cross-reference system is not the real problem — the file is. Somewhere between, there is a document ID convention or a matrix discipline to tighten.

Reality Check — Where do you stand?

Does every document in your technical file have a stable document ID that appears on the cover page, in the header or footer, and in the file name?
Does your GSPR checklist in Annex II Section 4 point to specific document IDs with section pointers, or does it use phrases like "see verification documentation"?
Can a reader pick any GSPR row, follow the evidence reference, and reach the supporting artefact in under two minutes?
Does every evidence document list the GSPR items it supports on its cover page, so the traceability runs both ways?
Is there a second traceability thread linking hazards to risk controls to verification evidence to residual-risk acceptance, with document IDs at every step?
If the same evidence is referenced in the GSPR matrix and the risk control chain, do the two references agree on which document ID and section?
Is the matrix itself under document control with its own ID, revision number, and change history?
When a verification report is revised, does someone check the GSPR rows it supports to confirm the evidence is still valid?

Frequently Asked Questions

Does MDR Annex II require a specific cross-reference format? No. Regulation (EU) 2017/745 Annex II defines the sections the technical documentation must contain and requires that the evidence for each GSPR is identified, but it does not mandate a specific matrix format or document ID scheme. The obligation is that evidence for every applicable GSPR is traceable and complete. Any system that makes the evidence reachable for a reader satisfies the regulatory intent; the matrix and ID conventions described in this post are a working shape that Notified Bodies recognise and startups can actually maintain.

Do document IDs have to follow a specific standard? No standard mandates a specific format. EN ISO 13485:2016+A11:2021 requires that documents be identified and controlled — the ID scheme is the manufacturer's choice. What matters is that the IDs are stable across revisions, unique across the file, and readable enough that a reviewer can understand a reference without opening the document.

Should I use a full eQMS or a spreadsheet for my GSPR matrix? Use whichever one you will actually keep accurate. A spreadsheet that is always current beats an eQMS that the team bypasses. For a pre-submission startup, a spreadsheet under version control (with a stable document ID and a change history) is usually the right starting point. Migrate to a heavier tool when the team outgrows the spreadsheet, not before.

What is the difference between the GSPR matrix and the risk control traceability thread? The GSPR matrix is organised by Annex I requirement — each row is a GSPR item with its evidence. The risk control thread is organised by hazard — each hazard points to risk controls, verification evidence, and residual-risk acceptance. The two intersect heavily because GSPRs are risk-driven, but they answer different questions. The matrix answers "have we covered every GSPR?" The risk thread answers "is every hazard controlled and verified?" Both have to be maintained.

How often should the cross-reference matrix be reviewed? On every change to any document it references, and on a defined periodic review cycle (typically once a year for stable files, more often for products under active development). Each review updates the "last review date" column for the rows touched and produces a new matrix revision under document control. A matrix whose last review date is older than the most recent evidence document it cites is out of sync and should be reconciled before the next submission or audit.

Can I generate the cross-reference matrix automatically from a requirements management tool? Yes, if the tool has the discipline to track document IDs, GSPR links, and revisions cleanly. Automated generation is the right end state for teams that ship continuously. The risk of automation without discipline is that the tool produces a matrix that looks complete but references documents that do not exist or links that the team never reviewed. Generate from the tool, then review the output as a controlled document before it ships.

Technical Documentation Templates for Startups — the matrix template the examples in this post derive from.
How to Document GSPR Annex I Compliance Checklist — the GSPR checklist that anchors the cross-reference backbone.
How to Manage Technical Documentation With a Small Team — the operational rhythm for keeping the matrix current.
Technical Documentation for Software as a Medical Device — the SaMD-specific shape of the same file and the same cross-references.
MDR Annex II Structure, Section by Section — the Annex II walkthrough the matrix is built against.

Sources

Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex II (technical documentation) and Annex I (general safety and performance requirements). Official Journal L 117, 5.5.2017.
EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Harmonised standard referenced for document control obligations.
EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. Harmonised standard referenced for the risk control traceability thread.

This post is a Category 5 spoke in the Subtract to Ship: MDR blog, sitting under the Technical Documentation pillar. Authored by Felix Lenhard and Tibor Zechmeister. MDR Annex II is the binding source; EN ISO 13485:2016+A11:2021 document control and EN ISO 14971:2019+A11:2021 risk management are the operational tools the cross-reference system rides on. For startup-specific support on technical file architecture, GSPR matrix design, and audit-ready traceability, Zechmeister Strategic Solutions is where this work is done in practice.