A healthcare startup rang me in early 2023. Nice founders, decent budget, clear brief: patient intake forms, appointment scheduling, maybe a telehealth widget down the line. "We're on WP Engine," the CTO told me. I asked if WP Engine had signed their BAA. Long pause. "What's a BAA?"
That's where the problem lives — not in the code, not in the plugin stack, but in the paper trail that most developers never read and most hosts quietly avoid.
Here's the thing: HIPAA compliance isn't a feature you toggle on. It's a legal framework, and the Business Associate Agreement is the contract that makes your hosting provider a formal part of that framework. Without a signed BAA, it doesn't matter if your server runs TLS 1.3 and you've encrypted every field in the database. You're still exposed. So are your clients.
Let me walk through what I actually know about which platforms will sign in 2026, and — more importantly — which ones say the right things but won't put pen to paper.
---
What a BAA Actually Is (and Isn't)
ABusiness Associate Agreementis a contract under the HIPAA Privacy Rule that binds a vendor to specific obligations around Protected Health Information (PHI). When you host a healthcare site, your hosting provider touches PHI — even if only at the infrastructure layer. That makes them a Business Associate. Full stop.
What the BAA doesn't do is make you compliant automatically. I see this misunderstood constantly. The BAA means the host acceptstheirshare of liability and agrees to safeguards. Your application layer, your forms, your WordPress plugins, your logging — that's still on you.
Seahawk had a project in 2022 for a US-based physiotherapy group running a WordPress site. The client had a BAA with their email provider (good), their EHR vendor (obviously), but nothing with their web host. Their site was collecting symptom data via Gravity Forms. Every submission was being emailed to a Gmail account. Three separate violations in one workflow. We untangled it over about six weeks.
---
The Hosts That Will Actually Sign in 2026
AWS, GCP, and Azure — The Serious Options
If you need a BAA and you need certainty, the hyperscalers are your answer. All three —Amazon Web Services, Google Cloud Platform, and Microsoft Azure — offer BAAs and maintain lists of HIPAA-eligible services.
AWS is what I reach for most. The BAA covers a solid range of services: EC2, RDS, S3, CloudFront, Lambda, and more. Critically, not every AWS service is eligible. DynamoDB is on the list; not all experimental services are. You have to check the current eligible services page before you architect anything.
GCP's BAA covers BigQuery, Cloud SQL, Compute Engine, and Cloud Storage, among others. Azure has the broadest enterprise adoption in healthcare specifically — their BAA and compliance documentation is mature, and if your client is already in the Microsoft ecosystem (which most enterprise healthcare orgs are), Azure often makes organisational sense.
The catch with all three: you're not getting managed WordPress here. You're getting infrastructure. Someone has to build and maintain the stack — OS patching, WAF configuration, backups, encryption at rest and in transit. At Seahawk we've used AWS with a hardened EC2 instance running Nginx, PHP-FPM, and MySQL for healthcare clients. It works. It's also a lot more operational overhead than handing someone a WP Engine login.
Kinsta — Situational Yes
Kinsta operates on GCP. They offer BAA signing for customers on their higher-tier plans (Business 1 and above, last time I checked). This matters because Kinsta is genuinely excellent managed WordPress hosting. Fast. Reliable. Good staging environments.
But — and this is worth stressing — Kinsta's BAA coverage is somewhat narrower than going direct to GCP yourself. You're relying on Kinsta's internal controls as well as GCP's. For many healthcare WordPress projects, that's fine. For anything touching very sensitive data at volume, I'd want to understand exactly what their security documentation says before committing.
Cloudways — No
Cloudways is popular in the agency world. Good price-to-performance ratio. We've used it on dozens of non-sensitive projects. But as of my last check, Cloudways does not offer a HIPAA BAA. They even run on AWS and GCP underneath, which is mildly ironic. The managed layer introduces uncertainty they won't contractually stand behind for HIPAA purposes.
Pantheon — No (for most plans)
Pantheon is excellent for Drupal and WordPress agencies. HIPAA compliance is not their market. They've been clear about this. Don't let the enterprise branding fool you.
WP Engine — No
I know. They have compliance documentation. They talk about security. They will not sign a HIPAA BAA. Their terms of service explicitly prohibit storing PHI on their platform. This disqualifies them for any true healthcare use case. The startup I mentioned at the top of this post? This is exactly where they were.
Liquid Web / Nexcess — Possible, with caveats
Liquid Web has offered HIPAA-compliant managed hosting with BAA signing, typically on their dedicated server or VPS products rather than shared plans. It's worth a direct conversation with their sales team. Their compliance posture has improved. But I'd want the BAA in hand before I built anything.
---
What Your WordPress Stack Needs Beyond the BAA
The BAA is the foundation, not the building. Here's what actually needs to happen at the application layer for a HIPAA-adjacent WordPress site.
Forms and Data Collection
- Gravity Formswith the proper setup can be used, but native Gravity Forms stores submissions in the WordPress database by default. For PHI, you either need to disable database storage and pipe data securely to a HIPAA-compliant destination, or use their Encrypted Fields add-on carefully.
- Cognito FormsandFormAssemblyboth offer HIPAA-compliant tiers with BAAs. If the form is the primary data-collection point, these are often cleaner than wrestling with GF.
- Never, ever use free contact form plugins that send data to third-party servers without checking their compliance posture.
This one kills people. Your WordPress site probably sends email via wp_mail(), which defaults to PHP mail or a connected SMTP plugin. Standard Gmail, standard Mailchimp, standard SendGrid — none of those sign a HIPAA BAA at entry-level tiers.
Pauboxis the one I recommend consistently for small-to-mid healthcare clients. HIPAA-compliant email, BAA included, straightforward pricing. Google Workspace also offers a BAA for their healthcare clients, but it requires a specific plan and a formal request process — it doesn't apply to a standard Google account.
Plugins and Third-Party Integrations
Every plugin that phones home, every analytics script, every live chat widget — all of it potentially touches PHI depending on what data is on the page. Run a proper audit. I useQuery Monitorto identify what's making external requests, then cross-reference against each vendor's compliance documentation.
HubSpot will sign a BAA. Intercom won't (at standard tiers). Hotjar almost certainly shouldn't be running on a healthcare site without a very careful scoping exercise.
---
How to Actually Get a BAA Signed
This is more procedural than technical, but I've seen projects stall here.
- Identify every vendorthat touches or could touch PHI — host, CDN, email, forms, analytics, support chat, backup provider.
- Request BAA documentationfrom each vendor's sales or compliance team. Don't assume. Get it in writing.
- Review the scope— a BAA that only covers certain services or certain data types needs to be understood before you sign.
- Store the signed agreementssomewhere your client's legal team can access. Not just in your inbox.
- Revisit annually— vendors change their policies, services get deprecated, and a BAA that covered your stack in 2024 might have gaps in 2026.
TheHHS guidance on Business Associatesis actually readable. Worth thirty minutes of your time if you're new to this.
---
The CDN Problem Nobody Talks About
You've sorted your host. You've got a BAA. You've locked down the application layer. Then you put Cloudflare in front of it.
Cloudflare will sign a BAA — but only on theirEnterprise plan, which starts at a price point that rules it out for most small healthcare clients. The free and Pro tiers? No BAA. Which means Cloudflare is technically decrypting and inspecting your HTTPS traffic without a BAA in place, on a site that may have PHI in transit.
For smaller projects, I've routed around this by using AWS CloudFront (BAA-eligible) as the CDN layer when the site is already on EC2 or behind an Application Load Balancer. It's less glamorous than a Cloudflare dashboard but it's clean from a compliance standpoint.
---
What I'd Actually Build in 2026
If a healthcare client came to me tomorrow with a WordPress requirement, here's roughly how I'd architect it:
- Hosting:AWS EC2 (with a signed BAA) running a hardened LEMP stack, or Kinsta Business with their BAA in hand
- Email:Paubox for transactional and provider-facing email
- Forms:FormAssembly or Gravity Forms with database storage disabled and encrypted submission routing
- CDN:AWS CloudFront, not Cloudflare free/Pro
- Analytics:Self-hosted Matomo on the same BAA-covered infrastructure — no Google Analytics for anything that has even a chance of PHI in the URL or parameters
- Backups:AWS S3 (BAA-eligible) with server-side encryption
Is it more expensive than a standard WordPress build? Yes. Is it more operationally complex? Also yes. But the alternative is a client facing aHIPAA breach notificationprocess, potential fines starting at $100 per violation per day, and a very uncomfortable conversation about why their developer never mentioned any of this.
---
FAQ
Does "HIPAA-compliant hosting" mean anything legally?
No. It's a marketing phrase. What has legal meaning is a signed BAA. Any host can call themselves HIPAA-ready, HIPAA-friendly, or HIPAA-something. Without a BAA, those words are decorative. Always ask specifically: "Will you sign a Business Associate Agreement with us?"
Does my site even need a BAA if it just has a contact form?
If the contact form collects information that could constitute PHI — symptoms, diagnoses, appointment reasons, anything tied to a patient's identity and health status — then yes, every vendor in that data chain should have a BAA. A general "book an appointment" form that collects only name, phone, and preferred time is grayer territory, but I'd still err toward getting the BAA.
Can I use WordPress.com for a healthcare site?
WordPress.com (the hosted platform, not self-hosted WordPress software) does not offer a HIPAA BAA. Full stop. This is different from self-hosted WordPress running on a compliant infrastructure. The software is fine. The hosted platform is not appropriate for PHI.
What happens if a vendor I'm using gets acquired and the new owner drops the BAA?
This is a real risk and I've seen it happen with smaller SaaS tools. Your BAA should have termination clauses that trigger if the vendor can no longer meet HIPAA obligations. When you get an acquisition announcement email, don't bin it — check whether compliance commitments are maintained under the new entity.
Is HIPAA only a US concern?
Yes, HIPAA is a US federal law. But if you're building for UK or EU healthcare clients, the equivalents — NHS Digital standards, the Data Security and Protection Toolkit, and GDPR applied to health data — have similar requirements around data processor agreements. The framework differs, the logic doesn't.
---
Most developers, if they're being honest, don't think about the BAA until someone asks. By then you're either fine (lucky) or you're retrofitting a stack under pressure with a nervous client on the phone.
Better to know the landscape before you start the project than to realise halfway through a build that your host won't sign the one document that actually matters.