HIPAA-Compliant Form Builders: What to Actually Look For
Most form builders that advertise HIPAA compliance are telling you about one thing: they signed a BAA. A BAA is necessary but nowhere near sufficient. Here is what a compliant form setup actually requires, from a former Jotform engineer.
- A BAA is the entry ticket, not the whole game. Encryption, access controls, PHI field handling, and integration safety all need to be verified separately.
- Email notifications are the most common silent HIPAA violation in form setups. PHI in an unencrypted email is a breach.
- Every tool in the chain that touches PHI needs its own BAA. The form builder is just the first one.
- Jotform, Cognito Forms, and Typeform have dedicated HIPAA tiers. Google Forms can be made compliant with a Workspace BAA but lacks clinical workflow features.
I spent five years inside Jotform, and I have seen more HIPAA compliance theater than I can count. A clinic signs up for a 'HIPAA-compliant' plan, checks the BAA box, and thinks they are done. They are not done. They have not even started.
A Business Associate Agreement is required. No BAA, no compliance. But a BAA is a legal document, not a security architecture. It says the vendor agrees to protect your data. It does not mean they actually do it in every place that matters. This guide breaks down what 'HIPAA-compliant form builder' should mean and where most setups fall short.
The six things a HIPAA-compliant form builder actually needs
1. A signed BAA
This is the minimum. Without it, you have no compliance claim at all. A BAA is a contract between you (the covered entity) and the form builder (the business associate). It defines what PHI the vendor can access, how it must be protected, and who is liable for a breach.
Some vendors offer BAAs only on higher tiers. Jotform requires its Gold or Enterprise plan for HIPAA compliance. Cognito Forms requires its Enterprise plan. Typeform requires its Enterprise plan. Google Workspace includes a BAA across all Business tiers. Check the plan, not the marketing page.
2. Encryption at rest and in transit
HIPAA requires PHI to be encrypted in transit (TLS) and at rest (AES-256 or equivalent). Most modern form builders handle TLS automatically. At-rest encryption is where it gets uneven.
Jotform encrypts submissions at rest on its HIPAA plans. Cognito Forms encrypts at rest on all plans. Google encrypts Drive data at rest but the link between Forms and Drive needs verification: check that the destination Drive has restricted sharing settings. Typeform encrypts at rest on Enterprise.
Ask the vendor specifically about at-rest encryption for form submissions, not just for their database in general. The answer should reference AES-256 and include key management details. If they say 'we use HTTPS,' they are answering the wrong question.
3. Access controls
Who can see submissions? Who can export them? Who can change form settings? A HIPAA-compliant setup needs role-based access at minimum, and two-factor authentication on every account that can access PHI.
Jotform supports 2FA and team-level permissions on HIPAA accounts. You can restrict collaborators to form-only access without submission visibility. Cognito Forms has role-based access on Enterprise. Google Workspace has 2FA enforcement at the org level but granular form-level permissions are limited: anyone with edit access to the form can see responses in the linked Sheet.
Check this before you check anything else: list every account that can view submissions. If a former employee still has access, you have a problem that a BAA will not fix.
4. PHI field-level controls
Not every field on a healthcare form contains PHI. 'Do you have insurance?' is not PHI. 'What is your insurance ID number?' is. A compliant form builder should let you mark certain fields as containing PHI and apply stricter handling to those fields.
Jotform does not have explicit PHI field tagging. It treats the entire form as HIPAA-compliant once the HIPAA plan is active. This is a limitation: you cannot exempt non-PHI fields from stricter logging or apply different retention rules to different fields. Cognito Forms is the same. Google Forms has no concept of PHI fields at all.
What this means in practice: you need to manage field-level PHI handling yourself. Build your form so that PHI fields are clearly labeled internally. Document which fields contain PHI. When you set up integrations, route only non-PHI fields to tools without BAAs.
5. Email notification and PDF export safety
This is the one that catches almost everyone. You set up an email notification so the front desk knows a new patient filled out the intake form. The notification includes the patient's name, date of birth, and insurance ID. That email is now PHI in transit, and unless your email provider has a BAA with you and supports encryption, you have a violation.
Jotform's HIPAA plan lets you disable submission data in email notifications. You get an alert that says 'New submission received' with a link back to the secure Jotform portal. This is the correct setup. Never include PHI in email body text.
PDF generation has the same issue. If a form builder generates a PDF of the submission and emails it, that PDF contains PHI. Jotform's HIPAA mode disables PDF attachments in notifications. If you use a third-party PDF generator via webhook, that tool also needs a BAA.
6. Webhook and integration audit trail
Every integration that receives form data is a potential PHI endpoint. Webhooks send the full submission payload to whatever URL you configure. If that URL points to a server without a BAA, or to a non-HIPAA SaaS product, the data is exposed.
Jotform logs webhook delivery on HIPAA accounts but does not validate the destination. That is your responsibility. Before connecting any integration, verify: does the receiving tool have a BAA? Does it encrypt data at rest? Does it log access? Can you audit who viewed the data?
The integration audit should be a document, not a mental checklist. List every tool in the chain, its BAA status, its encryption, and its access controls. Update it when you add or change an integration.
Comparing form builders on HIPAA readiness
Here is how the major form builders stack up on the six criteria above. This is not a ranking. It is a checklist applied to each tool so you can see what you get and what you still have to build yourself.
Jotform
BAA on Gold and Enterprise plans. Encryption at rest and in transit. 2FA and team permissions. No PHI field tagging. HIPAA mode disables email notification content and PDF attachments. Webhooks and integrations are your responsibility. Strong on the core form security. Weak on integration guardrails.
Google Forms
BAA available with Google Workspace. Encryption at rest and in transit. 2FA enforceable at the org level. No PHI field controls. No conditional logic for clinical workflows. No e-signature. File uploads go to Drive, which needs its own BAA configuration. Email notifications via Gmail are not HIPAA-compliant for PHI content. Best for simple intake where PHI is minimal. Not suitable for complex clinical workflows.
Typeform
BAA on Enterprise plan only. Encryption at rest and in transit. 2FA available. No PHI field controls. Limited conditional logic compared to Jotform. Notification emails can include PHI unless you configure them not to. No HIPAA-specific mode that disables data in notifications. You have to build that discipline yourself.
Cognito Forms
BAA on Enterprise plan. Encryption at rest and in transit. Role-based access. No PHI field tagging. Supports entry-level encryption (fields are encrypted with a key you hold) which adds a layer beyond what Jotform offers. Notification emails include data by default, so you need to configure them carefully. Strong on data protection, weaker on the integration ecosystem.
The form builder is one piece
A HIPAA-compliant form builder gives you a secure place to collect data. It does not make your entire workflow compliant. Every tool downstream of the form needs its own BAA and its own security controls.
The full chain for a typical healthcare form looks like this: the form builder collects the data. A notification alerts staff. The data is stored in a CRM or EHR. Maybe a Zapier automation routes it. Maybe a webhook pushes it to a custom backend. Each of those steps is a point where PHI can leak.
I have never audited a healthcare form setup that was fully compliant on the first pass. Not once. The form builder is usually fine. The integrations are where the gaps live.
What I would do
If I were setting up a HIPAA-compliant form workflow today, here is the order I would follow.
- Pick a form builder with a BAA. Jotform if you need conditional logic and integrations. Cognito Forms if you want field-level encryption. Google Forms only if the workflow is simple and PHI is minimal.
- Enable the HIPAA-specific mode. Disable email notification content. Disable PDF attachments. These are the two most common leak points.
- Set up 2FA on every account that can access submissions. Remove former employees. Restrict collaborators to form-only access if they do not need to see submissions.
- Map every integration. For each one, verify BAA, encryption, and access controls. Write it down.
- Test the full chain. Submit a test with fake PHI. Trace it through every integration. Check that PHI does not appear in email bodies, unencrypted Slack messages, or Google Sheets without a Workspace BAA.
- Document the setup. Include the BAA copies, the integration audit, the access control list, and the PHI flow map. This is your compliance evidence if you ever get audited.
None of this is hard. It is just methodical. Most practices skip it because the form builder said 'HIPAA compliant' on the pricing page and they stopped reading. The form builder is one piece of a compliant workflow. Do the rest.
