HIPAA Risk Analysis Tips – Open Appeal to Risk Thought Leaders

This entry is part 33 of 38 in the series HIPAA Security Risk Analysis Tips

Open Appeal to Risk Thought Leaders

Dear HIPAA Risk Analysis Thought Leader,

Admittedly, I may be tilting windmills here!  Consider helping me out.  While the wicked “harm standard” is being removed by the Final Omnibus Rule, published in the Federal Register on Friday, January 25, 2013, the confusion around what comprises an authentic risk assessment (known in 45 CFR §164.308(a)(1)(ii)(A) as a Risk Analysis) is perpetuated. Ugh!  How does this confusion contribute to organizations becoming and remaining compliant with these regulations?  Here’s today’s big ASK – Can We Join Together and Call It Something New – Compromised Assessment or…?!

harnessing risk starts with a bona fide risk analysis

HIPAA Risk Analysis Tip – Try Not to Be Confused!

In the Final Omnibus Rule, the phrase “risk assessment” is used sixty (60) times — 58 times perpetuating confusion about what comprises real risk analysis and 2 times in relation to what health care reform should really be about in the US, health risk assessments.  (Of course, that’s a separate matter and the difference between health insurance reform and real health reform — don’t get me started).

Let’s get back to the matter at hand!  Swirling around in the land of HIPAA-HITECH compliance are requirements to complete:

  • HIPAA Security Evaluation, required at 45 CFR 164.308(a)(8)
  • HIPAA Risk Analysis, required at 45 CFR §164.308(a)(1)(ii)(A) 
  • This “breach risk assessment” thing…

In a recent blog post, we explained the difference between the first two (Security Rule) requirements above: HIPAA Audit Tips – Don’t Confuse HIPAA Security Evaluation and Risk Analysis.  We also cover the difference in one of our most requested and most popular webinars which can be viewed On Demand: The Critical Difference: HIPAA Security Evaluation v HIPAA Security Risk Analysis.

The perpetuation of the ”breach risk assessment” thing emanates out of the preamble in the Final Omnibus Rule and in numerous comments and, of course, in the new definition at 45 CFR §164.402 Definitions in paragraph 2:

(2) Except as provided in paragraph (1) of this definition, an acquisition, access, use, or disclosure of protected health information in a manner not permitted under subpart E is presumed to be a breach (emphasis added) unless the covered entity or business associate, as applicable, demonstrates that there is a low probability that the protected health information has been compromised based on a risk assessment (ugh! added) of at least the following factors:

(i) The nature and extent of the protected health information involved, including the types of identifiers and the likelihood of re-identification;

(ii) The unauthorized person who used the protected health information or to whom the disclosure was made;

(iii) Whether the protected health information was actually acquired or viewed; and

(iv) The extent to which the risk to the protected health information has been mitigated.

What to Do?  - Call it something else! – Anything else! – Compromise Assessment?

As a friend recently reminded everyone, as soon as one has “an acquisition, access, use, or disclosure of protected health information in a manner not permitted under subpart E (Privacy Rule”, the Breach light is on.  The burden of proof is on the Covered Entity or Business Associate.  And, the proof needed is that there is a low probability of “that the protected health information has been compromised”. So, perhaps please, we can call it a Compromise Assessment simply to help eliminate some of the fear, uncertainty and doubt about these requirements.

And, finally as a reminder, what’s that HIPAA Risk Analysis requirement, again?

Risk analysis is a fundamental, foundational part of any risk management program, including your cyber security program.  It’s not an evil creation of HIPAA or HITECH statutes or their promulgated rules.  In fact, it’s been around since the beginning of mankind.  In a nutshell, risk analysis is determining your biggest to smallest risks (a.k.a., exposures) and then using this information to make informed decisions about treating them (accept, avoid, mitigate, transfer).

For leaders at healthcare Covered Entities or their Business Associates or their Subcontractors, HHS / OCR published its “Guidance on Risk Analysis Requirements under the HIPAA Security Rule” which relies on the NIST Security framework and specifically NIST SP800-30 Revision 1 Guide for Conducting Risk Assessments. According to both documents and NIST SP800-30,

“A Risk Analysis is the process of identifying, prioritizing, and estimating risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, …, resulting from the operation of an information system.  Part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place.”

To learn how to complete your Risk Analysis according to HHS/OCR and underlying NIST guidance, view Clearwater HIPAA Risk Analysis Video Overview.

Wanna be even more hip on HIPAA? Learn more…

The complete HIPAA Privacy, Security and Breach regulations are here.

If you’d like keep up to date on Risk Analysis or HIPAA-HITECH in general, please also consider (all optional!):

Series Navigation<< HIPAA Security Risk Analysis Tips – Open Letter to VITOHIPAA Risk Analysis Tip – Sage Risk Management Advice from Drucker >>
Share
3 Responses to “HIPAA Risk Analysis Tips – Open Appeal to Risk Thought Leaders”
  1. Linda 6 February 2013 at 9:07 am #

    How about calling it a Focused Breach Assessment? Or terminology that mirrors the reviews conducted by performance improvement / quality assessment professionals in health care when they do an initial review of a possible problem area. Those have been called “focused chart review”. It may be helpful to adapt terminology that suggests the process involved.

  2. Chip Council, PhD, CGEIT, CISA, CISM 6 February 2013 at 12:50 pm #

    I have always had a problem with this because I doubt what they are asking for is what they want.

    IMHO, a RISK ASSESSMENT is an assessment of INHERENT RISK (in English, risk before any security controls are applied). The data from this exercise can then be used to identify the areas of highest risk and used to evaluate the SECURITY CONTROLS (formalized measures taken to mitigate risk). Then a SECURITY AUDIT is conducted against the controls that mitigate the highest risk. The audit looks at the design of the controls, are they sufficient, the underlying governance, policies and procedures, and finally compliance with the controls. Tests are then conducted against the controls, (e.g. comparison of a sample of terminated employees and the dates their access was removed). The findings can then be combined with a RISK ANALYSIS to determine and prioritize remediation activities and communicate risks to senior management.

    There is guidance out there to assist with this:

    • Special Publication 800-30, Guide for Conducting Risk Assessments.

    • Special Publication 800-39, Managing Information Security Risk: Organization, Mission, and Information System View;11

    • Special Publication 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach;

    • Special Publication 800-53, Recommended Security Controls for Federal Information Systems and Organizations;

    • Special Publication 800-53A, Guide for Assessing the Security Controls in Federal Information Systems and Organizations: Building Effective Security Assessment Plans.

    • Information Securtity and Control Association (ISACA) IT Audit, Assurance and Control Standards

    There is also guidance on building the security controls such as the HI-TRUST framework that combines and cross references multiple regulatory provisions and best practices.

    Finally, knowledgeable people often argue over the semantics and poke holes in each others approaches. The important thing is rise above that, which may require recognition of the motivations of the critics. My humble advise is to 1) pick an approach that will accomplish the ultimate goal of understanding your greatest risks, 2) scale that plan to what is reasonable for the size of your organization and 3) create a plan to mitigate those risks. If you are making an educated effort based on existing guidance, I have never encountered regulators nor auditors who didn’t appreciate the structure and partner with you to improve it.

  3. Bob Chaput 8 February 2013 at 3:09 pm #

    Chip, thanks so much for the thoughtful and complete reply! I could not agree more…best, Bob

Leave a Reply