ISO 13485 and Requirements Traceability: The Integration Problem Competitors Ignore

Key Takeaways

• ISO 13485:2016 Clause 7.3 requires demonstrable traceability from user needs through design outputs, verification, validation, and risk controls. That chain must be auditable, not reconstructed on demand.
• When QMS software and design tools live in separate systems, traceability breaks at the handoff point, and teams spend days reassembling evidence that should already exist.
• A traceability matrix is not a static document. Auditors check whether it reflects the current state of the device, not the state it was in when the matrix was last exported.
• The manual work required to bridge disconnected tools introduces version control errors, gaps in linkage, and audit findings that are entirely avoidable.
• Integrated ALM and QMS platforms eliminate the gap by keeping requirements, risk records, test results, and design documents in a single traceable system.

What ISO 13485 Actually Requires on Traceability

ISO 13485:2016 does not use the term "traceability matrix" once. That matters, because teams sometimes treat the matrix as the requirement rather than as evidence of meeting it.

The actual requirement is distributed across Clause 7.3 (Design and Development) and supported by Clause 4.2.4 (Control of Documents), Clause 4.2.5 (Control of Records), and Clause 7.1, which requires risk management throughout product realization. Read together, they require that you can demonstrate:

• Clause 7.3.3: Design and development inputs are identified, documented, and reviewed. User needs, intended use, regulatory requirements, and outputs from risk management must all be captured as formal inputs.
• Clause 7.3.4: Design and development outputs must meet input requirements and be in a form suitable for verification against those inputs. The link between what was specified and what was designed must be explicit, not assumed.
• Clause 7.3.6: Design and development verification confirms that outputs meet inputs. Test records must be traceable to the specific requirements they address.
• Clause 7.3.7: Design and development validation confirms that the finished device meets user needs and intended use. Validation evidence must trace back to the original user requirements, not just to engineering specifications.
• Clause 7.3.9: Design changes must be controlled and evaluated for impact. You cannot assess impact without knowing what each requirement connects to.
• Clause 7.3.10: A design and development file must be maintained for each device type or family, including the records that demonstrate conformity to design requirements and records of design changes.

What this means in practice: every requirement must have a traceable path forward to its design output, verification test, validation evidence, and any associated risk control. Every risk control must trace back to the requirement it protects. If any link in that chain is broken or undocumented, you have a gap an auditor can and will find.

For a deeper walkthrough of the full ISO 13485 compliance framework, see the Complete Guide to ISO 13485 Compliance for Medical Device Manufacturers. 

Why Traceability Breaks When the QMS and Design Tools Are Separate

Most medical device teams do not start with the intention of building disconnected systems. They start with a requirements tool that works for engineering, then add a QMS platform for quality records, and then discover that these two systems have no shared data model.

Here is where the breakage typically occurs:

Requirements live in the ALM tool. Engineers write and manage specifications, link tests, and track verification in Jira, DOORS, or a similar platform. The engineering team considers this their source of truth.

Quality records live in the QMS. CAPAs, risk assessments, DHF documentation, and change control records are managed in a separate QMS platform. The quality team considers this their source of truth.

Neither system knows the other exists. When a requirement changes in the ALM tool, the QMS does not update. When a CAPA identifies a design gap, the requirements tool does not reflect it. The traceability matrix, if one exists, becomes a snapshot of a moment that has already passed.

The practical consequence: at the time of an audit, neither system alone tells the complete story. The team must pull data from both, reconcile discrepancies, and explain inconsistencies to an auditor who has seen this pattern many times before.

This is not a process failure. It is an architectural one. Separate systems create compliance gaps not because teams are careless, but because the tools were never designed to share a traceability model.

The Manual Work Teams Do to Bridge the Gap

The gap between disconnected systems does not go unmanaged. Teams fill it with manual effort, typically a combination of the following:

Spreadsheet-based traceability matrices. A QA engineer, or sometimes a regulatory affairs manager, manually constructs a matrix that maps requirements to design outputs, tests, and risk items by pulling data from each system and assembling it in Excel. This is often a multi-day effort before any audit.

Scheduled exports and reconciliation. Some teams set a cadence, monthly or quarterly, for exporting data from the ALM tool and comparing it against QMS records. Any delta must be investigated and explained. If the cadence slips, the matrix drifts.

Email and document trails as audit evidence. When a formal link does not exist between systems, teams substitute email chains, meeting minutes, and manually updated Word documents to demonstrate that a connection was made. This evidence is difficult to navigate during an audit and even harder to defend if questioned.

Dedicated "traceability owner" roles. In some organizations, one person effectively serves as the human integration layer, manually maintaining the mapping between engineering records and quality records. When that person leaves, institutional traceability knowledge leaves with them.

The cost of this manual work is not just labor hours. It is the risk of error. Version mismatches, missing links, and outdated cross-references are common. Auditors do not accept the explanation that the matrix was current last month.

For a detailed look at building a defensible traceability matrix structure, see the Requirements Traceability Matrix for Medical Devices: A Complete Compliance Guide. 

What an Auditor Looks For in a Traceability Matrix

An experienced auditor does not review a traceability matrix to confirm that it exists. They use it as a starting point to probe whether your design controls are real.

Specific checks auditors routinely run:

1. Completeness. Every user requirement should have a traceable design output. Every design output should have a corresponding verification test. Auditors pick items at random and follow the chain. Gaps in any link are findings.

1. Currency. The matrix must reflect the current approved version of the device, not a previous release. If your device has undergone design changes since the matrix was last updated, that is a control gap under Clause 7.3.9.

1. Risk linkage. Risk controls identified in your risk management file (per ISO 14971) must appear in the traceability chain. If a risk control is implemented as a design requirement, that requirement must be identifiable in the matrix and verifiable through test records.

1. Verification vs. validation distinction. Auditors check whether teams conflate these. Verification confirms that design outputs meet inputs. Validation confirms that the device meets user needs under real-world conditions. Both require distinct evidence, and both must trace to the right level of requirement.

1. Change control integrity. If the device has an approved change order, the auditor will check whether the traceability matrix reflects the impact assessment and re-verification that should have followed.

Where teams most commonly fail: the matrix is complete at the input/output level but does not show risk control linkage, or it reflects a prior version of the device because the update process was not triggered when a change was approved.

What Integrated ALM and QMS Changes

When requirements, design outputs, test records, risk items, and quality records share a single data model, traceability is not assembled. It is generated.

In a genuinely integrated ALM and QMS platform:

• A requirement created in the system automatically becomes a traceable item. When a test is linked to it, that link is stored, versioned, and visible without a manual export.
• A risk control associated with a requirement appears in the traceability view immediately. When the risk record is updated, the traceability view reflects it.
• A design change triggers an impact assessment that is anchored to the existing requirement structure. The team can see, directly in the system, which requirements, tests, and risk items are affected.
• The DHF does not need to be assembled from multiple sources before submission or audit. It is a live view of the records already in the system, each with its approval status, version history, and linkage intact.
• An auditor request for "show me the traceability for requirement X" is answered by navigating to that item in the system, not by opening a spreadsheet that may or may not be current.

This is not a marginal improvement in efficiency. It is a different compliance posture. The evidence exists continuously, not only when someone builds it.

For a detailed breakdown of how design controls function within this kind of integrated environment, see the Medical Device Design Controls guide. 

Orcanos is built specifically for this model. It is the only platform that links requirements, design outputs, verification and validation records, risk items, and CAPA in a single audit trail, eliminating the integration problem that arises when ALM and QMS operate as separate systems. QMS-only platforms manage quality records without engineering context. Standalone requirements tools manage specifications without quality linkage. Orcanos gives both teams a shared system, so the traceability chain is never broken by a tool boundary.

How to Assess Your Own Traceability Gap

Before your next audit, run this self-check with your team:

1. Can you generate a current traceability matrix in under one hour? If the answer requires pulling data from more than one system, you have a manual gap.

1. Is your traceability matrix version-controlled? If it lives in a shared drive as a spreadsheet, ask when it was last updated and who updated it. Compare that date to your most recent design change.

1. Does your traceability matrix include risk control links? Open any row and confirm that the associated risk item is identified. If risk management and requirements are in separate files, this link is likely missing or informal.

1. Can you demonstrate impact for a design change? Pick any change approved in the last 12 months and trace it from the change order through the affected requirements, re-verification, and updated risk assessment. If that chain requires you to cross multiple systems, document the gaps.

1. Do both engineering and quality have access to the same traceability view? If engineering and quality are working from different records of the same requirements, your audit evidence will reflect that inconsistency.

If any of these checks surface a problem, the corrective action is not another spreadsheet. It is an architectural change: consolidating requirements, design controls, and quality records into a system designed to keep them in sync.

See how Orcanos connects requirements, risk records, and quality evidence in a single traceable system. Schedule a demo to assess your current traceability architecture.

‍

FAQ

What is the difference between forward and backward traceability?

Forward traceability follows requirements downstream: from user needs to design inputs, design outputs, verification tests, and validation evidence. Backward traceability reverses the direction, confirming that every test, output, and design element links back to a documented requirement. A complete traceability matrix must support both directions. Auditors use backward traceability specifically to identify orphaned design features that have no requirement justification.

Who should own traceability: quality or engineering?

Both teams own it, at different levels. Engineering owns the linkage between requirements and design outputs. Quality owns the linkage between design records and the QMS, including risk controls, CAPA, and DHF compilation. The practical problem is that ownership split is where traceability breaks when tools are separate. In an integrated system, both teams work in the same traceability model, so ownership is collaborative rather than sequential.

How often should a traceability matrix be reviewed?

It should be reviewed as a required output of every design change, not on a fixed calendar schedule. ISO 13485:2016 Clause 7.3.9 requires that design changes are evaluated for their effect on the device and its constituent parts. That evaluation is impossible without a current traceability matrix. A matrix that is only reviewed annually will inevitably be out of date for any device under active development.

Does FDA’s QMSR require traceability as well?

Yes. Since February 2, 2026, FDA’s Quality Management System Regulation (QMSR) has incorporated ISO 13485:2016 by reference, so U.S. design control expectations now point to Clause 7.3. The former 21 CFR 820.30 and its Design History File requirement were removed, and the DHF now maps to the design and development file under Clause 7.3.10. The term “traceability matrix” still doesn’t appear in the regulation, but investigators expect to follow a clear link from design inputs through outputs, verification, validation, and risk controls.

Does traceability apply to software-only medical devices?

Yes, and with additional specificity. IEC 62304, which governs medical device software lifecycle processes, requires traceability between system requirements, software requirements, software system testing, and the risk control measures implemented in software. If your device includes software (and many do), traceability obligations extend into the software development record. Managing software requirements alongside hardware design controls in one system makes that full chain far easier to maintain.

‍