HIPAA Compliant Website Design: What the Regulations Actually Require
Most "HIPAA compliant" websites aren't. They use standard WordPress hosting, collect data through unencrypted contact forms, run Google Analytics on patient-facing pages, and hope nobody notices. For many practices, this works until it doesn't. When it doesn't, penalties start at $137 per violation and can reach $68,928 per incident with annual maximums exceeding $2 million.
This guide covers what HIPAA actually requires for healthcare websites, what qualifies as Protected Health Information online, and how to build a website that meets regulatory standards without enterprise-level budgets.
What HIPAA Requires for Websites
HIPAA doesn't mention websites directly. The regulations focus on Protected Health Information regardless of medium. Your website becomes subject to HIPAA when it collects, transmits, or stores PHI. That's the key distinction: a pure marketing site with no patient data collection has different requirements than a site with intake forms or patient portals.
The Security Rule Requirements
The HIPAA Security Rule requires administrative, physical, and technical safeguards for electronic PHI (ePHI). For websites, the technical safeguards matter most: Access controls mean role-based permissions and unique user identification. If staff members log into your CMS to manage patient-related content, each needs their own credentials with appropriate access levels.
Audit controls require tracking who accesses what data and when. Your hosting and CMS should maintain logs of all PHI interactions.
Integrity controls ensure data isn't altered or destroyed improperly. This means backup systems, version control, and protection against both accidental deletion and malicious modification.
Transmission security requires encryption for data in transit. TLS 1.2 or higher for all web traffic. No exceptions.
The Privacy Rule Requirements
The Privacy Rule governs how PHI can be used and disclosed. For websites, this means: Minimum necessary standard: Only collect the PHI you actually need. If a contact form asks about symptoms when a simple "request appointment" would suffice, you're collecting unnecessary PHI.
Patient authorization: Patients must consent before PHI can be used beyond treatment, payment, or operations. This affects testimonials, case studies, and marketing use of patient information.
Notice of Privacy Practices: Your privacy policy needs HIPAA-specific language, not just generic website privacy terms.
What Qualifies as PHI on Websites
Protected Health Information includes any individually identifiable health information. On websites, this includes: - Patient names combined with health-related page visits
- IP addresses logged alongside symptom checker usage
- Form submissions containing medical history, symptoms, or treatment questions
- Insurance information entered during scheduling
- Appointment details connected to patient identifiers
- Any health data combined with demographic information
The key phrase is "individually identifiable." Anonymous health information isn't PHI. But combining health data with names, email addresses, or even IP addresses creates PHI.
The Analytics Problem
This is where most healthcare websites fail compliance without realizing it. Google Analytics, Meta Pixel, and similar tracking tools collect IP addresses and browsing behavior. When a visitor browses your "depression treatment" or "STD testing" pages, that browsing history combined with their IP address becomes PHI.
The HHS Office for Civil Rights issued guidance in December 2022 explicitly stating that tracking technologies collecting individual health information require HIPAA compliance. Fines related to pixel tracking exceeded $100 million between 2023 and 2024.
Solutions that actually work:
- Plausible or Fathom for privacy-first analytics that don't collect personal data. No BAA needed because they don't capture IP addresses or create PHI
- PostHog if you need GA4-level features. They offer BAAs for healthcare, but even without one it works fine on marketing sites that don't collect PHI
- No analytics on form pages is the conservative approach. Track marketing content only, exclude pages with contact forms or appointment booking
Business Associate Agreements: The Foundation
A Business Associate Agreement is a contract between a healthcare provider (covered entity) and any vendor that handles PHI on their behalf (business associate). Without a signed BAA, sharing PHI with a vendor violates HIPAA regardless of how secure their systems are.
Vendors That Need BAAs
Your hosting provider if any PHI passes through or is stored on their servers. Most shared hosting providers don't offer BAAs. Dedicated HIPAA-compliant hosting like Healthcare Blocks, HIPAA Vault, or properly configured AWS/GCP/Azure does.
Your CMS provider if patient data enters the content management system. Most headless CMS platforms (Contentful, Sanity on standard plans) explicitly prohibit PHI in their terms of service. Self-hosted options like Directus or Payload CMS on your own infrastructure avoid this limitation.
Your form processor if forms collect health information. Standard contact form plugins don't offer BAAs. HIPAA-compliant form services include HIPAAtizer, Jotform's Gold/Enterprise tiers, and Formstack's HIPAA plans.
Your email provider if patient communications go through email. Standard personal Gmail or Outlook doesn't qualify. Google Workspace with HIPAA BAA, Paubox, or Microsoft 365 with BAA and proper configuration does.
Your analytics platform if you're tracking on pages with health-related content. See the analytics section above.
Vendors That Don't Need BAAs
Marketing tools used only for non-health content don't need BAAs. If your blog uses standard analytics but your patient portal uses compliant alternatives, that's a valid approach. The key is ensuring PHI never flows through non-compliant tools.
The 2025 HIPAA Updates
The HIPAA Security Rule received significant updates in 2025 with enforcement beginning in 2026. Key changes affecting websites: 24-hour breach notification to HHS for ransomware and unauthorized access (down from 60 days)
Mandatory encryption for all ePHI at rest and in transit. Previous "addressable" status allowed alternatives; now it's required.
Annual security audits with documented results
Network segmentation requirements separating systems containing ePHI
Multi-factor authentication for all systems accessing PHI
These updates make "we'll implement encryption later" approaches non-viable. Compliance needs to be built in from the start.
Technical Implementation Checklist
Hosting Requirements
| Requirement | Standard | HIPAA Compliant |
|---|---|---|
| BAA available | No | Yes |
| Encryption at rest | Sometimes | Required (AES-256) |
| Encryption in transit | Usually | Required (TLS 1.2+) |
| Audit logging | Basic | Comprehensive |
| Access controls | Basic | Role-based with MFA |
| Backup/DR | Varies | Documented procedures |
| Physical security | Shared | Dedicated or compliant cloud |
- Healthcare Blocks: $170/month starter, purpose-built for healthcare
- HIPAA Vault: $150/month, good for WordPress if you must use it
- AWS/GCP/Azure: Variable cost, requires proper configuration and signed BAA
- Railway: Works for custom solutions when no PHI is stored (like my Korawells project)
Form Security
Forms collecting any health information need: Encryption in transit: TLS for form submission (standard HTTPS)
Encryption at rest: Form data stored encrypted, not plain text
Access controls: Only authorized staff can view submissions
Audit logging: Track who views what submissions when
Data retention policies: Don't keep PHI longer than necessary
Disabled autocomplete: Prevent browsers from caching PHI in form fields. Add `autocomplete="off"` to sensitive form inputs.
For the Korawells wellness clinic project, we used Jotform's HIPAA-compliant tier with signed BAA. The site itself on Railway doesn't store any PHI. Form submissions go directly to Jotform's compliant infrastructure, accessible only to authorized clinic staff.
CMS Considerations
Most popular CMS platforms create compliance challenges: WordPress: The platform itself can be configured for compliance, but the ecosystem of plugins and themes introduces vulnerabilities. Every plugin is a potential security gap. Managed WordPress hosts like HIPAA Vault help, but you're still managing a complex stack.
Headless CMS (Contentful, Sanity): Standard plans prohibit PHI. Enterprise plans with BAA cost $60,000-80,000 annually.
Custom CMS: Building CMS functionality into your application codebase eliminates external vendor dependencies. No separate admin domain, no third-party API calls for content. I build custom content management into SvelteKit applications for clients who need this level of control. More on this approach in my WordPress alternatives guide.Common Compliance Mistakes
Mistake 1: SSL Certificate = HIPAA Compliant
Having HTTPS is necessary but not sufficient. Encryption in transit is one requirement among many. A site can have perfect SSL configuration while failing audit controls, access management, and BAA requirements.
Mistake 2: Privacy Policy = HIPAA Compliance
A privacy policy, even one mentioning HIPAA, doesn't create compliance. The policy describes practices; compliance requires implementing those practices with proper technical and administrative safeguards.
Mistake 3: Accessibility Overlay = ADA Compliance
Overlay widgets like accessiBe don't make websites compliant. Courts consistently rule that real accessibility requires fixing source code issues. These widgets often create new accessibility problems while failing to solve existing ones. The May 2026 HHS deadline for WCAG 2.1 AA compliance makes this particularly relevant for healthcare providers receiving federal funds.
Mistake 4: "We Don't Store Data" = No HIPAA Obligations
Transmission of PHI without storage still requires safeguards. If a contact form sends patient health information to staff email, that transmission needs encryption even if nothing is saved to a database.
Mistake 5: Internal IT Can Handle Security
HIPAA compliance involves legal, administrative, and technical components. IT departments handle technical implementation, but compliance requires documented policies, staff training, risk assessments, and incident response procedures that span organizational roles.
Cost Expectations by Practice Size
| Practice Size | Hosting | Forms | Analytics | Monthly Total | |
|---|---|---|---|---|---|
| Solo therapist | $150-200 | $9-30 | $0-23 | $10-15 | $170-270 |
| Small practice (2-5) | $150-300 | $30-50 | $23-100 | $40-75 | $240-525 |
| Mid-size (5-25) | $300-600 | $50-200 | $100-500 | $150-725 | $600-2,000 |
| Large clinic | $2,000-10,000+ | $200-1,000+ | $500-3,000+ | $300-625+ | $3,000-15,000+ |
My Approach to HIPAA-Compliant Websites
I build healthcare websites on SvelteKit rather than WordPress or React-based frameworks. The technical advantages align with compliance requirements: Smaller attack surface: No plugin ecosystem creating security vulnerabilities. A typical SvelteKit site ships around 42KB of JavaScript compared to 120KB+ for other frameworks.
Server-side security: Sensitive operations happen on the server, not in client-side JavaScript where they can be inspected or manipulated.
Performance benefits: Faster sites work better for senior patients and visitors on slower connections. This also supports accessibility compliance.
Custom CMS integration: Content management built into the same codebase eliminates external CMS vendor dependencies and their associated compliance concerns.
For projects requiring patient data handling, I architect solutions that minimize PHI touchpoints. Marketing content stays separate from patient data flows. Forms route to compliant processors. Analytics run only on non-sensitive pages or use privacy-first alternatives.
I work with clinics, therapists, telehealth platforms, wellness coaches, hormone optimization experts, and longevity practitioners across the US, Canada, UK, and Australia. Schedule a consultation to review your compliance requirements and technical options.
Transform your website into a revenue-generating asset
Partner with an award-winning Filipino web designer delivering world-class websites to global brands. 15+ years of experience creating sites that convert visitors into customers.
Frequently Asked Questions
-
If your website collects no patient data whatsoever, HIPAA may not apply to the website itself. But be careful: contact forms asking about health concerns, symptom checkers, or appointment requests mentioning conditions all create PHI. Most healthcare websites have at least some compliance obligations.
-
Yes, but it's harder than alternatives. You need HIPAA-compliant hosting with BAA, careful plugin selection (every plugin is a potential vulnerability), proper user access controls, and ongoing security maintenance. Many practices find this complexity isn't worth the perceived familiarity of WordPress.
-
HIPAA eligible means the vendor's infrastructure supports compliance if properly configured. HIPAA compliant means you've actually done the configuration, signed the BAA, and implemented required safeguards. AWS is HIPAA eligible; your properly configured website on AWS with signed BAA becomes HIPAA compliant.
-
Yes. Beyond standard HIPAA requirements, telehealth involves real-time video transmission of PHI, potential recording storage, and often integration with EHR systems. Video infrastructure must be HIPAA compliant with signed BAAs.
-
Get a security assessment. Check: Does your hosting provider have a signed BAA? Are forms encrypted and processed by compliant services? What analytics run on patient-facing pages? Is your CMS handling any PHI? Most practices discover gaps they didn't know existed.
-
HHS OCR audits examine your documented policies, technical implementations, risk assessments, staff training records, and incident response procedures. Having a compliant website is necessary but not sufficient. You need the documentation to prove compliance.