(ii) Implementation specification: Response and Reporting (Required).
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; and document security incidents and their outcomes.
Tell Me More:
The Response and Reporting Implementation Specification requires covered entities and business associates to 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; document security incidents and their outcomes; and as of February 17, 2010 report to the patients that their information has been breached. Acquiring effective tools will offer little risk mitigation without a correspondingly effective incident response plan.
The incident response plan establishes procedures to address attacks on the health care entity’s IT infrastructure. The incident response procedures must enable security personnel to identify, mitigate, and recover from malicious computer incidents. §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.” §164.304 further defines system as “an interconnected set of information resources under the same direct management control that shares common functionality. A system normally includes hardware, software, information, data, applications, communications and people.”
Generally, an incident is any event that may compromise the security of a system (operating system, application, database, etc.), a network, or data. An incident need not be real; even the threat of such an event can be considered an incident in many cases. The term “security incident” can include a broad range of topics. Some examples of incidents are: property theft (hardware or software); compromised passwords, tokens, or other means of controlled access to PHI; lost access badge; unauthorized access (physical or logical); unauthorized disclosure of PHI (hardcopy or electronic); unauthorized use of accounts or privileges; tampering with data with malicious intent; misusing PHI; malicious code or virus; hoaxes that cause stress and waste of business resources; hacking (actual or attempted); criminal activity; identity theft; fraud; improper network activity (e.g., probes or network mapping from unknown or unauthorized sources); and denial of service attacks or attempts. Incidents can also be accidental or natural, for example: electrical power outages; hardware failures; human error; and acts of God (e.g., tornados, fire, earthquake, and hurricanes.)
Questions to consider:
- Does the organization have a definition of “security incidents”? Does it meet the requirements of the Security Rule? It may be necessary to redefine what is considered a security incident.
- Are processes or systems in place to identify all security incidents and the impact of those incidents? If not, new processes or systems will need to be implemented.
- Has an emergency communications plan been developed to address how, when and to whom security incidents will be reported? Has someone been appointed to be the primary focal point for all security incidents? Your risk analysis will need to determine not only who this should be, but if there is a need for it to be more than one person. Be sure to address internal and external communications.
- Are processes or systems in place to contain and eradicate problems resulting from security incidents? If not, processes or systems will need to be implemented.
- Does the organization have processes in place to recover from security incidents? Procedures may need to be revised and implemented. Procedures addressing restoration, validation and monitoring of systems impacted by an incident all need to be addressed in your procedures. (See Standard: Contingency Plan)