Medical Device Data Sovereignty: HIPAA, GDPR, and Hospital Reviews

Reviewed October 14, 2026

A hospital security reviewer asks a simple question: "Where is our patient data stored, and who can see it?" Many device teams cannot answer quickly. The device sends readings to a cloud service in one region, backups land in another, logs go to a monitoring tool, a support engineer in a third country can log in remotely, and an AI feature may call an outside service. Each of those is a place the data lives or travels. Each one can trigger a different law, and each one is a line in the hospital's questionnaire. A vague answer stalls the purchase. A wrong answer can become a contract problem later. The fix is not complicated: draw the data map once, tie it to your architecture views and threat model, and reuse it for every review.

Why This Matters

Hospitals buy devices through a security review, and data location is now a standard part of it. Health systems in the EU and UK face strict transfer rules, and many US health systems write data location and access terms into their contracts. Your FDA submission already asks for the information you need. The FDA's February 3, 2026 final premarket guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," expects architecture views showing the whole system, including cloud services and connections, plus a threat model that covers them. If those views show where data is stored and who can reach it, the same picture answers the hospital. Teams that skip this end up rebuilding the answer for every customer, often with different wording each time, which reviewers notice.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); MDCG 2019-16, Guidance on Cybersecurity for Medical Devices (European Commission); HHS HIPAA for Professionals.

Where Does Patient Data Actually Live?

Start with a list of every place your system stores or processes patient data. Most teams find more than they expected:

1. On the device. Stored readings, logs, cached settings, and anything kept when the network drops.
2. On the companion app. Phone storage, app caches, and crash reports.
3. In your cloud. The main database, plus its backups and disaster recovery copies, which are often in a different region.
4. In outside services. Logging and monitoring tools, email and text notification services, analytics, crash reporting, and AI services.
5. In support access. Engineers who can log in remotely to the device or cloud, and the country they work from.
6. In the hospital's systems. Data your device sends to the electronic health record or a gateway. This is usually the hospital's responsibility, but your interface should be documented.

For each place, record the country or cloud region, who operates it, what data it holds, whether that data identifies patients, and how it is protected in transit and at rest. If data is de-identified before it leaves, say how. Our post on de-identification vs anonymization under HIPAA and GDPR explains why the two laws treat this differently.

What Does HIPAA Require?

HIPAA applies to covered entities, such as hospitals, and to their business associates. A device maker becomes a business associate when it creates, receives, maintains, or transmits protected health information on a hospital's behalf, for example by running the cloud service that stores patient readings. A device that keeps all data inside the hospital's own network may not make you a business associate at all. Our post on HIPAA for medical device manufacturers covers that line in more detail.

HIPAA does not require patient data to be stored in the United States. The HHS guidance on cloud computing states that the rules do not prohibit storing data offshore, but the risk analysis should consider the risks of doing so. In practice, that means:

• Sign a business associate agreement with the hospital when you are a business associate, and with your own subcontractors who touch the data, such as your cloud provider.
• Include every storage location and access path in your HIPAA risk analysis.
• Apply the Security Rule safeguards everywhere the data goes: access control, audit logs, encryption, and integrity protection.
• Be ready to say which countries data and support access reach. Many hospitals restrict offshore access by contract even though HIPAA does not.

HIPAA is not the only US rule. The Department of Justice rule on access to bulk sensitive personal data, at 28 CFR Part 202, took effect April 8, 2025. It restricts certain transactions that give countries of concern, including China and Russia, access to bulk US health and genetic data. If any vendor, support team, or investor in your system is connected to those countries, have counsel review it. Some states also have their own health data laws, such as Washington's My Health My Data Act.

What Are the GDPR Transfer Rules?

If you sell in the EU, GDPR treats health data as a special category under Article 9, with stricter conditions for using it. Chapter V then limits sending personal data outside the European Economic Area. A transfer is allowed only through one of these routes:

1. Adequacy decision (Article 45). The European Commission has decided the destination protects data well enough. For the United States, the EU-US Data Privacy Framework adequacy decision of July 10, 2023 covers transfers to US companies that have self-certified under the Framework. It does not cover companies that have not certified.
2. Appropriate safeguards (Article 46). Most often the Commission's standard contractual clauses, adopted in June 2021. Since the Court of Justice's Schrems II ruling in July 2020, exporters using these clauses are expected to assess whether the destination's laws undermine them, often called a transfer impact assessment, and add extra measures such as encryption where needed.
3. Binding corporate rules (Article 47). Approved internal rules for transfers within one corporate group.
4. Derogations (Article 49). Narrow exceptions, such as explicit consent, meant for occasional transfers, not a device's routine data flow.

Two points catch device teams out. First, remote access counts: if a US support engineer can view data stored in an EU data center, regulators treat that as a transfer. Second, the UK has its own version of these rules. The UK extension to the Data Privacy Framework, often called the UK-US data bridge, has applied since October 12, 2023, again only for certified US companies.

See also: De-identification vs Anonymization: HIPAA & GDPR, CLIA Lab Cybersecurity: HIPAA & 21 CFR Part 11 (2026), and HIPAA and Medical Device Manufacturers.

The simplest design for EU customers is often to store and process EU patient data in an EU cloud region, limit support access from outside the EEA, and document the route for any access that remains. Whether that is enough depends on your contracts and setup, so confirm it with EU privacy counsel. Our GDPR medical device compliance service covers the records, DPIAs, and transfer documentation EU hospitals expect. This post is general information, not legal advice.

How Should You Answer Hospital Questionnaires?

Hospital questionnaires ask the same questions in different formats. The Manufacturer Disclosure Statement for Medical Device Security (MDS2) form, ANSI/NEMA HN 1-2019, asks about personally identifiable information the device stores or sends, remote service, and transmission confidentiality. Custom questionnaires add questions like "Name every country where our data is stored" and "Do any subcontractors access our data?" Answer them from one source:

• Build one data flow map. Base it on your security architecture views, adding the country or region for each store and access path.
• Keep a subprocessor list. Name each outside service, what data it gets, and where it runs. Update it when vendors change.
• Write standard answers. Draft short, accurate answers for storage location, backups, remote access, encryption, retention, deletion at contract end, and transfer routes. Reuse them word for word.
• Be precise, not hopeful. "Data is stored in the US East region, with backups in US West, and support access is limited to US staff" beats "Data is stored securely in the cloud." If something is not true yet, do not say it is.
• Offer regional options if you have them. If you can host EU customers in the EU, say so and say what still leaves the region.
• Link answers to evidence. Point to your threat model, pen test summary, and SBOM where questions touch them.

Our free MDS2 generator walks through the form's questions so you can prepare answers before copying them onto NEMA's official form. Our MDS2 post explains how hospitals use it.

How Blue Goat Approaches This

We treat data location as part of the security architecture, not a separate privacy exercise. In the threat model, every data store and remote access path is drawn with its location and trust boundary, and threats such as unauthorized remote access, exposed backups, and leaks through outside services are tied to patient-harm and privacy ratings. Our PHI cloud and backend penetration testing then checks those paths: cloud configuration, region settings, support access, and what outside services actually receive. The result is an architecture view and data map that serve both your FDA submission and hospital reviews. Our hospital security review journey shows how this supports FDA clearance and approval by the hospital together. We are not lawyers, so we work alongside your privacy counsel on the legal questions.

Need ongoing help answering hospital data questions? See our medical device security advisory.

Related reading: Hospital Security Questions for AI Medical Devices and How to Answer.

FAQ

CTA

Getting stuck on hospital questions about where your data lives? Book a free 30-minute discovery call. We'll review your architecture, data flows, and remote access, then send a fixed-fee proposal. Nothing is billed until you approve it.