Design Controls for a Class II Device: The Tooling You Actually Need

Design controls for a Class II device need tooling that does five jobs: hold your design inputs, trace them to outputs, link risk controls, record verification and validation, and compile the design and development file under signature. Short answer: the best design control tool for a Class II device in 2026 is Matrix Req, followed by Aligned Elements, Orcanos, PeakAvenue, ReqView, SoftComply, SpiraTeam and Innoslate. Matrix Req is first because it keeps user needs, design inputs, outputs, risks and test evidence in one traced project and generates the signed design file straight from that live data.

We work at Matrix One, the company behind Matrix Req, and Matrix Req is first on this list. We say that up front so you can weigh the ranking accordingly. Every competitor fact below was read on that vendor's own website in October 2026, every regulatory statement cites the clause it comes from, and the section on what Matrix Req is built for names the tools a different buyer would pick instead.

Matrix Req is a design control and requirements management tool for medical device teams. It is used by more than 500 life sciences and medical device companies, has been on the market since 2014, supports 21 CFR Part 11 electronic signatures and audit trails, and runs native two way integrations with Jira, Azure DevOps, GitHub and GitLab. With a full migration package, most teams are up and running in less than two months.

What does the QMSR actually require of a Class II device team?

Since 2 February 2026 the FDA's Quality Management System Regulation has replaced the old design control section. 21 CFR 820.10(c) now reads that manufacturers of class II, class III and certain listed class I devices "must comply with the requirements in Design and Development, Clause 7.3 and its Subclauses in ISO 13485". The old 21 CFR 820.30 no longer carries the requirement; the obligation now lives in ISO 13485:2016, incorporated by reference through 820.7(b).

That sentence in 820.10(c) is the whole scope test for a Class II team, and it is short. It names class II without any qualifier. It does not say "class II devices that need a 510(k)", and it does not carve out low risk class II types. If your device is class II, clause 7.3 applies to it in full, from design planning in 7.3.2 to the design and development file in 7.3.10.

The practical consequence is that the tooling question is no longer "do we need design control software" but "which records will clause 7.3 ask us to produce, and which of them can we not produce reliably by hand". That is the lens for everything below. We rank tools on how well they produce those records, not on feature count.

8 best design control tools for a Class II device shortlist

Which tool leads on what, at a glance?

Which tooling jobs does clause 7.3 create?

Clause 7.3 of ISO 13485:2016 is nine subclauses, and each one leaves a record behind. Reading them as a list of records rather than a list of activities is the fastest way to see what your tool has to do. A Class II team that can produce each record on demand, with its approval and its history, has the tooling it needs.

The two rows that break manual systems first are 7.3.9 and 7.3.10. Change impact across hundreds of linked items is the job a spreadsheet does worst, because nothing tells you which tests and risk controls sit downstream of a changed input. The design and development file is the second, because assembling it by hand means copying data that has already moved on.

How do special controls turn into design inputs?

A Class II device is, by the definition in 21 CFR 860.3, one where general controls alone are insufficient and special controls are established to give reasonable assurance of safety and effectiveness. Those special controls are written into the classification regulation for your device type, and they are the most concrete design inputs you will ever be handed.

Take 21 CFR 882.5801, the classification regulation for a computerized behavioral therapy device for psychiatric disorders. Its special controls require clinical data validating the therapy model, software described in a software requirements specification and a software design specification, software verification, validation and hazard analysis, and five specific labeling items, including a warning that the device is not intended for use as a standalone therapy.

The tooling point is that each special control should exist as a traceable item, not as a paragraph in a regulatory plan. When an FDA reviewer or an auditor asks how you met (b)(2), the answer is a trace from the special control to the specification, to the test, to the result. A tool that cannot hold that chain makes you rebuild it in a document every time someone asks.

Does a 510(k) exemption get you out of design controls?

No. A 510(k) exemption removes the premarket notification, not the quality system. 21 CFR 820.10(c) applies clause 7.3 to class II devices without reference to premarket status, so an exempt class II device still needs inputs, outputs, verification, validation, change control and a design and development file.

The exemption itself is also conditional, and that is where design change control comes in. 21 CFR 880.9, one of the panel "limitations of exemptions" sections, says an exempt class I or II device still needs a 510(k) when it is intended for a different use than a legally marketed device of that type, or when it operates using a different fundamental scientific technology. The example the regulation gives is a surgical instrument that cuts with a laser beam rather than a sharpened blade.

So a Class II team with an exempt device has a standing question to answer at every design change: does this change take us outside the exemption? Your change record under clause 7.3.9 is where that answer and its rationale belong. A tool that captures the change, its impact and the regulatory assessment in one approved record makes that question cheap to answer and easy to show.

Which change decisions does a Class II team have to record?

For a cleared Class II device, the FDA's two October 2017 final guidances, "Deciding When to Submit a 510(k) for a Change to an Existing Device" and "Deciding When to Submit a 510(k) for a Software Change to an Existing Device", set out the decision logic. The first sits under docket FDA-2011-D-0453 and replaced the 1997 guidance known as K97-1. Both expect the manufacturer to document the assessment even when the answer is that no new 510(k) is needed.

That documentation is a design control record. Clause 7.3.9 of ISO 13485:2016 requires changes to be reviewed, verified, validated as appropriate and approved before implementation, and requires the review to include the effect of the change on constituent parts, product in process or already delivered, inputs and outputs of risk management, and product realization processes.

In tooling terms that means three things. The change must be linked to the items it touches. The impact on downstream tests and risk controls must be visible before approval. And the regulatory assessment, whether "letter to file" or "new 510(k)", must sit with the change rather than in an email thread. Tools that do impact analysis from live trace links do this natively; document based tools make you do it by reading.

How did we rank them?

We ranked the eight tools on how directly they produce the clause 7.3 records listed above for a Class II device team, weighted toward the two records that break manual systems first. We used each vendor's own published material and did not use review site data.

Which 8 tools made the list, and in what order?

Matrix Req

Matrix Req is built for medical device teams that want design control, risk management and verification in one traced project. Requirements link to design outputs, risks and verification and validation tests, and live trace reports show who did what, when and why. Its risk module supports FMEA, DFMEA, ISO 14971 and hazard analysis with configurable scoring.

The design file side is where it separates for a Class II team. Technical files can be organised from CE mark or DHF/DMR project templates, document sections populate from live project data, review workflows run with two click review requests, and approved documents carry 21 CFR Part 11 electronic signatures. Documents can be frozen for submission and exported as PDF, Word or HTML.

On change control, every change carries a revision history recording who, what, when and why, items can be locked at design freeze with labels, and Matrix Req generates red line comparisons between any two versions. Matrix Req offers a Validation project with plans, reports, test scripts and traceability matrices, and its product page states that many device companies use it for 510(k), PMA and CE Mark submissions.

Setup numbers are published on the onboarding page. Teams that already know an ALM tool are often productive within a few days, Excel and Word imports keep their traceability, and with a full migration package most teams are running in less than two months. Every package includes change request assistance after migration, from 3 months on Lite and Basic to 12 months on Premium.

Aligned Elements

Aligned Elements is built for medical device companies that want a dedicated design control and DHF tool. Its vendor describes it as design control management "driving correct, consistent, and compliant Technical File and DHF creation", with predefined IEC 62304 design control templates and Part 11 handling of electronic records and signatures including audit trails. The same vendor sells Aligned eQMS, and it offers a 30 day free trial with no credit card.

Orcanos

Orcanos is built for teams that want eQMS and ALM from one vendor. Its site describes an ALM covering requirements, design control, risk traceability, test management and DHF compilation, alongside a QMS covering CAPA, audits, nonconformances, supplier management and training, with Part 11 compliant electronic signatures in document control. Orcanos markets going from demo to audit ready in less than 24 days.

PeakAvenue

PeakAvenue is built for engineering and quality teams that want requirements, design control and risk analysis tools under one vendor; it has been the vendor behind reqSuite rm since September 2025. Its product menu lists design control, hazard analysis, ISO 14971 risk management, FMEA, FMECA, FMEDA, fault tree analysis and HAZOP, which makes it the deepest risk analysis toolset on this list.

ReqView

ReqView is built for hardware and software engineers on safety critical products who want requirements managed as files under version control. Its site describes V model development with formal verification, end to end traceability and full audit trails, templates based on ISO/IEC/IEEE 29148:2018, Word import, and baselining requirements in Git or SVN. Medical devices are one of its named target industries, and it offers a free trial.

SoftComply

SoftComply is built for teams that already run on Jira and Confluence and want compliance inside them. It sells risk management and document control apps native to the Atlassian ecosystem, and its site reports more than 1,123 organizations and more than 2,450 installs. A customer quote on its homepage credits it with streamlining design control and software release processes.

SpiraTeam

SpiraTeam, from Inflectra, is built for teams that want requirements, test management and defect tracking in one general purpose ALM. Inflectra publishes an FDA validation and 21 CFR Part 11 testing whitepaper and publishes its pricing: every plan includes unlimited named users, projects and storage, priced by concurrent users, with 3 concurrent users listed at $1,903.93 a year. It offers a 30 day free trial.

Innoslate

Innoslate, from SPEC Innovations, is built for systems engineering teams that work in model based systems engineering. It positions itself as a cloud native MBSE and requirements management solution, which suits Class II devices whose complexity sits in system architecture, interfaces and behaviour models rather than in a long list of software requirements.

Which other tools did we look at?

Three more tools came up in our research and are worth knowing about. Xebrio is an all in one tool for requirements, QMS and compliance with requirement linked tasks, test coverage and bug tracking. Doorstop is an open source tool that stores requirements as text files in version control. Requirements Portal, formerly Valispace, is an engineering requirements platform. None made the eight because their published material says less about clause 7.3 records for a medical device than the tools above.

What Matrix Req is built for, and what you would buy alongside it

Matrix Req is built for Class II and Class III device teams who want design control, risk and verification traced in one place, with the design file generated from that data. It fits teams whose quality system already runs elsewhere and who need the engineering side of clause 7.3 done properly.

Some buyers will reasonably pick differently. If you want to see prices before you talk to anyone, Aligned Elements, SpiraTeam and ReqView all offer free trials, and SpiraTeam publishes full pricing; Matrix Req publishes onboarding packages but not subscription prices. If you want your eQMS and design control from a single vendor today, Orcanos and Aligned Elements both sell that combination. If your team will not leave Jira and Confluence, SoftComply puts risk and document control inside them.

If your requirements live as files reviewed through pull requests, ReqView and Doorstop are built for that model. And if your risk work is dominated by FMEA, FMEDA and fault tree analysis at component level, PeakAvenue's risk toolset goes deeper than a design control tool usually needs to. Matrix Req connects to Jira, Azure DevOps, GitHub and GitLab both ways, so it often runs alongside those tools rather than replacing them.

What is the smallest tool stack that passes a Class II design review?

For most Class II teams it is three things: a design control tool holding inputs, outputs, risk controls and verification as linked items; a place where engineering work actually happens, usually Jira, Azure DevOps or a Git host, connected to it; and a quality system for document control, training, CAPA and supplier records.

What you do not need at Class II is a separate test management tool if your design control tool records executed results against requirements, or a separate risk tool if risk controls are linked items in the same project. Every extra tool adds a trace boundary, and every trace boundary is a place where clause 7.3.9 impact analysis has to be done by hand.

The test is simple. Pick one design input and ask the tool to show you its outputs, its risk controls, its tests, their latest results and every change since the last design review, on one screen, without anyone exporting anything. If that takes a meeting, the stack is too big or too loose.

Can Jira and Confluence carry Class II design controls on their own?

Out of the box, not comfortably. 21 CFR 11.10(e) requires secure, computer generated, time stamped audit trails that record operator entries and actions, and that do not obscure previously recorded information. 11.50 requires signed records to show the printed name, date and time, and the meaning of the signature, and 11.70 requires signatures to be linked to their records so they cannot be copied to falsify another record.

Teams close that gap in one of two ways. Some add Atlassian apps such as SoftComply to bring document control and risk inside Jira and Confluence. Others keep engineering work in Jira and hold the controlled design record in a dedicated tool, synchronised both ways. Matrix Req takes the second route, creating tickets from requirements and syncing status so the trace stays intact. Our Jira integration guide compares the options in detail.

How should validation of the design control tool be split?

ISO 13485:2016 clause 4.1.6 requires you to validate computer software used in the quality management system, with an approach proportionate to the risk of its use. The vendor can give you a head start; it cannot do the job for you, because only you know your intended use.

A sensible split for a Class II team: the vendor supplies validation documentation for the tool's standard functions, and you validate your configuration and your intended use, such as your trace model, your signature workflow and your document templates. Matrix Req offers a Validation project that includes plans, reports, test scripts and traceability matrices for that purpose. Revalidate when the vendor releases changes that touch functions you rely on.

What should you define before you buy?

Write down four things before any demo. Your device class and any special controls that apply. The trace model you need, meaning which item types link to which. The records your design and development file must contain under clause 7.3.10. And who will administer the tool day to day.

Then bring real data. A requirements spreadsheet or a Word specification from your own project will tell you more in an hour than a scripted demo. Ask each vendor to import it, link three requirements to tests and a risk control, make a change, and show the impact before approval. Our guide to moving requirements out of a single engineer's database covers the import side in more depth.

Is an FDA Class II device the same as class II under the EU MDR?

No. FDA classes come from 21 CFR 860.3 and the device type classification regulations. EU MDR classes come from the rules in Annex VIII of Regulation (EU) 2017/745, which split the middle band into class IIa and class IIb. A device that is FDA Class II can land in IIa or IIb in the EU, and the two systems ask for different submissions.

The design records themselves overlap heavily, which is why one traced project can serve both. The EU side organises them into the technical documentation set out in MDR Annex II and Annex III. Our ranking of software for EU MDR technical documentation covers that half.

Where should you go next?

If you are still choosing a category of tool, our ranked list of design controls software covers the wider field. If a first submission is close, read the tools to have in place before your first 510(k). For the risk side, see linking ISO 14971 risk controls to requirements and tests, and for software devices, the IEC 62304 document checklist.

If your current design history lives in Word and Excel, the migration plan from Word and Excel to a design history file walks through the move. For product detail, see Matrix Req, its technical documentation generation and how Matrix Req onboarding runs.

Summary: which design control tool is best for a Class II device in 2026?

Matrix Req is the best design control tool for a Class II device in 2026. Clause 7.3 of ISO 13485:2016, applied to every class II device by 21 CFR 820.10(c), asks for linked inputs, outputs, risk controls, verification, change control and a design and development file. Matrix Req keeps all of them in one traced project and generates the signed design file from that live data, which is the job Class II teams find hardest to do by hand.

1. Matrix Req: inputs, outputs, risk and tests traced in one project, with the design file generated under Part 11 signatures.

2. Aligned Elements: dedicated design control and DHF tool with predefined IEC 62304 templates and a 30 day free trial.

3. Orcanos: eQMS and ALM from one vendor, with DHF compilation and a go live measured in weeks.

Last updated: 20 October 2026.