What HIPAA actually requires of your website forms

Who HIPAA actually applies to

HIPAA's Privacy, Security and Breach Notification Rules apply to "covered entities" — health plans, health care clearinghouses, and health care providers who transmit health information electronically in connection with certain transactions. Certain provisions also apply directly to their business associates: vendors and contractors that create, receive, maintain or transmit protected health information (PHI) on the covered entity's behalf.

Source: HHS.gov: Business Associates

PHI is health information tied to something that identifies a person. A name and email address collected through a generic newsletter signup, on its own, typically isn't PHI. A form that pairs a name or contact detail with a symptom, diagnosis, medication or insurance ID moves into that territory. Whether a specific field or workflow counts is a judgment call for your compliance officer, not something a blog post can settle for you — when in doubt, that's the conversation to have before you build the form, not after.

The role of a business associate agreement

If a vendor will create, receive, maintain or transmit PHI on your behalf, the Privacy Rule requires the covered entity to obtain a written contract — a business associate agreement, or BAA — in which the vendor agrees to safeguard that information. A business associate is also directly liable under HIPAA for certain obligations, including compliance with the Security Rule and breach notification, independent of what the contract says.

Source: HHS.gov: Business Associates (BAA requirement)

A signed BAA is necessary before a vendor touches PHI, but it is a contract, not proof that the vendor's systems are actually configured safely. A form provider, host, or email service can sign a BAA and still misconfigure logging, storage or access controls. Ask for the contract and ask how the safeguards behind it are actually implemented.

What the Security Rule says about encryption

Encryption is not flatly mandatory under the Security Rule. It's what HHS calls an "addressable" implementation specification: a covered entity or business associate must assess, through a risk analysis, whether encryption is a reasonable and appropriate safeguard for its situation. If it is, implement it. If the entity decides it isn't appropriate, it must document that decision and either implement an equivalent alternative or document why the standard is otherwise met without it.

Source: HHS.gov: Is the use of encryption mandatory in the Security Rule?

In practice, most vendors serving healthcare clients treat encryption in transit and at rest as the default, because the alternative is documenting and defending a decision not to encrypt. Ask a vendor directly what's encrypted, at what point in the data's path, and ask to see that written into their security documentation rather than taking a marketing page's word for it.

Questions to ask a form or hosting vendor

• Will you sign a business associate agreement, and can I see the template before we commit?
• Where does form data go after submission — your servers, a database, a forwarded email — and is every stop in that chain covered by the same BAA?
• What is encrypted, in transit and at rest, and can you point to the specific configuration rather than a general claim?
• Do you provide audit logs showing who accessed a record and when, and can we review a sample?
• How is access to submitted data restricted to staff who need it, and can we control that ourselves?
• What is your breach notification process, and what timeline and information do you commit to giving us?
• If we integrate with our EHR, exactly which fields transfer, and is that limited to the minimum necessary?

If a vendor hesitates on the BAA question or can't describe their safeguards in specific terms, that hesitation is itself useful information.

Common ways exposure gets created

• Form notifications forwarded to a personal email account with no BAA covering that mailbox.
• General-purpose form backends not built for healthcare data and unwilling to sign a BAA.
• Treating a padlock icon (HTTPS) as proof of compliance — it says nothing about what happens to the data once it's stored or where it's forwarded.
• No written record of signed BAAs, retention schedules or an incident-response plan.
• Assuming a signed BAA means the technical setup was ever actually checked.

A simple way to think about scope

Some organizations avoid the question entirely by keeping clinical detail off the public website: a general contact form routes to a phone call or to an existing patient portal, and no symptom or diagnosis field ever touches the marketing site. That's a legitimate, lower-complexity choice for many small practices, and it's worth discussing with whoever owns your compliance decisions before assuming you need a fuller build. Other organizations need forms that do collect clinical detail directly — pre-visit intake, for example — and that calls for a vendor relationship built around a BAA and documented safeguards from the start.

Who decides, and where to check

Whether a given form triggers HIPAA obligations, and whether a vendor's setup satisfies them, is a determination for your organization's privacy or compliance officer, informed by legal counsel where the answer isn't obvious. Start with HHS's own guidance for professionals to understand your baseline obligations as a covered entity or business associate, and treat any vendor's compliance claims as a starting point for questions, not a substitute for your own review.

Source: HHS.gov: HIPAA for Professionals

None of this is a one-time project. Vendor terms change, staff turn over, and a configuration that was correct at launch can drift. Building a habit of periodically re-checking BAAs, mailbox settings and vendor configurations matters as much as getting the initial setup right.