On Tuesday, August 25, 2026, McKesson Corporation discovered a cybersecurity incident affecting its information systems. On Friday, August 28, it filed a Form 8-K disclosing the incident, describing the investigation as being in its early stages, and stating that as of the filing date it had not determined that the incident is material.
Separately, the extortion group operating under the ShinyHunters name claimed to have exfiltrated data on 284 million patient records from McKesson’s Salesforce and Snowflake environments, following a voice phishing (vishing) campaign against McKesson employees that yielded Okta single sign-on credentials. The group says roughly 1 TB was taken across four days, August 21 to 25, 2026, and that it demanded $55,236,150 with a 72-hour deadline that McKesson did not answer.
Two things about that number need saying immediately.
First, it is the attacker’s claim. McKesson has confirmed an incident involving unauthorised access and exfiltration of data through third-party applications. It has not confirmed a record count, a population, or a data-element inventory. Nothing on a criminal leak site is a finding.
Second, the attackers themselves have said the figure is not a patient count. ShinyHunters told reporters that 284 million is a raw count of rows or lines in the exfiltrated data, that it had not finished analysing it, and that it could not say how many unique individuals are represented. Rows in a data warehouse are transactions, claims, order lines and appointment records — one patient generates hundreds — and attacker counts inflate further through duplication across tables, staging copies and historical snapshots of the same population. The compliance obligation, however, does not wait for the number.
This article is about what 45 CFR § 164.410 actually requires of a business associate, and why an incident at an organisation of McKesson’s structural position converts a single intrusion into a cascade of separate, individually enforceable notification duties held by other organisations entirely.
Why McKesson’s HIPAA Status Is the Whole Analysis
Most breach coverage treats “healthcare company” as a single category. HIPAA does not: it assigns duties by role, and the role determines who notifies whom. A covered entity under 45 CFR § 160.103 is a health plan, a health care clearinghouse, or a health care provider transmitting health information electronically in a standard transaction. A business associate is a person or entity that creates, receives, maintains or transmits PHI on behalf of a covered entity.
McKesson’s corporate family sits on both sides of that line. Its clearinghouse and pharmacy-transaction businesses perform health care clearinghouse functions, and provider organisations affiliated with the group are health care providers in their own right — covered entity roles. Far more extensively, its technology, prior-authorisation, specialty pharmacy, revenue-cycle, patient-support and real-world-data businesses handle PHI on behalf of thousands of hospitals, health systems, physician practices, pharmacies and plans, under business associate agreements executed with each. Some of it is neither: pure wholesale distribution to a provider does not by itself make the distributor a business associate.
Public reporting has tied the affected environments to McKesson’s oncology and multispecialty and medical-surgical business units — squarely the part of the enterprise most likely to operate under BAAs. The practical consequence is that a single forensic determination may need to be partitioned into a covered-entity conclusion for some data and a business-associate conclusion for the rest, with different notification recipients and different regulators watching. We examined the same structural problem when a billing vendor’s incident became its clients’ notification duty in our analysis of the MCBS medical billing breach and business associate liability.
What § 164.410 Actually Says
The rule is short, and every clause does work.
§ 164.410(a)(1) — the duty. Following discovery of a breach of unsecured PHI, a business associate shall notify the covered entity of such breach.
§ 164.410(a)(2) — discovery. A breach is treated as discovered as of the first day on which it is known to the business associate or, by exercising reasonable diligence, would have been known, with knowledge imputed from any workforce member or agent other than the person committing the breach.
§ 164.410(b) — timing. Notice must be made without unreasonable delay and in no case later than 60 calendar days after discovery.
§ 164.410(c) — content. The notice must include, to the extent possible, the identification of each individual whose unsecured PHI has been, or is reasonably believed to have been, accessed, acquired, used or disclosed — plus the other information the covered entity needs for its own § 164.404(c) notices, provided promptly as it becomes available.
Three points that consistently surprise people:
- The duty runs to the covered entity, not to individuals. Absent contractual delegation, a business associate does not notify patients, HHS or media. It notifies its customers, and the customers carry the public-facing obligations.
- Sixty days is a ceiling, not an allowance. “Without unreasonable delay” is the operative standard. A business associate that sits on a confirmed breach for 55 days while it polishes a communications plan has a defensible date and an indefensible posture, and OCR has consistently treated unexplained delay as an independent failure.
- The clock runs from the business associate’s discovery, not the covered entity’s — the cascade’s central legal fact, and it deserves its own section.
The Cascade: How One Incident Becomes Thousands of Obligations
Once a business associate notifies a covered entity, the covered entity’s own machinery starts.
§ 164.404 — notice to individuals. Without unreasonable delay and no later than 60 days after discovery, by first-class mail or agreed email, with prescribed content: what happened and the date range, the types of information involved, steps individuals should take, what the entity is doing, and contact procedures including a toll-free number.
§ 164.406 — notice to media. For a breach involving more than 500 residents of a State or jurisdiction, notice to prominent media outlets serving that jurisdiction, on the same clock. Frequently missed, because organisations count total affected individuals rather than performing the per-state count the rule requires.
§ 164.408 — notice to the Secretary. At 500 or more individuals, notice to HHS contemporaneously with individual notice and within the 60 days. Below 500, a log submitted within 60 days after the end of the calendar year of discovery.
§ 164.414(b) — burden of proof. The covered entity or business associate bears the burden of demonstrating that all required notifications were made, or that no breach occurred. Documentation is the defence.
Now stack those on the facts. If a business associate incident touches PHI belonging to several thousand covered-entity customers, the result is not one notification event. It is one § 164.410 notice per customer; thousands of independent covered-entity discovery determinations, each starting its own § 164.404 clock; thousands of separate notification campaigns with their own mailings, call centres and credit-monitoring decisions; thousands of separate § 164.408 submissions to HHS; and a per-state media-notice analysis run thousands of times, because the 500-resident threshold is evaluated against each covered entity’s own affected population in each jurisdiction, never against the aggregate.
Each of those obligations belongs to a different legal entity with its own counsel and its own regulator-facing record, and none can be discharged by McKesson unless the BAA says so and the covered entity agrees. The entities at the far end of the chain — small oncology practices, community pharmacies, independent physician groups — are the least equipped to run a mass notification programme and the most likely to blow the clock. The DentaQuest scope expansion to 2.3 million individuals is the recent illustration of what happens when the population estimate moves after the first notices go out; the Medtronic incident’s HIPAA analysis shows the same actor’s pattern producing the same downstream problem in a device-maker’s customer base.
”Discovery” Is the Word That Decides Everything
Both § 164.404(a)(2) and § 164.410(a)(2) define discovery identically: the first day the breach is known, or by exercising reasonable diligence would have been known, with knowledge imputed from any workforce member or agent other than the person who committed the breach.
Two consequences follow.
The clock can start before you understand the incident. Discovery is not the completion of forensics, the identification of affected individuals, or the legal determination that a breach occurred. It is the day the organisation knew, or should have known. Investigations legitimately continue past that date — § 164.410(c)(2) expressly contemplates supplying identifying information later — but the deadline does not move to accommodate them. We set out those mechanics in our piece on the AnMed Health data-theft confirmation and the HIPAA discovery clock.
“Reasonable diligence” is a constructive-knowledge standard. An organisation whose alerting would have surfaced anomalous bulk export from a SaaS warehouse, but whose alerts went unmonitored, does not get to date discovery from the moment someone finally looked. Under the imputation rule, a help-desk technician who took the vishing call or an analyst who dismissed an impossible-travel alert can each start the clock for the whole enterprise.
For downstream covered entities the question is more immediate: when does your discovery date fall? If you learned of the incident from press coverage rather than from a § 164.410 notice, you have a defensible position that your own clock has not started for a breach of your PHI, because you do not yet know your data is involved. That position degrades the longer you sit on it without asking. Document the date you first became aware, what you knew, whom you asked, and when — a contemporaneous file note is the only thing that will substantiate your date later.
The Four-Factor Assessment, and Why It Will Not Rescue Anyone Here
45 CFR § 164.402 builds a presumption into the definition of “breach”: an impermissible acquisition, access, use or disclosure of PHI is presumed to be a breach unless the entity demonstrates a low probability that the PHI has been compromised, based on a risk assessment of at least four factors — (1) the nature and extent of the PHI, including identifier types and re-identification likelihood; (2) the unauthorised person who used or received it; (3) whether the PHI was actually acquired or viewed; and (4) the extent to which risk has been mitigated. Three narrow exceptions exist, and none contemplates a criminal extortion group.
Run the four factors against the claimed data set — names, addresses, dates of birth, Social Security numbers, patient IDs, medical record numbers, Medicaid numbers, medications, allergies, diagnoses, appointment details, physician information — and the assessment is not close.
Factor 1 is the worst possible combination: SSN plus DOB plus address is a complete identity-theft package, Medicaid number plus MRN a complete medical-identity-theft package, and an oncology data set discloses the fact of a cancer diagnosis. Re-identification is not a probability here; the records are already identified. Factor 2 is an extortion group that publicised the theft and demanded eight figures. Factor 3 is exfiltration, not merely access — acquisition is the strongest form of this factor. Factor 4 offers nothing: mitigation means a signed attestation of destruction from a trustworthy recipient, or encryption meeting the HHS safe-harbour guidance. Paying a ransom is not mitigation — a criminal’s promise to delete is unverifiable, and OCR has never treated it as evidence of low probability of compromise.
The § 164.402 assessment is a genuine tool, built for the misdirected fax, the mis-addressed envelope, the laptop recovered intact. It is not designed to rebut a confirmed criminal exfiltration of identified clinical records, and using it that way produces a documented failure rather than an avoided notification.
One real safe harbour remains, and it is the encryption one. The breach definition reaches only unsecured PHI — PHI not rendered unusable, unreadable or indecipherable through encryption or destruction meeting the Secretary’s guidance. Data exfiltrated from a live SaaS session using valid credentials is not protected by encryption-at-rest, because the application decrypts it for the authenticated user. That is precisely the failure mode described in the HIPAA Security Rule encryption and MFA analysis: encryption controls a class of risk that credential-theft attacks route around entirely.
The Portal, and What 500 Means
Breaches of 500 or more individuals reported under § 164.408 appear on the HHS OCR Breach Portal — the public database known as the “wall of shame,” listing entity, state, covered-entity type, individuals affected, submission date and breach type. Entries stay in the active list for 24 months, then move to a permanent public archive, and in practice a 500-plus report draws an OCR investigation.
The mechanic that trips organisations up is that 500 is counted per reporting entity, not per incident. An incident affecting 40 million people across 3,000 covered entities produces 3,000 separate portal entries, each showing that entity’s own count, with some falling under 500 and becoming annual-log entries instead. The portal’s “business associate present” field is then how journalists, plaintiffs’ firms and OCR reconstruct the true aggregate scale.
The Security Rule Question: Vishing, SSO, and SaaS
The notification duties above are consequences. The Security Rule governs the cause, and the reported attack chain maps onto specific standards.
Vishing to a help desk → § 164.308(a)(5), Security Awareness and Training. This standard requires a training programme for all workforce members including management. A programme built around annual click-through email-phishing training does not address an adversary who telephones the service desk from a lookalike domain and impersonates IT. The control that matters is a documented, enforced identity-verification procedure for the help desk — one that cannot be satisfied by information an attacker can lift from an org chart, and that has no manager-override path. The same vector produced the Abbott and Exact Sciences vishing-linked incidents earlier this year.
Okta SSO compromise → § 164.312(d), Person or Entity Authentication. A required technical safeguard: verify that a person seeking access to ePHI is the one claimed. Single sign-on is a force multiplier in both directions — one compromised identity reaches every federated application. Push-based MFA, SMS codes and one-time passcodes are all phishable in real time, because the attacker on the phone simply asks the victim to read out the code or approve the prompt. Phishing-resistant authenticators — FIDO2/WebAuthn keys and passkeys, or certificate-based authentication — break that chain cryptographically, because the credential is bound to the origin and cannot be relayed. Our passkey and phishing-resistant MFA implementation analysis covers the deployment mechanics.
Salesforce and Snowflake as the destination → § 164.308(a)(1)(ii)(A) risk analysis and § 164.312(b) audit controls. The Okta → SaaS → bulk-export pattern is the defining healthcare attack chain of 2026, and the prosecution arising from the earlier Snowflake credential campaign is now public record, as covered in our piece on the Moucka guilty plea and SaaS MFA obligations. Two questions follow: does your risk analysis enumerate your SaaS data stores as systems containing ePHI, and do you have export-volume alerting on them? A risk analysis that stops at the perimeter and the EHR does not cover the systems where the data actually sits — and OCR has made incomplete risk analysis the most-cited failing in its recent resolution agreements.
The 2025 HIPAA Security Rule NPRM proposed removing the addressable/required distinction and mandating MFA, asset inventory, segmentation and encryption, and its final form remains unsettled. But an organisation waiting for that rule before deploying phishing-resistant MFA on the identity provider fronting its clinical SaaS estate is not managing a compliance timeline; it is accepting a control gap that § 164.312(d) already reaches today.
State Law and the Shorter Clocks
HIPAA does not preempt state breach notification law that is more stringent, and most state laws are more stringent on timing. The operative rule is that you comply with whichever clock expires first, for each affected resident.
Colorado, Florida, Washington, Maine and Texas all require notice within 30 days, Texas adding Attorney General notification on the same clock where 250 or more Texas residents are affected. Vermont requires 45 days with a preliminary AG notice at 14. California requires the most expedient time possible without unreasonable delay, with AG notification at 500 affected residents, and its Confidentiality of Medical Information Act adds a separate regime with statutory damages. AG thresholds vary by state and are routinely missed by organisations focused on the HHS submission.
For a nationwide data set the plan is therefore not “60 days.” It is a 50-jurisdiction matrix driven by the residency of each affected individual, executed by each covered entity separately, on the shortest applicable clock.
The SEC Question: Item 8.01, Not Item 1.05
McKesson is a public company, so Item 1.05 of Form 8-K is in play: a registrant must disclose, within four business days of determining that a cybersecurity incident is material, the nature, scope and timing of the incident and its material or reasonably likely material impact.
The load-bearing word is determining. The clock runs from the materiality determination, not from discovery, and the SEC expects that determination without unreasonable delay after discovery. McKesson filed on August 28 — three days after discovery — stating it had not determined the incident to be material. That is an Item 8.01 (Other Events) voluntary disclosure, and SEC staff guidance encourages exactly this structure: a registrant disclosing before completing its materiality analysis should use Item 8.01 rather than filing prematurely under Item 1.05, which is reserved for incidents actually determined to be material.
So: disclosure engaged voluntarily, materiality determination still open, and an Item 1.05 filing required within four business days if and when the analysis concludes the incident is material. Notification cost, remediation and litigation all feed that analysis — and for a business associate, the aggregate cost of a cascade, with indemnity provisions in thousands of BAAs pointing back upstream, is a materially different figure from direct forensic cost. A “not material” determination is itself a judgment that must be documented and defensible; we examined that in our analysis of third-party breach disclosure and SEC materiality in healthcare.
Checklist: If You May Be Downstream of This
For covered entities holding a BAA with a large distributor, technology or specialty-pharmacy vendor, this is the order of operations. None of it requires waiting for a notification.
1. Establish whether you have exposure, and write down the answer either way. Inventory every BAA and vendor relationship with the organisation, including subsidiary and brand names — the entity on your BAA may not be the entity in the headline. Identify which product lines you use and whether they map to the environments described publicly, and determine what PHI you sent, in what fields, for what population, over what period. Then record the date, the person who checked, and the conclusion, including a conclusion of “no exposure” — that file note is your evidence of reasonable diligence.
2. Document your own discovery date, deliberately. Note the date and source of first awareness and precisely what it told you. Send a written enquiry to the vendor’s privacy officer asking whether your PHI is implicated, and retain both the request and the response — an unanswered written enquiry is itself part of the record.
3. Read the BAA’s notification clause, not your memory of it. Many BAAs shorten § 164.410’s 60 days to 10, 5 or even 24 hours; the contract can be stricter than the regulation but never laxer. Check whether it requires the vendor to supply § 164.410(c) individual-identification data; who bears notification, credit-monitoring and mailing cost, and whether any indemnity is capped; whether individual notification is delegated to the business associate, noting that delegation shifts the work, not your liability under § 164.404; and whether subcontractor flow-down under § 164.502(e)(1)(ii) is specific.
4. Prepare the cascade before you need it. Build the affected-population extract capability now — individuals, data elements, state of residence — and run the per-state count for the § 164.406 media threshold and the state AG thresholds, which is where obligations are most often found late. Draft § 164.404(c) content in advance, contract for mailing, call-centre and credit-monitoring capacity rather than sourcing it in a crisis, and confirm who holds your OCR portal credentials.
5. Close the control gap on your own estate. Give your identity-provider help desk a scripted verification procedure with no manager override, and test it with an authorised social-engineering exercise. Move privileged accounts to phishing-resistant authenticators, treating push and SMS as insufficient for anything touching ePHI. Enumerate your ePHI-holding SaaS platforms by name in the § 164.308(a)(1)(ii)(A) risk analysis, with bulk-export and anomalous-query alerting on each.
Conclusion
The number that will define public memory of this incident — 284 million — is an attacker’s claim, disclaimed by the attacker itself as a row count rather than a person count, and unconfirmed by McKesson. Hold it at arm’s length until a determination exists.
What is not conditional is the structure of the obligation. If protected health information held on behalf of covered entities was exfiltrated, 45 CFR § 164.410 requires notice to those covered entities without unreasonable delay and no later than 60 days from discovery — a discovery date that, under § 164.410(a)(2), may already have been fixed on August 25, 2026. Each of those notices then starts a fresh clock at a different organisation under § 164.404, § 164.406 and § 164.408, none of which the business associate can discharge on its behalf.
That is the lesson independent of this case. A business associate breach is not one notification event with a large number attached. It is a fan-out: one determination upstream, thousands of independent obligations downstream, each carrying its own burden of proof under § 164.414(b), each recorded separately on a public federal portal, and each held by an organisation that did not choose the vendor’s authentication architecture but will answer for its consequences. The covered entities that handle it well will not be the ones with the best incident-response retainer. They will be the ones that already know which vendors hold their PHI, what their BAAs say about notification timing, how to produce an affected-population extract by state, and what date they first became aware.
Sources: McKesson Corporation Form 8-K, August 28, 2026 (SEC EDGAR), McKesson cybersecurity updates, BleepingComputer, Help Net Security, HIPAA Journal, CyberInsider, 45 CFR Part 164 Subpart D — Notification in the Case of Breach of Unsecured Protected Health Information, HHS OCR Breach Portal
This article is provided for informational purposes only and does not constitute legal advice.
