|In January 2017 HHS issued guidance regarding "Audit Controls" under the Security Rule ("SR") by stating, among other things, the following: "[c]overed Entities and Business Associates should make sure that they appropriately review and secure audit trails, and they use the proper tools to collect, monitor, and review audit trails." HHS specifically references one of the Technical Safeguards, specifically §164.312(b). However, curiously (or maybe not depending on your perspective) the latter is a SR "Standard" that has NO implementation specification associated with it. In short, you are even more on your own than usual when it comes to interpreting how you should comply with this requirement.
The $$ quote from this guidance is as follows:
The HIPAA Security Rule provision on Audit Controls (45 C.F.R. § 164.312(b)) requires Covered Entities and Business Associates to implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information (ePHI). The majority of information systems provide some level of audit controls with a reporting method, such as audit reports. These controls are useful for recording and examining information system activity which also includes users and applications activity. [emphasis added].
The net/net is that you have to create and/or review logs (assuming the logs have already been created) in order to detect suspicious activity. It stands to reason that if you do not review logs there is no way (damn near impossible) that you would ever become aware of attempted or actual security breaches. To be more specific, you are reviewing the logs for security incidents. The latter is a term of art under the HIPAA rules ("Rules") and means the following: "the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system." Notice that a security incident is not synonymous with a Breach. Even an unsuccessful breach attempt is a security incident. Our Breach Notification Framework provides you with tools and templates that help you understand and deal with incidents.
Anyone that has ever supported an application, database, network, etc. understands that one of the things that you do on a daily basis is to check the logs to see if any errors or other negative issues have occurred. It's a routine part of a support person's job. However, for the vast majority of small to midsize covered entities and business associates, nearly all of whom use commercial-off-the-shelf ("COTS") software to run their respective businesses, there is likely no individual whose job requires review of logs. So, my favorite question to these organizations, if I were an auditor, would be "tell me how you manage security incidents?" Why? Because I'll bet that most of these organization's workforce do not even know who to call - if they could even recognize an incident. Assuming that they knew who to call, there's a high probability that incidents are NOT being tracked according to the Rules.
There's an even higher probability that no one within the organization is reviewing logs on a daily basis of any kind. So, asking about security incident management leads to natural "gotchas" that the unsuspecting compliance officer is going to "fall into." It's an auditor's "dream question." Notice that HHS' guidance conveniently does not suggest how often it should be done. Why is that and how can HHS get away with being so nonchalant about such an important requirement? Because it can rely on the "General Rules" under §164.306(b) and state that what you have to do under the "Flexibility Principle" is what is "reasonable and appropriate" for an organization of your size, complexity, etc. These are the "regulatory weasel words" that the Rules use to handle all such nuanced conduct.
Despite the weasel words (or because of them depending on whether or not you are the auditor) the answer of "we never review logs" is not going to be acceptable. Because if that's true, how is possible that you are tracking security incidents in a manner that the Rules require? What should a covered entity or business associate do if faced with this conundrum (i.e. almost exclusively relying on COTS solutions)? The answer is that whether or not these business associates (i.e. your COTS vendors) are hosted on the Cloud or not, they are almost always business associates of yours, which means, among other things, that you need to have a business associate agreement ("BAA") in place with them. Assuming that you have a BAA in place AND that you have gotten "satisfactory assurances" that they are likewise complying with the Rules, then you can "offload" this "reviewing of logs" requirement onto them.
Unfortunately, this "offloading ploy" only goes so far. Almost all of the organizations in question have local networks that underpin the communications amongst staff (e.g. email, txt, etc.). Whose responsibility is it to review these logs? Well, if you have dedicated HIT staff then the answer to that question is obvious. But the premise of this article is that most organizations do NOT have dedicated staff, and so the problem remains. However, a Compliance officer can readily be taught to review logs OR, you could hire an independent contractor (i.e. business associate) who would likely be willing to provide that service for next to nothing a month.
It is our hope that this article not only helped you to better understand "Audit Controls" but also helped you understand the nuanced nature of the SR!