Disclaimer: This article provides technical guidance on building WordPress websites that support HIPAA compliance requirements. It is not legal advice. HIPAA compliance involves organizational policies, staff training, and legal agreements beyond website configuration. Consult a healthcare compliance attorney for your specific situation.
Here’s the question we hear most from healthcare clients: “Can WordPress be HIPAA compliant?”
The honest answer is: WordPress is a content management system. It’s not compliant or non-compliant on its own, just like a filing cabinet isn’t HIPAA compliant or non-compliant — it depends on where you put it, who has the key, and what you store in it.
A default WordPress installation on a $10/month shared hosting plan with Contact Form 7 sending patient inquiries over unencrypted email? That’s a HIPAA violation waiting to happen. The same WordPress, configured correctly on HIPAA-eligible infrastructure with proper encryption, access controls, audit logging, and a signed Business Associate Agreement? That can absolutely meet HIPAA requirements.
This guide walks through every layer of a HIPAA-compliant WordPress website: what HIPAA actually requires from your site, how to choose hosting, how to handle forms and patient data, which plugins to use and avoid, and how to maintain compliance over time. It’s written for practice owners and developers who need to get this right — not for compliance officers who already know the regulations.
⚠️ IMPORTANT: This article covers the TECHNICAL SECURITY RULE requirements. HIPAA compliance also includes the Privacy Rule (policies, procedures, patient rights) and Breach Notification Rule. A compliant website is one piece of a larger compliance program.
What HIPAA actually requires from your website
HIPAA doesn’t mention WordPress, plugins, or hosting providers. It establishes standards for protecting Protected Health Information (PHI) — any individually identifiable information about a patient’s health, treatment, or payment. The Security Rule specifies technical safeguards. These are the requirements that directly affect how you build and run a WordPress site.
The technical safeguards that matter for your website
Encryption in transit. All data transmitted between the user’s browser and your server must be encrypted. In practice: SSL/TLS (HTTPS) everywhere, no exceptions. Every page, not just forms. This also means any email containing PHI must be encrypted — standard SMTP email is not.
Encryption at rest. PHI stored on your server — in the database, in files, in backups — must be encrypted. Standard WordPress does not encrypt database contents. Your hosting environment needs to provide disk-level or database-level encryption.
Access controls. Only authorized individuals should access PHI. In WordPress terms: unique user accounts for every person (no shared logins), role-based permissions (receptionist doesn’t get admin access), strong password policies, and ideally two-factor authentication.
Audit logging. You must be able to track who accessed what PHI and when. WordPress doesn’t do this natively. You need an activity logging plugin that records login attempts, data access, content changes, and user actions with timestamps.
Automatic session management. Sessions must expire after inactivity. If a staff member walks away from their computer while logged into WordPress with patient data visible, the session should time out. Default WordPress sessions can last days.
Backup and disaster recovery. PHI must be recoverable. Encrypted backups, stored securely, tested regularly. Standard WordPress backup plugins that store unencrypted copies on Google Drive or Dropbox don’t meet this requirement.
Business Associate Agreements (BAAs). Any third party that has access to PHI on your behalf must sign a BAA. That includes: your hosting provider, your email service (if PHI goes through email), any SaaS tools that touch patient data, your maintenance provider, and potentially your developer.
Choosing HIPAA-eligible WordPress hosting
This is where most HIPAA WordPress projects either succeed or fail, because your hosting provider is the foundation everything else sits on. If the infrastructure isn’t compliant, nothing you do at the WordPress level matters.
What HIPAA-eligible hosting provides
Encryption at rest (disk-level or database-level). Encrypted backups stored in a compliant environment. Physical security and access controls for the data center. Willingness to sign a Business Associate Agreement. Incident response procedures. Regular security audits and compliance documentation.
Hosting types and HIPAA
Standard shared hosting: Not HIPAA eligible. You share server resources with other sites, your provider almost certainly won’t sign a BAA, and you have no control over encryption at rest. This includes most plans from GoDaddy, Bluehost, SiteGround, and similar providers.
Managed WordPress hosting: Most managed WordPress hosts (WP Engine, Kinsta, Flywheel) do not offer HIPAA-eligible plans by default. Some offer enterprise tiers with BAAs, but verify this directly — don’t assume.
HIPAA-specific hosting: Providers like Liquid Web (with their HIPAA-compliant offering), AWS with a signed BAA and proper configuration, Google Cloud Platform with a BAA, and specialized healthcare hosting companies. These are designed for PHI from the ground up.
Cloud infrastructure (DIY): AWS and GCP will sign BAAs, but the BAA covers their infrastructure — you’re responsible for correctly configuring encryption, access controls, logging, and everything at the application level. This is powerful but requires significant DevOps expertise.
💡 KEY DECISION: For most small-to-medium practices, a HIPAA-specific managed hosting provider is the right choice. It’s more expensive than standard hosting ($200–$500/month vs $30–$100), but the provider handles infrastructure compliance, encryption, and will sign a BAA. Trying to DIY HIPAA on raw cloud infrastructure is cost-effective at scale but risky for organizations without dedicated DevOps.
Questions to ask your hosting provider before signing
Will you sign a Business Associate Agreement? Do you provide encryption at rest for the database and file system? Where are backups stored and are they encrypted? What’s your incident response procedure for a potential data breach? Can you provide documentation of your last security audit or SOC 2 report? Do you support two-factor authentication for server access? What are the physical security controls at your data center?
If they hesitate on the BAA question, they’re not the right provider. Full stop.
Less Code Support Plans
Need help choosing the right infrastructure for a healthcare WordPress site?
We’ve built compliant healthcare sites for clinics and practices.
Let’s talk about your requirements →
Handling forms and patient data on WordPress
Forms are the highest-risk element on a healthcare WordPress site. They’re where patients submit PHI, and they’re where most HIPAA violations happen — usually because the site owner didn’t realize that a simple contact form could be a compliance problem.
Why standard WordPress forms are a problem
A typical WordPress contact form does two things that violate HIPAA: it stores the submission in the WordPress database in plain text (accessible to anyone with database access), and it sends the submission via standard unencrypted email. If a patient fills out your “request an appointment” form and writes “I need to see a doctor about my diabetes medication,” that’s PHI traveling through unencrypted channels and sitting in an unprotected database.
Contact Form 7, WPForms, Gravity Forms — none of these are HIPAA compliant out of the box. That doesn’t mean you can’t use forms on a healthcare WordPress site. It means you need to handle the data differently.
Approaches that work
Option 1: Don’t collect PHI through forms. The simplest approach. Your website form collects only non-PHI information: name, phone number, “I’d like to schedule an appointment” (without asking what for). The actual health information is collected during the call or through your EHR’s patient portal. This limits your website’s compliance surface area dramatically.
Option 2: Use a HIPAA-compliant form service. Services like JotForm (HIPAA plan), Formstack (HIPAA plan), or Hushmail offer form solutions with built-in encryption, BAAs, and compliant data handling. The form is embedded on your WordPress site but data is processed and stored in the service’s compliant infrastructure, not in WordPress. This is the most practical option for most practices.
Option 3: Encrypt data within WordPress. Some plugins and custom solutions can encrypt form data before it reaches the WordPress database and route notifications through encrypted email or secure messaging. Gravity Forms with specific encryption add-ons, configured on HIPAA-eligible hosting, can work — but requires careful setup and verification. Not recommended unless you have a developer with HIPAA experience.
Option 4: Route to your EHR/patient portal. Instead of handling PHI in WordPress at all, your website links directly to your EHR’s patient portal for anything that involves health information. The website handles marketing and general information; the patient portal handles clinical interactions. WordPress stays clean of PHI entirely.
⚠️ CRITICAL: Whichever approach you choose, never send PHI via standard unencrypted email. This is the single most common HIPAA violation on healthcare websites. If your form sends an email notification containing patient information, that notification must go through an encrypted email service.
WordPress plugins: what to use, what to avoid, and what to verify
Every plugin you install on a HIPAA-compliant WordPress site introduces potential risk. Plugins have access to your database. Some make external API calls. Some store data on third-party servers. Each one needs evaluation.
Essential plugins for HIPAA compliance
Activity logging. WP Activity Log (or similar) provides the audit trail HIPAA requires. It records who logged in, what they accessed, what they changed, and when. Configure it to log database access and content changes. Store logs for a minimum of six years (HIPAA retention requirement). This is non-negotiable.
Two-factor authentication. Wordfence, WP 2FA, or similar. Every user account with access to the WordPress admin — or to any page that could display PHI — needs 2FA enabled. Not optional, not “nice to have.”
Session management. Configure automatic session timeouts. The default WordPress session can last up to 48 hours with “remember me.” For HIPAA, set sessions to expire after 15–30 minutes of inactivity. Plugins like Inactive Logout handle this.
Security hardening. Wordfence or Sucuri for firewall, malware scanning, and brute force protection. Standard WordPress login allows unlimited password attempts — you need rate limiting and lockout policies.
SSL enforcement. Really Simple SSL or server-level configuration to force HTTPS on every page. No mixed content. No HTTP fallbacks.
Plugins to scrutinize or avoid
Analytics plugins that send data to third parties. Standard Google Analytics is generally fine for marketing pages (it tracks behavior, not PHI). But if your site has authenticated areas where patients interact, be careful about what gets tracked. IP addresses combined with health-related page visits could constitute PHI.
Chat widgets and chatbots. Live chat plugins where patients might disclose health information send that data to the chat provider’s servers. Unless the chat provider signs a BAA and stores data compliantly, this is a violation. Most standard chat widgets (Intercom, Drift, Tidio) don’t offer healthcare-compliant plans.
Email marketing plugins. If you’re collecting email addresses from patients and using Mailchimp, ActiveCampaign, or similar, be aware: if those lists contain patient information (or if the list itself constitutes PHI because it’s “people who visited a specific health clinic”), you need a BAA with the email provider. Most standard plans don’t include one.
Any plugin that phones home. Some plugins send usage data, error reports, or license checks to external servers. Review what data each plugin transmits. If it could include PHI (even inadvertently through form data in error logs), it’s a compliance risk.
💡 RULE OF THUMB: Every plugin on a HIPAA WordPress site should be evaluated with one question: does this plugin have access to PHI, and if so, where does that data go? If the answer involves an external server without a BAA, the plugin is a compliance risk.d if so, where does that data go?
Appointment booking on a HIPAA-compliant WordPress site
Online booking is increasingly expected by patients, and it’s one of the most effective ways to reduce phone call volume and fill schedules. But on a HIPAA site, the booking system needs to meet the same standards as everything else.
What makes a booking system HIPAA-ready
The booking form collects PHI the moment it asks for a patient’s name and the type of appointment (which implies a health need). A HIPAA-ready booking system needs encrypted data transmission (HTTPS for the form submission), compliant data storage (encrypted at rest, with access controls), no unencrypted email notifications containing patient details, audit logging for booking access and changes, and either coverage under your hosting BAA or its own BAA if it’s a third-party service.
Your options
Embed your EHR’s built-in scheduling tool if it has one. Route to a HIPAA-compliant scheduling service (like Healthie, Luminello, or SimplePractice) that handles everything on their compliant infrastructure. Use a WordPress booking plugin on HIPAA-eligible hosting with proper configuration — but verify that the plugin doesn’t send unencrypted email notifications or store data in ways that bypass your hosting’s encryption.
Less Code Support Plans
Building a healthcare website that needs HIPAA compliance and online booking? We build these systems.
Tell us about your practice →
Maintaining HIPAA compliance over time
Building a compliant site is step one. Keeping it compliant is the ongoing work, and it’s where most violations eventually happen — not from a bad initial build, but from drift.
Regular security updates
Every unpatched WordPress core, theme, or plugin vulnerability is a potential breach vector. On a standard site, a delayed update is a nuisance. On a HIPAA site, a delayed update that leads to a breach is a reportable incident. Updates should be tested on staging and applied weekly, not quarterly.
Quarterly access reviews
Review who has WordPress admin access. Remove former employees immediately (ideally on their last day, not “when someone gets around to it”). Verify that role permissions are appropriate. Check that 2FA is still enabled for all accounts. This is the kind of task that seems trivial until an audit asks for documentation and you realize the former office manager still has admin access six months after leaving.
Annual risk assessment
HIPAA requires a documented risk assessment. For your website, this means: reviewing what PHI the site collects and how it’s handled, verifying that all BAAs are current, testing backup recovery, reviewing audit logs for anomalies, verifying encryption status, and documenting any changes made during the year. This isn’t optional — it’s explicitly required by the Security Rule.
Staff training
Every person who interacts with your WordPress site in a way that could involve PHI needs to understand what they can and can’t do. Sharing login credentials, discussing patient information in unencrypted channels, downloading patient data to personal devices — these are policy violations that no amount of technical configuration can prevent. Training should happen at onboarding and annually.
Incident response plan
Know what to do if something goes wrong. A suspected breach has specific notification timelines under HIPAA (60 days to affected individuals, immediate to HHS if over 500 people affected). Having a documented plan before an incident means you respond correctly and on time instead of scrambling.
HIPAA WordPress compliance: layer by layer
Here’s a consolidated view of every layer and what each one needs:
| LAYER | REQUIREMENTS | HOW TO IMPLEMENT |
| Hosting | Encryption at rest, BAA, physical security, incident response, audit documentation | HIPAA-specific hosting provider or configured AWS/GCP with signed BAA |
| SSL/TLS | Encryption in transit on all pages, no mixed content | SSL certificate (Let’s Encrypt or paid), force HTTPS server-side + plugin |
| WordPress core | Kept up to date, hardened configuration | Weekly updates on staging, disable XML-RPC, limit login attempts, security headers |
| User access | Unique accounts, role-based permissions, 2FA, session timeouts | No shared logins, WP 2FA plugin, Inactive Logout plugin, minimum necessary permissions |
| Audit logging | Track all access to PHI, login events, content changes | WP Activity Log, configured for 6-year retention minimum |
| Forms | No PHI in plain text, no unencrypted email, compliant storage | HIPAA-compliant form service (JotForm, Formstack) or EHR portal routing |
| No PHI in standard email, encrypted alternatives | Encrypted email service (Hushmail, Paubox) or avoid email for PHI entirely | |
| Plugins | Evaluated for PHI access, external data transmission, BAAs where needed | Audit each plugin, remove unnecessary ones, verify no external PHI transmission |
| Backups | Encrypted, stored compliantly, tested regularly | Hosting-level encrypted backups or encrypted backup plugin with compliant storage |
| Booking | Encrypted data, compliant storage, no plain-text notifications | EHR scheduling, HIPAA-compliant booking service, or configured plugin on HIPAA hosting |
| Maintenance | Weekly updates, quarterly access reviews, annual risk assessment | Professional support plan or documented internal maintenance schedule |
| Legal | BAAs with all business associates, Privacy Policy, Notice of Privacy Practices | Healthcare attorney review, BAAs with hosting, form, email, and maintenance providers |
The bottom line
WordPress can support a HIPAA-compliant healthcare website. But it doesn’t do it by default, and it doesn’t do it cheaply. Every layer — hosting, forms, email, plugins, access controls, backups, and maintenance — needs deliberate configuration.
The practices that get this right typically share two characteristics: they take the compliance requirement seriously from day one instead of trying to retrofit it later, and they work with developers who have actually built HIPAA-compliant sites before (not just standard WordPress sites with an SSL certificate added after the fact).
HIPAA compliance is not a feature you toggle on. It’s an architecture you build intentionally, a set of policies you enforce consistently, and an ongoing commitment you maintain over time. The website is one piece. But it needs to be the right piece, built the right way.
