HIPAA-Ready Managed Cloud for Practices and Health Tech
We run the cloud side of a healthcare business — Microsoft 365 or Google Workspace, backups, and the AWS, Azure, or Google Cloud accounts behind a patient portal or health app — to the Security Rule's safeguards, under a Business Associate Agreement.
Who this is for
Medical, dental, and behavioral-health practices whose EHR is cloud-hosted but whose email, file storage, backups, and devices nobody owns; and health-tech companies (telehealth, patient engagement, revenue-cycle software) that store ePHI in the cloud as a business associate of their customers.
Managed cloud for healthcare means an outside team operates the cloud systems that hold or touch electronic protected health information (ePHI) — productivity suites, backups, and the AWS, Azure, or Google Cloud accounts behind patient-facing apps — and configures them to the HIPAA Security Rule's administrative and technical safeguards (45 CFR 164.308 and 164.312). Because that team can reach ePHI, it is a business associate and signs a BAA.
When practices and health-tech teams call us
A payer, hospital partner, or health-system customer sent a security questionnaire asking for your risk analysis, BAA list, and audit-log retention, and nobody can answer it in writing.
The EHR is cloud-hosted, but the email, shared drives, scanners, and backups that also hold PHI were set up ad hoc and never reviewed.
Engineers launched the patient app on AWS or Azure before anyone checked which services the provider's BAA covers.
A ransomware story from a nearby practice or a phishing near-miss made the owners ask whether backups would actually restore.
The MIPS Promoting Interoperability attestation includes the security risk analysis measure, and the last analysis is years old.
Where healthcare cloud setups usually break
Most of the PHI risk in a small or mid-sized healthcare organization does not sit inside the EHR. Cloud EHR and practice-management vendors run their own hosting under their own BAA. The exposure is everything around them: referral letters exported to a shared drive, intake forms arriving by email, a scanner that saves to a personal OneDrive, a backup job nobody has tested, a former employee whose mailbox still forwards to a personal address. HHS has been explicit that a cloud provider storing ePHI is a business associate even when it only holds encrypted data and has no key, so each of those services needs a BAA and a configuration that matches the Security Rule.
Health-tech companies meet the same rule from the other side. A telehealth or patient-engagement product built for covered entities makes you their business associate, and the cloud account behind it is where most Security Rule evidence lives: who can read the production database, whether audit logs survive an engineer deleting them, whether backups are encrypted, whether staging holds copies of real PHI. AWS, Microsoft, and Google all sign BAAs, but each one covers a listed set of services. A feature built on a service outside that list is a gap even if the data is encrypted.
The Security Rule does not prescribe products. It requires an accurate and thorough risk analysis, risk management, access controls, audit controls, integrity controls, authentication, and transmission security, with documentation kept for six years. OCR's Risk Analysis Initiative has produced a run of settlements with providers and vendors that could not show an accurate analysis. Our job is to make the cloud configuration match what your documentation says, keep it that way as staff and systems change, and be able to show it when someone asks.
Healthcare systems we manage, and how
Cloud EHR and practice-management platforms
We do not administer the EHR application itself. We manage what connects to it: staff sign-in and MFA, the workstations and browsers used to reach it, exports and integrations, and the vendor's BAA on file.
Microsoft 365 or Google Workspace
Mail, chat, and shared drives are where PHI leaks in practice. We set conditional access and MFA, block automatic forwarding to outside domains, configure retention and audit logging, and turn on encryption for mail that leaves the organization.
AWS, Azure, and Google Cloud accounts
For health-tech products and practice servers moved to the cloud: separate accounts or subscriptions for production PHI, managed encryption keys, audit logs shipped to locked storage, and only services on the provider's BAA-covered list in the PHI path.
Backups and recovery
Encrypted, off-site backups with immutability where the platform supports it, and restore tests that are performed and recorded — the evidence for the contingency-plan standard at §164.308(a)(7).
Endpoints and front-office devices
Laptops, front-desk PCs, and scanners get disk encryption, patching, endpoint detection, and an inventory entry, because the device and media controls in §164.310(d) apply to them as much as to servers.
Interfaces and integrations
HL7 v2 or FHIR feeds, clearinghouse connections, and patient-messaging tools. We document each data flow, confirm a BAA exists for each vendor, and log use of the integration credentials.
What the managed HIPAA cloud service includes
ePHI inventory and data-flow map
A written list of every system that creates, receives, stores, or transmits ePHI and the flows between them — the input HHS guidance expects for the risk analysis and the first document an investigator asks for.
BAA register
Every vendor that touches PHI, when its BAA was signed, and which of its services the agreement covers. New tools are checked against the register before anyone uploads patient data.
Access control and audit logging
Unique user IDs, MFA on every account that can reach PHI, role-based access, and sign-in and admin logs from the cloud platform and the productivity suite retained centrally, so you can show who opened what.
Encryption at rest and in transit
Device encryption, encrypted cloud storage and databases, TLS on every connection, and documented key ownership. ePHI encrypted to the HHS guidance standard is not 'unsecured PHI', so losing it does not by itself trigger breach notification.
Tested backup and recovery
Backups of the systems you own, restore tests on a schedule, and a written contingency plan that says who does what when the EHR, email, or phones are down.
Monitoring and patching
Around-the-clock alerting on the cloud and identity platforms, monthly patch cycles for servers and endpoints, and an engineer who reviews suspicious sign-ins instead of leaving alerts in an inbox.
First 30 days
- Read-only access to cloud tenants and admin consoles; the assessment does not need access to patient charts.
- ePHI inventory, data-flow map, and a BAA gap list.
- MFA enforced on every account that can reach PHI, and external mail forwarding blocked.
- Backup coverage checked against the inventory and one restore performed and recorded.
- A prioritized fix list, each item tied to the Security Rule section it addresses.
After month one
- Monthly patching and configuration review across cloud accounts, the productivity suite, and endpoints.
- Quarterly access reviews with removed users and stale privileges documented.
- BAA register kept current as vendors are added or dropped.
- Restore tests and contingency-plan updates on an agreed schedule.
- Risk analysis refreshed annually, or sooner after a major system change.
- Evidence packages assembled for payer, partner, or OCR requests.
The HIPAA provisions behind the work
Security Rule administrative safeguards — 45 CFR 164.308
Requires a risk analysis and risk management process, a designated security official, workforce training, and a contingency plan. These are processes and documents, but most of their evidence comes from how the cloud is configured.
eCFR: 45 CFR Part 164, Subpart C (HIPAA Security Rule)Security Rule technical safeguards — 45 CFR 164.312
Access control, audit controls, integrity, person or entity authentication, and transmission security. Encryption and automatic logoff are 'addressable': you implement them or document why an equivalent measure is reasonable.
HHS: Summary of the HIPAA Security RuleBusiness associate agreements — 45 CFR 164.502(e), 164.504(e), 164.314(a)
A covered entity or business associate needs a BAA before a vendor creates, receives, maintains, or transmits PHI for it. HHS confirms this includes cloud providers that store only encrypted data without the key.
HHS: Guidance on HIPAA & Cloud ComputingBreach Notification Rule — 45 CFR 164.400–414
Affected individuals are notified without unreasonable delay and within 60 days of discovery. Breaches of 500 or more people also go to HHS, and to the media where more than 500 residents of one state are affected.
HHS: Breach Notification RuleProposed Security Rule update (January 2025)
HHS proposed making encryption and MFA mandatory and adding asset inventories and regular compliance audits. It is a proposal, not a final rule; we build toward it because the controls are sound either way.
Pricing for practices and health-tech teams
Most practices and smaller health-tech teams fit the Essential retainer ($3,500–$7,500 per month). Multi-site groups, or products with production workloads in AWS, Azure, or Google Cloud, usually land in Professional ($8,000–$15,000 per month). Without a current risk analysis, the fixed-price HIPAA Risk Analysis Sprint is the usual starting point, and its output becomes the baseline the managed service maintains.
Questions about HIPAA and the cloud
Will PlatOps sign a BAA for managed cloud work?
Yes. Managing systems that hold ePHI makes us your business associate, so the BAA is signed before we receive any access. If you are yourself a business associate, ours is a subcontractor agreement under your BAAs with customers.
Is Microsoft 365 or Google Workspace HIPAA compliant?
Neither is compliant on its own. Microsoft and Google sign BAAs for covered services, but default settings still allow things like automatic forwarding and unencrypted external mail. Compliance depends on the BAA plus how the tenant is configured, which is the part we manage.
Our EHR is cloud-hosted. Isn't the vendor responsible?
For its own hosting, yes, under its BAA with you. It is not responsible for your staff accounts, the devices they use, files exported from the EHR, or the email and storage around it. Those remain your obligations under the Security Rule, and they are where many small-practice incidents start.
Which AWS, Azure, or Google Cloud services can hold PHI?
Only the services each provider lists as covered by its BAA; AWS, for example, publishes a HIPAA Eligible Services Reference. We check every service in the PHI path against the current list, because the lists change and a new feature built on an uncovered service creates a gap.
Do we need encryption if the rule calls it 'addressable'?
In practice, yes. Addressable means implement it or document an equally effective alternative, and there are few alternatives for laptops and cloud storage. ePHI encrypted to the HHS standard is also not 'unsecured PHI', which can keep a lost device from becoming a reportable breach.
What happens if there is an incident?
We contain it, preserve logs, and work with your counsel and privacy officer on the breach risk assessment. The notification decision and letters stay with you. The 60-day clock starts at discovery, so the logging we set up beforehand is what makes the decision answerable on time.
Get a HIPAA cloud review
We will look at where ePHI lives across your cloud tenants, backups, and devices, and tell you which gaps matter first. If a fixed-price risk analysis is the better start, we will say so.