Cloud ePHI Security: A Step-by-Step Setup Guide

The Shared Responsibility Model is no longer just a concept. When you sign a BAA with AWS, Azure, or Google Cloud, you're entering a contract that divides compliance duties. Your provider secures the infrastructure; you secure everything you put on it. If you neglect your responsibilities, you're liable for any breaches.

Recent HHS guidance clarifies this division, and OCR audits now focus on the gap between what covered entities assume their cloud provider handles and what the BAA actually specifies. If you're storing ePHI in the cloud without implementing the necessary technical controls, you're at risk.

This guide walks you through the essential setup steps to close that gap.

What You Need Before Starting

Legal foundation:

• A signed BAA for every cloud service handling ePHI, including service-specific agreements for S3 buckets, databases, and compute instances.
• Written approval for any subcontractors your cloud provider uses.
• Updated BAA language covering Part 2 redisclosure restrictions if you handle substance use disorder records.

Technical access:

• Administrative credentials for your cloud console.
• Authority to configure IAM policies, encryption settings, and logging.
• A centralized log storage solution (cloud-native like AWS CloudTrail or a third-party SIEM).

Documentation:

• Your organization's current risk assessment.
• A list of who needs access to what ePHI, organized by role.
• Your contingency plan template (you'll be updating the recovery procedures).

Step-by-Step Implementation

1. Lock Down Encryption First

Start with encryption because unencrypted ePHI at rest violates the Security Rule.

For data at rest:

• Navigate to your storage service settings (S3, Azure Blob, Cloud Storage).
• Enable AES-256 encryption on every bucket or container holding ePHI.
• Set encryption as the default for new resources to prevent gaps.
• Document which encryption keys you manage versus those managed by the provider.

For data in transit:

• Enforce TLS 1.2 or higher on all endpoints.
• Disable legacy protocols (SSL, TLS 1.0, TLS 1.1) at the load balancer and application layer.
• Test your configuration with openssl s_client -connect yourdomain.com:443 -tls1_2 to confirm the handshake succeeds and lower versions fail.

2. Implement Identity-Based Microsegmentation

VLANs aren't enough. Prevent lateral movement if a workstation is compromised.

Set up network policies:

• Use your cloud provider's native tools (AWS Security Groups, Azure Network Security Groups, Google Cloud Firewall Rules).
• Create a policy for each workload specifying which services it can communicate with.
• Default-deny everything else.
• Example: Your billing application can reach the billing database on port 3306, but nothing else.

Apply identity controls:

• Tag every resource with its function and data classification.
• Write firewall rules that reference those tags, not IP ranges.
• When you add a new server, the tag determines its access automatically.

3. Mandate MFA Across the Board

MFA is now mandatory.

Enable at the root:

• Turn on MFA for your cloud account's root user.
• Use a hardware token or authenticator app, not SMS.
• Store backup codes securely offline.

Enforce for all users:

• Set an IAM policy denying console access without MFA.
• Apply the same rule to API access for administrative actions.
• Give users 48 hours to enroll, then lock out non-compliant accounts.

4. Build Role-Based Access Controls

Every user should have the minimum access their job requires.

Create roles, not individual permissions:

• Define roles like "Billing Specialist," "Clinical Data Analyst," "Security Administrator."
• Map each role to specific ePHI resources.
• Assign users to roles, not directly to resources.

Automate lifecycle management:

• Connect your IAM system to your HR system if possible.
• When someone leaves or changes departments, their access updates automatically.
• If automation isn't feasible, set a calendar reminder to review access quarterly and document the review.

5. Configure Centralized Logging

You can't investigate what you didn't log.

Turn on audit trails:

• Enable AWS CloudTrail, Azure Monitor, or Cloud Logging.
• Capture API calls, console sign-ins, and data access events.
• Ship logs to a tamper-resistant bucket with versioning and object lock enabled.

Set up alerts:

• Flag console logins from unfamiliar IP addresses.
• Alert on access attempts outside business hours.
• Notify when someone disables logging or encryption.

Establish a review cadence:

• Daily: automated alerts.
• Weekly: manual review of high-risk access (remote connections, administrative actions).
• Monthly: broader anomaly review.
• Document every review with date, reviewer name, and findings.

6. Implement the 3-2-1 Backup Rule

Cloud storage isn't immune to deletion, corruption, or regional outages.

Set up redundancy:

• Three copies of your ePHI (production + two backups).
• Two different storage types (e.g., live database + snapshot + archive).
• One copy in a different region or cloud provider.

Test restoration:

• Schedule a quarterly drill where you restore a subset of data.
• Measure how long it takes.
• Adjust your procedures until you can hit a 72-hour recovery window for critical systems.

Validation: How to Verify It Works

Run these checks within 30 days of implementation:

Encryption test:

• Attempt to create an unencrypted resource.
• It should fail or trigger an alert.

MFA enforcement:

• Try logging in with just a password.
• Access should be denied.

Microsegmentation proof:

• From a billing workstation, attempt to reach a clinical database.
• The connection should time out or be explicitly blocked.

Logging verification:

• Perform a test action (like accessing a patient record).
• Confirm the event appears in your centralized logs within 15 minutes.
• Verify the log includes timestamp, user identity, and resource accessed.

Backup restore:

• Select a non-production dataset.
• Delete it, then restore from backup.
• Time the process.

Maintenance and Ongoing Tasks

Monthly:

• Review access logs for anomalies.
• Check for new cloud services your teams have spun up and confirm they're covered by your BAA.
• Run a vulnerability scan (required at least biannually, but monthly is better).

Quarterly:

• Test your disaster recovery procedure.
• Review and update IAM roles as job functions change.
• Audit who has MFA enrolled.

Annually:

• Conduct a full risk assessment that includes your cloud environment.
• Update your contingency plan with lessons learned from your recovery drills.
• Retrain staff on their responsibilities under the Shared Responsibility Model.

When staff changes occur:

• Deprovision access within 24 hours of termination.
• Review the departed user's activity logs for the prior 90 days.
• Update role assignments when someone changes departments.

The Shared Responsibility Model puts half the compliance burden on you. Follow these steps to fulfill your part. If you skip them, the BAA won't protect you when OCR audits your cloud environment.