Traceability for Medical-Device Software (ISO 13485)
For medical-device software, traceability isn't a nicety. A design input has to link to the test that verifies it — and an auditor follows that thread.
Traceability isn't a nicety here
The usual caveat first, and it matters more in this cluster than most: what follows is a plain description of how medical-device software teams commonly approach traceability. It is not legal or regulatory advice, and it doesn't replace a qualified quality or regulatory professional who knows your device and its standards. Take it as a mental model, and confirm the specifics with someone qualified.
In most software, traceability — linking a requirement to the test that checks it — is good practice you can get away with skipping. In medical-device software, it isn't optional. Under standards like ISO 13485 and IEC 62304, a design input has to be linked to the verification that proves it was met, and an auditor will follow that link. A requirement with no traceable test behind it is a gap you have to explain.
That changes what the test record is for. It's not just a place to write cases; it's the thing that proves each requirement was covered, and the thread an assessor pulls to check. This is what that traceability is actually asking for, in plain terms.
Why traceability is central for device software
The logic behind the requirement is worth understanding, because it explains why assessors care so much about the links.
A medical device's software does something that can affect a patient. So the standards insist you can show a clean line from what the software was required to do, through the design, to evidence that it does it — and that nothing required was left unverified.
Traceability is how that line is made visible. Referenced plainly, ISO 13485 frames the quality-system expectation and IEC 62304 the software-lifecycle one, and both lean on the same idea: requirements don't stand alone; each is tied to the verification that closes it.
The consequence for testing is direct. Every requirement needs a case that verifies it, every case needs to point back to its requirement, and the whole set has to be navigable. "We tested thoroughly" is not the claim being assessed. "Every design input links to the verification that proves it" is.
The chain: requirement to case to run to defect
The traceability record is the same four-link chain the rest of this cluster keeps returning to, and here it's followed in both directions.
Forward: a requirement links to the case that verifies it, which links to the run that executed the case and its result, which links to any defect found and its resolution. Backward: from a failed run or a changed requirement, you can trace to everything it touches.
The forward direction proves coverage; the backward direction answers "if this requirement changed, which tests are now affected?" — the question that turns a small spec change from a guessing game into a list.
The link teams most often can't produce cleanly is the maintained connection between the requirement and the case as both evolve. It's easy to draw the links once and let them rot as requirements change and cases get rewritten. A traceability record is only worth anything if the links are kept current, because a stale link is worse than none — it claims a coverage you no longer have.
Where computer system validation fits
Alongside traceability sits computer system validation — CSV — and it's worth placing plainly, because the two are often tangled together.
Where traceability proves your requirements were verified, validation is the broader activity of demonstrating that a computerised system does what it's intended to do in its actual use, consistently. Testing is a core part of that demonstration: the validation asks what the system must do, and the test evidence shows it does.
What testing has to prove, in a validation context, is not just that features work in isolation but that the intended use is met and the evidence is documented, traceable, and reviewed.
The practical link is that good traceability makes validation tractable. If every requirement already traces to its verification, a large part of the validation evidence assembles itself. If it doesn't, validation becomes the painful exercise of reconstructing those links after the fact.
Traceability proves you verified what you were required to build. Validation proves the system, in real use, does what it's for. Testing is where both of them get their evidence.
Maintained, or reconstructed
Everything above comes down to one operational choice: are the links kept as you work, or rebuilt when someone asks?
A record that maintains the trace continuously — every case tied to its requirement, every run kept, every change tracked — turns an audit or a validation into an export. You filter to the release and produce the chain. A record that doesn't turns the same request into a multi-week reconstruction project, assembling links from memory and scattered documents, under time pressure, with the credibility problems that come from building evidence after the fact.
This is the whole practical argument for treating the test record as a record from the start, rather than a working tool you tidy later. In a regulated device context, "we'll sort out the traceability before the audit" is how a fortnight, or a month, disappears.
Common practice, not advice
Stated plainly once more: this describes how device-software teams commonly think about traceability and validation. It is not a determination of your obligations, which depend on your device, its classification and intended use, your quality system, and your organisation's interpretation of the applicable standards.
Use it as the shape of the thing, and confirm every specific with a qualified quality or regulatory professional. A blog post is a starting point for understanding, never the standard an assessor will hold you to.
Where a record helps
The honest role for a tool is to keep the links current as you work, so the trace is always producible. A system that maintains requirement-to-case traceability, keeps runs as their own records, versions cases with their history, and logs approvals is maintaining the chain by default — the same record a release rests on, kept navigable.
The boundary must be exact. Tesbo keeps the case record and its traceability; it does not run, schedule, or execute your tests, and it does not perform validation. And plainly: Tesbo is not certified, validated, or compliant with ISO 13485, IEC 62304, or any standard, and using it does not make you compliant. A maintained traceability record is a foundation for the evidence — not a substitute for validation or for an assessment by a qualified professional.
Questions people ask
Why is requirements traceability required for medical-device software?
Because the software can affect patients, standards like ISO 13485 and IEC 62304 expect you to show a clean line from each requirement to the verification that proves it was met, with nothing required left unverified. Traceability makes that line visible and navigable for an assessor. It's a general expectation described here, not compliance advice for your specific device.
What does the traceability chain look like?
Requirement to case to run to defect, followed both ways. Forward, a requirement links to the case that verifies it, the run that executed it, and any defect found — proving coverage. Backward, from a changed requirement or a failure you can find everything affected. The backward direction is what makes a spec change a list to work through rather than a guess.
How does computer system validation relate to traceability?
Traceability proves your requirements were verified; validation is the broader activity of showing the system does what it's intended to do in real use, consistently. Testing supplies evidence for both. Good traceability makes validation far easier, because much of the evidence assembles itself when every requirement already links to its verification.
What happens if traceability links aren't maintained?
They rot. As requirements change and cases get rewritten, links drawn once become stale — and a stale link is worse than none, because it claims coverage you no longer have. Maintaining the links as you work is the only way the record stays trustworthy; reconstructing them before an audit is slow and undermines its own credibility.
Does a test tool make us ISO 13485 or IEC 62304 compliant?
No. A tool can maintain the traceability and records that make an audit or validation far easier, but compliance is an assessment against the standards for your specific device, made by a qualified professional. Keeping a maintained, navigable record is a foundation for that evidence, not a replacement, and no vendor can hand you compliance.
