HIPAA Form Builders: Who Signs a BAA?

Every healthcare practice that goes looking for an online form tool ends up at the same two questions. The first is "is it HIPAA compliant?" The second is "will they sign a BAA?" Marketing pages answer both with a confident yes, and in doing so they quietly blur the fact that these are two different questions with two different kinds of answer — one about a legal contract, one about a property of your whole compliance programme.

This comparison untangles the two, then goes vendor by vendor through the form builders US practices actually shortlist — Google Forms, Microsoft Forms, JotForm, Cognito Forms, and Formstack — and shows, for each, whether a Business Associate Agreement (BAA) is available, what plan tier it requires, what the encryption model really is, and the question most comparison pages skip entirely: can the vendor technically read your Protected Health Information (PHI) at all? Schweizerform is in the table too, and we are honest about exactly where it does and does not fit.

What a BAA Actually Is (and What It Is Not)

A Business Associate Agreement is a contract. Under HIPAA, when a vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity, that vendor is a "business associate", and the covered entity must have a BAA in place with it. The BAA obligates the vendor to implement the Security Rule's safeguards, limits how it may use and disclose PHI, requires it to report breaches, and requires it to flow the same obligations down to its own subcontractors that touch PHI.

What a BAA is not: it is not a certificate, it is not a technical control, and it is not the thing that makes you compliant. There is no government body that issues a "HIPAA-compliant" stamp to a product. "HIPAA-compliant" is a property of your whole programme — your Privacy Rule analysis, your Security Rule safeguards, your breach-notification plan, and yes, your BAAs — not a label a product ships with. A vendor can hand you a perfectly valid BAA and still leave your programme non-compliant if the rest of the safeguards are not in place.

Required vs Addressable Specifications in 60 Seconds

The Security Rule splits its implementation specifications into two kinds: "required" and "addressable". This single distinction is the source of more bad HIPAA marketing than almost anything else, so it is worth getting straight before any vendor tells you what they do and do not have to do.

• Required means: you must implement it. No discretion.
• Addressable does NOT mean optional. It means: implement the specification, OR document why it is not reasonable in your environment and what equivalent safeguard you put in place instead.
• Encryption — both in transit and at rest — is an addressable specification. Since the 2013 Omnibus Rule and a long line of HHS enforcement actions, regulators treat encryption as the default expectation and have penalised entities that skipped it without a defensible written analysis.

We unpack the Privacy, Security, and Breach Notification Rules in much more depth in our companion article on HIPAA-compliant form collection — this page assumes the basics and focuses on the BAA-and-encryption question specifically. The short version: encryption is not technically mandatory, but in practice you implement it or you write a very good explanation of why you did not.

Who Signs a BAA — Vendor by Vendor

Here is the practical reality for the form tools US practices most often shortlist. For each, the questions that matter are: is a BAA available, on what plan, what is the encryption model, and who can technically reach the plain-text PHI.

Google Forms / Google Workspace

Google offers a BAA that covers core Google Workspace services, including Google Forms — but only for paid Workspace accounts, and the administrator has to actively review and accept the BAA in the Admin console. The free, consumer Google Forms product (a personal Gmail account collecting a health questionnaire) is not covered by any BAA, full stop. This is the single most common and most expensive mistake in this whole space: a clinic uses "free Google Forms", assumes that because Google is a serious company it must be fine, and discovers during an audit that the consumer product was never BAA-eligible.

Encryption model: Google encrypts data in transit (TLS) and at rest on its infrastructure, and Google holds the keys. Form responses are readable by Google's systems. Who can technically reach PHI: Google's infrastructure, and any party able to compel Google under US law. Default data location is the United States, configurable on enterprise tiers but with Google retaining processing latitude.

Microsoft Forms / Microsoft 365

Microsoft includes BAA terms for its covered services through its Product Terms and the HIPAA Business Associate Agreement that forms part of its commercial licensing for eligible Microsoft 365 / Office 365 subscriptions. For practices already standardised on Microsoft 365, Microsoft Forms inside a covered tenant can fall within that BAA framework — but, as always, eligibility is tied to the licence and tenant configuration, not to the consumer product, and you must confirm the specific service is in scope.

Encryption model: TLS in transit, encryption at rest with Microsoft-held keys (customer-managed key options exist on some services but the vendor's platform can still process the data). Who can technically reach PHI: Microsoft's platform and parties able to compel it under US law. Data location depends on tenant region settings.

JotForm

JotForm offers HIPAA-enabled accounts with a BAA, available on its higher paid tiers (its Silver, Gold, and Enterprise plans, with HIPAA features unlocked from the upper tiers). When you enable HIPAA mode, JotForm applies additional controls and will sign a BAA. This is a real, usable offering and a common choice for US practices that want breadth of features plus a BAA.

Encryption model: TLS in transit and encryption at rest, with JotForm holding the keys. Who can technically reach PHI: JotForm's servers — and therefore JotForm staff and any party with application-level access or a lawful demand — can read submissions in plain text. The BAA allocates responsibility for that access; it does not remove the access. Data location is primarily the United States, with EU options on higher plans.

Cognito Forms

Cognito Forms is the tool a lot of people are specifically searching for when they type "cognito forms hipaa compliance baa", so it deserves a careful, fair answer. Cognito Forms offers HIPAA features and will sign a BAA on its higher plans (Pro and above, with HIPAA enablement on the upper tiers). It also has a genuinely useful differentiator that most general-purpose builders lack: an "Encrypted Fields" feature, which lets you flag specific fields as encrypted so that those values are stored encrypted at rest rather than in plain text.

This is a real feature and meaningfully better than tools that store everything in the clear. But it is important to understand precisely what it is and is not. Encrypted Fields is server-side, vendor-managed encryption: Cognito holds the key infrastructure, and Cognito's servers see the plaintext during submission processing and decrypt the field when you, the form owner, view the submission. It is not end-to-end encryption. So the honest answer to the search query is: yes, Cognito Forms offers HIPAA features and a BAA on higher plans, and its Encrypted Fields raise the bar on at-rest protection — but Cognito can still technically access PHI, because it holds the keys. The BAA is what allocates legal responsibility for that access.

Formstack

Formstack is a compliance-focused enterprise workflow platform (forms, documents, e-signature) that offers a HIPAA-compliant plan with a BAA on its higher tiers. For mid-market and enterprise teams that want forms plus document generation and e-sign under one vendor with a BAA, it is a standard, credible choice.

Encryption model: TLS in transit and encryption at rest, with Formstack holding the keys. Who can technically reach PHI: Formstack's infrastructure, its authorised staff, integrations, and any party with a lawful demand can technically reach the plain-text data. Again, the BAA allocates responsibility; it does not change the fact that the vendor's systems can read the data. Data location is primarily the United States.

The Comparison Table

Read the last two columns together. "BAA available" tells you whether a vendor will accept legal responsibility for PHI. "Vendor can technically read PHI?" tells you whether that responsibility is the only thing standing between your patients' data and the vendor's staff. They are different axes, and the difference is the whole point of this page.

A BAA Is Not an Encryption Strategy

This is the section that the comparison table is really pointing at. A BAA and end-to-end encryption (E2EE) both reduce risk, but they do completely different jobs, and they are not substitutes for each other.

A BAA is a legal allocation of responsibility. When a breach happens, the BAA is what determines who must notify whom, who carries which obligations, and how liability is shared between the covered entity and the business associate. It is a paper instrument. It does nothing, by itself, to prevent the breach or to make the exposed data unreadable. Every mainstream vendor that signs a BAA can technically access PHI — their encryption-at-rest uses keys the vendor holds, which means the vendor's systems, staff, integrations, and anyone who can compel them legally can in principle reach the plain text. The BAA says "we promise to handle that access responsibly and to tell you if it goes wrong."

End-to-end encryption is an architectural control. With true zero-knowledge E2EE, the data is encrypted on the respondent's device before it ever reaches the vendor, and the vendor never holds the keys. In a breach, what an attacker — or a subpoena — obtains is ciphertext with no decryption path. The difference is the difference between "allowed to hold readable PHI, and contractually bound to handle it well" and "cannot hold readable PHI at all."

A BAA decides who is responsible when readable PHI is exposed. End-to-end encryption decides whether there is readable PHI to expose in the first place. The strongest programmes do not choose between them — they understand which one each tool actually gives them.

Where Schweizerform Honestly Fits

Time to be direct about our own product, because the whole value of this page depends on it. Schweizerform does not offer a HIPAA Business Associate Agreement, and it is not marketed as a HIPAA vendor. If your procurement checklist has a hard line that reads "vendor must sign a BAA", Schweizerform does not satisfy that line today, and we will not pretend otherwise.

What Schweizerform does have is the architectural property the entire "vendor can technically read PHI?" column is about. Every submission — including file attachments — is encrypted in the respondent's browser using AES-256-GCM, with the per-submission key wrapped by the form's RSA-OAEP-2048 public key. The owner's private key is protected by a Master Key derived from their Access Code, which never leaves their device. Our servers, hosted exclusively in Switzerland on Infomaniak, store ciphertext only. We hold no keys. We cannot decrypt submissions — not for support, not for analytics, not under a Swiss lawful request. That changes the risk conversation: there is no readable PHI on our side for a BAA to allocate responsibility over, because there is no readable PHI on our side at all.

There is also a second audience this page should not lose. For healthcare and health-adjacent organisations outside the US — in Switzerland, the EU, and the wider EEA — HIPAA is simply not the operative framework. The relevant regimes are the Swiss nFADP and GDPR (including the Article 9 rules for special-category health data). That is home turf for Schweizerform: Swiss hosting, Swiss jurisdiction outside US CLOUD Act reach, no US sub-processors in the submission data path, and zero-knowledge encryption on every plan including the free tier. For those buyers, the BAA question is a red herring, and the encryption-and-sovereignty question is the one that matters.

A Decision Framework

Run these five steps in order and the vendor question usually answers itself.

The Bottom Line

"Is it HIPAA compliant?" and "will they sign a BAA?" are two questions, and the honest mainstream answer is consistent across Google Workspace, Microsoft 365, JotForm, Cognito Forms, and Formstack: yes, a BAA is available on the appropriate paid or enterprise tier, and yes, the vendor can still technically read your PHI, because that is how vendor-held-key encryption works. The BAA is the control that governs that access. For US covered entities, that model is well-trodden and often exactly right — just verify it covers the specific product and plan you actually use.

The point this page exists to make is that a BAA is not an encryption strategy. It allocates responsibility for readable PHI; it does not make the PHI unreadable. End-to-end zero-knowledge encryption is the architectural alternative — the vendor cannot read PHI at all — and that is a genuinely different posture, even though, in Schweizerform's case, it comes without a BAA and is not a turnkey US HIPAA package. Choose the path that matches your obligations, verify the claim in writing, and document why.