Traceability matrices break because you treat them like spreadsheets — here’s how to keep them living

I used to defend a single 200‑row traceability spreadsheet through three audits and a product recall. It felt heroic at the time. To be fair, the intent was right: trace requirements to design outputs, risks to controls, tests to reports, and IFU. In practice this means whoever last edited the spreadsheet had the most power over your Technical File.

Traceability matrices break for predictable reasons. Notified bodies (and ISO 13485 auditors) expect evidence that your General Safety and Performance Requirements (Annex I, MDR 2017/745) are satisfied across design, risk management, verification/validation and post‑market data. If your matrix is static, scattered, or siloed, it fails that expectation — and it will fail you long before an auditor notices.

Why traceability matrices break

• They’re static tables. A spreadsheet is a snapshot that doesn’t capture change history or intent. When requirements evolve, the table shows last state only, not the impact pathway.
• They’re disconnected from the QMS. Requirements, design outputs, risk controls, test protocols and CAPAs live in different systems or folders, so links go stale.
• Authors and conventions differ. One engineer uses component names, another uses supplier codes. No unique identifiers — no reliable joins.
• Version proliferation. Designers fork files for prototypes; clinical adds an evidence row; procurement duplicates supplier data. Merge hell follows.
• Change control is afterthought. A supplier swap or software patch triggers dozens of updates; the matrix is rarely part of the change‑control flow.
• Scale and complexity. Systems grow: software functions, configurations, variants, accessories — a flat table does not express many‑to‑many relationships.

Granted, sometimes the real problem is governance: nobody owns the matrix as a living artefact. That ownership gap turns a useful map into compliance theatre.

What a “living” traceability system looks like

Traceability is not a table—it’s a system. That phrase has stuck with me because it forces a mental shift: from one document to a connected workflow. In a living approach you have:

• Unique, stable identifiers for requirements, hazards, design outputs, tests and documents.
• Bi‑directional links (upstream and downstream traceability).
• Automated change impact analysis — when a requirement or risk control changes, the system flags affected items and triggers reviewers.
• Audit trails and reviewability so every link and change is explainable to a notified body or auditor.
• Integration with CAPA and change control so that design changes automatically create or update CAPA records where needed.

If you map Annex I GSPRs to hazards in your ISO 14971 risk file, to design outputs, to verification protocols and then to V&V reports and IFU statements — and all of these links are live — then your traceability is genuinely useful for product safety and regulatory defence.

Practical steps to get there (what I do)

Start with pragmatic, repeatable steps rather than big‑bang tool projects.

1. Agree identifiers and a linking convention

   • Assign stable IDs: GSPR‑001, HAZ‑023, DO‑045, VVP‑009. Put these IDs on every document header.
   • Publish a short naming guide. Make it part of Document Control (ISO 13485 clause 4.2) so authors follow it.

2. Make the matrix a consumer, not the master

   • Your matrix should be generated from links that live in the documents and records, not manually edited.
   • In practice this means either an eQMS with linkable objects or a lightweight traceability database that ingests document metadata.

3. Bring traceability into change control

   • Add a Change Impact Mapping step in the Change Request form. If DO‑045 changes, the form should list downstream items and responsible owners automatically.
   • Trigger reviews and CAPAs when impact thresholds are met (safety‑critical parts, labelling, sterilisation process, etc).

4. Automate routine checks

   • Use automated reports to show orphaned items (hazards with no risk control, tests with no linked report).
   • Set periodic review reminders for high‑risk links (e.g. clinical claims, algorithm thresholds).

5. Reduce noise with sensible depth

   • You don’t need traceability at every nut and screw for every product. Define levels: top‑level GSPRs → safety‑critical functions → verification tests; detailed component traceability only where risk justifies it.

6. Embed PMCF/PSUR signals

   • Link post‑market observations to hazards and controls so trends surface without manual cross‑referencing. This closes the loop from field data to design and to CAPA.

Day‑to‑day governance

• Ownership: name a traceability steward inside RA/QA. They don’t do the edits, they ensure conventions, reviews and tooling work.
• Change policy: require traceability impact statements for any design or supplier change that touches safety or claims (Annex II expectations).
• Audit your traceability: once per year, run a verification exercise: pick a claim or a GSPR and walk the links from requirement to V&V report to PMS. If you can’t walk it quickly, it’s not living.

To be fair, tooling helps but does not replace discipline. I’ve seen teams buy an eQMS and continue manually copying spreadsheet rows into it. The investment was wasted because governance didn’t change.

Final note

Traceability becomes valuable when it reduces rework and informs safety decisions, not when it’s an auditor bait‑and‑switch. In my team, once we stopped treating the matrix as an output and started treating it as a process — change control bites, automated CAPAs kick in, and the Technical File assembly time fell dramatically.

How do you keep your traceability alive — convention, tooling, or sheer force of will?