In 2023, OCR settled with a healthcare system for $1.3 million after investigators found the organization had no process for identifying or responding to security incidents — even though it had experienced multiple unauthorized access events over a two-year span. The root cause wasn't a lack of technology. It was a fundamental misunderstanding of the HIPAA security incident definition and the obligations that flow from it.

This confusion isn't rare. Healthcare organizations consistently struggle to distinguish a security incident from a breach, and that gap creates serious compliance exposure under the Security Rule.

The HIPAA Security Incident Definition Under the Security Rule

The Security Rule at 45 CFR § 164.304 defines a security incident as "the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system." That definition is deceptively broad — and intentionally so.

Notice the word "attempted." Under this HIPAA security incident definition, your organization doesn't need a confirmed compromise of protected health information to trigger obligations. A failed login attempt from an unauthorized source, a phishing email opened by a workforce member, or a misconfigured firewall that briefly exposed a server can all qualify.

OCR has made clear in guidance documents that covered entities and business associates must treat this definition seriously, not as a technicality to minimize.

Security Incident vs. Breach: A Critical Distinction Your Team Must Understand

One of the most dangerous compliance mistakes I see is treating "security incident" and "breach" as interchangeable. They are not.

A breach, defined under the Breach Notification Rule at 45 CFR § 164.402, is an impermissible use or disclosure of PHI that compromises the security or privacy of that information. A breach is always a security incident — but a security incident is not always a breach.

Think of it this way: every security incident requires an internal investigation. Only those incidents that result in an actual unauthorized acquisition, access, use, or disclosure of protected health information — and that fail the four-factor risk assessment — escalate to breach notification obligations.

Your workforce needs to understand this distinction clearly. When staff can't differentiate between the two, incidents go unreported, investigations never happen, and your organization's exposure compounds silently.

What the Security Rule Requires When an Incident Occurs

The Security Rule's incident response requirement lives at 45 CFR § 164.308(a)(6). It mandates two specific implementation specifications:

  • Response and Reporting (Required): Your covered entity or business associate must identify and respond to suspected or known security incidents, mitigate harmful effects to the extent practicable, and document the incidents and their outcomes.
  • Ongoing Documentation: Every incident — including attempted unauthorized access — must be logged. OCR investigators will ask for these records during audits and complaint investigations.

In my work with covered entities, the most common deficiency is not the absence of a policy, but the absence of a functioning process. Organizations write an incident response plan during their initial risk analysis and then never operationalize it. Staff don't know how to report. Logs aren't reviewed. There's no escalation pathway.

Build an Incident Response Workflow That Actually Works

A compliant incident response process requires at minimum:

  • A clear reporting channel — every workforce member should know exactly who to notify and how.
  • Defined roles for investigation, containment, and mitigation.
  • A documentation protocol that captures timelines, individuals involved, PHI affected (if any), and remediation steps.
  • A decision tree for escalating from security incident to breach risk assessment under 45 CFR § 164.402.

Without these components, you're not meeting the standard — regardless of what your policy manual says.

Why the "Attempted" Standard Catches Organizations Off Guard

The inclusion of "attempted" access in the HIPAA security incident definition is where most organizations underperform. Logging failed login attempts, tracking unauthorized scanning of network ports, and flagging suspicious email activity all fall within scope.

OCR does not expect you to individually investigate every automated bot attempt against your systems. The agency acknowledged in early guidance that covered entities should implement reasonable incident response procedures scaled to their environment. But "reasonable" still means your organization has a documented rationale for how it triages and categorizes incidents — especially attempted ones.

If your risk analysis hasn't addressed how your organization handles attempted unauthorized access, it's incomplete.

The Workforce Training Requirement Most Organizations Underestimate

Your incident response plan is only as strong as your workforce's ability to execute it. Under 45 CFR § 164.308(a)(5), the Security Rule requires security awareness and training for all workforce members, and incident identification is a core component of that training.

Staff who handle electronic PHI daily — from front desk coordinators to IT administrators — must be able to recognize the signs of a security incident and know exactly how to report it. A delayed report of even a few days can transform a manageable incident into a reportable breach.

Investing in comprehensive HIPAA training and certification ensures your workforce understands both the HIPAA security incident definition and their specific role in the response chain. Generic annual training slides won't meet this standard.

Tie Your Incident Response Plan to Your Risk Analysis

Your security incident procedures should not exist in a vacuum. They must be informed by and integrated with your organization's risk analysis under 45 CFR § 164.308(a)(1). The threats you identify during your risk analysis — unauthorized access by insiders, ransomware, lost devices containing ePHI — should directly shape the scenarios your incident response plan addresses.

OCR enforcement actions consistently cite organizations that had separate, disconnected compliance documents. Your risk analysis identifies the threats. Your incident response plan operationalizes the response. Your workforce training ensures execution. These three elements must function as a system.

Don't Wait for an OCR Investigation to Pressure-Test Your Process

Run tabletop exercises at least annually. Simulate a phishing attack that leads to credential theft. Walk through a lost laptop scenario. Test whether your team follows the reporting chain, documents correctly, and makes the right escalation decisions.

Organizations that proactively stress-test their incident response processes are far better positioned during OCR investigations and significantly less likely to face penalties for willful neglect.

If your organization needs to strengthen its compliance foundation — from understanding the HIPAA security incident definition to building a workforce that can identify and respond to threats — explore the resources at HIPAA Certify for workforce HIPAA compliance. The cost of preparation is always less than the cost of a HIPAA violation discovered too late.