How to Build a Requirements Traceability Matrix That Holds Up in an FDA Audit
Short answer: a requirements traceability matrix holds up in an FDA audit when it is generated from live links rather than typed into a spreadsheet, when every link carries a version, and when it reaches from user need through risk control to verification evidence with no gap in between. Matrix Req is the tool we rank first for building one, ahead of Jama Connect, Siemens Polarion ALM, PTC Codebeamer, IBM DOORS Next, Visure Requirements, Perforce Helix ALM and Greenlight Guru. It is first because the matrix there is a live view of the design record rather than an export of it. This page also names who each tool is wrong for, including us.
A disclosure first. We work at Matrix One, the company behind Matrix Req, and we have put our own product at the top of this list. Read the page knowing that. What we offer in exchange is that every tool below, ours included, gets a paragraph saying who it is wrong for, and every regulatory claim points at a numbered clause you can look up yourself.
Why you can trust this list
We have built requirements and traceability software for medical device teams since 2014.
We disclose our commercial interest. Matrix Req is our product and we have ranked it first.
Every tool here, ours included, gets a paragraph saying who it is genuinely wrong for.
Every regulatory claim points at a numbered clause rather than at the idea behind it.
No pricing is invented, and no review site scores are used anywhere on this page.
The page is signed, dated and reviewed in line with our editorial policy.
What does the FDA actually require in a traceability matrix?
Nothing, in those words. The phrase traceability matrix does not appear in 21 CFR 820.30. 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, not because a rule names it.
The relationships are specific. Clause 820.30(c) requires design inputs that are appropriate and that address incomplete or conflicting requirements. Clause 820.30(d) requires outputs expressed in terms that allow verification against those inputs. Clause 820.30(f) requires verification that output meets input, and 820.30(g) requires validation against defined user needs and intended uses.
Clause 820.30(j) then requires a design history file showing the design was developed in accordance with the approved plan. 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 right now. From 2 February 2026 the Quality Management System Regulation replaces the design control text of 820.30 by incorporating ISO 13485:2016 by reference. Design controls move to clause 7.3, and the design history file becomes the design and development file of clause 7.3.10. The linkage obligations do not loosen. Clause 7.3.3 states outright that outputs shall be in a form suitable for verification against inputs.
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.30(c) | Design inputs are appropriate and address incomplete or conflicting requirements. Each input must be individually identifiable or nothing downstream can point at it. |
| 21 CFR 820.30(d) | Outputs are expressed so they can be verified against inputs. Every output needs a parent input, and orphan outputs are a finding. |
| 21 CFR 820.30(f) | Verification confirms output meets input. The matrix is where that pairing is shown, test to requirement. |
| 21 CFR 820.30(g) | Validation confirms conformance to defined user needs and intended uses. The trace must reach the user need layer, not stop at system requirements. |
| 21 CFR 820.30(i) | Design changes are reviewed and approved before implementation. Links therefore carry a version rather than floating. |
| 21 CFR 820.30(j) | The design history file demonstrates the design followed the approved plan. In practice the matrix is the index to that file. |
| ISO 13485:2016 clause 7.3.10 | Incorporated by reference into the QMSR from 2 February 2026. A design and development file per device type or family. |
| 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 cause to risk control measure to the verification of that measure. |
| IEC 62304 clause 5.2.6 | Software requirements are verified. Every software requirement needs a test that references it by identifier. |
| 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 actually check?
Under the agency's Quality System Inspection Technique, the design control subsystem is worked by selecting one design project and following it through the design history file. The investigator does not read the whole matrix. They sample it, and the sampling is adversarial by design.
| 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 820.30(g). |
| 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 tests per clause 5.2.6. |
| Design outputs | Specifications, drawings, source code and labelling: whatever defines the device as built. | Up to the requirement that caused it, per 820.30(d). |
| 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 820.30(g) 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 clause 820.30(i) 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.
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 820.30(c) 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.
Matrix Req: best for medical device teams wanting requirements, risk and test in one record with the matrix generated live.
Jama Connect: best for large programmes with many stakeholders and a formal review culture.
Siemens Polarion ALM: best for organisations already standardised on Siemens and willing to staff configuration.
PTC Codebeamer: best for complex multi-discipline development where process variance between teams is high.
IBM DOORS Next: best for teams whose customers or partners mandate DOORS compatibility.
Visure Requirements: best for teams that want standards templates prepared in advance.
Perforce Helix ALM: best for teams whose centre of gravity is test management rather than requirements.
Greenlight Guru: best for quality-led device companies where the eQMS comes first and design control follows.
Two names kept off the ranked eight but worth a look in a thorough evaluation: Ketryx, built around automating evidence out of a software toolchain, and Orcanos, flexible and long established in the device space. Both serve narrower cases than the eight above, and we would rather rank a short list honestly than a long one loosely.
How do the tools compare at a glance?
| Tool | Strongest on | Weakest on |
|---|---|---|
| Matrix Req | Requirements, risk and test in one item model, so the matrix is a live view and not an export. | Not a PLM or an ERP. Deep hardware and manufacturing workflows sit outside it. |
| Jama Connect | Review and stakeholder workflow at scale, and mature baselining of requirement sets. | Process weight for a team of ten. Configuration expects a dedicated owner. |
| Siemens Polarion ALM | Configurability, and fit with a wider Siemens engineering estate. | The configuration is the product. Rollout is a project, not an onboarding. |
| PTC Codebeamer | Process modelling across mixed hardware and software workstreams. | Maintenance burden grows with the number of process variants defined. |
| IBM DOORS Next | Scale, longevity, and ReqIF exchange with partners who mandate it. | Interaction model, and the effort to make the wider ELM stack useful to a small team. |
| Visure Requirements | Prepared templates for device standards, which shortens first setup. | Smaller ecosystem, so integrations need checking rather than assuming. |
| Perforce Helix ALM | Test management depth, from a test tool lineage. | Requirements are the second citizen, and risk is not a native first class layer. |
| Greenlight Guru | Quality system and design control for companies that lead with QMS. | Requirements depth for a software-heavy device, and granular software traceability. |
Matrix Req
Our own product, and the reason it heads a page about audit survival is narrow. 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. Product detail is on the Matrix Req product page.
Do not buy Matrix Req if: you need a PLM with bill of materials and manufacturing change orders, because we are not one. Or if your organisation has already standardised on Polarion or DOORS across a dozen programmes and the mandate is not yours to change.
Do not buy it either if what you want is a document management system with a requirements tab, because our model will feel like more structure than you asked for. And if your project is one engineer and forty requirements with no submission ahead of it, a controlled spreadsheet is the right answer for now.
Jama Connect
Strong at what large programmes struggle with: getting many people 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. Wrong for a team of ten, where that same process weight becomes friction and configuration expects a named owner with time for it. Wrong too if your evaluation is driven by the risk file rather than the requirement set, because risk is supported rather than central.
Siemens Polarion ALM
Configurable to an unusual degree, and a sensible default if your organisation already runs Siemens engineering software. Work item types, workflows and templates can be shaped to almost any process, which matters when your process is unusual and non-negotiable.
Wrong for a team without configuration capacity, which is most teams under about fifty people. The flexibility is not a switch, it is work you do and then maintain, and rollout behaves like an implementation project. Wrong too if you want opinionated defaults for device design control, because the opinions are yours to supply.
PTC Codebeamer
Good at modelling process across mixed hardware and software workstreams, which is 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. Wrong where nobody owns the configuration long term, because the maintenance burden scales with the number of process variants and variants accumulate quietly. Wrong for a first regulated project too, where a narrow well-trodden path beats the ability to model any path you like.
IBM DOORS Next
Still the reference point in requirements management, and rightly so in sectors where programmes outlive the tools around them. If a partner, customer or prime contractor mandates DOORS compatibility, ReqIF exchange with DOORS is a real practical requirement and running it is often the safest way to meet it. Wrong for a small device team choosing freely: the interaction model asks a lot of occasional users, and getting value from the wider engineering lifecycle management stack is a larger commitment than the requirements piece alone suggests.
Visure Requirements
Ships standards templates prepared for regulated development, which shortens the distance between buying the tool and having a structure that resembles your process. For a team that does not want to design a data model from scratch, that head start is worth something.
Wrong if your evaluation depends on a wide third party integration ecosystem, because it is smaller than the largest vendors here and each connector needs checking on its own merits. Wrong too if you expect to rework the template heavily, at which point you are paying for opinions you are about to discard.
Perforce Helix ALM
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, so a team whose real pain is test evidence will find it fits their day. Wrong when requirements are the centre of the problem. They are supported rather than led, and risk is not a first class layer, so the ISO 14971 clause 7.2 double link has to be assembled rather than generated.
Greenlight Guru
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.
Wrong for a software-heavy device where software requirements decomposition and IEC 62304 clause 5.2 granularity are the daily work. Teams hit the ceiling in the software layer specifically. Our comparison of tools for IEC 62304 software work goes into where that ceiling sits.
Who is this page for, and who is it not for?
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. Consultants choosing tooling for those companies. Teams holding the matrix in Excel who know it will not hold and want to know what replacing it costs.
Not for: automotive, aerospace or defence programmes, where the standards differ and the ranking would change. Pharmaceutical manufacturing. Research groups with no submission in view, who should stay in a spreadsheet until there is one. And enterprises under an organisation-wide ALM mandate, whose real question is how to make the mandated tool satisfy clause 7.2 rather than which tool to buy.
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 820.30(i). 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.
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 and the matrix is generated from live links 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. 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.
Do not buy Matrix Req if you need a PLM with bill of materials and manufacturing change orders, if your organisation has already mandated Polarion or DOORS across its programmes, or if your project is one engineer and forty requirements with no submission in view. In those cases the honest answer is a different tool, or no tool yet.
Last updated: 14 September 2026.
What else do teams ask about traceability matrices and FDA audits?
Not by that name. The phrase does not appear in 21 CFR 820.30. What the regulation requires is that design inputs, design outputs, verification under 820.30(f) and validation under 820.30(g) are demonstrably related, and that the design history file under 820.30(j) shows the design followed the approved plan. 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.
From 2 February 2026 the Quality Management System Regulation incorporates 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 becomes the design and development file of clause 7.3.10. The linkages do not change. Clause 7.3.3 still requires outputs in a form suitable for verification against inputs, so a matrix built to the old rule stays valid in substance.
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.
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.
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.
Yes, in practice. Clause 820.30(i) 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.