What does "Security Incident" mean to you?
(And do your partners and customers agree?)
HIPAA 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.”
HIPAA requires Covered Entities (CEs), Business Associates (BAs) and Sub-BAs to implement policies and procedures that address identification of and response to security incidents—all of which are meticulously detailed in Business Associate Agreements (BAAs).
From a 50,000-foot perspective, this all seems pretty straightforward. But, as is often the case with HIPAA mandates, complexity and confusion are just ahead.
HIPAA’s framers purposely did not define what comprises a security incident, preferring to “maintain a flexible, scalable and technology neutral approach” by not identifying any single method for healthcare organizations to use when identifying, addressing or reporting security incidents. Instead, organizations are expected to use information gathered while complying with other security standards to create customized definitions that make sense within the context of their own business operations.
As a result, definitions of security incidents vary widely across organizations, and the BAA is now ground zero for the confusion created by this lack of standardization.
A data breach has the concrete definition of “the loss of control, compromise, unauthorized disclosure, unauthorized acquisition, unauthorized access, or any similar term referring to situations where persons other than authorized users and for an other than authorized purpose have access or potential access to personally identifiable information, whether physical or electronic.” Breach response protocol is also spelled out in great detail, requiring CEs to notify affected individuals, the Office of Civil Rights and, in certain circumstances, the media. BAs must notify CEs if a breach occurs at or by the BA.
A security incident, however, has the much less clear-cut definition of “a violation or imminent threat of violation” of an organization’s security or privacy policies when it comes to protected health information (PHI). This definition from the National Institute of Standards and Technology leaves the door wide open when it comes to the crucial first step of deciding what actually constitutes a “security incident” for the purposes of maintaining a proper and compliant business relationship.
This has created an environment in which there is little consensus on what rises to the level of a reportable incident, often leading to conflicting definitions between CEs, BAs and Sub-BAs. An easy, non-techie way to think about this dilemma is discovering an open window in your family’s home. Does the open window itself constitute a “security incident” or is it, perhaps, a full break-in and robbery (a “breach”)? Did you open the window, or did someone else open it without your knowledge? What if an intruder opened it, came into the house, but didn’t steal anything? What if you’re not sure if anything was stolen? Who would you tell about the window? Would you call the police, or your insurance company? Would your family members, friends or neighbors react the same way as you?
The same conundrum exists for healthcare organizations. One facility may decide that multiple login attempts that don’t result in access constitutes a security incident requiring a response; another may decide a response is only needed if unauthorized access is achieved.
Other examples of problematic events that, thanks to the lack of a standard definition, are left up to each healthcare organization to decide if a reportable security incident has taken place:
- An electronic inquiry from an external system
- Unauthorized access to a facility’s internal Wi-Fi network
- Emailing or texting unsecured PHI
- Saving files containing PHI to a public drive or unsecure device
- The inadvertent disclosure of a password
- Missing or forgotten software updates or upgrades
- Improperly configured software
- Improper “disposal” of a device or software containing PHI
Ultimately, whatever is defined as a security incident should be spelled out in the BAA, along with response requirements. Consequently, this means that every BAA likely has different requirements regarding security incident response.
Variances in security incident response requirements create yet another logistical nightmare when it comes to managing BAAs and staying compliant.
There are two possible solutions, both of which are simple in theory but highly complex in execution. The first is to establish an industry-standard definition of “security incident” that meets the needs of all healthcare organizations. This is highly unlikely, given the broad variances we already see in the definition—and the unwillingness displayed thus far to attempt to establish one.
The second solution is to clearly define what constitutes an incident in every BAA so appropriate response triggers can be put in place. It’s an overwhelming prospect when the framework upon which to build a definition is so loose. Even if organizations succeeded in establishing concrete definitions to include in each BAA, manually establishing triggers would quickly overwhelm their resources.
While an emerging market sector—automated BAA management—can help once security incidents have been clearly defined in BAAs by automatically triggering the proper response, it’s up to the human element to address the challenge of creating workable definitions.
