Security Incident Procedures Response and Reporting: What to Do and How to Do It

This is the sixth Administrative Safeguard Standard of the HIPAA Administrative Simplification Security Rule. This is its one implementation specification, Response and Reporting, which is required for compliance. As we have noted in earlier postings, with enactment of the American Recovery and Reinvestment Act of 2009 (“ARRA”) on February 17, 2009, business associates also will be required to comply with the Security Rule standards, effective February 17, 2010.

What to Do

This standard requires that the covered entity implement response and reporting policies to address security incidents. 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.” [68 Federal Register 8376]  As a covered entity, you are required to identify, respond to, and to mitigate any harmful effects of security incidents, and to document the incidents, actions taken, and outcomes.

How to Do It

The covered entity’s Security Official is responsible for identifying, containing, mitigating, and documenting a security incident. A security incident might be leaving electronic protected health information on a computer that is donated to a local organization. The Security Official would determine the extent of the damage that occurred if the electronic protected health information were accessed by unauthorized persons, and implement measures to mitigate the damage, such as immediately recovering the computer. The Privacy Official, if different from the Security Official, may be called in to help mitigate the breach, as a security incident is called in the Privacy Rule, if the breach results in an unauthorized disclosure of electronic protected health information.

Another example of a security incident could be the destruction of or damage to electronic protected health information caused by a system intrusion, such as a suspect email or virus. Failure to report and respond to the incident could create a serious problem if electronic protected health information, such as patient records, were altered or destroyed.

The requirements of this implementation specification are met by information compiled and analyzed as part of the covered entity’s required risk analysis. In the risk analysis, the covered entity will identify vulnerabilities and potential threats. As part of contingency and disaster recovery planning, the covered entity will identify responses that will mitigate those risks.

The Security Official is responsible for documenting the security incident in writing, and maintaining the documentation in written or electronic format for at least six years. Lessons learned are important outcomes of the documentation process, so the covered entity should review the security incident documentation periodically as part of updating the risk analysis.

Each covered entity should prepare and maintain a Security Incident Report and a Security Incident Log.

The Security Incident Report should contain the following information:

» Description of Attempted or Actual Security Incident
» Date, Time, and Location of the Incident
» Person Who Discovered the Security Incident
» How the Security Incident Was Discovered
» Evidence of the Security Incident
» Actions Taken to Mitigate Damages to Covered Entity’s Electronic Systems and Protected Health Information
» Policy and Procedure Changes Implemented to Avoid Recurrence
» Date of Security Incident Report
» Name and Signature of Security Official

For Each Line Entry in the Security Incident Log, Date, Location, Description, and Severity of the Security Incident, with Severity Ranked from 1 (Least Serious) to 5 (Most Serious) should be included.

Remember, the covered entity must retain these documents at least six years from last entry.