ISO 13485 traceability and IEC 62304 verification: what a software supplier hands over

Traceability under ISO 13485 and IEC 62304 means you can follow every software requirement to the risk controls it implements, the tests that verify it, and a recorded result on a released build, and back again. The manufacturer owns that chain in its QMS. A software supplier produces much of the evidence and hands it over every release.

This guide is for medtech QA/RA leads, device software engineering managers and SaMD product owners who work with an external software team. It goes one level below our post on ISO 13485 vs IEC 62304: what your software vendor must prove, which explains how the two standards relate. Here we cover how to build the trace, what a verification record contains, who owns which part, and what a good release handover looks like.

This is engineering guidance, not regulatory advice. The manufacturer, and its notified body or FDA reviewer, make the conformity decisions.

Which kind of traceability does ISO 13485 mean?

ISO 13485 uses traceability in two senses. Design traceability links design outputs to design inputs, and it is planned in design and development (clause 7.3.2). Product traceability (clause 7.5.9) links a shipped device or lot to its components and records, with stricter rules for implantable devices. Software teams mostly mean design traceability.

The search phrase “ISO 13485 traceability software” can mean three things: traceability for device software, a software tool that manages traceability, or product traceability for shipped units. This post goes deep on the first, covers the second in the tool validation section, and leaves product traceability to your production and distribution processes.

For device software, the relevant parts of ISO 13485:2016 are:

• Clause 7.3.2, design and development planning: the plan includes the methods for tracing outputs to inputs.
• Clause 7.3.6, verification: verification results and conclusions are recorded.
• Clause 7.3.9, design changes: changes are reviewed, with their impact assessed.
• Clause 7.3.10, design and development files: the records are kept in a file for each device type or family.
• Clause 7.5.9, product traceability: identification of shipped product, lots and records.

Since 2 February 2026, the FDA’s Quality Management System Regulation (21 CFR Part 820) incorporates ISO 13485:2016 by reference. The same design control expectations now apply to manufacturers selling in the US.

In the EU, MDR Annex I, Section 17.2 asks that device software be developed according to the state of the art, taking into account the development life cycle, risk management (including information security) and verification and validation. Traceability is how you show those pieces connect.

What does IEC 62304 add to traceability and verification?

IEC 62304 turns the QMS expectation into software lifecycle tasks. The development plan sets out how traceability will work. Software requirements must trace to system requirements and risk controls. System tests must trace to software requirements, with that traceability recorded. Software risk controls must be traced to their verification. How deep you go depends on the software safety class.

The key clauses in IEC 62304:2006+AMD1:2015 for traceability and verification are:

• 4.3, software safety classification: Class A, B or C sets the depth of the activities below.
• 5.1.1, development plan: covers traceability between system requirements, software requirements, system tests and software risk controls.
• 5.2.6, verify software requirements: including that they trace to system requirements.
• 5.5.2 to 5.5.5, unit verification: the process, acceptance criteria and recorded results, for Class B and C.
• 5.6, integration and integration testing.
• 5.7.4, evaluate software system testing: including recorded traceability between requirements and tests, for all classes.
• 7.3.3, risk control traceability: software hazards traced to their causes, risk controls and the verification of those controls, for Class B and C.

These activities map onto the familiar software product development phases, from planning and design through coding and testing to release and maintenance, with documented outputs expected at each step.

Two terms are worth defining once. SOUP (software of unknown provenance) is any software item you did not develop under your own lifecycle, such as an open-source library or an operating system component. Software safety class reflects the harm a software failure could contribute to, and decides how much documentation and verification the standard expects.

A note on Edition 2

The current text is IEC 62304:2006+AMD1:2015. Edition 2 is still in development: the IEC project is at committee-draft stage, with a draft ballot opened in August 2026, and industry trackers report a forecast publication date of October 2028. Published reviews of the draft say it would replace safety classes A, B and C with two process rigor levels. None of this is final. Keep working to the current edition and do not plan to the draft.

How to build a requirements to risk to tests traceability matrix

Give every requirement, risk control, design item and test a stable ID. Link them both ways, from requirement to risk to design to test to result, and back. Baseline the matrix at each release and check it for gaps. A spreadsheet can work. What matters is controlled versions, complete links, and evidence tied to a specific build.

Minimum columns

A workable matrix for device software carries at least these fields:

• User need or system requirement ID.
• Software requirement ID and text.
• Software safety class.
• Linked hazard and risk control IDs, from your ISO 14971 risk management file.
• Architecture or software item that implements the requirement.
• Unit, integration and system test IDs.
• Result, build or version, and date of the last run.
• Status, for example verified, suspect after change, or open anomaly.

Example rows

Illustrative example, not from a real project. A fictional connected monitoring device:

The third row shows why status matters. The requirement changed after its last passing test, so the link is suspect until the tests are rerun on the new build.

Two-way checks before every release

Run these checks on the baselined matrix before a release candidate goes to review:

• Requirements with no test. Every software requirement needs at least one verification.
• Tests with no requirement (orphans). Either the requirement is missing or the test is noise.
• Risk controls with no verification. Each control needs a test that shows it works.
• Suspect links. Any requirement edited after its last passing test must be retested.
• SOUP with no risk assessment. Every SOUP item should appear in the risk analysis.

What counts as a verification record for medical device software?

A verification record proves that a specific test was run on a specific build and passed or failed against defined criteria. At a minimum it names the test procedure, the software version tested, the configuration and tools used, the date, who ran it, the result, and any anomalies raised. A green CI badge alone is not a record.

IEC 62304 lists what a software system test record should contain (clause 5.7.5, all classes): a reference to the test procedure, the result and any anomalies, the software version tested, the relevant hardware and software configuration, the test tools, the date, and the person who ran and recorded the test.

A few practical rules follow from that:

• Unit-level records apply for Class B and C (clause 5.5.5). Class A needs less, but many teams keep unit results anyway because it costs nothing in CI.
• Retest after changes. When software changes, rerun the affected tests and the regression set, and consider the risk impact of the change (clause 5.7.3).
• Automated output can be the record. CI test output works as a verification record if it is retained, tied to the build, and reviewable. Keep results; do not discard them after a passing run.
• Verification is not validation. Verification (clause 7.3.6) shows outputs meet inputs. Validation (clause 7.3.7) shows the device meets user needs and intended use. They produce separate records, and device validation belongs to the manufacturer.

How do you manage verification workflows for regulated product software?

Plan verification per safety class. Run unit and integration checks in CI on every change, and run system tests against approved protocols on release candidates. Record results against stable requirement IDs and flag any link touched by a change. Keep the workflow in tools your QMS has validated, so the evidence is usable in an audit.

A workflow that holds up in review usually runs in this order:

1. Verification plan. Define what is verified at each level, by which method, against which acceptance criteria, for each safety class (clause 5.1.6).
2. CI evidence on every change. Unit and integration tests run automatically, with results stored against the build ID.
3. Release-candidate system test. System tests run against approved protocols on a frozen build.
4. Review. The trace is checked for gaps, anomalies are evaluated, and deviations are justified.
5. Release package. Records are assembled and handed over (see the handover pack below).

Three supporting processes keep the trace honest:

• Change impact analysis. For every change, record what it touches, what must be retested and which risk controls are affected.
• Problem resolution. Log each anomaly with an ID and link it to the requirements and tests involved (IEC 62304 clause 9).
• Configuration management. Identify every configuration item, including each SOUP item with its version (clause 8, with SOUP identification in 8.1.2).

For versioning and reproducibility questions to put to a partner, use our partner due diligence FAQ.

Who owns what: the manufacturer’s QMS and the software supplier

The manufacturer owns intended use, classification, risk management, design reviews, validation, the release decision, and the design and development file. The supplier, under a quality agreement, typically drafts and maintains software requirements and design, performs and records verification, keeps the trace current, and maintains the SOUP list. The quality agreement sets the exact split.

The basis is ISO 13485 clause 4.1.5 (outsourced processes and quality agreements) and clause 7.4 (purchasing and supplier controls). The table below is a typical split; your quality agreement decides.

The point to get right: the design and development file belongs to the manufacturer (clause 7.3.10). The supplier contributes records to it, release by release.

If you are still choosing a supplier that can work this way, use our regulated software partner scorecard to shortlist.

The supplier handover pack: what you should receive with every release

Each release should arrive as one package your QMS can file without rework. It should contain the release identification, a baselined trace export with a gap summary, verification records, change impact and regression evidence, known residual anomalies with their evaluation, the SOUP list or SBOM, and the configuration items. Ask for it in your formats, every release, not only at the end.

This is the per-release view. For the documents to request before signing, see the ISO 13485 vs IEC 62304 post.

1. Release identification: version, build ID, source revision, and how the build was produced (clauses 5.8.4 and 5.8.5).
2. Trace export from the agreed tool (CSV or PDF), baselined, with coverage figures and a gap summary for that release.
3. Verification records at unit, integration and system level, as applicable to the safety class.
4. Change impact analysis and regression results since the previous release.
5. Known residual anomalies, documented (clause 5.8.2) and, for Class B and C, evaluated for risk (clause 5.8.3).
6. SOUP list or SBOM with versions and vulnerability status. For the buyer-side questions, see our SBOM and vulnerability questions for health software partners.
7. Configuration item list and a description of the build and test environments.
8. Review records for the code and design reviews the supplier took part in.
9. Deviations from the plan, each with a justification.
10. A signed delivery note under the quality agreement.

Agree stable IDs and an export format in week one. That keeps your evidence portable and avoids lock-in to a tool only the supplier can open.

Does ISO 13485 traceability software need to be validated?

Yes, if the tool is part of your quality system. ISO 13485 clause 4.1.6 requires documented validation of computer software used in the QMS, before first use and after changes, proportionate to risk. For US manufacturers, FDA’s Computer Software Assurance guidance describes a risk-based way to do this. Spreadsheets used as QMS records count as well.

The current version is FDA’s Computer Software Assurance for Production and Quality Management System Software (February 2026). It supersedes the final guidance issued on 24 September 2025 and is written for the QMSR, 21 CFR Part 820.

Practical points:

• Tool choice belongs to the manufacturer. Whether you use a dedicated requirements management tool or a controlled spreadsheet, you validate it for your intended use.
• Ask your supplier one question: can it work directly in your validated tool, or deliver a structured export with stable IDs that you import?
• Supplier tools produce evidence; your QMS holds it. A supplier’s CI server and issue tracker generate records. You decide how those records enter your validated system.

Traceability gaps that show up in audits and reviews

The gaps that hurt are specific. Watch for orphan tests and untested requirements, requirements edited after their last passing test, risk controls checked for implementation but not effectiveness, tests run on a different build than the one released, SOUP missing from the risk analysis, and unit results discarded after a passing run.

• Untested requirements and orphan tests. Fix: run the two-way check on every release candidate and block release on open gaps.
• Requirements edited after their last pass. Fix: mark links suspect automatically on any requirement change, and clear them only by a rerun.
• Risk controls verified for presence, not effect. A test shows the alarm exists but not that it fires in time. Fix: write a test that exercises the hazard scenario.
• Tests run on the wrong build. Results come from build 1.4.1, but 1.4.2 shipped. Fix: tie every record to a build ID and check it against the release identification.
• SOUP missing from the risk analysis. Fix: generate the SOUP list from the build, and reconcile it with the risk file each release.
• Unit results discarded. CI kept only the last green run. Fix: retain results per build for Class B and C items.
• Anomalies with no link. A known bug is not tied to the requirement it affects. Fix: require a requirement or test ID on every anomaly.
• IDs that change between tools. Fix: agree stable IDs and the export format at the start.

How Areusdev fits

Areusdev builds device and health software under the client’s ISO 13485 QMS, following IEC 62304 lifecycle practices. The client owns conformity decisions; Areusdev produces the engineering evidence: requirements traceability, verification records and release packages. Founded in 2004, Areusdev has 72 people, 17 of them in healthtech engineering.

In practice, that means we agree the trace structure, IDs and export formats with your QA/RA team at the start, keep the software part of the trace current, and deliver a handover pack with every release. You own conformity decisions; we own engineering clarity.

Public health R&D work includes NerveRepack, an EU research consortium where Areusdev contributes engineering. Learn more about our medical device R&D software engineering and healthcare software development.

Frequently asked questions

Does ISO 13485 require a traceability matrix?

ISO 13485 does not name a document called a traceability matrix. It does require planned methods to trace design outputs to design inputs, plus records of verification and validation. A traceability matrix is the usual way to show that. A controlled spreadsheet can be enough, as long as it is complete, versioned and tied to specific builds.

What is the difference between verification and validation for medical device software?

Verification checks that design outputs meet design inputs: did we build it right? It is covered by ISO 13485 clause 7.3.6 and, for software, by IEC 62304. Validation checks that the device meets user needs and its intended use: did we build the right thing? It is covered by clause 7.3.7, and the manufacturer owns it.

Does IEC 62304 require tracing unit tests to requirements?

Not explicitly. The standard’s traceability requirements cover system requirements, software requirements, system tests and software risk controls, risk controls to their verification, and changes. Unit verification for Class B and C runs against defined acceptance criteria instead. Many teams link unit tests to requirements anyway, because it makes change impact analysis faster and gaps easier to spot.

Who owns the design history file when an external supplier writes the software?

The manufacturer. Under ISO 13485, the manufacturer keeps the design and development file (clause 7.3.10), still called the DHF in older FDA terms. The supplier contributes records under the quality agreement, such as requirements, design, verification results and trace exports, and hands them over with each release.

Do traceability tools need to be validated under ISO 13485?

Yes, when the tool is part of your quality management system. Clause 4.1.6 requires documented validation of QMS software before first use and after changes, proportionate to risk. FDA’s Computer Software Assurance guidance gives US manufacturers a risk-based approach. See the tool validation section above for what to ask your supplier.

Will IEC 62304 Edition 2 change traceability requirements?

Edition 2 has not been published. It is at committee-draft stage, with publication forecast for October 2028. Keep working to IEC 62304:2006+AMD1:2015 and do not plan to the draft. We will revisit this answer when the IEC publishes the new edition.