A Requirements Traceability Matrix (RTM) is a structured record that connects each medical-device requirement to its source, associated risk controls, design outputs, and verification and validation evidence.
An RTM helps regulators and internal teams confirm that every approved user need and design input has been implemented, tested and formally closed before the device is released.
What is a Requirements Traceability Matrix?
A Requirements Traceability Matrix is a table or database that maps the relationships between requirements and the development records that satisfy them. It may be maintained in a spreadsheet, requirements-management platform or application lifecycle management system.
Each row normally represents one requirement. The columns identify information such as:
- Unique requirement identifier
- Requirement description
- Source or parent requirement
- Applicable risk control
- Design output
- Verification method
- Verification protocol and result
- Validation activity
- Current status
- Change history
- Responsible owner
Inside a medical-device Design History File or design and development file, the RTM acts as the connective layer between otherwise separate records. It links user needs to design inputs, design inputs to design outputs, and design outputs to objective verification and validation evidence.
Without this traceability, a development team may have approved specifications, drawings, source code and test reports but no reliable evidence that the records collectively cover every requirement.
RTM tools and formats
A small, stable project may maintain its traceability matrix in a controlled spreadsheet. More complex devices usually benefit from dedicated requirements-management or ALM software.
Platforms such as Jira can support requirements, tasks, defects and test records through configured issue types and relationships. However, a standard Jira configuration does not automatically create a compliant RTM, controlled baselines, electronic approvals or immutable audit trails. Medical-device teams may need validated plugins, overlays or integrations with dedicated ALM software.
Regardless of the selected tool, the manufacturer should define:
- What information the RTM will contain
- Which records are controlled
- Who may create, change or approve entries
- How revisions and baselines are managed
- How broken or missing links are detected
- How the system will be validated for its intended use
- How traceability records will be retained
The quality of the traceability model matters more than the name of the software used to maintain it.
Why an RTM matters in medical-device development
Patient safety depends on every functional, performance and safety requirement being implemented and tested—not merely documented.
An RTM exposes important gaps, including:
- A requirement with no associated design output
- A risk control with no verification evidence
- A test case that does not trace to an approved requirement
- A design output that implements an unauthorized feature
- A changed requirement linked to an obsolete test
- A failed test without documented resolution
- An unvalidated user need
- A software anomaly affecting a safety requirement
A missing link in a spreadsheet may appear to be an administrative problem. If the missing test allows an unsafe design to reach patients, it can become a complaint, CAPA, field correction or recall.
Regulators also treat traceability as evidence of design-control maturity. FDA reviewers and notified-body auditors may request a traceability matrix during a premarket review, technical-documentation audit or quality-system inspection.
An incomplete RTM can reveal where the development process lost control. Traceability gaps commonly lead to:
- Regulatory questions
- Audit nonconformities
- Additional testing
- Delayed submissions
- Design rework
- Incomplete risk-control verification
- Unresolved software requirements
- Expensive post-launch corrections
Traceability also reduces development costs. A missing requirement link is relatively inexpensive to correct during a design review. The same gap may require another test cycle if discovered during formal verification and could require a design change or field action if identified after launch.
Regulatory expectations for requirements traceability
ISO 13485:2016 Clause 7.3 requires manufacturers to maintain controlled design and development planning, inputs, outputs, reviews, verification, validation, transfer and changes. The standard does not require a document specifically named “Requirements Traceability Matrix,” but manufacturers must be able to demonstrate connections among these records.
The FDA Quality Management System Regulation became effective on February 2, 2026. Under 21 CFR 820.10, FDA now incorporates ISO 13485:2016 by reference, subject to the additional provisions of the QMSR.
Therefore, older references to 21 CFR 820.30(f) for verification and 820.30(g) for validation should not be used as the current regulatory basis. The applicable design and development requirements are now principally framed through ISO 13485 Clause 7.3 under the QMSR.
EU MDR and IVDR technical documentation similarly require manufacturers to demonstrate that applicable safety and performance requirements have been addressed. An RTM can help connect design requirements and risk controls to the evidence supporting the General Safety and Performance Requirements checklist.
For software-containing devices, IEC 62304 adds detailed traceability expectations between software requirements, architecture, implementation, risk controls, anomalies and software-system testing.
How a Requirements Traceability Matrix works
An RTM should be built incrementally as the design-controls process progresses. It should not be assembled retrospectively as a paperwork exercise immediately before a submission.
A comprehensive RTM typically connects the following elements.
User needs
User needs describe what users and patients require from the device. They should reflect the clinical objective, intended users, use environment and expected outcomes.
Validation ultimately confirms that the finished device meets these needs and its intended use.
Design inputs
Design inputs translate user needs, regulatory requirements, standards and risk controls into measurable and testable requirements.
Effective design inputs should be:
- Clear
- Complete
- Unambiguous
- Verifiable
- Consistent
- Identifiable
- Approved
Every design input should have a unique identifier and a traceable source.
Design outputs
Design outputs are the specifications and records that implement the approved inputs. Examples include:
- Engineering drawings
- Product specifications
- Software requirements
- Source code
- Schematics
- Bills of Materials
- Manufacturing instructions
- Inspection criteria
- Labeling
- Packaging specifications
- Service procedures
The RTM should identify which output or group of outputs implements each input.
Risk controls
Many product requirements originate as measures intended to control risks identified under ISO 14971. The RTM should connect those requirements to the relevant hazard, hazardous situation or risk-control record.
This connection allows reviewers to confirm that every required control was:
- Converted into an actionable requirement
- Implemented in the design or process
- Verified for correct implementation
- Evaluated for effectiveness
- Assessed for new risks
Verification records
Verification provides objective evidence that design outputs satisfy their corresponding design inputs.
The RTM may reference:
- Verification protocol
- Test-case identifier
- Analysis report
- Inspection record
- Acceptance criteria
- Test result
- Deviation or anomaly record
- Final verification report
A requirement should not be marked complete merely because a test exists. The associated result must demonstrate that the approved acceptance criteria were met or that any failure was formally resolved.
Validation records
Validation confirms that the finished device meets user needs and its intended use under actual or simulated conditions.
Validation links may include:
- Usability-validation protocols
- Clinical-evaluation evidence
- Simulated-use studies
- Performance-validation reports
- Production-equivalent unit records
- Labeling-validation activities
- Final validation conclusions
The matrix should distinguish design verification from design validation because the two activities answer different questions.
Software records
For software-driven devices, IEC 62304 traceability may connect:
- System requirements
- Software-system requirements
- Software architecture
- Software items and units
- Risk-control requirements
- Implementation records
- Unit-verification tests
- Integration tests
- Software-system tests
- Anomalies and problem reports
- Released software versions
Software traceability should reflect the approved version and safety classification of the software being released.
Change records
A requirement change can affect architecture, design outputs, risk controls, test methods, results, labeling and regulatory documentation.
The RTM should show:
- Which requirement changed
- Why it changed
- Which records were affected
- Whether risk analysis was updated
- Whether re-verification was required
- Whether validation remained applicable
- Which version was approved
- When the revised requirement became effective
Traceability is especially valuable during change-impact analysis because it exposes downstream records that might otherwise be overlooked.
Forward and backward traceability
Effective traceability operates in both directions.
Forward traceability
Forward traceability follows a requirement through implementation and testing. It confirms that every approved user need and design input reaches an implemented, verified and validated output.
A simplified forward chain might be:
User need → Design input → Risk control → Design output → Verification → Validation
Backward traceability
Backward traceability begins with a design output or test and follows it back to its authorized source.
It confirms that:
- Every implemented feature originates from an approved requirement.
- Every test evaluates something the device was required to do.
- Unauthorized scope has not entered the product.
- Every output has a documented justification.
Using forward traceability alone can leave unnecessary or unauthorized features undetected. Backward traceability helps control scope and ensures the team is not testing or building something that was never approved.
RTM status management
Every requirement should have a defined status. Possible statuses include:
- Draft
- Under review
- Approved
- Implemented
- Verification planned
- Verification passed
- Verification failed
- Validation complete
- Deferred
- Obsolete
- Closed
Status definitions should be controlled and consistently applied. A requirement should not be closed while its verification activity is incomplete, failed or linked to an unresolved anomaly.
Dashboards or matrix filters can help identify:
- Requirements without outputs
- Requirements without verification
- Failed or incomplete tests
- Unapproved changes
- Orphaned risk controls
- Tests without parent requirements
- Links pointing to obsolete document versions
Common challenges and best practices
Allowing the spreadsheet to become outdated
A frequent failure is maintaining an RTM in a spreadsheet that no longer reflects the current design. Requirements change, but the matrix retains old references to specifications or tests.
By the time an auditor reviews it, the RTM describes an earlier product version.
Assign ownership, control revisions and update the matrix as each requirement or linked record changes.
Building traceability retrospectively
Reconstructing traceability before a regulatory submission is time-consuming and unreliable. Teams may struggle to determine which test covered an earlier requirement or why a design decision was made.
Build and maintain the RTM as development occurs.
Maintaining only forward traceability
Tracing requirements to tests is necessary but insufficient. Teams must also confirm that every test and implemented feature has an approved source.
Perform both forward and backward traceability reviews.
Orphaned requirements
An orphaned requirement has no associated design output, risk control or verification activity. This may happen because a test was deferred, ownership was unclear or the requirement changed without updating downstream plans.
Run an orphan-link report before every formal design review.
Linking documents rather than specific evidence
A link to a 200-page test report may not tell a reviewer which test or result covers the requirement. Reference the specific protocol section, test-case identifier and result whenever possible.
Incorrect document versions
A valid link to an obsolete test protocol or earlier drawing does not demonstrate coverage for the released design.
Baseline the RTM with the approved product configuration and confirm that linked documents use the applicable revisions.
Confusing verification and validation
Verification confirms that outputs meet inputs. Validation confirms that the device meets user needs and intended use.
Keep separate matrix columns for verification and validation so the two types of evidence are not treated as interchangeable.
RTM best practices
Strong teams generally:
- Begin traceability when user needs and requirements are created.
- Assign a unique identifier to every controlled requirement.
- Record the source of each requirement.
- Connect requirements to applicable risks and standards.
- Maintain both forward and backward traceability.
- Link to specific test cases and results.
- Include requirement and document revision information.
- Use controlled status definitions.
- Assign an accountable RTM owner.
- Review traceability at every design-review gate.
- Baseline the matrix before formal verification.
- Reassess affected links after every approved change.
- Confirm that the final RTM matches the released device configuration.
The RTM should remain a living design record updated throughout the Phase-Gate Process, not a static document created only at project closure.
How SJML helps with Requirements Traceability Matrix
SJML builds requirements traceability into its medical device design and engineering process from concept and feasibility onward.
Engineering teams maintain connections among user needs, design inputs, design outputs, risk controls, verification and validation evidence as part of phase-gate program management. Structured change control keeps the matrix aligned as requirements and designs evolve.
ISO 14971 risk controls and IEC 62366 usability requirements link into the same structure, helping ensure that safety measures and use-related requirements remain connected to implementation and objective evidence.
This traceability extends across SJML’s electromechanical development, software, verification and design-transfer activities. It helps device teams approach design reviews, regulatory submissions and audits with a matrix that represents the current product rather than an obsolete development snapshot.
Frequently asked questions
A Design History File (DHF) is the complete compilation of records describing a device’s design history, including design plans, inputs, outputs, and reviews. The RTM is one document inside that file: the index linking every requirement to its supporting evidence elsewhere in the DHF.
Neither FDA 21 CFR Part 820.30 nor ISO 13485 names “RTM” explicitly, but both require demonstrable links between design inputs, outputs, verification, and validation. An RTM is the standard way manufacturers meet that requirement and present it to auditors.
At minimum: user needs, design inputs, design outputs, verification test references, validation test references, and status. Many teams also add risk control linkage under ISO 14971 and, for software-containing devices, IEC 62304 software item references.
Ownership typically sits with the design or systems engineering lead, though quality and regulatory affairs review it at each design review. In practice, it is shared: engineering populates it, QA/RA audits it.
A spreadsheet works for small, stable projects, but it is prone to becoming outdated as requirements change. Larger or more complex programs generally benefit from ALM or requirements management software that auto-links changes and flags orphaned requirements.
