HIPAA-Compliant Website Builder: What to Verify Before You Buy

"HIPAA-compliant website builder" is a phrase that appears on almost every healthcare website platform's marketing page, and it means almost nothing without specifics. HIPAA doesn't certify websites or website builders — there's no seal, no badge, no official designation. What HIPAA actually requires is a set of technical and administrative safeguards that protect PHI wherever it's created, stored, or transmitted. A website builder that claims compliance without documenting the specific controls is asking you to trust marketing copy rather than evidence. Here's what to actually verify before you commit.

When a Website Needs HIPAA Compliance

Not every medical practice website needs HIPAA compliance. A site that only displays public information — practice name, address, hours, services, provider bios — and has no patient-facing forms, no patient portal, and no way to submit PHI is not handling protected health information and doesn't require the full HIPAA safeguard framework.

But the moment a patient can submit any of the following through the website, HIPAA applies:

• Name and contact information combined with a request for medical services
• Appointment requests that include symptoms or reason for visit
• Insurance information submitted through an intake form
• Any health information shared through a contact form, chat widget, or messaging tool
• Patient portal access or authentication

Most practice websites include at least a contact form or appointment request form, which means most practice websites need at least basic HIPAA safeguards. The question isn't whether compliance applies — it's whether the website builder implements the required controls.

The Specific Controls to Verify

1. Encryption in Transit (TLS/HTTPS)

Every page on the site, not just the forms, must be served over HTTPS with a valid TLS certificate. This is table stakes — any website builder that doesn't provide HTTPS by default in 2026 is not a serious option. But verify it covers all subdomains and custom domains, not just the default builder subdomain.

2. Encryption at Rest

If the website builder stores form submissions, patient messages, or any user data, that data must be encrypted at rest in the builder's database. Ask specifically: "Where are form submissions stored, and are they encrypted at rest?" If the answer is "they're emailed to you" rather than stored, the encryption question moves to your email provider — which needs its own HIPAA compliance (Gmail and standard Outlook are not HIPAA-compliant without a BAA).

3. Business Associate Agreement (BAA)

Any vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a Business Associate under HIPAA. A website builder that hosts patient forms is a Business Associate. The builder must sign a BAA before any PHI is handled — not after, not "when we get around to it." If a builder won't sign a BAA, they are not HIPAA-compliant for your use case, regardless of what their marketing says.

4. Access Controls and Audit Logs

The builder should provide access controls for the practice's staff (who can edit the site, who can view form submissions) and audit logs that record who accessed patient data and when. This is an administrative safeguard under HIPAA, and it's the one most commonly missing from DIY builders.

5. Form Handling

Contact forms, appointment request forms, and intake forms are the most common vector for PHI exposure on practice websites. Verify:

• Form data is transmitted over HTTPS (not HTTP)
• Form submissions are stored encrypted or delivered through a secure channel (not unencrypted email)
• Forms don't pre-fill with patient data from previous visits
• Form auto-responders don't include PHI in confirmation emails

6. Analytics and Third-Party Tools

Google Analytics, Facebook Pixel, chat widgets, and other third-party tools can capture PHI if they track form submissions, URL parameters containing patient names, or chat conversations that include health information. Standard Google Analytics is not HIPAA-compliant — Google will not sign a BAA for standard GA. Verify that any analytics or tracking tools used on the site are either HIPAA-compliant (with a BAA) or configured to exclude PHI from tracking.

7. Session Management and Authentication

If the site has a patient portal or login, session tokens must be encrypted, sessions must expire after a reasonable timeout, and authentication must use strong password requirements or multi-factor authentication. This is a technical safeguard under the HIPAA Security Rule.

8. Backup and Disaster Recovery

The builder should have a documented backup and disaster recovery plan. If patient data is lost, the practice needs to know it can be recovered. Ask for the builder's RPO (Recovery Point Objective) and RTO (Recovery Time Objective) — these are standard metrics that any compliant vendor should be able to provide.

What "HIPAA-Compliant" Marketing Claims Usually Mean

When a website builder says "HIPAA-compliant," it can mean any of the following — and the practice needs to determine which:

Claim	What it might actually mean	What to ask
"HIPAA-compliant hosting"	The servers are in a compliant data center	"Do you sign a BAA?"
"We offer BAAs"	A BAA is available, but only on certain plans	"Is the BAA included in my plan, or is it an add-on?"
"HIPAA-ready"	The platform can be configured to be compliant, but it's not by default	"What configuration is required, and who is responsible for it?"
"Encrypted forms"	Form data is encrypted in transit	"Is it also encrypted at rest? Where is it stored?"
"We're SOC 2 certified"	The company has completed a SOC 2 audit	"SOC 2 is not HIPAA. Do you also sign BAAs?"

The Verification Checklist

Before choosing a website builder for a medical practice, ask these questions in writing and save the answers:

1. Will you sign a Business Associate Agreement before we go live?
2. Is the BAA included in our plan, or does it cost extra?
3. Where are form submissions stored, and are they encrypted at rest?
4. Who has access to patient data submitted through the site, and are access controls and audit logs provided?
5. Are analytics tools HIPAA-compliant, or can they be disabled?
6. Is the site served entirely over HTTPS?
7. What is your backup and disaster recovery plan?
8. What happens to patient data if we cancel our subscription?
9. Are chat widgets, if included, covered by the BAA?
10. Can you provide documentation of the specific HIPAA safeguards you implement?

If a builder can't answer these questions clearly, they are not HIPAA-compliant for your use case — regardless of what their website says.

How ClinicSite Handles This

ClinicSite documents the specific controls rather than asking you to trust a badge:

• HIPAA-compliant hosting with documented technical controls (TLS, encryption, access controls, audit logging)
• A BAA is available before any patient data is handled
• Published sites are locked down with security headers and form handling that prevents PHI exposure
• Forms on published sites are configured with form-action: none by default — they don't submit unless the practice explicitly enables secure submission
• The generator is constrained to make only claims traceable to the practice's actual information, preventing the creation of fabricated medical claims or compliance assertions on the generated site

For the full technical control documentation, see our HIPAA-compliant website hosting guide and our HIPAA website requirements guide.

---

Want a website that handles compliance correctly? Start a free migration — the generated site includes HIPAA-aware hosting and form handling from the start, not as an afterthought.