When a health system moves to a new electronic health record (EHR) platform, the old records have to go somewhere. Often they go to a specialist vendor that migrates and archives them. The records stop being part of daily operations. They do not stop being sensitive.
In 2026, one such vendor reported that an intruder had been inside its cloud environment. According to Paubox, Aesto Health, a Birmingham, Alabama company that provides data migration, EHR exchange, and legacy data archiving, reported 9,540,683 affected individuals to the U.S. Department of Health and Human Services (HHS).
Details are still limited, and Aesto has not published how the intruder got in. But the shape of the incident is clear enough to learn from. The real lesson is not about one vendor's cloud configuration. It is about what happens to data after it leaves the system where people were protecting it.
What Happened
Based on public reporting, the facts so far are these:
- The intrusion: Paubox reports that data was taken between December 2 and December 18, 2025. Aesto found "unauthorized activity" in portions of its Amazon Web Services (AWS) infrastructure on December 18.
- The scale: Breached.company reports that the actor accessed "a limited portion" of the AWS environment, and that no ransomware group has claimed the attack. The root cause has not been published.
- The data: Names, dates of birth, Social Security numbers, driver's license and other government ID numbers, taxpayer IDs, financial account numbers, health insurance information, and medical information. What each person lost varies.
- The clients: At least two dozen provider organizations are affected, according to Paubox. Counts vary by outlet, so treat any single number as approximate.
- The timeline: Aesto's investigation concluded on May 26, 2026. DPC Insider reports that Aesto notified its clients in late June, and that filings reached state attorneys general on July 31. DPC Insider calculates that as 225 days after the incident.
State filings give a sense of how widely the records spread. Breached.company lists 80,622 South Carolina residents and 37,253 Washington residents among those affected. Aesto is offering 24 months of Experian identity monitoring.
An Archive Is Still Production Data
It is easy to think of an archive as a quiet back room. Nobody is treating patients from it. Nobody is running reports against it. It is cheaper to store and easier to forget.
Attackers do not see it that way. An archive is a large, consolidated collection of exactly the fields that are hard to replace: Social Security numbers, insurance details, medical histories. It often holds records from many years and many facilities in one place. For someone with access, it is more efficient than breaking into dozens of hospitals one at a time.
This is the principle behind a point we have made before. The system may no longer be production, but the data still is. We described the same dynamic in The Hidden Risk of Non-Production Data. A legacy archive is a close cousin: a copy of real data in a place where the controls are weaker than the sensitivity of what it holds.
Handing Data to a Vendor Does Not Hand Over the Duty
DPC Insider points out that under HIPAA, the duty to notify patients stayed with the covered entity, even though the notification letters went out under Aesto's name. The same reasoning applies more broadly. The provider chose to move its records, and the provider remains answerable for them.
That is a fair burden to carry, but it is not a simple one. A health system may use dozens of vendors, and some of them hold data from systems the organization retired years ago. Mergers add more. Every acquisition brings legacy archives that the combined organization may not have fully inventoried.
We covered the general pattern in The Sensitive Data Supply Chain: every copy is another place for data to leak, and every recipient is another link. Migration and archiving vendors are an especially concentrated link, because their entire job is to hold complete copies.
Long Gaps Make Everything Harder
The time between detection and notification matters too. Paubox notes that some client notices indicate roughly five months from detection to confirming which data was affected, and up to eight months before patients heard about it. That is not unusual for a large forensic review, and we should be fair about it: working out which of nine million records were touched is slow work.
It is also a reminder of a structural problem. If the data was readable by whoever held the right access, the investigation has to reconstruct who saw what. If the data was protected at the field level, with Social Security numbers and diagnoses encrypted or tokenized, the question changes. The investigators can ask whether the intruder could use what they took.
Five Questions to Ask About Your Archive Vendors
- Do we have a complete list? Include vendors you no longer actively use. If a vendor still holds your data, it belongs on the list.
- Do we still need to retain it? Data destroyed on schedule cannot be exposed. Retention periods should be enforced, including in archives.
- What does the contract require? Business associate agreements should set a firm deadline for notifying you of an incident, not a vague promise.
- How is the data protected if the environment is breached? Ask whether sensitive fields are encrypted or tokenized, and who holds the keys. Encryption at the storage layer alone does not help when the intruder inherits access to the running system.
- Could we migrate with less sensitive data? Many migrations and test loads do not need real identifiers. Masked or tokenized data can serve the purpose.
OnData's Take
The Aesto incident is a useful case because nothing about it is exotic. A trusted vendor held a large copy of sensitive records, and an unauthorized party reached part of its cloud environment. The pattern repeats across industries. Protection that depends on the vendor's perimeter holding is protection that has been delegated, not secured.
Data-centric security takes a different approach. OnData SecureFile discovers, classifies, and encrypts sensitive files, with access control that follows the file wherever it is stored, including archives and exported copies. OnData SecureDB provides runtime encryption and identity-based access control for databases, so that the records in a migration or archive stay protected at the data layer. And for migration, testing, and analytics, OnData SecureAI supports de-identification and masking so that systems get the data they need without the identifiers they do not.
Retiring a system does not retire the risk. Protect the data, and the archive is just another place it can safely rest.
