Review of the 2026 OCR HIPAA Security Conference

The 2026 OCR HIPAA Security Conference focused on the growing connection between HIPAA compliance, cybersecurity, patient safety, third-party risk, ransomware, medical device security, and artificial intelligence governance. The Safeguarding Health Information: Building Assurance through HIPAA Security 2026 conference took place at the start of September 2026 at the NIST campus in Gaithersburg, Maryland. The event was co-hosted by the U.S. Department of Health and Human Services Office for Civil Rights and the National Institute of Standards and Technology.

The conference provided healthcare organizations with an indication of the security risks receiving attention from federal agencies and the safeguards organizations should be examining. A recurring theme was that HIPAA compliance cannot be separated from the systems, vendors, devices, and technologies that create, receive, maintain, or transmit electronic protected health information.

Healthcare Cyberattacks Remain a Major HIPAA Risk

The conference reviewed healthcare breach data and the continuing role of hacking in large healthcare data breaches. The number of people affected by breaches can fluctuate substantially from year to year because a small number of incidents can affect tens of millions of individuals.

Attack methods provide another measure of the threat. Hacking accounted for approximately 75 percent of healthcare breaches in the data presented at the conference, while network servers and email represented approximately 88 percent of breach locations.

These figures connect HIPAA compliance directly with cybersecurity controls. Policies and HIPAA training remain components of a compliance program, but organizations also need to address email security, network security, access controls, encryption, backups, authentication, system vulnerabilities, and third-party access.

OCR Continues to Focus on Risk Analysis and Risk Management

Risk analysis and risk management received substantial attention during the conference. OCR enforcement activity has repeatedly identified failures involving the assessment and management of risks to electronic protected health information.

A completed security risk analysis is not the end of the process. The findings should create a working remediation plan that identifies weaknesses and assigns actions to address them.

Examples include unsupported systems, missing multifactor authentication, excessive user permissions, unencrypted devices, vendor weaknesses, and deficiencies in security controls. Some issues can be corrected quickly, while others require budget decisions, system changes, vendor involvement, or replacement projects.

The risk management process therefore continues after the assessment has been completed. Organizations need to track identified risks and document the measures taken to reduce them.

Risk Analysis Should Follow the ePHI

One practical approach discussed at the conference was to follow electronic protected health information through the organization. The assessment should identify where ePHI is located, how it moves between systems, how it leaves the organization, who can access it, and which external organizations interact with it.

This approach can identify risks that are missed when an assessment concentrates primarily on servers and workstations. ePHI can move through email, file transfers, APIs, collaboration platforms, cloud applications, medical devices, fax systems, mobile devices, and vendor platforms.

The assessment also needs to consider encryption and access. Organizations need to know where information is stored without encryption, where it is transmitted, which accounts can access it, and where unauthorized access or disclosure could occur.

Third-Party Risk Extends Beyond the Business Associate Agreement

Third-party risk was a recurring subject throughout the conference. Healthcare organizations depend on external companies for hosting, communications, billing, claims processing, software, data storage, medical technology, artificial intelligence, and other services.

A Business Associate Agreement does not establish that a vendor presents an acceptable security or operational risk. Organizations also need to understand what information a vendor handles, where that information is located, how it is secured, and what happens when the vendor experiences an outage or cyberattack.

The Change Healthcare cyberattack was discussed as an example of the consequences of concentrated third-party dependence. A security incident affecting one organization can disrupt healthcare operations across a large number of Covered Entities and Business Associates.

Vendor Failure Is Also a Business Continuity Risk

Vendor management should address availability as well as confidentiality and security. An organization can experience serious disruption even when a vendor failure does not expose PHI.

Healthcare organizations should identify the vendors on which their operations depend and determine what happens if those services become unavailable. This includes considering whether data can be recovered, whether another system can perform the function, and how long operations can continue without the vendor.

This issue also applies to artificial intelligence vendors. The AI market contains companies and products that may change ownership, discontinue services, or cease operating. Organizations using those services need to know how their information can be retrieved and whether operations can continue without the platform.

Cybersecurity Incidents Can Become Patient Safety Incidents

One of the broader points from the conference was that healthcare cybersecurity is directly connected to patient safety. A cyberattack does not need to alter a medical record to affect patient care.

System outages can prevent clinicians from accessing medical records, interrupt diagnostic services, delay procedures, divert patients, and prevent healthcare organizations from performing normal operations. Dependence on cloud infrastructure creates another source of operational risk when healthcare systems rely on external platforms that become unavailable.

Cybersecurity planning therefore needs to account for the clinical and operational consequences of system failure. An incident response plan that addresses only data breach notification does not address the full effect of a major healthcare cyberattack.

Medical Devices Require Lifecycle Security Management

Connected medical devices create a substantial security management problem because healthcare organizations can operate thousands of devices across multiple locations and clinical functions. The conference addressed the number of connected devices in hospitals and the continued use of equipment operating on legacy systems.

Older medical equipment can be difficult or impossible to patch. A manufacturer may stop supporting the device or the operating system on which it depends. Known vulnerabilities can remain available to attackers after security updates have stopped.

Organizations therefore need inventories that identify devices, operating systems, support status, network connections, data storage, and replacement requirements. End-of-life planning should form part of medical device security management.

Used and Retired Medical Equipment Can Still Contain PHI

Medical equipment also creates a data disposal issue. Devices can retain patient information after they have been removed from clinical use.

The podcast accompanying the conference review described an example involving used ultrasound equipment that still contained patient data when purchased. The example illustrates why equipment disposal, resale, return, and replacement procedures need to account for stored information.

Organizations need to determine whether device memory or storage contains ePHI and how that information will be securely removed. Depending on the equipment and storage technology, this can involve data sanitization or physical destruction of storage media.

Security Awareness Training Needs to Reflect Current Attack Methods

Security awareness cannot remain fixed while social engineering techniques change. The conference addressed QR code phishing, sometimes called quishing, and techniques that use fake system messages to persuade users to execute malicious instructions.

QR codes create a particular awareness problem because users cannot normally determine the destination by looking at the code. A malicious QR code can move an attack from a controlled organizational computer to an employee’s mobile device.

Workforce security awareness programs should therefore be reviewed as attack techniques change. Repeating the same phishing examples each year can leave employees unfamiliar with newer methods of obtaining credentials or introducing malicious software.

Artificial Intelligence Does Not Create an Exception to HIPAA

The introduction of artificial intelligence does not remove existing HIPAA obligations when the technology creates, receives, maintains, or transmits PHI. Organizations still need to consider risk analysis, access controls, vendor management, Business Associate Agreements, and other applicable HIPAA requirements.

The conference discussion did not present AI solely as a threat. AI can improve healthcare administrative processes, including claims processing and other repetitive functions. The compliance issue is how the technology is selected, governed, monitored, and integrated into existing systems.

Healthcare Organizations Need an AI Inventory

An AI inventory provides a practical starting point for AI governance. Organizations need to know which AI tools are being used before they can assess the risks associated with them.

The inventory can identify the AI product, its business purpose, the information it receives, the people using it, the person or function that approved it, the vendor’s data retention practices, and whether its output receives human review before affecting consequential decisions.

AI should also be included in third-party vendor management. This prevents AI applications from developing into a separate category of technology that bypasses established procurement, privacy, security, and vendor assessment procedures.

The NIST AI Risk Management Framework Provides a Governance Structure

The NIST AI Risk Management Framework was identified as a framework healthcare organizations can use to structure AI governance. Its four functions are Govern, Map, Measure, and Manage.

Govern establishes responsibility for AI oversight. Map identifies where and how AI is being used. Measure assesses the risks created by those uses. Manage addresses how identified risks will be handled.

This structure can be applied to organizations using multiple AI systems or to an organization using a single AI application. The number of tools does not remove the need to identify ownership, data use, risk, and controls.

Agentic AI Creates Additional Data Flow and Access Questions

Agentic AI creates additional governance issues because an AI system may interact with other applications, websites, data sources, and credentials without an employee manually performing each action. Understanding the initial AI application is therefore not sufficient when the application can initiate additional activities.

Organizations need to identify which systems an AI agent can reach, which credentials it can use, what information it can retrieve, where information can be transmitted, and which external services it can contact.

Human review also remains relevant where AI-generated output affects consequential decisions. Automated output should not automatically be treated as accurate merely because the process operates without direct human involvement.

Incident Response Plans Need to Be Tested

Having an incident response or downtime plan does not establish that the plan will work during an actual cyberattack. Healthcare organizations need to test whether employees understand their responsibilities and whether alternative processes function when normal systems are unavailable.

Testing can identify dependencies that were not apparent when the plan was written. A downtime procedure may itself depend on an unavailable system, vendor, communication service, credential, or data source.

The same principle applies to backups and disaster recovery. Organizations need to determine whether data can actually be restored and whether restored systems can support the operations required during recovery.

HIPAA Compliance, Cybersecurity, and AI Governance Are Converging

The conference presented HIPAA compliance, cybersecurity, and AI governance as connected risk management activities rather than independent programs. Electronic protected health information moves through networks, cloud services, medical devices, vendors, communication platforms, and AI systems, making separation increasingly difficult in operational practice.

A security risk analysis provides a common starting point. Organizations can identify where ePHI exists, examine the technologies and vendors that interact with it, assess the associated risks, establish safeguards, and document remediation.

The practical message from the 2026 OCR HIPAA Security Conference was not limited to adopting additional security technology. Healthcare organizations need to know where their information is located, who and what can access it, which third parties depend on it, what happens when systems fail, and whether identified risks are actually being managed.