So: is Gravity Forms HIPAA compliant?

The short answer: Gravity Forms out of the box is not HIPAA compliant, because it stores every form entry — name, phone, "reason for visit," everything — in your WordPress database. But the plugin itself isn't the problem. The storage architecture is. Configure Gravity Forms so entries never touch WordPress at all, and it becomes one of the safest intake front-ends a medical practice can run.

This article explains exactly how that works, because it's the architecture we run across the practices we manage.

Why default Gravity Forms is a HIPAA problem

Gravity Forms is a form builder. When a visitor hits submit, the default behavior writes the entry to the wp_gf_entry and wp_gf_entry_meta tables in your WordPress database, and usually emails a copy to the front desk.

Walk through what that means for a medical practice:

• Your WordPress database now contains PHI. A name plus "interested in TMS for depression" is protected health information. It's now sitting in MySQL on a shared host, next to your blog posts.
• Everyone with wp-admin access can read it. Your SEO contractor, the intern who updates hours, the theme developer from 2023 whose account nobody deactivated — all of them can open Forms → Entries and read patient submissions.
• Your hosting company is now handling PHI without a BAA. Most shared and managed WordPress hosts will not sign a Business Associate Agreement on standard plans. The moment PHI lands in that database, you have a business-associate relationship on paper that doesn't exist in contract.
• Backups multiply the exposure. Every database backup — the host's, your backup plugin's, the zip a developer downloaded to their laptop — is another copy of PHI with no audit trail.
• Notification emails leak it again. "New entry" emails carry the full submission into Gmail or Outlook inboxes, often without encryption in transit guarantees, and definitely without access logging.
• WordPress gets breached constantly. WordPress powers a huge share of the web precisely because it's extensible — and every plugin is attack surface. A compromised site with stored entries is a reportable breach; a compromised site with an empty entries table is a defacement.

Gravity Forms (the company, Rocketgenius) does not sign BAAs, and doesn't need to — the plugin runs on your server. The compliance burden is entirely on where the data goes after submit. Which is exactly the lever you control.

The server-to-server architecture: entries that never exist in WordPress

Here's how we deploy Gravity Forms across every practice site we build (full WordPress hardening approach here):

1. On submit, the entry POSTs server-to-server to the platform — and is deleted from WordPress. The submission is transmitted from the web server directly to app.pilotpractice.com over TLS, into a HIPAA-compliant CRM with field-level encryption, access logging, and a signed BAA. This is not JavaScript firing data from the visitor's browser to a third party (the pattern that created the pixel-lawsuit era). It's a server-to-server handoff, invisible to the browser, with nothing retained in the WordPress database. Your website becomes what it should be: a pass-through, not a datastore.

2. Every site authenticates with its own bearer token. Each practice website holds a per-site credential. The platform knows exactly which site sent which submission, a stolen token from one site can't impersonate another, and a single site's credential can be revoked instantly without touching the fleet. Compare that with the default architecture, where "authentication" is whoever can reach wp-admin.

3. Spam never reaches the CRM. Submissions are screened before they become records, and the fleet runs reCAPTCHA v3 with monitored rollout. That matters for compliance, not just tidiness: bot-stuffed junk entries in a PHI system pollute audit trails and inflate the surface of "data" you're responsible for protecting.

4. Passwords are structurally unstorable — three independent layers deep. Patients do the darnedest things, including typing passwords into open text fields ("here's my portal login so you can check my records"). Our ingest pipeline enforces, in three separate places, that a password can never persist:

• an ingest block that rejects password-shaped data at the point of intake,
• a cast strip at the model layer, so even if a value slipped past intake, it cannot be written to the field,
• a retroactive scrub that sweeps stored records and removes anything that got through historically.

Any one layer failing still leaves two. That's what "structurally unstorable" means — it isn't a policy asking staff not to save passwords; the system is physically incapable of it.

5. What patients see doesn't change. Same Gravity Forms front-end, same styling, same conditional logic and field types your team already knows. The compliance work happens entirely behind the submit button.

The result: the practice keeps the best form builder in the WordPress ecosystem, and the WordPress database holds zero patient submissions. A full site compromise exposes brochure content, not intake data.

The ungated checklist: audit your forms in 15 minutes

Run this on your own site today. No email required.

1. Open Forms → Entries in wp-admin. If you see patient submissions, PHI is stored in WordPress right now. That's the finding.
2. Check how far back entries go. Years of retained entries = years of unlogged, unencrypted PHI in every backup ever taken.
3. List everyone with wp-admin access — including agencies and ex-contractors. Each account is a person who can read patient entries with no audit trail.
4. Ask your host for a BAA. If they won't sign one (most won't on standard plans), PHI cannot live on that server.
5. Check notification emails. Do "new entry" emails contain the full submission? Who receives them? On what mailbox, under what BAA?
6. Check the anti-spam setup. No CAPTCHA means bots are writing to your PHI store.
7. Check third-party form add-ons. Zapier, Mailchimp, and Google Sheets feeds each copy PHI to another vendor — each needs its own BAA (spoiler: Mailchimp won't sign one).
8. Verify the fix, not the promise. After moving to server-to-server delivery, submit a test entry and confirm the WordPress entries table stays empty.

If item 1 already failed, don't panic-delete — export nothing, forward nothing, and get a plan for compliant migration and secure disposal of historical entries and backups.

Gravity Forms vs. "HIPAA form" SaaS tools

Jotform, IntakeQ, and similar tools offer HIPAA plans with BAAs, and they're legitimate. The trade-offs: monthly per-form pricing, iframe embeds that fight your site's design and conversion tracking, and — the big one — the data lands in another silo that doesn't talk to your CRM, your call tracking, or your booking system. The server-to-server Gravity Forms architecture delivers submissions straight into the same HIPAA-compliant platform that handles your scheduling, attribution, and follow-up. One BAA, one system, no swivel-chair.

It also pairs naturally with vertical-specific intake design — see our guides for therapy practices and med spas & aesthetics.

Verdict

Is Gravity Forms HIPAA compliant? Not as installed — default entry storage puts PHI in your WordPress database, and that alone is disqualifying. But re-architected so every submission POSTs server-to-server to a BAA-covered platform with a per-site bearer token, with nothing stored in WordPress, it's the strongest intake stack on the platform that already runs your website. The plugin was never the risk. The database was.

Actually running intake as a marketing channel

A compliant form that nobody fills out is a very safe zero. Once the architecture is right, the work that grows a practice is ordinary marketing discipline: put a short form above the fold on every service page, keep it to the fields you genuinely need (every extra field costs conversions), route submissions into a CRM that fires a follow-up within minutes — speed-to-lead is the whole game — and track which channel produced each patient without leaking PHI to ad platforms.

That's the part we do for practices every day. PilotPractice builds the site, wires the server-to-server intake, signs the BAA, and runs the marketing — SOC 2 and HIPAA controls documented at trust.pilotpractice.com, and the full playbook in our 2026 HIPAA-compliant marketing guide.

Wondering what your site is leaking right now? Run the free PHI scanner — it checks your pages for trackers and form-data exposure in about a minute, no email gate. Or book a demo and we'll walk your current stack with you.

PilotPractice security & compliance documentation: trust.pilotpractice.com