When a business associate's cloud intrusion exposes 3.7 million patient records, as CareCloud's six-day AWS breach did from March 10 to March 16, 2026, covered entities find themselves responsible for breach analysis and notification even if they never touched the compromised infrastructure. If you're a business associate running healthcare workloads in AWS, your security posture directly impacts whether your clients face OCR investigations, notification costs, and reputational damage. This guide walks you through hardening your AWS environment to prevent unauthorized access and meet the shared responsibility model's customer-side obligations under the HIPAA Security Rule.
The Problem: Why This Matters Now
CareCloud identified affected Protected Health Information on June 24, roughly 100 days after discovering the breach. That delay, spent reviewing database contents and matching records to individuals, shows how intrusion containment and impact assessment operate on different timelines. Your clients' 60-day notification clock starts when you report the breach to them, meaning every day you spend determining scope is a day they can't begin their own compliance work.
Revenue cycle and practice management vendors concentrate records from hundreds of practices into single environments, making them high-value targets. When you hold data for multiple covered entities, a single configuration error or compromised credential can trigger notification obligations across your entire client base simultaneously.
What You Need Before Starting
Access inventory:
- Complete list of IAM users, roles, and service accounts with current permissions
- Documentation of which personnel require console access versus programmatic access
- Inventory of third-party integrations using AWS credentials
Architecture documentation:
- Network diagrams showing VPC boundaries, subnets, and security group rules
- Data flow maps indicating where ePHI enters, processes, and exits your environment
- List of S3 buckets, RDS instances, and other storage resources containing ePHI
Baseline configurations:
- Current CloudTrail settings and log retention policies
- Existing encryption status for data at rest and in transit
- Active GuardDuty findings and Config compliance reports
Business associate agreements:
- Notification timelines you've committed to (the standard 60-day maximum or shorter)
- Breach reporting procedures specifying what triggers immediate client notification
- Security audit rights your clients can exercise
Step-by-Step Implementation
1. Enforce Multi-Factor Authentication on All Human Access
In the IAM console, create a policy denying all actions except MFA management until MFA is enabled:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllExceptMFA",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ListUsers",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"sts:GetSessionToken"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
Attach this policy to all IAM users. Configure your identity provider to require hardware tokens or authenticator apps. SMS-based MFA doesn't meet HITRUST CSF control requirements for privileged access.
2. Segment Client Data with Separate AWS Accounts
Use AWS Organizations to create dedicated accounts for each covered entity client or client tier. This architectural separation limits blast radius: a credential compromise in one account can't reach another client's ePHI. Set up a central logging account that aggregates CloudTrail and Config data from all member accounts.
In the management account, enable service control policies (SCPs) that prevent member accounts from disabling CloudTrail, modifying GuardDuty detectors, or changing encryption settings without approval workflows.
3. Enable Encryption with Customer-Managed Keys
Create a KMS customer master key (CMK) for each account handling ePHI. In the KMS console, configure key policies that restrict decrypt operations to specific IAM roles tied to application workloads:
{
"Sid": "Allow decrypt only for application role",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ACCOUNT-ID:role/ehr-application-role"
},
"Action": "kms:Decrypt",
"Resource": "*"
}
Enable encryption at rest for all RDS instances, S3 buckets, and EBS volumes. For S3, set bucket policies requiring encryption headers on all PUT requests. The HIPAA Security Rule's encryption Addressable Specification becomes effectively required when you're storing ePHI for multiple clients. Document why you chose this implementation in your risk analysis.
4. Lock Down Network Access with Security Groups and NACLs
Default-deny all inbound traffic at the network ACL level. Use security groups to whitelist only the specific ports and protocols your applications require. For database instances holding ePHI:
- Restrict RDS security groups to application tier security groups only
- Never allow 0.0.0.0/0 on database ports
- Disable public accessibility on all RDS instances
- Use VPC endpoints for AWS service access instead of internet gateways where possible
Document these network boundaries in your system security plan. They're evidence for HITRUST CSF control 01.m (Network Segregation).
5. Configure Real-Time Alerting on High-Risk Actions
In CloudWatch, create metric filters on your CloudTrail logs for actions that indicate potential compromise:
- Root account usage
- IAM policy changes
- Security group modifications allowing 0.0.0.0/0
- KMS key deletion or disablement
- CloudTrail logging changes
- MFA device deactivation
Route these alarms to an SNS topic that pages your security team immediately. The CareCloud breach involved unauthorized access over six days. Real-time detection cuts that window to hours.
Set up GuardDuty in all accounts and integrate findings with your SIEM or incident response platform. Configure automatic responses for high-severity findings: Lambda functions that isolate compromised instances or revoke suspicious IAM credentials.
6. Implement Session Recording for Administrative Access
Use AWS Systems Manager Session Manager instead of SSH for EC2 instance access. Enable session logging to S3 with encryption and configure CloudWatch Logs integration. This creates an audit trail showing exactly what commands administrators ran, when, and on which instances. This is critical for post-incident forensics and demonstrating access controls to clients exercising audit rights under your business associate agreement.
Validation: How to Verify It Works
Test MFA enforcement: Create a test IAM user without MFA and attempt console login. It should fail with a policy denial.
Verify encryption: Use the AWS CLI to check encryption status across resources:
aws rds describe-db-instances --query 'DBInstances[*].[DBInstanceIdentifier,StorageEncrypted]'
aws s3api get-bucket-encryption --bucket your-bucket-name
Every result should show encryption enabled with your KMS CMK.
Validate network isolation: From an external IP, attempt to connect to your RDS endpoint on port 3306 or 5432. The connection should time out, not refuse.
Check alerting: Manually trigger a test alarm by modifying a security group to allow 0.0.0.0/0. Your security team should receive a page within five minutes.
Review access logs: Pull a CloudTrail report for the past 30 days and filter for root account activity. There should be zero events unless you've documented a specific break-glass scenario.
Maintenance and Ongoing Tasks
Weekly: Review GuardDuty findings and Config compliance reports. Remediate any resources flagged as non-compliant with your encryption or network policies.
Monthly: Audit IAM users and roles. Remove credentials that haven't been used in 90 days. Rotate access keys for programmatic accounts. Review security group rules for any that allow broader access than current application architecture requires.
Quarterly: Run AWS Trusted Advisor checks and address all security-related recommendations. Test your incident response runbook with a tabletop exercise that simulates unauthorized access discovery. Practice the notification timeline you've committed to in your business associate agreements.
Annually: Engage a third-party assessor to validate your control implementation against HITRUST CSF or conduct a penetration test scoped to your AWS environment. Share the results with clients who've requested evidence of your security practices.
When your clients ask how quickly you'll notify them after discovery, your answer depends on how fast you can determine scope, which depends on how well you've instrumented your environment before the breach happens. The controls above give you the visibility and containment capability to meet 60-day obligations with margin to spare.
