8 Essential Practices for Healthcare Cloud Data

PHI in the cloud is not hard to protect if you do the specific things that matter and skip the things that don't. Most healthcare cloud security programs are weak not because they're missing sophisticated controls, but because they're missing basic ones — unrotated service accounts, over-permissive IAM, backup targets that share credentials with production. Here are eight practices that matter, prioritized by leverage.

1. Classify Data Before You Protect It

Not every byte in a healthcare environment is PHI. Lab results are. Appointment reminders might be (they contain enough identifiers). Aggregate reporting is probably not, if it's properly de-identified. Marketing lists might be, depending on source.

What to do:

• Tag every data store with its classification (public, internal, PHI, PHI-sensitive)
• Enforce different controls per classification automatically
• Review classifications quarterly — data scope creeps
• De-identify where you can. De-identified data outside the scope of HIPAA is dramatically cheaper and simpler to handle.

The HHS Safe Harbor method for de-identification is specific and well-defined. Use it where possible.

2. Customer-Managed Keys for PHI Data Stores

Default cloud encryption uses vendor-managed keys. That's fine for most workloads and not fine for PHI. Customer-Managed Keys (CMK) give you revocation control — if something goes wrong, you can pull the key and the data becomes unreadable.

How we set it up:

• Azure Key Vault Premium or AWS CloudHSM for FIPS 140-2 Level 3 validation
• Keys in a separate subscription/account from the data they protect
• Automatic key rotation enabled
• Access to the key vault audited separately from access to the data
• Break-glass procedure documented for key recovery

For behavioral health data, substance abuse records (42 CFR Part 2), and genomics, consider Hold Your Own Key (HYOK) where the key material never leaves your HSM.

3. Role-Based Access With Break-Glass Procedures

Clinical staff need access to records. Administrative staff need different access. Billing needs different access again. Research needs de-identified access. IT needs just enough access to operate the systems without seeing the clinical data itself.

RBAC principles that work:

• Roles aligned to job function, not organizational structure
• Access reviewed quarterly
• Emergency access (break-glass) available but heavily monitored
• Separation of duties — the person who grants access can't approve their own access changes

Break-glass specifically: Clinical emergencies sometimes require access that normal RBAC denies. Build an explicit break-glass procedure that lets authorized personnel access records they don't normally see, with mandatory justification, automatic alerts to security, and retrospective review.

4. Audit Logs That Capture the "Who Accessed What" Question

HIPAA's audit control requirement is vague. The practical test: can you answer "who accessed patient John Smith's records last Tuesday" within a few minutes? If not, your audit logs are insufficient.

What we enable:

• Application-level audit logging (EHR audit log, database audit log)
• Cloud-level audit logging (CloudTrail, Activity Log, Cloud Audit Logs)
• Immutable storage for audit data with at least 6 years of retention
• SIEM integration for active monitoring

Row-level database audit is particularly important. Table-level or API-level logs don't answer the question. pgAudit for PostgreSQL, SQL Server Audit, and native audit for Oracle and MySQL all support it.

5. Network Segmentation for PHI Workloads

PHI workloads should not share a network segment with general-purpose workloads. The blast radius of a compromise in another part of the environment should be limited.

Practical implementation:

• Dedicated VNets or VPCs for PHI workloads
• No direct peering to general-purpose networks without explicit firewall rules
• Private endpoints for all PaaS services (no public IPs for databases, storage)
• Egress filtering to prevent data exfiltration
• Network flow logs for forensics

6. BAA Hygiene

A Business Associate Agreement is required with every vendor touching PHI. Keeping the BAA inventory current is harder than it sounds.

What to track:

• List of every service with a BAA, updated quarterly
• Which services on each vendor's covered list you actually use
• New services evaluated before deployment (does a BAA exist? is it signed?)
• Sub-processor lists from each BA, reviewed annually

Common failure: A developer enables a new cloud service to try something out. The service isn't on the BAA covered list. A month later, a QA environment has PHI running through it. This is a reportable breach. Policy enforcement (Azure Policy, AWS Service Control Policies) that denies deployment of services outside the covered list prevents it.

7. Backups Separated From Production Credentials

If the credentials that operate your production environment can also delete your backups, you do not have backups. Ransomware attackers will use the production credentials to wipe the backups first.

Architecture:

• Backup targets in a separate cloud account or subscription
• Immutable object storage (S3 Object Lock in Compliance mode, Azure Blob immutable tier)
• Backup service accounts that cannot delete completed backups
• Cross-region or cross-cloud backup copies for geographic separation
• Monthly restore tests with documented results

This is the single highest-leverage control against ransomware. Healthcare has been a primary ransomware target for years. Budget accordingly.

8. Data Exfiltration Detection

Bulk data export is a signal. Legitimate users rarely download thousands of records in a single session. Detecting and alerting on bulk operations catches insider threats and compromised accounts early.

What to alert on:

• Queries returning unusually large result sets
• Bulk exports from EHR systems
• Unusual access patterns (off-hours, geographic anomalies, new devices)
• Database dumps or mass file downloads
• Cloud storage downloads above normal volumes

Microsoft Purview, AWS Macie, and Google Cloud DLP can identify PHI in data stores and flag bulk movement. Custom detection in your SIEM can cover the application-specific patterns.

What We'd Actually Do

For a healthcare organization with existing cloud deployment but weak PHI protection:

1. Week 1: Inventory everything touching PHI. Tag it. Confirm BAAs exist.
2. Week 2: Enable CMK on every data store holding PHI. Move keys to a separate key vault.
3. Week 3: Enable row-level audit logging on databases. Ship to immutable storage.
4. Week 4: Migrate backup target to a separate cloud account with immutable storage.
5. Month 2: Implement data exfiltration alerts in SIEM.
6. Month 3: Tabletop exercise with the privacy officer, security team, and executive.
7. Ongoing: Quarterly access reviews, monthly restore tests, annual external penetration test.

Three Takeaways

1. Customer-managed keys in a separate vault are the single biggest PHI protection upgrade most organizations can make. Budget a week for implementation.
2. Immutable backups with separated credentials are non-negotiable for healthcare. Ransomware is the single biggest HIPAA risk in 2025.
3. Row-level audit is what auditors actually care about. Cloud API logs don't answer the questions HIPAA asks.