Design Traceability Matrix (DTM) Guide for Medical Devices

A Design Traceability Matrix (DTM) is the single source of truth that connects every user need, design input, design output, hazard, risk control, and verification and validation activity in a medical device project. Auditors use it to confirm that nothing was designed without a reason, and nothing was released without evidence. This guide explains what a DTM must contain, how it satisfies FDA 21 CFR 820.30 and ISO 14971, and how modern teams build and maintain one without a half-FTE of manual work.

What a Design Traceability Matrix Is

A DTM is a bidirectional map of design-control artifacts. Read it left to right and every user need resolves into one or more design requirements, design outputs, verifications, and validations. Read it right to left and every verification or design output ties back to a requirement and ultimately to a user need or a regulatory input. The matrix also intersects the risk file: hazards link to the requirements that introduce them and to the risk controls that mitigate them.

The DTM is not a separate deliverable invented for auditors. It is the consequence of disciplined linking inside your design history file (DHF). If your requirements, hazards, and test records reference each other with stable IDs, the matrix exists; you only need to render it.

FDA 21 CFR 820.30 — What the Regulation Requires

21 CFR 820.30 — the Design Controls subpart of the Quality System Regulation — establishes the artifacts a DTM must connect:

• §820.30(c) Design Inputs: requirements derived from user needs and intended use, including applicable regulatory and safety requirements.
• §820.30(d) Design Outputs: the drawings, specifications, code, and labeling that implement the inputs and that can be verified.
• §820.30(f) Design Verification: objective evidence that design outputs meet design inputs.
• §820.30(g) Design Validation: objective evidence that the finished device conforms to user needs and intended uses under actual or simulated use conditions.
• §820.30(g) Risk Analysis: required as part of design validation, with results reflected back into the design.
• §820.30(j) Design History File: the DHF must demonstrate the design was developed per the approved plan — the DTM is how you show it at a glance.

With FDA's adoption of ISO 13485 via the Quality Management System Regulation (QMSR), the same expectations now flow through ISO 13485 §7.3. The artifact list and the need to trace between them does not change.

ISO 14971 — Folding Risk Into the Matrix

ISO 14971:2019 requires a risk management file that identifies hazards and hazardous situations, estimates and evaluates risks, implements risk controls, and verifies that those controls are effective. A complete DTM extends past the §820.30 columns and adds the risk chain:

1. Hazard / hazardous situation identified through preliminary hazard analysis, FMEA, or task analysis.
2. Risk control — typically realized as a design requirement, a protective measure, or information for safety.
3. Implementation evidence — the design output that embodies the control.
4. Verification of effectiveness — the test record showing the control performs as intended.
5. Residual risk evaluation — acceptability after the control is in place.

When every hazard row in your risk file points at a requirement ID, and every requirement that exists as a risk control points back at its hazard, the auditor's "show me how this risk is controlled and verified" question becomes a two-click answer.

The Anatomy of a Useful DTM

A DTM that holds up in an audit usually contains the following columns, rendered or queryable for each user need:

• User Need ID and statement.
• Design Requirement ID(s) derived from that need.
• Design Output reference — drawing number, code module, label.
• Hazard / FMEA ID(s) introduced or mitigated by the requirement.
• Risk Control classification (inherent, protective, information).
• Verification record — protocol and report IDs, pass/fail.
• Validation record — protocol and report IDs, pass/fail.
• Residual risk acceptability after controls.
• Status — draft, approved, obsolete, with revision.

How User Needs, Hazards, and V&V Evidence Connect

The relationship the DTM has to make visible is a graph, not a table. Each user need spawns one or more design requirements. Each requirement can be the source of a hazard (something the design now does that could harm a user) and the home of a risk control (something the design now does to prevent harm). Verification proves the requirement was implemented; validation proves the user need was met under realistic use. The risk file checks that every identified hazard has a control and that every control has verification of effectiveness.

When any one of those links is missing, an auditor's finding is almost guaranteed: an orphan requirement with no user need, an unverified design output, a hazard with no control, or a control with no test record.

Common DTM Failure Modes

• Spreadsheet drift. The DTM is a separate workbook that a single owner updates on Fridays. By the next audit it disagrees with the DHF.
• One-way links. Requirements list their test cases, but test cases do not list the requirement IDs they cover, so reverse traces require manual searching.
• Risk file in isolation. The hazard analysis lives in a separate document and references requirements by description, not ID, so renames silently break the chain.
• No revision history. The matrix shows today's state but cannot reconstruct what was verified at the time of a specific design review or release.

Building a DTM That Stays Current

1. Pick stable IDs early. User needs (UN-), design requirements (REQ-), hazards (HA-/FMEA-), verifications (VER-), and validations (VAL-) all need a prefix and a number that never change.
2. Make links first-class data, not free text. Every link is a typed reference between two artifacts so it survives renames and generates reverse traces automatically.
3. Render the matrix on demand. The DTM is a view over your live data, not a maintained document. Filter it by release, by hazard, or by user need.
4. Audit the graph, not the page. Surface orphan requirements, unverified outputs, and hazards without controls as warnings so they are fixed before an external audit finds them.

Why Purpose-Built Tooling Matters

General-purpose document tools can hold a DTM, but they cannot enforce the relationships that make it trustworthy. A purpose-built requirements and risk platform like redpoint stores user needs, design requirements, hazards, FMEAs, verifications, and validations as linked records, renders the matrix automatically, and flags missing links the moment they appear. The result is an always-current DTM that satisfies 21 CFR 820.30, ISO 14971, and ISO 13485 §7.3 without a dedicated owner chasing spreadsheets.