HIPAA-Compliant Medical Websites: The Full Guide

HIPAA-compliant healthcare websites must protect all patient health information (PHI) through encrypted forms, HIPAA-eligible hosting, signed Business Associate Agreements with every vendor, and compliant analytics. For healthcare providers in Minneapolis, Chicago, and across the Midwest, getting this right is not optional — a single misconfigured form or tracking pixel can trigger a federal breach investigation.

At BSPKN, we build healthcare websites for recovery centers, clinics, and specialty practices that have to pass both Google’s quality bar and a compliance attorney’s review. This guide covers exactly what HIPAA requires for your website and how to implement each requirement correctly. For broader context on driving patient growth, read our healthcare marketing services page.

What HIPAA Actually Requires for Healthcare Websites

The HIPAA Security Rule applies the moment your website touches electronic protected health information (ePHI). That includes appointment request forms, patient intake forms, portal logins, and any page where a visitor can submit personal health data.

The Minimum Necessary Rule

HIPAA’s minimum necessary standard requires that you collect only the patient information you actually need for a specific purpose. On a website, this means your intake forms should not ask for diagnosis history, insurance policy numbers, or medical record numbers unless you have a documented clinical reason for collecting that data at the first-touch stage. Many healthcare practices unknowingly overcollect on web forms, creating unnecessary breach exposure.

PHI Protection Requirements

Any ePHI transmitted through your website must be protected with:

• Encryption in transit (TLS 1.2 minimum — TLS 1.3 is the current standard)
• Encryption at rest for any stored form data
• Access controls limiting who can view submitted patient information
• Audit logs tracking who accessed what data and when

A standard WordPress contact form — Contact Form 7, WPForms free tier, or most out-of-the-box form builders — fails every one of these requirements if the form data is stored in your WordPress database without additional encryption and the form vendor has not signed a BAA.

Patient Form Security: The Most Common Failure Point

Healthcare website contact forms are the highest-risk compliance area we see at BSPKN. Most clinics and recovery centers launch a “Get Help Now” or “Request an Appointment” form without realizing the form plugin stores submissions in a database, emails them to staff unencrypted, and has no signed BAA with the form vendor.

What a Compliant Form Setup Looks Like

A HIPAA-compliant patient form requires all of the following:

• Encrypted form submission: Data encrypted in transit via TLS 1.3 and encrypted at rest. Gravity Forms with the HIPAA-compliant Gravity Forms Encrypted Fields add-on is one viable WordPress option. Standard Contact Form 7 is not compliant for PHI collection.
• BAA with the form vendor: The company providing your form software must sign a Business Associate Agreement. Gravity Forms offers a BAA. Many free and standard form tools do not.
• No unencrypted email delivery: Form notifications that email PHI in plain text to a staff inbox violate HIPAA. Compliant setups either suppress email notifications for PHI-containing submissions or use encrypted email delivery.
• Staff access controls: Only authorized staff should be able to view form submissions, with documented access controls and audit logging.

At BSPKN, we have implemented compliant form stacks for recovery centers including Guiding Road Recovery, Brost Clinic, and facilities across the Twin Cities and Chicago areas. The configuration is more involved than standard WordPress forms, but it is manageable with the right setup.

Business Associate Agreement (BAA) Requirements

A BAA is a written contract that a covered healthcare entity must have with every vendor who handles ePHI on their behalf. This is one of the most overlooked HIPAA requirements in web development — and one of the most consequential.

For a healthcare website, you need BAAs with every vendor in the following stack:

Hosting

Your web host touches every byte of data on your server. Standard shared WordPress hosting — including most budget managed WordPress hosts — does not offer a HIPAA BAA and is therefore not eligible for hosting healthcare websites that handle ePHI.

HIPAA-eligible hosting options with available BAAs include:

• AWS (Amazon Web Services) — BAA available, used as infrastructure layer by many healthcare-specific hosts
• Microsoft Azure — BAA available
• WP Engine HIPAA Plan — managed WordPress hosting with a formal BAA, purpose-built for healthcare sites
• Liquid Web / Nexcess HIPAA plans — dedicated server options with BAA available

Standard WP Engine, Kinsta, Flywheel, and SiteGround plans do not include a BAA. “Encrypted storage” is not the same as a signed BAA.

Analytics

Analytics platforms are a major compliance risk area. The standard Google Analytics 4 implementation using a JavaScript snippet on a healthcare website can capture query strings, form field data, and referral information that constitutes ePHI — especially on pages where patients enter symptoms, conditions, or treatment information.

Standard Google Analytics does not offer a HIPAA BAA and should not be deployed on PHI-handling pages without a carefully engineered server-side implementation that strips all ePHI before it reaches Google. Options that are more commonly used in compliant healthcare setups include:

• Matomo (self-hosted) — open-source, data stays on your server, no third-party BAA required
• Heap with BAA — enterprise analytics platform, BAA available at enterprise tier
• GA4 with server-side tagging — routes data through your own server, stripping ePHI before sending to Google. Complex to implement correctly but allows use of GA4 in a more compliant architecture.

Hospitals and large health systems also use platforms like Snowplow or Amplitude with server-side architectures. For smaller clinics and recovery centers, self-hosted Matomo is often the most practical compliant option.

CRM and Email Providers

If your CRM receives patient form submissions from your website — names, contact information, health concerns — your CRM provider must sign a BAA. HubSpot offers a BAA at the Enterprise tier. Salesforce Health Cloud includes a BAA. Standard Mailchimp does not offer a BAA and should not receive healthcare patient data. GoHighLevel does not currently offer a formal BAA.

For the healthcare clients in our healthcare marketing practice, we evaluate every tool in the data flow and confirm BAA status before going live.

SSL/TLS Encryption Standards

TLS (Transport Layer Security) encrypts data in transit between your website visitor’s browser and your server. HIPAA does not specify a minimum TLS version in its text, but NIST guidelines and the HHS audit protocol effectively require TLS 1.2 as a floor, with TLS 1.3 as the current best practice.

What this means for your website:

• SSL/TLS certificate from a trusted certificate authority (Let’s Encrypt, DigiCert, etc.) — standard on all modern hosting
• TLS 1.0 and TLS 1.1 must be disabled on your server — both are deprecated and considered insecure
• TLS 1.2 is the acceptable minimum
• TLS 1.3 is the recommended standard for healthcare websites
• Mixed content (HTTP resources loaded on HTTPS pages) must be eliminated

A free SSL certificate with TLS 1.3 and HSTS headers enabled is achievable on any quality managed WordPress host. Your hosting configuration, not just the certificate, determines whether you are actually running TLS 1.3.

HIPAA-Eligible Hosting: What to Look For

Beyond the BAA, HIPAA-eligible hosting should include the following technical safeguards:

• Encryption at rest for all stored data
• Physical security controls at the data center (SOC 2 Type II certified facilities)
• Network access controls and firewall configuration
• Automated backup with encrypted backup storage
• Intrusion detection and system activity logging
• Documented incident response procedures

Ryan Rivard, Founder of BSPKN, notes: “The hosting BAA conversation is where most healthcare web projects stall. A client will be mid-build and their current host says they do not offer BAAs. We often recommend migrating to WP Engine’s HIPAA plan or an AWS-backed solution before launch. The migration cost is always less than the risk of operating on a non-eligible host.”

BSPKN’s Healthcare Web Development Process

Our healthcare website development process is built specifically around the HIPAA compliance requirements described above. We have delivered compliant web projects for The Retreat, Hazelden Betty Ford, Guiding Road Recovery, Brost Clinic, and Stretch Zone, among other providers across Minneapolis, the Twin Cities, and Chicago.

Step 1: Risk Assessment and BAA Stack Audit

Before writing a line of code, we map every vendor in the proposed technology stack and document BAA status. Hosting, analytics, CRM, email, form tools, chat widgets, scheduling tools — each one gets evaluated. Any vendor that cannot provide a BAA and that will handle ePHI is replaced before build.

Step 2: Compliant Form Architecture

We configure encrypted form infrastructure using a BAA-backed form solution. Form submissions that may contain PHI are handled with encryption at rest, staff access controls, and compliant notification workflows. We do not use standard Contact Form 7 for any PHI-touching forms on healthcare sites.

Step 3: Compliant Analytics Setup

Depending on the client’s reporting needs, we implement self-hosted Matomo or a server-side GA4 architecture. For recovery centers and clinics in the Twin Cities and Chicago who need conversion tracking for their paid media campaigns, we configure conversion tracking in a way that does not transmit ePHI to advertising platforms.

Step 4: Hosting Migration and BAA Execution

We coordinate hosting migration to a HIPAA-eligible environment if the client’s current host is non-eligible. We facilitate the formal BAA signing process with the hosting provider and document it in the client’s compliance file.

Step 5: Pre-Launch Compliance Review

Before launch, we conduct a technical compliance review covering encryption standards, BAA documentation, form security, analytics implementation, and access controls. We provide a written summary the client can share with their compliance officer or legal counsel.

If your healthcare practice is in Minneapolis, Chicago, or anywhere in the Midwest and you need a HIPAA-ready website that also performs for patient acquisition, visit our healthcare marketing page to learn more about how we work with providers.