Is Zapier HIPAA compliant?

Short answer: HIPAA does not certify software as compliant on its own. This guide also cannot tell you whether Zapier will sign a business associate agreement or which of its plans that would cover, because we are not relying on any Zapier source here. Ask Zapier directly for its current terms in writing. What we can set out is the decision underneath the question. The real question is whether the automation will touch patient data. If a workflow moves marketing data only, such as a newsletter signup with no health details, the business associate rules may not come into play at all, though your counsel should confirm that. If it carries identifiable health information for a covered entity, the regulation’s definition of a business associate can reach the vendor, and the rules require a contract or other arrangement with specific terms.

This guide is for medical practices, clinics and healthcare companies whose websites send form submissions into other tools. It explains how the regulation frames the question, gives you four checks to run before connecting anything, and shows who owns each decision. It is not legal advice, and a website design firm cannot certify your compliance.

Why a tool is not compliant on its own

The HIPAA rules are written around organizations and the roles they play, not around products. The definitions in 45 CFR 160.103 describe a covered entity as a health plan, a health care clearinghouse, or a health care provider who transmits any health information in electronic form in connection with a covered transaction. The same section defines a business associate as a person who, on behalf of a covered entity, “creates, receives, maintains, or transmits protected health information” for a regulated function or activity. It expressly includes a subcontractor that creates, receives, maintains or transmits protected health information on behalf of a business associate.

That produces a chain: Covered entity, Business associate, Subcontractor. Contract obligations follow the chain. Under 45 CFR 164.504(e)(5), the contract requirements that apply between a covered entity and its business associate apply in the same manner between a business associate and its subcontractor. Whether a cloud automation tool is acceptable for a given workflow therefore depends on where it sits in that chain for your data and whether the right agreement exists.

The definition of protected health information decides whether the chain matters at all. Section 160.103 describes individually identifiable health information as information, including demographic information collected from an individual, that is created or received by a health care provider, health plan, employer or clearinghouse; relates to the person’s past, present or future health or condition, the provision of care, or payment for care; and identifies the person or could reasonably be used to identify them. Protected health information is that information when transmitted or maintained in electronic media or in any other form or medium.

Map what your website actually sends

Start with your forms. Before anyone asks about vendor terms, we recommend listing every form and every field, then sorting each form into one of three groups:

• Marketing data only: newsletter signups, general webinar registrations, partnership or sales inquiries. No condition, symptom, appointment reason, medication or insurance detail.
• Identifiable health information: a name, email or phone number together with a symptom, condition, appointment reason, medication or insurance detail, submitted to a provider or plan.
• Unclear: free-text message boxes where visitors can type anything they like.

Hypothetical example 1. A two-location physical therapy practice has a “Request an appointment” form with name, phone, preferred location and a box labeled “What brings you in?”. A visitor writes about a recent knee surgery. That submission is received by a health care provider, describes a condition and identifies the person, which lines up with each element of the definition above. If an automation copies it into a spreadsheet, the automation vendor transmits it and the spreadsheet service stores it.

Hypothetical example 2. A digital health company that sells software to hospitals runs a “Book a demo” form asking for name, work email, job title and organization size. Nothing in it concerns anyone’s health. Pushing those leads into a sales tool is a marketing workflow, and that form may not raise the HIPAA question at all. Your counsel should still confirm it for your situation.

We recommend paying closest attention to free-text boxes. Even a form designed for marketing data only can collect health details when visitors are invited to “tell us more”. Tighten labels and helper text so people know what not to send, and remove the box if you do not need it.

Four checks before you connect a form

1. Classify every field the automation will read. Include hidden fields, page URLs and campaign parameters. We recommend reviewing these because a page path can name a specific service or condition.
2. Decide whether the data can be minimized. Often the cleanest option is to remove the health question from the public form and ask it later inside a system your organization has already reviewed for that purpose.
3. Confirm the vendor’s current contract terms in writing. Ask whether the vendor signs a business associate agreement, which plans and features it covers, and what it requires of you. An automation that moves data from a form to a spreadsheet involves at least three services: the form, the automation tool and the destination. Each one that handles the data needs to be accounted for.
4. Test, document and assign an owner. Submit test entries with fake data, confirm where every copy lands, record the workflow in your privacy documentation, and name the person who approves changes to it.

If the second check removes every health detail, the form may move back into the marketing group. If it does not, the third check decides the matter. Business associate agreement terms deserve the same scrutiny as any other contract, and we recommend that no protected health information flow until an agreement is in place and reviewed by counsel.

What the agreement has to cover

When a vendor offers an agreement, read it against the regulation rather than taking the title on trust. Under 45 CFR 164.504(e)(2), a contract between a covered entity and a business associate must, among other things:

• establish the permitted and required uses and disclosures of protected health information by the business associate;
• provide that the business associate will not use or further disclose the information other than as the contract permits or as required by law;
• provide that it will use appropriate safeguards and comply, where applicable, with subpart C for electronic protected health information;
• require it to report uses or disclosures not provided for by the contract, including breaches of unsecured protected health information;
• require it to ensure its subcontractors agree to the same restrictions and conditions;
• require return or destruction of the information at termination, if feasible; and
• authorize the covered entity to terminate the contract if the business associate has violated a material term.

The security rule adds parallel terms. 45 CFR 164.314(a)(2)(i) says the contract must provide that the business associate will comply with the applicable requirements of that subpart, ensure subcontractors agree to comply, and report any security incident of which it becomes aware. Hand the vendor’s document and these sections to your privacy counsel together.

Questions to ask about any automation vendor

A signed agreement does not end your own obligations. 45 CFR 164.312 says a covered entity or business associate must implement technical safeguards, including access control with unique user identification, audit controls that record and examine activity in systems containing electronic protected health information, integrity protections, person or entity authentication, and transmission security for information sent over an electronic communications network. Encryption appears there as an addressable specification for both stored and transmitted data.

Those standards translate into practical questions we recommend putting to any automation vendor and to your own team:

• Can every staff member have their own login, or is one shared account running the workflows?
• Is there an activity history showing who created or edited a workflow, and when?
• How is data protected while it moves between connected services?
• Does the tool keep copies of submitted data in task or run history, and can you control how long?
• Who can turn a workflow off quickly if something goes wrong?

If you are a health company, not a covered entity

If your company is not a health plan, a clearinghouse or a provider transmitting health information electronically in covered transactions, HIPAA’s covered entity definition may not reach it. A different federal rule might. According to 16 CFR 318.1, the Health Breach Notification Rule applies to vendors of personal health records, PHR related entities and third party service providers, and does not apply to HIPAA-covered entities or to an entity to the extent it acts as a business associate. Its definitions in 16 CFR 318.2 describe health care services or supplies as including any online service, such as a website, mobile application or internet-connected device, that provides mechanisms to track diseases, health conditions, symptoms, medications, sleep, diet and similar matters.

If your product or website tracks anything like that, ask counsel which framework applies before you wire forms or app events into third-party automation. The data mapping and minimizing steps above are useful either way.

Keep sensitive data out of your website CMS

Before you point any automation at your website’s content system, be clear about what that system is for. Webflow describes a CMS Collection as “a database where you can store content to reference throughout your site” (Webflow Help Center). Framer’s developer documentation says plugins “can read and write to the Framer CMS” and recommends Managed Collections when you want to sync data between Framer and a third party (Framer Developers). WordPress assigns each user a role, and its documentation describes the Administrator as someone with access to all administration features within a single site (WordPress.org).

Our recommendation: treat the website CMS as a publishing tool for public content. If an automation writes to it at all, it should carry things like event listings, location hours or article updates, never patient submissions. On WordPress in particular, review who holds Administrator access, since that role reaches every administration feature of the site, and ask your developer whether any installed form plugin keeps copies of submissions inside the site.

Who owns which decision

Party	What they should own
Your organization	Deciding whether it is a covered entity, approving each data flow, keeping documentation and naming an owner for every workflow.
Privacy counsel	Interpreting which rules apply and reviewing any business associate agreement against the regulation.
Automation vendor	Stating its contract terms in writing and operating the safeguards it commits to.
Website developer	Building forms that collect only the fields you approved, configuring where submissions go, and flagging fields that could invite health details.

Ask your developer to put the form inventory and routing in writing as part of the build, so your counsel reviews the real configuration rather than a description of it.

Scoping the website side

Health Site Works designs and builds healthcare marketing websites on Framer, WordPress and Webflow, including redesigns and migrations. Clinical systems, patient portals and sensitive intake need separate scope and provider review, and Health Site Works does not guarantee compliance outcomes. That boundary shapes the main tradeoff:

• Marketing forms only. The public site collects contact and inquiry details with no health fields, and anything clinical is handled in a system your organization has reviewed. This keeps the website scope smaller and the automation question simpler.
• Sensitive intake on the site. Collecting health details through the website brings vendor agreements, safeguard review and provider sign-off into the project, which means separate scope and more people at the table.

Pricing is set case by case after scoping, based on actual need, and there is no public rate card. The Selected work page shows healthcare website design projects, from a healthcare product website and life sciences work to public health. Related guides on Insights include “Healthcare website redesign: what to include in the project brief”, a useful place to record your form inventory. If you reach out about a project, a contact form submission is an inquiry, not a booking.

Frequently asked questions

Does a signed agreement make our automation compliant?

No. The agreement is one requirement. Your own safeguards still apply, and 45 CFR 164.504(e)(1)(ii) says a covered entity is not in compliance if it knew of a pattern of activity by the business associate that was a material breach and did not take reasonable steps to cure it or, failing that, end the contract if feasible.

Can we just tell visitors not to enter health details?

A notice helps, but you cannot control what people type. We recommend designing forms so health details are never invited, then adding the notice as a backstop.

Is a newsletter signup protected health information?

A general list on a company site may collect marketing data only. A signup for a condition-specific list run by a provider could reveal health information by association. Ask counsel about any list tied to a condition or service.

Does the same analysis apply to native Webflow, Framer or WordPress forms?

Yes. Any service that receives or stores submissions sits in the data flow. Ask each vendor for its terms, and do not assume one vendor’s agreement covers the others.