Most dental practices know what a HIPAA breach is. But HIPAA defines a separate category called a security incident. Every practice must have procedures for identifying, responding to, and documenting these incidents. That applies even when no breach occurs.
Most dental teams have never been trained on the difference. Here is what you need to know about security incidents, how they differ from breaches, and what your practice must do when one happens.

The HIPAA Security Rule defines a security incident broadly. It covers any attempted or successful unauthorized access to information in a health IT system. Importantly, the definition also includes interference with system operations. The rule casts a wide net on purpose.
A security incident does not require stolen patient data. For instance, a failed login attempt counts. So does a staff member accessing a record they should not have. Similarly, malware detected on a workstation qualifies as an incident, even if nothing was taken.
A HIPAA breach is a specific type of security incident. It occurs when unsecured PHI is acquired, accessed, or disclosed in a way the Privacy Rule does not permit. Not every incident rises to that level.
For example, a failed ransomware attack stopped before encrypting files is an incident but may not be a reportable breach. Likewise, a staff member who opened a phishing email without clicking a link triggers an incident but likely not a breach. The distinction matters because the response requirements differ significantly.
When a security incident involves a potential disclosure of PHI, HIPAA requires a four-factor risk assessment to determine whether the incident constitutes a reportable breach. The four factors are: the nature and extent of the PHI involved, the identity of who accessed or could have accessed it, whether the PHI was actually acquired or viewed, and the extent to which the risk to the PHI has been mitigated.
If this assessment cannot demonstrate a low probability that PHI was compromised, the incident must be treated as a breach and handled accordingly.

A staff member receives an email designed to look like a trusted sender and either clicks a link or opens an attachment. Even if no credentials were entered, this is a security incident that must be documented. If credentials were entered on a fake login page, the incident must be assessed as a potential breach.
Ransomware detected on a workstation is always a security incident. Depending on whether patient data was encrypted or exfiltrated before the malware was contained, it may also be a reportable breach. Ransomware incidents require immediate containment, documentation, and a thorough forensic investigation.
A staff member accessing a patient record they have no treatment relationship with is a security incident. HIPAA requires access controls and audit logging specifically so these incidents can be detected and investigated.
A lost laptop, phone, or USB drive that contains or could access patient data is a security incident. If the device was not encrypted, it is likely a reportable breach. If the device was encrypted and the data is inaccessible, it may qualify for the safe harbor exception to breach reporting.
No. Only incidents that meet the definition of a reportable breach require notification to HHS, affected patients, and in some cases the media. All security incidents must be documented internally regardless of whether they are reportable. This documentation demonstrates that your practice has active incident management procedures in place.
HIPAA requires breach notification to affected patients and HHS within 60 days of discovering the breach. If more than 500 patients in a state are affected, media notification in that state is also required within 60 days. Delays in notification are treated as separate violations and have resulted in significant fines for dental practices.
HIPAA requires documentation of security incidents and their outcomes. This includes the date of the incident, how it was discovered, what PHI was involved, the results of the four-factor breach risk assessment, and what actions were taken in response. This documentation must be retained for six years.
Yes. Ekim IT Solutions provides incident response support for dental practices including containment, forensic investigation, documentation, and remediation. We serve practices across all 50 states remotely and provide on-site support in New England and New York. We also help practices build documented incident response procedures before an incident occurs so the response is coordinated rather than reactive.
Ekim IT Solutions works exclusively with dental practices. We serve New England and New York with on-site support and dental practices nationwide with remote support. Security, compliance, and everything in between so you can focus on patients.
Schedule a Fit Call: Find out in 15 minutes if we are the right fit for your practice.