I used to think a traceability matrix was a table you updated before a certification audit and then forgot about until the next one. After five years of MDR audits, Technical File updates and more than one surprise notified-body question, I no longer believe that. A traceability matrix that "lives" is not a spreadsheet with cell comments. It is a connected, reviewable artefact of your quality system — and keeping it alive is both technical and procedural.
Why traditional matrices break
In practice this means a handful of predictable failure modes:
- Changes create drift. Requirements, design outputs, risk controls and verification records are updated at different times by different people. A static matrix becomes inconsistent within weeks.
- Scope creep and version sprawl. Multiple product variants, software branches or supplier changes spawn parallel documents and ad hoc matrices.
- Trace is brittle. Links in a spreadsheet point to filenames or cell references; the link dies when someone renames a document or moves a folder.
- Human overhead. Keeping a matrix accurate is treated as an administrative task, not a compliance-critical control, so it is deprioritised.
- Audit surprise. Notified bodies increasingly ask for evidence that you can demonstrate traceability across change — not just a snapshot but the history of how traceability evolved.
To be fair, none of these are new. MDR and ISO 13485 raise the bar for demonstrating that risk controls are implemented and verified; that forces traceability to become operational, not archival.
What a "living" traceability matrix looks like
A living matrix has three properties that matter to RA/QA and to auditors:
- Connected. Requirements, risk items, design outputs, verification/validation and post-market data are linked, not pasted into cells.
- Reviewable. Changes to trace links are visible in the change control history and are assigned for review (who changed what, why, and when).
- Actionable. When a link breaks or a related document changes, the system flags impacted items and initiates a controlled workflow (change control, CAPA, or a documentation update).
Granted, few small manufacturers can afford bespoke ALM systems. But even within an eQMS you can design for these properties: avoid manual copy-and-paste, require controlled references, and put acceptance gates where traceability changes matter.
Practical steps to keep a matrix alive
These are the measures I use in my company. They are deliberately pragmatic — you can start with small process changes before investing in tooling.
- Map the minimum trace paths you actually need
- For MDR compliance, link user needs → design inputs → risk controls → verification/validation → release artefacts → PMS findings. Don't attempt to trace everything the first time.
- Make trace creation a gate in your change-control workflow
- When a design change is raised, require the engineer to identify impacted requirements and risk items as part of the change record. If the system shows missing links, the change cannot proceed.
- Use document identifiers, not file names
- IDs with version control survive restructures. Your traceability references should point to IDs (and ideally to specific versions or change-history snapshots).
- Require explicit reviewer comments on link changes
- A reviewer should confirm whether an updated link changes the risk picture or verification sufficiency; capture that confirmation in the record.
- Automate impact prompts, not decisions
- Set the system to flag impacted tests, procedures or instructions when requirements or risk controls change. Escalation should create a controlled task — who assesses the impact is still a human.
- Keep a digestible export for audits
- Notified bodies still like readable matrices. Provide a filtered export that shows the path, the responsible owners, and key timestamps, plus the change history.
Tooling considerations (what actually helps)
To be useful, tooling must support the above. Here are the features worth prioritising; everything else is nice-to-have.
- Native linking between artefacts (not hyperlinks)
- Version-aware references (trace to exact revision or change set)
- Connected workflow integration: change control → CAPA → verification scheduling
- Audit trail and reviewability for link changes
- Bulk impact analysis (so an engineer can see the ripple of a requirement change)
- Configurable alerts (so not every minor editorial update escalates)
Two caveats. First, tools do not replace governance. If engineers are allowed to bypass change control, your "living" matrix will still die. Second, integration matters more than feature count. A system where change, CAPA, risk and document control are connected reduces duplicate work.
Audits and notified bodies — what they care about
Notified bodies rarely accept "we updated the matrix last week" without evidence. They want to see:
- Trace evidence linked to versions and verification records
- How traceability was maintained through a change (change records, reviewers, risk reassessment)
- That post-market findings fed back into design or risk controls where required
Per MDR Annex II, your technical documentation must demonstrate conformity across design, manufacture and risk management. A living matrix is the simplest way to show that links exist and have been reviewed.
Final thoughts
I stopped treating traceability as an audit artefact and started treating it as a control. That change in mindset — and modest investments in process and tooling — make audits less stressful and product changes less risky.
How have you structured your traceability so it survives real-world change, not just audit season?
Top comments (0)