Is a traceability matrix required by regulation?

Not by that name. ISO 13485 requires design outputs traceable to inputs; IEC 62304 requires traceability from system requirements through software requirements to tests and from risk controls to their verification; ISO 14971 requires every risk control to be implemented and verified. A matrix — or any equivalent linked structure — is simply the only practical way to demonstrate all of that at once.

What should a traceability matrix actually link?

Five chains cover the regulatory expectations: user needs to system requirements; system requirements to software/hardware requirements; requirements to verification tests with results; risk controls to the requirements implementing them and the tests verifying them; and requirements to the design outputs that realise them. If a reviewer can walk any of those chains in both directions, you're in good shape.

How granular should trace links be?

Row to row — requirement ID to requirement ID, requirement ID to test case ID. Document-to-document links ('the SRS traces to the test plan') prove nothing, because they can't show which requirement is uncovered. Granularity is what makes gap detection possible.

How do we keep the matrix current after every change?

Make updating the links part of the change itself, not a separate documentation task. When a requirement changes, the change isn't complete until its links — up to needs, down to tests, across to risks — are re-confirmed. Teams that batch this work for audit season always find the backlog has quietly rotted.

Spreadsheet or tool for the trace matrix?

A spreadsheet can express the links; what it can't do is maintain them — every change means hand-searching for affected rows, and nothing warns you when a link goes stale. Whether you migrate to a tool is a question of change volume: if requirements still change weekly, manual reconciliation is a standing tax. Whatever you choose, stable IDs and row-level links are what transfer.

Building a Traceability Matrix That Survives an Audit

What it has to prove

Not a deliverable — a proof.

A traceability matrix exists to answer two families of questions on demand. Downward: "You promised this — show me where it's built and tested." Upward: "This test failed / this component changed — show me everything affected." Auditors ask the first kind; engineering reality asks the second kind weekly.

That's why the matrix can't be a document someone writes. It's a property of your records — either the links between requirements, risks, designs and tests are real and current, or the matrix is a drawing of a bridge that doesn't exist.

An auditor doesn't read your matrix to admire it. They pick a row at random and pull the thread. The matrix survives if every thread holds.

The five chains

What must trace to what.

Chain	Direction	What it demonstrates
1 · Needs → system	UN ↔ SYS	Every user need decomposed into measurable system requirements; no need left unanswered, no requirement without a reason to exist.
2 · System → subsystem	SYS ↔ SW/HW	System requirements allocated to the software and hardware that implement them — the IEC 62304 §5.2 trace for the software side.
3 · Requirements → tests	REQ ↔ TC ↔ RESULT	Every requirement covered by at least one test case, and the test case by an executed result at a named version. Coverage without results is a plan, not evidence.
4 · Risks → controls → verification	HAZ ↔ CTRL ↔ REQ ↔ TC	Each risk control implemented as a requirement and verified by a test — the loop ISO 14971 reviewers walk first, because it's where the patient harm lives.
5 · Requirements → outputs	REQ ↔ DESIGN	Design outputs traceable to inputs — ISO 13485's own wording — connecting the requirement tree to architecture, drawings and code modules.

Notice every chain is written with a double arrow. One-directional traceability is half a proof: down-trace shows completeness of implementation, up-trace shows impact of change. Reviewers use both; so will you, the first time a test fails late.

Who demands it

Nobody says "matrix." Everybody requires the links.

ISO 13485 §7.3 — design outputs must be traceable to design inputs, and verification must confirm the outputs meet them.
IEC 62304 — system to software requirements, software requirements to tests, risk controls to their verification: the standard names the trace explicitly, and class B/C devices get audited on it.
ISO 14971 — every risk control implemented and its effectiveness verified; without chain 4 you can't show either.
EU MDR — the GSPR matrix is itself a trace: requirement to method to evidence. And the technical file reviewers cross-read documents along exactly these links.
FDA QMSR — design controls run through ISO 13485 now, so the §7.3 trace expectations apply on both sides of the Atlantic.

The two orphan checks

Two queries tell you if the matrix is honest.

Orphans: items with no parent. A software requirement no system requirement asked for, a test verifying nothing in the baseline. Orphans mean the team is building and testing things outside the controlled scope — each one is either missing paperwork or missing judgement, and an auditor will want to know which.

Childless items: promises with no proof. A requirement with no test, a risk control with no verifying evidence, a user need nothing decomposes from. Childless rows are the gaps that become findings — and they accumulate silently every time someone adds a requirement under deadline pressure.

Run both checks continuously and the matrix stays a tool; run them before audits and the matrix is a confession. The week-before-the-audit reconciliation everyone dreads is precisely the backlog of skipped orphan checks, paid at the worst possible time.

Keeping it true

Rules that keep the links real.

Stable IDs, forever. A requirement's ID never changes meaning, never gets reused. Every link, risk record and test report cites these IDs for the device's lifetime — under the MDR's retention rules, that's a decade or more.
Row-level links only. "Document A traces to document B" demonstrates nothing. Requirement-to-requirement, requirement-to-test-case — granularity is what makes the orphan checks computable.
Linking is part of the change, not after it. A requirement change is finished when its links — up, down, and across to risks — are re-confirmed. Put it in the definition of done, not in audit prep.
Versions matter. A trace to "the test report" is a trace to nothing. Links point at versions; when the target changes, the link is stale until someone re-confirms it.
Mind the seams. The links that rot first are the cross-document ones — risk file to requirements, requirements to the GSPR matrix — because no single owner sees both sides. Assign the seams, or automate them.

FAQ

Common questions.

Is a traceability matrix legally required?

Not by name. ISO 13485 requires outputs traceable to inputs, IEC 62304 names the software trace explicitly, ISO 14971 requires controls verified. The matrix — or any equivalent linked structure — is simply the only practical way to demonstrate all of it at once.

What exactly should it link?

Five chains: user needs ↔ system requirements; system ↔ software/hardware requirements; requirements ↔ tests with results; risks ↔ controls ↔ verification; requirements ↔ design outputs. If a reviewer can walk each chain both ways, you're covered.

How granular do the links need to be?

Row to row — ID to ID. Document-level links can't show which requirement is uncovered, which is the whole point of the exercise.

How do we keep it current?

Make link maintenance part of each change's definition of done, and run the orphan / childless checks continuously. Batching the work for audit season is how matrices rot — quietly, then suddenly.

Spreadsheet or tool?

A spreadsheet can express the links; it can't maintain them or warn you when they go stale. The deciding factor is change volume. Either way, the stable IDs and row-level links are the asset — they transfer intact to whatever you use next.

A traceability matrix that survives an audit.