When a data breach impacts an organization a number of parallel processes should optimally begin to come into play. One of the more important aspects is determining the contents of a breach notification that will go out. However, attention will certainly be drawn more to containing and resolving the actual cause and impact of the breach. While getting operations back to normal operation is an essential and primary point of focus, sufficient time should still be given to the contents of the notice.
Why does the breach notification get short shrift? One perspective is that the notice takes time away from operational concerns and recovering from the impact of the breach event. Another is that the notice represents an admission of the problem or a possible failure in security or procedural measures. Regardless of the specific reason for not wanting to send the notice, it must occur and can be viewed as an opportunity for positive engagement. This will not be a discussion of when notice must be provided (for that, check out this already 3 year old post). Instead, this discussion will touch on what level of detail should or must be included in a breach notification. To be clear though, the discussion around requirements is focusing solely on what HIPAA regulates, which can differ from other breach notification requirements, which can also depend on the information impacted by the breach.
The Bare Minimum or What HIPAA Mandates
The Breach Notification Rule under HIPAA outlines certain elements that must be included in any breach notification that is issued. As laid out in the rule (45 CFR 164.404(c)), the elements to be included are:
- A brief description of what happened, which should include the date of the breach and the date the breach was discovered if those dates are known;
- A description of the type of patient information impacted by the breach if the information was not secured (quick reminder here that if date are secure then a breach probably did not happen under HIPAA);
- What steps the organization suggests an individual should take to protect against impacts from the breach;
- A brief description of how (i) the breach is being investigated, (ii) the impacts of the breach are being mitigated, and (iii) measures are being implemented to prevent future breaches; and
- A listing of contact options for reaching out to contacts at the impact organization if there are questions about the breach.
The key component is a brief description of what happened. The rule itself only says that, a brief description. I admittedly have prepared the barebones notification letter, which is in all likelihood similar to what most healthcare attorneys have in their files as a template ready to provide to any client that experienced a breach. Without quoting directly, the “brief description” often says that an incident occurred, the full impact is not necessarily known but balanced with a statement that no improper use is known, and that it was not possible to determine that data were taken and/or accessed.
The bare minimum approach does not provide much information and can be easily dismissed by individuals receiving it. As a point of fairness, in many instances, there is not much detail that can be or needs to be made known as the impact is not that big or the underlying issues that complicated. When that is the case, it is understandable and fine to give a basic breach notification. When that may not be the case though is when details of a breach are put out there in another forum or there is other clear evidence of a deeper, known issue.
Seizing the Opportunity
When a situation is more complex, should an organization provide more detail about the breach situation? It is a complex question and the answer will be the classic lawyer answer of: it depends. Each situation is unique and can call for a different approach. Leaving aside the need to comply with HIPAA, organizations do need to balance potential liability, exposure of internal operations in a way that is counterproductive, and a whole host of other issues.
Without being able to cover every scenario or nuance, there are some instances when more detail could be called for. One example is when a security researcher provides information about data being available or exposure occurring. An independent security researcher should be considered a more reliable source than a cyber-attacker posting notice of having data (that will be addressed next) and approaching the researcher with a shoot-the-messenger mentality is not productive. If information is provided about an issue, that information can be used to formulate the description of the breach incident. While it is probably not necessary to use all of the information, it is helpful to consider adding in more than a statement that an issue occurred.
The decision to get more detailed could also be influenced by the independent actions of the researcher. While not all researchers publish accounts of what they found, when that does occur, it can create a stark contrast against the official notification from the impact organization. When conflicting information enters the public sphere, especially from potentially trusted sources, it can create unnecessary confusion and tension. Organizations can get in front of that complication by adding a bit more transparency into the notification.
As suggested above, what happens when a cyber-attacker posts screenshots or other evidence of data being taken, it is not necessary to say that the attacker is accurate. However, completely ignoring that reality and trying to state that it is not known if data were accessed and/or taken in the face of a public posting rings of dishonesty or willful ignorance. Either approach does not engender trust among impacted patients or even the general public. If individuals can find additional information, then it does not make sense to hide the ball from them. Given that perspective, going a bit beyond an organization’s comfort or clear safety zone may be called for in the name of positive patient relations.
The patient relationship point of view is an important one to consider when crafting the contents of the breach notification. As already noted, the regulations, in particular HIPAA, set the floor from which to operate. A floor is just the base though and not the finished product. Instead, the floor can be viewed as the solid base from which a preferred building can be constructed. In the context of a breach notice, the final building can be dense and opaque or open and transparent. There are obviously many variations in between those two extremes, but the final product is all in the craftsmanship.
A final note about craftsmanship is that it can be an evolving process. If all of the details are not known within the required timeframe to issue a notification, then an initial heads-up that is honest about that circumstance could be useful. Then, as more details are fleshed out and learned, the notice can also be updated and made more informative. The decision points in that instance are about organizational preference, arguably adherence to the black and white regulatory statements, and how to make the best of a bad situation.
The Notice of the Future
Examples of informative and engaging breach notices are possible to find. It can be refreshing and stand out when those instances occur since they are still not very frequent. Despite the current status of notices erring more on the bland and short side, change is possible. The question is whether organizations will stay with a bare minimum approach or start moving in the direction of rewriting the narrative around a negative occurrence.