AI Agent Conducts First Fully Autonomous Ransomware Attack

Posted by Steve Alder

Researchers have identified what they believe to be the first agentic ransomware attack. An autonomous large language model (LLM) agent conducted an entire attack without human involvement, including vulnerability exploitation, credential theft, lateral movement and file encryption.

The attack was identified by researchers at the cloud security company Sysdig, who linked the attack to the JadePuffer ransomware operation. JadePuffer used a fully autonomous AI agent to conduct reconnaissance on the targeted company, exploit a vulnerability (CVE-2025-3248), steal credentials, move laterally within the victim’s network, establish persistence, escalate privileges, encrypt data, and drop a ransom note, adapting to failures on the fly without human intervention.

The vulnerability exploited for initial access was an unauthenticated remote code execution vulnerability in the Langflow open source framework. The researchers explained that this is an attractive entry point as Langflow servers are AI-adjacent, often hold provider API keys and cloud credentials, and are commonly stood up quickly without network controls. While a patch had been issued to fix the vulnerability on April 1, 2025, and the flaw was known to be actively exploited, the vulnerability had not been patched.

The AI agent was able to adjust its approach in a similar way to a human attacker. For instance, when an API request returned XML instead of JSON, the next payload adjusted its parsing logic accordingly, and when certain steps failed, the AI agent retried those steps using refined parameters. “In one sequence, it went from a failed login to a working fix in 31 seconds,” explained the researchers.

The AI agent gained access to a production MySQL server running Alibaba Nacos by exploiting a 2021 authentication bypass vulnerability, then encrypted all 1,342 Nacos service configuration items and deleted the originals. The AES encryption key was not transmitted to the attacker’s infrastructure, so even if the ransom was paid, recovery would not have been possible.

According to a recent statement from the Five Eyes cybersecurity agencies,  advances in artificial intelligence have accelerated the speed, scale, and sophistication of cyber threats. The agencies warned that “frontier AI models are anticipated to exceed current industry expectations, fundamentally transforming both offensive and defensive cyber capabilities. The timeline is not years; it is months.” The Sysdig researchers say the age of agentic threat actors has arrived.

While the attack was fully automated, it did not involve the exploitation of any zero-day vulnerabilities or novel techniques, therefore defending against automated attacks is no different to defending against hands-on- keyboard attacks. As recommended by the Five Eyes agencies, organizations should take steps now to combat threats by reducing their attack surface, accelerating patching processes, addressing legacy systems, reviewing and strengthening identity and access controls, and ensuring they develop and test incident response plans, which should be focused on fast containment and recovery.

The post AI Agent Conducts First Fully Autonomous Ransomware Attack appeared first on The HIPAA Journal.

Almost 30,000 Texas Residents Affected by Data Breach at The Texas Hearing Institute

Posted by Steve Alder

The Texas Hearing Institute has notified the Texas Attorney General about a data breach impacting more than 29, 000 state residents. Data breaches have also been announced by Family Health Centers of Southern Indiana, the Wisconsin Department of Health Services, and Stephen W. Brown & Radiology Associates of Augusta.

Texas Hearing Institute

The Texas Hearing Institute, a pediatric hearing center in Houston, Texas, has started notifying at least 29,498 individuals about a March 2026 cyberattack that resulted in unauthorized access to its network and the exposure of patients’ personal and health data.

Unauthorized network access was identified on March 20, 2026, and immediate steps were taken to contain the incident and secure its systems. Assisted by third-party digital forensics experts, the Texas Hearing Institute determined on April 22, 2026, that there had been unauthorized access to personal information on its systems. The data review confirmed that names, Social Security numbers, financial information, and medical records were compromised in the incident.

The affected individuals have been offered 24 months of complimentary credit monitoring and identity theft protection services. While the notification letters do not provide further information about the nature of the attack, this appears to have been a ransomware incident. The interlock ransomware group added the Texas Hearing Institute to its dark web data leak site in early April, claiming to have stolen 540 gigabytes of data. As such, the affected individuals should ensure that they take advantage of the free identity theft protection services being offered. The Texas Attorney General was informed that 29,498 Texas residents were affected. It is currently unclear how many individuals were affected in total.

Family Health Centers of Southern Indiana

Family Health Centers of Southern Indiana, a network of health centers in Jeffersonville, New Albany, Corydon, and Clarksville in Indiana, announced a data security incident on June 22, 2026, that may have resulted in unauthorized access to patient data.

Unauthorized network activity was identified on or around January 16, 2026. Its incident response plan was immediately initiated, and an investigation was launched to determine the nature and scope of the activity. The investigation confirmed that an unauthorized third party had access to parts of its network containing patient data, including names, dates of birth, contact information, demographic information, Social Security numbers, medical information, and health insurance information.

Family Health Centers of Southern Indiana has implemented additional technical safeguards, enhanced security measures, and updated its procedures related to data privacy and security. Complimentary credit monitoring and identity theft protection services have been offered to individuals whose Social Security numbers were involved.

The data breach is not yet shown on the HHS’ Office for Civil Rights website; however, the Indiana Attorney General was informed that the protected health information of 7,037 Indiana residents was compromised in the incident. The Termine threat group took responsibility for the incident and added Family Health Centers of Southern Indiana to its dark web data leak site, including samples of the stolen data. The group claims to have exfiltrated around 250 gigabytes of data.

Stephen W. Brown & Radiology Associates of Augusta

Stephen W. Brown & Radiology Associates of Augusta have been affected by a data breach at their third-party billing vendor, MCBS, LLC. MCBS was provided with patient information as part of its contracted duties, and discovered on or around September 26, 2025, that an unauthorized third party had gained access to systems containing that information.

After an extensive forensic analysis, MCBS determined that its systems were accessed by an unauthorized third party between September 22 and September 26, 2025. Individuals affected by the incident may have had some or all of the following data stolen in the incident: name, address, date of birth, Social Security number, diagnosis, treatment information, mental or physical condition, medical history, health plan beneficiary number, health insurance policy number/subscriber identification number, and other health insurance information.

MCBS said it is unaware of any misuse of the affected data; however, as a precaution, the affected individuals have been offered complimentary credit monitoring and identity theft protection services for 12 months. It is currently unclear how many patients of Stephen W. Brown & Radiology Associates of Augusta have been affected, or how many individuals were affected in total.

Wisconsin Department of Health Services

The Wisconsin Department of Health Services has recently reported a HIPAA breach to the HHS’ Office for Civil Rights that involved unauthorized access to the protected health information of 8,157 individuals. The affected individuals were Medicaid recipients who received benefits from the Wisconsin Supplementary Security Income program.

Letters were mailed to those individuals that contained personal and private information regarding an increase in their benefits. Some of those letters were inadvertently sent to outdated addresses. The error was identified on April 30, 2026, and further mailings to the incorrect addresses have been prevented. Up to 8,157 individuals were affected and have now been notified that their information may have been accessed by unauthorized individuals as a result of the error. Complimentary credit monitoring services have been offered to those individuals for 12 months.

The post Almost 30,000 Texas Residents Affected by Data Breach at The Texas Hearing Institute appeared first on The HIPAA Journal.

What is a HIPAA Audit Checklist?

Posted by Steve Alder

A HIPAA audit checklist is a document covered entities and business associates should use to audit compliance with the standards of the HIPAA Administrative Simplification Regulations applicable to their operations.

HIPAA Audit ChecklistAn internal HIPAA audit checklist differs from an external HIPAA audit checklist inasmuch as an external HIPAA audit checklist is designed to meet specific criteria of the OCR audit protocol, CMS’ compliance review program, or a third-party’s certification requirements.

By comparison, an internal HIPAA audit checklist is a comprehensive document that covers all areas of an organization’s compliance obligations. However, as different organizations have different compliance obligations, there is no “one-size-fits-all” internal HIPAA audit checklist.

Covered entities and business associates should review the following content, determine which standards of the HIPAA Administrative Simplification Regulations apply to their operations, and develop a HIPAA internal audit checklist that meets their requirements. The checklist should then be used as a HIPAA compliance audit checklist to identify gaps in compliance and implement measures to fill gaps.

hipaa audit checklist - thehipaajournal.com

Administrative Requirements Audit Checklist

The Administrative Requirements of HIPAA (Part 162) cover areas such as Unique Health Identifiers, Transaction Rules, and Code Set Standards. Covered entities that conduct claims processing or administration in-house, and business associates that provide billing and claims management services for covered entities, are required to comply with the standards of this Part.

Generally, there are only three areas of compliance organizations may need to include on an internal HIPAA audit checklist – the operating rules, the transaction rules, and documentation.

  • Verify compliance with the operating rules for eligibility, claims status, and electronic funds transfer/remittance advice.
  • Test transactions for compliance using the Administrative Simplification Enforcement and Testing Tool (ASETT).
  • Document policies, procedures, and test results for when the documentation is required for a compliance review.

While violations of the Administrative Requirements have never yet resulted in a civil monetary penalty, CMS has the authority to fine covered entities and business associates for noncompliance with Part 162 if an organization fails a CMS HIPAA audit and subsequently fails to comply with a corrective action plan. In the year to May 2023, 51% of organizations failed compliance reviews and were issued with a corrective action plan. (Reports for 2024 and 2025 have not been published).

HIPAA Privacy Rule Audit Checklist

The HIPAA Privacy Rule only has two basic HIPAA audit requirements – to protect individually identifiable health information from impermissible uses and disclosures, and to give individuals rights over their protected health information. To comply with these two requirements, organizations subject to the HIPAA Privacy Rule must comply with up to fourteen sets of standards depending on the nature of their operations.

Why “up to” fourteen? This is because, while all covered entities are required to comply with the HIPAA Privacy Rule, some standards do not apply to all types of organizations – for example, some standards apply to only health plans. Some business associates may be required to comply with specific HIPAA Privacy Rule standards depending on the service being provided for or on behalf of a covered entity and/or on the terms of their Business Associate Agreement with the covered entity.

All organizations subject to HIPAA compliance should review the following list, determine which applies to their operations, and add the relevant items to a HIPAA compliance audit checklist.

1. Designate a HIPAA Privacy Officer

Although most organizations will be familiar with this requirement, it is essential a member of the workforce is designated the role of Privacy Officer to be the point of contact for patients/plan members, workforce members, and regulatory agencies. The HIPAA Privacy Officer also has the responsibility to develop and implement HIPAA-compliant policies and procedures.

2. Understand What Constitutes PHI

There is a lot of misunderstanding about PHI, due to which some organizations can be unnecessarily overprotective with data, while others can be a little too carefree. Not only is it important to understand what constitutes PHI; but, for the sake of security and efficiency, to develop procedures for securing PHI in the minimum number of designated record sets practical.

3. Permissible Uses and Disclosures

Make sure all members of your organization´s workforce understand the difference between required, permissible, and attestable uses and disclosures of PHI, uses and disclosures of PHI for which an individual should be given an opportunity to consent or object, and uses and disclosures of PHI for which an individual´s written HIPAA authorization is required.

4. Procedures for Obtaining Authorizations

Every covered entity should have procedures for obtaining and managing authorizations so that if an individual exercises the right to revoke an authorization, the revocation can be actioned without delay. Procedures should also exist for (for example) withdrawing any information about the patient that has been used in fundraising or marketing material.

5. Notices of Privacy Practices

Every patient or plan member must be given a Notice of Privacy Practices when first attending a healthcare facility or enrolling in a health plan. The Notice must contain details of how PHI may be used or disclosed without an authorization, when it may only be used with the individual´s authorization, the rights of the individual to request privacy protection or copies of PHI.

6. Procedures for Responding to Requests for Privacy Protection

Individuals have the right to request restrictions on certain uses and disclosures – which can be situation-specific – and request to restrict how they are contacted by a covered entity or business associate. Organizations must have procedures in place to respond to requests for privacy protection, manage requests, and document oral terminations of requests.

7. Procedures for Responding to Requests for Access, Correction, and Transfer

The failure to provide access to health information, correct it when necessary, and transfer it to other providers when requested is one of the leading causes of complaints to HHS’ Office for Civil Rights. In an attempt to reduce the number of complaints, the agency is increasing its enforcement action against organizations that fail to respond to requests in a timely manner.

8. Procedures for Maintaining an Accounting of Disclosures

Individuals have the right to request an accounting of disclosures of their PHI for the six years prior to the request being made. However, not all disclosures have to be accounted for. It is important that covered entities understand which disclosures have to be accounted for and adopt procedures for maintaining an accounting of disclosures for each individual.

9. Workforce Training

Under the Privacy Rule, the training requirements are limited in scope to members of the workforce to whom HIPAA policies and procedures apply. However, basic HIPAA training should be provided to all members of the workforce in order to mitigate the risk of impermissible disclosures due to a lack of knowledge and reduce the risk of human error.

10. Documentation

Documentation is a requirement of nearly every standard in the HIPAA Privacy Rule, and organizations required to comply with the standards must put procedures in place for documenting policies and procedures, Notices of Privacy Practices, individual authorizations, workforce training, etc., and retaining policies and procedures for at least six years since they were last in force.

Organizations subject to the HIPAA Privacy Rule should also review the General Provisions of Part 164 – a section of the Administrative Simplification Regulations not covered by a “Rule”. These provisions primarily apply to Hybrid Entities, Affiliated Entities, and Organized Health Care Arrangements, and cover restricting access to PHI to only those who are authorized to access it within their roles and safeguarding PHI from non-covered areas of the organization.

HIPAA Security Rule Audit Checklist

Compared to the potential complexity of a HIPAA Privacy Rule audit checklist, a HIPAA Security Rule audit checklist is relatively straightforward. Not only does the HIPAA Security Rule contain far fewer standards than the HIPAA Privacy Rule, but the standards within the HIPAA Security Rule are less open to interpretation. The Security Standards General Rules also allow covered entities and business associates a “flexibility of approach” about how the standards are implemented.

To help organizations compile a HIPAA audit checklist for the HIPAA Security Rule, the Office of the National Coordinator for Health Information Technology (ONC) and HHS’ Office for Civil Rights have jointly produced a HIPAA Security Risk Assessment (SRA) Tool. Organizations can use the tool online or download as an Excel document to fulfill the risk assessment requirements of the Security Rule. However, this tool may not be suitable for all organizations; and before using it, it is advisable to consider the following questions:

1. Has your organization designated a HIPAA Security Officer?

This can be the same person as the HIPAA Privacy Officer but they need to be qualified for the position inasmuch as they have to design, implement, and enforce security policies and procedures. Ideally, it is best to designate this role to a senior member of the IT team.

2. Have you identified from where ePHI originates?

In order to protect ePHI from unauthorized access, disclosure, alteration, or deletion, you have to know from where ePHI originates, where it is maintained, and to where it is transmitted. Effectively, you need to create an audit trail for all ePHI in your organization´s possession.

3. Do you know how users access ePHI?

Before using the ONC/OCR Security Risk Assessment Tool, you need to conduct an inventory of devices used to access ePHI and the media on which it is stored. This not only includes onsite devices and servers, but also devices used to access ePHI remotely.

4. What security software is already in place?

As a covered entity or business associate, you are required to implement measures to mitigate threats from malware, ransomware, and phishing. Many organizations already have security measures – such as email and web filters – in place to mitigate threats.

5. What role-based access controls are already in place?

Similar to the previous item, many organizations already utilize role-based access controls to control what information users can access. It is far easier to adjust existing controls to comply with the Security Rule standards than start from scratch.

6. What other security mechanisms do you already use?

Due to the “flexibility of approach” clause and the fact that some implementation specifications are addressable, it may be possible to comply with many HIPAA Security Rule standards by enforcing the use of existing security mechanisms – i.e., PIN lock, automatic log-off, password managers, etc.

7. What processes already exist for reporting security incidents?

Most organizations should already have processes in place to flag suspect emails, malware, and other anomalies. These are usually sufficient for internal compliance with the HIPAA Security Rule – not forgetting that business associates are required to report all security incidents to covered entities.

8. Does the organization already have a security awareness training program?

The likelihood is that most organizations will have some form of security awareness training, and all that may be necessary for the training to meet the General Requirements of the HIPAA Security Rule (§164.406) is to tweak it to be more HIPAA-centric and ensure the training is documented.

9. Does the organization enforce a scaled sanctions policy?

Enforcing a scaled sanctions policy is an important step toward HIPAA compliance because it serves as a reminder to members of the workforce that minor or repeated violations of HIPAA can have consequences.

10. Does the organization have a contingency or emergency action plan?

Developing a contingency plan for foreseeable emergency events that may threaten the confidentiality, integrity, and availability of ePHI is a requirement of HIPAA. You may need to review the SRA Tool to ensure you have every type of emergency covered.

Although this HIPAA Security Rule HIPAA audit checklist is relatively basic with regards to the questions it asks, it is advisable to start a journey to HIPAA compliance by assuming zero knowledge – rather than assuming an existing degree of knowledge as the SRA Tool does. In addition, when implementing new measures, it is a best practice to test members of the workforce on what information they have absorbed rather than assume they have understood the new measures in one explanation.

HIPAA Audit Log Requirements

Whether you use a HIPAA Security Rule Audit Checklist or the SRA Tool, it is important not to overlook the HIPAA audit log requirements. The HIPAA Security Rule requires covered entities and business associates to implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic Protected Health Information.

Audit logs enable covered entities and business associates to identify risks associated with events such as unauthorized access, impermissible disclosures, application flaws, and suspicious activities. They can also be used to provide forensic evidence following a security incident or data breach so measures can be put in place to prevent a reoccurrence.

The HIPAA Security Rule does not specify what data needs to be collected by audit logs or how frequently logs should be reviewed. HHS also acknowledges that different software solutions and applications record and examine system activity in different ways. For this reason, it can be beneficial for covered entities and business associates to implement HIPAA compliance software that can monitor all system activity and flag issues for further investigation.

Breach Notification Rule Audit Checklist

As business associates are required to notify covered entities of all security incidents (not just those that result in a breach of unsecured ePHI), business associates will need to use a different Breach Notification Rule audit checklist than a covered entity – who can use a HIPAA breach notification tool to determine whether a security incident is reportable or not. However, both Breach Notification Rule audit checklists will share some common items – for example:

  • How did the breach/security incident occur?
  • How has the impact of the breach/security incident been mitigated?
  • What should be done to prevent the breach/security incident from happening again?

It is also the case that procedures should be in place and responsibilities assigned for notifying covered entities of a security incident or for covered entities notifying HHS’ Office for Civil Rights and impacted individuals of a breach of unsecured ePHI. As with all other areas of HIPAA compliance, the procedures, all breaches/security incidents, and their outcomes must be documented and the documentation retained for a minimum of six years.

Advice for Developing and Completing HIPAA Audit Checklists

Integrating every element of HIPAA compliance into a single HIPAA audit checklist can be challenging and – due to the checklist’s comprehensiveness – potentially leave gaps that lead to compliance failures. There are two ways to overcome this challenge. Either divide the HIPAA audit checklist into smaller, more manageable units, or engage the services of a compliance professional to help you with both the development and the completion of the checklist.

One of the advantages of choosing the latter option is that compliance professionals have the experience to assess an existing checklist, determine how much help you need, and provide as much help as necessary to produce an accurate and comprehensive checklist. This approach has the benefit of preventing the scenario in which you are looking for threats that do not exist in standards that do not apply to your organization – saving your time and your organization’s money.

FAQs

What are the HIPAA Administrative Simplification Regulations?

The HIPAA Administrative Simplification Regulations are the “Administrative Data Standards and Other Requirements” that were developed as a result of the passage of HIPAA (Title 45, Subtitle A, Subchapter C of the Code of Federal Regulations).

The Regulations not only include the standards for the Administrative Requirements and the HIPAA Privacy, Security, and Breach Notification Rules, but also the General Administrative Provisions, the General Security and Privacy Provisions, and the Enforcement Rule.

Could CMS issue a civil monetary penalty for noncompliance?

The Centers for Medicare and Medicaid Services (CMS) has the same authority to impose sanctions on noncompliant organizations as HHS’ Office for Civil Rights. In theory, CMS could impose a fine of up to $2,134,831 on a covered entity or business associate who repeatedly failed to comply with the Administrative Requirements due to willful neglect.

Why are business associates required to comply with the Privacy Rule?

The applicability standard of the HIPAA Privacy Rule (§164.104) was amended via the Final Omnibus Rule in 2013 to read “Where provided, the standards, requirements, and implementation specifications adopted under this part [the HIPAA Privacy Rule] apply to a business associate.”

This means that a business associate may need to develop policies and procedures relating to permissible uses and disclosures and for managing access requests if an individual’s ePHI is maintained in a separate designated record set from that of the covered entity.

Does a business associate have to designate a Privacy Officer?

This depends on the nature of the business associate’s operations and the potential for interactions with the public and regulatory authorities. If there is likely to only be minimal interaction, the role of Privacy Officer could be designated to a Security Officer.

What is considered PHI under HIPAA?

This is possibly the most frequently asked question relating to HIPAA compliance because what is considered PHI under HIPAA is complicated – so complicated that we have dedicated a full-page article to answering this question.

Why is the ONC/OCR Security Risk Assessment Tool not suitable for all organizations?

According to the OCR’s website, “the tool’s features make it useful in assisting small and medium-sized health care practices and business associates”. This implies that it is not suitable for health plans, healthcare clearinghouses, and larger organizations.

In addition, the tool assumes a certain level of knowledge and that a number of measures have already been implemented to comply with HIPAA Security Rule standards. If your organization is taking its first steps towards HIPAA compliance, you may find the tool too advanced for your needs.

How might an organization already have role-based access controls in place?

Many organizations use identity and access management services such as Microsoft AD, Okta Lifecycle Management, or Open LDAP (etc.) to control who in the organization has access to systems and databases. These services can often be used to comply with the HIPAA Security Rule access requirements.

What is the difference between a HIPAA compliance audit checklist and a healthcare compliance audit checklist?

The difference between a HIPAA compliance audit checklist and a healthcare compliance audit checklist is that a HIPAA compliance checklist helps organizations audit their compliance with HIPAA, while a healthcare compliance checklist helps organizations audit their compliance with all applicable federal, state, and local regulations related to their healthcare activities (i.e., CMS’ Medicare regulations, OSHA workplace regulations, and state licensing requirements).

What are 3 important components of a HIPAA security audit?

All components of a HIPAA security audit are important. However, the 3 elements of a HIPAA security audit most organizations should focus on include:

  • An inventory and audit trail of ePHI. If you do not know where ePHI originates, where it is stored, how it is used, and how it is disclosed, it will be impossible to implement measures to safeguard the confidentiality, integrity, and availability of health information.
  • The implementation and configuration of software. It is often not sufficient to implement software described as “HIPAA compliant” to comply with the HIPAA Security Rule. The software also has to be configured to mitigate threats to health information.
  • Workforce training and compliance monitoring. All members of the workforce must receive security awareness training even when they do not have access to ePHI. It is also important to monitor compliance with the security awareness training.

The post What is a HIPAA Audit Checklist? appeared first on The HIPAA Journal.

ANCHOR-CI Framework Strengthens Partnerships and Information Sharing to Secure Critical Infrastructure

Posted by Steve Alder

The Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) has announced the formation of the Alliance of National Councils for Homeland Operational Resilience–Critical Infrastructure, or ANCHOR-CI for short. ANCHOR-CI will operate for two years initially but may be extended by DHS Secretary under the authority provided by Section 871 of the Homeland Security Act.

ANCHOR-CI is the successor to the Critical Infrastructure Partnership Advisory Council (CIPAC), which enabled critical infrastructure entities to exchange sensitive information with the federal government about physical and cyber risks. CIPAC was established by the DHS in March 2006 and served as the framework for public collaboration on security for almost two decades, until it was eliminated by then DHS Secretary Kristi Noem in March 2025. There has been no formal framework for government-industry coordination on critical infrastructure cybersecurity for more than a year, and without the legal protections provided by CIPAC or an equivalent framework, some critical infrastructure sectors stopped sharing cybersecurity data with the federal government.

ANCHOR-CI retains the legal protections of CIPAC and creates a new framework to strengthen information sharing and broaden partnerships across government and industry to better secure the nation’s critical infrastructure. “The new and innovative ANCHOR-CI framework will be a game changer in how the public and private sectors collaborate and share information,” said DHS Secretary Markwayne Mullin. “In a rapidly evolving threat environment, ANCHOR-CI will ensure we have the right people in the room working together to keep the critical infrastructure Americans rely on secure and resilient. This is just another example of the partnership needed to confront the threats of today and tomorrow.”

ANCHOR-CI allows the establishment of four council types: critical infrastructure sector councils, cross-sector councils, critical infrastructure industry councils, and regional coordinating councils, which will advise and provide strategic and actionable recommendations to ensure a coordinated national effort to strengthen critical infrastructure cybersecurity. The councils will recruit members from four groups: critical infrastructure owners, operators and their trade associations; federal, state, local, tribal and territorial government agencies; organizations with direct responsibility for cybersecurity and infrastructure resilience; and other private sector entities.

The new framework is more flexible than its predecessor, supports open and candid discussions of sensitive information, strengthens collaboration between the government and industry, and will ensure more critical infrastructure stakeholders participate. One key feature of CIPAC that has been dropped in ANCHOR-CI is liability protection for participants. This was an important feature that allowed executives to discuss incidents in group settings without antitrust or regulatory exposure.

Under the new framework, CISA will approve proposed council members and may appoint additional participants. Under CIPAC, private sector councils chose their own representatives. While some meetings can be opened to the public, sensitive discussions are shielded, as ANCHOR-CI is exempted from the Federal Advisory Committee Act.

Governance of the ANCHOR-CI councils will be managed by the DHS and CISA, and it will be housed by CISA, which will provide the necessary funding and administrative support. The HHS Office of Cybersecurity and Infrastructure Protection (CIP) will work closely with DHS and CISA to advance collaboration and ensure that the Healthcare and Public Health (HPH) sector priorities are elevated.  The ANCHOR-CI councils will help strengthen partnerships within the HPH sector, as well as across interdependent critical infrastructure sectors, including water and communications.

The post ANCHOR-CI Framework Strengthens Partnerships and Information Sharing to Secure Critical Infrastructure appeared first on The HIPAA Journal.

AdaptHealth Reports Material Cybersecurity Incident and Theft of Patient Data

Posted by Steve Alder

AdaptHealth, a publicly traded healthcare company that provides home medical equipment, diabetes supplies, and sleep therapy products, has informed the U.S. Securities and Exchange Commission (SEC) that it is investigating a material cybersecurity incident involving unauthorized access to patient data.

According to the company’s Form 8-K filing, a threat actor contacted the company on June 15, 2026, claiming to have obtained files containing patient data. AdaptHealth launched an investigation, engaged third-party cybersecurity experts, and notified law enforcement. AdaptHealth has determined that certain cloud-based business applications were accessed by the threat actor, including internal patient management systems and document storage platforms. Files containing patients’ personally identifiable information (PII) and protected health information were exfiltrated by the threat actor.

The investigation is ongoing; however, AdaptHealth has determined that the unauthorized access occurred as a result of a response to a social engineering attack on a third-party contractor, which allowed the contractor’s credentials to be obtained. The threat actor obtained a stored password file tied to insurance billing and access to external electronic health record portals.

The affected account has been disabled, credentials have been reset, and additional access controls have been implemented. The incident has not had an impact on its operations or patient services, and a review is ongoing to determine the extent of data theft. The types of data involved have yet to be determined, and the number of affected individuals is currently unknown. AdaptHealth said it does not collect patients’ Social Security numbers, and financial account information and payment card information are not stored in the compromised systems.

AdaptHealth said it considers this to be a material cybersecurity incident due to the nature and potential volume of data at risk. The financial impact of the incident is still being assessed, with the company potentially having to cover costs associated with forensics, breach notification, legal and regulatory responses, and any remediation measures. The company holds a cybersecurity insurance policy, which may cover certain losses associated with the incident.

While AdaptHealth has not named the threat actor behind the attack, this appears to have been a data theft and extortion attempt by the ShinyHunters threat group. ShinyHunters added AdaptHealth to its data leak site and has threatened to leak the stolen data if the ransom is not paid, giving the company a final warning to pay or face a data leak.

The post AdaptHealth Reports Material Cybersecurity Incident and Theft of Patient Data appeared first on The HIPAA Journal.