Requirements-to-test traceability: the guide and the template

Standard & Framework · Verification Evidence

The most common audit finding in regulated software is a broken link between a requirement, its design element, its test, and its ISO 14971 risk control, and a requirements traceability matrix regenerated from source control on every change keeps the 3 clauses of IEC 62304 verification (§5.5 to §5.7) auditable.

A traceability matrix that's regenerated from source control on every change survives an audit; one maintained by hand in a spreadsheet does not.

Why hand-maintained traceability matrices fail audits

A spreadsheet requirements traceability matrix is accurate exactly once — the moment someone finishes updating it — which is why IEC 62304 audits of MedTech software keep finding broken rows. The next requirement change, the next refactored test, the next renamed module: each one silently invalidates a row, and nothing forces anyone to notice. For MedTech teams under IEC 62304, an automated, source-control-derived requirements traceability matrix (requirement → design element → test → risk control, regenerated on every commit) is the practical fix — not a heavier document template.

The template

A minimal, six-column matrix. Download it below or copy the table directly.

Deriving it from a database of record, not a spreadsheet

If requirements, design elements, and test results already live in structured storage, the matrix is a query, not a maintenance chore:

SELECT
    r.requirement_id,
    r.requirement_text,
    d.design_element_id,
    t.verification_method,
    t.test_id,
    t.status,
    rc.risk_control_id
FROM requirements r
LEFT JOIN design_traces d   ON d.requirement_id = r.requirement_id
LEFT JOIN test_results t    ON t.design_element_id = d.design_element_id
LEFT JOIN risk_controls rc  ON rc.requirement_id = r.requirement_id
ORDER BY r.requirement_id;

Every row this query returns is regenerable and dated by the query's own run time — the matrix stops being a document someone forgot to update and becomes a live report.

Engineering reference template only. Not formal regulatory counsel, not a statement of conformance. Adapt to your own quality system's schema and document-control process.

Artifact: requirements-traceability-matrix-template.md

Generated client-side; no server round-trip, no account required.

# Requirements-to-Test Traceability Matrix (template v1.0.0)

Engineering reference template only. Adapt columns to your own quality system.

| Requirement ID | Requirement text | Design element | Verification method | Test/Evidence ID | Risk control (ISO 14971) | Status |
|---|---|---|---|---|---|---|
| REQ-001 | | | Unit test / Integration test / System test / Inspection | | | Pass / Fail / Not run |
| REQ-002 | | | | | | |
| REQ-003 | | | | | | |

## How to keep this from drifting

1. Generate this matrix from source control (commit messages, test IDs, requirement
   IDs), not by hand-editing a spreadsheet after the fact.
2. Every row's Test/Evidence ID must resolve to an actual, reproducible artifact
   (a test run, not "manually verified").
3. Re-generate on every requirement change; a stale matrix is worse than none,
   because it looks authoritative.
4. Every REQ-* with `Risk control` populated must trace to a specific ISO 14971
   risk-analysis record, not a general risk statement.

Download requirements-traceability-matrix-template.md

Useful next step

Run the IEC 62304 gap assessment

Provenance & review state

Last reviewed

September 11, 2026

Sources

• IEC 62304:2006+AMD1:2015 — International Electrotechnical Commission
• ISO 14971:2019 — International Organization for Standardization

Ingested from