Built by PJ Zonis · SideGuy Solutions
Operator-honest, North County San Diego. No retainer, no sales call — a real human who'll tell you straight which of this you actually need.
💬 Text PJ · 858-461-8054 · 📤 Share this
Most big cloud and SaaS vendors will sign a Business Associate Agreement — but on specific plans, for specific services, and with one gotcha that trips up most teams: a signed BAA alone doesn't make you compliant.
Yes — AWS, Google, Microsoft, Datadog, Twilio, Slack, Zoom and many others sign a HIPAA BAA for qualifying customers. The catches: many only offer it on a specific plan tier, and the BAA only covers the vendor's designated HIPAA-eligible services — not every feature.
A signed BAA is necessary but not sufficient. It creates the legal relationship; it does not configure the service securely or keep PHI out of an uncovered feature. You still own configuration, access control, and your risk assessment.
No BAA = no PHI. If a vendor won't sign one, you cannot route protected health information through it, period. Find an equivalent that will, or keep PHI out of that tool.
A starting checklist — always confirm current terms with the vendor, since plans and eligibility change.
| Vendor | BAA availability tier | What the BAA actually covers | Gotcha | Operator read |
|---|---|---|---|---|
| Google Workspace | Business / Enterprise eligible | Covered Google Workspace services listed in the admin/compliance terms. | Consumer Gmail is not the same thing. Workspace settings and covered-services scope matter. | Good default for small clinics if admin controls are actually configured. |
| Microsoft 365 | Business / Enterprise eligible | Microsoft online services under the applicable compliance terms. | Teams, SharePoint, OneDrive, Exchange, and add-ons each need scope review. | Often the cleanest HIPAA office stack when the team already lives in Microsoft. |
| AWS | Self-service via AWS Artifact | Only AWS HIPAA-eligible services, configured inside the BAA scope. | A non-eligible AWS service can still break the chain even after the BAA is accepted. | Strongest infra default if someone owns the service list and logging posture. |
| Google Cloud | Cloud BAA / covered products | Designated Google Cloud services listed as HIPAA-eligible. | Workspace and GCP are different paths; do not assume one signature covers the other. | Solid if the product is already on GCP; verify each managed service before PHI lands. |
| Azure | Microsoft compliance terms | Azure in-scope services under Microsoft's BAA / online services terms. | Marketplace add-ons and third-party integrations are separate vendors. | Best fit for Microsoft-native healthcare teams that want one identity and infra stack. |
| Zoom | Healthcare / eligible paid plans | Covered Zoom services configured under the BAA. | Consumer or standard setups are not a HIPAA telehealth program by themselves. | Works for video visits only when scheduling, recordings, chat, and storage are scoped too. |
| Slack | Usually Enterprise-gated | Eligible Slack services under an enterprise BAA. | Regular team chat habits leak PHI fast: screenshots, names, files, channel history. | Keep PHI out unless the enterprise BAA and retention rules are intentional. |
| Dropbox | Business / Enterprise plan-gated | Covered file storage and sharing services under Dropbox's BAA path. | Shared links, personal accounts, and unmanaged devices are the usual failure modes. | Acceptable for document workflows if access control and link hygiene are locked down. |
| Twilio | Product-restricted BAA | Specific eligible communication products and configurations. | Not every channel, log field, recording, or messaging pattern belongs in HIPAA scope. | Good for patient messaging only after you map message bodies, logs, and retention. |
| Stripe-adjacent payments | Usually avoid PHI in payments | Payment processing may be available, but payment metadata should not carry PHI. | Procedure names, diagnosis notes, and visit details in invoices/payment descriptors are the trap. | Treat payments as adjacent: take money cleanly, keep PHI in the clinical system. |
Vendor terms shift — treat this as a starting point and verify the current plan requirement + covered-services list directly before sending any PHI.
The mistake we see most — and it isn't "the vendor wouldn't sign."
The dangerous failure isn't a missing BAA — it's a signed BAA that lulls a team into thinking the job is done. Getting the signature is the easy 20%. The 80% that actually keeps you compliant is staying inside the vendor's HIPAA-eligible services and configuring them correctly. We've seen teams with a perfectly executed AWS or Datadog BAA still mishandle PHI because they routed it through a feature the BAA didn't cover, or left a setting open. The paper protects the relationship; your configuration protects the data.
So treat the BAA as step one of three: (1) confirm the vendor signs one and on which plan; (2) execute it and get the covered-services list in writing; (3) configure your usage to stay strictly inside that scope, and document it in your risk assessment. Skipping step three is where audits find blood.
And never improvise around a "no." If a tool won't sign a BAA, it cannot handle PHI — there's no clever workaround, no "we'll just encrypt it ourselves." Either swap to an equivalent vendor that signs (there usually is one), or architect PHI out of that tool entirely. If you want a second set of eyes on which of your vendors actually need a BAA, and whether your current stack is in scope, text PJ — honest answer, no sales pitch.
What teams Google before sending PHI to a vendor.
Most major cloud and many SaaS vendors will sign a HIPAA Business Associate Agreement (BAA) for qualifying customers — including AWS, Google Cloud, Google Workspace, Microsoft Azure, Microsoft 365, Twilio, Slack, Zoom, and Dropbox. The important caveats are that many only offer a BAA on specific plan tiers, and that signing the BAA only covers the vendor's designated HIPAA-eligible services — not necessarily every feature of the product.
Yes, Google Workspace can support a HIPAA BAA on eligible plans and covered services, but consumer Gmail is not a substitute. You still need the admin-side agreement, covered-products scope, access controls, sharing restrictions, and a rule that PHI stays out of services or features the BAA does not cover.
No. A signed BAA is necessary but not sufficient. It establishes the legal relationship and obligations between you (a covered entity or business associate) and the vendor (a business associate or subcontractor), but it does not configure the service securely for you. You still have to use only the vendor's HIPAA-eligible services, configure encryption and access controls correctly, limit who can see PHI, and run your own risk assessment and safeguards. Plenty of organizations have a signed BAA and are still out of compliance because they misconfigured the service or sent PHI through a feature the BAA doesn't cover.
If you send, store, or process protected health information through a vendor that has not signed a BAA with you, you are out of compliance with HIPAA, full stop — there is no workaround. The BAA is the mechanism that lawfully extends HIPAA obligations to that vendor. Using a no-BAA tool for PHI exposes you to breach liability and potential penalties, and it's a common finding in audits. If a vendor won't sign a BAA, you cannot route PHI through it; you either find an equivalent vendor that will, or keep PHI out of that tool entirely.
The process varies by vendor. Some make it self-service: AWS, Google, and Microsoft let you accept or request the BAA through an account/admin console or compliance portal. Others require you to be on a specific plan and to request the BAA through sales or support. The practical steps are: confirm the vendor offers a BAA, confirm which plan tier is required, request and execute the BAA, get the list of HIPAA-eligible/covered services, and then configure your usage to stay inside that scope.
Yes. AWS lets eligible customers accept the BAA through AWS Artifact, but the signature only covers HIPAA-eligible AWS services. Your architecture still has to avoid non-eligible services for PHI, configure encryption and access controls, and document the scope in your risk assessment.
Treat payment processors as HIPAA-adjacent unless your exact contract and workflow say otherwise. The safer operator pattern is to keep PHI out of payment metadata, invoices, descriptors, receipts, and support tickets. Take payment cleanly; keep diagnosis, procedure, and visit details inside the clinical system.