Field Notes · Incident Command September 2, 2026 · 8 min read

Your vendor's breach is your notification, not theirs.

Two of the largest disclosures this month came from vendors most affected organizations would struggle to name: an EHR archival service and an identity-verification provider. The vendor held the data, but the people in that data are the customer's patients, renters, and applicants. The letter, the regulator, and the class action land on the customer.

Update. Updated 2026-09-02: reacts to BleepingComputer and KrebsOnSecurity reporting of 2026-09-01 on the Aesto Health and IDScan.net disclosures.

Who must notify when a vendor is breached

In most frameworks the organization that collected the data owes the notification, and the vendor that lost it owes that organization a timely account of what happened.

That means a vendor's discovery date, forensic scope, and record-level identification of your data are not courtesies. They are the inputs your counsel needs to decide whether a duty exists and when it started.

The organizations that handle this well already know which vendors hold their data at rest, and they demand specific evidence rather than accepting a summary letter.

The breach is upstream. The duty is downstream.

On 2026-09-01 BleepingComputer reported that Aesto Health, a SaaS vendor that migrates and archives electronic health records, disclosed a breach affecting 9,540,683 people. Per that reporting, the intrusion ran from 2025-12-02 to 2025-12-18, the company internally confirmed it on 2026-05-26, and individual notices began on 2026-08-21. The data included Social Security numbers, dates of birth, medical information, driver's license numbers, financial account numbers, and ITINs. Twenty-nine provider organizations were affected, including VillageMD, Everside/Marathon Health, Marana Health, and Together Women's Health. No threat group claimed it.

Read that list of names again. Those providers are the ones whose patients receive the letters. Aesto is an archival vendor. Its job was to hold old records a provider migrated off a retired system. In many organizations that contract lives with whoever ran the migration years ago, and nobody in the current security or legal function thinks of it as a live data holder. The intrusion happened in December. The vendor confirmed it in May. The patients heard in August.

The same day, KrebsOnSecurity reported that a dark-web service calling itself Nexus was advertising more than 153 million driver's license scans from the United States and Canada, traced to identity-verification vendor IDScan.net. Per Krebs, the FBI New Orleans field office opened an inquiry on 2026-09-01, IDScan.net said it is investigating and has not reached conclusions, and the seller claimed to have been continuously exfiltrating new data for over a year. Corporate clients named in the reporting include Hertz, Target, FedEx, Motorola Solutions, and Jack Henry.

An identity-verification vendor is the purest form of this problem. The customer never wanted the license scan. It wanted a yes or no on whether the person at the counter was who they claimed. The scan was a byproduct, and the vendor kept it. If the seller's claim of a year of continuous exfiltration holds, every organization that ran scans through that service in that window has to work out whether its customers' documents were in the take. The vendor has not reached conclusions. The customers cannot wait for it to.

The companion pattern this month is what happens to a disclosure under pressure. Nutex Health filed an 8-K under Item 8.01 on 2026-08-24, then reclassified the event to Item 1.05, the material cybersecurity incident item, on 2026-08-31. A class action was filed on 2026-08-27, between the two filings. That is a materiality reversal inside a week. I am not commenting on the merits of either filing. I am pointing out that the first assessment did not survive contact with what came next, and that is the normal shape of a vendor-originated incident. The customer's initial read is built on the vendor's initial summary, and the vendor's initial summary is usually wrong in the direction of smaller.

None of this is legal advice. Whether a duty exists, which framework governs, and when the clock starts are questions for counsel. What I can say from the incident side is that counsel cannot answer them with the evidence a breached vendor sends by default.

The evidence to demand from a breached vendor

A vendor's breach letter is written by the vendor's counsel for the vendor's benefit. It will say an unauthorized party accessed certain systems, that a forensic firm was engaged, and that customers are being notified out of an abundance of caution. That is not evidence. It is a position. Here is what I would ask for, in writing, in the first conversation.

A forensic scope statement that names your records. Not "customer data may have been affected." Which of your datasets, by system, by table or export, by date range, and by record count. If the vendor's forensic firm cannot produce that, the vendor does not yet know what it lost and should say so.
The vendor's discovery date, and its position on which clock that date starts. Under HIPAA a business associate's breach starts a 60-day notification clock. The Aesto reporting has an intrusion window in December, an internal confirmation on 2026-05-26, and notices on 2026-08-21. Which of those dates the vendor treats as discovery is a question your counsel will need to test, and the vendor's answer belongs in writing.
Proof of what the vendor was retaining and why. An archival vendor holds data by design. An identity-verification vendor should not be holding license scans long after the check cleared. Ask for the retention policy that applied to your data and the evidence it was enforced. The gap between the two is usually the size of the breach.
Cloud audit-log retention. If the vendor runs on AWS, ask whether CloudTrail and GuardDuty were enabled across all accounts and regions, how long the logs were kept, and whether they cover the full intrusion window. A vendor that confirms an intrusion five months after it started often did so because the logs that would have shown it earlier did not exist or had aged out. If the logs do not cover the window, the scope statement is an estimate, and you should treat it as one.
The indemnity and notification-cost clauses in your contract. Pull the master agreement and the business associate agreement before the first call. Know whether notification costs, credit monitoring, and regulatory response are the vendor's obligation or yours. Counsel owns this question. The incident team's job is to have the contract on the table on day one.

The vendor will push back. The scope statement in particular is often "still being determined" for weeks. That is a finding in itself. If the vendor cannot tell you which of your records were taken, your counsel is deciding whether to notify on an absence of evidence, and the notice will have to say so.

Everything you receive should be dated, attributed to a named person at the vendor, and preserved. When the vendor's story changes, and it will, the sequence of what it told you and when is the record that protects you.

Build the vendor-data map before the letter arrives

The organizations that will handle the next Aesto well are the ones that can answer one question in an hour: which vendors hold our data at rest, and what data is it. Not who processes it in flight. Who holds it. Where it sits when nobody is using it.

Most vendor inventories are built for procurement and answer a different question. They know who is paid and for what. They do not know that the migration vendor from a prior EHR still holds a full copy of the archive, or that the identity-verification service retains the scans it was only supposed to check. Both of this month's examples sit in exactly that blind spot. Archival vendors in particular fall out of the inventory the moment the migration project closes, and their contracts fall out with them.

A usable vendor-data map is short. For each vendor it records what data elements the vendor holds, whether at rest or only in transit, where the contract and the business associate agreement live, who at the vendor is the security contact, and what the contract says about notification timing and cost. It includes retired and archival vendors. It is reviewed when a system is decommissioned, because that is the moment data moves to a vendor and stops being visible.

The five-month detection window in the Aesto reporting is the second reason to build it now. You cannot shorten a vendor's detection time. You can shorten your own reaction time, and the only way to do that is to already know the vendor exists, what it holds, and what you are entitled to demand.

When the letter arrives, the map turns a scramble into a checklist. The contract is found. The security contact is called. The evidence list above goes out in the first conversation. Counsel gets the vendor's discovery date and scope statement in writing on day one and starts its clock analysis on facts rather than on the vendor's summary. The alternative is what many of the twenty-nine provider organizations in the Aesto reporting are likely doing right now: learning from a vendor's notice that the vendor existed, and then discovering how much it held.

Questions people ask

Who is responsible for notifying people when a vendor is breached?

In most frameworks the organization that collected the data owes the notification, and the vendor owes that organization a timely account. The Aesto and IDScan.net reporting shows the pattern: the vendor discloses, the named customers notify. Which duty applies to you is a question for counsel.

What should I ask a breached vendor for first?

A forensic scope statement that names your specific records, the vendor's discovery date in writing, its retention policy and proof it was enforced, cloud audit-log retention covering the intrusion window, and the indemnity and notification-cost terms in your contract. Ask on day one and preserve every answer.

What is a vendor-data map and why does it matter?

A short inventory of every vendor that holds your data at rest, what elements it holds, and where the contract lives. It includes archival and retired vendors, which is where this month's examples sat. It turns a vendor breach notice into a checklist instead of a discovery exercise.

If a vendor has told you your data was in its breach and you need the vendor's forensic scope and timeline tested independently, an incident closure review establishes what the evidence actually supports.