Twelve rows. Forty columns. Filter coffee going cold in my hand for the third time this morning. That is what passes for our design traceability matrix this quarter, and any notified body auditor who asks for it will see exactly how honest we have been with ourselves.
The traceability matrix is the first thing a notified body asks for on a design control audit. Not because it is the most important deliverable in your DHF, but because in one screen it tells the auditor whether your design is internally consistent. Are your user needs actually flowing down into design inputs? Do your design outputs trace back to those inputs? Does every verification activity cover the requirement it claims to? Does every change have a documented impact on the matrix? If the matrix is consistent, the rest of your design history file probably is too. If it is not, the auditor will spend the next three days proving it.
What the standards actually ask for
The matrix is not invented by auditors. ISO 13485, clauses 7.3.9 and 7.3.10, treats verification and validation as the bridge between design inputs and design outputs — and that bridge has to be traceable. 21 CFR 820.30 in the US uses the same logic. EU MDR is less explicit on the matrix itself, but the GSPR traceability obligation in Article 10(4) and the technical documentation expectations under Annex II and Annex III make the same demand in different language. The matrix is the artefact that proves the chain.
Most of us learned this the same way: during our first NB audit, when someone calmly asked, "show me how this user need connects to this verification protocol," and we fumbled through six documents to find the answer.
Why ours goes stale
We are a contract manufacturer. Our designs come in three flavours:
- OEM-owned designs where we only run the manufacturing process — the OEM owns the matrix, and we inherit a frozen snapshot.
- Co-developed designs where we own parts of the design history file — usually process design, supplier qualification, and process validation.
- Transfer projects where we receive a frozen design and have to verify it builds the same way every time.
In every flavour, the matrix drifts. New requirements get added during a design review and someone forgets to add the verification row. A verification fails, the protocol is revised, but the matrix still points at the old version. A supplier is qualified, an associated material spec is updated, and the link in the matrix still points at the previous revision. Six months in, the matrix is a historical document wearing the costume of a current one.
The reason is rarely that nobody cares. The reason is that the matrix lives in a spreadsheet, the spreadsheet lives on a shared drive, and updates happen when someone has the bandwidth — usually the night before an internal audit, never during the week a real change happens.
What we tried, and what failed
We tried the obvious things:
- A designated owner who reviews the matrix monthly. Worked for two months. Then the owner went on leave and the matrix sat.
- A Python script that cross-references our requirements repository against the verification log and flags orphan rows. Useful, but it only catches missing links — it does not catch stale ones, and it does not catch links that exist but point at the wrong revision.
- A review gate inside our change control workflow: every change has to touch the matrix before closure. This one actually helped, until change reviewers realised they could tick the box without doing the work, and we ended up with a checked box and an unchanged matrix.
- A quarterly "matrix health check" presented in our QMR. Beautiful slides, real numbers, an executive sponsor who genuinely cared. The matrix continued to drift.
None of these failed because they were bad ideas. They failed because they treated the matrix as an artefact to be maintained, when the standard actually treats it as a property of the system.
What the standard is really asking for
Re-read 13485 with fresh eyes. The phrase that matters is not "you must have a traceability matrix." The phrase is that traceability shall be maintained throughout product realisation. The matrix is a snapshot of a live property — the property is that every requirement, specification, verification, and change in your design history is connected to the others in a consistent, current way.
That is what a notified body is testing when they pull up the matrix. They are not testing whether you have rows and columns. They are not even testing whether the rows and columns agree with each other on the day of the audit. They are testing whether your system produces a consistent matrix on demand, every time, at any point in the design's life.
A spreadsheet cannot do this. A spreadsheet is a snapshot. It will always be six months stale, or three months stale, or — if you are unusually disciplined — three weeks stale. It will always be one revision behind something.
What I would do differently
If I were rebuilding this from a blank slate tomorrow morning, I would not start with the matrix. I would start with the links:
- Every user need has a unique ID stored in one place of truth.
- Every design input references the user need IDs by rule, not by hand.
- Every design output references the input IDs the same way.
- Every verification protocol references the outputs it covers.
- Every change record has to declare which links it touches, and the system propagates the impact automatically.
The matrix then becomes a view, not a document. It is regenerated from the underlying links every time someone asks. It cannot drift, because the links are the source of truth, and the links are maintained by the workflow that creates requirements, specifications, and verifications in the first place.
Until we get there, the spreadsheet stays, the filter goes cold for the third time this morning, and I keep my answers short before the next audit.
How are you keeping your traceability matrix honest — spreadsheet discipline, a side project in your favourite scripting language, or a system that actually owns the links?
Top comments (0)