July 10, 2017 – With the recent wave of ransomware attacks, hacking attempts, and unauthorized disclosures, healthcare organizations have more opportunities to exercise their incident management plans. Unfortunately, these same organizations are learning the hard way that the probability of a successful response and recovery is dependent on prior investments in testing and staff training. For this reason, it is important to review the characteristics of a robust and mature security incident reporting process.
Building a robust process starts with a thorough understanding of the foundations of a mature incident response process. Covered entities and business associates have legal, regulatory, and contractual obligations to report security and privacy incidents that meet the threshold of a breach, as defined by the HIPAA Breach Notification Rule, state laws, and/or perhaps Business Associate Agreements.
These requirements vary by the type of organization, the laws governing the patients’ data, and contracts. The HIPAA requirements should be treated as the minimum compliance threshold, rather than a goal.
For organizations that have experienced adverse events including breaches, there is ample evidence that the process — from the initial discovery to validation, remediation, and recovery — can be very time consuming.
While HIPAA allows for up to 60 days to report breaches of 500 or more patients, other state laws and contracts have shorter expectations. Business associates are often obligated to respond in the shorter timelines.
In addition to external reporting requirements, covered entities have obligations to protect and respond to events impacting the integrity and availability of data. In these instances, these internal and external stakeholders have much shorter expectations.
The incident process starts at the beginning
The HIPAA definition of a security incident is, “the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system.”
The HIPAA Security Rule requires covered entities and business associates to “implement a policy and procedures to address security incidents.” The Privacy Rule (and Section 164.402 of the Omnibus Rule) requires the organization to report Breaches of Protected Health Information. Both Rules start with an assumption that healthcare organizations know an incident has occurred.
In reality, every confirmed incident is preceded by a suspected incident, as organizations rarely have 20/20 vision and the ability to instantly determine if a suspected security incident is real, a test, or some other type of reporting anomaly.
Therefore, incident management procedures should include initial discovery and reporting of suspected incidents, or events, as the first step.
Building one incident process
One challenge in building a reporting process is to quickly alert individuals who are authorized to validate and respond to an incident. Unfortunately, functional stovepipes may build independent incident structures leading to separate security, privacy, technical, and non-technical reporting processes. This fosters an environment with training challenges and reporting delays.
It is more efficient to address the challenge as an enterprise issue, as the Compliance Officer, Chief Privacy Officer, and/or the Chief Information Security Officer all need to be alerted so that incidents can be analyzed to determine if there is a loss of confidentiality, integrity, or availability of any myriad types of sensitive information.
In response, healthcare organizations should consider one incident reporting and analysis process. A single process simplifies workforce training, facilitates early executive and compliance alerting, and brings a collective set of experiences to evaluate each incident.
A single process also accelerates coordination, analysis, recovery, and, if needed, rapid reporting if a breach is confirmed.
When a user discovers an anomaly, it may be difficult to determine what system or type of data has been compromised.
As history has shown, hackers have expanded an initial breach targeting non-PHI systems to systems that contain PHI. Having one reporting process would facilitate quickly alerting all responders.
All breaches start as an incident, but not all incidents result in a breach
Just as not all events can be validated to be incidents, not all incidents reach the threshold to be called breaches.
The Omnibus Rule defines a breach as, “the acquisition, access, use, or disclosure of protected health information in a manner not permitted under subpart E of this part (a.k.a., the HIPAA Privacy Rule) which compromises the security or privacy of the protected health information.” The Omnibus Rule goes on to define a set of exclusions to the term breach.
The analysis of a suspected breach and application of the defined exclusions are challenging for even experienced compliance teams. Therefore, the use of the term breach should be limited to only those incidents that have thoroughly been reviewed and found to meet the strict breach definition contained in the HIPAA regulations.
The authority to declare a breach should therefore be limited to a very small group of individuals who have been granted authority to perform the evaluation and the competence to evaluate the evidence calmly.
Until those events happen, all internal written and verbal communication up to the point that an incident is declared a breach should use the terms ‘event’ or ‘incident’ so as to preclude over-reaction.
Breaches that do not involve the acquisition, access, use, or disclosure of protected health information also require a rapid response. These likely require other legal, regulatory, or contractual responses.
For example, Payment Card Information (PCI), the loss of employee data, the unauthorized access of insider financial data, etc. can all cause negative impacts to an organization but may not trigger a HIPAA reporting requirement.
Identifying barriers to quick reporting
Many healthcare providers are required to have a compliance hotline. These hotlines provide whistleblowers an outlet to report compliance issues without fear of identification or retribution. To work properly, all members of the workforce must be trained and retrained on how to report issues.
Incident reporting processes can benefit from similar processes and protections. Healthcare organizations with an anonymous incident reporting hotline will likely experience a higher number of incidents that those without a hotline, but this is a positive situation.
Compliance and IT professionals cannot manage what they don’t measure, and underreporting security and privacy events creates a false sense of security and lead to under investment. The anonymous reporting portal will facilitate a higher reporting frequency, but only as long as the workforce feels comfortable that retribution is not tolerated. Therefore, leaders should not tolerate retribution, or else incidents will be underreported.
Workforce members are also more likely to report events and incidents when the leadership demonstrates the will to investigate and respond to all incidents fairly. Once workforce confidence is established, organizations will experience two trends over time.
First, reported incident rates will increase as the workforce awareness and comfort levels increase. Second, incident severity should drop as root cause analysis is performed and lessons learned are incorporated.
At some point, the rate of new reports will stabilize and the average severity should remain low. This would indicate that the incident reporting process is mature.
Preventing future healthcare security, privacy incidents
In summary, healthcare organizations can benefit from a detailed incident policy that starts at a suspected discovery, through the closure.
There should be one reporting process that quickly alerts trained responders.
Finally, organizations that use third parties for helping build and test procedures fare better because of the cross-functional, cross-organizational lessons learned. It will also be beneficial to have these same third parties help by retaining individuals who have been tested in other situations.
Clyde Hewitt is vice president of security strategy at CynergisTek. He brings more than 30 years of executive leadership experience in cybersecurity to his position with CynergisTek, where his many responsibilities include being the senior security advisor and client executive, thought leader and developer of strategic direction for information and cybersecurity services, nationwide business development lead for security services, and contributor to CynergisTek’s industry outreach and educational events.