Email Security & Compliance: Free Consumer Accounts

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

This page is about the free consumer tiers: gmail.com, outlook.com, hotmail.com, yahoo.com, aol.com, icloud.com and the address your internet provider gave you. Plenty of good practices run on one, usually for historical reasons rather than by decision. We are not going to tell you that makes you non-compliant. We are going to show you what the vendors actually publish, and what changes.

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.

The Fact That Settles Most of the Argument

The Free Tier and the Business Tier Are Different Products

This is the part that gets lost. When people say "Gmail is not HIPAA compliant" and someone else says "yes it is", they are usually talking about two different products that happen to share a name. Here is what each vendor publishes, in their own terms.

Google

Google Workspace and Cloud Identity, not free gmail.com

Google publishes a HIPAA Business Associate Amendment for customers subject to HIPAA who wish to use certain Google Workspace or Cloud Identity services, and publishes a defined HIPAA Included Functionality list of the covered services. Google states that customers who have not signed a BAA with Google must not use PHI in Google Workspace or Cloud Identity services, and that third-party applications including add-ons are not part of the Included Functionality.10

A free gmail.com address is a consumer product held by an individual. It is not the Workspace environment that amendment attaches to.

Microsoft

Named enterprise services, not free outlook.com or hotmail.com

Microsoft enters into Business Associate Agreements with its covered entity and business associate customers, made available through the Microsoft Online Services Data Protection Addendum, and publishes the list of in-scope cloud platforms and services it covers. That list describes enterprise services including Office 365, Exchange Online, Microsoft Teams, SharePoint Online, OneDrive for Business and Microsoft Entra ID.11

Consumer Outlook.com and Hotmail accounts are a separate consumer product and are not part of that enterprise services list. Microsoft also answers "No" to whether having a BAA ensures the customer's own compliance.11

Yahoo, AOL and most ISP addresses

No published healthcare agreement that we could find

We reviewed Yahoo's published terms and could not find any healthcare business associate agreement offering for Yahoo Mail; the Terms of Service make no reference to HIPAA, protected health information, healthcare or a business associate agreement.12 The same pattern applies to most consumer and ISP mail services, which are sold to individuals rather than to organisations.

This records the absence of a published offering, not a refusal. Vendors change what they publish. If your practice needs certainty on this, ask the vendor directly and get the answer in writing rather than relying on any summary, including ours.

What this does and does not mean

It does not mean any practice using a free address is violating HIPAA. We are not saying that, and it would not be accurate. The rules apply to organisations, and whether an organisation complies depends on its whole environment.

What it does mean is narrow and specific. HHS guidance is clear that a service provider which creates, receives, maintains or transmits ePHI on your behalf is a business associate, and that a covered entity must have a business associate agreement in place with it.6 Where the vendor publishes no such agreement for the tier you are on, that requirement has no obvious route to being satisfied. That is a question to resolve, and resolving it is usually easier and cheaper than people expect.

The argument is not "Gmail versus HIPAA". It is "which product am I actually using?"

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.

The One Item That Is Not a Grey Area

One Address, One Password, Four People at the Front Desk

Almost everything on this page is a judgement call under a risk-based rule. This one is different, and it is the pattern free consumer accounts produce most often, because a free account has no concept of multiple users.

Why shared credentials sit differently from everything else here

Unique user identification is marked "Required", not "Addressable", under the Access Control standard. The specification is to assign a unique name or number for identifying and tracking user identity.3 There is no "assess whether it is reasonable and appropriate" path for a Required specification, and no documented-alternative route of the kind that exists for addressable ones.1

The knock-on effects are practical rather than theoretical. Audit controls require mechanisms that record and examine activity, and information system activity review, itself Required, expects regular review of records such as audit logs and access reports.23 A shared password makes every one of those records say the same thing: "the account". If something goes wrong, nobody can tell you who did it, and neither can the logs.

We are still not going to tell you that your specific arrangement is a violation, because that depends on the full facts and is not something a web page can determine. What we will say is that of everything discussed on this page, this is the item most directly connected to a Required specification, and it is usually the cheapest one to fix.

The distinction worth knowing

A shared password is not the same thing as a shared mailbox. A shared mailbox that several named people reach through their own individual accounts gives you the same convenience at the front desk, and every action still attributes to a person. That is a standard feature of business email subscriptions and it is not available on a free consumer account. CareVixis recommendation

Two Models, Two Sets of Responsibilities

Third-Party Email and Email You Control

If a practice does move off a free consumer address, the choice is usually between a business cloud subscription and email the organisation runs itself. Neither is automatically the safer one.

Model One

Third-Party / Cloud Email

Google Workspace and Gmail, Microsoft 365 and Outlook, and other hosted business email providers, on a domain the practice owns.

What the provider brings
  • Managed infrastructure, patched and maintained without practice involvement
  • Security engineering and threat detection at a scale no small practice could fund
  • 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 services1011
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 environment
  • 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, on premises or on infrastructure the organisation controls.

What you gain
  • Direct control over configuration, data location and retention
  • Independence 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. For a practice leaving a free consumer mailbox, a managed business subscription on its own domain is almost always the shorter and cheaper route to a defensible position, and it costs a few dollars per person per month. CareVixis recommendation

The Most Common Misunderstanding

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

This matters here for a specific reason. A practice that upgrades from a free account specifically to obtain a BAA can arrive at the new platform believing the job is done. It is not, and the gap between those two beliefs is where most real exposure sits.

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

It is a genuine requirement, and obtaining one is a genuine improvement. It is the beginning of the work rather than the end of it.

What it does not do

It Is Not a Security Setting

A practice can hold an entirely appropriate agreement with its new provider and still have every one of these on day one:

  • The same shared password everybody used on the old free account
  • No multi-factor authentication, because nobody turned it on
  • A forwarding rule copying everything back to the old free mailbox
  • Former employees still holding accounts, migrated along with everyone else
  • Unmanaged personal devices, now syncing the new mailbox as well as the old one
  • More administrators than the practice needs
  • Third-party applications reconnected out of habit
  • The old free mailbox still receiving mail, indefinitely
  • Staff who have never had security training

Migration moves the mail. It does not move the practices, and it certainly does not fix them.

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 publishes a defined HIPAA Included Functionality list and states that third-party applications, including add-ons, are not part of it.10 Microsoft publishes its in-scope cloud platforms and services and states plainly that having a BAA with Microsoft does not on its own ensure your compliance.11

So the meaningful question is never "do we have a BAA?" It is "does our agreement cover the services our staff are actually using for this information, and are we operating them properly?"

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?"

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?"

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?"

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 small practice uses a free address with patients

A behavioral health practice communicates with patients from a free consumer 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 a consumer account, or a business environment on the same brand?
  • Does PHI genuinely pass through it?
  • Is an applicable agreement in place, and can anyone produce it?
  • How is the account configured?
  • Is two-step verification switched on?
  • Who has access, and does anyone share the password?
  • Are messages automatically forwarded anywhere?
  • What applications have been granted access?
  • 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. What a free tier does change is that the agreement question and the control questions usually have no answer yet.

Scenario Two

"We're small, and it's only scheduling"

A two-person practice keeps the free account on the reasonable basis that no clinical information passes through it. This is a legitimate position, and it is the one we test most carefully, because it holds only if it is actually true.

What tends to be found when someone actually looks
  • A patient name alongside an appointment with a named specialist
  • A records request that somebody answered helpfully
  • An insurance or balance discussion with a patient
  • A referral letter forwarded as an attachment
  • A photograph a patient sent unprompted
  • A payer or clearinghouse message containing member details

Size does not change which rules apply, although the Security Rule does expect you to weigh your organisation's size, complexity and capabilities when choosing measures.1 If you rely on the no-PHI boundary, make it real: check actual mailboxes, document what you found, tell staff where the line is, and re-check periodically.

Scenario Three

The account belongs to a person, not the practice

The practice email was created by whoever set things up, in their own name, with their own phone as the recovery method. They leave. The practice has no console, no administrator, and no mechanism to disable, transfer or preserve anything.

Identity lifecycle, which is both a security and a compliance concern
  • Who legally and practically controls the account?
  • Can the practice disable access, or only ask?
  • Can it export or preserve the mailbox?
  • Was anything forwarded out of it that is still running?
  • Does that person still hold practice information on a personal device?
  • Is there any record of what was in there?

Termination procedures are an Addressable specification, and contingency planning specifications including data backup and disaster recovery are Required.2 Both are difficult to satisfy for an account the organisation does not control.

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
  • A written policy the workforce has actually seen

On a free consumer account there is usually no central way to see which devices are connected or remove practice data from one. That does not make it prohibited. It makes it a risk worth measuring rather than assuming.

Scenario Five

The convenient forwarding rule

A staff member forwards practice email to their personal free account so they can keep an eye on things from home. It is well intentioned, and it is the quietest way for patient information to leave an environment you control.

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, and this one costs nothing to find.

Scenario Six

A patient emails their card number

Nobody asked them to. They did it because it was convenient, and now it is in a mailbox, a sent folder and 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
  • On a free mailbox shared by several people, you may have no reliable way to find and remove every copy

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 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 two-step verification enforced? Target: 100%
How many shared user credentials exist? Target: 0. Unique user identification is Required3
How many former employees currently retain active access? Target: 0
Whose personal phone or address is the recovery method for the practice mailbox? Name it, then decide whether that is acceptable

Access

When was the last user access review completed?Record the date
Can you produce a current list of everyone who knows the password?Yes / No
Can you identify anyone the mailbox is shared with?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 signed in to the mailbox? Yes / No

Monitoring

Can you see recent sign-in activity for the account?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
On a free consumer address, all three answers are effectively "not applicable to us". These are DNS records published for a domain, and that domain belongs to the provider rather than to your practice. You cannot configure them for your practice identity, and you receive no reports about anyone impersonating your practice by name. A reason practices move to their own domain
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. 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. Free consumer tiers generally do not offer this.
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 are reading this because someone told you your email address is a problem, that conversation was probably shorter and more alarming than it needed to be. Ask us anything: whether it is actually a problem for your practice, what moving would involve and what it would cost, what you should do first if you only have an hour, 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. On a free account, steps five and six cost nothing and can be done today, which is why we would not wait for the bigger project before doing them.

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 free address on the referral pads, and the personal accounts staff use for practice matters.

2

Determine whether PHI or payment card information enters those systems

This decides which frameworks apply and how urgent everything else is. Open real mailboxes and look, rather than relying on what the policy says should be happening. The two answers are often different.

3

Verify the applicable vendor agreements, including BAAs where required

Published healthcare agreements attach to business products.1011 Where a vendor publishes nothing for the tier you are on, ask directly and get the answer in writing rather than assuming either way.

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

Stop the shared password, and switch on two-step verification

Both are free, and both can be done this afternoon. Unique user identification is Required rather than addressable.3 Two-step verification is our recommendation, and it is one of the changes HHS has proposed to require outright.7

6

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

Also free, and usually an hour of work. Find out who knows the password, what is connected, what is forwarded and which devices are signed in. This single exercise finds more real exposure than any other item on this list.

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

Get onto a domain you own, then configure SPF, DKIM and DMARC

This is the larger project, and it is what makes the practice identity defensible and portable. It also means a future change of provider never changes your address again. Plan the migration so referral continuity and payer registrations survive it. Best practice CareVixis recommendation

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.

Even where the honest answer is that a mailbox should eventually move, that is a plan rather than an emergency. A rushed migration loses referral continuity, breaks payer and portal registrations, and leaves mail arriving somewhere nobody is watching.

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. Where a move makes sense we plan it properly: a domain the practice owns, both mailboxes running in parallel, referrers and payers notified, and the old mailbox retained under a documented decision rather than switched off and forgotten. 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, and the published HIPAA Included Functionality list. Customers subject to HIPAA who wish to use covered services must enter into a Business Associate Amendment, customers who have not signed a BAA with Google must not use PHI in those services, and third-party applications including add-ons are not part of the Included Functionality. Google Workspace Admin Help
  11. Microsoft, HIPAA and HITECH Act, Microsoft Compliance. Microsoft enters into Business Associate Agreements with covered entity and business associate customers, makes the BAA available through the Microsoft Online Services Data Protection Addendum, publishes its in-scope cloud platforms and services, and answers "No" to whether having a BAA with Microsoft ensures the customer's own HIPAA compliance. Microsoft Learn: HIPAA and HITECH Act
  12. Yahoo, Terms of Service, reviewed 10 September 2026. We found no reference to HIPAA, protected health information, healthcare or a business associate agreement, and we could not locate a published healthcare business associate agreement offering for Yahoo Mail on Yahoo's own materials. This records the absence of a published offering as of that date. It is not evidence that Yahoo has declined to provide one, and vendors change what they publish. Confirm directly with the vendor, in writing, before relying on this either way. Yahoo Terms of Service

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, Hotmail, Yahoo Mail, AOL, iCloud, an ISP address or any other named service violates HIPAA or PCI DSS. That is not our position, and it would not be accurate. Statements about what a vendor does or does not publish describe published documentation reviewed on the date shown, and are not statements about that vendor's internal policies, its willingness to enter into any agreement, or the compliance of anyone using it. Vendors change their terms and their service lists, so verify the current position 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