The traceability matrix is FDA's primary way of verifying your software was built to spec and tested thoroughly. Here's what it needs to contain and how to maintain it.
The traceability matrix is one of the most scrutinised documents in any 510(k) software submission. FDA reviewers use it to answer a simple question: does every requirement have a test, and does every test link back to a requirement?
This guide explains what the matrix needs to contain, how to structure it, and the mistakes that trigger Additional Information (AI) letters.
A traceability matrix is a document that maps requirements to the other artefacts that implement, verify, or validate them. In a medical device DHF, it typically traces:
IEC 62304 §5.7.5 explicitly requires traceability between software requirements and test cases for Class B and C software. FDA expects this in every 510(k) software submission regardless of class.
At minimum, your requirements-to-tests matrix should include:
| Column | Description | Example |
|---|---|---|
| Requirement ID | Unique identifier from your SRS | SRS-042 |
| Requirement Summary | Short description (not the full text) | Session timeout after 5 min inactivity |
| Safety Critical? | Whether this is a safety requirement | Yes / No |
| Test Case ID(s) | SSTC IDs that verify this requirement | TDCS-118, TDCS-119 |
| Test Status | Pass / Fail / Not Executed | Pass |
| Risk Control Ref | ISO 14971 risk control ID, if applicable | RC-007 |
| Notes | Rationale for any deviations or exceptions | — |
The matrix must demonstrate bidirectional coverage:
FDA reviewers will literally scan for:
The most common gap: Requirements added late in development (usually after a change request) that weren't retroactively added to the traceability matrix. Always update the matrix when you add requirements.
If your device is Class B or C, the traceability chain must extend from your ISO 14971 risk management file into the SRS. Specifically, every risk control in your Risk Management Report that is implemented in software must trace to a specific SRS requirement.
This means your traceability matrix (or a supplementary document) needs a column for Risk Control Reference. If RC-007 says "Software shall enforce maximum dose limit", then SRS-042 ("The system shall reject any dose input exceeding 250 Gy") must reference RC-007.
FDA reviewers will cross-reference your Risk Management Report and your SRS. Disconnected risk controls and requirements are a finding.
A traceability matrix is only as good as the process for keeping it current. Common failure modes:
FDA doesn't mandate a specific format. We've seen compliant submissions with:
What matters is completeness and accuracy — not the tool. That said, manual Excel maintenance of large matrices is error-prone. A tool that auto-generates the matrix from linked requirements and test cases reduces the risk of human error and makes updates trivial.
"We submitted with an Excel traceability matrix for our first product. By version 2.0, we had 450 requirements and three engineers spending a week every release keeping it current. The second product was built in a proper tool from day one." — Medical device startup CTO
Before sending your 510(k), verify:
Requirements and test cases linked automatically. Traceability matrix generated from your live data — always current, always complete.
Book a 30-minute demo