[BreachExchange] Creating a Healthcare Security Incident Reporting Process

[Audrey McNeil]

https://healthitsecurity.com/news/creating-a-healthcare-
security-incident-reporting-process


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20170713/d820a5fa/attachment.html>