Good morning everyone,

We hope you’re finding ways to stay cool as summer settles in.  This past week brought a notable HIPAA enforcement action, critical software vulnerabilities, and new state‑level privacy laws.  Several health‑care organizations also issued breach notices stemming from compromises at third‑party vendors.  Together, these events remind us that risk analysis, vendor oversight, vulnerability management, and privacy compliance require constant vigilance.

Below you’ll find summaries of the most significant developments and practical takeaways for compliance, security and privacy leaders.

Regulatory & Legal Updates

HHS OCR settles ransomware investigation with Spencer Gifts LLC Flexible Benefits and Welfare Benefit Plan

What happened: The Office for Civil Rights (OCR) announced a settlement with Spencer Gifts LLC Flexible Benefits and Welfare Benefit Plans after a November 2021 ransomware attack encrypted servers storing PHI.  The plan reported the breach in January 2022.  OCR’s investigation found failures to conduct an accurate and thorough risk analysis and to implement policies to comply with the HIPAA Privacy, Security and Breach Notification Rules.  Approximately 10,023 individuals were affected.  Under the resolution agreement the plan will pay $450 000 and implement a two‑year corrective action plan requiring a comprehensive risk analysis, updated policies and workforce training.  OCR reminds covered entities to identify where ePHI exists, perform periodic risk analyses, implement audit controls and encryption, and provide regular HIPAA training.

Why it matters: This is OCR’s 20th ransomware enforcement action and highlights that employer‑sponsored health plans are equally accountable for HIPAA compliance.  OCR’s findings show that not performing a documented risk analysis and lacking basic policies (e.g., incident response, breach notification) can lead to significant penalties even if a third‑party attack is the catalyst.  The resolution agreement reinforces that corrective actions are not one‑time tasks but multi‑year programs.

Recommended actions:

• Map all locations where electronic PHI (ePHI) is stored or transmitted and update this inventory as systems and vendors change.
• Conduct and document an enterprise‑wide risk analysis that considers threats like ransomware, supply‑chain compromises and insider misuse; update the analysis annually or after major changes.
• Review and revise privacy, security and breach‑notification policies; ensure they include clear procedures for responding to ransomware and vendor incidents.
• Provide role‑based HIPAA training that covers phishing, social engineering, secure remote access and timely breach reporting.

HRSA’s 340B Model Pilot update & legal challenges

What happened: The Real Economy Blog reported on the Health Resources and Services Administration’s (HRSA) 340B Model Pilot Program, which is expected to relaunch after HRSA reviews comments received by April 20 2026.  The pilot aims to modernize drug‑discount oversight by shifting to a rebate model with claims‑level data sharing and measures to prevent duplicate discounts.  A federal court recently overturned an HRSA policy that required child sites to appear on a hospital’s cost report before obtaining 340B pricing; HRSA is appealing.  Stakeholder feedback suggests the program could start January 1 2027.

Why it matters: The 340B pilot reflects broader efforts by CMS and HRSA to increase drug‑pricing transparency and prevent duplicate discounting.  Hospitals will need to build or improve systems to capture claims‑level data and handle post‑purchase rebates.  The legal challenge may change eligibility rules for offsite facilities; organizations should watch the appeal closely.

Recommended actions:

• Monitor HRSA communications for the draft notice on the 340B pilot and plan for potential rebate workflows that require post‑purchase reconciliations.
• Strengthen data infrastructure to capture and validate claims‑level data across pharmacy and finance systems.
• Align pharmacy, finance, compliance and IT teams early to coordinate new reporting and reimbursement processes.
• Evaluate cash‑flow impacts of delayed rebates and ensure contractual arrangements with manufacturers address timing and payment terms.

Connecticut enacts genetic privacy law (SB 4)

What happened: Connecticut Governor Ned Lamont signed SB 4, an omnibus privacy law containing direct‑to‑consumer genetic testing provisions.  The law defines a “direct‑to‑consumer genetic testing company” as an entity offering genetic testing to consumers or collecting/analyzing genetic data provided by consumers.  It grants consumers property rights in their biological samples and genetic test results and requires companies to disclose genetic data practices and obtain express consent for collection, use, disclosure and retention.  Consumers can access and delete genetic data, require destruction of biological samples, and revoke consent.  Violations are deemed unfair or deceptive trade practices enforceable by the state Attorney General.  Provisions take effect October 1 2026.

Why it matters: The law closes gaps for genetic testing companies not covered by HIPAA and sets a high bar for transparency and consent.  Unlike some state laws, it does not exempt human‑subject research or HIPAA‑covered entities, meaning health systems offering consumer‑facing genetic services may be subject to overlapping regulations.  The recognition of property rights in DNA samples could spur litigation over ownership and secondary uses.

Recommended actions:

• For organizations offering genetic testing, conduct a gap analysis between current consent processes and SB 4’s express consent requirements for primary and secondary uses.
• Update privacy notices to disclose data handling, retention, third‑party sharing and sample‑destruction policies.
• Develop processes to respond to consumer requests to access, delete or destroy genetic data and samples within statutory deadlines.
• Monitor additional state genetic privacy bills; similar laws have been introduced in other states and may require multi‑state compliance strategies.

Breach & Incident Notices

NYC Health + Hospitals third‑party vendor data breach

What happened: New York City Health + Hospitals (NYC H+H) published a notice on March 24 2026 to inform patients and workforce members about a security incident involving a third‑party vendor.  The notice remains posted on the health system’s website until June 23 2026.  Investigators determined that an unauthorized actor accessed certain NYC H+H systems between November 25 2025 and February 11 2026 and copied files.  The breach appears linked to a vendor security incident.  Potentially exposed data include health insurance information, medical data, biometrics, billing/claims records and personal identifiers such as Social Security numbers and driver’s license numbers.  NYC H+H deployed additional security measures, reset credentials, enhanced remote‑access controls and offered 24 months of identity‑protection services to all patients and workforce members since 2020.

Why it matters: The breadth of data types involved—including biometrics and precise geolocation—underscores the escalating sensitivity of data stored across health‑care systems.  Although the incident occurred earlier this year, its notice period highlights ongoing regulatory obligations under HIPAA’s breach‑notification rule.  The breach also demonstrates how vulnerabilities at third‑party vendors can expose multiple classes of personal information.

Recommended actions:

• Review vendor contracts to ensure they require prompt notification of security incidents and adherence to HIPAA breach‑notification timelines.
• Validate that third‑party vendors implement strong access controls, encryption and regular security assessments; include rights to audit security controls.
• Update incident response plans to coordinate with vendor incident teams; test notification processes to confirm that impacted patients can be notified within required timelines.
• Encourage affected individuals to enrol in offered identity‑protection services and to monitor medical billing statements and credit reports for fraudulent activity.

One Medical Seniors (Iora Health) third‑party storage breach

What happened: One Medical reported that on June 13 2026 it discovered unauthorized access to a third‑party file‑storage system used to retain archived data for One Medical Seniors (formerly Iora Health).  Investigation revealed that an unauthorized person accessed the storage system between June 8 and June 11 2026.  The incident was limited to this external platform and did not impact One Medical’s clinical systems or electronic medical records.  Exposed data include demographic and clinical records for a subset of patients at clinics in Atlanta, Cape Cod, Charlotte, Denver, Houston, Phoenix, Tucson and Seattle.  One Medical immediately revoked system access, rotated credentials and implemented additional safeguards.  A dedicated call centre is available to affected patients.

Why it matters: This breach illustrates that even when core medical systems are secure, archived data stored with third‑party providers can create exposure risks.  The incident affects legacy patient records from Iora Health and highlights the importance of inventorying all repositories—active and archived—that contain PHI.  Organizations acquiring or merging with other providers should evaluate inherited systems for outdated storage platforms or misconfigured vendor services.

Recommended actions:

• Inventory all external storage services used for backups or archives; ensure they meet current security standards and restrict unnecessary access.
• Integrate legacy systems from acquisitions into your enterprise security program; decommission or migrate data from unsupported platforms.
• Require vendors to notify you promptly of suspicious activity and to support forensic investigations.
• Provide breach‑specific notices and call‑centre support for patients; encourage monitoring of medical bills and credit reports for fraud.

Vendor & Supply Chain Risk

Third‑party services are increasingly being exploited to gain a foothold into health‑care networks.  Both NYC H+H and One Medical incidents stemmed from vendor systems.  In addition, the FortiBleed and Splunk vulnerabilities (discussed below) involve widely deployed infrastructure that may be managed by external service providers.

Recommended actions:

• Maintain an updated inventory of vendors that handle PHI or provide mission‑critical IT functions, including storage platforms, network appliances, and telehealth services.
• Incorporate security requirements into contracts (e.g., patch timelines, encryption, multi‑factor authentication, incident reporting) and enforce them through audits.
• Assess vendor adherence to frameworks like NIST SP 800‑53 or the Health Sector Coordinating Council (HSCC) HITRUST CSF; require evidence of third‑party risk assessments.
• Monitor threat‑intelligence feeds for vulnerabilities affecting vendor products (e.g., Splunk and Fortinet) and coordinate patching or mitigation with suppliers.

Cybersecurity & Threat Intelligence

CISA adds Splunk Enterprise Postgres sidecar flaw (CVE‑2026‑20253) to Known Exploited Vulnerabilities Catalog

What happened: The Cybersecurity and Infrastructure Security Agency (CISA) added CVE‑2026‑20253, a critical vulnerability in Splunk Enterprise’s PostgreSQL sidecar service, to its Known Exploited Vulnerabilities (KEV) catalog.  The flaw allows unauthenticated remote attackers to create or truncate files on the host operating system via a PostgreSQL superuser account; Splunk confirmed limited exploitation and released patches.  CISA set a remediation deadline of June 21 2026 for U.S. federal agencies, as required by Binding Operational Directive 22‑01.  Private organizations are urged to update to Splunk Enterprise versions 9.3.1 or 9.2.2 and disable the sidecar service where patches cannot be applied.

Why it matters: Splunk is widely used for security information and event management (SIEM).  Exploitation of this vulnerability could allow attackers to tamper with log files or plant malicious code, severely undermining detection capabilities.  Health‑care entities relying on Splunk for incident monitoring should treat this as a priority.

Recommended actions:

• Identify whether your organization or security operations vendor uses Splunk Enterprise versions 9.2 or 9.3.  If so, apply the patch immediately and verify that the PostgreSQL sidecar service is disabled or properly configured.
• Review SIEM architectures to ensure logs are ingested and stored in a tamper‑resistant manner; consider implementing integrity monitoring on log servers.
• Monitor CISA’s KEV catalog regularly; incorporate KEV remediation timelines into vulnerability‑management programs.
• Conduct tabletop exercises to assess how your organization would detect and respond if an attacker attempted to modify or erase log files.

FortiBleed campaign harvests 110 million credentials from FortiGate firewalls

What happened: SOCRadar researchers detailed an operation dubbed FortiBleed, which targeted over 430 000 FortiGate firewalls worldwide and harvested 110 million credentials.  The attackers exploited misconfigured Fortinet SSL‑VPN devices and weak authentication to capture sensitive data such as admin passwords.  The report describes the operation as financially motivated and notes that some credentials were offered for sale on dark‑web forums.  The campaign demonstrates the risk posed by unmanaged or outdated network appliances.

Why it matters: Fortinet appliances are commonly deployed in hospital and provider networks to facilitate remote access.  Harvested credentials could be used to compromise internal systems or to perform credential‑stuffing attacks against other services.  Because the campaign targets misconfigurations rather than new zero‑day vulnerabilities, health‑care organizations should review their VPN deployments for weak practices.

Recommended actions:

• Audit FortiGate devices to ensure VPN services are running the latest firmware and that any known vulnerabilities are patched.  Disable unused services and enforce strong password policies and multi‑factor authentication.
• Review firewall configuration to ensure that only authorized IP addresses can access SSL‑VPN portals; consider implementing geofencing or IP allow lists.
• Monitor for suspicious authentication activity, such as repeated login attempts or connections from unexpected locations; integrate alerts into SIEM platforms.
• If credentials may have been exposed, reset them and search for overlapping use across other systems to prevent credential‑reuse attacks.

AryStinger malware hijacks 4 300+ outdated routers for reconnaissance

What happened: Researchers discovered a stealthy malware campaign dubbed AryStinger that hijacked more than 4 300 routers—mostly older models made by Linksys and D‑Link—by exploiting years‑old vulnerabilities (CVE‑2013‑3307 and CVE‑2016‑5681).  The routers serve as “executors,” performing scanning and reconnaissance tasks while concealing the operator’s location.  The attackers use the compromised devices to scan networks, exfiltrate data and route malicious traffic.

Why it matters: Many health‑care organizations still rely on consumer‑grade or outdated networking gear in clinics, telehealth sites or remote offices.  Unpatched routers may be commandeered into botnets for reconnaissance or launching attacks.  Because the exploited vulnerabilities date back several years, the campaign underscores the danger of unsupported hardware.

Recommended actions:

• Inventory all routers and network devices across clinics, telehealth sites and home offices; replace or patch any models with known vulnerabilities.
• Disable remote management on routers unless absolutely necessary; if remote access is required, implement strong authentication and restrict by IP address.
• Segment networks to isolate sensitive systems from devices connected via outdated routers; enforce network‑access control to prevent unauthorized devices.
• Include routers and IoT devices in vulnerability‑scanning and patch‑management programs; retire equipment that no longer receives security updates.

Privacy, AI & Digital Health Updates

State‑level AI and privacy initiatives continue gaining momentum

What happened: As reported by RSM’s health‑care industry trend watch, states across the U.S. introduced 250 health AI‑related bills in 2026.  Utah established an Artificial Intelligence Policy Act with a regulatory sandbox to test AI applications under supervision, while California enacted transparency and safety rules for chatbots and Colorado adopted oversight of automated decision‑making technology.  Massachusetts and Georgia explored restrictions and disclosure requirements for AI used in mental health care and insurance coverage decisions.  At the federal level, agencies issued guidance for AI‑powered devices and algorithmic transparency, but comprehensive federal legislation remains absent.

Why it matters: Health‑care organizations developing or procuring AI solutions must navigate a patchwork of state laws addressing chatbots, algorithmic decision‑making, genetic data, and AI use in clinical decisions.  Regulatory sandboxes, like Utah’s, can provide opportunities to test innovations while under oversight.  However, diverging state requirements may increase compliance complexity and the risk of non‑compliance in multi‑state operations.

Recommended actions:

• Establish an AI governance framework that includes inventorying AI systems, documenting use cases, evaluating algorithmic bias and ensuring human oversight.
• Track state legislative developments and adjust policies for chatbot transparency, automated decision‑making disclosures and consumer consent as required.
• Participate in regulatory sandboxes where available to pilot AI tools and gain insights into compliance expectations.
• Collaborate with legal counsel to harmonize AI policies with existing HIPAA, FTC and state privacy laws to avoid conflicting obligations.

Closing Thoughts

This week’s developments highlight a recurring theme: risk management is a continuous process, not a checklist.  OCR’s settlement underscores that ransomware preparedness starts with foundational HIPAA compliance—regular risk assessments, updated policies and workforce training.  At the same time, third‑party breaches at NYC H+H and One Medical remind us that data security is only as strong as the weakest vendor in your ecosystem.  Comprehensive vendor inventories, contract clauses, and due diligence should be part of every compliance program.

On the cybersecurity front, attackers are exploiting misconfigurations (FortiBleed), unpatched services (Splunk), and obsolete hardware (AryStinger) to harvest credentials and conceal their tracks.  Timely patching, configuration reviews and network segmentation remain essential.  Finally, evolving state laws—from Connecticut’s genetic privacy act to AI governance bills—signal that privacy and AI compliance will become even more complex in the coming years.  Building adaptable governance frameworks, integrating privacy‑by‑design into AI, and staying engaged with regulators will help organizations navigate this changing landscape.

As always, please reach out if you have any questions or need support with compliance, risk assessment or vendor management.