The breach at Aesto Health wasn't just a cloud issue. It was a single AWS compromise that affected over two dozen healthcare providers, exposing data for more than 9.5 million patients. When you outsource EHR migration, archiving, or data exchange to a Business Associate, you're trusting their infrastructure as if it were your own. If their AWS environment is breached, your patients' Social Security numbers, financial account numbers, and medical records are at risk.
The delay between Aesto Health's detection on December 18, 2025, and final confirmation on May 26, 2026, highlights another issue: lengthy investigation timelines. Some providers had to handle their own patient notifications, creating confusion about responsibilities and timing.
You need a repeatable process to audit Business Associate security before signing a contract and on a recurring basis. This playbook guides you through that process.
What You Need Before Starting
Access and Authority:
- Signed Business Associate Agreement (BAA) with audit rights explicitly stated in § 164.314(a)(2)(i) language
- Internal stakeholder alignment: your HIPAA Compliance Officer, Privacy Official, IT security lead, and procurement lead should all review findings
- Budget authority to walk away if the vendor can't demonstrate adequate safeguards
Documentation to Request from the Vendor:
- Current HITRUST CSF certification (r2 or i1 validated assessment preferred) or SOC 2 Type II report
- Most recent HIPAA Security Rule risk analysis, dated within the past 12 months
- Incident response plan and breach notification procedure
- Cloud infrastructure diagram showing where PHI resides and how it's segmented
- Access control matrix: who can access PHI, what roles exist, how privileges are granted and revoked
- Encryption specifications: at-rest (AES-256 or equivalent) and in-transit (TLS 1.2 minimum)
- Business continuity and disaster recovery runbooks with tested restore times
Your Audit Checklist Template: Create a spreadsheet with columns for Security Rule requirement (cite by § number), vendor evidence type, date reviewed, pass/fail, and remediation deadline. You'll populate this as you work through the steps below.
Step-by-Step Implementation
1. Verify Third-Party Attestations
Don't take a HITRUST certificate or SOC 2 report at face value. Log into the HITRUST MyCSF portal to confirm the vendor's organization name, certification tier, and expiration date. For SOC 2, request the full report, not just the summary letter. Read Section II for the auditor's testing procedures and exceptions. Flag any repeated exceptions around access reviews or change management.
2. Map Their Infrastructure to Your Data Flows
Ask the vendor to diagram exactly where your PHI will live. If they're using AWS, you need to see:
- Which AWS regions host your data
- Whether they use dedicated Virtual Private Clouds (VPCs) or shared tenancy
- How they segment client data (separate S3 buckets per client, separate accounts, database-level isolation)
- What IAM roles and policies govern access to those resources
Run this test: ask them to show you the IAM policy JSON for a role that touches PHI. If they can't produce it or if the policy includes wildcard actions (s3:* on Resource: "*"), that's a red flag.
3. Audit Encryption and Key Management
Request evidence of encryption at rest and in transit. For AWS environments, confirm they're using:
- S3 bucket encryption with AWS KMS or customer-managed keys (not just SSE-S3)
- RDS encryption enabled on all database instances
- EBS volume encryption for any EC2 instances processing PHI
- TLS 1.2 or 1.3 enforced on all API endpoints and data transfer channels
Ask who controls the encryption keys. If the vendor uses AWS-managed keys, verify they have a key rotation policy. If they use customer-managed KMS keys, confirm they maintain an audit trail of key usage in CloudTrail.
4. Test Access Controls and Logging
Request a walkthrough of their access provisioning process. Specifically:
- How does a new employee get access to production systems?
- What approval workflow exists?
- How frequently do they review active accounts (§ 164.308(a)(3)(ii)(C) requires periodic review)?
- Do they enforce multi-factor authentication on all privileged accounts?
Then verify logging. Ask for a sample CloudTrail log export showing API calls to S3 buckets or RDS instances that store PHI. Confirm logs capture:
- Who accessed what resource
- When (with timestamps in UTC)
- From which IP address or role
- Whether the action succeeded or failed
If they can't produce this within 24 hours, their logging isn't production-ready.
5. Validate Incident Response and Breach Notification
Walk through their incident response plan with specific questions:
- Who is the first responder if they detect unauthorized access?
- What's the escalation path to their HIPAA Compliance Officer?
- How do they determine whether data was exfiltrated (not just accessed)?
- At what point do they notify you as the Covered Entity?
Reference the Aesto Health timeline: detection on December 18, confirmation of exfiltration on May 26. Ask the vendor how they would compress that investigation window and what forensic tools they use.
Confirm their BAA specifies notification timelines. HIPAA's Breach Notification Rule requires Covered Entities to notify individuals within 60 days of discovery, but your BAA should require the Business Associate to notify you within 24-48 hours of detecting a potential breach so you have time to investigate and meet your own deadline.
6. Review Subcontractor Management
If the vendor uses subcontractors (cloud providers, backup services, analytics platforms), request:
- A current list of all subcontractors with access to PHI
- Signed BAAs with each subcontractor
- Evidence that subcontractors meet the same security standards
For AWS specifically, confirm the vendor understands the Shared Responsibility Model: AWS secures the infrastructure, but the vendor must secure everything they build on top of it (IAM policies, encryption, logging, patching).
Validation: How to Verify It Works
After completing your audit, schedule a tabletop exercise with the vendor. Present a scenario: "Your AWS environment shows unauthorized API calls to an S3 bucket containing archived EHR data. Walk me through your response in the first four hours."
Score their response on:
- Speed of detection (do they have automated alerting?)
- Containment steps (can they isolate the affected bucket without disrupting other clients?)
- Evidence preservation (do they snapshot volumes and preserve logs before remediation?)
- Communication cadence (when do they call you, and what information do they provide?)
If they can't articulate a clear response or if they say "we'd call AWS support first," that's a gap.
Request a sample breach notification letter they would send to affected individuals. Verify it includes all elements required by § 164.404(c): description of the breach, types of information involved, steps individuals should take, what the vendor is doing to investigate and prevent recurrence, and contact information.
Maintenance and Ongoing Tasks
Quarterly:
- Review access logs for anomalies (unusual access times, unfamiliar IP addresses, bulk data exports)
- Confirm the vendor has completed quarterly access reviews and disabled terminated employee accounts
Annually:
- Re-verify HITRUST CSF or SOC 2 certification (check for lapses or downgrades)
- Request an updated risk analysis and compare it to the prior year's version
- Conduct a follow-up tabletop exercise with a different breach scenario
After Any Vendor Infrastructure Change:
- If they migrate to a new AWS region, add a cloud provider, or launch a new service that touches your PHI, require a change notification and security assessment before you authorize the change
Track Vendor Breaches Industry-Wide: Monitor the HHS breach portal for your vendor's name. If they appear, immediately invoke your audit rights under the BAA and request a full incident report, even if your data wasn't affected. A breach at another client signals systemic risk.
The Aesto Health breach affected multiple provider clients because they all relied on the same compromised infrastructure. Your audit process should ensure that if your Business Associate ends up on the breach portal, you already know their security posture well enough to explain to your patients exactly what happened and why you trusted them in the first place.
