HIPAA: Reasonably have known

Should Reasonably Have Known

The HIPAA Breach Notification Rule has an interesting turn of phrase: “should reasonably have known”.  A company is liable if they reasonably should have known about a breach.  So what is reasonable?  The latest 2013 rulemaking gives some guidance on that:  §164.404(a)(2) expands that to reasonably should have known by exercising reasonable diligence.  And then goes on to define it as “business care and prudence expected from a person seeking to satisfy a legal requirement under similar circumstances”.  Further adding that as soon as a workforce member or other agent has knowledge or should have had knowledge of the breach, the clock on notification starts.

So, you’ve got some relatively vague definitions of what’s reasonable, and as soon as someone at your company knew, or should “reasonably have known” about a breach, the clock starts on the notification timeline.   Who makes the decision on what is reasonable?  The HHS official looking into the breach.

There are some guidelines that can help determine what “reasonably should have known” might mean.  Most legal dictionaries define reasonable as “just, rational, appropriate, ordinary or usual in the circumstances.”  That’s still pretty vague, but it gives more of an idea of what reasonable means in this context: if most folks are doing it, you probably should too – or at least consider it.

When used in the context of  “should reasonably have known” in HIPAA, it is necessary to examine what others in your industry are doing as far as training, logging and review, and incident monitoring goes.  Evaluate what they are doing, determine if it’s “reasonable” for you to do the same, and if so, implement it.

Training

Why do you need to worry about training for learning about a breach?  The breach notification time line starts when any workforce member or agent should reasonably have known about a breach. Therefore, every person in your organization that is a workforce member (employee) or acting as an agent for the organization must know to notify those responsible for incident management within a specific time frame.  The incident management team needs to know right away about anything that might be a breach as required by §164.308(a)(5). Then that team can investigate and determine if it is actually a breach, and if it requires a response.

The only way to educate the entire workforce is via training. Putting it into a policy is a good idea, but that doesn’t mean that all employees will follow that policy.  Training doesn’t guarantee that either, but if you communicate the importance of your employees notifying the incident management team (or their manager, etc), you’re likely to get higher compliance from your employees.  And this training needs to include any agents working for you as well – independent contractors, business associates that may be agents, etc.

Logging and Review

As security experts, we’ve been telling folks to log security events where possible and review them on some schedule that makes sense for them for a long time.  Manual log review is one of the “low tech” ways to detect an incident – and relatively low cost.  As an auditor, I would expect to see logging turned on and periodic reviews of those logs.  It’s a required component of §164.312(b), so you’d better have logging and review of at least systems involved with PHI.  It could even be argued that you want logging and review on all systems and devices.  You may have attackers on your network, but they haven’t been playing around with your PHI systems – yet.  Having logging enabled on all of your systems may give you a “heads up” that gives you time to avoid a breach of PHI.  One thing you want to ensure is that the folks reviewing the logs are trained on that particular system, device or application as well as what is “normal” for your systems.  You want someone reviewing the logs that knows whether something is normal or not, and can filter out “false positives” that are common in logs.  And from an audit perspective – document everything!  Document your policies, document every time a log is reviewed, and document any communication about log configuration or log review.

Incident monitoring

Incident monitoring is a broad topic, but basically means the team, processes and procedures for discovering an incident (aka a potential breach).  There are a lot of things that go into incident monitoring, and this topic is where the “should reasonably have known” phrase leaves a lot open for interpretation.  Logging and review are definitely part of the incident monitoring processes, but many other things can be as well.  You can pay for a SELM or SIEM system or service, or you can do it manually yourself.  There are pros and cons to both ways.  The biggest con to a commercial SELM and SIEM systems is the cost.  They can be expensive!  When it comes to whether you “should reasonably have known” though, are you required to have an SELM or SIEM just because many of your peers do?  Ultimately the auditor or investigator will make that determination. However, you can document your research and decisions to make the case that your decisions are reasonable. Back it up with your methods of determining if a breach occurred, even your methods don’t require the latest, most expensive tools.

Conclusion

“Should reasonably have known” is a vague term, with limited guidance on what it means.  Ultimately, the auditor or investigator will make the determination.  To help you meet the Breach Notification Rule requirements, we suggest you look at your peers in the same industry, and seriously consider the same technologies and tools they are using.  Consider the benefits of those technologies and tools, and consider the cost to you – both in terms of the technology or tool, and in terms of fines for a breach.  Document your risk assessment process, and your decisions – whatever they are!  While HIPAA’s minimum penalty for willful neglect is $50,000, that still might not justify the cost for a SELM or SIEM system to protect PHI – unless you need it for another reason.  Whatever your decision, it is important to implement incident detection  and response mechanisms, whether automated or manual.

This article has been cross-posted from the Gemini Security Solutions website.