Email Security & Compliance: Gmail and Google Workspace

Your Email Works. But Is It Secure, Compliant, and Appropriate for Patient Information?

Healthcare email isn't just about sending and receiving messages. When patient information, billing information, payment information, or other sensitive data enters the conversation, how your email environment is configured and operated matters.

Review Your Email Security See What Most Practices Miss
Compliant Secure by default Best practice

These three overlap, and they are not the same thing. Compliant means you meet the requirements that apply to you. Secure by default would mean the product protects you without configuration, which no email platform does. Best practice means the additional, reasonable protections you choose because of how sensitive the information is. A practice can satisfy one of these and not the others.

Ten Questions, Three Readings

A Short Self-Assessment

Ten questions about your environment. At the end you get three separate readings rather than a verdict, because a verdict would not be honest. Nothing is stored, nothing is sent, and no email address is asked for.

How to Read This Page

We Label What the Law Requires and What We Merely Recommend.

A great deal of email advice aimed at healthcare presents a vendor's preference as though it were a federal requirement. We have separated them throughout, and cited the sources at the foot of the page so you can check us.

Required by regulation

An authoritative source establishes it. In the Security Rule this means an implementation specification marked "Required", or a standard itself.1

Addressable / risk based

The regulation names the safeguard but lets you decide. You assess it, implement it if reasonable and appropriate, or document why not and put an equivalent measure in place.1

Best practice

Widely accepted security practice that no regulation names. Useful, sometimes essential, but not a legal requirement, and we will not describe it as one.

CareVixis recommendation

What we would do, and what we advise our practice partners to do. Our opinion, offered as an opinion.

One note on where the rules are heading

In December 2024 HHS issued a Notice of Proposed Rulemaking that would, among other things, remove the distinction between "required" and "addressable" specifications and make nearly all of them required, and would explicitly require multi-factor authentication and encryption with limited exceptions.7 As of the date on this page that rule is proposed and not final, and the current Security Rule remains in effect. We have written this page against the rule as it stands today, and flagged the proposal where it is relevant. Confirm the current status before relying on either.

Two Models, Two Sets of Responsibilities

Third-Party Email and Email You Control

Neither model is automatically the safer one. What changes between them is which responsibilities the vendor takes on, and which ones stay with the practice no matter what.

Model One

Third-Party / Cloud Email

Google Workspace and Gmail, Microsoft 365 and Outlook, and other hosted business email providers.

What the provider brings
  • Managed infrastructure, patched and maintained without practice involvement
  • Substantial security engineering and threat detection that a small practice could not build
  • High availability and geographic redundancy
  • An administrative console with centralised policy controls
  • Audit logging and reporting
  • Spam and malware filtering maintained continuously
  • A published business associate agreement for the covered services10
What stays yours
  • Choosing the appropriate business account and service tier
  • Executing the BAA, and knowing which services it covers
  • Administrator configuration of the whole tenant
  • Who has an account, and what each one may reach
  • Multi-factor authentication and authentication policy
  • Device security for anything that connects
  • Encryption choices beyond the defaults
  • Reviewing the audit logs the platform produces
  • Forwarding rules and delegated mailbox access
  • Which third-party applications are allowed to connect
  • Retention, backup and recovery decisions
  • Account termination and offboarding
  • Workforce policies, sanctions and training

The provider secures the platform. The practice is still responsible for configuring and operating the environment appropriately, and HHS guidance is explicit that a provider is not responsible for failures attributable solely to the customer's own actions or inactions.6

Model Two

Organisation-Controlled / Self-Managed Email

A mail server the practice or its IT provider runs directly, whether on premises or on infrastructure the organisation controls.

What you gain
  • Direct control over configuration, data location and retention
  • Freedom from a vendor's product decisions
  • The ability to design around an unusual requirement
What you take on, in full
  • Mail server software, and its configuration
  • DNS records and their accuracy
  • TLS configuration and certificate lifecycle
  • Spam filtering and malware protection
  • Authentication systems and directory services
  • Backups, and proving they restore
  • Patching, on the vendor's schedule and on the attacker's
  • Monitoring and alerting, with someone to receive the alerts
  • Log collection, retention and review
  • High availability and failover
  • Disaster recovery planning and testing
  • Administrative access control and privileged account management
  • Physical and infrastructure security
  • Incident detection and response, at 2am as well as 2pm

Contingency planning is not optional here. Data backup, disaster recovery and emergency mode operation are all Required implementation specifications under the Security Rule.2

Owning or controlling the email server does not automatically make it more compliant or more secure.

Control creates flexibility, and it creates responsibility in exactly the same measure. A self-managed server run by someone with the time and skill to run it can be excellent. The same server, patched when somebody remembers, is materially worse than a well-configured cloud tenant. The honest question is not which model is better in the abstract. It is which model your practice can actually operate to the standard the information deserves.

The Most Common Misunderstanding

"We Have a BAA, So We're Covered." Not Quite.

The business associate agreement is real, it matters, and in many cases you are required to have one. It is also the single most over-interpreted document in healthcare technology.

What it does

A Legal Instrument

  • Establishes the permitted and required uses and disclosures of PHI by the business associate6
  • Contractually requires the business associate to safeguard the information, including implementing the Security Rule requirements that apply to it6
  • Satisfies a Required specification: written contracts with business associates2
  • Makes a cloud provider that handles ePHI on your behalf accountable as a business associate, which HHS confirms applies even where the provider cannot view the encrypted data6

Google states the position plainly: customers who have not signed a BAA with Google must not use PHI in Google Workspace or Cloud Identity services.10

What it does not do

It Is Not a Security Setting

A practice can hold an entirely appropriate agreement with its cloud email provider and still have every one of these:

  • Shared passwords across a front desk
  • Weak or absent multi-factor authentication
  • Forwarding rules sending mail somewhere nobody approved
  • Former employees with accounts that still sign in
  • Unmanaged personal devices holding years of mail
  • Far more administrators than the practice needs
  • Third-party applications connected during a trial and never disconnected
  • Sensitive attachments handled with no particular care
  • Staff who have never had security training

The existence of the BAA corrects none of that. Not one item on that list is touched by signing it.

A BAA is part of the legal and compliance framework. It isn't a security configuration button.

Scope is the part people miss

A BAA covers named services, not a vendor as a whole. Google's HIPAA Included Functionality list names the covered services, and Google states that third-party applications, including add-ons, are not included in that covered functionality, and that the BAA terms do not extend to Additional Google Services.1011

So the meaningful question is not "do we have a BAA?" It is "does our agreement cover the services our staff are actually using for this information?" Those are different questions, and only the second one has a useful answer.

The Distinction That Matters Most

Meeting a Requirement and Protecting a Patient Are Not Always the Same Question

Three questions, asked about the same mailbox, that produce three different answers.

Compliance asks

"Are we meeting the applicable requirements?" It is a question about rules, evidence and documentation. It has a defined scope, and it can be satisfied.

Security asks

"How could this information actually be compromised?" It is a question about attackers, mistakes and accidents. It does not care what the rule says, and it is never finished.

Best practice asks

"Given the sensitivity of this information, what additional reasonable protections should we implement?" It is a question of judgement, and it is where most of the real protection lives.

Where CareVixis stands

When you're entrusted with confidential patient information, CareVixis believes the conversation shouldn't end with "Are we technically compliant?"

It should continue with: "Is this how we would want our own confidential information protected?"

That is a higher bar than the regulations set, and we are labelling it honestly as our view rather than as a legal obligation. The Security Rule itself contemplates this: it requires you to consider the probability and criticality of potential risks, the size and capability of your organisation, and the cost of the measures, and then choose measures that reasonably and appropriately implement the standards.1 That is a judgement the practice makes. We think it should be made deliberately.

Compliance is the minimum requirement. Protecting confidential patient information should be the goal.

Six Situations We Actually See

None of These Have a One-Word Answer.

Each of these gets discussed online as though it were settled. None of them is. In every case the useful move is to replace the verdict with the questions that produce one.

Scenario One

A practice uses a Gmail address with patients

A small behavioral health practice communicates with patients from a Gmail address. The internet will tell you this is a violation. The internet does not know enough to say that.

The questions that actually decide it
  • Is this consumer Gmail, or an appropriate Google Workspace environment?
  • Is the applicable BAA in place, and does it cover the services in use?
  • How is the account and the wider tenant configured?
  • Is multi-factor authentication enforced?
  • Who has access, including delegates and administrators?
  • Are messages automatically forwarded anywhere?
  • What third-party applications have been granted access?
  • How is PHI actually handled once it arrives?
  • Are the devices that reach it appropriately secured?
  • What policies and procedures govern email use?

The email address alone doesn't tell you whether the practice is compliant. The environment and how it is operated matter.

Scenario Two

"We bought the business plan, so we're compliant"

A practice moves to a paid Google Workspace subscription and treats the purchase as the end of the project. Licensing a platform with compliance capabilities and operating it appropriately are different things, and only the second one protects anybody.

What buying the licence did not do
  • Execute the business associate amendment, which Google requires you to enter into
  • Restrict PHI to the services the agreement actually covers
  • Turn on two-step verification for every user
  • Restrict which third-party Marketplace applications may connect
  • Decide who gets super administrator rights
  • Configure retention or export, or decide whether Vault is needed
  • Write a single policy or train a single person

The subscription supplies capability. Compliance is an outcome of how the capability is used, which is why no vendor certifies its customers as compliant.

Scenario Three

The mailbox that never really left

A billing coordinator leaves. The account is "handled" by changing the password. Six months later it is still licensed, a delegate still has access, an old forwarding rule still fires, and the phone that was never collected still syncs the mailbox.

Identity lifecycle, which is both a security and a compliance concern
  • Is sign-in actually disabled, and were active sessions and tokens revoked?
  • Were delegation and forwarding rules removed, not just the password changed?
  • Was the mailbox transferred or preserved deliberately?
  • Were devices collected, or access to them removed?
  • Was the account removed from connected third-party applications?
  • Is there a record showing when each of those happened?

Termination procedures are an Addressable specification under Workforce Security.2 Addressable is not the same as optional: implement it, or document why not and put an equivalent measure in place.1

Scenario Four

A provider reads patient email on a personal phone

This is normal, it is often necessary, and it is not prohibited. HIPAA does not ban personal devices. What the Security Rule expects is that you assess the risk and apply safeguards that are reasonable and appropriate for your environment.1

What a documented standard usually covers
  • Screen lock and a non-trivial passcode or biometric
  • A supported operating system, kept current
  • Protection on the account itself, not only the device
  • Device encryption where the platform provides it
  • A defined route for reporting loss or theft, quickly
  • Remote wipe or selective removal of practice data where appropriate
  • A written policy the workforce has actually seen

We are not going to tell you HIPAA forbids personal phones, because it does not. We will tell you that an unmanaged device holding years of patient email is a risk worth measuring rather than assuming.

Scenario Five

The convenient forwarding rule

A staff member forwards practice email to a personal account so they can keep an eye on things from home. It is well intentioned. It is also the quietest way for patient information to leave an environment you control and enter one you do not.

What the rule actually did
  • Moved PHI to an account with no agreement covering it
  • Placed it outside your administrative control and your audit logs
  • Made it unreachable by your retention, legal hold and offboarding processes
  • Left it in place after the staff member leaves, unless someone looks
  • Created a copy you cannot produce, search, or delete on request

Our recommendation Block automatic external forwarding by default and allow it only by documented exception. Then go and look at what rules exist today, because most practices have never checked.

Scenario Six

A patient emails their card number

Nobody asked them to. They did it because it was convenient, and now it is sitting in a mailbox, a sent folder, a backup and possibly a phone. This is largely not a HIPAA question.

Two frameworks, two different answers
  • PCI DSS Requirement 4.2.2 prohibits sending unprotected primary account numbers through end-user messaging technologies9
  • The PCI Security Standards Council states that email, instant messaging, SMS and chat are all end-user messaging technologies9
  • A HIPAA-compliant environment does not satisfy PCI DSS on its own
  • Storing that message makes the problem larger and longer lived

Payment card data should be handled through a payment workflow designed for it. The goal is to keep card data out of email, not to re-engineer email into a payment system.

Two Frameworks, Often Confused

HIPAA and PCI DSS Are Not the Same Thing

Most healthcare practices handle both patient information and payments. The two frameworks address different information, different risks and different obligations, and satisfying one tells you nothing about the other.

HIPAA
Protected Health Information

Federal regulation. Applies to covered entities and their business associates. Enforced by the HHS Office for Civil Rights.

Sometimes Both may affect the same organisation, the same workflow, and occasionally the same message.
PCI DSS
Payment Card Data

A contractual security standard from the PCI Security Standards Council, enforced through payment brands and acquirers rather than by a federal agency.

HIPAA compliance does not automatically equal PCI DSS compliance, and PCI DSS compliance does not automatically equal HIPAA compliance.

The practical conclusion

Reducing or eliminating payment card information from email is generally preferable to trying to make email a payment card processing workflow. Every message containing a card number expands the environment that has to be protected, and it expands it into backups, mobile devices, exports and archives that were never designed for that data.

A payment link, a portal, a terminal or a phone process handled through your payment provider keeps card data inside a system built for it. That is a smaller problem than securing a mailbox to a payment standard, and it is usually a much cheaper one. CareVixis recommendation

Common Gaps

What Practices Commonly Get Wrong

Tick the ones that are genuinely handled at your practice today. Nothing is recorded, nothing is sent anywhere, and this stays in your browser. The point is the honest count at the bottom, which is for you alone.

You have 0 of 18 handled today. Not every unticked item is a violation, and we have deliberately not presented them that way. Several are best practice, one belongs to a different framework entirely, and the rest depend on your environment.
Measurable, Not Vague

Can You Answer "Yes" to These Questions Today?

Advice like "improve your email security" cannot be acted on or checked. These can. Every one of them has an answer that somebody at your practice either knows or does not know, and finding out which is itself informative.

Identity

What percentage of email users have MFA enforced? Target: 100%
How many shared user credentials exist? Best-practice target: 0
How many former employees currently retain active access? Target: 0
How many users hold administrative privileges? Target: only documented, authorised personnel who require them

Access

When was the last user access review completed?Record the date
Can you produce a current list of everyone with mailbox access?Yes / No
Can you identify every mailbox delegate?Yes / No
Can you identify every active forwarding rule?Yes / No

Devices

What percentage of devices reaching sensitive practice email meet your documented security standard? Best-practice target: 100%
Do you have a documented security standard for those devices at all? Yes / No
Can you list the devices currently connected to each mailbox? Yes / No

Monitoring

Are authentication and administrative events logged?Yes / No
Who reviews the security alerts, by name?Name a person
Is there a documented escalation procedure?Yes / No
Could you determine when and from where a suspicious sign-in occurred?Yes / No

Email Authentication

SPF declares which servers may send for your domain. DKIM cryptographically signs your messages. DMARC tells receiving servers what to do when a message fails, and sends you reports.
SPF: Yes / No DKIM: Yes / No DMARC: Yes / No DMARC policy: None / Quarantine / Reject
These primarily address domain and email authentication and spoofing. They are not, by themselves, HIPAA compliance controls, and we will not present them as such. They protect your domain from being impersonated to your patients, your staff and your payers. Best practice, not a regulatory requirement

Encryption

In transit: TLS between mail servers is the baseline, and it is normally opportunistic rather than guaranteed, which means delivery can fall back to an unprotected path.
At rest: a separate question, answered by the platform and by your own device encryption.
Secure message delivery: where risk warrants it, a portal or enforced encrypted delivery gives you assurance that opportunistic TLS does not.
Talking to patients is treated differently. HHS has stated that the Privacy Rule does not prohibit the use of unencrypted email for treatment-related communications between a provider and a patient, provided reasonable safeguards are applied, such as checking the address before sending and limiting the amount of information disclosed.5 That is a narrower permission than it is often reported to be, and it does not displace the Security Rule.
Encryption is an addressable specification for both access control and transmission security. Assess it, implement it if reasonable and appropriate, or document why not and implement an equivalent alternative measure.13 Avoid the shortcut "TLS = HIPAA compliant"

Governance

Date of the most recent security risk analysisRequired specification2
Date of the most recent email security reviewRecord the date
Date of the most recent workforce security trainingRecord the date
Date access permissions were last reviewedRecord the date
Does an incident response plan exist?Response and reporting is required2
Are termination and offboarding procedures documented?Yes / No

If several of these produced a shrug rather than an answer, that is genuinely useful information and it is also completely normal. Almost no practice we meet can answer all of them on the first pass. Knowing which ones you cannot answer is the actual starting point.

You will talk to a person

Would It Help to Just Talk This Through With Someone?

Compliance is a genuinely big issue, and it is one of the heaviest things a practice carries alongside actually seeing patients. Most of the material written about it is designed to make you anxious enough to buy something. We would rather answer your questions.

If you have read this far and you are not certain where your practice stands, that is a completely reasonable place to be, and it is worth a conversation rather than another article. Ask us anything: what your BAA actually covers, whether your setup is a problem, what you should look at first, or whether the thing you are worried about is worth worrying about. We're here to help, and there is no cost and no obligation to any of it.

Schedule a 15-Minute Conversation Or Call (352) 897-8598

No scare tactics, and no automatic recommendation to replace what you already have. If your setup is fundamentally fine, we will tell you it is fine. 100% US based, and you talk to the people who do the work.

A Practical Starting Framework

10 Steps a Practice Can Take

In this order, because each step depends on the one before it. Step five is where most practices want to start, and it is much less useful before steps one and two are done.

1

Identify every email system the practice uses

Not the one you think of first. The scheduling address, the old billing account, the fax-to-email service, the address on the business cards nobody reprinted, and the personal address a provider still uses for referrals.

2

Determine whether PHI or payment card information enters those systems

This decides which frameworks apply to which system. Look at real mailboxes rather than at what the policy says should be happening. The two answers are often different.

3

Verify the applicable vendor agreements, including BAAs where required

Not only that one exists, but which services it covers. Google publishes a defined Included Functionality list and excludes third-party applications and add-ons from it.1011

4

Perform and document an appropriate risk analysis

An accurate and thorough assessment of potential risks and vulnerabilities is a Required implementation specification, and it is the foundation the addressable decisions rest on.2 NIST SP 800-66r2, written with the HHS Office for Civil Rights, sets out a process you can follow.8

5

Require strong identity controls and MFA

Unique accounts for every person is Required.3 MFA on all of them is our recommendation and a widely accepted best practice, and it is one of the changes HHS has proposed to require outright.7

6

Review every user, administrator, delegate, application, device and forwarding rule

All six categories, in one pass, written down. This single exercise finds more real exposure than any other item on this list, and most practices have never completed it.

7

Review encryption and secure message delivery against your risk

Encryption is addressable, so the decision has to be made and recorded rather than assumed.1 HHS has said the Security Rule does not expressly prohibit sending e-PHI by email, and that you must assess your use of open networks and select an appropriate solution.4

8

Configure and monitor SPF, DKIM and DMARC

Then actually read the DMARC reports and move the policy past p=none once your legitimate senders pass. This is anti-spoofing and domain protection, not HIPAA compliance. Best practice

9

Document onboarding, offboarding, incident response, access review and training procedures

Incident response and reporting is Required.2 Termination procedures and training specifications are Addressable, which still means implement or document a reasoned alternative.12

10

Reassess periodically, and whenever something significant changes

New system, new vendor, new staff, new workflow. Periodic evaluation is a Required standard on its own.2

Completing these ten steps does not guarantee compliance, and we are not going to suggest otherwise. They are a practical starting framework. Compliance depends on your whole environment, your documentation, your workforce and how the systems are actually used day to day, and no ten-step list can account for that. What these steps will do is replace guesswork with a set of answers you can point at.

The CareVixis Approach

We Don't Start by Telling You to Replace Everything.

Your current email system may be perfectly capable of supporting your practice. The question is whether it has been configured, secured, documented and integrated appropriately for the information you're asking it to protect.

CareVixis works shoulder to shoulder with providers to examine the entire environment, not just one application. Email. Communications. EHR. Billing. Patient information. Payment workflows. User access. Devices. Policies. Security. Compliance.

Your system may not be broken. It may simply be fragmented.

Our goal is to identify the gaps between those systems and help the practice build a more secure, manageable and defensible environment. If keeping what you have is the right answer, that is a supported outcome and we will manage it for you. The decision is never "switch or don't". It is who is accountable for making this work.

Don't Ask, "Do We Have a BAA?"

Ask: "Can We Demonstrate How We Protect Patient Information?"

We'll look at your current setup with you, explain what we see, identify potential gaps, and separate compliance considerations from security best practices. We understand how much weight this carries for a practice, and we are here to help.

Review My Practice Email Environment Talk to Someone Now: (352) 897-8598

No scare tactics. No automatic rip-and-replace recommendation. Just practical answers.

A 15-minute conversation is usually enough to know whether you have a real problem or a paperwork problem.

Other Platforms

Using Something Else?

The principles are the same everywhere. The specifics, and what each vendor actually publishes, are not.

Gmail & Google WorkspaceWhat Google publishes about BAAs, covered services and add-ons. Outlook & Microsoft 365In-scope services, mailbox permissions, and what Microsoft says a BAA does not do. Yahoo MailA consumer service with no published healthcare agreement. What that means in practice. Free Email Accountsgmail.com, outlook.com, hotmail.com, aol.com and ISP addresses used as a practice address.
Sources

Where These Statements Come From

Every regulatory claim on this page traces to one of these. Where we could not find an authoritative source for a claim, we have labelled it as our own recommendation instead of asserting it as a requirement.

  1. U.S. Department of Health and Human Services, HIPAA Security Rule, 45 CFR 164.306, Security standards: General rules. Establishes the general requirements, the flexibility of approach factors, and the "Required" versus "Addressable" distinction, including the obligation to document why an addressable specification is not reasonable and appropriate and to implement an equivalent alternative measure where reasonable and appropriate. eCFR 45 CFR 164.306
  2. HHS, HIPAA Security Rule, 45 CFR 164.308, Administrative safeguards. Source for risk analysis, risk management, sanction policy and information system activity review (all Required); workforce security and termination procedures (Addressable); information access management; security awareness and training (Addressable specifications); security incident procedures, response and reporting (Required); contingency plan including data backup, disaster recovery and emergency mode operation (Required); evaluation (Required); and business associate contracts (Required). eCFR 45 CFR 164.308
  3. HHS, HIPAA Security Rule, 45 CFR 164.312, Technical safeguards. Unique user identification and emergency access procedure are Required; automatic logoff and encryption and decryption are Addressable; audit controls and person or entity authentication are standards; integrity controls and transmission encryption are Addressable. eCFR 45 CFR 164.312
  4. HHS, FAQ: Does the Security Rule allow for sending electronic PHI (e-PHI) in an email or over the Internet? The Security Rule does not expressly prohibit the use of email for sending e-PHI; the access control, integrity and transmission security standards require policies and procedures to restrict access, protect integrity and guard against unauthorised access, and a covered entity must assess its use of open networks and select an appropriate solution. HHS FAQ 2006
  5. HHS, FAQ 570: Does the HIPAA Privacy Rule permit health care providers to use e-mail to discuss health issues and treatment with their patients? Yes, with reasonable safeguards applied, and the Privacy Rule does not prohibit unencrypted email for treatment-related communications between providers and patients. HHS FAQ 570
  6. HHS Office for Civil Rights, Guidance on HIPAA and Cloud Computing. A cloud service provider that creates, receives, maintains or transmits ePHI is a business associate, including where it cannot view the encrypted data; a BAA is required; and where the customer controls certain security features and fails to implement them, a provider is not responsible for compliance failures attributable solely to the customer. HHS Cloud Computing guidance
  7. HHS Office for Civil Rights, HIPAA Security Rule Notice of Proposed Rulemaking, issued 27 December 2024 and published in the Federal Register in January 2025. Proposes removing the required versus addressable distinction and would require multi-factor authentication and encryption of ePHI at rest and in transit, with limited exceptions. This is a proposed rule. It was not final as of the date on this page, and the current Security Rule remains in effect. HHS NPRM factsheet
  8. National Institute of Standards and Technology, NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide (February 2024), developed with the HHS Office for Civil Rights. Provides a risk assessment process and maps Security Rule standards to NIST Cybersecurity Framework subcategories and SP 800-53r5 controls. NIST SP 800-66r2
  9. PCI Security Standards Council, PCI DSS Requirement 4.2.2 and the Council's published FAQ: unprotected primary account numbers may not be sent via end-user messaging technologies, and email, instant messaging, SMS and chat are all end-user messaging technologies. Requirement 4.2.1 requires strong cryptography and security protocols when cardholder data is sent over open, public networks. PCI SSC FAQ 1085
  10. Google, HIPAA compliance with Google Workspace and Cloud Identity. Customers subject to HIPAA who wish to use covered services must enter into a Business Associate Amendment, and customers who have not signed a BAA with Google must not use PHI in Google Workspace or Cloud Identity services. Third-party applications, including add-ons, are not part of the Included Functionality covered by the BAA, and the BAA terms do not extend to Additional Google Services. Google Workspace Admin Help
  11. Google, HIPAA Included Functionality, the published list of Google Workspace services covered by the HIPAA Business Associate Addendum. Read the current version rather than relying on any summary, including this one, because the list changes. Google HIPAA Included Functionality

Educational information, not legal advice. This page is provided for general educational purposes. It is not legal advice, it is not a compliance certification, and it does not create any professional or advisory relationship. CareVixis is not a law firm and does not provide legal opinions.

Compliance depends on your specific circumstances. Whether any organisation complies with HIPAA, the HIPAA Security Rule, PCI DSS or any other framework depends on that organisation's own environment, risk analysis, policies, procedures, workforce, technology, vendor agreements and the way its systems are actually used. Nothing on this page determines that, and no questionnaire can.

Nothing here states that using Gmail, Google Workspace, Outlook, Microsoft 365 or any other named service violates HIPAA or PCI DSS. That is not our position, and it would not be accurate. Descriptions of vendor offerings are drawn from the vendors' own published documentation as of the date on this page and are summarised here; vendors change their terms, their service lists and their agreements, so verify the current version directly with the vendor before relying on it.

Regulatory requirements change. Statements about the HIPAA Security Rule reflect the rule in effect as of 10 September 2026, and a proposed rule that would change several of these points was pending and not final on that date. Consult qualified legal counsel and your own compliance advisors regarding your obligations.

Talk to Someone About This