Email Security & Compliance: Outlook, Microsoft 365 and Hotmail

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.

Start With the Vendor's Own Words

Microsoft Has Already Answered the Big Question.

Most of the argument about Microsoft 365 and HIPAA can be settled by reading what Microsoft publishes. It is unusually direct, and it is worth quoting rather than paraphrasing.

"Does having a Business Associate Agreement with Microsoft ensure my organization's compliance with HIPAA and the HITECH Act?"

Microsoft's published answer begins with the word "No." It goes on to say that by offering a Business Associate Agreement, Microsoft helps support your HIPAA compliance, but that using Microsoft services doesn't on its own achieve HIPAA compliance, and that your organisation is responsible for ensuring that you have an adequate compliance program and internal processes in place, and that your particular use of Microsoft services aligns with your obligations under HIPAA and the HITECH Act.10

Microsoft also states that there is currently no certification standard that the Department of Health and Human Services approves to demonstrate compliance with HIPAA or the HITECH Act.10 Nobody can sell you a certificate that makes your practice compliant, because no such certificate exists. If a vendor implies otherwise, that is worth noticing.

The platform is capable. Compliance is an outcome of how you operate it.

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

Practices running Microsoft 365 sometimes ask whether an on-premises Exchange server, or a server their IT provider runs, would be safer. It can be. It can also be considerably worse. What changes is which responsibilities the vendor absorbs and which ones stay with you regardless.

Model One

Third-Party / Cloud Email

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

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, reporting and eDiscovery tooling
  • Spam and malware filtering maintained continuously
  • A published business associate agreement covering named enterprise services10
  • Independent audits, including ISO/IEC 27001 and HITRUST CSF certification for services covered under the BAA10
What stays yours
  • Choosing the appropriate business subscription and service tier
  • Accepting the BAA, and knowing which services it covers
  • Tenant-wide administrator configuration
  • Who has an account, and what each one may reach
  • Multi-factor authentication and conditional access policy
  • Device security for anything that connects
  • Encryption choices beyond the defaults
  • Reviewing the audit logs the platform produces
  • Inbox rules, mail flow rules, and delegated mailbox permissions
  • Which third-party applications may consent to your tenant
  • Retention, hold, backup and recovery decisions
  • Account termination and offboarding
  • Workforce policies, sanctions and training

Microsoft supplies the platform and the audits. HHS guidance is explicit that where a customer controls certain security features and fails to implement them, the provider is not responsible for compliance failures attributable solely to the customer.6

Model Two

Organisation-Controlled / Self-Managed Email

An Exchange server or other 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 and licensing 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 mail 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, and Microsoft says so itself.

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

Microsoft makes its HIPAA BAA available through the Microsoft Online Services Data Protection Addendum, by default, to customers that are covered entities or business associates under HIPAA.10 Many practices already have it and have never read it.

What it does not do

It Is Not a Security Setting

A practice can hold an entirely appropriate agreement with Microsoft and still have every one of these:

  • A shared front desk login that four people use
  • Multi-factor authentication available but not enforced
  • Inbox rules quietly forwarding mail outside the tenant
  • A departed employee whose account still authenticates
  • Unmanaged personal phones carrying years of mail in the Outlook app
  • Six global administrators in a nine-person practice
  • Third-party applications that were granted tenant consent once and never reviewed
  • 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 accepting 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. Microsoft publishes a list of in-scope cloud platforms and services, and a further table of in-scope Office 365 services which includes Exchange Online, Microsoft Teams, SharePoint Online, OneDrive for Business, Microsoft Entra ID, Microsoft Defender for Office 365 and the Microsoft Purview portal, among others.10

That list is worth reading against what your practice actually uses, because it is where surprises live: a workflow tool, a form product, a note-taking app or an add-in that nobody thought of as a healthcare system. Microsoft also states that it cannot use a customer's own Business Associate Agreement, because its services are standardised across all customers.10 So the terms are Microsoft's, and the reading is your job.

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

The practice email is a hotmail.com address

A long-established practice has used the same Hotmail address since before Microsoft 365 existed. It is on the business cards, the referral letters and the payer files. 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 Outlook.com or Hotmail account, or a Microsoft 365 business tenant?
  • Does PHI actually pass through it, or only appointment logistics?
  • Is an applicable agreement in place, and does it cover this service?
  • Is multi-factor authentication enforced on the account?
  • Who else can sign in, and does anyone share the password?
  • Are messages forwarded anywhere automatically?
  • What applications have been connected to the account?
  • Which devices hold a copy of the mailbox?
  • What happens to this address when the person holding it leaves?
  • What policies and procedures govern its use?

The email address alone doesn't tell you whether the practice is compliant. The environment and how it is operated matter. What a consumer account does change is the vendor agreement question, which needs a definite answer rather than an assumption.

Scenario Two

"We bought Microsoft 365, so we're compliant"

A practice purchases Microsoft 365, sees the healthcare compliance material on Microsoft's site, and treats the purchase as the end of the project. Microsoft's own documentation contradicts that reading in plain language.10

What buying the licence did not do
  • Confirm which in-scope services your BAA actually covers
  • Restrict PHI to those services
  • Enforce multi-factor authentication on every account
  • Decide who holds global administrator rights
  • Review which third-party applications have tenant consent
  • Configure audit log review, retention or hold
  • Establish a device standard for the Outlook mobile app
  • Write a single policy or train a single person

Licensing the platform and operating it appropriately are different things. Microsoft states that using its services does not on its own achieve HIPAA compliance, and that the compliance program and internal processes are the customer's responsibility.10

Scenario Three

The mailbox that never really left

A billing coordinator leaves. Someone changes the password and moves on. Months later the account still authenticates, a colleague still holds full access permissions granted for one week of cover, an old rule still forwards a copy, and the phone nobody collected still syncs.

Identity lifecycle, which is both a security and a compliance concern
  • Is sign-in blocked, and were active sessions and refresh tokens revoked?
  • Were mailbox permissions and send-as rights removed, not just the password changed?
  • Were inbox rules and forwarding checked before the mailbox was converted or archived?
  • Was the mailbox preserved deliberately, under a retention decision someone made?
  • Were devices collected, or practice data removed from them?
  • 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

Usually through the Outlook mobile app, usually on a device the practice has never seen. 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.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
  • The ability to remove practice data selectively, where the tooling supports it
  • 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 creates an inbox rule sending a copy of everything to a personal address, 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 a tenant you administer 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 retention, legal hold, eDiscovery and offboarding
  • Left it running after the staff member leaves, unless someone looks
  • Created a copy you cannot produce, search, or delete on request

Our recommendation Control automatic external forwarding at the tenant level rather than trusting rule by rule, and allow exceptions only through a documented process. Then check what rules exist right now, because most practices have never looked.

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, a mobile device and whatever retention policy applies. 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
  • Retention and hold policies can keep that message alive far longer than anyone intends

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 archives, exports, mobile devices and holds 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 global administrator 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, including full access and send-as rights?Yes / No
Can you identify every active forwarding rule, including rules users set for themselves?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 Microsoft agreement actually covers, whether your tenant configuration 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 Hotmail 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. Microsoft publishes its in-scope cloud platforms and services and a separate table of in-scope Office 365 services; read the current version against what your staff actually use.10

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, new licence tier. 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. Microsoft, Health Insurance Portability and Accountability Act (HIPAA) and HITECH Act, Microsoft Compliance. Source for: Microsoft entering into Business Associate Agreements with covered entity and business associate customers; the BAA being available through the Microsoft Online Services Data Protection Addendum by default; the list of in-scope cloud platforms and services and the table of in-scope Office 365 services; the statement that there is no HHS-approved certification standard for HIPAA compliance; the statement that Microsoft cannot use a customer's own BAA; and the published answer "No" to whether having a BAA with Microsoft ensures the customer's compliance, with the accompanying explanation that using Microsoft services does not on its own achieve HIPAA compliance and that the customer is responsible for its own compliance program. Verify the current version, because service lists change. Microsoft Learn: HIPAA and HITECH Act

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 Outlook, Microsoft 365, Hotmail, Gmail, Google Workspace 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