On December 18, 2025, Aesto Health discovered unauthorized access to its AWS infrastructure. By the time the Birmingham-based healthcare technology company completed its investigation and notified affected clients in June 2026, the damage was clear: 9,540,683 patient records were exposed across at least 30 healthcare provider clients.
This wasn't a ransomware attack or a phishing campaign. An unauthorized party gained access to Aesto's cloud environment and remained there for 16 days, extracting Protected Health Information (PHI) that included Social Security numbers, financial account numbers, medical histories, and health insurance details.
For privacy officers working with Business Associates handling data migration, EHR exchanges, or legacy archiving, this breach offers a stark lesson: your vendor's cloud security posture is your security posture.
What Happened
Aesto Health provides data migration, legacy archiving, and EHR exchange services to medical practices and healthcare enterprises. Between December 2 and December 18, 2025, an unauthorized third party accessed portions of the company's AWS infrastructure containing patient data.
The compromised environment held Individually Identifiable Health Information for millions of patients across Aesto's client base, including names, Social Security numbers, partial dates of birth, driver's license numbers, financial account information, and complete medical records with claims and billing data.
Aesto engaged third-party cybersecurity experts to investigate. The company notified affected Covered Entities starting June 26, 2026, more than six months after discovering the breach.
Timeline
- December 2, 2025: Unauthorized access to AWS environment begins
- December 18, 2025: Aesto identifies the security incident
- December 18, 2025, June 2026: Investigation and forensic analysis period
- June 26, 2026: Client notification begins
- August 2026: Breach reported to Office for Civil Rights (OCR) as affecting 9,540,683 individuals
The six-month gap between discovery and notification raises questions about investigation complexity and the coordination required when a single Business Associate breach affects dozens of Covered Entities.
Which Controls Failed
The breach notice states Aesto "had taken many precautions to safeguard the sensitive data" and "continually evaluates and modifies its security practices," but the incident reveals specific control failures:
Access controls on the AWS environment were insufficient. An unauthorized party gained entry and maintained access for 16 days without detection. This suggests failures in authentication mechanisms or network segmentation.
Detection capabilities didn't catch the intrusion in real time. Sixteen days of unauthorized access indicates gaps in logging, monitoring, or alerting on the AWS infrastructure hosting PHI.
Data at rest wasn't adequately protected. Once inside the environment, the unauthorized party could access PHI in a readable format, suggesting encryption controls were either absent or ineffective.
What the Standards Require
The HIPAA Security Rule's Technical Safeguards directly address these failures:
§ 164.312(a)(1) Access Control (Required): Covered Entities and Business Associates must implement technical policies and procedures that allow only authorized persons to access Electronic Protected Health Information (ePHI). This includes unique user identification (Required), emergency access procedures (Required), automatic logoff (Addressable), and encryption and decryption (Addressable).
§ 164.312(b) Audit Controls (Required): Organizations must implement hardware, software, and procedural mechanisms that record and examine activity in information systems containing ePHI. The 16-day window suggests audit logging either wasn't comprehensive or wasn't actively monitored.
§ 164.312(e)(1) Transmission Security (Required): While this breach involved data at rest in AWS, the standard requires technical security measures to guard against unauthorized access to ePHI being transmitted over electronic networks. The same encryption principles apply to stored data under § 164.312(a)(2)(iv).
§ 164.308(a)(1)(ii)(D) Information System Activity Review (Required): The Security Management Process requires regular review of records of information system activity such as audit logs, access reports, and security incident tracking reports. This administrative safeguard should catch unauthorized access patterns before they persist for 16 days.
For the affected Covered Entities, the Breach Notification Rule created additional compliance burdens. Under 45 CFR § 164.410, when a breach occurs at a Business Associate, the Covered Entity remains responsible for notification to individuals, OCR, and potentially the media if the breach affects more than 500 residents of a state. The Covered Entity can delegate notification to the Business Associate, but it can't delegate accountability.
Lessons and Action Items
If you're a privacy officer working with Business Associates that store or process PHI in cloud environments, here's what this breach should prompt you to do:
Audit your Business Associate Agreements immediately. Your BAA should require the Business Associate to implement specific Security Rule safeguards, not just promise "reasonable security." Specify encryption requirements, access control standards, and audit logging expectations. Require annual security assessments and the right to audit their controls.
Request AWS security documentation from vendors using cloud infrastructure. Ask for their AWS security architecture, including identity and access management policies, network segmentation design, encryption implementation (both at rest and in transit), and logging configuration. If they can't produce this documentation, that's your answer about their security maturity.
Require evidence of continuous monitoring. Don't accept "we have monitoring in place" as sufficient. Ask what security information and event management (SIEM) tools they use, what alerts are configured, what the mean time to detect unauthorized access is, and who reviews alerts in real time. A 16-day intrusion window is unacceptable in 2026.
Verify encryption of data at rest. AWS offers multiple encryption options, but they must be configured and managed properly. Confirm your Business Associates are using AWS Key Management Service or equivalent, that encryption keys are rotated, and that access to keys is tightly controlled and logged.
Establish clear breach notification timelines in your BAA. The HIPAA Breach Notification Rule requires notification without unreasonable delay and no later than 60 days after discovery. Six months between discovery and client notification suggests either investigation complexity or coordination failures. Your BAA should specify notification timelines and require regular status updates during investigations.
Test your own breach response plan for Business Associate incidents. When Aesto notified its clients in June 2026, each Covered Entity had to activate its breach response, determine whether to delegate notification or handle it directly, and coordinate with potentially dozens of other affected organizations. Have you practiced this scenario?
Consider vendor consolidation and risk concentration. Aesto's breach affected at least 30 healthcare providers because it served as a centralized data migration and archiving vendor. That concentration of PHI in a single Business Associate creates systemic risk. Evaluate whether your vendor relationships create similar concentration points.
The Aesto breach won't be the last time a Business Associate's cloud security failure exposes millions of patient records. But it doesn't have to be your breach. Your vendor risk management program and your BAA terms are the controls you can implement today to prevent the same outcome.
