Home > Security and Compliance Blog > Cybersecurity Risk Management > The Amazon One Medical Breach: When Third-Party File Storage Becomes a PHI Liability

The Amazon One Medical Breach: When Third-Party File Storage Becomes a PHI Liability

by Patrick Spencer updated June 23, 2026 Cybersecurity Risk Management

Reading Time: 12 minutes

The Amazon One Medical breach illustrates a truth the healthcare security community knows but struggles to operationalize: it does not matter how strong your clinical systems are if the data that flows out of them into downstream file storage, billing workflows, and vendor-managed environments is not subject to the same controls. ShinyHunters, the threat group that has previously claimed breaches at Ticketmaster, Santander, and Snowflake customer environments, posted samples of purported Amazon One Medical patient records to a dark web forum and claimed to hold 8.8 terabytes of data exfiltrated from a third-party file storage environment. Samples have been independently verified as authentic patient records, including names, dates of birth, insurance information, diagnoses, and treatment notes – a combination that meets HIPAA’s definition of protected health information across multiple categories.

The incident follows a pattern that security researchers have been documenting for years: healthcare organizations invest heavily in securing their EHR platforms and clinical networks, then inadvertently expose the same patient data by allowing it to flow into file storage environments, integration platforms, and vendor-managed systems that do not carry equivalent security controls. The data at rest in those downstream environments often lacks the encryption protections applied in core clinical systems, is subject to far less rigorous ABAC, and is monitored by vendors whose HIPAA Business Associate Agreement obligations may not have been verified recently or thoroughly.

Table of Contents

The Kiteworks 2026 Data Security and Compliance Risk: Annual Forecast Report flagged third-party data exposure in healthcare as one of the highest-risk categories for the year, noting that the combination of increased data sharing across care coordination networks, aggressive monetization of healthcare data by threat actors, and persistent underinvestment in security for non-EHR data environments creates conditions for exactly this kind of breach. The Amazon One Medical incident is the most prominent realization of that risk profile to date in 2026.

This post examines what is known about the breach, what the exposure means for affected patients and for Amazon One Medical’s regulatory obligations, and what healthcare organizations should take from this incident as a prompt to review their own exposure.

Key Takeaways

1. A third-party file storage misconfiguration, not a clinical system compromise, was the entry point

The breach did not originate inside Amazon One Medical’s electronic health record or clinical systems – it originated in a third-party file storage environment, illustrating the persistent risk that vendor-managed infrastructure poses to healthcare organizations even when internal systems are properly secured.

2. The ShinyHunters claim of 8.8 TB remains unverified, but partial verification is worse

ShinyHunters’ assertion that they exfiltrated 8.8 terabytes of patient data has not been independently confirmed in full, but samples of patient records posted to dark web forums have been verified as authentic – meaning even a fraction of the claimed volume represents a significant HIPAA breach.

3. PHI exposure spans nine US metropolitan areas

Patient records confirmed as part of the exposed dataset include individuals from nine US metropolitan areas where Amazon One Medical operates, dramatically widening the potential population requiring breach notification and raising the compliance and litigation exposure proportionally.

4. Healthcare organizations are systematically underprotecting data in transit and at rest outside clinical systems

The breach pattern – sensitive patient data residing in a file storage system that was not subject to the same security controls as core clinical infrastructure – reflects a systemic gap across the healthcare sector, not a unique failure specific to Amazon One Medical.

5. HIPAA’s Business Associate Agreement requirements create direct organizational liability regardless of where the breach occurred

Amazon One Medical’s third-party storage vendor relationship triggers HIPAA Business Associate Agreement obligations; a breach in that environment creates the same notification and liability exposure as a breach in the covered entity’s own systems, a fact that many healthcare organizations still underestimate when evaluating TPRM.

You Trust Your Organization is Secure. But Can You Verify It?

Read Now

What Happened: The Breach Timeline and Attribution

The breach came to public attention when ShinyHunters posted a sample dataset to a dark web marketplace, claiming it was drawn from 8.8 terabytes of Amazon One Medical patient data acquired by exploiting a misconfiguration in a third-party file storage environment. The group provided sample records as proof of possession, and independent security researchers subsequently verified that a subset of those records matched the format and content consistent with Amazon One Medical patient records, including care coordination notes and insurance billing data.

ShinyHunters is a well-documented threat actor with a history of high-volume data theft from cloud and SaaS environments. Their previous operations have targeted misconfigured cloud storage buckets, compromised SaaS vendor environments, and exploited credential theft at integration platform providers. The Amazon One Medical claim follows the same general methodology: rather than attacking hardened clinical systems directly, the group identified a less-scrutinized storage environment in the supply chain and exfiltrated data from it. The claimed 8.8 TB volume – if accurate – would represent one of the largest individual healthcare breaches by data volume in 2026.

Amazon confirmed that it was investigating “unauthorized access to a third-party file storage environment” associated with Amazon One Medical operations and that it had notified affected patients in accordance with HIPAA requirements. The company stated that its core clinical systems were not compromised and that the access was isolated to the third-party environment. Law enforcement has been notified, consistent with standard incident response protocol for a breach of this magnitude.

The distinction between “core clinical systems not compromised” and “third-party file storage compromised” is legally and operationally significant – but it offers patients and regulators cold comfort. Under HIPAA, the covered entity (Amazon One Medical) retains responsibility for the protection of PHI regardless of whether it resides in their own systems or in a Business Associate’s environment. The breach notification obligations, the Office for Civil Rights investigation, and the potential civil liability are the same either way.

The PHI Categories at Risk

The sample records verified by independent researchers indicate that the compromised dataset included combinations of PHI that span multiple HIPAA-defined identifier categories. The most sensitive categories confirmed include full names combined with dates of birth, health insurance member IDs and payer information, diagnosis codes and clinical notes, prescription records, and care coordination messages between providers. In combination, these elements represent what HIPAA practitioners consider “high-risk” PHI – the type of records that enable identity theft, insurance fraud, and targeted social engineering against patients.

The geographic scope compounds the severity. Amazon One Medical operates in nine major US metropolitan areas, and the breach appears to include records from patients across those markets. Multistate breach notification requirements mean that Amazon One Medical must navigate not only HIPAA’s federal requirements but potentially varying state notification laws, some of which – California’s CCPA/CPRA, for example – impose additional obligations and timelines beyond HIPAA’s 60-day notification window. Organizations subject to CCPA must provide notice within 30 days of discovery for some breach categories, compressing the response timeline significantly.

The HIPAA Minimum Necessary Rule is worth examining in this context. The rule requires that covered entities and their business associates access and use only the minimum amount of PHI necessary for the specific purpose at hand. If the file storage environment that was compromised contained records beyond what was genuinely necessary for the operations it was supporting – a common finding when healthcare organizations migrate data to vendor-managed environments without a systematic data minimization review – that creates both a compliance issue and an aggravating factor in the breach’s severity assessment.

The combination of breadth (nine cities), depth (multiple PHI categories per patient), and recency (data from active patient relationships) makes this a high-severity breach from a notification and liability standpoint regardless of whether the full 8.8 TB figure is verified. HIPAA’s breach risk assessment framework requires covered entities to evaluate the probability that PHI has been compromised based on available evidence, and verified authentic sample records cross that threshold clearly.

Why Third-Party File Storage Is Healthcare’s Persistent Vulnerability

The healthcare sector’s security investment is heavily concentrated in the systems that clinicians touch directly – EHR platforms, clinical imaging systems, medical device networks, telehealth infrastructure. That investment is appropriate; those systems are high-value targets and their compromise can have immediate patient safety consequences. But the concentration of investment in clinical systems leaves a systematic gap in the environments where PHI accumulates as a byproduct of normal operations: file transfer workflows between providers and payers, vendor-managed billing and coding platforms, care coordination tools that aggregate records across provider networks, and the various file storage environments that integrate with all of the above.

Third-party risk management in healthcare is often more aspirational than operational. Organizations typically execute a Business Associate Agreement when engaging a vendor, conduct a security assessment at contract initiation, and then revisit that assessment infrequently – sometimes only at contract renewal. In the intervening period, the vendor’s security posture may have changed, the data they hold may have grown substantially, and the integration points through which data flows to them may have expanded. None of those changes trigger a mandatory security review under most healthcare vendor risk management programs.

The file storage environment that was the entry point in the Amazon One Medical breach represents a category of infrastructure that healthcare organizations often treat as low-risk: it is not a clinical system, it does not process real-time patient care, and it does not have direct patient-facing interfaces. But the data in it is every bit as sensitive as the data in core clinical systems – and in many cases, it has sat there longer, with less scrutiny, accumulating records that should have been subject to data minimization and retention policies that were never applied.

Healthcare organizations that review their own vendor landscapes in the wake of this breach will often find a similar pattern: PHI resident in file storage, billing platform archives, and integration middleware that is not subject to the same encryption, access control, or audit logging requirements they apply to their EHR environments. That gap is not a single vendor’s failure – it is a structural characteristic of how healthcare data flows through complex provider and payer ecosystems. Addressing it requires a systematic approach to data governance that follows the data rather than stopping at the perimeter of the covered entity’s primary systems. Organizations serious about closing this gap should also evaluate their supply chain risk management practices to ensure that downstream vendors are held to the same security standards as direct business associates.

The Regulatory Consequences: HIPAA, OCR, and State Law Obligations

The regulatory consequences of a breach of this scale are substantial and multidimensional. Under HIPAA’s Breach Notification Rule, Amazon One Medical must notify affected individuals within 60 days of discovery, notify the Department of Health and Human Services, and – given that the breach exceeds 500 individuals in multiple states – notify prominent media outlets in each affected state. The HHS Office for Civil Rights will conduct an investigation, during which Amazon One Medical must demonstrate that its HIPAA compliance program, including its Business Associate Management practices, met the required standard of care.

The HIPAA Security Rule requires covered entities to implement administrative, physical, and technical safeguards for electronic PHI. In a third-party breach scenario, the OCR investigation will focus on whether the covered entity’s Business Associate Agreement adequately specified security requirements, whether the covered entity conducted appropriate due diligence in selecting and monitoring the vendor, and whether the specific misconfiguration that enabled the breach would have been identified under a reasonable security assessment program.

State law obligations layer additional complexity. California’s CPRA grants consumers the right to know whether their personal information has been compromised and imposes specific notification timelines and content requirements that differ from HIPAA’s. The Federal Trade Commission has also demonstrated increasing willingness to pursue enforcement actions against healthcare organizations for data security failures under its general authority, independent of HIPAA, creating a second regulatory track for potential penalties.

The cumulative regulatory exposure from a multistate breach of this profile – federal HIPAA investigation, potential OCR civil money penalties, state AG inquiries, and FTC scrutiny – can easily exceed $10 million even before private litigation is factored in. HIPAA’s civil money penalty tiers run up to $1.9 million per violation category per year, and OCR has demonstrated willingness to pursue maximum penalties for covered entities it determines failed to conduct adequate risk assessments or maintain adequate Business Associate Agreement oversight.

For healthcare organizations reviewing their own exposure in light of this breach, the practical questions are: Do your Business Associate Agreements specify security control requirements for the data your vendors hold? When did you last conduct a security assessment of your major vendors’ file storage and integration environments? Is the PHI in those environments subject to the same AES-256 encryption, access control, and audit logging standards as your clinical systems? If the answers are uncertain, that uncertainty itself is a compliance risk.

Building a Healthcare Data Security Architecture That Addresses the Actual Threat Model

The Amazon One Medical breach points toward an architecture question that healthcare security programs need to address directly: how do you apply consistent security controls to PHI regardless of where it resides in your ecosystem?

The answer requires moving away from a perimeter-and-core model – where security controls are concentrated around clinical systems and the rest of the environment is treated as lower risk – toward a data-centric model where encryption, access control, and audit logging follow the data wherever it goes. That includes file storage environments managed by vendors, integration platforms, billing systems, and the various data flows that connect them.

End-to-end encryption for PHI in transit and at rest should be table stakes, not an advanced security measure. Data held in vendor-managed environments should be encrypted with FIPS 140-3 Level 1 validated encryption and the encryption keys should be managed in a way that ensures the vendor cannot access the plaintext data – eliminating the attack surface that storage misconfigurations create. When the storage environment is misconfigured and data is exposed, encrypted data with externally managed customer-controlled encryption keys provides a meaningful backstop that unencrypted data does not.

ABAC applied to file access – including in vendor-managed environments – limits what a compromised vendor account or misconfigured permission can access. Rather than granting broad access to a file storage environment and relying on perimeter controls to prevent exfiltration, ABAC approaches enforce fine-grained access controls based on user attributes, data sensitivity, and context. When an attacker compromises an account in a storage environment, they get what that account can access – nothing more.

A unified audit trail across all environments where PHI resides gives security and compliance teams the visibility they need to detect anomalous access, investigate incidents, and demonstrate compliance to OCR investigators. The CISO Dashboard capability in the Kiteworks Private Data Network provides this unified visibility across all content communication channels – including managed file transfer, secure email, secure file sharing, and enterprise integrations – with a single-pane-of-glass view of who accessed what, when, and from where.

Healthcare organizations that want to address the structural gap the Amazon One Medical breach highlights should also review their security architecture for DSPM for healthcare considerations – specifically, whether they have visibility into where PHI resides across their entire ecosystem, not just in their core clinical systems. Applying data classification disciplines to content stored in vendor-managed environments is a prerequisite for knowing what is sensitive, where it lives, and whether it is adequately protected.

To learn more about how Kiteworks helps healthcare organizations protect PHI across their entire data ecosystem, schedule a custom demo today.

Frequently Asked Questions

Verified samples from the breach include patient names, dates of birth, health insurance member IDs, diagnosis codes, clinical notes, and prescription records – categories that HIPAA classifies as protected health information. The breach covers patients from nine US metropolitan areas where Amazon One Medical operates, making this a multistate incident with both federal HIPAA notification obligations and state-specific requirements under laws like California’s CCPA and CPRA. ShinyHunters’ claimed total of 8.8 terabytes of data has not been independently verified in full, but the confirmation of authentic record samples means that affected patients should assume their PHI may have been compromised and should monitor their insurance accounts and health records for signs of unauthorized activity. Patients in California may have additional rights to request information about the breach under the state’s CPRA notification provisions.

Under HIPAA, a covered entity retains responsibility for the protection of PHI regardless of whether it resides in the covered entity’s own systems or in a Business Associate’s environment. When a BA experiences a breach, the covered entity must still comply with HIPAA’s Breach Notification Rule – including patient notification within 60 days, HHS reporting, and media notification for breaches affecting more than 500 individuals in a state. The OCR investigation will examine whether Amazon One Medical’s Business Associate Agreement with the storage vendor adequately specified security requirements, whether appropriate due diligence was conducted, and whether the HIPAA Security Rule‘s technical safeguard requirements were met in the vendor environment. Liability exposure includes civil money penalties and potential settlement agreements that impose ongoing compliance monitoring requirements that can extend for years after the incident. Healthcare organizations with similar vendor structures should review their incident response plans to ensure BA breach scenarios are explicitly covered.

Three controls, applied in combination, would have materially reduced the breach’s impact. First, encryption of PHI at rest in the storage environment with externally managed keys – so that a misconfiguration exposing the storage environment would not expose readable data. Second, ABAC governing access to individual records within the storage environment, limiting what a compromised credential or misconfigured permission could access. Third, a continuous audit trail capturing access events in the vendor-managed environment and correlating them with behavioral baselines – so that bulk exfiltration activity would trigger anomaly alerts. Healthcare organizations should evaluate whether their Business Associate Agreements require these controls as a condition of holding PHI, not merely as a best practice recommendation. A security risk management framework that extends explicitly to BA environments is essential for closing this gap.

Healthcare organizations should treat the Amazon One Medical breach as a prompt to audit their own vendor landscapes. The first step is inventorying which vendors hold PHI, in what volumes, and under what security controls. The second step is reviewing Business Associate Agreements to confirm that they specify encryption, access control, and audit logging requirements consistent with current best practices. The third step is conducting security assessments of high-risk vendors – particularly those holding large volumes of PHI in file storage or integration environments – rather than relying on point-in-time assessments conducted at contract initiation. Organizations that identify gaps should prioritize TPRM remediation as a compliance priority, documenting their assessment and remediation efforts as evidence of good faith compliance with the HIPAA Security Rule’s risk management requirements. Applying data governance policies that require periodic review of PHI volumes held by vendors will help prevent data accumulation without oversight.

Kiteworks addresses the architectural gap that the Amazon One Medical breach highlights – the absence of consistent security controls for PHI outside of core clinical systems – through its Private Data Network. The platform applies FIPS 140-3 Level 1 validated encryption to all content in transit and at rest, enforces ABAC policies that govern what users and systems can access based on role, data sensitivity, and context, and logs every access event in a unified audit trail that spans all content communication channels. For healthcare-specific compliance, Kiteworks supports HIPAA compliance requirements including the Security Rule’s technical safeguard obligations and provides the documentation and reporting capabilities that OCR investigations require. The CISO Dashboard gives security and compliance leadership real-time visibility into PHI access across the organization, including in vendor-managed integration environments – addressing the blind spot that made the Amazon One Medical breach possible. For healthcare organizations also managing industry-specific compliance obligations beyond HIPAA, Kiteworks provides a unified platform that consolidates security controls across all sensitive content workflows.

Additional Resources