Written by: Senior QA Engineer
Mykhailo RalduhinPosted: 27.08.2026
14 min read
In May 2025, Zyno Medical recalled certain models of its infusion pumps as they were released with the wrong software versions that had not undergone required verification and validation testing and could experience unexpected performance problems. Such recalls are what happen to medical device producers in case of FDA non-compliance.
The FDA sets clear regulations for medical technology to ensure its reliability, safety, and fit for the intended use. Compliance is closely monitored through inspections, recalls, and post-market oversight.
In medical software development under the category of SaMD or SiMD, FDA compliance is definitely one of your key priorities and concerns. Yet, regulatory compliance for medical devices is not only a legal obligation but also a safeguard for your business and your end users.
The good news is that meeting FDA requirements is absolutely possible. Moreover, it's much easier with an expert QA partner by your side. Because regulatory compliance and medical device testing are deeply connected, QA experts can help you anticipate risks, close gaps, and check all the compliance boxes. How? Read on to get the answer.
Healthcare QA expertise you can build on
When and how the FDA regulations are applied
As a federal agency within the U.S. Department of Health and Human Services, the FDA is responsible for protecting public health by ensuring the safety, effectiveness, and quality of food, drugs, vaccines, medical devices, cosmetics, and tobacco products. Software isn't mentioned. Is it a mistake? Not at all.
The thing is that the FDA regulates only those types of software that are either embedded in medical devices or function as medical devices on their own. This means not every healthcare-related solution falls under FDA oversight. For those that do, however, the scope of regulation and the level of testing depend on how the software is defined and classified.
What is software as a medical device (SaMD)?
While software embedded into medical devices is straightforward, software as a medical device often raises more questions. So, what is SaMD? The FDA uses the internationally adopted definition that comes from IMDRF:
SaMD is software that's intended for one or more medical purposes and performs those purposes without being part of a hardware medical device.
In other words, if your software helps diagnose, prevent, monitor, or treat a disease, it likely qualifies as SaMD.
Quick self-check:
A mobile app that analyzes heart rate data to detect arrhythmias — ✔️ SaMD (FDA-regulated).
A telemedicine platform with video calls — ❌ not SaMD (not FDA-regulated).
A fitness tracker — ❌ not SaMD (not FDA-regulated).
An AI-powered app that checks retinal images for diabetic retinopathy — ✔️ SaMD (FDA-regulated).
Depending on the purpose and risk, the FDA clearly distinguishes software that counts as a medical device and must be regulated, those that are technically devices but low-risk enough to avoid strict rules, and solutions that aren't considered devices at all, like wellness trackers, medical reference libraries, or educational tools.
FDA classification of medical devices
The FDA applies a risk-based classification to all medical devices, including SaMD and software embedded in devices (SiMD). It defines the needed level of testing, documentation, and review:
- Class I (low risk)
This class covers general wellness or simple diagnostic support tools. Such solutions usually deal with light regulatory requirements but still need to prove safety and effectiveness.
Examples: Menstrual cycle tracking apps, symptom checkers that advise whether to see a doctor, or basic medication reminders.
Regulatory control: General controls (e.g., registration, labeling)
- Class II (moderate risk)
Most medical software falls here, such as apps that track chronic conditions or guide clinicians in treatment decisions. They require thorough testing, validation, and often FDA clearance through the 510(k) pathway.
Examples: Apps that analyze glucose data, ECG analysis tools, or radiology software that flags suspicious lesions in scans.
Regulatory control: General and special controls (e.g., performance standards, post-market surveillance).
- Class III (high risk)
This class includes software that supports life-sustaining decisions, such as insulin pump controllers or cardiac monitoring systems. Since a failure here could harm someone's health, software of this kind goes through the strictest FDA checks and needs premarket approval (PMA) with plenty of testing proof.
Examples: Software that controls implantable defibrillators, closed-loop insulin delivery systems, or diagnostic platforms that determine chemotherapy dosing.
Regulatory control: General controls and Premarket Approval (PMA)
Correct classification is very important for healthcare software compliance. If you underestimate the risk and classify your software too low, your submission may be rejected or delayed until additional data is provided. On the other hand, overestimating risk could lead to extra expenses and time loss.
Getting classification right from the outset ensures that your testing strategy matches FDA expectations. Unsure? You can request FDA feedback via a 513(g) to confirm how your product will be classified.
How FDA regulatory compliance and software testing work together
FDA compliance is enforced by the US government to protect users of medical devices. And that's the very same mission quality assurance serves. While FDA regulations set the rules by defining risk classes, requirements, and needed documentation, QA ensures those rules are met in practice by performing software validation for FDA compliance.
The FDA demands that every claim about your software be proven, every risk be mitigated, and every change be documented. Based on these requirements, dedicated QA teams create test strategies, traceability matrices, and validation protocols that provide good evidence.
Without proper medical equipment safety testing and QA, compliance turns into guesswork. When the two work together, you get the needed accountability loop — requirements → implementation → testing → evidence. That's how you prevent costly regulatory setbacks and shorten the time to market.
Core FDA regulations in medical software testing
The impact of the FDA on software as a medical device testing is huge. You can't achieve real safety and compliance without a full understanding of the regulatory framework. The FDA's requirements and cross-industry standards collectively shape how software is designed, tested, and monitored.
The key medical software FDA regulations to know:
21 CFR Part 11 — Electronic Records and Signatures
21 CFR Part 11 outlines how electronic records and signatures should be handled, ensuring data integrity, audit trails, and validation of software tools. QA teams must carefully check that systems managing clinical data follow these requirements, including proper logs and secure access.
21 CFR Part 820 (Quality System Regulation — QSR)
Part 820 lays out the rules for design, testing, and risk management in medical device software development. It affects how you plan and run tests and what documentation you need to prepare, making sure every feature is checked and every risk is covered.
Cybersecurity Guidance (2023 updates)
Based on these requirements, the FDA now wants premarket submissions to include threat modeling, a software bill of materials (SBOM), and postmarket vulnerability monitoring. It requires a security testing and validation process to meet these requirements.
General Principles of Software Validation
General Principles of Software Validation give a roadmap for validating software across its whole lifecycle. For QA teams it means to structure validation protocols, traceability matrices, and documentation in order to meet FDA expectations.
IEC 62304 — Software Lifecycle Processes
Recognized by the FDA as a consensus standard, IEC 62304 outlines best practices for the lifecycle of software that's part of a medical device. By following it, you ensure that the design, development, and maintenance of your software adhere to global standards.
ISO 14971 — Risk Management
Risk management standard explains how to spot and mitigate possible hazards in your software. It nudges QA to perform risk analysis and prepare risk mitigation strategies, checking not just that the software works, but that it does so safely under all conditions.
IEC 62366 — Human Factors / Usability
IEC 62366 has a goal to make software safe and easy to use, reducing the chance of user errors that could harm patients. QA teams use it to run usability tests, check how real users interact with the software, and make corresponding adjustments before release.
While all these FDA regulations and standards primarily focus on safety and effectiveness, it's worth mentioning that software that handles patient data also must meet complementary data-security requirements like HIPAA compliance, HITECH, and HITRUST. All of them regulate how protected health information needs to be stored, managed, accessed, and transmitted, and QA processes should include corresponding checks to comply with these rules too.
What does an FDA-compliant test strategy look like?
Quality assurance for medical devices is a highly challenging task. If you're developing SaMD or SiMD, a test strategy that hunts only for bugs won't cut it. Here is how to approach each of the five traditional phases of software testing, considering FDA compliance:
Phase 1: Planning
Treat this phase as laying out your map before a road trip. Without it, you'll get lost, and regulators will conclude you weren't in control of your process.
Compliance angle: You need a detailed test plan that defines test scope, goals, and risk priorities. Regulators expect to see how you identified hazards and tied your testing effort to patient safety.
What to do: Start with risk analysis. Leverage FMEA (Failure Mode and Effects Analysis) to rate possible failures by severity, likelihood, and detectability. Mark anything that could cause any harm or critical regulatory non-compliance.
Deliverables: Risk assessment, test strategy, traceability of critical functions, regulatory mapping (matrix of FDA/IEC/ISO clauses to test coverage).
Why it matters: If you can show the FDA that your test scope is built around patient safety, you're in line with ISO 14971 and FDA guidance. It proves you didn't just test what seemed important, but covered all the truly critical areas.
Phase 2: Test design
At this point, the goal of a QA team isn't just to design test cases but to build the proof that regulators will ask for later.
Compliance angle: Every requirement must be linked to one or more tests. This is where your traceability matrix is a must because it's your evidence that nothing slipped through the cracks.
What to do:
Create test cases with clear inputs, expected results, and acceptance criteria for normal, boundary, and failure-mode behavior.
Connect each test to a particular requirement or risk.
Also, include test types regulators usually care about, like performance testing, user acceptance validation, and security testing.
Deliverables: Test cases with acceptance criteria, a traceability matrix, test data sets.
Why it matters: The FDA doesn't just want to know you tested software. What they really want is to see traceability. If a bug shows up, they'll ask for proof that you considered that scenario in your test design.
Phase 3: Test execution
Now, it's time to run your tests. This is also when your paper trail starts to prove its value.
Compliance angle: Every test run must be logged and reviewable. It's not enough to say that you tested your software. You need strong evidence with details.
What to do:
Record environment details (software build, database version, test hardware).
Document inputs, outputs, and outcomes.
Log defects with risk impact, root cause, and fix verification path.
Track retesting after fixes.
Why it matters: During a review, regulators often ask to provide test evidence for a specific requirement. If you can quickly present the log, defect record, and retest result, you look reliable. If you can't, you drop points.
Deliverables: Test logs, defect reports, updated risk assessment, change-control records.
Phase 4: Reporting
At this stage, QA engineers' job is to tell a story of testing in a way that satisfies auditors and keeps your team informed.
Compliance angle: Your test report is your defense file. It must summarize coverage, results, and risks clearly enough for an outsider to understand.
What to do:
Create an audit-ready report with:
traceability matrix snapshots
pass/fail summaries
risk-critical defect handling (what was found, how it was fixed, and proof of retesting)
sign-offs from QA leads and stakeholders.
Deliverables: Test summary reports, deviation reports.
Why it matters: The FDA auditors won't rerun your tests when reviewing your project. Instead, they'll take a look at your reports. If they are clear and complete, it proves your control over the QA process.
Phase 5: Verification and validation after fixes (V&V)
This final phase helps you show that you've fixed what was broken and that the system, as a whole, is really safe for real-world use.
Compliance angle: Verification and validation are essential elements of FDA compliance software testing, and it's important to know the difference between them:
Verification ensures the software is developed in the right way (checking against requirements).
Validation ensures the software developed is actually the right thing (checking for meeting user and patient needs).
What to do:
Re-run tests after fixes to verify nothing else broke through regression testing.
Validate that the final build is still in line with user workflows, safety expectations, and compliance standards.
Document final sign-off to close the loop.
Deliverables: Verification report, validation report, regulatory submission package.
Why it matters: Without well-documented V&V, regulators may suggest you don't actually know if your software is safe.
Healthcare QA partner you can count on
How QA partnership helps medtech companies stay compliant
Not every company has a fully staffed in-house QA team that knows FDA regulations from A to Z. But even those that have it may need some extra hands. If you're facing strict deadlines, tackling a first-of-its-kind feature, or missing FDA-level documentation skills, QA partners can save time and cut down on rework.
Services for healthcare software testing
Leading providers of healthcare software testing services strive to adjust to clients' needs. Their offerings usually include:
Managed test automation: Automated software testing in healthcare is a real boon, but it requires special skills and efforts. An experienced QA partner can take on the task of developing, maintaining, and scaling automated tests while ensuring they stay FDA-compliant.
That's what DeviQA has done for Abbott when working on its LibreView platform. The test automation we implemented expanded test coverage to 90% and significantly cut regression and smoke testing time. This collaboration ensured both faster releases and adherence to FDA regulations — a good example of the value a seasoned QA partner brings to medical software development.
QA consulting: You can get expert QA assistance in setting up compliant processes, writing traceable test documentation, or preparing for regulatory reviews.
Dedicated QA teams: It's your opportunity to bring in QA specialists who can quickly get onboarded and ensure every release is audit-ready.
What to consider when choosing a QA partner?
When it comes to FDA compliance, not every vendor can get it done. To find the right QA partner, we'd advise you to pay attention to the following aspects:
Domain experience
Target QA teams that have already worked on SaMD or SiMD projects and know all intricacies, workflows, data privacy nuances, etc.
Regulatory fluency
Your potential partner should be familiar with FDA 21 CFR Part 11, IEC 62304 life-cycle practices, ISO 14971 risk management, IEC 62366-1 human factors, IEC 82304-1 health-software quality, and cybersecurity regulations to ensure full regulatory compliance.
Proven automation frameworks
A partner with ready-to-use infrastructure speeds up compliance while saving you from the bulk of work. So, ask for reusable, maintainable frameworks, pipelines wired for traceability, data seeding, test environment isolation, and regression at each change.
Certifications
Shortlist QA companies with ISO 9001 (quality management), ISO 20000 (service management), ISO 27001 (information security), and team-level ISTQB credentials. Surely, these don't replace evidence, but they do signal that the team has structured practices in place.
Why it's worth it
With a trustworthy QA partner, you can avoid months of rework and ensure a seamless regulatory submission. They bring skilled people, battle-tested frameworks, documentation discipline, and a regulatory mindset that's difficult to quickly grow internally.
Conclusion — Compliant testing as a way to deliver SaMD or SiMD safely and quickly
FDA compliance can be a real pain in the neck, taking additional time and effort. On the flip side, this is an important safety measure that protects your users' health and lives and shields your business from serious trouble.
By understanding what the FDA expects from you and following its regulations, you can hit the market with innovative healthcare solutions, being confident in their safety and value. An experienced QA partner by your side can make the whole process less stressful through risk-aware and well-documented QA.
Is this what you need? Schedule a call with the DeviQA team and learn how we can help you pass FDA audits and scale safely.
Book a strategic QA consultation
About the author
Senior QA engineer
Mykhailo Ralduhin is a Senior QA Engineer at DeviQA, specializing in building stable, well-structured testing processes for complex software products.