It isn't, at least not yet. No cloud platform is automatically HIPAA compliant, and every new app, integration, or subcontractor adds another party that can touch patient data. The Verizon 2025 Data Breach Investigations Report found that the share of breaches involving third parties doubled to 30%.
The good news is that cloud compliance follows a clear pattern. Once you know which parts the provider handles and which parts stay with you, the checklist is manageable.
In this blog, you will learn what a HIPAA compliant cloud actually means, how the shared responsibility model works, how native settings, DIY, and a managed partner compare, the steps to secure PHI in the cloud, the most common mistakes, and how to choose the right cloud partner.
Key Takeaways
- Compliance is configured, not bought: Cloud providers support HIPAA, but your settings, contracts, and monitoring decide whether you comply.
- A BAA comes first: Every cloud service that handles ePHI needs a signed Business Associate Agreement before any data moves.
- The BAA only covers listed services: Features and add-ons outside the agreement aren't covered, even from the same vendor.
- Identity is the weak point: MFA, least-privilege access, and fast offboarding stop most cloud account takeovers.
- Backups need proof: Only a backup you've restored from shows you can recover patient data after deletion or ransomware.
- Reviews never finish: Every new tool, integration, or vendor is a reason to recheck your BAAs and settings.
What Does "HIPAA Compliant Cloud" Actually Mean?
HIPAA doesn't certify cloud products, and there's no government badge to look for. HHS has confirmed that no standard requires organizations to certify compliance, and it doesn't endorse private certifications either.
What triggers the rules is the data. Any cloud service that creates, receives, maintains, or transmits electronic protected health information (ePHI) falls under HIPAA, from your EHR to the file-sharing tool a billing coordinator uses.
A cloud provider handling PHI for a covered entity is a business associate, so a BAA must be signed first. The major vendors offer one, but each limits what it covers:
| Cloud Service | How the BAA Works | What Stays With You |
|---|---|---|
| Microsoft 365 | Covers listed services through Microsoft's data protection terms | MFA, sharing settings, and user permissions |
| Google Workspace | Covers only the listed "Covered Services" | Keeping PHI out of services that aren't covered |
| AWS | Standard BAA through AWS Artifact, limited to HIPAA-eligible services | Configuration of every service you use |
| Box | A signed BAA is required before PHI is stored | Folder permissions and shared links |
| Dropbox Business | Team admins can sign a BAA on qualifying plans | Link settings and admin controls |
None of these agreements makes an unconfigured account or a public share link compliant. That part is always on the customer.
Understanding what the label means makes it easier to see exactly where your responsibilities begin.
How Does the Shared Responsibility Model Work for HIPAA?
Think of it as a lease. The cloud provider secures the building, and you're responsible for what happens inside your unit. AWS describes the customer's share as the guest operating system, security groups, data, and identity and access management.
The split usually looks like this:
| Responsibility | Cloud Provider | Your Organization |
|---|---|---|
| Data centers and hardware | Secures and maintains them | Nothing to manage |
| Core network and infrastructure | Protects and patches it | Configures firewalls and network rules you control |
| User accounts and MFA | Provides the tools | Turns them on and enforces them |
| Sharing and permissions | Offers the settings | Sets them to the minimum necessary |
| Encryption | Offers encryption options | Enables and manages them for ePHI |
| Audit logs | Generates the logs | Retains and reviews them |
| Breach notification | Notifies you if it's the source | Notifies patients, HHS, and sometimes media |
Under the Breach Notification Rule, a business associate must tell the covered entity about a breach no later than 60 days after discovery. The covered entity then handles notice to individuals, HHS, and, for breaches affecting more than 500 residents of a state, local media.
With the split clear, the next question is who should handle your share of the work.
Native Settings vs DIY vs a Managed IT Partner: What's the Difference?
Every major platform includes security and compliance tools. The difference is who configures them, watches them, and keeps the paperwork current.
The following comparison helps explain how the three approaches differ:
| Aspect | Managed IT Partner | DIY With Internal Staff | Native Settings Left on Default |
|---|---|---|---|
| BAAs | Collected and tracked across vendors | Tracked by whoever remembers | Often never signed |
| MFA and access | Enforced for every user | Depends on staff time | Optional and often off |
| Sharing settings | Restricted and reviewed | Set once, rarely revisited | Defaults may allow broad links |
| Monitoring | Alerts reviewed 24/7 | Business hours at best | Alerts generated but unread |
| Backups | Independent, versioned, and restore-tested | Possible if prioritized | Retention settings, not true backup |
| Documentation | Kept ready for audits | Built when someone asks | Minimal |
| Best for | Small practices without IT staff | Larger teams with a compliance lead | Very low-risk, non-PHI use |
To be fair, a practice with a capable internal IT person can handle much of this itself. For most small healthcare offices, though, the gap is time and continuous attention, not tools.
Once you know who will do the work, the steps themselves are straightforward.
8 Simple Steps to Ensure HIPAA Compliance in the Cloud
Cloud compliance comes from running a clear checklist and repeating it as your tools change.
Here's how to approach it, step by step:
Step 1: Sign a BAA With Every Cloud Provider
Do this before any ePHI is stored or sent. Confirm the agreement names the specific services you use, and keep a signed copy where an auditor can find it.
Step 2: Lock Down Access
Set up granular access controls, including MFA, role-based permissions, and single sign-on, so only authorized staff can reach ePHI.
Step 3: Encrypt Data at Rest and in Transit
Turn on encryption for every device and service that touches ePHI, following NIST-recommended standards. Laptops and phones that sync patient files need device encryption too, not just the cloud account.
Step 4: Turn On Audit Logging
Log sign-ins, file access, and admin changes, and review the logs regularly rather than only after something looks wrong. Keep required HIPAA documentation for at least six years.
Step 5: Watch for Unauthorized Changes
File integrity monitoring and alerting catch unexpected edits, deletions, and new forwarding rules early.
Step 6: Classify Data and Plan for Recovery
Know where your most sensitive data lives, and make sure your backup and disaster recovery plans support a fast restore. Built-in retention settings in cloud suites are not a full backup.
Step 7: Run Regular Risk Assessments
Periodic risk assessments catch misconfigurations before an auditor or an attacker does.
Step 8: Recheck Everything When Your Stack Changes
Review BAAs and settings whenever you add a new tool, integration, or subcontractor. A short change checklist makes this a habit instead of an afterthought.
Also Read: Cloud Cybersecurity Solutions Providers
Following these steps covers the basics, but a few recurring mistakes still catch organizations out.
What Are the Most Common Mistakes That Put Cloud-Based PHI at Risk?
Most cloud breaches don't come from sophisticated attacks. They come from settings nobody double-checked.
These are the mistakes to watch for:
1. Trusting the Vendor Label
A vendor that signs a BAA still leaves configuration in your hands. The label is a starting point, not a finish line.
2. Forgetting to Update BAAs
New cloud tools, integrations, and subcontractors often start handling PHI before anyone signs an agreement.
3. Leaving Default Sharing On
Public or "anyone with the link" settings in shared drives can expose patient files to the internet.
4. Leaving Servers Exposed
In 2023, business associate MedEvolve settled for $350,000 after a server holding PHI for more than 230,000 people was left publicly accessible. iHealth Solutions, another business associate, paid $75,000 after PHI for 267 people was left on an unsecured server.
5. Skipping Ongoing Training
Staff who haven't been trained on phishing and file sharing make the same mistakes the settings were meant to prevent. Short, regular sessions and simulated phishing tests keep the lessons fresh.
Both cases started with a server left open to the internet, the kind of misconfiguration that routine reviews and monitoring are designed to catch.
Also Read: Backup vs Disaster Recovery: What's the Difference?
Knowing the common mistakes makes it easier to judge which partner can help you avoid them.
How to Choose the Right HIPAA Cloud Partner?
The right partner depends on your platforms, your size, and how much hands-on help you need. Here's what to look for:
- Platform depth: Look for real experience configuring Microsoft 365, Google Workspace, and cloud backup, not just reselling licenses.
- BAA management: The partner should help collect and track agreements across every vendor.
- Identity controls: MFA, role-based access, and same-day offboarding should be standard.
- 24/7 monitoring: Ask who reviews suspicious logins and mass email activity outside business hours.
- Tested backups: Confirm independent, versioned backups with periodic test restores.
- Compliance experience: The partner should run risk assessments and help keep documentation audit-ready.
- Clear terms: Short agreements with an opt-out show confidence in the service.
Thinking through these factors helps you pick a partner that keeps your cloud environment secure and audit-ready as it grows.
Also Read: Office 365 MDM: Mobile Device Management
How LME Services Helps Healthcare Organizations Secure PHI in the Cloud
Small medical practices, billing firms, and other healthcare-adjacent businesses rarely have staff who can configure cloud compliance settings and watch them around the clock. Most can't justify a full-time compliance hire either, so they need managed coverage that includes compliance work.
LME Services is a family-owned, second-generation managed IT and cybersecurity company with its headquarters in Hoffman Estates, Illinois. Leon Engelking founded the company in 1994 after leaving IBM, and his son, CEO Joe Engelking, leads it today. Joe sums up the security side of the business this way: "our job is to help our clients avoid the horror stories that cause so much stress, lost revenue, and worse."
HIPAA cloud services at LME include:
- Managed Cloud Security Services
- Cybersecurity Compliance Services and Consulting
- Healthcare IT Support Services
- Backup and Disaster Recovery Services
- Office 365 Migration Consultant Services
- Cloud Endpoint Protection with EDR
Here's what sets LME apart:
- Deep Microsoft 365 experience: LME has managed more than 100 Exchange, SharePoint, and OneDrive migrations, with an onsite technician on cutover day and Entra ID device policies set up along the way.
- Cloud backups that are tested: Microsoft 365 and Google Workspace data is backed up in separate, versioned storage, with periodic test restores and documented RTO and RPO.
- BAA collection handled: HIPAA engagements include Business Associate Agreement collection, so practices aren't chasing agreements from every vendor alone.
- Healthcare clients in Chicagoland: LME's healthcare clients include the American Board of Psychiatry and Neurology in Buffalo Grove, the Isaac Ray Center in Chicago, and Dr. Roma Franzia's practice in Winnetka.
- Identity and access built in: MFA on every sensitive account, single sign-on, role-based access, and same-day offboarding come with every cybersecurity plan.
- 24×7 human monitoring: A shared, managed SOC with 24×7 analysts watches for unusual logins, privilege changes, and unusual data movement.
- Flexible terms: Cybersecurity quotes arrive in 1–2 days, and plans run on a 1-year agreement with a 30-day opt-out.
This approach helps healthcare organizations use the cloud confidently while someone else keeps watch over the settings.
Conclusion
HIPAA compliance in the cloud rests on a few habits: signing BAAs first, configuring access and encryption carefully, logging and monitoring activity, and testing your backups. The provider secures the platform, but the settings and the evidence are yours.
That's where the right partner makes a real difference. Consistent monitoring, tracked BAAs, and restore-tested backups often decide whether a small misconfiguration stays small.
If you're moving patient data to the cloud or reviewing what's already there, connect with the LME Services team today for a free 15-minute consultation, and find out how to keep your cloud environment HIPAA ready.
Frequently Asked Questions
Which cloud services are HIPAA compliant?
No cloud service is compliant on its own. Microsoft 365, Google Workspace, AWS, Box, and Dropbox Business offer BAAs, but you still need to configure MFA, permissions, encryption, and logging correctly.
Do I need a BAA for every cloud tool my staff uses?
Yes, if the tool creates, receives, stores, or transmits ePHI. That includes file sharing, scheduling, email, and backup services.
Is Google Drive or Dropbox safe for patient records?
Both can support HIPAA compliance with a signed BAA and the right settings, such as restricted sharing and enforced MFA. Neither is safe for PHI on default settings.
What happens if a cloud vendor won't sign a BAA?
That vendor can't be used to store or transmit PHI. Choose a provider that will sign an agreement covering the services you need.
How often should cloud HIPAA settings be reviewed?
Run a full risk assessment at least once a year. Review settings and BAAs again whenever you add a tool, change vendors, or make a major system change.