Is Gravity Forms HIPAA Compliant? WordPress Intake

No, Gravity Forms is not HIPAA compliant on its own, and it will not sign a BAA. Gravity Forms states plainly that because it does not host or store your collected form data, it will not sign such agreements. That is a different answer from a SaaS vendor refusing, because the data never leaves your server. The BAA question moves to your WordPress host, and the compliance work moves to your configuration. Curve is the HIPAA-compliant tracking and attribution layer that measures those form conversions without patient data reaching ad platforms, with a signed BAA on every plan.

The direct answer, in more detail

Almost every "is X HIPAA compliant" question is really a question about a vendor's servers. Does the vendor receive your data, and will they sign a contract accepting business associate obligations for it. Gravity Forms breaks that pattern, because it is licensed software that runs inside your own WordPress installation.

When a patient submits a Gravity Forms entry, the data goes into your WordPress database, on infrastructure you or your host control. Gravity Forms the company never sees it. Their documentation says exactly this, and draws the conclusion: as they do not host or store your collected form data on your behalf, they will not sign any such agreements.

That is not evasion. It is accurate. A vendor who never receives PHI is not your business associate, and a BAA with them would protect nothing. The company is equally clear that it does not claim to be HIPAA compliant as a product, because compliance depends on hosting, storage, plugins, and data management practices that sit outside its control.

So the verdict is conditional in an unusual direction. Gravity Forms can be part of a HIPAA-compliant intake process. It cannot make one, and buying the plugin transfers no obligation away from you. Every requirement the software does not satisfy remains yours.

Who your business associates actually are

If the plugin is not the business associate, someone is. Work through the list for a typical WordPress clinic site and it gets longer than people expect.

• Your web host. This is the primary one. The host stores the database containing your form entries, and if that includes PHI, the host needs a signed BAA. Most mainstream shared and managed WordPress hosts do not offer one. Some do, usually on specific plans.
• Your backup provider. Backups contain the same entries. An off-site backup service holding a copy of your database is holding PHI.
• Your email delivery service. Form notifications go out through an SMTP relay or transactional email vendor. If the notification includes entry contents, that vendor is processing PHI.
• Your CDN or security proxy, if it terminates TLS and sees request bodies.
• Any plugin or add-on that transmits data outward. CRM connectors, payment add-ons, spam filtering services, and analytics integrations each send data somewhere.
• Your development agency, if they have database or admin access. Contractors with access to PHI are business associates too.

This is the real shape of the problem. A SaaS form builder concentrates the risk in one vendor you can evaluate. Self-hosting distributes it across a stack you assembled incrementally and probably never inventoried.

What Gravity Forms does not do for you

Gravity Forms is well-built software. It is also general-purpose software, and several HIPAA-relevant gaps are default behavior rather than bugs.

Storage encryption. Gravity Forms states that by default, the data it collects is not encrypted during storage. Entries sit in plain text in your WordPress database. Encryption at rest has to come from the database layer, the host, or an add-on built for it.

Access control. WordPress roles are coarse. Anyone with entry-viewing capability can read every entry on the site, and administrator accounts see everything by definition. HIPAA expects access limited to the minimum necessary, which WordPress does not model natively.

Audit trails. There is no built-in record of who viewed which entry and when. Audit logging is a plugin decision, and most sites do not make it.

Transport encryption. Gravity Forms notes this depends on your environment and sits outside the product's design. TLS is your host's job, and it needs to be enforced site-wide, not just on the form page.

Retention. Entries accumulate indefinitely unless someone configures otherwise. A five-year-old intake form on a marketing site is a quiet archive of patient data nobody remembers exists.

The notification problem

The single most common way PHI escapes a self-hosted WordPress intake form is not a breach. It is the notification email.

Gravity Forms sends an email when an entry is submitted, and the default template includes all submitted fields. That email travels through your mail infrastructure to staff inboxes, which are frequently ordinary business email accounts, sometimes on a domain with no BAA covering the mail provider, sometimes forwarded to a personal address, and often synced to phones with no device management.

You have taken a form entry that was arguably contained on your own server and broadcast it across several vendors and devices in a single automated step. Every one of those hops is a disclosure.

The fix is content-free notification. The email says an entry was received and links to an authenticated location where staff log in to read it. That single change eliminates most of the exposure in a typical WordPress intake setup and costs nothing but a template edit.

The architecture that works

A defensible WordPress intake stack looks like this:

• Hosting with a signed BAA, confirmed in writing, on the specific plan you are actually on.
• TLS enforced everywhere, with HSTS, and no mixed content on form pages.
• Encryption at rest, from the database layer, the host, or a purpose-built add-on that encrypts entry values.
• Content-free notifications and no entry data in any outbound email.
• Least-privilege roles plus audit logging, so entry access is limited and recorded.
• A short retention policy, enforced automatically, with entries moving to your clinical system of record and being deleted from WordPress.
• An inventory of every add-on that transmits data outward, with a BAA question answered for each destination.
• A hardened WordPress core, because the plugin surface is the attack surface. A vulnerable unrelated plugin reaches the same database as your intake entries.

An alternative worth considering seriously: do not store intake in WordPress at all. Use the form to capture contact details and a request for a callback, and move clinical intake to a system built for it. A form that only collects a name, a phone number, and "I would like to book" is dramatically easier to defend than one that collects symptoms. Our guide to PHI-safe healthcare form configuration works through what to ask and what to leave out.

Payments deserve their own analysis, since a Gravity Forms payment add-on introduces a processor into the picture. See our verdict on whether Stripe is HIPAA compliant for patient payments.

Where the ad tracking problem shows up

Everything above concerns data at rest on your own infrastructure. The advertising layer is where a self-hosted form leaks data to third parties, and it leaks in ways that self-hosting does nothing to prevent.

A WordPress clinic site typically carries a Meta Pixel and a Google tag, often installed by a plugin. Those scripts run in the visitor's browser on the same page as your form. They see the URL, which on a treatment page names the condition. They see a persistent browser identifier. On submission they frequently fire a conversion event, and depending on configuration that event can carry form field values, the form name, and the page path.

Meta and Google do not sign BAAs for their advertising products, so those calls are disclosures to vendors with no agreement in place. This is the mechanism behind healthcare pixel litigation, which has cumulatively crossed $100 million in settlements, with Advocate Aurora settling at roughly $12.225 million. The plaintiffs' theory does not require that a diagnosis was transmitted. It requires that an identifiable person's health interest was disclosed to a third party.

There is a particular WordPress trap here. Pixel-management plugins market themselves on automatic event tracking, which means they detect forms and fire enriched conversion events without anyone configuring what goes in them. Automatic is the opposite of what a healthcare site wants. You want deliberate.

How Curve handles WordPress intake tracking

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare. It replaces the client-side pixels on your WordPress site with a server-side path, so the decision about what reaches an ad platform is made on infrastructure you have a BAA with rather than in the visitor's browser.

The Curve tracking script installs in place of the Meta Pixel and Google tag. Events go to Curve's US-hosted infrastructure. From there:

• Per-destination field mapping controls what forwards. Only fields you explicitly map reach a given destination, configured separately for each one. Form field values, page URLs, and form names stay behind unless you deliberately map them. The default is that nothing goes.
• Identifiers are hashed. Email, phone, and name are SHA-256 hashed to each platform's conversion API requirements before forwarding, which is what makes conversion matching work without shipping raw contact details to an ad platform.
• Neutral event aliases replace descriptive names. A submission on a treatment-specific intake form forwards as a generic conversion rather than one naming the service, so the ad platform interface never displays the condition.
• PHI-pattern detection monitors payloads. Curve flags PHI-shaped values such as SSNs, MRN-style identifiers, dates, and long numeric sequences. On a WordPress site where a plugin update can change form behavior overnight, that monitoring layer is how you find out. The protection itself is the field mapping plus the hashing.
• Bridge tokens preserve attribution across handoffs. When your form hands the patient to a separate booking or intake tool, attribution normally breaks at exactly the moment it becomes valuable. Bridge tokens carry it across.
• Incoming webhooks match downstream outcomes back to the original click by email, click ID, or bridge token, and cannot override protected core attribution fields.
• Offline conversion uploads close the loop. Bulk CRM or EHR outcomes match to the originating ad click by click ID, so revenue reporting never requires exporting an entry list to an ad platform.

Clean conversions forward server-side to Meta CAPI, Google Ads Enhanced Conversions, TikTok Events API, Microsoft, and LinkedIn. Because the path is server-side, ad blockers and browser tracking prevention stop suppressing it, which usually raises measured conversion volume rather than lowering it. Every Curve plan includes a signed BAA. For what happens after submission, see our guide to HIPAA-compliant lead routing from ad click to CRM.

What to check on your own WordPress site

1. Get your host's BAA in writing and confirm it applies to the plan you are on, not just to an enterprise tier you could buy.
2. Open a notification email and read it. If it contains entry values, change the template today.
3. Look at your oldest form entries. Retention problems are always older than expected.
4. List every user who can view entries and ask whether each one needs to.
5. Inventory every add-on that sends data anywhere, including spam filtering and CRM connectors, and answer the BAA question per destination.
6. Check whether your backups leave your host and where they land.
7. Watch the network tab during a test submission and read what leaves for ad platform domains. Our free compliance scanner does the first pass automatically.

Frequently asked questions

Will Gravity Forms sign a BAA?

No. Gravity Forms states that because it does not host or store your collected form data on your behalf, it will not sign such agreements. The BAA you need is with your web host, since that is where the entries live.

Does a HIPAA add-on make Gravity Forms compliant?

An add-on can close specific gaps, most usefully encryption of entry values and isolated storage. It cannot supply a compliant host, least-privilege access, audit logging, retention enforcement, or discipline about notification emails. Read carefully what any add-on vendor's own BAA actually covers, since it typically covers only the data their service holds.

Is a self-hosted form safer than a SaaS form builder?

It is different, not automatically safer. Self-hosting removes one vendor from the picture and hands you every obligation that vendor would have carried. A managed HIPAA form service with a signed BAA is often the lower-risk choice for a small practice with no dedicated technical staff.

Can I keep entries in WordPress if the database is encrypted?

Encryption is necessary and not sufficient. You still need a host that has signed a BAA, restricted access, audit trails, and a retention policy. Encryption protects data at rest against one class of threat and does nothing about a staff account with excessive permissions.

What is the fastest single improvement I can make?

Strip entry contents out of notification emails and replace them with a login link. It is a template change, it takes minutes, and it removes the widest disclosure path in a typical WordPress intake setup.

Do I still need to worry about tracking if my host has signed a BAA?

Yes, and this is the gap most sites miss. A compliant host protects data sitting on your server. It has no effect on what the pixels in the visitor's browser transmit to Meta and Google while the patient is filling in the form.

Where to start

Gravity Forms will not sign a BAA and does not need to, because your form data never reaches them. What that means in practice is that the entire compliance burden for WordPress intake is yours: a host that has signed, encryption at rest, TLS everywhere, least-privilege access, audit logging, short retention, content-free notifications, and an inventory of every add-on that transmits data outward.

The layer none of that touches is advertising. Curve replaces the pixels on your WordPress site with server-side collection, per-destination field mapping, hashed identifiers, and neutral event aliases, so Meta and Google receive a conversion signal without receiving anything about the patient or the treatment. A signed BAA is included on every plan. Run the free compliance scanner against your site to see what is leaving right now, or visit curvecompliance.com to walk through your intake architecture.

Reviewed August 2026. Vendor BAA policies change. Confirm current terms with the vendor.