Is Your Website Platform HIPAA-Ready? Shopify, Wix & WordPress

Why no platform is "HIPAA compliant"

The question "is this platform HIPAA compliant?" feels like it should have a yes/no answer, the way "does this platform support SSL?" does. It doesn't — and understanding why is the key that unlocks every other answer in this article.

HIPAA compliance is not a certification a website builder earns and stamps on its homepage. It's a legal state that a covered entity — a healthcare provider, health plan, or clearinghouse — achieves through a combination of things: a documented risk analysis, administrative safeguards, physical safeguards, technical safeguards like encryption and access controls, workforce training, and a signed contract with every vendor that will handle protected health information on its behalf. A platform can support that state or obstruct it, but it cannot be it for you.

This is why a platform can be genuinely secure — encrypted, SOC 2 audited, hardened — and still be the wrong choice for PHI. Security and compliance overlap, but they aren't the same thing. SOC 2 reports, ISO certifications, and TLS encryption do not, on their own, make a platform HIPAA compliant or authorize it to handle PHI. They're evidence of good security practice; they are not a Business Associate Agreement, and they are not permission.

What a BAA actually covers (and what it doesn't)

A Business Associate Agreement (BAA) is the contract at the centre of every platform decision here, so it's worth being precise about what it is. Under the HIPAA Privacy Rule, a BAA is a legally required agreement between a covered entity and any business associate — a vendor that creates, receives, maintains, or transmits PHI on the covered entity's behalf. The agreement must be in place before any PHI is shared, and it spells out permitted uses, required safeguards, breach-notification duties, and what happens to the data when the relationship ends.

Two features of BAAs trip people up, and both matter for choosing a platform:

A BAA does not shift your liability. Signing one does not hand your compliance obligations to the vendor. Since the HITECH Act and the 2013 Omnibus Rule, business associates are directly liable for HIPAA violations too — but that's in addition to your responsibility as the covered entity, not instead of it. A BAA distributes accountability across the chain; it doesn't let you off the hook.

A BAA covers only what it covers. Vendor BAAs are frequently conditional. Cloud BAAs, for instance, typically state that the vendor's obligations apply only when the in-scope services are configured correctly by you — encryption enabled, logging on, PHI kept within the covered services. A signed BAA on a misconfigured setup can leave you exposed in exactly the places you assumed were handled.

There's also a common myth worth killing: the idea that a platform is just a "conduit" for data, like the postal service, and therefore doesn't need a BAA. The conduit exception is real but extremely narrow — it covers pure transmission services (a courier, an ISP carrying encrypted traffic) that never store the data. Regulators have been clear that cloud and hosting providers do not qualify as conduits, even when the data is encrypted and they hold no keys, because they store it. If a platform holds PHI for any meaningful period, it needs a BAA — full stop.

Is Shopify HIPAA compliant?

Shopify is a fully hosted, closed commerce platform, and its position on PHI is unambiguous: it does not sign a Business Associate Agreement for standard stores on any tier, Plus included. More than that, Shopify's Acceptable Use Policy explicitly names uploading protected health information subject to HIPAA as an unsupported activity. So this isn't a grey area you can negotiate — using Shopify to store PHI is against its own terms as well as being non-compliant under HIPAA.

Shopify does publish SOC 2 Type 2 reports, and you'll sometimes see that cited as if it settles the question. It doesn't. As covered above, SOC 2 is a security-assurance framework; it doesn't create HIPAA compliance, doesn't stand in for a BAA, and doesn't authorise PHI. They're different instruments answering different questions.

So does that mean healthcare businesses can't use Shopify? Not at all — plenty do, successfully. The workable model is data segregation: you use Shopify for what it's brilliant at (catalogue, checkout, payments, fulfilment) and you make sure PHI never touches it. In practice that means keeping health details out of product names and variants, checkout fields, customer notes and tags, metafields, uploaded files, connected apps, and support tickets. Anything genuinely clinical — intake forms, symptom questionnaires, prescription details, refill requests — gets routed to a separate, HIPAA-focused form or portal whose vendor will sign a BAA, kept entirely outside the Shopify environment.

Is Wix HIPAA compliant?

This is the platform where the honest answer changed recently, and where a lot of published guidance is now out of date. As of March 2026, Wix offers a Business Associate Agreement for certain healthcare uses — a genuine shift from its earlier position. If you read an article from 2024 or early 2025 saying "Wix won't sign a BAA," that information is stale.

The path Wix provides looks like this: on an eligible plan, you open the site's compliance and privacy settings, activate a "PHI protection" mode across the data stores that will hold health information (forms, databases, inbox and messages, bookings), and then sign the BAA through your account. Eligible plans currently include Business, Plus, Elite, Business Elite, and Enterprise, built with the Wix Editor or Wix Studio.

The critical caveat — and Wix says this itself — is that turning on the mode and signing the BAA is necessary, not sufficient. Compliance still depends on how you configure and run the site, which apps you use (incompatible ones may be disabled, restricted, or removed once PHI protection is on), and your own risk analysis. A standard Wix plan without those steps is not covered, and a "protected" site wired up to an unreviewed third-party app can reopen the gap you just closed. What Wix now gives you is a viable path to handling PHI — not an automatic destination.

Is WordPress HIPAA compliant?

"Is WordPress HIPAA compliant?" is the trickiest of the three, because "WordPress" isn't one thing. The self-hosted software from WordPress.org is exactly that — software you install somewhere. It has no plan, no hosting contract, and no BAA of its own to offer. So it doesn't get a yes-or-no verdict; it gets a conditional, architecture-level one: a WordPress site can sit inside a compliant system, but WordPress the software doesn't supply that system.

The distinctions that matter:

• WordPress.com (the hosted service) will not sign a BAA, so it can't be used to hold PHI.
• Self-hosted WordPress can be part of a compliant setup — if you host it with a provider that signs a BAA and configure everything correctly. Specialist HIPAA hosts sign BAAs for WordPress; DIY builders can get a self-service BAA from major cloud providers. Many mainstream managed-WordPress hosts, by contrast, do not offer a BAA — so a strong general-purpose host is not automatically an option for PHI. Confirm directly, every time.

Here's the part most guides underplay: the host's BAA covers the infrastructure, and nothing else. Everything else in a WordPress stack is still yours to secure — the plugins you install, the forms that collect data, the emails those forms trigger, user access, backups, and the audit logs and annual risk analysis HIPAA expects. A single vulnerable plugin, a shared admin account, a public upload URL, or an old unencrypted backup can expose PHI on an otherwise well-hosted site.

Forms are the classic WordPress leak

The most common WordPress mistake involves forms, and it's worth spelling out because it generalises. A HIPAA-ready form is an architecture, not a plugin setting. Embedded form services that store submissions on their own servers sign their own BAA with you. Self-hosted form plugins never send your data anywhere — the submissions land in your site's database — which means the plugin doesn't need a BAA, but your host does, plus you need encryption and safe handling of the notification emails. That last point is the leak almost everyone misses: a form can be perfectly configured while the automatic "you have a new submission" email quietly ships the patient's details in plaintext to an inbox that isn't covered by anything.

The three platforms, side by side

Pulling it together — this is the comparison most single-platform articles don't give you, because the useful decision is relative, not absolute:

Notice what the table makes obvious: none of these rows is really about the platform's technology. They're about contracts and configuration. The "best" platform for a healthcare business is whichever one lets you keep PHI inside a BAA-covered boundary with the least friction — and that depends far more on how you work than on which logo is on the login screen.

Where PHI actually hides on a website

A recurring reason healthcare sites fall out of compliance is that PHI ends up in places nobody thought of as "medical data." HIPAA's definition is broad: PHI is health information that can identify a person. On a website, that shows up in far more spots than the obvious intake form. Worth checking every one of these:

• Form fields — anything asking about symptoms, conditions, medications, or reasons for visit.
• Appointment and booking details — a calendar entry titled with a procedure name is PHI.
• File uploads — patients attaching records, images, or lab results.
• Live chat and messaging transcripts — often stored by a third-party tool outside any BAA.
• Order notes, customer tags, and profiles — the Shopify trap, but it happens everywhere.
• Notification emails — the plaintext copy of a form submission sent to staff.
• URLs and tracking parameters — a page path or UTM string that reveals a condition.
• Analytics tied to identity — behavioural data that becomes PHI when linked to a person.

That last pair — URLs and analytics — is the bridge to the problem most of this article's competitors never mention. Because once you're talking about what your tracking tools capture and where they send it, you've quietly stepped out of HIPAA's territory and into a different body of law entirely.

The second problem HIPAA doesn't cover

Here's the distinction that matters most, and the one that catches businesses completely off guard: HIPAA governs the protected health information you hold. It says nothing about what your website transmits to third parties before a visitor consents. Those are two different problems, governed by two different bodies of law, and solving one does nothing for the other.

Think of it as two lanes:

The reason this catches people is that Lane 2 applies even if you handle no PHI at all. A supplement store, a wellness brand, a clinic's marketing site with no patient portal — none of them may touch a single medical record, so they reasonably conclude "HIPAA isn't really our problem." They might be right about Lane 1. But almost all of them run marketing trackers — the Meta Pixel, Google Analytics, Google Ads — that fire the instant a page loads and transmit what the visitor is doing to those third parties. On a health-adjacent site, the page someone is viewing can itself reveal something sensitive: which condition they're researching, which treatment they're pricing, which product they're about to buy.

Sending that browsing activity to third parties before the visitor has consented is the exposure at the heart of the wave of website-privacy litigation and enforcement — California's Invasion of Privacy Act (CIPA) claims, GDPR consent requirements, and the growing patchwork of US state privacy laws. It's a real, active risk, and it's entirely separate from whether your intake form is HIPAA-ready.

Where ConsentPixel fits — and where it doesn't

This is worth stating plainly, because the two lanes are easy to blur. ConsentPixel does not make your site HIPAA compliant, and it doesn't touch your PHI. That's Lane 1 — your vertical, your platform choice, your BAAs, your risk analysis. Nothing in this article changes that, and no consent tool can do it for you.

What ConsentPixel handles is Lane 2: keeping your customer-facing site compliant with the user-privacy laws that apply based on where each visitor is. It's a single pixel that blocks third-party trackers from firing until the visitor has actually consented — so health-related browsing isn't quietly shipped to advertising platforms before anyone agreed. And because the applicable law depends on geography, it's region-aware: a visitor from California, a visitor from the EU, and a visitor from Texas each get the correct consent treatment for their jurisdiction, on the same site, automatically.

So the practical sequence for a healthcare or health-adjacent business is: use this article to get Lane 1 right — pick a platform whose BAA posture fits how you work, and keep PHI inside that covered boundary. Then handle Lane 2 separately, because getting HIPAA perfect does nothing about the trackers firing on your homepage. The quickest way to see whether Lane 2 is a live issue for you is to look at what your site actually transmits before consent.

Frequently asked questions

About this article: This piece is for informational purposes only and is not legal advice. It summarises publicly available information about HIPAA, Business Associate Agreements, and the stated policies of Shopify, Wix, and WordPress as understood in August 2026; vendor BAA policies change, so confirm current terms directly with each vendor before relying on them. HIPAA obligations depend on your organisation's documented risk analysis and specific circumstances — consult qualified counsel or a compliance professional. ConsentPixel — Privacy · Verified is a consent-infrastructure provider that addresses user-privacy laws (such as CIPA, GDPR, and US state privacy laws) governing what a site transmits to third parties before consent; it does not handle protected health information, does not sign BAAs, and does not make any website "HIPAA compliant."