By focusing on security, and leveraging a flexible analysis approach, a HIPAA Security Risk analysis can achieve both security as well as HIPAA compliance and meet HITECH Act meaningful use objectives.

1. HIPAA Security Risk Analysis: Compliance vs Security
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.
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).
WEB PHONE EMAIL
WWW.REDSPIN.COM 800-721-9177 INFO@REDSPIN.COM

2. 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.
WEB PHONE EMAIL
WWW.REDSPIN.COM 800-721-9177 INFO@REDSPIN.COM