Is WordPress HIPAA compliant? What medical practices must know

Is WordPress HIPAA compliant? The question assumes compliance is a feature of the CMS. It is not. HIPAA applies to covered entities and their business associates, and it judges how they handle protected health information, not which software they installed.

A medical practice can run a defensible website on WordPress. It can also run an indefensible one on any other platform. The difference sits in the hosting, the forms, the booking tool, the email path, the analytics tags and the vendors that sign agreements.

This guide maps that data path for practice owners and directors in the United States. It covers what counts as PHI on a site, who needs a business associate agreement, where forms and tracking tools leak, which safeguards matter and when a custom build beats a stack of plugins.

Is WordPress HIPAA compliant? The short answer#

No version of WordPress is certified, and none can be. There is no official HIPAA certification for software, hosts or plugins. When a vendor calls its product "HIPAA compliant", it usually means the product can be configured to support compliance and the vendor will sign a business associate agreement.

WordPress core is open-source publishing software. On its own it collects nothing from patients. The moment you add a form, a booking plugin, a chat widget or an analytics tag, you create a data path, and that path is what HIPAA examines.

Software is not certified, setups are assessed#

When the HHS Office for Civil Rights investigates a complaint or a breach, it looks at the entity, not the product. It asks whether you ran a risk analysis, applied safeguards that match it and signed the right agreements. The HIPAA Security Rule overview describes that approach, which is deliberately flexible and scalable.

So no seal protects you. A documented risk analysis, safeguards that match it and agreements with every vendor do.

Who is responsible: the practice and its vendors#

A covered entity is a health care provider that conducts certain transactions electronically, a health plan or a clearinghouse. A business associate is a vendor that creates, receives, maintains or transmits PHI on behalf of a covered entity. The Privacy Rule governs how PHI is used and disclosed. The Security Rule sets the safeguards for electronic PHI.

Responsibility stays with the practice even when a vendor does the work. Your web agency counts too if it can open form entries or read database backups. HIPAA is a United States law, so if you serve patients in Spain or Latin America, check local health data law as well.

What counts as PHI on a website#

PHI is individually identifiable health information held by a covered entity or business associate. Identifiers include names, email addresses, phone numbers, device IDs and IP addresses. Health context is anything that reveals a condition, care or payment for care. A name on a newsletter list is usually not PHI. The same name next to "new patient, knee pain" is.

A working rule: if a visitor can be identified and the data reveals something about their health or care, treat it as PHI.

Forms and intake questionnaires#

Intake forms are the obvious case. The quiet risk is the general contact form where people type symptoms into a free-text box. You cannot control what visitors write, so decide whether that form is allowed to receive PHI at all.

Online booking and patient portals#

A booking request ties a person to a provider, a service and a date. That is health information even when no diagnosis appears. Portals with logins add records, messages and billing, which raises every requirement.

Chat, email notifications and analytics#

Chat transcripts, notification emails and analytics events all copy data away from your form. Session replay and heatmap tools can record what people type into fields. Each copy needs the same protection as the original.

Business associate agreements: who must sign#

What a BAA actually covers#

A business associate agreement (BAA) is a written contract between a covered entity and a vendor that handles PHI for it. It limits how the vendor may use the data, requires safeguards, requires the vendor to report incidents and breaches, and extends the same duties to its subcontractors. The HHS business associate guidance explains the definition and the required contract terms.

A BAA makes a vendor accountable. It does not make the product secure, and it does not configure anything for you.

Vendors on a WordPress stack that need one#

Count the vendors that actually touch the data. A form plugin that stores entries in your own database is not a vendor receiving PHI, but your host is. A form plugin that forwards entries to a cloud service is.

• The host that runs the server and database
• The form service, or any SaaS the form posts to
• The booking or scheduling tool
• The email or SMTP service that delivers notifications
• The backup provider, including cloud storage
• Live chat and chatbot providers
• CRM or EHR connectors and any automation tool in the middle
• Your web agency, if it can reach entries or backups

The diagram follows one form submission across its hops. Each hop is a place where a BAA may be required.

Form submission path

1. 01Visitor browserPatient submits form over TLS
2. 02WordPress siteForm plugin receives the entry
3. 03Host and databaseBAA needed with the host
4. 04Email or CRMBAA needed with the vendor

Data path of one patient form submission across browser, WordPress, host and email or CRM, with a BAA needed at each hop

When a vendor will not sign#

Some vendors will not sign, and free plans rarely do. You have three options: choose a vendor that signs, stop sending PHI to that tool, or remove the tool from pages where PHI appears. Do not treat a line in standard terms of service as a BAA unless counsel confirms it.

HIPAA compliant forms and appointment booking#

Forms and booking are where a WordPress site meets patients, so they carry the most risk. A HIPAA compliant contact form on WordPress is less about the plugin brand and more about three questions: where do submissions go, who is notified, and who can read them later.

Where submissions are stored and sent#

A single submission often lives in three places: the WordPress database, an inbox and a third-party service such as a CRM or spreadsheet. Each copy is another place to protect, log and eventually delete. Transport must use TLS. Storage should be encrypted at the host level, and field-level encryption adds protection if the database is exposed.

Collect the minimum. Remove free-text fields from general forms, route sensitive requests to a dedicated form and keep entries only as long as you need them.

Email notifications are the usual leak#

The default behavior of most form plugins is to email the full submission to staff. That copies PHI into inboxes, phones and forwarding rules, usually over email that is not end to end encrypted.

Change the notification to a neutral message such as "New request received, sign in to review". Send it through a mail service that signs a BAA, and keep the sign-in behind multi-factor authentication.

Booking: embed a vendor or build it#

For HIPAA compliant appointment booking you have three realistic paths. The table compares them.

An embedded vendor is fastest if it signs a BAA and you keep your own tags off the page that embeds it. A plugin works for low volume if you control the email path. An API connection keeps patient data out of WordPress, which shrinks what you must defend.

Tracking pixels and analytics under HHS guidance#

Why a Meta pixel on a booking page is a problem#

HHS published a bulletin on online tracking technologies used by covered entities and business associates. Its core point: when a pixel or script on a regulated site sends identifiable visit data to a vendor, that can be a disclosure of PHI. A visit to an appointment page plus an IP address can be enough to show who is seeking care. Ad platforms and general analytics tools typically do not sign BAAs, and Google's own documentation says Google Analytics is not intended for PHI.

Legal status matters here. In June 2024 a federal court vacated part of the bulletin, the portion on tracking technologies on unauthenticated public pages. The rest of the guidance still stands, including its treatment of authenticated pages such as portals. Confirm the current status with counsel, and remember that state laws and other regulators, the FTC among them, also police health data tracking.

Safer measurement options#

You do not need to give up measurement. You need to decide where it is allowed.

• Remove all third-party tags from booking, portal, intake and symptom pages
• Restrict tags by URL in your tag manager, with a deny rule for sensitive paths
• Measure server-side, stripping identifiers and full URLs before data leaves your control
• Run self-hosted analytics on infrastructure covered by your host's BAA
• Use a vendor that signs a BAA, and keep that agreement on file

Audit the less obvious scripts too: session replay, heatmaps, chat widgets, embedded video and font loaders. A tag scan of the booking page takes minutes and tends to find surprises.

A HIPAA compliant WordPress site: technical safeguards#

The Security Rule groups requirements into administrative, physical and technical safeguards. Some specifications are required, others are addressable, which means you implement them or document an equivalent alternative. Here is how the technical ones translate into WordPress and hosting tasks.

Hosting and encryption#

For HIPAA compliant hosting on WordPress, ask for the BAA before you ask for the price. Most shared hosting plans do not sign one. Then check for TLS on every page with HSTS, encryption at rest, isolated environments, restricted staff access to servers and a list of the host's subcontractors. Keep the database off public access and force HTTPS for the admin area.

Access control and audit logs#

Every person gets a unique account with the least privilege that fits the job. Require multi-factor authentication for all administrators and editors, set session timeouts and remove unused users each quarter. Disable the theme and plugin file editor in the dashboard.

Add an activity log that records who viewed, exported or deleted form entries and who changed settings. Store logs away from the web server, limit who can read them and keep PHI out of the log text itself.

Backups, updates and retention#

Backups contain PHI, so encrypt them, store them with a provider under a BAA and test restores. Patch WordPress core, plugins and themes on a schedule, test on staging first and remove anything abandoned. Our post on web application security and the OWASP baseline covers the general layer, and the plugin problem explains why every extra plugin widens your exposure.

Retention needs two rules. HIPAA requires you to keep required documentation, such as policies and risk analyses, for six years. Medical record retention is set by state law, and form entries should have their own schedule. Also write down who runs incident response and how a breach is assessed and reported.

Plugin stack or custom build for patient data#

Neither answer is always right. The question is how many vendors, copies and logs you must defend.

When plugins are enough#

A marketing site that collects no health information can run on a normal plugin stack. A contact form that asks only for name, email and topic, with a clear note not to send medical details, is a low-risk case. Keep tracking off sensitive pages and keep the update routine.

When a custom plugin or integration is safer#

Once the site collects patient data, count the stack. For example, a practice with a form plugin, an SMTP plugin, a booking plugin, a chat widget and a cloud backup tool has five vendors, five agreements and five sets of logs. That is an illustrative setup, not a client case.

A custom plugin or API integration can post a form directly to your practice system over TLS, store nothing in WordPress, log every access and send neutral notifications. That leaves the host and the practice system as the vendors to cover.

Custom is not automatically safer. It is code you own, so it needs review, tests and updates. Our guide to custom WordPress plugin development covers when it pays off, and our integrations service covers the API side.

Where to start: a practice checklist#

Start with a map, not a purchase. Spend the first week on the actions below. The result is a short document your counsel or compliance officer can review and your developer can act on.

• Map every place patient data enters the site, including forms, booking, chat and email
• List every vendor that touches that data, including the host and your agency
• Get a BAA signed with each vendor, or remove the vendor from the data path
• Audit tags and pixels, and block them on booking, portal and intake pages
• Move forms off full-content email notifications
• Turn on multi-factor authentication, access control, activity logging and encrypted backups
• Set a plugin and core update routine with a staging test
• Write down who owns incident response and breach assessment

If you want a team to run the technical side, see our WordPress services or contact us. We build and maintain WordPress sites for companies that need controlled data paths. One more reminder: this is not legal advice, so have counsel review your risk analysis and agreements.

Frequently asked questions#