When CareCloud's AWS environment was breached between March 10 and March 16, 2026, the attacker had six days to explore databases containing names, Social Security numbers, financial account numbers, and protected health information for over 345,000 patients. The breach wasn't detected until network disruption occurred on March 16. By then, the damage was done.
If you're running healthcare applications in AWS, Azure, or Google Cloud, this checklist will help you close the gaps that allowed this breach to happen. Each item includes what auditors and regulators expect to see, tied to HIPAA Security Rule requirements where applicable.
What This Checklist Covers
This is your pre-breach security posture verification for healthcare cloud environments. It addresses the specific controls that would have prevented or detected the CareCloud incident: access monitoring, data encryption, network segmentation, and incident response readiness. You'll need your cloud security architect, HIPAA Security Officer, and a representative from your business associate agreements team to complete this properly.
Prerequisites
Before you start, gather:
- Your current AWS/Azure/GCP account inventory and IAM policy documentation
- Business Associate Agreements with your cloud provider (required under HIPAA)
- Your most recent vulnerability scan and penetration test results
- CloudTrail, GuardDuty, or equivalent logging configurations
- Your incident response plan and the date it was last tested
You'll also need administrative access to your cloud console and your SIEM or log aggregation platform.
Checklist Items
1. Multi-Factor Authentication enforced on all privileged accounts
Check that every account with administrative access to your cloud environment requires MFA. This includes service accounts used by automation tools. HIPAA Security Rule § 164.312(a)(2)(i) requires unique user identification, and MFA is the implementation specification for access control.
Good looks like: Zero accounts with console or API access that can authenticate with password alone. Your IAM audit should show MFA devices registered for 100% of human users and certificate-based authentication for service accounts.
2. CloudTrail or equivalent logging enabled across all regions
Verify that you're capturing API calls, console sign-ins, and resource changes in every region where you have resources deployed. The CareCloud breach involved unauthorized access over multiple days. Without comprehensive logging, you can't reconstruct what happened.
Good looks like: CloudTrail logs flowing to an S3 bucket with versioning and MFA delete enabled, with log file validation turned on. Logs should be sent to a separate AWS account that the application team cannot access. Retention must meet your state breach notification law requirements (typically 6 years minimum for HIPAA-covered entities).
3. Real-time alerting configured for high-risk activities
Set up alerts for: new IAM user creation, changes to security groups, S3 bucket policy modifications, CloudTrail logging disabled, root account usage, and failed authentication attempts exceeding your threshold.
Good looks like: Alerts route to your Security Operations Center or on-call security team within 5 minutes of the triggering event. Your incident response plan documents who receives these alerts and their expected response time. Test by triggering a simulated high-risk event quarterly.
4. Database encryption at rest using customer-managed keys
Confirm that your RDS instances, DynamoDB tables, and S3 buckets containing protected health information use encryption with keys you control through AWS KMS, not AWS-managed keys. HIPAA Security Rule § 164.312(a)(2)(iv) requires encryption as an addressable implementation specification, which becomes mandatory when you conduct your risk assessment.
Good looks like: Your KMS key policies restrict key usage to specific IAM roles, with key rotation enabled. You maintain documentation showing which databases contain ePHI and their corresponding encryption keys. Encryption status appears in your configuration management database.
5. Network segmentation isolating ePHI databases
Verify that databases containing protected health information sit in private subnets with no direct internet access. Security groups should implement default-deny rules, allowing only specific application servers to connect on required ports.
Good looks like: Your network diagram shows ePHI databases in private subnets behind application load balancers. Security group rules reference specific security groups as sources, not IP ranges. You can demonstrate that a compromised web server cannot directly access your patient database.
6. Privileged Access Management with session recording
Check that you're using AWS Systems Manager Session Manager, Azure Bastion, or a third-party PAM solution that records privileged sessions. When the breach investigation starts, you need to know exactly what the attacker did.
Good looks like: No SSH keys stored on developer laptops. All privileged access goes through a jump host or bastion that logs every command. Sessions terminate after 30 minutes of inactivity. You can produce a complete audit trail of who accessed which systems and when.
7. Vulnerability scanning running weekly
Confirm that you're scanning EC2 instances, container images, and serverless functions for known vulnerabilities. The HIPAA Security Rule § 164.308(a)(8) requires regular evaluation of security measures.
Good looks like: Automated scanning integrated into your CI/CD pipeline that blocks deployments containing critical vulnerabilities. Scan results feed into your vulnerability management program with defined SLAs for remediation (critical: 7 days, high: 30 days). Your most recent scan report shows zero critical findings older than your SLA.
8. Third-party cybersecurity experts identified and contracted
CareCloud engaged external experts after the breach was detected. You need that relationship established before the breach happens. Identify forensics firms that specialize in healthcare breaches and have them under a retainer or pre-negotiated contract.
Good looks like: A signed retainer agreement or master services agreement with a digital forensics firm that includes guaranteed response times. Your incident response plan lists their 24/7 contact number. You've conducted a tabletop exercise with them in the past 12 months.
9. Data classification completed and documented
Know which S3 buckets, databases, and file shares contain ePHI versus de-identified data versus non-health information. You can't protect what you haven't inventoried.
Good looks like: Every data store has a classification tag (ePHI, PII, public, internal). Your data flow diagrams show how ePHI moves between systems. You can produce this documentation in response to a regulator's request within 24 hours.
10. Incident response plan tested in the past 6 months
Your plan should cover detection, containment, eradication, recovery, and the HIPAA Breach Notification Rule's 60-day notification requirement. HIPAA Security Rule § 164.308(a)(6) requires an incident response and reporting procedure.
Good looks like: Tabletop exercise documentation showing you walked through a cloud breach scenario. Participants included your HIPAA Security Officer, legal counsel, public relations, and your cloud security team. You identified gaps and updated the plan afterward.
Common Mistakes
Assuming AWS is responsible for HIPAA compliance. AWS provides HIPAA-eligible services, but you're responsible for configuring them securely. The shared responsibility model means AWS secures the infrastructure; you secure what you put on it.
Treating CloudTrail logs as optional. After the CareCloud breach, investigators needed to determine what data was accessed between March 10 and March 16. Without logs, that's impossible. Logs aren't just for compliance checkboxes; they're your breach investigation starting point.
Skipping encryption because "it's complicated." Enabling encryption at rest in AWS RDS takes three clicks and adds no performance overhead for most workloads. The complexity argument doesn't hold up when you're explaining a breach to the Office for Civil Rights.
Not testing your incident response plan. CareCloud notified the SEC on March 30, began detailed data review, and confirmed data types on June 24. That's three months to determine what was compromised. Tabletop exercises reveal these bottlenecks before they matter.
Next Steps
Work through this checklist with your cloud security architect within the next 30 days. For any item you can't check off, document the gap, assign an owner, and set a remediation deadline. Your HIPAA Security Rule risk analysis under § 164.308(a)(1)(ii)(A) should reference these findings.
If you're more than 60 days away from checking every box, consider bringing in a healthcare cloud security consultant to accelerate remediation. The cost of that engagement is a fraction of what CareCloud will spend on breach notification, credit monitoring for 345,000 individuals, legal fees, and potential Office for Civil Rights penalties.
The attacker who breached CareCloud had six days of access before detection. Your goal is to reduce that window to six hours, then six minutes. This checklist gets you there.
