The Best Software for EU MDR Technical Documentation and Traceability
The best software for EU MDR technical documentation and traceability is the tool that keeps every Annex II section linked to the controlled evidence behind it, so the file regenerates when the design changes. Short answer: for 2026 the ranking is Matrix Req first, then Ketryx, Greenlight Guru, Jama Connect, PTC Codebeamer, Orcanos, Siemens Polarion ALM and IBM DOORS Next. Matrix Req is first because it generates the technical file from live, traced project data: CE mark technical file templates, document versions linked to technical file versions, Part 11 signatures, a ZIP export of the whole file as PDFs, and a Compliance Checker that turns the MDR into a checklist assessed against your own evidence.
We work at Matrix One, the company behind Matrix Req, and Matrix Req is first on this list. We say so up front so you can weigh the ranking accordingly. Every regulatory statement below is tied to a numbered article or annex section of Regulation (EU) 2017/745, or of the amending Regulation (EU) 2023/607, read on EUR-Lex on 13 October 2026. Every competitor fact was read on that vendor's own website in October 2026, and we quote no pricing a vendor does not publish itself.
Matrix Req is a requirements management and design controls tool for medical device and regulated product teams. Matrix One has built it since 2014, says more than 500 life sciences and medical device companies use its products, and publishes a dedicated page on technical documentation generation in Matrix Req. External reviewers describe it as built for small and mid-sized medical device teams that want a configurable, validated requirements and traceability tool, rather than for enterprises running one ALM platform across many industries.
8 best software for EU MDR technical documentation shortlist
| Tool | Best for |
|---|---|
| Matrix Req | Device teams that want the Annex II file generated from traced requirements, risks and tests, with CE mark templates and signed versions |
| Ketryx | Software-heavy device teams whose engineers already work in Jira, GitHub and TestRail |
| Greenlight Guru | Device companies that want design controls, technical documentation and an eQMS from one medtech vendor |
| Jama Connect | Larger organisations running many device programmes with live traceability across distributed teams |
| PTC Codebeamer | Groups whose platform spans medical devices and other regulated industries such as automotive |
| Orcanos | Smaller manufacturers that want ALM and QMS sharing one data model |
| Siemens Polarion ALM | Enterprises standardised on Siemens engineering software that want preconfigured medical device templates |
| IBM DOORS Next | Organisations with a long-running DOORS estate inside IBM Engineering Lifecycle Management |
How do the 8 tools compare at a glance?
| Tool | Built for | Strongest on |
|---|---|---|
| Matrix Req | MDR technical file generated from linked items | CE mark technical file templates, versioned documents tied to file versions, Compliance Checker against the MDR |
| Ketryx | Developer-native evidence | GSPR traceability matrix and technical file assembled from Jira, Git and test tools |
| Greenlight Guru | Design and quality in one product | Design controls beside its own medtech QMS |
| Jama Connect | Many programmes, many teams | Live traceability and review across large distributed organisations |
| PTC Codebeamer | Cross-industry regulated platforms | Standards templates spanning medical, automotive and more |
| Orcanos | ALM plus QMS for small teams | One data model across design control and quality |
| Siemens Polarion ALM | Siemens engineering estates | Preconfigured medical device templates and ReqIF exchange |
| IBM DOORS Next | Very large requirement sets | Scale and round-trip import and export inside IBM ELM |
The rest of this page starts with the regulation, because the annexes decide what the software has to hold, and then ranks the tools.
What does MDR Article 10(4) actually require of technical documentation?
Article 10(4) of Regulation (EU) 2017/745 requires manufacturers of devices other than custom-made devices to "draw up and keep up to date" technical documentation that allows the conformity of the device to be assessed, and it must include the elements set out in Annexes II and III. Custom-made devices follow Section 2 of Annex XIII instead, under Article 10(5).
Annex II also sets a format rule that most buyers skip past. Its opening sentence says the documentation shall be presented "in a clear, organised, readily searchable and unambiguous manner". Annex III repeats the same words for post-market surveillance documentation.
Which Annex II sections depend on traceability?
Annex II has six numbered sections. Four of them are, in practice, views over linked data, which is where a traceability tool earns its place.
| Annex II section | What it requires | What the software has to hold |
|---|---|---|
| 1. Device description and specification | Intended purpose, Basic UDI-DI, risk class and rule, variants, accessories, technical specifications | Variants and configurations as items, so each one traces to its own requirements |
| 2. Information supplied by the manufacturer | Labels and instructions for use in the languages of each Member State | Labelling requirements linked to the risks and warnings they carry |
| 3. Design and manufacturing information | Information to understand the design stages, manufacturing processes and their validation, all sites | Design stage records, reviews and approvals in sequence |
| 4. General safety and performance requirements | Applicable GSPRs and why others do not apply, methods, standards, and the precise identity of controlled evidence documents | A GSPR checklist where each row links to versioned evidence, not to a typed reference |
| 5. Benefit-risk analysis and risk management | Benefit-risk analysis under Annex I Sections 1 and 8, risk management results under Section 3 | Hazards, risk controls and their verification as linked records |
| 6. Product verification and validation | Results and critical analyses of all V&V, pre-clinical and clinical data, software V&V, CER and PMCF plan | Tests and results linked back to the requirement and the GSPR they demonstrate |
Why is Annex II Section 4(d) the hardest line to keep true?
Section 4 asks for the GSPRs that apply, an explanation of why the others do not, the methods used to demonstrate conformity, and the harmonised standards, common specifications or other solutions applied. Point (d) then asks for "the precise identity of the controlled documents offering evidence of conformity" with each standard or method, and a cross-reference to where that evidence sits in the full technical documentation.
That is a traceability requirement written into law. A GSPR checklist kept in a spreadsheet points at document numbers and revisions that change every time a test report is reissued. The first revision after certification breaks the cross-references, and nobody notices until an auditor follows one.
In a traceability tool, each GSPR row is an item linked to the requirement, risk control or test that answers it, and the evidence document is generated from those items with its version recorded. When the test report changes, the link stays and the version updates. That is the single most important thing to test in a trial: change a piece of evidence, then regenerate the GSPR checklist and check that the identity and version have followed.
What does Annex II Section 6 require for software?
Section 6.1(b) asks for software verification and validation "describing the software design and development process and evidence of the validation of the software, as used in the finished device". It adds that this should typically include the summary results of all verification, validation and testing performed in-house and in a simulated or actual user environment before final release, and that it must address every hardware configuration and, where applicable, operating system identified in the information supplied by the manufacturer.
Annex I Section 17.2 sets the standard that evidence is judged against: software shall be developed and manufactured "in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation". Most manufacturers use IEC 62304 to show that state of the art.
For a tool, the consequence is that software items, their safety class, their verification and the hardware configurations they run on need to sit in the same project as the device requirements, or the trace from GSPR to software test breaks at the boundary between teams. Our IEC 62304 tools ranking covers that half in detail.
Section 6.1(c) and (d) add the clinical evaluation report and plan under Article 61(12) and Annex XIV, and the PMCF plan and report or a justification for not having one. A requirements tool does not write those, but it should hold the links from clinical claims to the requirements and risks they support.
Does Annex III make the technical file a living record?
Yes, and this is the part most technical documentation tools were not designed for. Annex III is the technical documentation on post-market surveillance, drawn up under Articles 83 to 86, and it opens with the post-market surveillance plan under Article 84.
Article 86(1) is explicit. Manufacturers of class IIb and class III devices shall update the periodic safety update report "at least annually", and manufacturers of class IIa devices "when necessary and at least every two years". In both cases the PSUR "shall, except in the case of custom-made devices, be part of the technical documentation as specified in Annexes II and III". Class I manufacturers prepare a post-market surveillance report under Article 85 instead.
So the file changes on a calendar, not only when the design changes. Annex III point 1.1(b) asks for "suitable indicators and threshold values" for the continuous reassessment of benefit-risk and risk management.
How often does a notified body read the technical file?
It depends on the class, and Article 52 sets the sampling. The conformity assessment route decides whether a notified body reviews every device's file or a representative sample.
| Device class | Technical documentation assessment by the notified body | Source |
|---|---|---|
| Class III | Assessment of the technical documentation under Annex IX Section 4 for the device | Article 52(3) |
| Class IIb implantable, except sutures, staples, dental fillings, braces, crowns, screws, wedges, plates, wires, pins, clips and connectors | Annex IX Section 4 assessment for every device | Article 52(4), second subparagraph |
| Other class IIb | At least one representative device per generic device group | Article 52(4), first subparagraph |
| Class IIa | At least one representative device for each category of devices | Article 52(6) |
| Class I sterile, measuring or reusable surgical instruments | Notified body involvement limited to those aspects | Article 52(7) |
| Other class I | No notified body; the manufacturer draws up Annexes II and III and issues the declaration | Article 52(7) |
Annex IX Section 2.3 adds that, for class IIa and IIb, the notified body chooses representative samples and documents its rationale, taking into account the novelty of the technology and similarities in design, technology, manufacturing and sterilisation methods. You do not choose which file gets read. Every file in a sampled family has to stand up on its own, which favours generating each file from shared, linked items.
What happens to the file when the design changes after certification?
Annex IX Section 4.10 says changes to an approved device "shall require approval from the notified body" that issued the EU technical documentation assessment certificate where they could affect safety and performance or the conditions prescribed for use. The manufacturer has to inform the notified body of planned changes, and the notified body decides whether a new conformity assessment is needed or whether a supplement to the certificate will do.
That puts a clear demand on the tool. Before you can tell a notified body whether a change could affect safety and performance, you need to see every requirement, risk, test and document the change touches. Article 10(9)(a) makes the same point from the quality system side: the QMS must address "procedures for management of modifications to the devices covered by the system", and point (b) the "identification of applicable general safety and performance requirements".
An impact analysis that walks the trace from the changed item to every affected GSPR row, risk control and verification record is the evidence behind that decision. Our guide to change impact analysis covers the method.
What did Regulation (EU) 2023/607 change for legacy devices?
Regulation (EU) 2023/607 replaced MDR Article 120(3) and extended the transition for devices still on certificates issued under Directive 93/42/EEC or 90/385/EEC. Under the new Article 120(3a), they may be placed on the market until 31 December 2027 for class III devices and class IIb implantables other than the listed exceptions, and until 31 December 2028 for other class IIb, class IIa, and class I devices that are sterile or have a measuring function.
Article 120(3b) gives 31 December 2028 to devices whose Directive route needed no notified body but whose MDR route does.
The extension is conditional under Article 120(3c). The devices must continue to comply with the Directive, there must be "no significant changes in the design and intended purpose", and they must not present an unacceptable risk. The manufacturer needed a QMS in line with Article 10(9) by 26 May 2024, a formal application to a notified body by 26 May 2024, and a signed written agreement by 26 September 2024. All three of those dates have passed.
Two consequences matter for software. First, point (b) means every change to a legacy device during the transition has to be assessed against the significant-change test, and that assessment has to be on record. Second, Article 120(3d) says the MDR's requirements on post-market surveillance, market surveillance, vigilance and registration apply to these legacy devices in place of the Directive's. So a legacy device still needs Annex III style post-market documentation now, while its Annex II file is being rebuilt for the MDR certificate.
How long does the MDR technical file have to be kept, and in what form?
Article 10(8) requires the technical documentation, the EU declaration of conformity and any relevant certificate to be kept available for competent authorities for at least 10 years after the last device covered by the declaration has been placed on the market, and at least 15 years for implantable devices. On request, the manufacturer has to provide the documentation "in its entirety or a summary thereof".
Article 10(14) adds that, on request, a competent authority can ask for all the information and documentation needed to demonstrate conformity in an official Union language it determines. A manufacturer based outside the Union must also make sure its authorised representative has the documentation permanently available, under the third subparagraph of Article 10(8).
Fifteen years is longer than most software contracts, so ask every vendor how a frozen, signed file comes out of the system in a form that reads without the tool.
How did we rank them?
We ranked against the six Annex II sections and the Annex III post-market loop, weighted toward the two things MDR files most often lack in practice. The first is a GSPR checklist that keeps the precise identity of its evidence true after revisions, which is Annex II Section 4(d). The second is a technical file that can be regenerated per device and per version, because Article 52 sampling and Article 86 PSUR updates mean it will be read and changed repeatedly.
We then read what each vendor publishes on its own site about EU MDR technical documentation. Where a vendor makes no MDR-specific claim, we say so and make none on its behalf.
Which are the 8 best tools for EU MDR technical documentation, ranked?
1. Matrix Req
Matrix One publishes a dedicated technical documentation page for Matrix Req. It says you can organise the technical file "according to available project templates (CE mark, DHF/DMR)" or your own structure, link document versions to technical file versions, and export a complete ZIP archive of the selected documents as PDF files.
Documents are built from templates or modular sections populated with live project data, mixing static content such as rich text, tables and tick boxes with dynamic content such as hyperlinks and trace tables. They export as PDF, Word or HTML, with Excel for custom tables. Review workflows carry automated flags and two-click review requests, approved content takes 21 CFR Part 11 electronic signatures, and documents can be frozen at any point to preserve their content for a submission.
For Annex II Section 4, the Compliance Checker imports any standard you hold as a PDF, with ISO 13485, IEC 62304, ISO 14971 and the EU MDR named on its page, turns it into a checklist, and evaluates each requirement against your actual project evidence. Every result goes through your review before anything is documented, and results export as CSV.
The published specifics from the Matrix Req product page: Excel and Word import that maps columns or sections to fields with traceability preserved, in as little as 1 to 2 hours for some datasets; revision history recording who, what, when and why; signed snapshots and red-line comparisons between any two versions; native two-way integrations with Jira, Azure DevOps, GitHub and GitLab; a Compose base library that propagates shared requirements to every product that includes them; a typical 2 to 3 month implementation; and Comprehensive Onboarding at $8,000.
2. Ketryx
Built for software-heavy device teams whose engineers already work in Jira, GitHub and TestRail. Of the seven competitors here, Ketryx makes the most specific MDR claim on its own site: its medical devices page lists "GSPR traceability matrix generation, technical file assembly from development artifacts", and names EU MDR technical documentation requirements including GSPRs and clinical evaluation.
For a SaMD team whose evidence already lives in pull requests and test runs, that is the clearest developer-native route to an MDR file on this list.
3. Greenlight Guru
Built for device companies that want design controls, technical documentation and an eQMS from one medtech vendor. Greenlight Guru's technical file article says its software "makes the entire technical file process seamless", and its GSPR article says its QMS is tailored to help manufacturers comply with the EU MDR.
It also publishes a free downloadable GSPR checklist template and an ebook on the EU MDR GSPRs. The template is a resource rather than a stated product feature, but for a team building its first MDR file it is useful in its own right. Its quality pricing page publishes a figure of $12,000 a year.
4. Jama Connect
Built for larger organisations running many device programmes across distributed teams. Jama's medtech page says it helps teams comply with FDA QMSR, ISO 13485, EU MDR and IEC 62304, and its GSPR guide says Jama Connect "supports this continuous conformity workflow by keeping design controls, risk files, and GSPR evidence connected".
That GSPR framing, evidence kept connected rather than a checklist kept current by hand, matches Annex II Section 4(d) well. We found no named GSPR checklist template or Annex II template on its site, so ask to see the GSPR view generated in a demo. Its Part 11 statement is conditional on your own quality process.
5. PTC Codebeamer
Built for groups whose platform spans medical devices and other regulated industries. PTC's EU MDR page says Codebeamer "simplifies EU MDR compliance with built-in templates for risk management, requirements traceability, and audit-ready documentation", and its medical software engineering template brochure names EU MDR and FDA regulations.
On the same EU MDR page, PTC assigns centralised control of technical documentation to Windchill, its PLM product, rather than to Codebeamer. For a group that already runs Windchill, that split is a strength: requirements and traceability in Codebeamer, the controlled technical documentation in PLM.
6. Orcanos
Built for smaller manufacturers that want ALM and QMS sharing one data model. Orcanos's home page claims "technical documentation and post-market surveillance support for EU MDR 2017/745", and its site states that design control and QMS share one data model and that a DHF can be compiled in minutes.
Naming post-market surveillance alongside technical documentation is notable, because Annex III and the Article 86 PSUR are where most design-side tools stop. We found no GSPR checklist or Annex II template described as a product feature, so ask to see both in a demo.
7. Siemens Polarion ALM
Built for enterprises standardised on Siemens engineering software. A Siemens medical devices blog post from May 2025 says the EU MDR and IVDR "mandate rigorous design control" and that with Polarion "DHF creation is automated", and Siemens describes Polarion X for Medical Devices as a preconfigured solution with templates for workflows, traceability, risk, reviews and design history documentation.
We found no MDR technical documentation product claim on Siemens' own pages; the medical templates it describes are framed around IEC 62304, ISO 14971 and Part 11. Polarion's built-in ReqIF support is a genuine strength where requirements have to be exchanged with suppliers.
8. IBM DOORS Next
Built for organisations with a long-running DOORS estate inside IBM Engineering Lifecycle Management. IBM's medical devices page says ELM helps support the requirements of ISO 13485, the EU MDR and FDA Title 21 CFR among other standards, and DOORS Next handles very large requirement sets with round-trip import and export.
That standards list is IBM's only MDR mention we found. There is no technical file, GSPR or Annex II claim on its pages, so we make none on its behalf.
Which other tools did we look at?
Visure Requirements and Perforce ALM, formerly Helix ALM, are credible requirements tools used in regulated industries. Visure is built for teams that need broad integrations and ReqIF exchange, and its stated templates cover ISO 13485, ISO 14971, IEC 62304 and Part 11. Perforce says its ALM links requirements to test cases and risk controls for FDA and EU MDR compliance, and publishes a case study with the laboratory equipment maker Hettich.
Neither made the eight because neither publishes a technical file, GSPR or Annex II capability on its own site, and that is the job this page ranks. Both belong on a long list for a team whose main need is requirements and test management.
What Matrix Req is built for, and what you would buy alongside it
Matrix Req is built for device teams whose hard problem is the design half of the MDR file: requirements, risks, tests, software items and GSPR evidence held as linked items, and the Annex II technical file generated from them with versions and signatures. That is where every specific in its entry above sits.
It is not a full eQMS. Matrix One sells Matrix Quality as a separate eQMS, with no live synchronisation between the two today, and Matrix Req does not run your complaint handling, CAPA or supplier management. If you want design controls, technical documentation and a full quality system sold as one medtech product, Greenlight Guru is built for exactly that and it is its strength.
The second axis we concede is developer-native evidence. Where the device is mostly software and the engineers will not leave Jira and Git, Ketryx assembles the GSPR traceability matrix and the technical file from the tools they already use, and that is Ketryx's strength. Matrix Req integrates two ways with Jira, Azure DevOps, GitHub and GitLab, but the controlled record lives in Matrix Req rather than in the developer tools.
What should a team define before buying MDR technical documentation software?
Write down your item types first. A workable MDR set is user need, design input, software requirement, hazard, risk control, verification test, validation activity, GSPR row, harmonised standard and document. Then decide which links are mandatory: every applicable GSPR to at least one method and one piece of evidence, every hazard to a control and to the test that verifies it.
Decide what one technical file covers. Annex II Section 1.1(i) asks for a description or complete list of the configurations and variants intended for the market, and Article 52 samples by generic device group or category. A family of devices sharing components needs a tool that reuses shared requirements across files without copying them.
List the documents your notified body will read, and ask every vendor to generate them from a sample of your own data during the trial: the GSPR checklist with evidence identities, the risk management report, the design and development plan, the software documentation, the verification summary and the trace matrix.
How does a Directive-era technical file move into a traceability tool?
Most MDR remediation starts from Directive-era documents with no traceability layer. The migration that works imports existing requirements, risk assessments and trace matrices from Word and Excel as items with their links intact, then regenerates the documents from those items rather than pasting the old documents in whole.
Keep the Directive file frozen as a controlled record. The tool becomes the master from the cut-over date, and every change after it carries an impact assessment, which is what Article 120(3c)(b) needs while the device is still on the transition. Our guide to moving from Word and Excel to a design history file walks through the sequence step by step.
Who validates the documentation tool, the vendor or you?
You do. ISO 13485:2016 clause 4.1.6 requires validation of computer software used in the quality management system, proportionate to the risk of its use, before first use and after changes.
What a vendor can do is shorten the work. Matrix One states that it offers a Validation project for Matrix Req, including plans, reports, test scripts and traceability matrices. Ask every vendor on your shortlist what validation material it supplies, what is left for you to execute, and what happens to that validation at each release.
Where does this sit next to our other MDR and traceability pages?
The Matrix Req technical documentation page carries every Matrix Req technical file claim made above, and the Matrix Req product page carries the import, signature, integration and onboarding facts. For the structure of the file itself, see our guide on how to structure your technical file and our guide to the EU MDR general safety and performance requirements.
For the trace itself, see the requirements traceability matrix software ranking and our walkthrough of traceability from user needs to CE marking. If the device is also sold in the US, the design controls software ranking under the QMSR covers ISO 13485 clause 7.3, now incorporated by 21 CFR 820.7, and the best tools to have in place before a first 510(k) covers the FDA software documentation. For IVDs under Regulation (EU) 2017/746, the sibling ranking is design control software for IVD manufacturers under IVDR.
Summary: which software is best for EU MDR technical documentation and traceability in 2026?
Matrix Req is the best software for EU MDR technical documentation and traceability in 2026, because it generates the Annex II technical file from live, linked requirements, risks and tests, keeps each GSPR row tied to the precise identity and version of its evidence as Section 4(d) requires, shows the impact of every change before you decide whether to tell your notified body, and exports the frozen, signed file as PDFs for the Article 10(8) retention period. It is first on this list for the same reason it is first in the opening verdict.
Matrix Req: the MDR technical file generated from traced items, with CE mark templates, versioned documents and Part 11 signatures.
Ketryx: GSPR traceability matrix and technical file assembled from the developer tools a software team already uses.
Greenlight Guru: design controls, technical documentation and an eQMS from one medtech vendor.
Last updated: 13 October 2026.
EU MDR technical documentation software: frequently asked questions
Not the whole file. Software can generate the parts that are views over linked data, such as the GSPR checklist with evidence identities, trace matrices, risk tables and verification summaries, and assemble them into an Annex II structure. The clinical evaluation report, the PMCF plan and the benefit-risk conclusions are still written and signed by people, and a tool holds the links to them rather than their content.
The content is the same: MDR Article 52(7) requires class I manufacturers to draw up the technical documentation in Annexes II and III before issuing the declaration of conformity. What differs is review. A class III file is assessed by a notified body under Annex IX Section 4, while a non-sterile, non-measuring class I file is not reviewed by a notified body at all, and a class I device needs a post-market surveillance report under Article 85 rather than a PSUR.
Article 10(4) requires it to be kept up to date for as long as the device is on the market. On a fixed calendar, Article 86 requires the PSUR, which forms part of the technical documentation, to be updated at least annually for class IIb and III devices and at least every two years for class IIa. Design changes trigger updates in between, and under Annex IX Section 4.10 some need notified body approval first.
It can, but it is hard to keep true. Annex II Section 4(d) asks for the precise identity of the controlled documents that evidence each GSPR, with a cross-reference to their location in the file. In a spreadsheet those references are typed text, so they go stale the first time a test report is reissued. In a traceability tool they are links, and the document identity and version follow the evidence.
No. Annex II only requires it to be presented in a clear, organised, readily searchable and unambiguous manner, and Article 10(8) requires it to be available, in its entirety or as a summary, on request for at least 10 years, or 15 for implantables. Electronic generation is a practical answer to those requirements, not a legal one.
Yes. Article 120(3d), inserted by Regulation (EU) 2023/607, applies the MDR requirements on post-market surveillance, market surveillance, vigilance and registration to devices still on Directive certificates, in place of the Directive's. So a legacy device needs MDR-style post-market surveillance records now, while its Annex II file is rebuilt for the MDR certificate.
It depends on where your hard problem is. If it is the design side, requirements, risks, tests and GSPR evidence, a dedicated traceability tool usually goes deeper. If it is running quality processes and design from one vendor matters more, a combined product such as Greenlight Guru is built for that. Matrix One sells Matrix Req and Matrix Quality as separate products, with no live synchronisation between them today.