So when a practice owner asks us "is WordPress HIPAA compliant?", we give the honest answer most articles won't: that's the wrong question. WordPress is a content management system. It's not compliant or non-compliant any more than a filing cabinet is. What matters is what you let the website touch. A default WordPress install with a contact form storing entries in the database, a Meta Pixel in the header, and a public before/after gallery is a PHI leak waiting for a regulator. The same WordPress install, architected so that protected health information structurally cannot live on it, is one of the best marketing platforms a medical practice can run.

This is the architecture we build for every practice site we manage — what it looks like, why each piece exists, and how to check whether your current site would survive the same scrutiny. Updated for 2026.

The real problem: PHI on a marketing server

HIPAA's Privacy and Security Rules apply to protected health information wherever it lands. When a prospective patient fills out "I'd like a consultation for TMS therapy, here's my phone number" on your website, that combination — an identifier plus a health context — is PHI the moment your practice receives it. (Yes, even for a prospective patient contacting a covered entity about care.)

A stock WordPress form plugin does the worst possible thing with that submission: it writes it into the WordPress database, on a general-purpose web host, guarded by whatever password your front-desk admin chose in 2021, backed up who-knows-where, readable by every plugin on the site. Your marketing website just became a system that stores PHI — which means it now needs a BAA with the host, encryption, access controls, audit logging, and breach-notification obligations. Most practices have none of that on their WP host, and most WP hosts won't sign a BAA anyway.

A quick note on the legal landscape, because the "just get a BAA" verdict blogs get this wrong in both directions: in June 2024, the Northern District of Texas partially vacated OCR's online-tracking guidance — specifically the part that treated a visitor's IP address combined with visiting a health-condition page as PHI. That ruling narrowed OCR's most aggressive theory. It did not repeal HIPAA. Form submissions with names, phone numbers, and health concerns; appointment requests; intake data; patient photos — all of that is squarely PHI, and disclosing it to a vendor without a BAA, or storing it on an unsecured server, is exactly what the enforcement actions and state AG cases keep punishing. The vacatur is a footnote, not a permission slip.

There are two ways to respond to this:

1. The verdict-blog answer: "WordPress isn't HIPAA compliant, get a BAA, good luck." Technically cautious, practically useless — it leaves you with no working website strategy.
2. The architecture answer: design the site so PHI never lands on WordPress in the first place. Then WordPress goes back to being what it's great at — fast, SEO-friendly marketing pages — and the compliance burden sits on infrastructure actually built for it.

We build the second one. Here's the blueprint.

Principle 1: Forms that never store PHI on WordPress

Forms are where most practice sites fail. The fix isn't a "HIPAA form plugin" that encrypts entries in the same WP database — it's making sure the WordPress database never holds the entry at all.

On our sites, forms are still Gravity Forms on the front end — familiar editor, familiar styling. But the moment a visitor hits submit, the entry is POSTed server-to-server from the practice's web server directly to app.pilotpractice.com, our HIPAA-compliant platform, authenticated with a per-site bearer token. Three things about that design matter:

• Server-to-server, not browser-side. The submission travels from the site's server to ours over an authenticated backend request. There's no client-side JavaScript shipping form contents to a third-party endpoint where a tag manager, pixel, or browser extension could see it in flight.
• Per-site tokens. Every practice site holds its own credential. A token compromised on one site can't write into — or read from — anyone else's data. Tokens are scoped to ingest, not to query.
• The CRM record, not the WP row, is the system of record. Once the entry lands in our platform, it's inside infrastructure with field-level encryption, append-only audit logging, and access controls. What's left behind on WordPress is not a patient database.

Two side benefits fall out of this architecture that practices feel immediately:

Spam never reaches your CRM. Because submissions flow through our ingest pipeline, spam is filtered before it becomes a lead. Your front desk isn't triaging "SEO services for your website!!!" between real patient inquiries. We also roll out reCAPTCHA v3 fleet-wide across every site we manage — with automated verification and auto-revert if the deployment breaks a form on any individual site, so an anti-spam upgrade never silently costs a practice a week of patient inquiries.

Passwords are structurally unstorable. Some visitors paste things into forms they shouldn't — including passwords ("here's my patient-portal login so you can look at my chart"). Our ingest pipeline makes storing one impossible at three independent layers: password-shaped fields are blocked at ingest, stripped by the data-layer cast if anything slips through, and a retroactive scrub sweeps historical records. Not a policy that says "don't store passwords" — an architecture where there's no code path that can.

If you want the deep dive on this pattern — and the honest verdict on the plugin by itself — read Is Gravity Forms HIPAA compliant?

Principle 2: Booking never touches the WordPress database

The highest-value action on a practice website is booking an appointment — and it's also the highest-density PHI event: name, phone, DOB, appointment type, sometimes insurance. That data has no business anywhere near a WP database.

So on our sites, the booking experience is iframed off WordPress entirely. The visitor sees a booking flow embedded in the page, but the widget runs on our infrastructure, talks directly to the practice's EHR or PMS through one of our 30+ EHR/EMR integrations, and shows real, live availability. The appointment lands in the practice's actual schedule. WordPress serves the marketing page around it and never sees a byte of the intake.

This is a much stronger position than either alternative practices usually land on:

• A generic scheduler (Calendly-style) creates a second, disconnected calendar and a second vendor holding patient data — often without a BAA.
• A WP booking plugin puts appointment PHI right back into the database we just spent Principle 1 keeping clean.

Full treatment in HIPAA-compliant online scheduling: why EHR-integrated booking wins.

Principle 3: Assume the site will be attacked — and harden for it

Keeping PHI off WordPress dramatically shrinks the blast radius of a compromise, but a defaced or backdoored practice site is still a patient-trust disaster and a business-continuity problem. WordPress runs over 40% of the web; it is the most attacked CMS in existence. We manage practice sites at fleet scale, so we harden them like a fleet.

Fail-closed two-factor authentication

Every wp-admin login on every site we manage requires 2FA — and the policy is fail-closed and self-healing. Most 2FA setups fail open: an attacker (or a well-meaning staffer) who deactivates the plugin turns the protection off, silently, forever. Ours is enforced by automation that continuously verifies the 2FA policy is active and re-applies it if it's been disabled or misconfigured. Turning it off isn't a bypass; it's a condition the system detects and repairs.

Nightly allow-list malware scanning

Signature-based malware scanners answer "does any file match a known-bad pattern?" — which means they lose to any attacker who writes something new. Our nightly scanner inverts the question: "does every file on this site match a known-good allow-list?" Anything that isn't a known WordPress core file, a verified plugin/theme file, or an explicitly approved custom file gets flagged, every night, across the whole fleet.

The difference isn't academic. This scanner caught a real intrusion where the attacker had added their own backdoors to a compromised site's allow-list — a move designed specifically to beat this class of defense. The files didn't match our source of truth, the scan flagged them, and the site was cleaned. A signature scanner would have found nothing, because the backdoors were bespoke.

Why fleet-wide matters: bot attacks against WordPress aren't targeted, they're broadcast. Credential-stuffing runs and exploit scans hit every practice site the same week a vulnerability drops. A control that's "enabled on most of our sites" is a control that's off on the site that gets hit. Fleet enforcement — verified continuously by automation rather than a human checklist — is the difference between a policy and a posture.

Real backups, off the host

Every site is backed up to Google Cloud Storage — off the web host, so a compromised or failed host can't take the backups down with it. Recovery from defacement, a bad update, or a deleted page is a restore, not a rebuild.

Principle 4: Patient photos don't belong in Google's index

Before/after galleries are among the most persuasive content a surgical, dental, or aesthetic practice can publish — and among the easiest ways to violate patient trust at scale. A photo published with consent for your website was not consented for Google Images, where it detaches from its context, gets reverse-image-searched, and outlives the gallery page it came from.

Every patient gallery we build is noindexed: visible to the prospective patients browsing your site, invisible to search engines. Consent scope stays intact, and you're never in the position of asking Google to un-index a patient's face. (Consent documentation and what you can legally publish is its own topic — see Before & after photos and HIPAA.)

Principle 5: Analytics and pixels stay on the safe side of the line

Everything above keeps PHI off the WordPress server. The URMC and Froedtert cases were about the other direction: data flowing out of the page to ad platforms and analytics vendors. The same architecture answers it — measurement runs through a first-party pipeline that sends ad platforms conversion events, never form contents, with analytics routed through a scrubbing GA4 forwarder rather than a raw pixel (a forwarder design we're building into the platform). That's a full article of its own; start with the HIPAA-compliant marketing pillar guide for the tracking side, and note that "we removed the Meta Pixel" and "we can no longer measure our ads" do not have to be the same sentence.

What this looks like in practice on our sites: one first-party script, loaded from the practice's own domain, with a hard allowlist of what it may capture — UTM parameters and ad-platform click IDs, a visitor identifier, page context. No form field contents, ever, by construction. When a lead later books or shows up, the conversion is uploaded to Google or Meta as an offline event tied to the click ID — the ad platform learns "the click from campaign X converted," never who converted or why they came in. If a record needs to be pulled back (a consent revocation, a misclassified lead), retraction jobs remove the uploaded event. The practice keeps full-funnel measurement — cost per booked appointment, by campaign — without a single pixel firing on a page where a patient types.

The litmus test for any tracking setup, ours or anyone's: open your browser's network tab, submit a test form, and see which domains receive requests containing what you typed. On our sites the answer is one: the practice's own backend. If your current site's answer includes facebook.com, google-analytics.com, or a session-recording vendor, that's the URMC fact pattern, live, on your domain.

The checklist: is your WordPress site leaking PHI?

Run this against your current site. No email gate, no sales call — just look.

1. Submit your own contact form, then look in wp-admin. If the entry — name, phone, message — is sitting in a form plugin's entries screen, PHI is stored in your WordPress database. That's the single most common failure.
2. Ask your host for a BAA. If PHI is stored on the site (see #1) and the host won't sign, you have an unauthorized disclosure to a vendor, ongoing, every day.
3. View source on your homepage and a service page. Search for fbq(, gtag(, clarity, hotjar. Every third-party script on a page also loads on pages where patients type things.
4. Check who can log in, and how. How many admin accounts exist? Do all of them have 2FA? Can anyone disable it?
5. Google site:yourdomain.com with "before" or "gallery". If patient photos appear in results, your galleries are indexed.
6. Find your booking path. Does scheduling happen inside a WP plugin (PHI in the WP DB), on a third-party scheduler (second vendor, BAA status unknown), or off-site on HIPAA-compliant infrastructure?
7. Ask when the last off-host backup ran — and whether anyone has ever tested a restore.
8. Ask what would detect a backdoor file uploaded tonight. If the answer is a signature scanner or "nothing," assume nothing.

Two or more failures is normal — most practice sites fail five. For the tracking-side version of this exercise, run the 10-minute PHI leak self-audit.

"Should we just leave WordPress?"

Usually asked next, and usually the wrong move. Wix and Squarespace don't solve any of this — they can't do server-to-server form ingestion, won't sign BAAs, and give you less control over what loads on the page, not more (full verdict here). WordPress's real advantages for a practice — SEO performance, ownership, unlimited service/location page architecture — are exactly what a growing or multi-location group needs. The platform was never the problem. The untreated deployment was.

What this means for actually doing your marketing

Here's the part the verdict blogs never get to. The point of all this architecture isn't compliance for its own sake — it's that a practice with this foundation can market aggressively. You can run ads to landing pages with real forms, publish galleries, embed live EHR-integrated booking on every service page, and measure what converts — because the site was built so none of it creates a PHI problem. Compliance done right isn't a brake on marketing. It's what makes the marketing safe to floor.

You can build this yourself: server-to-server form ingestion into a HIPAA-compliant backend, fail-closed 2FA enforcement, nightly allow-list scanning, off-host backups, noindexed galleries, and booking iframed onto compliant infrastructure. It's real engineering and real ongoing operations — every one of these controls is only as good as the automation that keeps it on.

Or it's simply how your site works from day one. Every WordPress site PilotPractice builds ships with this architecture as the default, operated as a fleet, with the marketing — ads, SEO, content, booking — run on top of it by our team. HIPAA-compliant by default, and we actually run your marketing.

Book a demo and we'll walk through your current site against this checklist, live.

Security and compliance documentation, including our SOC 2 and HIPAA posture: trust.pilotpractice.com