A medical-connected device can be properly designed and yet not pass a compliance review by giving an incorrect response.

FDA and EU Medical Device Regulation (EU MDR) state whether a device can be marketed as a medical device or not. IEC 62304 manages the lifecycle of a medical device software. ISO 14971 establishes the whole process of safety risk management.

The IEC 60601 series tells about safety and essential performance of medical electrical equipment. HIPAA deals with medical information protected by Covered Entities and business partners in the USA. The GDPR manages the processing of personal data (including health data) in its territory.

Those regimes overlap, but they are not substitutes for one another. FDA clearance does not establish HIPAA compliance. CE marking under the MDR does not establish GDPR compliance. An IEC 62304 lifecycle does not, by itself, prove that a device is safe, clinically effective, electrically safe or legally marketable.

The useful way to view the stack is:

FDA and EU MDR: product regulation and market access;
IEC 62304: software lifecycle discipline;
ISO 14971: medical-device safety risk management;
IEC 60601 series: electrical safety, essential performance and applicable collateral or particular requirements;
HIPAA and GDPR: rules for particular health-data processing relationships and activities.

The rest of this guide turns that stack into an evidence plan a product team can actually use.

Medical IoT compliance matrix at a glance

Framework What it is Main question it answers Typical trigger for a medical IoT product Core evidence "Pass" or market outcome
FDA Binding U.S. statutes and regulations, supplemented by FDA guidance Is this a device software function, how is it classified, and what evidence is needed for lawful U.S. marketing and lifecycle control? A sensor, gateway, app or cloud function is intended to diagnose, cure, mitigate, treat or prevent disease, or otherwise meets the device definition Intended-use statement, classification rationale, quality-system records, risk analysis, software documentation, cybersecurity evidence, testing, labeling, clinical or performance evidence where needed Exemption or an appropriate FDA marketing pathway, such as 510(k), De Novo or PMA; plus ongoing compliance
IEC 62304 International consensus standard Is medical-device software developed and maintained through controlled lifecycle processes proportionate to possible harm? Software is itself a medical device or is embedded in, or integral to, a medical device Software development and maintenance plans, safety classification, requirements, architecture, unit/integration/system verification, problem-resolution and configuration records Conformity evidence; not independent FDA authorization or an EU CE mark
ISO 14971 International consensus standard How does the manufacturer identify hazards, estimate and evaluate risk, control risk and monitor it through the lifecycle? The product is a medical device, including software as a medical device Risk-management plan and file, hazard analysis, risk-control traceability, residual-risk evaluation, production and post-production feedback Documented risk-management conformity; the standard does not define a universal acceptable-risk level
IEC 60601 family International product-safety standards Does medical electrical equipment or a medical electrical system meet applicable basic-safety and essential-performance requirements? The product is medical electrical equipment or forms a medical electrical system; exact scope depends on architecture and intended use Test plan and accredited-lab reports, essential-performance rationale, EMC evidence, usability-related safety evidence, home-use or alarm evidence where applicable Test evidence used within a regulatory submission or conformity assessment; not a standalone market authorization
HIPAA U.S. federal privacy, security and breach-notification rules Is the organization a covered entity or business associate, and is the information PHI/ePHI handled for that regulated relationship? A device company or platform creates, receives, maintains or transmits PHI on behalf of a covered entity, or is itself a covered entity Risk analysis, policies, BAAs, access and audit controls, training, incident and contingency procedures, breach assessment and documentation Organizational compliance; there is no general government-issued "HIPAA-certified device" status
GDPR EU regulation on personal-data processing Is personal data processed lawfully, fairly, transparently and securely, with special conditions for health data? Processing concerns people in the EU or otherwise falls within the GDPR's territorial scope; connected-health data is commonly personal data and often health data Data map, controller/processor analysis, Article 6 basis and Article 9 condition, notices, records of processing, DPIA where required, processor terms, security and rights procedures Ongoing accountability for processing activities; not a product approval
EU MDR Binding EU medical-device regulation Is the product a medical device, what class applies, and can the manufacturer demonstrate safety, performance and lifecycle conformity for CE marking? The hardware or software has a medical intended purpose and is placed on the EU market or put into service Technical documentation, GSPR mapping, clinical evaluation, risk-management file, software and cybersecurity evidence, QMS, PMS/vigilance records, labeling and UDI evidence EU declaration of conformity and CE marking after the required conformity-assessment route; notified-body involvement depends on class and circumstances

Start with the product boundary, not the standard list

Most of the compliance waste is generated at the very beginning, even before the team starts working on a standard. The architecture diagram covers a wearable device, mobile app, API, clinician portal, and analytical software, but nothing has been decided on which functions make up the controlled device.

Preparatory work should be conducted in the form of a one-page product-boundary memo before the procedures for control assignment begin. The memo should contain the answers to the questions:

What is the purpose of the product?
Which users, patients, environments for use, and conditions are included?
Which hardware and software parts are used for the purposes of diagnosis, monitoring, or usage of the product?
Which functions are for convenience, administration, storing, or communication only?
What if a reading is incomplete, sent too late, or corrupted, and is used for a wrong patient?
Which system components can be changed after the product has been put to the market?
Who controls the purposes and means of processing each part of the personal data?
Who will be taking care of the PHI for a U.S. covered entity?
Which markets will the product be launched in?

While some apps may have functions that fall under regulations, many others may not. The U.S. regulations see fit to strictly regulate some software functions while choosing to classify some others as non-devices.

The main conclusion is that being categorized as "wellness" does not eliminate the need to take in consideration such elements as the diagnostic claims, course of treatment and actual technical specifications of the mobile app.

The seven-gate applicability test

Gate Question If yes If no
1. Medical purpose Does a function diagnose, prevent, monitor, predict, prognose, treat or alleviate disease or injury, or otherwise meet the relevant device definition? Perform FDA and EU qualification analyses separately Product law may still apply, but the function may be outside medical-device rules
2. U.S. market Will it be commercially distributed in the United States? Determine FDA classification, pathway, QMSR applicability and submission evidence FDA market authorization may not be in scope, though U.S. data and consumer-protection laws can remain relevant
3. EU market Will it be placed on the EU market or put into service there? Apply MDR qualification, classification, conformity assessment, economic-operator and post-market duties MDR may be out of scope; GDPR can still apply to EU-facing processing
4. Medical software Is software itself a device or part of one? Establish IEC 62304 lifecycle processes and jurisdiction-specific software documentation General software controls may still be needed, but IEC 62304 may not be the governing product standard
5. Electrical equipment/system Does the product fall within IEC 60601-1 or an applicable collateral/particular standard? Define essential performance and a test strategy early Do not force a pure cloud function into an electrical-equipment test program
6. U.S. regulated health-data relationship Is the organization a HIPAA covered entity or business associate, and is the information PHI/ePHI in that relationship? Apply the Privacy, Security and Breach Notification Rules as applicable Do not declare a legal vacuum; assess FTC, state and contractual requirements
7. EU personal data Does the processing fall within GDPR scope? Determine roles, lawful basis, Article 9 condition, transparency, rights, DPIA, security, retention and transfer controls Document the territorial and data analysis; other privacy laws can still apply

What each framework contributes

1. FDA: U.S. device status, submission and total-product-lifecycle control

For FDA evaluation, the basis for the assessment is not the nomenclature of the device, but the primary purpose and risk analysis irrespective of the fact whether the device is referred to as IoT Devices. The usage of connected scales for general fitness purposes is not similar to the evaluation of the same devices for making decisions about heart failure treatments.

If the device is in the regulation category, it should be classified into product classes with a suitable marketing path. The 510(k) generally aims at establishing whether the new device is similar to any legally approved and marketable device.

The De Novo procedure helps to register certain devices with no appropriate equivalent examples.

Class III devices are mostly included in PMA unless specified otherwise.

A number of devices classified as low-risk do not have to go through pre-market notification though this does not eliminate their need to comply with the rules set by the FDA.

The Quality Management System Regulation started using ISO 13485:2016 on February 2, 2026.

This matters to teams working from older checklists that still treat the former Quality System Regulation wording as the current baseline.

For software submissions, FDA's June 2023 guidance describes the recommended documentation for device software functions.

The appropriate documentation level depends on the risk of a hazardous situation resulting from a software failure, not simply on the number of lines of code or whether software runs in the cloud.

FDA evidence package for a connected device

Depending on pathway and product, a defensible package commonly includes:

clear intended use, indications, users and use environments;
device description and system-context diagrams;
regulatory classification and predicate strategy, if applicable;
software requirements specification and architecture;
software hazard analysis and risk-control traceability;
development, configuration, maintenance and problem-resolution records;
verification and validation results, including abnormal and degraded conditions;
interoperability, wireless coexistence and data-integrity evidence;
human-factors evidence for safety-critical use;
electrical-safety and EMC reports where applicable;
clinical or performance evidence where required;
cybersecurity threat modeling, security architecture and testing;
software bill of materials (SBOM) for relevant components;
labeling, installation assumptions and update/support information;
complaint, corrective and preventive action, medical-device reporting and recall processes.

FDA cybersecurity is now a statutory as well as design issue

Section 524B of the Federal Food, Drug, and Cosmetic Act applies to premarket submissions for a "cyber device."

At a high level, that means a device that includes software, can connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats.

FDA interprets software broadly enough to include firmware and programmable logic and considers devices able to connect directly or indirectly, including where connection may occur unintentionally.

The statutory package has provisions for monitoring, detecting, and dealing with post-market vulnerabilities and exploits, making post-market updates and patches available, design processes, and lifecycle processes providing reasonable cybersecurity assurance and SBOM for commercial and open-source software components.

In February 2026, FDA released the new version of the pre-market cybersecurity guidance. It replaces the 2025 edition and takes into account the terminology used in QMSR. The product team relying on the old version of a PDF dated 2023 or 2025 should check if it has the latest version..

The takeaway is that cybersecurity can't be limited to a penetration-test report prepared just before submission. The aspects of security requirements, trust boundaries, the ability to be updated, key management, logging, and recovery/support planning need to be part of design controls and risk management.

2. IEC 62304: the medical-device software lifecycle

IEC 62304 defines lifecycle processes for medical-device software, whether software is the device or is embedded in, or integral to, a medical device.It is not a general claim that every line of code is safe, and it does not replace final validation of the medical device.

The standard's practical value is repeatability. It asks a team to control how software is planned, specified, architected, implemented, integrated, tested, released, maintained and corrected. It also connects software work to risk management, configuration management and problem resolution.

Software safety classification

IEC 62304 uses three software safety classes. In simplified terms:

Class Simplified consequence model Practical effect
A No injury or damage to health is possible from a software failure Least extensive set of lifecycle activities under the standard
B Non-serious injury is possible More lifecycle rigor and evidence
C Death or serious injury is possible Most extensive lifecycle rigor and evidence

This table is only an orientation. Classification involves the contribution of software to hazardous situations, risk controls external to the software and the exact requirements of the licensed standard and applicable amendment. Do not classify by intuition or by copying the device's regulatory class. A Class II FDA device is not automatically IEC 62304 Class B, and an EU Class IIa device does not mechanically produce a particular software safety class.

Evidence auditors and reviewers expect to connect

An IEC 62304 file should tell a coherent story:

the software development plan identifies activities, responsibilities, deliverables and tools;
system and safety inputs flow into testable software requirements;
the architecture identifies items, interfaces, segregation and risk-control mechanisms;
units and integrations are verified at the required rigor;
anomalies are assessed, tracked and justified before release;
configuration records identify exactly what source, dependencies, build environment and binaries constitute the release;
maintenance and problem-resolution processes continue after launch;
changes trigger impact analysis across requirements, risk, tests, cybersecurity and regulatory status.

The software item chart for cloud-connected devices ought to consider device firmware, mobile software, backend services, and portal logic that is clinically useful. Dependence upon only the embedded firmware as medically relevant software may mean that critical safety-determining changes in the cloud are unregulated.

The FDA recognizes IEC 62304:2006 with Amendment 1:2015 through its consensus-standards program and under U.S. recognition records.

While recognition enables to make the declaration of conformity when needed, it does not render the rules applicable in every submission, nor does it imply approval of papers that contain insufficient proofs. In the European Union, please verify the current references and requirements in the Official Journal prior to asserting presumption of conformity.

3. ISO 14971: safety risk from concept through post-market operation

ISO 14971:2019 provides the process for medical-device risk management across the lifecycle.The manufacturer identifies hazards, estimates and evaluates associated risks, controls those risks and monitors the effectiveness of controls using production and post-production information.

The standard deliberately does not set one universal level of acceptable risk. The manufacturer must define objective risk-acceptability criteria within its policy and apply the required decision process. ISO/TR 24971:2020 provides non-mandatory implementation guidance.

A useful medical IoT risk chain

Risk analysis is strongest when it separates events instead of writing a vague row such as "hacker harms patient." A traceable chain looks like this:

Expired cloud certificate → device cannot authenticate to service → readings queue locally → clinician dashboard displays stale status without a clear age indicator → deterioration is not reviewed in time → delayed intervention causes harm.

That chain supports controls in several places:

certificate-expiry monitoring and renewal;
a safe local queue with bounded storage;
visible data-age and last-sync indicators;
alarm behavior for missing telemetry;
operational monitoring and escalation;
verification of clock drift, outage and recovery;
labeling about loss of connectivity and expected clinical response.

Security risk and safety risk are related but not identical. A threat model may rank likelihood using attacker capability and exposure; the ISO 14971 file focuses on harms to people and applicable property or environment concepts. When a cybersecurity event can create a hazardous situation, link the security analysis to the safety-risk file rather than pasting one scoring scheme into the other.

The risk-management file is a living index

A credible file should connect:

intended use and reasonably foreseeable misuse;
characteristics related to safety;
hazards, sequences of events, hazardous situations and harms;
initial risk estimates;
risk-control option analysis;
implementation and effectiveness verification;
residual-risk evaluation and, where required, benefit-risk analysis;
evaluation of overall residual risk;
the risk-management report;
production and post-production signals.

Complaint trends, incident reports, vulnerability disclosures, fleet telemetry, update failures and third-party component advisories are not separate from risk management. They are inputs that can change occurrence estimates, uncover new sequences of events or show that a control is less effective than assumed.

FDA recognizes ANSI/AAMI ISO 14971:2019 in its consensus-standards database.[For EU work, verify the harmonized EN adoption and Official Journal status relevant to the device and date rather than assuming the ISO edition alone creates a presumption of conformity.

4. IEC 60601: basic safety and essential performance of connected medical electrical systems

IEC 60601-1 applies to medical electrical equipment and medical electrical systems within its scope and establishes general requirements for basic safety and essential performance. It is a family, not a single universal test.

Connected-device teams commonly need to evaluate:

IEC 60601-1: general requirements;
IEC 60601-1-2: electromagnetic disturbances and emissions;
IEC 60601-1-8: alarm-system requirements where applicable;
IEC 60601-1-11: equipment and systems intended for the home healthcare environment;
an applicable particular standard for the device type.

Collateral and particular standards can supplement or modify the general standard. IEC itself warns that 60601-1 should not be used alone where a relevant particular standard exists.

How does connectivity affect the safety test approach

Wireless connections open up several failure modes that traditional bench tests on standalone equipment would not catch:

loss, duplication, reordering, or delay of information;
radio interference and coexistence issues;
corrupted settings or calibration data;
unsafe operation after a system reboot;
problems with time synchronization;
alarm floods or silent alarms;
failure of remote commands and/or confirmations;
battery drain by repeated attempts to communicate;
impact of software modification on functionality.

The IEC 60601-1-2 standard states EMC requirements and testing and requires taking into account the environment of use.

The IEC 60601-1-11 standard expands the requirements related to the home healthcare environment, which can be unsafe due to the involvement of patients in the operation process and due to the specific conditions like power, quality of the network, temperature conditions, condition of the equipment storage, and electromagnetic environment, which are different from hospitals.

Define "essential performance" early. If a product's safety depends on measurement accuracy, alarm timing, a therapy limit or a safe state during communication loss, that dependency should be visible in requirements, risk controls and test acceptance criteria. A lab cannot infer the clinical consequences of a failure that the manufacturer has never defined.

FDA's recognized-standards database lists IEC 60601-1 Edition 3.2 and identifies U.S. national differences and recognition details. Always check the current recognition record, applicable collateral and particular standards, testing-laboratory scope and transition dates before freezing a certification plan.

5. HIPAA: relationship-based protection of PHI, not a blanket "health app law"

HIPAA is often inappropriately defined as being exceedingly broad. The rules themselves apply to covered entities and business associates. Thus, if an organization is not one of the two categories, HIPAA does not apply simply because the product accommodates health-related data.

Covered entities include health plans, healthcare clearinghouses, and healthcare providers that conduct specified electronic transactions. A business associate generally performs certain functions or services for a covered entity involving the creation, receipt, maintenance, or transmission of PHI.

Business associates can be directly liable for specified HIPAA duties, and appropriate business associate agreements are required in covered relationships.

A device vendor's role is factual. HHS explains that merely selling software to a covered entity does not create a business-associate relationship when the vendor has no access to the covered entity's PHI.

If the vendor needs such access to provide its service, it would be a business associate.Similarly, not every disclosure to a medical-device company makes that company a business associate; the purpose and relationship matter.

HIPAA Security Rule controls that matter to medical IoT

For ePHI, the currently effective Security Rule requires reasonable and appropriate administrative, physical and technical safeguards. Core duties include:

an accurate and thorough risk analysis;
risk management to reduce risks and vulnerabilities to a reasonable and appropriate level;
an assigned security official;
workforce access and training controls;
security-incident procedures;
contingency planning and data recovery;
periodic technical and non-technical evaluation;
facility, workstation, device and media controls;
access control, audit controls, integrity, authentication and transmission security;
written policies, procedures and evidence of required actions.

"Addressable" implementation specifications are not optional. A regulated entity must determine whether an addressable specification is reasonable and appropriate; if it is not, it must use a reasonable and appropriate alternative when applicable and document the decision.

HHS's Security Rule summary was reviewed on 7 August 2026 and explicitly distinguishes the rule currently in effect from OCR's proposed cybersecurity modifications. The proposal may influence planning, but it should not be presented as final law.

HIPAA documentation required by the Security Rule must generally be retained for six years after the later of creation or the date it last was in effect.Device technical records can have different retention periods under FDA or EU rules, so a unified document-retention schedule should preserve the longest applicable requirement for each record category.

If HIPAA does not apply

"Not HIPAA" is not the same as "unregulated." The FTC's Health Breach Notification Rule covers certain vendors of personal health records, PHR-related entities and service providers not covered by HIPAA.

The 2024 amendments clarify the rule's relevance to many health apps and connected technologies.State privacy, health-data, biometric, consumer-protection and breach laws may also apply and are outside the scope of this matrix.

6. GDPR: accountability for the data operation

The GDPR applies to processing of personal data within its material and territorial scope, including in some cases organizations outside the EU offering goods or services to, or monitoring the behavior of, people in the EU.Identifiable readings, device identifiers, account data, location, usage patterns and inferences can all be personal data. Health data is a special category of personal data.

For health-data processing, a controller generally needs both an Article 6 lawful basis and an applicable Article 9 condition. "The user agreed to the terms" is not a substitute for that analysis. Consent can be valid in the right circumstances, but it is not automatically the best or only basis, and GDPR consent must meet specific conditions.

Roles of processors and controllers abide by the facts.

The controller defines the purpose of processing and the essential means of it. The processor operates on behalf of controller based on its documented instructions.

An IoT medical provider might be:

a processor of hosting and supporting provided by hospitals;
an independent controller for its own purposes, safety monitoring or direct patient provision;
a joint controller for genuinely common processing activity;
and various characteristics for different data usages on the same platform.

The use of contract terms helps to formalize the agreement but does not influence on the actual decision-making.

GDPR evidence for connected-health products

Obligation Practical evidence
Lawfulness and special-category condition Written purpose-by-purpose Article 6 and Article 9 analysis
Fairness and transparency Layered patient/user notices aligned with actual telemetry and recipients
Purpose limitation Data-use rules separating care delivery, safety monitoring, analytics, research and marketing
Data minimization Field-level justification, collection defaults and disabled unnecessary telemetry
Accuracy Sensor-quality controls, correction workflows, provenance and time stamps
Storage limitation Event- and purpose-based retention schedule plus tested deletion or anonymization workflows
Privacy by design/default Architecture decisions, default settings, design reviews and test evidence
Security Risk-based technical and organizational measures, incident response and supplier controls
Data-subject rights Identity verification and workflows for access, correction, erasure, restriction, objection and portability where applicable
Processor governance Article 28 terms, subprocessor records, instructions and assurance evidence
High-risk processing DPIA and prior consultation where residual high risk requires it
International transfers Transfer map, adequacy or safeguards such as applicable SCCs, plus supplementary analysis where needed
Accountability Records of processing, decisions, approvals, training and recurring review

A data protection impact assessment is required where processing is likely to result in high risk to individuals' rights and freedoms.

Connected medical monitoring can combine sensitive data, systematic observation, vulnerable people, new technology and consequential decisions; that combination deserves an early DPIA screening, not a form completed after launch.

The GDPR also requires data protection by design and by default and risk-appropriate security measures.

A strong medical IoT implementation may include device identity, least privilege, tenant isolation, cryptographic protection, secure update, auditability, resilience, restore testing and disciplined vulnerability handling. But controls must also serve privacy principles: a perfectly encrypted data field can still be unlawfully collected or retained.

When a personal-data breach occurs, the controller must assess notification duties. Article 33 sets a 72-hour supervisory-authority notification rule where the legal threshold is met; processor-to-controller notification is required without undue delay.

That clock is not identical to HIPAA breach timing, FDA medical-device reporting or MDR vigilance timelines. Use one incident playbook with jurisdiction-specific branches.

7. EU MDR: CE marking, clinical evidence and post-market accountability

The EU MDR regulates medical devices placed on the EU market or put into service. For software, qualification and classification depend heavily on intended purpose. The fact that code is delivered through an app store, browser or cloud service does not remove it from medical-device analysis. The June 2025 revision of MDCG 2019-11 confirms that medical-device software is classified in the same way regardless of its location or type of interconnection with hardware.

MDR Rule 11 Explained Simply

When it comes to software used in medical devices, MDR Rule 11 is about how software is classified:

any software that is responsible for providing information that influences diagnosis or treatment is usually considered Class IIa;
but the classification class increases to Class IIb if a wrong decision can lead to a big problem or require surgical intervention;
making a wrong decision will mean that the classification is Class III if life is at risk;
if the software is used to monitor physical functions, it will be considered as Class IIa;
monitoring the physical functions in cases where the change in ___ could cause any imminent danger will raise the classification to Class IIb;
other types of software can be classified as Class I.

The explanation given here is only the summary and does not represent a classification opinion. The result can be changed by the other regulations, implementation provisions, accessories, modules, closed-loop functions and the definite usage.

MDR manufacturer evidence

A manufacturer must build a technical file that demonstrates conformity with applicable general safety and performance requirements (GSPRs). For a connected product, it commonly includes:

device description, variants, accessories and intended purpose;
qualification and classification rationale;
design and manufacturing information;
GSPR checklist with methods and evidence;
risk-management documentation;
clinical evaluation and post-market clinical follow-up where applicable;
software lifecycle, usability and verification/validation evidence;
cybersecurity architecture, risk analysis, testing and update processes;
labeling, instructions and minimum IT/network requirements;
UDI and registration evidence;
post-market surveillance plan and report or periodic safety update report, as applicable;
vigilance and field-safety-corrective-action procedures;
declaration of conformity and notified-body certificates where required.

Class I devices can often follow manufacturer self-declaration, subject to important exceptions. Class IIa, IIb and III devices generally require notified-body involvement. The conformity route, sampling, clinical evidence and surveillance intensity rise with classification and product characteristics.

MDR Annex I specifically addresses software lifecycle, risk management including information security, verification and validation, minimum hardware/network/IT security requirements, and protection against unauthorized access for relevant devices.

The Commission's cybersecurity guidance connects those requirements to secure design, technical documentation, post-market surveillance, vulnerability handling and updates.

MDR cybersecurity and GDPR privacy must be coordinated, not collapsed. The MDR focuses on device safety and performance, the GDPR regulates personal-data processing and rights. A vulnerability that exposes patient records can engage GDPR even when it does not create a medical-device safety risk.

A denial-of-service condition can create a serious clinical risk even when no personal data is disclosed.

Lifecycle control matrix: who owns what

The table below is an implementation map, not a clause-by-clause conformity checklist.

Lifecycle activity FDA IEC 62304 ISO 14971 IEC 60601 HIPAA GDPR EU MDR
Intended purpose and claims Determines device status, classification and pathway Defines software scope and inputs Establishes use context and foreseeable misuse Defines intended users and environments relevant to safety Defines whether PHI is handled in a regulated relationship Defines processing purposes and transparency Determines qualification, classification and conformity route
System architecture Device description, boundaries and submission evidence Software items, interfaces, segregation and lifecycle controls Shows where hazards arise and controls operate Identifies ME equipment/system and essential-performance dependencies Locates ePHI and access points Supports data minimization, roles, transfers and privacy by design Supports GSPR, technical documentation and cybersecurity evidence
Risk management Benefit-risk and quality-system expectations Software contribution to hazardous situations Primary medical-device safety-risk process Safety and essential-performance risks Confidentiality, integrity and availability risks to ePHI Risks to individuals' rights and freedoms Lifecycle risk management and clinical-risk integration
Software development Premarket documentation and QMSR records Primary lifecycle framework Risk controls become software requirements Programmable-system functions can affect safety Secure development supports safeguards Secure and privacy-preserving design supports Articles 25 and 32 State-of-the-art development, verification and technical evidence
Verification and validation Supports safety, effectiveness and submission claims Unit, integration, system and release evidence Confirms control implementation and effectiveness Lab and product tests for applicable requirements Evaluations and control-effectiveness evidence Testing supports accountability and security GSPR, clinical, software and cybersecurity conformity evidence
Supplier/open-source control Purchasing/QMS records, OTS assessment and SBOM where applicable SOUP/configuration/problem management Supplier failures and component risks Critical components and test configuration BAAs and vendor risk where roles apply Processor/subprocessor contracts and assurance Supplier control, technical file and QMS evidence
Release and change Submission impact, labeling, QMSR and change-control analysis Release, maintenance, configuration and problem resolution New risks and control effectiveness Regression where safety/essential performance may change Security evaluation and documentation updates DPIA, notice, lawful-basis and rights impact Significant-change, certificate and technical-file assessment
Post-market monitoring Complaints, MDR reports, corrections/recalls, cyber vulnerability processes Maintenance and problem-resolution records Production/post-production information Field evidence can reopen safety conclusions Incident and breach processes Breach, rights, processor and security response PMS, PMCF, vigilance, trend reporting and FSCA

A reference evidence architecture

Teams do not need seven disconnected documentation systems. They need one controlled evidence model with distinct regulatory views.

Evidence object Minimum useful content Reused by
Intended-purpose record Medical purpose, patient population, users, environment, indications, contraindications and claims FDA, MDR, IEC 62304 scope, ISO 14971, IEC 60601, privacy notices
System context and data-flow model Device, app, cloud, portal, identities, interfaces, external systems, data categories and jurisdictions All seven frameworks
Regulatory applicability memo Function-by-function U.S./EU status, classification and data-law roles FDA, MDR, HIPAA, GDPR
Safety-risk file Hazards through residual risk and post-market feedback ISO 14971, FDA, MDR, IEC 62304, IEC 60601
Security-risk file Assets, threats, attack paths, security risks, controls, residual risk and monitoring FDA cyber, MDR cyber, HIPAA, GDPR; linked to ISO 14971 when patient harm is possible
Privacy assessment/DPIA Purposes, data, roles, lawful bases, necessity, proportionality, rights risks and mitigations GDPR; useful for HIPAA and broader privacy governance
Software lifecycle file Plans, requirements, architecture, code/configuration identity, tests, anomalies and maintenance IEC 62304, FDA, MDR
Product-safety test file Essential performance, standards plan, lab configuration, deviations and reports IEC 60601, FDA, MDR
Clinical-evidence file Clinical claims, evaluation plan, data appraisal, conclusions and post-market evidence FDA pathway as relevant, MDR
Component/SBOM register Versions, suppliers, licenses, known vulnerabilities, support status and device exposure FDA cyber, MDR cyber, IEC 62304, ISO 14971
Release dossier Approved versions, hashes, build provenance, test status, open anomalies, labeling and deployment plan FDA, IEC 62304, ISO 14971, MDR
Post-market signal register Complaints, adverse events, incidents, vulnerabilities, trend data, CAPA and field actions FDA, ISO 14971, IEC 62304, HIPAA, GDPR, MDR

The key is traceability. A reviewer should be able to move from a claim to a hazard, from a hazard to a requirement, from a requirement to a control, from a control to a test, and from the released control to post-market monitoring.

Worked example: a connected home cardiac monitor

Consider a hypothetical patch that measures rhythm, sends data through a patient's phone to a cloud service and highlights suspected events for clinician review. The portal does not directly administer therapy.

Product and data assumptions

The manufacturer claims the system detects and presents clinically relevant rhythm events.
The patch and mobile app can cache data during outages.
The cloud algorithm prioritizes episodes for clinician review.
A U.S. clinic subscribes to the service; the vendor hosts patient accounts and telemetry.
The system is also offered to hospitals in EU member states.
Patients use the product at home.

How the frameworks attach

Framework Likely issue to resolve Example evidence—not a final legal conclusion
FDA The diagnostic/monitoring functions are likely device functions; classification and pathway depend on intended use and product code Classification memo, predicate or De Novo strategy, software and cybersecurity documentation, performance evidence, QMSR records
IEC 62304 Patch firmware, mobile transfer logic, backend episode processing and portal presentation may all contribute to the medical function Software-item map, safety classes, requirements and verification across the end-to-end data path
ISO 14971 False negatives, false positives, delay, misassociation, data corruption, skin injury and foreseeable misuse require analysis Hazard chains, risk controls, residual-risk decisions and post-market measures
IEC 60601 The patch hardware and system may be within applicable medical electrical standards; home use and EMC matter Essential-performance definition, 60601-1/1-2/1-11 and applicable particular-standard strategy
HIPAA Hosting telemetry for the U.S. clinic likely creates business-associate functions BAA, subcontractor flow-down, risk analysis, access/audit/integrity controls, incident and contingency processes
GDPR The EU service processes personal and health data; roles may differ by purpose Article 6/9 analysis, controller/processor map, notices, DPIA, Article 28 terms, rights and transfer controls
EU MDR The intended monitoring and decision-support purpose likely makes the system medical-device software/hardware; Rule 11 and other rules require analysis Qualification/classification memo, technical documentation, clinical evaluation, QMS, CE route, PMS and vigilance plan

One risk, seven views

Suppose an update causes the phone app to display "sync complete" even though the most recent six hours of patch data remain queued.

FDA: Was the defect prevented or detected through design, software validation and change controls? Does it require a report, correction, recall or submission assessment?
IEC 62304: Were the requirement, integration test, anomaly evaluation, release decision and problem-resolution process adequate?
ISO 14971: Can stale data cause a delayed review and harm? Was the data-age control effective, and does field evidence change residual risk?
IEC 60601: Does the failure affect defined essential performance or alarm behavior of the equipment/system?
HIPAA: Is ePHI availability or integrity affected? Was the incident assessed, documented and reported under applicable agreements and breach rules?
GDPR: Is there a personal-data breach or an availability/integrity risk to individuals? Are controller, processor and supervisory-authority steps triggered?
EU MDR: Does the malfunction meet vigilance thresholds or require a field safety corrective action, and must technical and post-market files be updated?

One engineering defect produces different legal questions, decision owners and clocks. That is why an incident record needs a common technical fact base plus separate regulatory determinations.

Twelve mistakes that repeatedly delay medical IoT programs

01

"The hospital follows the HIPAA compliance rules, so our device follows them too."

HIPAA compliance applies to organizations, processes, data and functions. Just because a hospital is compliant doesn't mean a vendor is. Confirm whether or not the seller is a business partner and what software handles the patient's information.

02

"It is given the CE mark, meaning it is compliant with GDPR."

The CE mark under European MDR shows that the device is compliant with its requirements. However, the GDPR calls for totally different analysis of processing, responsibility, legal basis, transparency, rights and accountability.

03

"We comply with IEC 62304, so our product meets the FDA software requirements.

IEC 62304 is a good source of information for improving the life cycle of the device but this documentation is just one part of FDA submissions that should be embedded into risk, classification, pathway, device description and any other aspects that the FDA requires.

04

"The electrical lab will decide essential performance"

The manufacturer must define the clinically grounded safety functions and acceptance criteria. Late definitions create repeat tests and design changes.

05

"Encryption means privacy compliance"

Encryption helps security. It does not establish purpose limitation, a lawful basis, an Article 9 condition, data minimization, transparent notices, rights handling or lawful transfers.

06

"Addressable HIPAA controls are optional"

They are not. The regulated entity must assess them and implement the specification or an appropriate alternative when permitted, with documentation.

07

"The device regulatory class equals the IEC 62304 safety class"

They use different classification logic. Document each analysis independently and connect them through hazards and software contribution.

08

"Penetration test is part of cybersecurity program"

Penetration testing is one type of verification. It does not supersede threat modeling, secure design, component level governance, planning for updates, continuous monitoring, responsible disclosure, and post market response.

09

"Medical devices have only firmware as software"

Cloud computing and portable tools can manipulate, sort, or provide clinical data. It is necessary to map the entire medical application prior to establishing the limits of 62304.

10

"All open source software is dealt with according to the SBOM"

SBOM is only a list. Other processes still have to be done like monitoring, threat assessment, decision making on remediation, oversight of licensing and confirmation of availability of support.

11

"A proposed rule is already enforceable"

Proposals are important planning signals, not final law. This is particularly relevant to the proposed HIPAA Security Rule modifications that HHS still distinguishes from the rule in effect as of August 2026.

12

"A successful launch ends the compliance project"

Medical-device and data-protection regimes impose continuing duties. Complaints, clinical evidence, vulnerabilities, breaches, suppliers, software changes and field actions keep the evidence system active.

Audit-ready checklist

Scope and governance

Intended purposes and respective claims being applied in labeling, website, app stores and sales materials are approved.
Device qualification/classification decisions in the U.S. and the EU are being documented.
Boundaries of devices, software modules, systems and data processing are clear.
HIPAA-covered-entity/business-associate has been checked out for every U.S. material relationship.
GDPR controller, processor or joint-controller roles are drawn up based on purpose.
Applicable standards editions, amendments and harmonization/recognition status with the relevant transition dates are recorded.
Regulatory, quality, safety, security, privacy and clinical owners are defined by approving authority.

Engineering and safety evidence

Software lifecycle plans and safety classifications are approved.
Requirements cover normal, abnormal, degraded and recovery behavior.
Architecture identifies trust boundaries, safety partitions and external dependencies.
Risk controls trace to implementation and effectiveness tests.
Essential performance is clinically justified.
Applicable 60601 collateral and particular standards are identified.
End-to-end data integrity, timing and patient association are verified.
Configuration and release records can reproduce each marketed version.

Security and vendor mates

Threat frameworks include different types of devices like mobile devices, clouds, portals, updates, and handling.
Identity of device/service and encryption keys are given the correct sequence of operations.
Update process should be verified and be recoverable under any disturbance.
SBOMs need to match released builds with affected product queries.
Vulnerabilities monitoring includes commercial, open-source and embedded components.
Vulnerability disclosure must be improved through data transfer techniques and customer communication.
Supplier agreements must include standards for security, confidentiality, availability, modification, evidence, etc.

HIPAA and GDPR

Every data field and recipient has a documented purpose.
U.S. PHI/ePHI and EU personal/health data are identified in the data-flow map.
BAAs and HIPAA subcontractor flow-downs are complete where required.
Article 6 lawful bases and Article 9 conditions are documented by processing purpose.
Transparency notices match actual telemetry, analytics and disclosures.
DPIA screening is recorded; a DPIA is completed where required.
Retention, deletion, correction and access workflows are technically tested.
International-transfer mechanisms and transfer risks are reviewed.
Incident playbooks contain correct notification decision points and clocks.

Market and post-market operations

FDA submission or exemption rationale is complete, where applicable.
MDR technical documentation, clinical evaluation, QMS and conformity route are complete, where applicable.
Labeling states network, hardware, software and security assumptions needed for safe use.
Complaint, vigilance, medical-device reporting, breach and field-action pathways are assigned.
PMS inputs include cybersecurity and privacy signals as well as clinical complaints.
Changes trigger safety, security, privacy and regulatory impact assessment.
End-of-support and end-of-life controls address deployed devices and retained data.

Final takeaway

Medical IoT compliance isn't about gathering up badges. It's about mastering the art of stability, maintaining a healthy balance among the clinical claims made, the regulated product employed, the software solution used, and the data processing applied.

Particularly successful compliance programs share three important features.

First of all, they ensure that the definition of the product's scope precedes the classification.

Then they understand that safety, security, and privacy are not interchangeable, and at last but not least, they make sure that all the major findings directly relate to the product itself and its evidential support after the product has been released.

That approach does more than prepare a submission or audit. It makes failures easier to detect, updates safer to ship and clinical promises easier to defend.

Primary sources and official references

The links below were checked during the 25 August 2026 review. Standards are copyrighted documents; official catalogue pages identify scope and editions, while implementers should obtain the licensed text.

U.S. Food and Drug Administration, Policy for Device Software Functions and Mobile Medical Applications.
U.S. Food and Drug Administration, Device Software Functions Including Mobile Medical Applications.
European Commission, MDCG 2019-11 Rev. 1: Qualification and Classification of Software under the MDR and IVDR.
U.S. Food and Drug Administration, Quality Management System Regulation (QMSR).
U.S. Food and Drug Administration, Content of Premarket Submissions for Device Software Functions.
U.S. Food and Drug Administration, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026).
International Electrotechnical Commission, IEC 62304:2006+A1:2015—Medical Device Software, Software Life Cycle Processes.
U.S. Food and Drug Administration, Recognized Consensus Standard: IEC 62304.
European Commission, Harmonised Standards for Medical Devices.
International Organization for Standardization, ISO 14971:2019—Application of Risk Management to Medical Devices.
International Organization for Standardization, ISO/TR 24971:2020—Guidance on the Application of ISO 14971.
U.S. Food and Drug Administration, Recognized Consensus Standard: ANSI/AAMI ISO 14971:2019.
International Electrotechnical Commission, IEC 60601-1:2005+A1:2012+A2:2020—General Requirements for Basic Safety and Essential Performance.
International Electrotechnical Commission, IEC 60601-1-2:2014+A1:2020—Electromagnetic Disturbances.
International Electrotechnical Commission, IEC 60601-1-11:2015+A1:2020—Home Healthcare Environment.
U.S. Food and Drug Administration, Recognized Consensus Standard: IEC 60601-1 Edition 3.2.
U.S. Department of Health and Human Services, Covered Entities and Business Associates.
U.S. Department of Health and Human Services, Business Associates.
U.S. Department of Health and Human Services, Is a Software Vendor a Business Associate?.
U.S. Department of Health and Human Services, When a Medical Device Company Is Not a Business Associate for Certain Disclosures.
U.S. Department of Health and Human Services, Summary of the HIPAA Security Rule.
U.S. Department of Health and Human Services, HIPAA Security Rule Notice of Proposed Rulemaking—Fact Sheet.
U.S. Federal Trade Commission, Health Breach Notification Rule.
EUR-Lex, Regulation (EU) 2016/679—General Data Protection Regulation.
European Data Protection Board, Data Protection Basics: Special Categories Including Health Data.
European Commission, When Is a Data Protection Impact Assessment Required?.
European Data Protection Board, Guidelines 4/2019 on Data Protection by Design and by Default.
EUR-Lex, Regulation (EU) 2017/745 on Medical Devices.
European Commission, MDCG 2019-16 Rev. 1: Guidance on Cybersecurity for Medical Devices.
European Commission, MDCG-Endorsed Documents and Other Medical-Device Guidance.
U.S. Food and Drug Administration, Recognized Consensus Standards Database.
Electronic Code of Federal Regulations, 45 CFR Part 164—Security and Privacy.
International Electrotechnical Commission, IEC 60601-1-8:2006+A1:2012+A2:2020—Alarm Systems.