WordPress powers more than 43% of all websites globally, and thousands of healthcare organizations use it every day. The problem is that HIPAA compliance requirements and what WordPress actually delivers out of the box are two very different things.
Most covered entities discover this gap not through careful internal review, but during an OCR audit or after a breach that carries serious financial penalties.
In this blog, we will walk you through the most common HIPAA compliance pitfalls on WordPress, why they happen, and what you can do to fix them before an auditor finds them first.
TL;DR: Key Takeaways on HIPAA Compliance for WordPress Sites
- WordPress is not HIPAA-compliant in its default state and requires deliberate configuration to handle protected health information (ePHI) legally.
- A signed Business Associate Agreement (BAA) with your hosting provider is mandatory, not optional.
- Standard contact forms in default mode are not safe for collecting patient data.
- Every plugin that touches ePHI needs individual vetting and a BAA from its developer.
- WordPress has no native audit logging, which is a direct HIPAA requirement.
- Weak access controls and shared admin accounts are among the most cited causes of HIPAA violations.
- A formal HIPAA risk assessment is required by law, not just good practice.
Why WordPress is Not HIPAA Compliant Out of the Box?
WordPress was built to power content, not healthcare workflows. By default, it does not encrypt data stored in its database. It does not generate the audit logs HIPAA mandates.
- It also does not include a Business Associate Agreement. A BAA is a legally binding contract with any vendor handling ePHI on your behalf. Without one, you are already non-compliant before a patient fills out a single form.
- The HIPAA Security Rule requires covered entities to implement safeguards in three categories: administrative, physical, and technical.
On the technical side, this means encryption at rest and in transit, access controls with unique user identification, audit trails that log every interaction with ePHI, and transmission security that goes beyond a basic SSL certificate.
WordPress core addresses none of these requirements on its own. Compliance depends entirely on how you configure your hosting, which plugins you install, how you manage user accounts, and whether every third-party vendor in your stack has signed a BAA.
However, none of this means WordPress is the wrong choice for a healthcare website. It means it requires a deliberate, structured approach from the ground up.
How Seahawk Media Helps You Stay Compliant?
At Seahawk Media, we work with healthcare organizations, digital agencies serving healthcare clients, and WordPress developers who need to build compliant environments without becoming HIPAA experts overnight.
Our approach covers the full stack:
- Secure hosting partnerships with providers who sign BAAs.
- Plugin auditing to identify compliance risks before they become violations.
- Access control configuration that enforces the minimum necessary standard.
- Ongoing site maintenance that keeps your environment current as WordPress and HIPAA requirements evolve.
We also help teams understand what documentation they need to have on file, how to structure their vendor BAA inventory, and what a meaningful HIPAA risk assessment looks like in practice.
Compliance is not a one-time project. It is an ongoing responsibility, and having an experienced team behind you makes it significantly more manageable.
If you are running a healthcare website on WordPress and you are not certain whether your current setup meets HIPAA requirements, now is the right time to find out. Reach out to the Seahawk Media team to start the conversation.
Doing “Almost Compliant” Isn’t Enough
HIPAA compliance needs the right setup, not assumptions. We help you close the gaps before they turn into real problems.
The Most Common HIPAA Compliance Pitfalls in WordPress
Most healthcare organizations using WordPress are not one bad plugin away from a breach. They are one overlooked configuration away from an OCR investigation.
Here are the pitfalls that keep showing up in enforcement actions and exactly what you can do to avoid them.
Choosing a Host That Won’t Sign a BAA
This is the single most common and most consequential mistake healthcare organizations make. Popular hosting providers like Bluehost, Hostinger, and SiteGround are excellent for most websites. For a site that collects, stores, or transmits patient information, they are simply not an option unless they are willing to sign a Business Associate Agreement.
- A BAA is not a formality. It is a legal document that establishes what a vendor is permitted to do with ePHI, how they must protect it, and what will happen in the event of a breach.
- Under HIPAA, if your hosting provider touches ePHI without a signed BAA in place, your organization is automatically noncompliant, regardless of any other security measures you have implemented.
The solution is straightforward but requires doing your homework before you buy. Liquid Web and WP Engine both offer managed WordPress hosting environments designed for HIPAA-aligned deployments.
They provide dedicated infrastructure, encrypted storage, intrusion detection, and, most importantly, they will sign a BAA. Seahawk Media can help you identify the right hosting configuration and ensure your entire stack is built on a compliant foundation from day one.
Using Standard Contact Forms to Collect Patient Data
A patient fills out an appointment request form on your website. They include their name, date of birth, phone number, and a brief note about their condition. That combination of identifiable information and health context is ePHI the moment it touches your system.
If you are using WPForms in its default configurations, that data is likely stored unencrypted in your WordPress database and delivered to your inbox via standard email, neither of which meets HIPAA requirements.
The issue is not the form plugin itself. WPForms, for example, can be part of a compliant setup when configured correctly. The issue is that default configurations prioritize convenience, not compliance.
For a form to handle ePHI safely, submissions need to be encrypted in transit and at rest, stored in a secure environment outside the standard WordPress database where possible, and the form provider must sign a BAA. Standard email delivery of form submissions is never acceptable for ePHI.
If your forms collect anything linking a person to a health condition, treat them as a compliance risk.
Installing Plugins Without Vetting Them for PHI Access
WordPress’s plugin ecosystem is one of its greatest strengths. It is also one of its biggest compliance vulnerabilities in a healthcare context.
Many popular plugins quietly send data to external third-party servers. Analytics tools, live chat widgets, CRM connectors, booking systems, and even some SEO plugins can transmit user-submitted data off your server without you ever knowing.
Under HIPAA, if a plugin developer can access ePHI because their software processes or stores it, that developer is a business associate. That means they need to sign a BAA.
Most plugin developers have never considered this and will not sign one. Jetpack, for instance, is a widely used plugin that connects your WordPress site to Automattic’s infrastructure.
Before using it on a healthcare site, you need to understand exactly what data it transmits and whether Automattic will execute a BAA for your specific use case.
SolidWP offers a strong foundation for WordPress security hardening and is worth reviewing as part of your overall plugin strategy. The broader principle, however, is that every plugin on a healthcare site needs to be evaluated through a compliance lens before installation, not after.
Skipping Audit Logs and Activity Monitoring
HIPAA requires organizations to track who accessed ePHI, what they did with it, and when. This is not optional, and WordPress does not handle it automatically.
Out of the box, WordPress keeps no meaningful record of user activity beyond basic login events. If a staff member views a patient record, exports a form submission, or changes access permissions, there is no log of it unless you have specifically configured one.
WP Activity Log is a plugin that fills this gap. It creates detailed records of user actions across the WordPress admin, including content edits, user role changes, login attempts, and plugin activations. This continuous logging enables you to respond to an OCR investigation with evidence of compliance rather than assumptions.
The keyword here is continuous. Turning on audit logging the week before an audit is not a compliance strategy. It needs to be running from the moment your site handles any form of patient data.
Weak Access Controls and Shared Admin Accounts
Shared login credentials are a direct HIPAA violation. HIPAA requires unique user identification, meaning that every person who accesses a system containing ePHI must have their own account and credentials.
- Shared passwords eliminate accountability because there is no way to trace an action back to a specific individual.
- Beyond shared accounts, many WordPress healthcare sites hand out far more access than staff actually need. A team member who only updates blog posts should never hold administrator-level access.
Yet many sites give them exactly that. That level of access lets them view form submissions, install plugins, and change backend settings. HIPAA’s minimum necessary standard is clear on this. You must limit access to ePHI to only what each person needs to do their job.
The fix involves assigning custom user roles with granular permissions, enforcing multi-factor authentication for every account with backend access, and immediately revoking access when a staff member changes roles or leaves the organization.
Managed environments implement some of these controls at the infrastructure level, reducing the risk of human error in day-to-day administration.
Ignoring SSL or Using Outdated Encryption Protocols
A valid SSL certificate is the starting point for transmission security, not the finish line. Many healthcare sites install a free SSL certificate and consider the job done. In reality, HIPAA’s transmission security requirements go significantly further.
Your site needs to enforce HTTPS across every page and every form, use TLS 1.2 or higher with weak cipher suites disabled, and implement HSTS to prevent protocol downgrade attacks.
Really Simple SSL is a useful tool for enforcing HTTPS site-wide and can handle some of the basic configuration automatically. However, it does not address database encryption, backup encryption, or the server-level TLS configuration that proper HIPAA compliance requires.
Those elements need to be managed at the hosting level, which is another reason why your choice of host is so foundational to everything else.
No Incident Response or Breach Notification Plan
HIPAA’s Breach Notification Rule requires covered entities to notify affected individuals, the Department of Health and Human Services, and in some cases the media within 60 days of discovering a breach.
Most WordPress-based healthcare sites have no documented plan for what to do in those 60 days. When a breach occurs, the absence of a plan does not pause the clock. It just means you are making critical decisions under pressure without a framework to guide you.
A basic incident response plan covers five stages: detection, containment, assessment, notification, and documentation.
On the technical side, tools like BlogVault and WPvivid Backup support disaster recovery by maintaining encrypted, off-site backups that let you quickly restore a clean version of your site.
However, technical recovery tools alone do not satisfy HIPAA’s breach notification requirements. The plan itself needs to be written down, assigned to specific individuals, and tested before you need it.
Skipping the HIPAA Risk Assessment Entirely
This is the violation that appears most frequently in OCR enforcement actions, under 45 CFR §164.308(a)(1)(ii)(A), every covered entity is legally required to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to ePHI across all the systems that create, receive, maintain, or transmit it.
A security plugin does not satisfy this requirement. A compliance checklist does not satisfy this requirement. A formal, documented risk assessment does.
The risk assessment is not a one-time event. It needs to be repeated every year. It also needs updating whenever you change your hosting environment, add new plugins, or onboard new vendors. Its purpose is to find gaps before an auditor or a breach does. It also creates a documented remediation plan that shows OCR you are actively managing compliance, not just assuming it.
Many WordPress site owners operating in healthcare have never done one. If that describes your situation, it is the single most urgent compliance action you can take.
Seahawk Media works with healthcare organizations to conduct structured HIPAA risk assessments and translate the findings into concrete, actionable improvements to their WordPress environments.
What a HIPAA-Compliant WordPress Setup Actually Looks Like?
After walking through everything that can go wrong, it helps to have a clear picture of what you are working toward. A properly configured HIPAA-compliant WordPress site is built on five pillars, and each one needs to be in place before you can genuinely claim compliance.
- HIPAA-compliant hosting with a signed BAA.
- End-to-end encryption at rest and in transit.
- Role-based access controls with MFA enforced.
- Continuous audit logging and activity monitoring.
- Documented incident response and breach notification plan.
Beyond these five pillars, a compliant setup also requires a complete vendor inventory, with every third-party tool that touches ePHI having a signed BAA on file; regular security scanning and plugin audits to catch new vulnerabilities before they are exploited; and a formal risk assessment that is updated at least annually.
The goal is not to build a healthcare site that looks secure. It is to build one that can demonstrate compliance with OCR through documentation, logs, and, if needed, signed agreements. That distinction matters enormously when an enforcement action begins.
Final Thoughts
HIPAA compliance on WordPress is entirely achievable. Thousands of healthcare organizations run WordPress safely and effectively every day. The ones that stay out of trouble treat compliance as a foundation, not an afterthought. Building it in from the start costs far less than fixing it after a breach forces you to.
The pitfalls covered in this post are the ones that appear repeatedly in enforcement actions precisely because they are easy to miss. A missing BAA, an unconfigured form plugin, a shared admin password, and a missing audit log. None of them is exotic.
All of them are fixable. The first step is knowing where to look, and the second step is working with people who can help you fix what they find.
If you are ready to get serious about HIPAA compliance for your WordPress site, the Seahawk Media team is here to help you do it right.
FAQs About HIPAA Compliance Pitfalls
Can WordPress be made HIPAA-compliant?
Yes, but not in its default state. WordPress can support a HIPAA-compliant deployment when hosted on infrastructure that has a signed BAA, is configured with appropriate access controls and encryption, supports audit logging, and is maintained through a regular risk assessment process. Compliance depends on the entire environment, not just the CMS itself.
Does my hosting provider need to sign a BAA?
Absolutely. Any hosting provider that can access or handle ePHI qualifies as a business associate under HIPAA. That makes a signed BAA legally required, not optional. Operating without one puts your organization out of compliance, regardless of everything else you have configured. Always confirm BAA availability before you sign up with any host for a healthcare site.
Which WordPress plugins are safe to use on a healthcare site?
There is no universal safe list because the answer depends on how each plugin handles data and whether its developer will sign a BAA. Every plugin that transmits or stores user-submitted data externally needs individual vetting.
Tools like SolidWP for security hardening and WP Activity Log for audit trails are strong options. Still, any plugin touching ePHI must be reviewed in the context of your specific compliance setup.
What happens if my WordPress site violates HIPAA?
Penalties vary based on the severity of the violation and whether the covered entity knew about the risk. Fines range from $100 to $50,000 per violation, with an annual cap of $1.9 million per violation category.
Beyond financial penalties, breaches require formal notification to affected individuals and HHS, and repeated violations can result in corrective action plans that impose significant operational restrictions.
