Is WordPress HIPAA Compliant?
Written by Jessica Freeman, Web Designer and SEO Strategist since 2011 • Post Last Updated September 2026
WordPress is not HIPAA compliant out of the box, and no CMS, no matter how it is marketed, really can be. Compliance is not something a piece of software carries around with it. It is a property of the system around that software: who hosts it, what data touches it, and what agreements are in place with everyone in between.
Here is the good news: if your WordPress site is your public-facing front door, your services pages, your blog, your about page, a booking widget that hands off to a separate scheduling platform, you are already living in the lowest-risk category. Most practices never store protected health information inside WordPress itself, which means you’re probably safe.
The place this gets tricky is forms. A contact form that lets someone type a message, a symptom description, or medical history directly into your WordPress database is where it gets really messy. If you have already read the piece on Google Analytics and HIPAA, this one picks up right where that left off, since tracking pixels and analytics scripts show up again here as a WordPress-specific problem too.
Is WordPress HIPAA compliant out of the box?
No, and there is no version of WordPress, free or paid, self-hosted or managed, that changes that answer. The HIPAA Security Rule applies to the entire operational environment, and the federal government does not certify software as HIPAA compliant in the first place. Any hosting company or plugin advertising “HIPAA certified” is making a claim that technically does not exist under the law.
A standard WordPress install with no forms collecting health information, no patient portal, and no clinical data stored anywhere on the site carries very little of the regulatory weight. The requirements kick in when protected health information starts flowing through the site, and for a lot of practices, it simply never does. Your website talks about your services and lets people book a consultation elsewhere!
What makes WordPress a HIPAA risk in the first place?
WordPress core does not encrypt form submissions by default, it does not log who accessed which records, and it does not automatically log administrators out after a period of inactivity. Standard login sessions can persist for two weeks if someone checks “remember me.” Plugins run with full access to the same database as everything else on the site, so one poorly maintained extension can become a door into anything sensitive stored there.
None of that matters if there is nothing sensitive to find. This is why it’s important to use a software like PracticeBetter for forms and questionnaires, so that the information is protected. There’s risk when just a basic form starts asking about condition, treatment history, insurance details tied to a diagnosis, or anything that reads like an intake questionnaire.
Does WordPress count as a Business Associate under HIPAA?
No. A Business Associate is a vendor that creates, receives, maintains, or transmits protected health information on behalf of a covered entity, and neither the WordPress Foundation nor Automattic, the company behind WordPress.com, will sign a Business Associate Agreement for the open-source software itself. There is no BAA to sign because WordPress core is not a service, it is a codebase you install somewhere else.
Under 45 CFR § 164.308(b) and § 164.504(e), a covered entity cannot let a vendor touch protected health information without that signed agreement in place first. Standard shared hosting from providers like Bluehost or a basic WordPress.com plan explicitly refuses to sign one and prohibits health data in their terms of service outright.
If your site is only handling marketing content, that refusal is irrelevant to you.
What happens if patient information ends up in your WordPress forms or database?
For the majority of practice sites, this section is a non-issue, because there is no patient information in WordPress to begin with.
If your site does collect anything clinical through a standard contact form plugin, the most common failure point is not the database itself, it is the notification email. Most form plugins are configured by default to email a full copy of every submission to an inbox, and that email travels across standard, unencrypted mail servers with no BAA covering any of it.
A practice that thinks its forms are “just for convenience” can end up disclosing symptom descriptions to an ordinary Gmail inbox without anyone realizing that happened. You would need to turn off detailed notification emails, or routing them through a HIPAA-compliant email service.
What are HIPAA compliant alternatives for handling patient information on a WordPress site?
If you do need to collect anything clinical, there are two options:
| Approach | How it works | Who signs the BAA | Best fit |
|---|---|---|---|
| Decoupled hosted forms (Jotform Enterprise, Formstack, LuxSci) | Form is embedded on your WordPress page, but submissions route directly to the vendor’s own compliant system. Nothing touches your WordPress database. | The form vendor, directly with your practice | Practices that want to keep using standard WordPress hosting for everything else |
| Self-hosted forms on BAA-covered hosting (Gravity Forms or WPForms on a compliant host like HIPAA Vault or Liquid Web) | Submissions land in your own WordPress database, but the entire hosting environment is under a signed BAA and hardened accordingly | Your hosting provider | Practices that want full control over the data and are prepared for more setup and maintenance |
| Standard contact form plugin on regular commercial hosting | Submissions save in plain text and often email out over unencrypted SMTP | Nobody. No BAA exists in this setup at all | Fine only when the form never collects anything clinical |
How can you reduce HIPAA risk on a WordPress site if you do collect patient information?
Turning off detailed form notification emails is the single highest-impact fix, since it closes the most common real-world leak. Enforcing multi-factor authentication for every WordPress login, not just the admin account, closes off the most common way these sites get compromised in the first place. Keeping plugins current and removing anything abandoned or rarely updated shrinks the risk as well.
None of this is a substitute for BAA-covered hosting if ePHI is genuinely going to live in your WordPress database. Configuration reduces exposure. It does not create the legal agreement that makes handling that data lawful in the first place. If you are in the category where none of this applies because your site never touches patient information, just confirm that is actually true, and keep it that way as your forms and plugins change over time.
Frequently asked questions
Does using a page builder like Divi or Kadence change any of this? No. Page builders control how your site looks, not how data moves once someone submits a form or how your hosting environment is secured. A beautifully designed intake form on standard shared hosting carries the exact same risk as a plain one.
My site only has a “request an appointment” button that links out to Jane App or SimplePractice. Am I in the clear? Generally, yes. If the actual booking and intake happens on a separate, already-compliant platform and WordPress is only linking out to it, patient information never touches your WordPress database in the first place. That is the decoupled approach working exactly as intended, even if you did not set it up with HIPAA in mind.
Do I need to worry about this if I am a solo practitioner with a simple site? The size of your practice does not change the requirements, but it usually does change how much work is involved. A solo site with a handful of pages and a basic contact form is quick to audit.
Final thoughts
For most practice websites, the honest answer to “is WordPress HIPAA compliant” is that the question does not fully apply, because the site was never going to hold patient data in the first place.
The one part of this worth revisiting periodically is your forms. A site that starts as a simple contact page can slowly grow an intake questionnaire, a symptom checklist, or a “tell us about your situation” field without anyone deciding that on purpose.
If you want a second set of eyes on your setup, whether that is confirming you are in the clear or figuring out what needs to change, that is the kind of audit I do. Reach out and we can walk through it together!
