Road to HIPAA Compliance: Incident Response
by KirkpatrickPrice / September 28th, 2016
Security, Incident, Response, Repeat
There are several challenges when it comes to understanding security incidents and incident response. Our goal for this webinar is to answer several questions that occur while considering your organization’s incident response plan and creating policies and procedures to accompany your plan.
How would you define “security incident” for a practical, real-world setting?
The regulatory definition of a “security incident” includes the access, use, disclosure, modification, or destruction of information or system operations interference. You can have an activity that doesn’t actually access PHI, but it interferes with system operations just enough to establish a security incident. The definition also includes successful and unsuccessful attempts, which is important to remember when creating policies.
How often and to whom should security incidents be reported? How should it be documented?
Incident reporting should be considered initial, ongoing, and final. Initial reporting should be done immediately and directed towards security officers or to a security incident response team. The second phase, ongoing reporting, includes security officers, a security incident response team, management, and legal counsel. The third phase is a report on the final outcome of the investigation, which may need to be delivered to business associates or covered entities. Your organization needs to have policies and procedures in place to facilitate the documentation of initial, ongoing, and final reporting.
What about the “response” part; what are the appropriate responses?
There are four steps when responding to a security incident: investigation, mitigation, restoration, and correction. After investigating what security incident occurred, your organization should enter the mitigation phase. Mitigation is taking steps to reduce the harmful effects and temporarily fixing whatever security issues were found. Then, you should completely and fully restore the functionality you had before the security incident occurred. Then, your organization will determine what corrective actions need to be made beyond restoring the system to functionality.
Is identifying patterns of attempted security incidents reasonable and appropriate?
Certain incidents happen with such frequency that keeping track of trending may not be appropriate, like firewall attacks. Other incidents, though, like phishing attacks, need to be tracked so your organization can determine if it’s testing something that may be a weakness in your security management system. Using your organization’s Risk Analysis is vital when determining whether or not to identify trends and patterns. You can use the information to see where your highest risks and highest impacts are, so that those areas are given the consideration they deserve when conducting trending.
What is the difference between a security incident and a breach?
A security incident is something that can turn into a breach; think of a security incident as a baseline for a breach notification requirement. A security incident becomes a breach when PHI is compromised. If a compromise of PHI does not occur, then it is defined as a security incident.
Download the full webinar to hear from our HIPAA expert, Mark Hinely, hear enlightening examples, and learn about the details of each of these topics.
