What HIPAA actually covers
The Health Insurance Portability and Accountability Act (HIPAA) is a US federal law. Per HHS's own guidance, it directly applies to "covered entities" — health care providers, health plans, and health care clearinghouses — and to their "business associates": any person or entity that performs functions or services on a covered entity's behalf involving access to Protected Health Information (PHI). A business associate can be a billing company, a cloud storage provider, an email service, or a web host — anything that creates, receives, maintains, or transmits PHI for a covered entity.
If a covered entity uses a business associate to handle PHI, HHS requires a written Business Associate Agreement (BAA) between them, spelling out exactly what the business associate is allowed to do with the data and requiring them to protect it under HIPAA's rules. A BAA isn't a formality — it's the legal instrument that makes it permissible for that vendor to touch PHI at all.
The question that actually decides whether HIPAA applies to your site
It isn't "are you a healthcare business." It's narrower: does your website ever create, receive, store, or transmit PHI? A large share of healthcare marketing sites can honestly answer no. A practice website that describes services, lists providers, publishes educational content, and gives visitors a way to call or email the office doesn't need to touch a single piece of health information to do any of that.
If the honest answer is no, HIPAA's technical safeguards simply don't apply to the site, regardless of how "medical" the subject matter looks. Ordinary page-view analytics and IP addresses collected on general, unauthenticated marketing pages are not PHI on their own. A vendor insisting that a purely informational practice website needs specialized "HIPAA-compliant hosting" is very often selling something the site doesn't actually require.
What flips the answer to yes
The line moves the moment a form, page, or integration starts handling identifiable health information tied to a specific person. Concretely, on a WordPress site this usually looks like:
- An appointment-request form that asks for symptoms, conditions, medications, or reason for visit — not just name and preferred time.
- A patient portal, secure messaging widget, or any login area where patients discuss their own care.
- A "contact us" form specifically inviting visitors to describe a health issue, even informally.
- Any integration — a chatbot, a scheduling widget, an email marketing tool — that receives and stores that kind of detail on the practice's behalf.
The moment PHI is flowing through a piece of the stack, every vendor that touches it — the form plugin's storage, the host, the email service that delivers the submission — becomes a business associate in that specific data flow, and needs a BAA before it's used that way.
Why most WordPress hosts and form plugins aren't set up for this
This is the part that trips people up in practice: most mainstream WordPress hosts, form plugins, and transactional-email services simply do not offer BAAs, because their business isn't built around HIPAA obligations. If a vendor won't sign one, it legally cannot be used to handle PHI, no matter how good its general security reputation is.
There's also a subtler, very common gap worth calling out specifically: a form plugin can be entirely self-hosted — meaning submissions never leave your own server, so the plugin itself has nothing to sign a BAA over — and still cause a compliance problem if it's configured to email every submission to a staff inbox. That email typically travels in plain text through a mailbox and mail service that were never covered by any BAA. The safeguard isn't just "pick a HIPAA-sounding plugin" — it's making sure PHI stays inside a covered storage and notification path end to end, not just at the point of submission.
Practical guidance for a WordPress site that does need to touch PHI
- Keep low-risk forms low-risk. A "request a callback" form that only collects name, phone number, and a preferred time carries far less exposure than one that asks what the callback is about.
- Route anything that touches PHI through a purpose-built, BAA-covered service rather than a general-purpose contact-form plugin — there are WordPress-specific tools and hosted form providers built specifically around HIPAA requirements, with a signed BAA available as part of the offering.
- Don't let submissions land in plain email if the form can collect health details — store them in a covered system instead of forwarding them to an inbox with no BAA behind it.
- Separate the marketing site from the PHI-handling piece where practical — many practices keep the public WordPress site purely informational and route anything that actually touches patient health data through a dedicated, compliant patient-portal or scheduling platform, rather than trying to make the whole WordPress install HIPAA-compliant.
Where a security plugin fits — and where it doesn't
A general WordPress security plugin, including SecurynAI, can genuinely help with the security hygiene that any HIPAA-relevant system needs: patching, monitoring for unauthorized access, alerting on suspicious activity, hardening the parts of the site that remain. What it cannot do is make a vendor into a signed business associate, or turn a non-compliant form plugin into a compliant one. Those are contractual and architectural decisions, not something a plugin configures on its own.
The honest bottom line
Most WordPress sites for healthcare-adjacent businesses — marketing pages, service descriptions, provider bios, general content — never touch PHI and never trigger HIPAA's technical requirements. The moment a form or feature starts collecting identifiable health information, the whole calculus changes, and that specific piece of the site needs vendors willing to sign a BAA, not just a security plugin doing its job well.
Whatever your compliance status, know what's actually happening on your site first.
Install free →