---
title: Medical Software Traceability: Requirements, Design, Tests, Risks
description: The 4-way traceability matrix under EN 62304 and EN ISO 14971 — linking requirements, architecture, tests, and risk controls. With a startup playbook.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: medical software traceability requirements tests risks
canonical_url: https://zechmeister-solutions.com/en/blog/software-traceability-requirements-design-tests-risks
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Medical Software Traceability: Requirements, Design, Tests, Risks

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Traceability in medical software means four bidirectional links: every requirement traces to an architectural element, every requirement traces to a test, every risk control traces to the requirement or design that implements it, and every test result traces back to the requirement and the risk it verifies. EN 62304 clauses 5.1.1, 5.2, 5.3, 5.5, 5.6, and 5.7 together make this the backbone of the software lifecycle, and a notified body auditor will ask for your trace matrix first.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- EN 62304:2006+A1:2015 mandates traceability across planning (5.1.1), requirements (5.2), architecture (5.3), unit implementation and verification (5.5), integration testing (5.6), and system testing (5.7).
- The trace must be bidirectional and must include the link from risk controls in the EN ISO 14971:2019+A11:2021 risk file to the software elements that implement them.
- The practical shape of this is a "4-way trace": requirements <-> design, requirements <-> tests, risk controls <-> requirements/design, and risk controls <-> tests.
- An auditor's first request in a software technical documentation review is almost always the trace matrix. A bad trace matrix signals a bad lifecycle. A good one signals the opposite.
- Tooling ranges from spreadsheets to dedicated ALM platforms. The tool matters less than the discipline.
- Untraced requirements are latent hazards. Untraced risk controls are unverified risk controls — which is an MDR Annex I §17.2 finding waiting to happen.

## Why this matters

Every notified body software reviewer I have worked with starts the same way. They ask for the list of software requirements. Then the list of risk controls. Then the trace matrix connecting the two to the tests. If those three artefacts are clean and align, the review is smooth. If they do not, the review becomes a two-day interrogation.

Traceability is the nervous system of your software lifecycle. It is how you prove, not claim, that every requirement was implemented and tested, that every hazard has a control, that every control has a verification, and that nothing slipped through the cracks. Without it, EN 62304 is a bag of documents. With it, EN 62304 is a chain of evidence.

Startups often treat traceability as overhead — something to be backfilled when the auditor is knocking. That is exactly backwards. The trace matrix is the cheapest quality tool in the entire regulatory toolkit when you keep it alive from day one, and the most expensive thing in the project when you try to construct it retroactively.

## What EN 62304 and EN ISO 14971 actually say

EN 62304:2006+A1:2015 embeds traceability as a cross-cutting requirement across several clauses:

- **5.1.1 Software development plan.** The plan must include procedures for traceability, including traceability between system requirements, software requirements, software system test, and risk control measures.
- **5.2 Software requirements analysis.** Requirements must be verified for completeness, consistency, and testability, and must be traceable to system requirements and to the risk control measures.
- **5.3 Software architectural design.** The architecture must be verified to implement the software requirements. That verification is traceability — every software requirement maps to an architectural element.
- **5.5 Software unit implementation and verification.** (For class B and C software.) Unit verification must cover the unit's implementation of its requirements and design.
- **5.6 Software integration and integration testing.** Integration tests verify that integrated units perform as specified and must be traceable to the integration test criteria derived from requirements and architecture.
- **5.7 Software system testing.** System tests verify the software system as a whole against the software requirements and must be traceable to each software requirement.
- **7 Software risk management process.** Risk control measures implemented in software must be traceable. This clause aligns directly with EN ISO 14971:2019+A11:2021.

EN ISO 14971:2019+A11:2021 requires every risk control measure to be verified for implementation and effectiveness. For software-implemented controls, that verification lives in the software verification activities. The only way to show that a risk control was verified is to trace from the risk file to the software test that verified it.

MDR Annex I §17.2 requires software to be developed and manufactured in accordance with the state of the art taking into account development lifecycle, risk management, verification, and validation. EN 62304 is the harmonized standard giving presumption of conformity. Annex II point 6.1(b) requires the verification and validation evidence to be in the technical documentation. Your trace matrix is the index that makes the rest of the evidence navigable.

Put plainly: if you cannot show the auditor that risk control RC-17 is implemented in software requirement SR-42, designed into architectural element AE-9, and verified by test case ST-113 with a passing result, then RC-17 does not exist as far as the audit is concerned.

## The 4-way trace

Across the cited clauses and the risk management link, the trace collapses into four bidirectional relations:

1. **Requirements <-> Design.** Every software requirement is implemented by one or more architectural or detailed-design elements. Every design element exists to implement at least one requirement (or is explicitly justified as non-functional infrastructure).
2. **Requirements <-> Tests.** Every software requirement is verified by one or more tests at the appropriate level (unit, integration, system). Every test exists because it verifies at least one requirement or directly verifies a risk control.
3. **Risk controls <-> Requirements/Design.** Every software-implemented risk control from the EN ISO 14971 risk file is realized by a specific requirement or design element. Every safety-critical requirement is annotated with its source risk control.
4. **Risk controls <-> Tests.** Every software-implemented risk control has a test that verifies its implementation and, where applicable, its effectiveness.

A trace that covers only #1 and #2 is a functional trace. It is incomplete under EN 62304. Safety-focused software requires #3 and #4 to be visible and checkable. That is the difference between a bag of documents and a lifecycle that holds up under audit.

## A worked example: good vs bad trace matrix rows

**Bad row.**
`REQ-042 | "The app must be safe." | Tested | Test_results_final_v3.xlsx`

What is wrong: the requirement is not testable, the test reference is not specific, there is no link to the risk file, no link to a design element, and no pass/fail per criterion.

**Good row.**
`REQ-042 | "When the triage result is 'Emergency', the app shall display the result in red within 1 second and require an acknowledgement before any navigation" | AE-09 TriageResultView, DD-17 UrgencyAlertHandler | UT-112, ST-207 | RC-17 (hazard H-05: user dismisses critical result) | ST-207 passed 2026-02-14, build 2.4.0+b.8842`

What is right: testable, traced to design, traced to tests at two levels, traced to a specific risk control and its parent hazard, and the test result is anchored to a specific build.

A notified body reviewer reading the good row can verify the chain in under a minute. They will check that RC-17 exists in the risk file, that H-05 is evaluated, that ST-207 in the test report passed, that build 2.4.0+b.8842 is the archived release, and that REQ-042 appears in the software requirements specification. Five steps, five confirmations, one clean line of evidence.

Scale that to two hundred requirements and forty risk controls and you have a defensible lifecycle.

## Tooling options

**Spreadsheets.** Workable up to roughly 80 requirements. Beyond that, manual sync between the requirements document, the risk file, the test reports, and the trace matrix becomes a full-time job and a source of errors.

**Issue tracker with custom fields.** Jira, Linear, or GitHub Issues with disciplined linking can act as a lightweight trace database. Export the trace as a report. Works if the discipline holds. Breaks if the team drifts.

**Application Lifecycle Management (ALM) platforms.** Polarion, Jama, Codebeamer, Matrix ALM, and medical-device-specific eQMS vendors offer native 4-way traceability with integrity enforcement. Price goes up, manual effort goes down.

**Hybrid: code-adjacent trace.** Some teams keep requirements and tests in a version-controlled repository next to the code, using identifiers in commit messages and test names. The trace matrix is generated by a build script. Works well for software-forward teams, but the trace still has to be exported into a form an auditor can read without a terminal.

The tool is less important than three things: uniqueness of identifiers, bidirectionality, and maintenance as part of the daily workflow rather than a pre-audit panic.

## The Subtract to Ship trace matrix playbook

**1. Start the trace matrix on day one of software development planning.** EN 62304 clause 5.1.1 requires the software development plan to describe the traceability approach. Decide the tool and the identifier scheme before the first requirement is written.

**2. Require unique, stable identifiers.** Requirements: REQ-nnn. Architecture elements: AE-nn. Detailed design: DD-nn. Unit tests: UT-nnn. Integration tests: IT-nnn. System tests: ST-nnn. Risk controls: RC-nn (matching the risk file). Never renumber.

**3. Every requirement row must have a source and a destination.** Source: a system requirement, a regulatory requirement, or a risk control. Destination: a design element and a test. No orphans. Orphans are review findings.

**4. Link risk controls in the requirement itself.** The requirement text or metadata carries the RC-id it implements. This keeps the safety perspective alive during engineering, not only at audit time.

**5. Trace tests at the level they verify.** Low-level requirements verified by unit tests. Integration concerns by integration tests. End-to-end behavioral requirements by system tests. Risk controls verified at whichever level proves the control works — often system level, sometimes unit.

**6. Automate the trace report.** Whatever tool you pick, the trace matrix is generated, not hand-maintained. The master data lives in the tool; the exported report is the artefact the auditor sees.

**7. Run a monthly trace integrity check.** Five questions: are there any requirements with no tests? Any tests with no requirements? Any risk controls not traced to requirements or design? Any failed tests still marked open? Any requirements added this month without a design link? Any "yes" answer is a to-do.

**8. Use the trace matrix as your software release gate.** Before a clause 5.8 release, the trace must be clean — no orphans, no unverified risk controls, no open failed tests on traced requirements. This is the single most effective quality gate in the lifecycle.

Trace: EN 62304:2006+A1:2015 clauses 5.1.1, 5.2, 5.3, 5.5, 5.6, 5.7 and clause 7 -> EN ISO 14971:2019+A11:2021 risk management -> MDR Annex I §17.2 -> MDR Annex II point 6.1(b). Every link is required. The trace matrix is how you prove the chain holds.

## Reality Check

- Can you produce your current trace matrix in under five minutes? Is it generated or hand-maintained?
- Does every software requirement trace forward to a design element and to at least one test?
- Does every software-implemented risk control from your EN ISO 14971 risk file trace to a requirement and a verifying test?
- Are your test results linked to a specific build identifier, or only to a date?
- How many requirements in your current baseline have no test linked? How many have a linked test that last failed and was never rerun?
- When a risk control changes in the risk file, does your process automatically flag the affected requirements and tests?
- Could a new engineer reconstruct why REQ-042 exists by following the trace backward to a hazard?
- Is your trace matrix the first thing you hand an auditor, or the last?

## Frequently Asked Questions

**Does traceability apply to software safety class A?**
Yes, but the depth is lighter. Class A still requires 5.1.1, 5.2, 5.3, and 5.7. Clauses 5.5 and 5.6 are not required for class A, so unit and integration test traces shrink — but the requirement-to-test and risk-control-to-requirement traces still apply.

**Is a requirements-to-tests matrix enough?**
No. That is two of the four legs. You also need the design link and the risk control links. Many startups stop at two and are surprised by the finding at audit.

**Can we use GitHub Issues as our trace tool?**
Yes, with discipline. Use labels, issue links, and a reporting script. The auditor will still want a human-readable export. Make sure you can produce one.

**How do we trace SOUP components?**
SOUP (software of unknown provenance) is traced through its evaluation record and the requirements it satisfies. If a SOUP component provides a risk-control function, that provision must be traced to the risk control.

**What does "bidirectional" really mean?**
You can start from any node (requirement, design, test, risk control) and find the connected nodes in both directions. No dead ends, no orphans.

**How often do we update the trace matrix?**
Continuously. Every new requirement, every changed test, every risk file update. If you run it as a separate activity, it will drift, and drift is a finding.

## Related reading
- [MDR Software Lifecycle: IEC 62304 Overview](/blog/mdr-software-lifecycle-iec-62304) — the clauses that traceability stitches together
- [Software Requirements Under IEC 62304](/blog/software-requirements-iec-62304) — the upstream node in the trace
- [Software Architecture Documentation](/blog/software-architecture-documentation-iec-62304) — the design node the trace passes through
- [Software Release Process Under IEC 62304](/blog/software-release-process-iec-62304) — how a clean trace matrix unlocks clause 5.8
- [Unit Testing Under IEC 62304](/blog/software-verification-unit-testing-iec-62304) — where the lowest-level trace links live

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17.2; Annex II point 6.1(b).
2. EN 62304:2006+A1:2015 — Medical device software — Software life cycle processes. Clauses 5.1.1, 5.2, 5.3, 5.5, 5.6, 5.7, and clause 7.
3. EN ISO 14971:2019+A11:2021 — Application of risk management to medical devices.

---

*This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*