Can You Build a HIPAA-Compliant Website with WordPress?

Yes, you can run a HIPAA-compliant healthcare website on WordPress, but WordPress itself does not make you compliant and no plugin does either. Compliance comes from the architecture around it: where protected health information (PHI) lives, who has signed a Business Associate Agreement (BAA), how data is encrypted, and what you can prove in an audit. We have built practice sites, clinic portals and patient intake flows on WordPress, and the pattern that works is the same every time: keep PHI out of WordPress wherever possible, and lock down everything that remains.

This guide covers what HIPAA actually asks of a website, which parts of a WordPress stack are affected, the hosting and form decisions that matter most, and the mistakes we see practices make again and again.

What HIPAA actually requires of a website

HIPAA applies to covered entities (providers, health plans, clearinghouses) and to their business associates (any vendor that creates, receives, maintains or transmits PHI on their behalf). A brochure site that lists your clinic hours, doctors and a phone number does not handle PHI and is not in scope. The moment a visitor types “I need an appointment for my diabetes follow-up” into a contact form, you are collecting PHI and the Security Rule applies to every system that touches it.

The Security Rule breaks down into three groups of safeguards:

• Administrative: a documented risk analysis, workforce training, access policies, an incident response plan and signed BAAs with every vendor in the PHI path.
• Physical: control over the servers and devices that store PHI. For a website this is mostly your hosting provider’s responsibility, which is exactly why the hosting BAA matters.
• Technical: unique user IDs, access controls, audit logs, integrity controls, and encryption of PHI in transit and at rest.

One regulatory note worth knowing. In January 2025 HHS published a proposed update to the Security Rule that would make encryption at rest and in transit, multi-factor authentication, vulnerability scans every six months, annual penetration tests and a 72-hour restoration plan mandatory rather than “addressable”. The rule has not been finalised as of August 2026 (the OMB agenda now points to mid-2027), but auditors are already treating those items as the expected baseline. Build to that standard now and you will not need to rebuild later. The HIPAA Journal tracker is a reliable place to watch the status.

The first decision: where does PHI actually live?

Every HIPAA WordPress project should start by drawing a simple data-flow map. List every place a patient can submit information and trace where that information ends up: the WordPress database, an email inbox, a third-party SaaS, a CRM, a backup file, a log. Each stop on that map needs a BAA and needs to meet the technical safeguards.

In practice you have two architectures to pick from.

Option A: PHI never touches WordPress

WordPress serves the public site (services, providers, locations, blog, insurance information). Anything that collects PHI is handled by a dedicated, HIPAA-ready service that signs a BAA: an embedded Jotform HIPAA form, a patient portal from your EHR vendor (Athena, eClinicalWorks, Kareo and similar all provide embeddable scheduling), or a telehealth platform. The embed is an iframe or script; the data posts directly to the vendor and never enters your database or email.

This is the architecture we recommend for most small and mid-sized practices. Your WordPress install stays out of scope for PHI, your hosting requirements relax to “good security hygiene”, and your compliance burden collapses to a handful of vendor BAAs.

Option B: WordPress stores or processes PHI

If you need custom intake workflows, a member area with patient records, or forms whose submissions stay in WordPress, you are now running a PHI system. That means HIPAA-grade hosting with a BAA, encrypted database fields, audit logging at the application level, strict role management, and a plugin inventory you can defend in an audit. It is doable, we have done it, but budget two to three times the effort of option A and plan for annual reviews.

Pick A unless you have a concrete reason to pick B.

Hosting: the BAA is non-negotiable

Automattic, the WordPress.org project and most mainstream managed hosts will not sign a BAA. If your site stores or transmits PHI, your host must. A handful of providers specialise in this: Atlantic.Net, HIPAA Vault, Liquid Web’s HIPAA plans and Kinsta’s enterprise HIPAA tier are the names we see most. Expect to pay from roughly $100 a month for a small managed VPS to several hundred for a dedicated, fully managed environment. Compare that with a $30 shared plan and it sounds steep, but a single OCR settlement starts in six figures.

What a genuine HIPAA hosting plan gives you beyond a signature:

• Encrypted disks (AES-256 at rest) and TLS 1.2+ enforced for every connection.
• Isolated environments rather than shared tenancy.
• Centralised audit logging with retention (six years is the HIPAA documentation retention period).
• Managed OS patching, intrusion detection and a documented backup and restore procedure.
• Staff who have signed confidentiality agreements and completed HIPAA training.

Ask two questions before signing: “Will you provide your most recent risk assessment or SOC 2 report?” and “What exactly is excluded from the BAA?” Many BAAs exclude the application layer entirely, which means WordPress, its plugins and your users remain your problem.

Forms: the most common compliance failure

Contact and appointment forms are where most healthcare WordPress sites break HIPAA without anyone noticing. The default behaviour of WPForms, Gravity Forms, Contact Form 7 and Formidable is to store the entry in the database and email a copy to the front desk. That email is unencrypted PHI sitting in Gmail or Outlook, and neither Google Workspace nor Microsoft 365 is covered unless you are on a plan with a signed BAA and have configured it correctly.

Here is how the mainstream options compare.

Tool	Signs a BAA?	Where entries live	Our take
Jotform (Gold or Enterprise)	Yes	Jotform’s HIPAA-enabled servers	Simplest path for option A sites. Embed and forget.
Gravity Forms	No	Your WordPress database	Fine only on HIPAA hosting with encryption add-on, entries restricted, notifications stripped of PHI.
Formidable Forms	No	Your WordPress database	Same conditions as Gravity. Field-level encryption needs a third-party add-on.
WPForms / Contact Form 7	No	Database (WPForms) or email only (CF7)	Avoid for PHI. CF7’s email-only flow is the worst case: PHI in plain-text mail.
EHR-provided scheduling widget	Yes (under your EHR BAA)	Your EHR	Best option when your EHR offers one. Data lands where staff already work.

If you must use a self-hosted form plugin, do all of the following:

1. Change every notification email so it says only “A new appointment request has arrived. Log in to view it.” No field values in the email body.
2. Restrict entry viewing to a dedicated role (not Editor or Administrator shared by the whole office) and enforce two-factor authentication for that role.
3. Encrypt sensitive fields at rest. For Gravity Forms, the Encrypted Fields add-on from Pluginsmiths or a custom solution using sodium_crypto_secretbox() hooked on gform_save_field_value works.
4. Set an automatic purge. Entries older than 30 days should be deleted once they have been transferred into the EHR.
5. Confirm your backups are encrypted too, because every backup now contains PHI.

Hardening the WordPress layer

Whichever architecture you choose, the WordPress install itself needs to be defensible. Security plugins do not confer compliance, but the controls below map directly to Security Rule requirements and an auditor will look for them.

Access control and authentication

Give every staff member their own account (HIPAA requires unique user identification; shared logins fail immediately). Enforce two-factor authentication for all users with WP 2FA, Wordfence Login Security or Solid Security. Set minimum password length to 14 characters, limit login attempts, and remove accounts the day someone leaves. Use the least privileged role that does the job; a receptionist who only reads form entries does not need Administrator.

Audit logging

WordPress does not log user activity by default. Install WP Activity Log (or Stream) and ship the logs off-site to your host’s logging service or a SIEM. You need to answer “who viewed this patient’s entry and when” for six years.

Encryption in transit

Force HTTPS everywhere, redirect HTTP, enable HSTS, and disable TLS 1.0 and 1.1 at the server. Test with Qualys SSL Labs and aim for an A rating. Set FORCE_SSL_ADMIN to true in the wp-config file.

Plugin and theme discipline

Outdated plugins are the leading cause of WordPress breaches in healthcare. Keep a written inventory of every plugin with its purpose, vendor and update cadence. Remove anything unused. Subscribe to Patchstack or Wordfence vulnerability feeds so you hear about a CVE before an attacker exploits it. Test updates on staging, then apply to production within a defined window (we use seven days for normal updates and 24 hours for critical security releases). WordPress 7.1 shipped on 19 August 2026 with a React 19 upgrade under the editor, which is a good reminder that major core releases can break older plugins; staging is not optional.

Backups and recovery

The proposed rule’s 72-hour restoration requirement is a sensible target anyway. Take daily encrypted backups to a location covered by a BAA (your HIPAA host’s backup service, or S3 with server-side encryption under the AWS BAA). Run a restore drill twice a year and document it. If you want a shortlist of tools, our backup plugin comparison covers the options, but on a PHI site the host-level backup is the one you rely on.

Analytics, chat widgets and tracking pixels

In December 2022 HHS published guidance saying that tracking technologies on authenticated pages, and in some cases public pages, could expose PHI. A federal court vacated the broadest part of that guidance in June 2024, which relaxed the rules for public pages. That does not make analytics risk-free. Meta Pixel and Google Ads tags still send page URLs and identifiers to vendors who will not sign a BAA, and class actions over pixel use on hospital sites continue.

Our working rules:

• No third-party scripts on any page behind a login or on any page that handles PHI (forms, portals, symptom checkers).
• On public pages, prefer a privacy-focused analytics tool that signs a BAA or runs on your own infrastructure (Piwik PRO’s healthcare plan, or self-hosted Matomo on your HIPAA server). If you keep Google Analytics 4, turn off Google Signals, shorten retention, and keep it off condition-specific pages.
• Live chat only from vendors with a BAA. A generic chat widget that lets a visitor type “I think I have an STI” has just created PHI in an uncovered system.

A realistic build plan for a small practice

Here is what we would do for a three-provider clinic that needs a public site, online appointment requests and a newsletter, with no patient portal in WordPress.

1. Scope and map. Confirm the only PHI entry point is the appointment request form. Everything else is marketing content.
2. Hosting. Because PHI does not enter WordPress, use a reputable managed host with strong security (Kinsta, WP Engine, Pressable). Skip the HIPAA tier unless the scope changes.
3. Form. Embed a Jotform HIPAA form for appointment requests. Route submissions to the practice manager’s Jotform inbox and to the EHR via Jotform’s integration. No email notifications containing field data.
4. Newsletter. Use a mailing tool for general health tips only. Never segment by condition. Collect email and first name, nothing else.
5. WordPress hardening. Unique accounts, 2FA, activity logging, HTTPS with HSTS, limited plugin set, automatic minor updates, weekly review of major updates on staging.
6. Analytics. Privacy-first analytics on public pages only; no pixels on the appointment page.
7. Paperwork. Collect BAAs from Jotform and any other vendor in the PHI path. Write the risk analysis, the access policy and the incident response plan. Train staff annually and keep the records.
8. Review. Re-run the data-flow map every twelve months or whenever a new tool is added. Most compliance drift happens when someone installs “just one more plugin”.

If your needs go beyond this (patient education gated by login, provider-only communities, intake that must live in WordPress), the same principles apply but the implementation needs a developer who has done it before. Our security hardening service covers the technical controls above, and we can build custom intake and portal workflows through custom plugin development when off-the-shelf tools will not do.

Frequently asked questions

Is there a plugin that makes WordPress HIPAA compliant?

No. Plugins can supply individual controls (2FA, logging, encryption) but compliance is the combination of hosting, vendors, configuration, policies and training. Any product that advertises “one-click HIPAA compliance” is overselling.

Do I need a BAA if my site only has a contact form?

If the form can reasonably receive health information (and “describe your concern” fields always do), yes. Either move the form to a vendor that signs a BAA or make sure your host, form storage and email provider are all covered.

Can I use WordPress.com for a healthcare site?

For a pure marketing site with no PHI collection, yes. For anything that collects PHI, no. Automattic does not sign BAAs.

Does an SSL certificate make my forms compliant?

It covers encryption in transit only. Data at rest in your database, in email and in backups still needs protection, and you still need access controls, logs and BAAs.

What happens if we get it wrong?

OCR restarted its audit programme in 2025 and continues to settle cases, with penalties scaled by level of negligence. Beyond fines, a breach notification to every affected patient does lasting damage to a practice’s reputation. The cost of doing it right is small by comparison.

Where to start

Draw the data-flow map today. If PHI only enters through one or two forms, move those forms to a BAA-backed service this week and you have removed most of your risk in an afternoon. Then harden the WordPress install, write the policies, and schedule the annual review. WordPress is a perfectly good foundation for a healthcare site; it just needs to be treated as one component of a compliant system rather than the whole answer.