This is a ready-to-use traceability matrix for the link auditors most often find missing: a threat-model finding that produced a mitigation nobody can point to inside the design history file, or a security control that was built but never verified against a stated requirement. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen follows. This matrix is a companion to, not a replacement for, your general requirements-to-test traceability matrix; it exists specifically to keep the security file and the design-controls file from diverging.
Instructions
For every credible threat in the threat model, trace it through a requirement, a design element, and a test.
- Where the threat crosses into patient harm, add the corresponding ISO 14971 hazard ID.
- A threat with no downstream requirement, or a requirement with no test, is an open finding, not a completed row.
The matrix
Acceptance criteria
- Every threat rated as credible in the threat model has at least one row in this matrix; a threat with no row is an open gap, not an accepted risk.
- Every security requirement traces to a design element and to a passing verification or validation result; an untested security requirement is treated the same as an untested functional requirement.
- Every threat whose realization could plausibly cause patient harm has a populated safety risk file link; “N/A” is only acceptable with a documented rationale for why the threat has no safety crossover.
- The matrix is reconciled with the threat model and the SBOM at each release, not built once at submission and left static.
References
IEC 62304, Medical device software, Software life cycle processes (design and development traceability expectations; describe, do not reproduce clause text).
ISO 14971, Application of risk management to medical devices.
AAMI TIR57, Principles for medical device security, Risk management.
FDA guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (current version; confirm the version in force).
Revision history
Approvals
Filled specimen
These two rows show the two accepted patterns.
- The first row has a direct patient-harm path: a named hazard ID ties the security control back into the same risk file the clinical and engineering teams already use.
- The second row is an accepted “N/A, security-only” entry, acceptable because the failure mode (a rejected update) is a reliability event, not a harm pathway, and the matrix says so explicitly rather than leaving the cell blank.
Common inspection findings this matrix prevents
- A threat model with twenty identified threats and a design history file that shows mitigations for twelve of them, with no record of what happened to the other eight.
- A security requirement that exists in the SRS with no corresponding test case, discovered only when an auditor asks to see the evidence.
- A threat with an obvious patient-harm path (a spoofed dosing command) that was never linked to the ISO 14971 risk file, so the safety team’s hazard list and the security team’s threat list disagree about what is in scope.
- A matrix built once before the original submission and never updated as the threat model and SBOM changed across subsequent releases.
How to adapt this matrix
- Set your document number and link it to your actual threat model and risk management file document numbers in the header.
- Populate one row per credible threat; do not summarize multiple threats into one row, since that is exactly the compression that hides a gap.
- For a combination product, reconcile the “N/A, security-only” rationale with your drug/biologic-side quality system reviewer, since what counts as a reliability-only event versus a patient-safety event is a judgment call worth a second set of eyes.
- Regenerate or re-review this matrix at the same cadence as your threat model and SBOM updates, per your cybersecurity management plan.
