If you are building software that qualifies as a medical device, or software that runs inside one, the standards you follow determine whether you reach the market or stall in regulatory review. The problem most HealthTech teams face is not a lack of standards. It is the opposite: too many standards, overlapping jurisdictions, and recent regulatory changes that invalidate older playbooks.
This guide maps the medical device software standards that matter now, explains how they connect to FDA and EU MDR requirements, and gives you a documentation checklist you can hand to your quality and engineering leads.
What Counts as Medical Device Software
The term "Software as a Medical Device" (SaMD) refers to software that performs a medical function on its own, without being part of a physical device. A mobile app that analyzes cardiac rhythm data to detect arrhythmias is SaMD. A firmware module embedded in an infusion pump is "software in a medical device" (SiMD). Both categories fall under medical device software standards, but the regulatory path and applicable standards differ.
Regulators classify SaMD by the severity of the clinical decision it informs and the condition it addresses. A wellness tracker that logs steps is not SaMD. An algorithm that flags sepsis risk from vital-sign trends almost certainly is. If your product sits near the boundary, engage a regulatory consultant before you write your first user story. Misclassification wastes months.
For teams exploring the broader context of building regulated health products, our overview of healthcare software development covers the service models and compliance considerations involved.
The Standards Map: What Each Standard Governs
The table below covers the standards and regulations most HealthTech teams will encounter. It is not exhaustive, but it captures the ones that generate the most documentation, the most audit findings, and the most confusion.
| Standard / Regulation | What It Governs | Evidence Produced | When to Involve Quality / Regulatory |
|---|---|---|---|
| ISO 13485:2016 | Quality management system (QMS) for medical device organizations | Quality manual, procedures, records of design control, supplier management, CAPA logs | Before project kickoff; QMS must be in place before design activities begin |
| ISO 14971:2019 | Risk management across the device lifecycle | Risk management file: hazard analysis, risk evaluation, risk control measures, residual risk assessment | At concept stage; update continuously through post-market |
| IEC 62304:2006+A1:2015 | Software lifecycle processes for medical device software | Software development plan, architecture docs, unit/integration/system test records, release notes | At planning; safety class determines rigor level |
| IEC 62366-1:2015+A1:2020 | Usability engineering (application of usability to medical devices) | Use specification, formative evaluation reports, summative usability test report | During requirements definition; usability file reviewed at design transfer |
| IEC 81001-5-1:2021 | Security lifecycle for health software | Threat model, security risk assessment, secure design documentation, vulnerability management plan | At architecture phase; use it to structure security evidence and verify recognition or harmonisation by market |
| FDA QMSR (21 CFR 820, revised) | U.S. quality system requirements incorporating ISO 13485:2016 | QMS records aligned with ISO 13485 plus FDA-specific additions | Before any FDA submission; effective February 2, 2026 |
| EU MDR 2017/745 | European market access for medical devices including SaMD | Technical documentation, clinical evaluation, Declaration of Conformity, UDI registration | At product concept if EU market is planned; Notified Body engagement early |
| IEC 60601-1 (and -1-2) | Safety and electromagnetic compatibility for medical electrical equipment | Test reports, risk analysis for electrical safety | Applies when software is part of medical electrical equipment |
This table answers the long-tail query that already ranks near the top 10: "ISO 13485 ISO 14971 IEC 62304 IEC 62366 medical device standards overview." Bookmark it or print it for your next compliance planning session.
ISO 13485 and the FDA QMSR Shift
ISO 13485:2016 defines the quality management system requirements for organizations involved in any stage of a medical device's lifecycle. It covers design controls, document management, purchasing, production, CAPA (corrective and preventive action), and management review.
What changed recently: the FDA finalized its Quality Management System Regulation (QMSR), which incorporates ISO 13485:2016 into the U.S. regulatory framework with FDA-specific additions. This regulation became effective February 2, 2026. If your QMS was built solely around the old 21 CFR Part 820 structure, you need a gap analysis now. The inspection process will change, and auditors will expect ISO 13485-aligned evidence.
For software teams, ISO 13485 means every design decision, requirement change, and verification activity must be traceable and recorded. The standard does not tell you how to write code. It tells you how to prove that your organization controls the process that produces the code.
ISO 14971: Risk Management That Runs the Entire Lifecycle
ISO 14971:2019 provides the framework for identifying hazards, estimating and evaluating risks, controlling those risks, and monitoring residual risk after the product ships. It applies to every medical device, including SaMD.
The risk management file is the single most reviewed document in any regulatory submission. It is not a one-time deliverable. You update it when requirements change, when post-market data reveals new hazards, and when you release software updates that alter clinical behavior.
Practical risk workflow for software teams
- Identify hazards during requirements and architecture reviews. For SaMD, consider data integrity failures, incorrect algorithm outputs, latency in clinical alerts, and user-interface misinterpretation.
- Estimate severity and probability using your clinical context. A diagnostic algorithm that misclassifies a malignant lesion as benign carries different risk than a scheduling tool.
- Define risk controls at the software level: input validation, algorithm boundary checks, user confirmation steps, fail-safe defaults.
- Verify controls through testing. Trace each control back to the hazard it mitigates.
- Monitor post-market. Customer complaints, field safety reports, and software anomaly logs feed back into the risk management file.
Teams building connected health products that combine mobile apps, wearable data, and clinical portals face compounded risk scenarios. A project like RAE Health, which integrates multiple data sources into a clinical workflow, illustrates the kind of architectural complexity where disciplined risk management prevents gaps from becoming patient safety events.
IEC 62304: Software Safety Classification and Lifecycle Rigor
IEC 62304 is the standard that software engineers interact with most directly. It defines three safety classes based on the potential harm from software failure:
- Class A: No injury or damage to health is possible.
- Class B: Non-serious injury is possible.
- Class C: Death or serious injury is possible.
The safety class determines how much documentation and process rigor you need. Class A requires a software development plan and basic verification. Class C requires detailed architecture documentation, unit-level testing, and full traceability from requirements through code to test cases.
How to determine your safety class
Start with your ISO 14971 risk analysis. If a software failure could contribute to a hazardous situation that results in serious injury or death, and no external risk control (hardware interlock, clinical workflow step) reduces that risk, you are in Class C. If an external measure mitigates the risk to non-serious injury, you may justify Class B.
Do not default to Class A to reduce paperwork. Auditors and reviewers will challenge your classification if the clinical context suggests otherwise. A well-reasoned classification, documented in your risk management file, saves time during review.
Understanding the cost implications of this rigor is useful during planning. Our breakdown of healthcare app development cost covers how regulatory requirements influence budget and timeline.
IEC 81001-5-1: Cybersecurity Is Now a Lifecycle Requirement
IEC 81001-5-1:2021 defines security lifecycle requirements for health software. Treat it as the working baseline for secure health software development, then verify the current recognition or harmonisation status for each target market with your regulatory team.
The FDA's updated cybersecurity guidance, finalized in February 2026, recommends that manufacturers address cybersecurity design, labeling, and premarket submission content for any device with cybersecurity risk. This guidance supersedes earlier versions and raises the bar for what reviewers expect in a 510(k) or De Novo submission.
What this means in practice:
- Threat modeling at the architecture phase, not as an afterthought before submission.
- Security risk assessment integrated with your ISO 14971 risk management process.
- Vulnerability management plan that covers your entire software supply chain, including open-source components.
- Patch and update strategy documented before market release.
- Secure development practices: static analysis, dependency scanning, penetration testing, and secure coding standards.
If your product handles protected health information in the U.S., HIPAA requirements layer on top of device cybersecurity standards. Our guide to HIPAA compliant app development covers the technical and administrative safeguards involved.
EU MDR Harmonised Standards: Verify Before You Assume
Teams targeting the European market must work with the EU MDR (2017/745) and the standards or technical evidence they use to support the General Safety and Performance Requirements. A common mistake is assuming that compliance with an ISO or IEC standard automatically satisfies the MDR's General Safety and Performance Requirements (GSPRs).
Harmonised standards are developed by CEN/CENELEC and listed by the European Commission. Only standards that appear on the current Official Journal listing provide a presumption of conformity. Standards can be added, removed, or have their harmonisation status changed. Your regulatory team must verify the current status of every standard you cite in your technical documentation.
The FDA maintains a separate database of recognized consensus standards for U.S. submissions. A Declaration of Conformity to a recognized standard can streamline FDA review, but only if the standard version matches what the FDA has recognized.
Documentation Checklist for Regulatory Readiness
This checklist covers the deliverables most commonly requested during regulatory submissions and audits. Tailor it to your device classification and target markets.
Quality system:
- Quality manual and QMS procedures (ISO 13485)
- Management review records
- CAPA procedure and log
- Supplier qualification records
- Training records for design and development staff
Risk management:
- Risk management plan (ISO 14971)
- Hazard analysis (FMEA, fault tree, or equivalent)
- Risk/benefit analysis
- Risk management report
- Post-market risk monitoring procedure
Software lifecycle (IEC 62304):
- Software development plan
- Software requirements specification
- Software architecture document
- Detailed design (Class C)
- Unit test records (Class B and C)
- Integration test records
- System test records
- Software release notes
- Problem resolution and change control records
Usability (IEC 62366-1):
- Use specification (intended users, use environments, user interface)
- Formative evaluation records
- Summative usability test protocol and report
Cybersecurity (IEC 81001-5-1 / FDA guidance):
- Threat model
- Security risk assessment
- Software bill of materials (SBOM)
- Vulnerability management plan
- Penetration test report
Clinical and regulatory:
- Clinical evaluation report (EU MDR)
- Predicate comparison or performance data (FDA)
- Labeling, including cybersecurity labeling
- Declaration of Conformity (if citing harmonised or recognized standards)
For teams scoping a new medical software product, our article on healthcare software product development walks through the planning stages where these documentation requirements should be mapped to your development timeline.
FAQ
Do I need ISO 13485 certification to sell a medical device in the U.S.?
The FDA does not require ISO 13485 certification. However, with the QMSR incorporating ISO 13485:2016 requirements effective February 2, 2026, your QMS must satisfy those requirements. Many manufacturers pursue certification because it simplifies audits and supports EU MDR compliance simultaneously.
Which standard should I start with?
Start with ISO 14971 (risk management) and IEC 62304 (software lifecycle). Your risk analysis determines your software safety class, which in turn determines the depth of your IEC 62304 documentation. ISO 13485 should already be in place as your organizational QMS before you begin design activities.
Does IEC 62304 apply to mobile health apps?
If your mobile app meets the definition of SaMD or is part of a medical device system, IEC 62304 applies. Wellness apps that do not make clinical claims are generally outside scope, but the boundary is determined by regulatory classification, not by the technology platform.
How does IEC 81001-5-1 relate to FDA cybersecurity requirements?
IEC 81001-5-1 provides a lifecycle framework for health software security. The FDA's February 2026 cybersecurity guidance aligns with many of the same principles but adds specific expectations for premarket submission content, labeling, and SBOM disclosure. Teams targeting both U.S. and EU markets benefit from using IEC 81001-5-1 as their baseline and layering FDA-specific requirements on top.
What happens if I cite a standard that is no longer harmonised under EU MDR?
You lose the presumption of conformity for the GSPRs that standard was meant to cover. You must then demonstrate conformity through other means, such as clinical data, bench testing, or expert assessment. Check the European Commission's harmonised standards listing before finalizing your technical documentation.
Planning Your Compliance Roadmap
Standards compliance is a project management problem as much as a technical one. The teams that reach the market on schedule are the ones that map standards requirements to their development milestones during planning, not during audit preparation.
Identify your target markets and device classification first. Build your QMS before you start design. Assign your software safety class based on a real risk analysis. Integrate cybersecurity from the architecture phase. And verify the harmonisation or recognition status of every standard you plan to cite.
If you are evaluating custom healthcare software solutions and need a development partner who understands the documentation burden that comes with regulated software, start the conversation at the scoping stage. Retrofitting compliance into a finished product costs two to five times more than building it in from the beginning.
