The answer turns on the account, not the product. Google Forms appears by name in the list of functionality that Google's HIPAA Business Associate Addendum covers, which means a form can hold protected health information. It also means the conditions attached to that addendum apply in full, and one of them rules out the account most people are signed in to when they ask the question. Below is what the documents say, what has to be configured, and which parts of a HIPAA obligation a form does not address at all.
The short answer
Google Forms is inside the scope of the Google Workspace HIPAA BAA. The current Included Functionality list names "Google Drive (including Google Docs, Google Forms, Google Pics, Google Sheets, Google Slides, and Google Vids)" among the services covered under the applicable HIPAA Business Associate Addendum.
Three conditions come with that.
The account has to be a Google Workspace or Cloud Identity account, and the addendum has to be signed. Google's implementation guide states that customers subject to HIPAA who wish to use Google Workspace with PHI must sign a Business Associate Addendum to their Google Workspace Agreement, and the same applies to Cloud Identity customers under their own agreement. A personal Google account has no agreement to add an addendum to and no admin console in which to accept one, so a form built on a free account is outside this entirely.
PHI is permitted only in the covered subset. The guide is explicit that per the BAA, PHI is allowed only in a subset of Google services, and that those covered services must be configured by administrators to help ensure PHI is properly protected.
The organisation decides whether it needs the addendum at all. Google's guide places that with the customer: customers are responsible for determining if they are a business associate and whether a BAA with Google is required, and for using the services in compliance with HIPAA.
What the rule actually requires
Two parts of the regulation explain why the addendum is the pivot.
45 CFR 164.502(e)(1)(i) permits a covered entity to disclose PHI to a business associate, and to let that business associate create, receive, maintain or transmit PHI on its behalf, "if the covered entity obtains satisfactory assurance that the business associate will appropriately safeguard the information". Paragraph (e)(2) adds that those assurances "must be documented through a written contract or other written agreement or arrangement", meeting the requirements of 164.504(e).
That is the whole of the BAA question. A form tool holding PHI on an organisation's behalf is a business associate, and without a written agreement the arrangement fails at the first step regardless of how the product is built.
The technical safeguards in 164.312 then describe what the configuration has to deliver. Access control with unique user identification is required. Audit controls are required: "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information". Person or entity authentication is required. Automatic logoff and encryption are listed as addressable, which means a documented decision rather than an optional extra.
Read in that order, the product question becomes narrow. Who can open a response, what record exists of them opening it, and is there a signed agreement with whoever holds it.
What the addendum does not reach
The covered list is a subset, and the exclusions are where practical mistakes happen.
Services outside the list. Google Contacts is named in the guide as a core service in which PHI is not permitted. Other non-core services, with YouTube, Blogger and Google Photos given as examples, must be disabled for users who handle PHI within the Included Functionality unless covered by a separate BAA.
Technical support. The guide states that technical support services provided to a customer are not part of the HIPAA Included Functionality, and that customers should not provide PHI to Google when using them. Pasting a form response into a support ticket to demonstrate a problem is the way this gets broken.
Pre-release features. Pre-GA offerings are not to be used with PHI unless the offering's own terms say otherwise. Anything that arrives labelled as a preview is outside the addendum by default.
Third party add-ons and integrations. This is the largest gap in practice. Where a user shares PHI with a third party application, add-on, system or database, including by authorising API access, the guide puts the responsibility on the customer to have appropriate HIPAA compliant measures in place with that third party, and to determine whether a separate BAA is needed. A form that sends every response to a spreadsheet is inside the covered set. The same form connected to an automation service, a scheduling tool, or a notification app is only as covered as the agreement with that other company.
The configuration that has to happen
Google's guide gives specific recommendations. These are the ones that bear on a form.
| Requirement | What to do | Where |
|---|---|---|
| A documented agreement | Accept the BAA before any PHI is collected | Admin console, Account settings, Legal and compliance |
| Limit who can respond | Restrict the form to the organisation where responses come from staff | Form response settings |
| Minimum necessary in names | Avoid PHI in the titles of files, folders and shared drives | Naming convention, form and sheet titles |
| Control sharing | Restrict external sharing, and set default file visibility to private to the owner | Drive sharing settings |
| Close the side doors | Consider disabling third party applications such as Drive SDK apps and Docs add-ons, and control Marketplace installation | Admin console app access controls |
| Separate the users | Put staff who handle PHI in their own organisational unit and turn non-core services off for them | Organisational units |
| Keep an audit trail | Review admin reports and logs, and configure alerts for account events | Admin console reports and alerts |
The naming point deserves emphasis because it is easy to overlook and hard to undo. Google's guide recommends that users avoid putting PHI in the titles of files, folders or shared drives. A form titled with a patient name, or a response spreadsheet named after a case, spreads that name into share dialogues, notification emails, and search results across the domain.
What a form still does not do
Suppose the addendum is signed and everything above is configured. A set of HIPAA obligations remains, and none of them is a form feature.
Who can see a response, individually. A form's responses live in one spreadsheet or one response view. Access is granted to the file, so anyone who can open it can read every submission. The minimum necessary principle points the other way, and 164.312(a) asks for access rights granted to those persons who need them. Splitting a single file into per person access is not something a form does.
Who actually read it. Drive and admin logs record file access, so the evidence exists, but it exists at the file level rather than at the level of one person's information. Answering the question "who opened this individual's submission, and when" means reconstructing it from logs rather than reading it off the record.
What happened next. A submission that requires action has a state: received, reviewed, contacted, closed. A response row has no state, so the state lives in a colour fill, a side column, or somebody's memory. Where several staff work the same queue, this is also an access control problem, because the usual workaround is to give everyone the whole file.
The reply. Replies sent from a personal mailbox leave the record of the exchange in that mailbox. Gmail is covered functionality, so this is not a breach of the addendum, but it does mean the correspondence and the submission are in two places, and an access request for everything held about one person becomes a search rather than a lookup.
Retention. A form keeps responses until someone deletes them. A retention schedule has to be applied by hand, or through Vault where that is licensed, and it is one of the first things an auditor asks about.
These are the reasons health organisations using Google Forms for intake tend to end up with a spreadsheet, a folder of documents, and a shared mailbox, all separately shared with the same group of people. Each part is inside the addendum. The combination is difficult to evidence. What removes most of it is a system where a response is a record in its own right, with an owner, a status, an access level per person, and the correspondence attached to it, and the intake situations where that shape pays for itself are exactly the ones with a queue and several reviewers.
The questions to put to any form vendor in writing
Whether the answer is Google or something else, the same short list settles it, and every item on it should be answered in a document rather than in a sales conversation.
Is a business associate agreement available, and at which plan. Some vendors offer one only on higher tiers, some not at all. Without it, 164.502(e) is not satisfied and nothing else on the list matters.
Who the subcontractors are. Hosting, email delivery, file storage, error monitoring. A business associate that passes PHI to a subcontractor has to obtain its own assurances from that subcontractor under 164.502(e)(1)(ii), so the chain should be visible.
How access is granted. Per record, per folder, or per whole account. This is the difference between granting a reviewer one submission and granting them every submission ever received.
What the access log records, and for how long it is kept. Audit controls are required under 164.312(b), and a log that shows logins but not record views does not answer the question that gets asked after an incident.
How breaches are reported, and how quickly. Under 164.410 a business associate must notify the covered entity following discovery of a breach of unsecured PHI, without unreasonable delay and no later than 60 calendar days after discovery. A vendor should be able to say what its own process is without being asked twice.
How data is deleted. A retention schedule needs a mechanism behind it, whether that is bulk deletion, per record deletion, or export then purge.
Where the data and the uploaded files are held. HIPAA does not require any particular country, but the answer feeds other obligations and it should be written down rather than assumed.
What to change first
Check the account before anything else. If the form is on a personal Google account, there is no addendum, and the collection has to move to a Workspace or Cloud Identity account with the BAA accepted before the next submission arrives. If the account is right, the highest value change is usually not in the form: it is auditing every integration hanging off the response spreadsheet, because that is where PHI leaves the covered set without anyone deciding that it should. Then look at how many people can open the whole response file, and whether an individual's submission, its documents, and the reply can be produced together on request. Any tool considered as a replacement has to answer the written agreement question first, and the access control and record keeping question second. Reading how a candidate tool answers those two in public, as Halict does on data location and workspace separation, is a faster filter than a feature list.
Q1. Can a free Google account be used for a HIPAA compliant form?
No. The HIPAA addendum attaches to a Google Workspace or Cloud Identity agreement, and a personal account has neither an agreement to amend nor an admin console in which to accept it. Google's implementation guide requires customers subject to HIPAA who want to use the services with PHI to sign the addendum first.
Q2. Is Google Forms listed as a covered service?
Yes. The current Included Functionality list names Google Drive and states that it includes Google Docs, Google Forms, Google Pics, Google Sheets, Google Slides and Google Vids. Coverage applies only while the addendum is in place and the services are configured as the implementation guide describes.
Q3. Does connecting a form to another app break HIPAA coverage?
It moves the data outside the agreement with Google. The implementation guide places responsibility on the customer to ensure appropriate HIPAA compliant measures are in place with any third party application, add-on, system or database, and to determine whether a separate BAA is needed. Automations that forward responses are the usual way PHI leaves the covered set unnoticed.
Q4. Is signing the BAA enough on its own?
No. The addendum permits PHI in the covered subset of services, and the guide states those services must be configured by administrators to protect it. That includes restricting sharing, keeping PHI out of file titles, turning off non-core services for users who handle PHI, controlling add-on installation, and reviewing audit logs.
Q5. What is the weakest point of using a form and a spreadsheet for patient intake?
Access granularity and evidence. Access is granted to a whole file rather than to individual submissions, so everyone who needs one record can read all of them, and showing who read a particular person's information means reconstructing it from Drive and admin logs. Neither is impossible, and both are work that a system built around individual records does not create.