What are the HIPAA Security Rule Incident Response and Reporting Requirments?

DISCLAIMER: The information provided in this article, other knowledge base articles, and the Compliancy Group website do not, and are not intended to, constitute legal advice. All information, content, and materials in the Knowledge Base and on the Compliancy Group website are for general informational purposes only.

Introduction

The HIPAA Security Rule contains a "security incident procedures" requirement. Under this requirement, covered entities and business associates must implement policies and procedures to address security incidents.

To implement this rule, covered entities and business associates must identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity or business associate; and document security incidents and their outcomes.

What is a Security Incident?

The HIPAA 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."

How Do Covered Entities and Business Associates Address Security Incidents?

The Security Incident Procedures standard at 45 CFR § 164.308(a)(6)(i) requires covered entities and business associates to implement policies and procedures to address security incidents. Addressing security incidents includes identifying and responding to them.

How Can Covered Entities and Business Associates Identify Security Incidents?

How can an entity identify security incidents? One way to identify a security incident is to rely upon the information gathered in complying with the other Security Rule standards, particularly, information gathered as a result of performing a risk analysis. Performing a risk analysis requires covered entities and business associates to "Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the [organization]."

An example of an assessment of risks and vulnerabilities involves determining whether an entity has audit controls in place, and whether those audit controls are working effectively. Audit controls are hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

Having audit controls in place allows an entity to examine user activity. Through examining user activity, an entity can determine if there has been unauthorized access to the network. Recall that a security incident is defined as "the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system." Risk analysis reveals whether audit controls are in place. Audit controls reveal instances of unauthorized access. Unauthorized access, by definition, is a security incident. So, by performing a risk analysis, an organization can identify security incidents.

How Can Covered Entities and Business Associates Respond to Security Incidents?

Once an organization identifies a security incident, the security incident procedures standard requires the entity to respond to the incident. Different incidents may require different responses.

If, for example, an employee is found to have engaged in repeated unauthorized access, disciplinary action and/or termination of access privileges may be appropriate.

A security incident can also consist of an unauthorized disclosure of PHI that constitutes a breach of unsecured PHI. To make the determination of whether a breach of unsecured PHI has occurred, an organization must follow its breach determination procedure.

To ensure an appropriate and effective response to a security incident, covered entities and business associates should also have policies and procedures that address how incidents are to be documented and reported; what information should be contained in the documentation; how often and to whom should incidents be reported; what are the appropriate responses to particular types of incidents; and how to document outcomes.

How Do Covered Entities and Business Associates Mitigate the Harmful Effects of Security Incidents?

The Security Incident Procedures standard at 45 CFR § 164.308(a)(6)(i) requires covered entities and business associates to implement policies and procedures to address security incidents. Addressing security incidents includes mitigating the harmful effects of security incidents, to the extent practicable, that are known to a covered entity or a business associate.

Different incidents may call for different mitigation steps. Mitigation steps may not be needed if a security incident did not cause harmful effects. For example, an entity may decide that a “ping” (a request-response utility used to determine whether a specific Internet Protocol (IP) address, or host, exists or is accessible) on its network initiated from an external source would require the following actions to comply with the standard; (1) minimal, if any, response; (2) no mitigation actions since no harmful effects were caused by the incident; and (3) brief documentation of the security incident and outcome, such as a recording of aggregate statistical information.

Mitigating the harmful effects of a ransomware attack, in contrast, may require taking one or more of the following measures: 

1. Establishing routine network backups and updates.
2. Review of available ports, protocols, and services required to support business operations.
3. Improving password hygiene.
4. Enhancing endpoint security.
5. Implementing an intrusion detection system.

Are All Security Incidents Harmful?

Not necessarily. Recall the definition of "security incident": "The attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system." Unsuccessful attempts to access, use, disclose, modify, or destroy PHI can cause no harm, but by definition are still "incidents." The language of the security incident procedures standard requires covered entities and business associates to document all security incidents and their outcomes – even if the incident results in no harmful effects (e.g. a pattern of pings from an external source).