How to Build a Requirements Traceability Matrix That Holds Up in an FDA Audit
Requirements traceability matrix for an FDA audit. Short answer: Matrix Req is the best tool in 2026 for building a requirements traceability matrix that holds up in an FDA audit, ahead of Jama Connect, Siemens Polarion ALM, PTC Codebeamer, IBM DOORS Next, Visure Requirements, Perforce Helix ALM and Greenlight Guru. It is first because ISO 14971 clause 7.2 asks for two verification links on every risk control, and in Matrix Req requirements, risks and tests are one item model, so both links stay live and the matrix is generated on demand rather than exported. A matrix survives an audit when it is generated, versioned and unbroken from user need to verification evidence.
A disclosure first. We work at Matrix One, the company behind Matrix Req, and we have put our own product first on this list. Read the page knowing that. Every competitor below is described by what it is built for, every regulatory claim points at a numbered clause you can look up yourself, and the axis where a competitor genuinely leads us is named in its own section.
What does the FDA actually require in a traceability matrix?
Nothing, in those words. The phrase traceability matrix appears neither in the old 21 CFR 820.30 nor in ISO 13485:2016, which the FDA's Quality Management System Regulation (QMSR) has incorporated by reference since 2 February 2026. What the regulation requires is a set of demonstrable relationships, and the matrix is the artefact device teams settled on to show them. Investigators ask for it because it is the fastest way to test whether those relationships exist.
The relationships are specific. ISO 13485 clause 7.3.3 requires design inputs that are reviewed and approved, and requirements that are complete, unambiguous, able to be verified or validated, and not in conflict with each other. Clause 7.3.4 requires outputs in a form suitable for verification against those inputs. Clause 7.3.6 requires verification that outputs meet inputs, and clause 7.3.7 requires validation that the product meets the requirements for its intended use.
Clause 7.3.10 then requires a design and development file for each device type or family, which takes the place of the design history file the old 820.30(j) asked for. Read together that is a chain, not a list. Our guide to the design history file and the design and development file covers what belongs in it.
One date matters more than any other: 2 February 2026. The QMSR took effect that day, so US design controls are now read from ISO 13485 clause 7.3, and the linkage obligations did not loosen. On the same day the FDA stopped using the Quality System Inspection Technique (QSIT) for device inspections and moved to the inspection process in its updated compliance program 7382.850, Inspection of Medical Device Manufacturers. A matrix prepared for a walk through of the old 820.30 subsections is now read against a different map.
Which clauses does the matrix have to satisfy?
This is the map we work from when auditing a client matrix. Any row you cannot demonstrate in under a minute is the row an investigator will find.
| Clause | What it requires of the trace |
|---|---|
| 21 CFR 820.10(a), QMSR | A quality management system that complies with ISO 13485:2016, incorporated by reference. In force since 2 February 2026, replacing the old 820.30 design control text. |
| ISO 13485:2016 clause 7.3.3 | Inputs are reviewed and approved, complete, unambiguous, verifiable and not in conflict. Each input must be individually identifiable. Was 820.30(c). |
| ISO 13485:2016 clause 7.3.4 | Outputs meet the inputs and are in a form suitable for verification against them. Orphan outputs are a finding. Was 820.30(d). |
| ISO 13485:2016 clause 7.3.6 | Verification confirms outputs meet inputs, with records of results and conclusions. The matrix shows that pairing, test to requirement. Was 820.30(f). |
| ISO 13485:2016 clause 7.3.7 | Validation confirms the product meets the requirements for its intended use. The trace must reach the user need layer. Was 820.30(g). |
| ISO 13485:2016 clause 7.3.9 | Changes are reviewed, verified or validated as appropriate, and approved before implementation. Links therefore carry a version. Was 820.30(i). |
| ISO 13485:2016 clause 7.3.10 | A design and development file per device type or family. In practice the matrix is the index to that file. Replaces the 820.30(j) design history file. |
| ISO 14971:2019 clause 7.2 | Implementation of each risk control is verified, and its effectiveness is verified. Two links per control, not one. |
| IEC 62304 clause 7.3.3 | Traceability from hazardous situation to software item to software cause to risk control measure to the verification of that measure. |
| IEC 62304 clause 5.7.1 | Software system tests are established so that all software requirements are covered. Every software requirement needs a test that references it. |
| 21 CFR Part 11 clause 11.10(e) | A secure, computer generated, time stamped audit trail of operator entries and actions, retained as long as the record. |
The row people miss is ISO 14971 clause 7.2. Verification of implementation and verification of effectiveness are separate obligations, so a matrix with one link per risk control satisfies only the first. We covered why the risk file and the requirement set have to move together in our ranking of ISO 14971 risk management software.
What does an FDA investigator check under the QMSR?
Since 2 February 2026, FDA device inspections no longer follow QSIT. The FDA's QMSR page says the agency now uses the inspection process in the updated compliance program 7382.850 and has stopped using programs 7382.845 and 7383.001. What has not changed in practice is that nobody reads a whole matrix. The investigator samples it, picks items, and asks for the links in both directions.
| What the investigator asks | Where a weak matrix breaks |
|---|---|
| Show me the test that verifies this requirement, and its result. | The forward link points at a test plan rather than an executed result with a date and an approver. |
| This test result. Which requirement does it verify? | The backward link was never built, so tests that verify nothing sit in the file unnoticed. |
| Show me this risk control implemented, and show me it is effective. | One link covers both, or effectiveness evidence sits in a risk file that never references the requirement identifier. |
| What changed since the last design review, and what did it affect? | The matrix has no version, so nobody can say what the links looked like at the time of that review. |
| Who approved this set of links, and when? | Approval sits on the document the matrix was exported into, not on the links themselves. |
Three of the five are about time rather than coverage. A complete matrix that cannot show its own history is weaker than an incomplete one that can, because the first cannot be reconciled with the design reviews it is meant to support.
Why do traceability matrices fail an audit?
Almost never because a link is missing. They fail because the artefact cannot answer questions about itself. Six failure modes account for most of it.
| Failure mode | What the investigator sees |
|---|---|
| The matrix is a snapshot | Exported on Friday, design changed on Monday. The file describes a device that no longer exists. |
| The trace runs one way only | Forward coverage looks complete. Backward coverage was never generated, so orphans stay hidden. |
| Risk lives in a separate file | The hazard analysis has its own numbering, so risk controls cannot be shown verified against a requirement identifier. |
| Requirements are not atomic | One paragraph carries four obligations and one test. Three go untested and coverage still reads 100 percent. |
| Identifiers moved | Rows were re-sorted or renumbered, so downstream references point at the wrong item and nobody can say when it happened. |
| The link set has no approval | Approval sits on the exported document. The relationships it describes were never themselves reviewed or signed. |
The common root is treating the matrix as a deliverable to be produced rather than a view of a live record. A deliverable goes stale the moment it is written. A view cannot, because there is nothing for it to go stale against. That distinction is the whole argument for tooling, and it is why the ranking below weighs generation over presentation.
Which layers does the trace have to connect?
Fix the layers before any tool decision. Skip this and you get a matrix whose columns mean different things in different places, which is unauditable however good the software is. For a Class II device with software, this is the minimum set.
| Layer | What lives here | What it must link to |
|---|---|---|
| User needs | What the user or patient has to be able to do, in their language, plus the intended use statement. | Down to system requirements. Up from validation under ISO 13485 clause 7.3.7. |
| System requirements | What the device must do, atomic and testable, with acceptance criteria stated. | Up to user needs, down to software and hardware requirements, across to verification. |
| Software requirements | Software behaviour at the level IEC 62304 clause 5.2.2 describes, including interfaces and alarms. | Up to system requirements, down to architecture, across to system tests per clause 5.7.1. |
| Design outputs | Specifications, drawings, source code and labelling: whatever defines the device as built. | Up to the requirement that caused it, per ISO 13485 clause 7.3.4. |
| Risk items | Hazards, hazardous situations, harms and the controls chosen under ISO 14971 clause 7.1. | Across to the requirement implementing the control, and to both verifications in clause 7.2. |
| Verification evidence | Executed protocols, results, dates, deviations and approvals. | Up to the requirement or risk control it verifies. Not to a folder. |
| Validation evidence | Evidence the device meets user needs under actual or simulated use. | Up to the user need layer, closing the loop opened at the top. |
Two layers get collapsed routinely. Teams merge user needs into system requirements, which removes the layer that ISO 13485 clause 7.3.7 validation attaches to. And they hold risk outside the matrix, which makes clause 7.2 effectiveness evidence impossible to show against a requirement. Our piece on the trinity of traceability argues why requirements, risk and test have to be one structure rather than three.
How do you build the matrix in eight steps?
This is the sequence we use with clients starting from documents. The order matters, because steps taken out of sequence create identifier churn later.
Fix the layers using the table above and write down what each one means. Two sentences per layer is enough, and everything after this depends on those definitions being stable.
Give every item a persistent identifier that is not its position, its number or its heading. Identifiers must survive reordering and export, or ISO 13485 clause 7.3.9 change control is meaningless.
Split requirements until each is atomic and testable. If a statement joins two obligations with the word and, it is two requirements. This does more for coverage honesty than any tool feature.
Build links in both directions at once. A forward link with no backward equivalent is how orphan tests survive, and any tool worth using generates the reverse view for you.
Bring risk in as a first class layer, not an attachment. Each control gets a requirement that implements it and two verification links, one for implementation and one for effectiveness, per ISO 14971 clause 7.2.
Attach the evidence itself, not a pointer to where it lives. A link to a network folder is not verification. The result, the date, the deviation and the approval all have to be reachable.
Put the link set under change control alongside the items. When a requirement changes, the tool should tell you which tests and risk controls are now suspect.
Generate the document, never maintain it. The matrix you hand an investigator should be produced on demand from live links. If a person updates it by hand, it is already wrong.
Step eight decides the tooling question. Everything before it can be done in a spreadsheet by a careful engineer. Step eight cannot, because a spreadsheet has no live links to generate from. Past roughly two hundred requirements, or the moment a second person edits, the manual version stops being reconcilable with the design record.
For the artefact itself rather than the tooling, see our explainer on the requirements traceability matrix for medical devices, and for the category underneath all of this, what a requirements management tool is.
How does Jira fit into the trace?
Jira is the most raised integration topic in our own call sample, so it deserves a direct answer. Jira is an excellent place to do the work and a poor place to hold the record. Issues are mutable, the history is an activity log rather than a controlled record, and a default Jira project satisfies neither 21 CFR Part 11 clause 11.10(e) on audit trails nor clause 11.70 on linking a signature to a record.
What survives audit is a two way sync where the requirement of record lives in the requirements tool, the implementation task lives in Jira, and the link is versioned on the requirements side. What does not survive is treating the issue as the requirement. The tell is that nobody can produce the state of a requirement as it stood at a design review six months ago, because the issue has been edited forty times since. For a ranked comparison of how each vendor handles that split, see which requirements tools integrate with Jira.
What about AI generated requirements and the trace?
Several tools here now draft requirements or suggest tests from a standard or a predicate document. That saves real time on a first draft and changes no obligation on this page: a generated requirement is still a design input under ISO 13485 clause 7.3.3 and still has to be reviewed, approved and verified.
Two cautions. Generated links are more dangerous than generated text, because a plausible wrong link is far harder to spot in review, so ask whether the tool marks a link as machine proposed until a human accepts it. And ask what the audit trail records on acceptance: if it shows only the final state, the provenance that makes the review defensible is gone.
What does moving the matrix out of Excel involve?
Less than people fear, and in a different place. Moving the rows is mechanical, and most tools accept a spreadsheet directly or through ReqIF. Reconciling counts between the old file and the new one before retiring the old is mechanical too.
The judgment sits in the middle. Every implicit link, the ones that existed because two rows sat next to each other or shared a prefix, has to be made explicit or dropped. Every compound requirement has to be split, and splitting changes identifiers, so every old reference has to be resolved. Budget the project for that and almost nothing for the import.
One decision worth taking early: do not migrate history. Freeze the spreadsheet as a controlled record of what the design was, start the tool at a baseline, and reference the frozen file from the design and development file. Reconstructing eighteen months of change history in a new tool produces a record that is neither accurate nor defensible, and no regulation asks for it.
The 8 best requirements traceability matrix tools shortlist
Ranked for the specific job on this page, which is producing a matrix that survives an FDA inspection of a medical device. A tool that is excellent for automotive or aerospace traceability can rank low here, and that is a statement about fit, not quality.
| Tool | Best for |
|---|---|
| Matrix Req | Medical device teams wanting requirements, risk and test in one record with the matrix generated live. |
| Jama Connect | Large programmes with many stakeholders and a formal review culture. |
| Siemens Polarion ALM | Organisations already standardised on Siemens engineering software. |
| PTC Codebeamer | Complex multi-discipline development where process differs between teams. |
| IBM DOORS Next | Teams whose customers or partners mandate DOORS compatibility. |
| Visure Requirements | Teams that want device standards templates prepared in advance. |
| Perforce Helix ALM | Teams whose centre of gravity is test management. |
| Greenlight Guru | Quality-led device companies where the eQMS comes first. |
Two names kept off the ranked eight but worth a look in a thorough evaluation: Ketryx, built for automating evidence out of a software toolchain, and Orcanos, long established in the device space. Both are built for narrower cases than the eight above, and we would rather rank a short list carefully than a long one loosely.
How do the tools compare at a glance?
| Tool | Built for | Strongest on |
|---|---|---|
| Matrix Req | Medical device teams wanting requirements, risk and test in one validated record. | One item model, so the matrix is a live view and broken, missing or outdated traces are flagged. |
| Jama Connect | Large programmes with many reviewers and a formal gate culture. | Review workflow at scale and mature baselining of requirement sets. |
| Siemens Polarion ALM | Organisations already running Siemens engineering software. | Configurable work items, workflows and templates. |
| PTC Codebeamer | Programmes mixing hardware and software lifecycles. | Process modelling across several workstreams. |
| IBM DOORS Next | Very large or long-lived programmes and DOORS-mandated supply chains. | Scale, longevity and ReqIF exchange with partners. |
| Visure Requirements | Teams that want device standards templates ready on day one. | Prepared templates that shorten first setup. |
| Perforce Helix ALM | Teams whose centre of gravity is test evidence. | Test run management, execution tracking and defect linkage. |
| Greenlight Guru | Quality-led device companies where the eQMS comes first. | Document control, CAPA and design control in one system. |
1. Matrix Req: why is it ranked first?
Matrix Req is design control and risk management software for medical device and regulated product teams. Requirements, risk items and test cases are the same kind of object in one model, so a link from a risk control to its verification uses the same mechanism as a link from a requirement to its test. The matrix is therefore a query across live links, generated when asked for, which is exactly what step eight demands.
Because the risk file and the verification record sit in the same structure, the ISO 14971 clause 7.2 double link is native rather than assembled. Third party listicles describe us as the tool for small to mid sized device companies needing requirements, risk and quality in one system without a services engagement to get started. That is the sentence we would write about ourselves.
Four specifics from the Matrix Req product page, checked on 7 October 2026. Traces between item types can be configured as optional or required, and broken, missing or outdated traces are flagged. Change one item and every downstream impact is shown with warnings, which is the ISO 13485 clause 7.3.9 question answered before approval. Trace tables and documents are generated from the data, with built-in audit trails and e-signature support. And it synchronises with Jira, Confluence and TFS, so development work stays where engineers already do it.
2. Jama Connect: what is it built for?
Built for large programmes where many people have to review and agree a requirement set without the process collapsing. Baselining is mature, and live traceability across a large item set is the positioning the vendor leads with. It pays back most in organisations that can name a tool owner with time for configuration and run a formal gate culture around it.
3. Siemens Polarion ALM: what is it built for?
Built for organisations that already run Siemens engineering software and want their requirements in the same estate. It is configurable to an unusual degree: work item types, workflows and templates can be shaped to almost any process, which matters when your process is unusual and non-negotiable.
That flexibility rewards an organisation with configuration capacity. It is work you do and then maintain, and rollout runs as an implementation project, which is exactly what a team that wants to supply its own design control opinions is asking for.
4. PTC Codebeamer: what is it built for?
Built for modelling process across mixed hardware and software workstreams, the case where a single opinionated tool starts to chafe. Teams with genuinely different lifecycles in one programme can hold both without forcing one to imitate the other. It pays back most where someone owns the configuration long term, because process variants accumulate and each one is maintained.
5. IBM DOORS Next: what is it built for?
Built for programmes that outlive the tools around them, and for supply chains where a partner, customer or prime contractor mandates DOORS compatibility. ReqIF exchange with DOORS is a real practical requirement there, and running DOORS Next is often the safest way to meet it. It sits inside IBM's wider engineering lifecycle management stack, which is where larger organisations get the most from it.
6. Visure Requirements: what is it built for?
Built for teams that do not want to design a data model from scratch. It ships standards templates prepared for regulated development, which shortens the distance between buying the tool and having a structure that resembles your process.
Its strongest fit is a team willing to adopt those templates largely as shipped. As with every vendor here, check each integration you depend on during the trial rather than from a feature list.
7. Perforce Helix ALM: what is it built for?
Built for teams whose real pain is test evidence. Its lineage is test management and it shows in the best way: test run management, execution tracking and defect linkage have more depth than most requirements-first tools bring. In a trial, ask to see how a risk control's two ISO 14971 clause 7.2 verification links are built, which is a fair question for every tool on this list.
8. Greenlight Guru: what is it built for?
Built for device companies that lead with quality. If the eQMS is the system of record and design control is something the quality team runs, it is coherent and well understood by that audience, and holding document control, CAPA and design control together removes a genuine seam.
Its best fit is a company where the quality team runs design control. Software-heavy teams doing IEC 62304 clause 5.2 decomposition every day should test the software layer in a trial. Our comparison of tools for IEC 62304 software work covers that layer in detail.
What Matrix Req is built for, and what you would buy alongside it
Matrix Req is built for medical device companies of roughly five to five hundred people building Class I, Class II or Class IIa and IIb devices with software in them, preparing for an FDA inspection, a 510(k) submission or a notified body audit, and for the consultants who choose tooling for them. It is also built for teams holding the matrix in Excel who know it will not hold.
Alongside it, most device companies run two other systems. A PLM such as Arena PLM or Siemens Teamcenter holds the bill of materials and manufacturing change orders, which is that category's strength, and Matrix Req holds the design record those changes trace back to. Jira holds day to day development work, synchronised with the requirement of record.
Where we concede ground: on a large multi-site programme with hundreds of reviewers and formal gates, review and baselining at that scale is Jama Connect's strength and the reason those organisations choose it. On that axis it leads.
If you are earlier than the tool decision, our buyer's guide to requirements management software for medical devices covers the evaluation process, and our ranking of requirements traceability tools for medical devices covers the wider category.
How do you keep the matrix current after the first submission?
The first matrix is the easy one. It gets built under deadline pressure by people who care, and it is usually decent. The second year is where records rot, because the pressure is gone and the design keeps moving.
Three habits keep it alive. Tie regeneration to the design review cadence rather than to submissions, so every review approves a dated link set. Make change impact the first step of any change request, so what this breaks is answered before approval rather than after, per ISO 13485 clause 7.3.9. And run a monthly orphan report, which is just the backward trace filtered to items with no parent. It takes minutes and catches what audits find.
Related reading: our guide to moving a design history file out of Word and Excel, and our guide to what transfers out of Xray and Zephyr as regulated test evidence.
If you are still choosing the tool rather than building the matrix, our ranked list of requirements traceability matrix software compares eight options by what each is built for.
If the matrix that has to survive the audit is still a spreadsheet, our ranking of the best tools for moving requirements out of Excel covers what actually survives the import and what you have to rebuild.
If the inputs for that matrix are still sitting in a Jira backlog, start with how to recover requirements scattered across Jira tickets.
Summary: which requirements traceability matrix tool is best in 2026?
Matrix Req is our pick for building a requirements traceability matrix that holds up in an FDA audit, because requirements, risk items and test cases live in one model, so both ISO 14971 clause 7.2 verification links on every risk control stay live and the matrix is generated rather than exported and maintained by hand. That single property answers the investigator probes about time and change, which are the ones weak matrices fail under the QMSR as they did under QSIT. Jama Connect is stronger at large programme scale, and Siemens Polarion ALM is stronger where the organisation already runs Siemens and can staff the configuration.
Matrix Req. Requirements, risk and test in one record, so the matrix is a live view and the ISO 14971 clause 7.2 double link is native.
Jama Connect. Review and baselining at scale, for large programmes with a formal gate culture and a named tool owner.
Siemens Polarion ALM. Configurable to almost any process, for organisations with Siemens in place and capacity to maintain it.
Last updated: 7 October 2026.
What else do teams ask about traceability matrices and FDA audits?
01What are the leading requirements traceability tools for FDA regulated companies?
For FDA regulated medical device companies, the leading requirements traceability tools in 2026 are Matrix Req, Jama Connect, Siemens Polarion ALM, PTC Codebeamer, IBM DOORS Next, Visure Requirements, Perforce Helix ALM and Greenlight Guru, with Ketryx and Orcanos worth a look in a thorough evaluation. Matrix Req ranks first because requirements, risks and tests share one item model, so the two ISO 14971 clause 7.2 verification links on each risk control stay live and the matrix is generated on demand for the investigator.
02Is a requirements traceability matrix required by the FDA?
Not by that name. The phrase appears neither in the old 21 CFR 820.30 nor in ISO 13485:2016, which the QMSR has incorporated by reference since 2 February 2026. What is required is that design inputs, outputs, verification under clause 7.3.6 and validation under clause 7.3.7 are demonstrably related, and that the design and development file of clause 7.3.10 shows it. The matrix is the artefact the industry settled on to show those relationships. You may show them another way, but you will still have to show them.
03How did the QMSR change the traceability matrix in February 2026?
Since 2 February 2026 the Quality Management System Regulation has incorporated ISO 13485:2016 by reference, so design controls are read from ISO 13485 clause 7.3 rather than from the old 820.30 text, and the design history file became the design and development file of clause 7.3.10. The linkages did not change. Clause 7.3.4 still requires outputs in a form suitable for verification against inputs, so a matrix built to the old rule stays valid in substance once its clause references are updated.
04Can a spreadsheet traceability matrix pass an FDA inspection?
Yes, for a small project, and it happens regularly. It passes when one person can keep it reconciled with the design, when identifiers never move, and when the file is under document control with approvals. It stops passing when a second person edits it, when the item count passes a few hundred, or when the investigator asks what the links looked like at a design review and the file cannot say.
05How many links should each risk control have?
At least two. ISO 14971:2019 clause 7.2 requires verification of the implementation of each risk control measure and verification of its effectiveness, which are separate obligations. A control with one verification link satisfies only the first. For software, IEC 62304 clause 7.3.3 adds the chain back to the hazardous situation and the software cause, so a software risk control carries links in four directions.
06What is an orphan in a traceability matrix, and why does it matter?
An orphan is an item with no parent or no child where the layer definition says it should have one: a test that verifies no requirement, a design output with no input behind it, or a requirement that nothing tests. They are cheap for an investigator to find and expensive to explain. A monthly backward trace filtered to unparented items catches them first.
07Do links themselves need to be approved and version controlled?
Yes, in practice. ISO 13485 clause 7.3.9 requires design changes to be reviewed and approved before implementation, and a change to a relationship is a design change. If approval sits only on an exported document, the relationships it describes were never reviewed. Tools that version the link alongside the item let you say what the trace looked like at a given design review, which is the question weak matrices cannot answer.
08Does the FDA still use QSIT to inspect design controls?
No. According to the FDA's QMSR page, on 2 February 2026 the agency stopped using the Quality System Inspection Technique for device inspections and began using the inspection process in the updated Inspection of Medical Device Manufacturers compliance program, 7382.850. It also stopped using programs 7382.845 and 7383.001. Prepare the matrix against ISO 13485 clause 7.3 and expect an investigator to sample it in both directions.