A Business Associate Agreement (BAA) is the legal and operational bridge that lets a HIPAA covered entity—or another business associate—use a
vendor that will create, receive, maintain, or transmit PHI/ePHI on its behalf.
In practice, it gives you required contractual assurances, allocates duties around safeguards and incidents, and makes the vendor directly accountable for important HIPAA obligations;
it does not make your application, configuration, or overall use of the vendor automatically HIPAA compliant.
What value a BAA provides
A properly executed BAA provides several concrete protections and compliance functions:
| Practical value | What it means in a cloud hosted service |
| Permitted-use boundary | The vendor may use or disclose PHI only for the defined services and other legally permitted purposes—not for unrelated product development, advertising, profiling, or resale. |
| Contractual security commitment | The vendor must implement appropriate safeguards, including HIPAA Security Rule requirements for ePHI it handles. This turns security protection from a vague marketing claim into a contractual obligation. hhs |
| Incident and breach reporting | The vendor must report impermissible uses/disclosures and relevant security incidents, including breaches of unsecured PHI. This lets you investigate, meet breach-notification duties, and coordinate response. hhs |
| Subcontractor flow-down | If the vendor relies on infrastructure providers, support firms, backup vendors, or other subcontractors that access PHI, it must bind them to the same applicable restrictions and safeguards. hhs |
| Lifecycle controls | The agreement addresses return or destruction of PHI at termination when feasible; if that cannot be done, protections must continue. hhs |
| Regulatory assurance and accountability | HIPAA requires covered entities/business associates to obtain “satisfactory assurances” through a BAA when a cloud service provider handles ePHI. Business associates also have direct liability for certain HIPAA failures—not merely contractual exposure to you. hhs |
| Enforcement leverage | A compliant BAA must authorize termination if the business associate materially violates it. The agreement also creates a defined basis to request incident cooperation, documentation, and remediation. hhs |
Without a BAA, a service provider that stores, processes, backs up, logs, or otherwise handles PHI is usually not an acceptable HIPAA business associate arrangement. Encryption alone does not eliminate the need for a BAA when the provider maintains ePHI for you; HHS specifically treats cloud service providers in that role as business associates.
What it does not provide
A BAA is important, but it is not a certification or a shield against your own mistakes.
It does not:
- Make every product, feature, account type, region, plugin, or support channel HIPAA-eligible.
- Configure encryption, IAM, MFA, retention, backups, logging, audit trails, or network isolation for you.
- Prevent staff from putting PHI into an unapproved service such as an ordinary consumer mailbox, form tool, CDN log, customer-support ticket, analytics platform, error tracker, AI prompt, or website database.
- Transfer the covered entity’s or application owner’s HIPAA responsibility to the vendor.
- Guarantee that a breach never occurs or eliminate your risk-analysis, policy, training, access-control, monitoring, and incident-response obligations.
For Google Cloud, Google states that the entity entering the BAA remains responsible for building a HIPAA-compliant solution and must use the listed covered services. In other words, “we have Google’s BAA” is necessary for eligible workloads but not sufficient for compliance.
Hosting-vendor implications
For Google Cloud, the BAA generally applies only to explicitly identified Covered Services. You need to verify the precise product, feature, and deployment pattern before allowing PHI into it—not merely assume all services under a Google billing account qualify. Google publishes the covered-service list and its HIPAA BAA/implementation material; the list includes many core cloud services, but your architecture still needs controls such as least-privilege IAM, encryption, audit logging, retention controls, secure backups, and carefully managed support access.
For a Google Workspace use case, treat it separately from Google Cloud: ensure the correct Workspace edition, BAA execution path, and service-specific HIPAA guidance apply. Do not infer Workspace coverage from a Google Cloud BAA.
Will this specific contracted service create, receive, maintain, or transmit PHI, and will the vendor sign a HIPAA-compliant BAA for that service?
If the answer is yes, get the BAA and validate the service scope and shared-responsibility terms. If the vendor will not sign a BAA, the safe compliance posture is to ensure PHI never enters that service—not in the production database, server files, backups, web forms, email, logs, recordings, support tickets, or exported reports.
This is especially relevant for a public-facing web application. A marketing site can often run on a non-BAA host only if it is genuinely PHI-free. The moment it accepts patient intake data, appointment details tied to identity, clinical information, authenticated patient messages, uploaded records, or application telemetry containing identifiers plus health context, it may become part of the PHI environment.
A practical way to evaluate vendors
Before signing or relying on a BAA, use this decision process:
- Map PHI data flows. Identify every place PHI could travel or persist: browser forms, APIs, databases, object storage, queues, backups, logs, monitoring, error reporting, email/SMS, customer support, analytics, developer tools, and AI integrations.
- Identify every vendor that touches it. Include indirect providers and features, not only the primary host. A managed database, CDN/WAF, transactional email platform, session replay product, and log-management system may each be separate business associates.
- Confirm BAA availability and scope. Obtain the actual BAA—not a sales statement. Verify the named legal entity, service/account, products covered, conditions, geographic limits if relevant, and whether subcontractor protections apply.
- Read the shared-responsibility documentation. Confirm who is responsible for identity controls, encryption/key management, configuration, vulnerability management, backups, audit logs, access reviews, incident notification, and data deletion.
- Restrict PHI to approved services only. Maintain a short approved-services register. Treat any service outside that list as PHI-prohibited by default.
- Document the decision in your HIPAA risk analysis. Preserve the BAA, service eligibility evidence, architecture/data-flow diagram, security configuration baseline, and periodic review record.
The most useful mental model is: a BAA makes a vendor an acceptable link in your PHI supply chain, subject to its scope and your technical controls. It is a prerequisite where the vendor handles PHI, not a substitute for HIPAA security engineering or governance.
Image below provides a practical PHI map for data flows when configuring Google Workspace for a not-for-profit client to store PHI data in Google Workspace (Gmail, Drive, Sheet, Doc, etc.). For a not-for-profit using Google Workspace, the most practical PHI map is a data-flow inventory plus an approved-use boundary: show where PHI originates, which Google Workspace services may hold or transmit it, who can access it, where it can leave the tenant, and the controls at each transition.
Start by accepting Google’s HIPAA BAA and confirm that you’re using only the specifically covered HIPAA Included Functionality for PHI. Google identifies Gmail; Drive and its editors (Docs, Sheets, Slides, Forms); Calendar; Chat; Meet; Groups; Vault; and other specified Workspace services as covered functionality, but the organization remains responsible for configuring and operating its environment compliantly.