Why traceability matters more in 2026
Traceability is how you prove design controls work. Under QMSR, design and development is one of six areas FDA inspects, and verification, validation and software validation are explicit inspection elements (FDA CP 7382.850). FDA’s own QMSR design training says design planning should “Note roles and responsibilities, traceability methods, and resources needed,” and gives the example that “updates were made to the risk traceability matrix of the device” (FDA, Tartal).
For how to build traceability that FDA and auditors trust, see Requirements Traceability for Medical Devices: Building a Traceability Matrix Auditors Trust.
What FDA expects for software traceability
FDA’s 2023 guidance “Content of Premarket Submissions for Device Software Functions” sets clear expectations (FDA):
- “Each requirement identified in the software requirements specification should be traceable.”
- Risk management should include “tracing the identified hazard to the verified specific risk control measures.”
- Verification includes “traceability analyses (e.g., software requirements specification to software design specification.”
In its webinar on the guidance, FDA explained that a separate traceability document is no longer requested in submissions, but that at minimum it expects traceability of “test cases to requirement” (FDA webinar transcript). The matrix still belongs in your design and development file.
For software, IEC 62304 includes clauses on documenting traceability and providing traceability of changes (OpenRegulatory mapping).
Design traceability matrix template
One row per design input. Link each column to a controlled document ID and version.
| ID | User need | Design input | Design output | Verification | Validation | Hazard / risk control | Status |
|---|---|---|---|---|---|---|---|
| DI-001 | Device runs 8 h on battery | Battery life ≥ 8 h at max load | Battery spec BAT-02 v3; power design PD-01 v4 | TR-110 battery life test (pass) | Simulated-use study VAL-03 | HZ-12 loss of power; RC-05 low-battery alarm (verified TR-115) | Complete |
| DI-002 | Clinician enters dose quickly | Dose entry ≤ 3 steps | UI spec UI-04 v2; SW req SRS-031 | SW test ST-031 (pass) | HF summative HF-VAL-01 | HZ-20 wrong dose; RC-09 confirmation screen (verified ST-045) | Complete |
| DI-003 | Safe for skin contact | Biocompatible materials per ISO 10993 | Material spec MAT-07 v1 | Biocompatibility report BIO-02 | Clinical evaluation CE-01 | HZ-31 irritation; RC-11 material selection | Open: BIO-02 pending |
Rows are illustrative.
Software layer
For device software, add rows or a linked matrix: software requirement → architecture/design element → unit or integration test → system test, plus hazard → risk control → verifying test.
Traceability matrix checklist
- Every user need traces to at least one design input
- Every design input traces to output(s) and verification with acceptance criteria
- Validation traces to user needs and intended use
- Every hazard traces to risk controls, and every control to verification of implementation and effectiveness
- Every software requirement traces to tests
- No orphan outputs or tests without a parent requirement
- All references point to controlled documents with versions
- Matrix updated with every design change, with change ID recorded
- Matrix stored in the design and development file
Check traceability without rebuilding the spreadsheet
Matrices drift: a test is renamed, a requirement is split, a risk control is added late. AI document assessment can read requirements, test reports and risk files, flag inputs without verification and controls without evidence, and cite the passage behind every finding.
Run a sample regulatory document assessment on one product’s design file. AskDona shows the evidence; your engineers decide.
FAQ
Is a traceability matrix required by FDA? No regulation names the format, but QMSR design controls and FDA’s software guidance expect traceability between requirements, design, tests and risk controls (FDA).
Do I submit the traceability matrix in a 510(k)? FDA no longer asks for a separate traceability document in software submissions, but expects test-to-requirement traceability (FDA webinar).
What should a risk traceability matrix include? Hazards, hazardous situations, harms, risk controls and the verification that each control works.
How often should the matrix be updated? With every design change, so it always reflects the current design.
References
All pages opened and checked by October 9, 2026.
| Source | Type | Date | Used for |
|---|---|---|---|
| FDA: Content of Premarket Submissions for Device Software Functions | Regulator guidance | Jun 14, 2023 | Software traceability |
| FDA: Software guidance webinar transcript | Regulator | Jul 20, 2023 | Test-to-requirement minimum |
| FDA: QMSR – Design and Development (Tartal) | Regulator training | 2026 | Traceability methods |
| FDA: CP 7382.850 | Regulator | Feb 2, 2026 | Design inspection elements |
| OpenRegulatory: IEC 62304 mapping | Industry resource | Current | IEC 62304 clause titles |