Talk to a Security Expert Now: (800) 721-9177

HIPAA Security Risk Analysis: Compliance vs Security

Security vs Compliance

As an independent provider of security assessments, we are keenly aware of the 2 primary drivers of an objective security assessment – security or compliance. Roughly, these two views of risk management can be thought of as follows:

  • Security: For organizations in this camp, ensuring that ePHI is protected is mission critical to the business. Any impact to data security would be viewed as negatively impacting business value: whether it be monetary, brand value or customer loyalty, and minimizing the risk of a data breach is the goal of an assessment – this is pure risk management.
  • Compliance: On the other hand, organizations that are driven by compliance – while they don’t necessarily feel that data security is unimportant – the primary driver for doing a security assessment is to “check-the-box” that a HIPAA Security Risk Analysis has been completed per HIPAA or to address HITECH meaningful use objectives.

In reality, of course, both of these objectives often factor into the need to perform a HIPAA Security Risk Analysis. However, it’s important for healthcare organizations to be able to differentiate between these drivers, because the value of a risk assessment can be maximized if the effort is guided properly. In fact, with the right guidance a risk analysis can achieve both.

Venn diagram showing the difference between security and compliance

Security vs. Compliance

To understand this, it’s important to understand how compliance relates to security; note the Venn diagram at left. If one focuses purely on compliance during a risk analysis, then likely there will be a lot of residual risk that is not identified during the analysis. In fact, there might be some wasted effort as a pure compliance effort may place too much emphasis on certain areas of analysis that are not necessarily relevant to the environment in question (the light blue area of the diagram).

However, if one focuses on the intent of HIPAA Security Rule, then both security and compliance can be achieved. After all security is the intent of the Security Rule. While this may seem obvious, many compliance oriented risk analysis efforts leverage a static scope with little room for in-depth analysis of critical controls. Sure the control exists – say encryption on a device, for example – but the real question is whether the control is actually working as intended. In our experience the vast majority of risk in health IT environments is not missing controls, but rather controls that are not deployed correctly, and thus providing a false sense of security.  This is often due to configuration error or a lack of effective process supporting the control. Furthermore, a static “check-the-box” risk analysis creates findings and recommendations that result in the deployment of controls that are often expensive and don’t map into high areas of security risk. I can’t tell you how many organizations I’ve seen spending precious IT department resources on low security risk issues, while blatant easy-to-fix critical security risk just hangs out there for months. Sure it might be more fun and exciting to deploy an expensive intrusion detection system (IDS), however, doing this in a situation where its number 37 on your priority list of issues, when in fact you have laptops that you think are encrypted but they are in fact not can be disaster.

How to achieve both security and compliance

First off, leverage a risk-based approach to risk analysis in which the ePHI and IT processes around the data drive the scope, as opposed to a static check box list-of-questions approach.  No two IT environments are the same and thus no two assessments of risk are the same. The HIPAA Security Rule is practical and flexible. Its practical in that it was founded on sound principals and security best practices, and flexibility is clearly stated in the Security Rule:

HIPAA Security Rule: § 164.306(b) Flexibility of approach

(1) Covered entities may use any security measures that allow the covered entity to reasonably and appropriately implement the standards and implementation specifications as specified in this subpart.

(2) In deciding which security measures to use, a covered entity must take into account the following factors:

(i) The size, complexity, and capabilities of the covered entity.

(ii) The covered entity’s technical infrastructure, hardware, and software security capabilities.

(iii) The costs of security measures.

(iv) The probability and criticality of potential risks to electronic protected health information.

From a compliance standpoint a HIPAA Security Risk Analysis is a foundational component of both HIPAA compliance and HITECH Act meaningful use objectives. However, it is also a fundamental aspect of any robust information security program. By focusing on security (the intent of compliance) a risk analysis can significantly reduce the risk of an ePHI breach, save money by focusing IT resources on the most important issues and….. achieve compliance.

Leave a Reply

Your email address will not be published. Required fields are marked *