Is HIPAA Only for US Sites? What Non-US Operators Need to Know
HIPAA is not limited to US-hosted websites, but it only binds organizations that are Covered Entities or Business Associates under 45 CFR § 160.103, so a website or SaaS operated entirely outside the US, with no US healthcare customers, has no HIPAA obligations regardless of where its servers sit. The moment that same company signs a contract to handle protected health information (PHI) for a US clinic, it becomes a Business Associate and HIPAA applies in full. For founders outside the US, the question is not geography. It is customer relationships.
TL;DR: Quick answer
- HIPAA attaches to entity status under 45 CFR § 160.103, not to hosting location, domain, or audience nationality; a Berlin-hosted patient portal run by a US Covered Entity is fully regulated, while a US-hosted wellness blog run by a German company is not.
- A non-US vendor that creates, receives, maintains, or transmits PHI for a US Covered Entity is a Business Associate and must sign a BAA under 45 CFR §§ 164.308(b) and 164.504(e), with direct Security Rule liability.
- HHS OCR can levy civil money penalties up to $73,011 per violation and $2,190,294 per provision annually (45 CFR § 102.3, 2026) against Business Associates, though collecting against offshore entities is harder in practice.
- Offshore hosting of ePHI is not prohibited by HIPAA, but the Covered Entity's risk analysis under 45 CFR § 164.308(a)(1)(ii)(A) must address it, and many US customers refuse it contractually.
- "HIPAA compliant" marketing by non-US companies with no US healthcare clients signals security ambition, not a legal status; no official HIPAA certification exists.
What actually pulls a non-US website into HIPAA?
Run the entity test, not the geography test. HIPAA applies to two groups defined at 45 CFR § 160.103: Covered Entities (US healthcare providers conducting electronic standard transactions, health plans, and clearinghouses) and Business Associates (anyone handling PHI on a Covered Entity's behalf). For a non-US website operator, three situations create real obligations:
- You sell to US healthcare organizations. A scheduling SaaS in Lisbon that signs a US dermatology group as a customer, and stores their patient appointment data, is a Business Associate. The dermatology group is required to obtain a BAA before sharing PHI (45 CFR § 164.504(e)), and the SaaS becomes directly liable for the Security Rule safeguards at 45 CFR §§ 164.308-312 and for breach reporting under 45 CFR §§ 164.400-414.
- You subcontract for someone who does. Subcontractor Business Associates need flow-down BAAs too. A freelance developer in Manila maintaining a US telehealth platform's database is in the chain.
- You operate as a US provider from abroad. Rare, but a foreign-based company that furnishes care to US patients and bills US insurers electronically can itself meet the Covered Entity definition.
What does not trigger HIPAA: US visitors reading your health content, US consumers buying a direct-to-consumer wellness app with no Covered Entity in the loop, or hosting your site in a US data center. Our breakdown of who needs HIPAA-compliant hosting applies the same test to US businesses.
Why "HIPAA as a global standard" is partly marketing
Non-US vendors often advertise HIPAA compliance to signal trustworthiness, and buyers often demand it reflexively. Two corrections keep this honest. First, HIPAA is a US sector-specific law; most of the world regulates health data through omnibus statutes like the EU GDPR, Canada's PIPEDA, and Brazil's LGPD, several of which impose stricter consent rules and far larger fines. Our comparison of HIPAA vs international privacy laws tables the differences. Second, there is no official HIPAA certification. HHS does not certify products or companies, so "HIPAA certified" badges are marketing artifacts. The defensible claims are "HIPAA-eligible," "BAA-covered," or "supports HIPAA compliance," backed by an actual risk analysis and signed agreements.
That said, the demand is rational. For a non-US SaaS, willingness to sign a BAA is frequently the gating requirement for the US healthcare market, and the Security Rule's controls map closely to what GDPR Article 32 and ISO 27001 already expect. Building once to the strictest applicable standard usually costs less than retrofitting.
Does HIPAA allow ePHI on servers outside the US?
Yes. No provision of HIPAA prohibits storing or processing electronic PHI (ePHI) offshore. Three practical constraints still push PHI workloads onto US-region infrastructure:
- Risk analysis. The Covered Entity must evaluate offshore storage in its documented risk analysis (45 CFR § 164.308(a)(1)(ii)(A)), covering foreign legal access regimes, auditability, and incident response across time zones. Many conclude the added risk is not worth it.
- Enforcement practicality. HHS OCR's remedies against a judgment-proof offshore vendor are limited, which makes US customers lean on contract terms, indemnities, and US-region hosting requirements instead.
- Procurement reality. Hospital and payer security questionnaires routinely require US data residency even though the statute does not.
The common architecture for a non-US founder is therefore a US-region deployment for the PHI workload, on infrastructure whose provider signs a BAA. AWS supports this model with HIPAA-eligible services under its BAA, covered in detail in is AWS HIPAA compliant.
A practical stack for serving the US and home markets together
For a SaaS or site operator outside the US entering the US healthcare market, the workable sequence is:
- Confirm Business Associate status and template your BAA before sales conversations start; US Covered Entities cannot legally share PHI without one (45 CFR § 164.308(b)).
- Run and document a risk analysis (45 CFR § 164.308(a)(1)(ii)(A)) and keep policies and records for six years (45 CFR § 164.316(b)(2)(i)).
- Implement the technical safeguards at 45 CFR § 164.312: unique user identification, audit controls (§ 164.312(b)), integrity controls, and encryption in transit and at rest (§ 164.312(a)(2)(iv), (e)).
- Segment PHI into a US-region, BAA-covered environment while home-market data stays under GDPR, PIPEDA, or local rules; Canadian founders have additional layers we cover in HIPAA, Canada, and PIPEDA.
- Train staff who touch PHI (45 CFR § 164.308(a)(5)) and write the breach playbook against the four-factor assessment at 45 CFR § 164.402.
The full control list is in our HIPAA-compliant hosting guide. hipaacomplianthosting.com provides managed HIPAA hosting on AWS for exactly this pattern, including non-US companies serving US healthcare clients; that is our business, and our HIPAA cloud hosting includes the BAA and the platform safeguards.
Frequently asked questions
Does HIPAA apply to websites hosted outside the US?
Hosting location is irrelevant to applicability. HIPAA applies if the site's operator is a Covered Entity or Business Associate under 45 CFR § 160.103, wherever the servers are.
Can a non-US company sign a BAA?
Yes. Nothing limits BAAs to US companies, and US Covered Entities must obtain one from any vendor handling their PHI under 45 CFR § 164.504(e). The non-US signer takes on direct Security Rule obligations.
Can HHS OCR fine a company with no US presence?
Legally yes, since Business Associates are directly liable, with 2026 penalties up to $73,011 per violation (45 CFR § 102.3). Practically, enforcement against offshore entities is harder, which is why US customers compensate with contract terms and residency requirements.
Is GDPR compliance enough to claim HIPAA readiness?
No. The controls overlap substantially, but HIPAA adds BAAs, a documented risk analysis, six-year documentation retention, and its own breach notification regime. Map the gaps rather than assuming equivalence.
Do I need HIPAA if my health app sells directly to consumers worldwide?
Generally no, because no Covered Entity relationship exists. Your obligations come from GDPR, the FTC's Health Breach Notification Rule for US consumers, and state laws such as Washington's My Health My Data Act.
This article is general information, not legal advice. Consult counsel about your entity status and contracts, and base your safeguards on a documented risk analysis. Reviewed June 2026.