What auditors are actually asking for
When an auditor asks to see your traceability documentation, they're asking one underlying question: can you demonstrate that every user need is satisfied, and that you know it's satisfied because you can point to the evidence? Traceability is the mechanism by which you answer that question — not in theory, but with a live, navigable record that doesn't require you to spend three days assembling a spreadsheet before each review.
This guide is for teams building under ISO 13485 (quality management for medical devices) and IEC 62304 (software lifecycle for medical device software). The principles apply broadly to other regulated domains — DO-178C in aerospace, ISO 26262 in automotive — but the specific requirements language used here reflects the medical device context where most early-stage regulated software teams are operating.
The anatomy of a complete traceability chain
A complete traceability matrix for a medical device software submission traces from the top of the requirement hierarchy to the bottom of the verification stack. The standard levels are:
- User Needs (UN) — What the user or patient needs from the device. Written in user-facing language. Not yet system-specific.
- System Requirements (SRS) — What the system must do to satisfy the user needs. Testable, unambiguous, attributable.
- Software Requirements (SwRS) — Software-specific decomposition of system requirements, with safety classification per IEC 62304 §5.2.
- Software Architecture / Design Inputs (DI) — How the software is structured to implement the requirements.
- Verification Activities (V&V) — Tests, inspections, analyses, or demonstrations that provide objective evidence the requirement is met. Each requirement must trace to at least one verification activity with a recorded result.
Bidirectional traceability means: given any user need, you can trace forward to the verification evidence that it's satisfied. Given any test case, you can trace backward to the user need it validates. Both directions matter. Forward traceability answers "is everything covered?" Backward traceability answers "why does this test exist?"
ISO 13485 and IEC 62304: what they actually require
ISO 13485 §7.3 (Design and Development) requires that design inputs be documented, that design outputs trace to design inputs, and that design verification confirms that outputs meet inputs. The standard doesn't prescribe a specific tool or format — it requires demonstrable, documented linkage.
IEC 62304 §5.2 requires that software requirements be defined, that they be traceable to system requirements, and that they be updated when system requirements change. §5.7 requires that software integration testing trace to software requirements. §5.8 requires that system testing verify system requirements. The standard explicitly requires traceability items to be identified and maintained throughout the software lifecycle.
The key phrase in both standards is "maintained throughout." A traceability matrix that was accurate at the time of the design freeze but hasn't been updated through three subsequent software versions is not compliant — even if it looked perfect at the time it was created.
Common mistakes that fail audits
Traceability as a one-time deliverable
The most common failure mode: the team builds a traceability matrix right before submission, maps everything manually, and submits it as a static artifact. The auditor asks a question about a change made in a later software version. The traceability matrix was built against an earlier version. Nobody updated it. The audit finding writes itself.
Traceability is a living record, not a submission artifact. It must be maintained with every requirement change, every design decision, every verification activity added or modified. If your tooling doesn't make it easy to update trace links when requirements change, your traceability will drift — guaranteed.
Unidirectional coverage
Teams often build top-down traceability (user need → system req → software req → test) but don't verify bottom-up. The failure this creates: orphaned test cases that don't trace to any requirement (which raises questions about why they exist), and requirements that have trace links but no corresponding test results in the record (which is a gap in your verification evidence).
Before any submission or review, run both directions: confirm every leaf-level requirement traces to at least one verification activity with a result, and confirm every verification activity traces back to at least one requirement.
Trace links that say nothing
A trace link is not just a line between two IDs. A trace link should convey relationship type. "UN-004 traces to SRS-017" tells an auditor nothing about whether the relationship is a full satisfaction, a partial satisfaction, or a derived relationship. The more useful record: "SRS-017 satisfies UN-004" or "SwRS-031 implements SRS-017 (partial — see also SwRS-032 and SwRS-033)."
Most tools support relationship type tagging. Use it. An auditor reading a traceability matrix annotated with relationship semantics can verify your logic in minutes. An auditor reading a matrix of bare ID pairs has to trace the logic themselves — which means they're more likely to find something inconsistent.
Requirements that can't be verified
A requirement that has no verification activity is a gap. A requirement with a verification activity that doesn't actually test the requirement is a more dangerous gap — because it appears covered until someone reads carefully. "The system shall respond to user input within an acceptable timeframe" with a verification activity of "tested and passed" is not a verifiable requirement with defensible evidence. "The system shall respond to user input within 200ms under peak load conditions as defined in performance specification PS-003" with a corresponding load test protocol and recorded results is.
Review your requirements for verifiability before building your traceability matrix. Requirements that can't be tested need to be revised, not just linked to a vague inspection record.
Change history gaps
When a requirement changes, the traceability matrix must reflect the change, the trace links must be reviewed for validity, and the change must be recorded with attribution — who changed it, when, why, and what approval process it went through. This is where teams using Word documents consistently fail: tracked changes show what changed, but not who approved the change, whether downstream trace links were reviewed, or whether the corresponding verification activities were updated.
This is also the gap that purpose-built requirements tools close. Immutable revision history with change attribution, coupled with trace link staleness detection, is the baseline compliance primitive that separates a requirements management tool from a document editor.
Structuring your traceability matrix for a real submission
Here's a practical structure for a traceability matrix that satisfies both ISO 13485 §7.3 and IEC 62304 §5.2 reviewers:
- Forward matrix columns: User Need ID | User Need text (abbreviated) | System Req ID(s) | Software Req ID(s) | Verification Activity ID(s) | Verification Result | Status
- Backward matrix columns: Verification Activity ID | Protocol version | Requirement ID(s) verified | Result summary | Date executed | Executed by
- Relationship type annotation: For each link, note whether it's a full satisfaction, partial satisfaction, or derived requirement
- Change tracking: Each row should reference the current approved version of the requirement and the date the trace link was last verified as current
- Gap column: Explicit "gaps identified" field for requirements with incomplete verification, open trace links, or known deviations under review
The goal is not a perfect matrix — auditors understand that products evolve. The goal is a matrix that demonstrates disciplined process: gaps are known, documented, and have a resolution path. Undocumented gaps are audit findings. Documented gaps with a resolution plan are typically manageable findings that don't stall a submission.
Tooling implications
The traceability discipline described above is achievable in a well-maintained spreadsheet. It is not sustainable in a spreadsheet at any serious development scale or pace. The operational cost of manually updating trace links, checking for orphans, verifying bidirectional coverage, and generating submission-ready matrix exports creates a compliance burden that grows faster than the product itself.
The minimum viable requirements tooling for a regulated submission should provide: structured requirement IDs, typed trace link relationships, revision history with change attribution, and export to a matrix format readable by auditors. If your current tool doesn't provide these as first-class features, you're accumulating technical debt in your compliance infrastructure.
For teams evaluating tooling before their first serious submission: the question to ask isn't "can we get through the audit with what we have?" It's "when the auditor asks to see how a specific requirement changed between versions, how long does it take us to pull that record?" If the honest answer is "more than five minutes," the tooling needs to change before the submission, not after.