RisknCompliance Blog

Thoughts On Delivering Meaningful Outcomes in Security and Privacy

Category: Regulatory Compliance (page 1 of 3)

Hello PCI SSC… Can we rethink?

This is a detailed follow-up to the quick post I wrote the Friday before the Labor Day weekend,  based on my read at the time of the PCI SSC’s Special Interest Group paper on “Best practices for maintaining PCI DSS compliance”1 published just the day before.

The best practices guidance is by and large a good one though nothing of what is discussed is necessarily new or ground breaking. The bottom line of what the paper discusses is the reality of what any person or organization with electronic information of some value (and who doesn’t today?) needs to do… which is that there is no substitute for constant and appropriate security vigilance in today’s digital world.

That said,  I am not sure this guidance (or anything else PCI SSC has done so far with PCI DSS including the new version 3 taking effect at the end of the year) is going to result in the change we need… the change in how PCI organizations are able to prevent or at least able to detect and contain the damage caused by security breaches in their cardholder data environments (CDEs). After all, we have had more PCI breaches (both in number and scale) over the past year than at any other time since PCI DSS has been in effect.

One is then naturally forced to question why or how does PCI SSC expect a different result if  PCI DSS itself hasn’t changed fundamentally over the years. I believe a famous person no less than Albert Einstein had something to say about doing the same thing over and over again and expecting different results.AE

If you have had anything to do with the PCI DSS over the last several years, you are probably very familiar with the criticism it has received from time to time.  For the record, I think PCI DSS has been a good thing for the industry and it isn’t too hard to recognize that security in PCI could be much worse without the DSS.

At the same time, it is also not hard to see that PCI DSS hasn’t fundamentally changed in its philosophy and approach since its inception in 2006 while the security threat environment itself has evolved drastically both in its nature and scale over this period.

The objective of this post is to offer some suggestions for how to make PCI DSS more effective and meaningful for the amount of money and overheads that merchants and service providers are having to spend on it year after year.

Suggestion #1 : Call for Requirement Zero

I am glad the best practices guidance1 highlights the need for a risk based PCI DSS program. It is also pertinent to note that risk assessment is included as a milestone 1 item in the Prioritized Approach tool2 though I doubt many organizations use the suggested prioritization.

In my opinion however, you are not emphasizing the need for a risk based program if your risk assessment requirement is buried inconspicuously under requirement #12 of the 12 requirements (12.2 to be specific). If we are to direct merchants and service providers to execute a risk based PCI DSS program, I believe the best way to do it is by  making risk assessment the very first thing that they do soon after identifying and finalizing the CDE they want to live with.

As such, I recommend introducing a new Requirement Zero to include the following :

  • Identify the current CDE and try to reduce the CDE footprint to the extent possible
  • Update the inventory of system components in the CDE (Current requirement 2.4)
  • Prepare CDE Network diagram (Current requirement 1.1.2) and CHD flow diagram (Current requirement 1.1.3). I consider this to be a critical step. After all, we can only safeguard something valuable if we know it exists. We also talked about how the HIPAA Security Rule could use this requirement in a different post.
  • Conduct a Risk Assessment (Current requirement 12.2)

Performing a risk assessment right at the beginning will provide the means for organizations to evaluate how far they need to go with implementing each of the 200+ requirements. In many cases, they may have to go well over the letter of certain requirements and truly address the intent and spirit of the requirements in order to reduce the estimated risk to acceptable levels.

Performing the risk assessment will also (hopefully) force organizations to consider the current and evolving threats and mitigate the risks posed by these threats. Without the risk assessment being performed upfront, one will naturally fall into the template security mindset we discussed here. As discussed in the post, template approaches are likely to drive a security program to failure down the road (or at least make it ineffective).

Suggestion #2 : Discontinue all (requirements) or nothing approach

A true risk management program must mean that the organizations should have a choice not to implement a control if they can clearly articulate the risk associated with not implementing it is truly low.

I think PCI DSS has a fundamental contradiction in its philosophy of pushing a all-or-nothing regulation while advocating a risk based approach at the same time. In an ideal world where organizations have limitless resources and time at their disposal, they could perhaps fully meet every one of the 200+ requirements while also addressing the present and evolving risks. As we know however, the real world is far from ideal in that the organizations are almost always faced with constraints all around and certainly with the amount of resources and time available at their disposal.

Making this change (from all or nothing approach) of course will mean a foundational change in PCI DSS’ philosophy of how the whole program is administered by PCI SSC and the card brands. Regardless, this change is too important to be ignored considering the realities of business challenges and the security landscape.

Suggestion #3 : Compensating controls

As anyone that has dealt with PCI DSS knows, documentation of compensating controls is one of the most onerous aspects of PCI DSS, so much so that you are sometimes better off implementing the original control than having to document and justify the “validity” of the compensating control to your QSA. No wonder then, that a book on PCI DSS compliance actually had a whole chapter on the “art of compensating control”.

The need for compensating controls should be based on the risk to the cardholder data and not on not implementing the requirement itself. This should be a no-brainer if PCI SSC really wants PCI DSS to be risk based.

If the risk associated with not implementing a control is low enough, organizations should have a choice of not implementing a compensating control or at least not implementing it to the extent that the DSS currently expects the organization to.

Suggestion #4 : Reducing compliance burden and fatigue

As is well known, PCI DSS requires substantial annual efforts and related expenses. If the assessments involve Qualified Security Assessors (QSAs), the overheads are much higher than self-assessments. Despite such onerous efforts and overheads, even some of the more prominent retailers and well-funded organizations can’t detect their own breaches.

The reality is that most PCI organizations have limited budgets to spend on security let alone on compliance with PCI DSS. Forcing these organizations to divert much of their security funding to repeated annual compliance efforts simply doesn’t make any business or practical sense, especially considering the big question of whether these annual compliance efforts really help improve the ability of organizations to do better against breaches.

I would like to suggest the following changes for reducing compliance burden so that organizations can spend more of their security budgets on initiatives and activities that can truly reduce the risk of breaches:

  • The full scope (of all 200+ requirements or controls) may be in scope for compliance assessments (internal or by QSA) only during the first year of the three year PCI DSS update cycle. Remember that organizations may still choose not to implement certain controls based on the results of the risk assessment (see suggestion #2 above)
  • For the remaining two years, organizations may be required to perform only a risk assessment and implement appropriate changes in their environment to address the increased risk levels. Risk assessments must be performed appropriately and with the right level of due diligence. The assessment must include (among other things) review of certain key information obtained through firewall reviews (requirement 1.1.7), application security testing (requirement 6. 6), access reviews (requirement 7), vulnerability scans (11.2) and penetration tests (11.3).

 Suggestion #5 : Redundant (or less relevant) controls

PCI SSC may look at reviewing the value of certain control requirements considering that newer requirements added in subsequent versions could reduce the usefulness or relevance of those controls or perhaps even make them redundant.

For example, PCI DSS v3 requirement around penetration testing has a considerable change compared to the previous version. If the organization were to perform the penetration tests appropriately, there should not be much need for requirement 2.1 especially the rather elaborate testing procedures highlighted in the figure.

PCIDSSreq21

There are several other requirements or controls as well that perhaps fall into the same category of being less useful or even redundant.

Such redundant requirements should help make the case for deprecation or consolidation of certain requirements.  These requirements also help make the case for moving away from the all or nothing approach or philosophy we discussed under #2.

 Suggestion #6 : Reduce Documentation Requirements

PCI DSS in general requires fairly extensive documentation at all levels. We already talked about it when we discussed the topic of compensating controls above.

Documentation is certainly useful and indeed strongly recommended in certain areas especially where it helps with communication and better enforcement of security controls that help in risk reduction.

On the other hand, documentation purely for compliance purposes must be avoidable especially if it doesn’t help improve security safeguards to any appreciable extent.

…………………………………………………

That was perhaps a longer post than some of us are used to,  especially on a blog. These are the suggestions that I can readily think of. I’ll be keen to hear any other suggestions you may have yourself or perhaps even comments or critique of my thoughts.

References

1Best Practices for Maintaining PCI DSS Compliance (pdf)  by Special Interest Group, PCI Security Standards Council (SSC)
2PCI DSS Prioritized Approach (xls download)

Hello PCI SSC…

Hello PCI SSC,

You had me on board until I saw this statement in your guidance1 released yesterday.

“However, using risk as the basis for an organization’s information security program does not permit organizations to avoid or bypass applicable PCI DSS requirements or related compensating controls. In order to achieve compliance with PCI DSS, an organization must meet all applicable PCI DSS requirements.”

I believe we need a change in your “all requirements mandatory” approach. I think it leads to compliance fatigue and misguided spend of already limited security budgets.

I’ll explain in another blog post to come soon.

References
1Best Practices for Maintaining PCI DSS Compliance (pdf)  by Special Interest Group, PCI Security Standards Council (SSC)

 

PCI Breaches – Can we at least detect them?

Almost all Payment Card Industry (PCI) breaches over the past year, including the most recent one at Supervalu appear to have the following aspects in common:

1. They involved some compromise of Point of Sale (POS) systems.

2. The compromise and breaches continued for several weeks or months before being detected.

3. The breaches were detected not by the retailer but by some external entity – FBI, the US Secret Service, Payment processor, card brands, issuing bank etc.

4. At the time the breach was disclosed, the retailers appear to have had a passing PCI DSS certification.

Anyone that has a reasonable understanding of the current Information Security landscape should know that it is not a matter of “if” but “when” an organization will get compromised. Given this humbling reality, it only makes sense that we must be able to detect a compromise in a “timely” manner and hopefully contain the magnitude of the breach before it gets much worse.

Let’s consider the following aspects as well:

  1. PCI has one of the more prescriptive regulations in the form of PCI DSS and PA DSS than any other industry. As a case in point, consider the equivalent regulations for Electronic Health Records systems (EHRs) in the United States – the EHR Certification regulation (PA DSS equivalent) requirements highlighted yellow in this document and the Meaningful Use regulation (PCI DSS equivalent) requirements highlighted green. You will see that the PCI regulations are a lot more comprehensive both in breadth and depth.
  1. PCI DSS requires merchants and service providers to validate and document their compliance status every year. For the large retailers that have been in the news for the wrong reasons, this probably meant having a external Qualified Security Assessor (QSA)  performing a on-site security assessment and providing them with a passing Report on Compliance (ROC) every year.
  1. As for logging and monitoring requirements that should help with detection of a potential compromise,  both PCI DSS (Requirement 10)  and PA DSS (Requirement 4) are as detailed as they get in any security framework or regulation I am aware of.
  1. Even if you think requirement #10 can’t help detect POS malware activity, there is PCI DSS requirement 12.2 that requires a security risk assessment to be performed at least once a year. The risk assessment must consider the current threats and vulnerabilities. Given the constant stream of breaches, one would think that the POS malware threats are accounted for in these risk assessments.
  1. These large merchants have been around for a while and are supposed to have been PCI DSS compliant for several years. And so, one would think they have appropriate technologies and processes to at least detect a security compromise that results in the scale of breaches they have had.

So, what do you think may be the reasons why the retailers or the PCI regulations are not effective in at least detecting the breaches? More importantly, what changes would you suggest, both to the regulations and also to how the retailers plan and execute their security programs? Or perhaps even to how the QSAs perform their assessments in providing passing ROCs to the retailers?

I’m keen to hear your thoughts and comments.

I like the fact that the HIPAA Security Rule is not prescriptive, except…

I think it makes sense for the HIPAA Security Rule (even in its latest form from the Omnibus update)  not to be prescriptive. For one, the Rule is meant to address HIPAA Covered Entities (CEs) and now (with the Omnibus update) Business Associates (BAs) that come in all shapes, sizes and sophistication levels (Think single provider practices versus large hospital systems, one person billing coder versus large payers or clearing houses). The second reason I think it makes sense is that this is after all a Federal Government Regulation (as opposed to a industry regulation like PCI DSS). We all know how laborious and time consuming the Federal Government rule making process can be. Consider for example, the fact that the Omnibus Rule update to the HIPAA Security/Privacy Rules took more than four years after the relevant statute (HITECH Act of 2009) was signed into law. If the HIPAA Security Rule were prescriptive (like PCI DSS for example), the rule would need to be updated frequently in order for it to remain relevant in the constantly evolving environment of security threats and vulnerabilities. We know PCI DSS gets updated every three years or so, not to mention the constant stream of guidelines that PCI SSC issues.

For all that makes sense for the HIPAA Security Rule to be as non-prescriptive as it is, I think it could use one prescriptive requirement. And that is to require all CEs and BAs to have a current diagram of the PHI Data Flows. This in fact is a newly included requirement in the recently released PCI DSS 3.0 (pdf). Below is a screen capture of the the new PCI DSS requirement 1.1.3.

image

In my view, maintaining a current Data Flow Diagram showing all locations PHI is created, received, stored, processed  or transmitted is so “foundational” to Healthcare Security and Privacy programs. After all, how can one implement appropriate safeguards if one doesn’t know what and where to safeguard? It is also for this very reason that we have this requirement as the very first in our list of Top 10 PitFalls in Security/Privacy Risk Assessments.  The closest that the HHS Office for Civil Rights (OCR) comes to addressing this is buried in the last statement of the audit procedure in OCR Audit Protocol  (see screen capture below)  which says “Determine if the covered entity has identified all systems that contain, process, or transmit ePHI”. In my view, this procedure step is not good enough because “identifying systems” is not the same as having knowledge of all the PHI Data Flows.

image

In my experience, lack of knowledge of the PHI Data Flows is a very common challenge among most CEs and BAs regardless of their size or scale. The problem is especially acute when the data goes out of structured systems (EHRs, Revenue Cycle Management Applications etc.) in the form of unstructured data for one or more reasons. It is extremely hard to track and safeguard unstructured PHI so it is important that the organizations get a clear understanding of their PHI data flows and closely manage the flows. As such, any investments in a Security/Privacy program without first getting an understanding of the the data flows may not deliver the desired returns or help achieve the objective of safeguarding PHI or patient privacy.

I’ll be interested in hearing your feedback or opinions. What are your thoughts? What other prescriptive requirements would you like to see included in the HIPAA Security Rule?

Pay attention to Security Risk Analysis in Meaningful Use Attestation

As is well known, Centers for Medicare & Medicaid Services (CMS) has been conducting pre and post payment audits of healthcare provider organizations attesting to Meaningful Use (MU).  Our experience tells us that providers do not always exercise the necessary due diligence in meeting Stage I MU Core Objective #14 (Eligible Hospitals) and #15 (Eligible Professionals). In our view and as supported by ONC’s 10 Step Plan for Meeting Privacy and Security Portions of Meaningful Use, the MU Security Risk Analysis needs to go well beyond assessing just the technical controls of a EHR system. We believe that the risk analysis should cover the people and process aspects of EHR operations as well as how the EHR interfaces with other systems, organizations, people or processes.

As noted in a previous post, College of Healthcare Information Management Executives (CHIME), a professional organization for chief information officers and other senior healthcare IT leaders seemed to hold the view that the MU Security Risks Analysis scope should be limited. While we do not have a complete insight into CHIME’s viewpoint, we believe that providers need some work to do if they are to meet the requirements effectively. A robust security risks analysis is in any case the right thing to do every time there is a change in the Health IT environment … and implementing a EHR should qualify as a major change in that regard. It is also a mandatory compliance obligation under the HIPAA Security Rule.

So, why not do the “right thing”? We highly recommend that providers avoid “checkbox compliance” tendencies when it comes to meeting MU Core Objective #14/15.

Can we change the tune on Health Information Security and Privacy please?

Notice the title doesn’t say HIPAA Security and Privacy. Nor does it have any of the words – HITECH, Omnibus Rule, Meaningful Use etc. That is the point of this post.

Let us start with a question…  I am sure many of you like me are routine visitors to the blogosphere and social media sites (especially LinkedIn group discussions) to get a pulse of the happenings in Information Security and Privacy. How often do you see posts or discussions around compliance versus discussions focused squarely on risk, meaning risk to the organization or to the patients if their health information was compromised by one or the other means?

Compliance (risk of non-compliance) is only one of the risks  and in our view, should not be the primary driver for any Information Security or Privacy program. In fact, we often like to say that Compliance should be a natural consequence of  good risk management practices.

Having lived and watched Health Information Security and Privacy for nearly ten years, I am not surprised by this trend at all. Rather, I am looking forward to a day where we talk more about safeguarding the security and privacy of patient data and less about preparing for an OCR Audit. I am not suggesting that you shouldn’t worry about the latter. In fact, I’ll say that one will very likely not have to worry about the OCR or any audit for that matter if one’s real intent is to safeguard security and privacy of patient information. The real intent and objective are extremely important because they shape our thinking and how we go about executing our efforts.

I think  Security and Privacy programs in Healthcare can be a lot more effective (and likely even cost efficient) if they were to prioritize the objectives in the following order:

  • Patient Care and Safety – In most discussions on security, we tend to focus solely on confidentiality of patient information and less so on integrity and availability of the information. When we begin to think of all three security components in equal measure, it is easier to appreciate how a security incident or breach could impact patient care and safety. With the increasing adoption of EHRs, it is very likely that many health-care providers are relying solely on electronic versions of the patient records in one or more EHRs. It is possible that a security incident or breach could result in the patient record not being “available” for access by the physicians who may need to look at the patient’s treatment history before providing the patient with some urgent or emergency care.  In another possible scenario, it is possible that the security breach resulted in compromise of the integrity of the patient record itself, in which case there may be a chance that physicians end up misdiagnosing the patient condition and not providing the right treatment. Such cases were probably unlikely in a world of paper records but they are not inconceivable in a world of electronic records. These issues can result from both malicious and unintentional circumstances.
  • Patient Privacy and Loss of Trust – The impact of a healthcare privacy breach doesn’t need much discussion. The impacted individuals can face severe and lasting financial and reputational harm which can make for a very painful experience. This in turn could result in the provider losing the valuable trust of its customers. 
  • Business Risk – Healthcare businesses could face Tort or Class Action lawsuits from either of the two previous scenarios.  And then of course, there is the possibility of patients turning to competitors especially when they have access to multiple providers where they live. In effect, health care organizations could face substantial losses to their bottomlines and given the increasing competitive nature of the industry, this could put business sustainability of the organizations at risk.
  • Risks of Non-Compliance – Finally of course, there is the risk of non-compliance with industry or government regulations. Non-compliance could leave healthcare organizations facing considerable civil and possible criminal fines as well as recurring expenses from having to comply with OCR resolution agreements for example. In most instances however, the impact of non-compliance fines and expenses are only temporary in nature lasting a few years or more. On the other hand, the impact of the previous three risks could be much more significant and longer lasting.

Until we think of security and privacy as being central to patient care/safety and the business/clinical culture, it is our view that many programs will likely falter and not deliver the intended results. The new era of digital healthcare requires healthcare organizations to think of security and privacy as a business or customer issue and not something that they need to address only for compliance purposes.

In a following post, we’ll specifically discuss some examples of why thinking compliance first will not get us very far in managing health information security risks.

Compliance obligations need not stand in the way of better information security and risk management

I couldn’t help write this post when I noticed this press release based on an IDC Insights Survey of Oil & Gas Companies. I don’t have access to the full report so I am basing my comments solely on the contents of the press release.

I found the following two findings (copied from the press release) to be of interest :

  • Security investments are not compliance driven. Only 10% of the respondents indicated that they are using regulatory compliance as a requirement to justify budgets.
  • Tough regulatory compliance and threat sophistication are the biggest barriers. Almost 25% of respondents indicated regulatory environment as a barrier to ensuring security. In addition, 20% of respondents acknowledged the increasing threat landscape.

The good news here is that only 10% of the respondents used Regulatory Compliance needs to justify budgets. What that tells me (I hope it is the case) is that the remaining 90% make budgetary decisions based solely on the information security risks that their  businesses face and not on the risks of not complying with regulations or audits. I would commend them for it… and I don’t think any good auditor (regulatory or internal/external) would have a problem with it either if the organization was able to “demonstrate” that the risk of not complying with a particular regulatory requirement was very low. Agreed.. you still need to be able to “demonstrate” which isn’t easy if one hasn’t been diligent with risk assessments.

The not-so-good news to me is the 25% number (I realize it might be low enough for some people)..  that of folks indicating that regulatory compliance is a barrier to ensuring security. For those folks, I say “It really doesn’t need to be a barrier”, not if you have good   information risk management governance and processes. I don’t know a single regulation that would force you to implement specific controls no matter what. Even if you are faced with an all-or-nothing regulation like PCI DSS, you can resort to using compensating controls (see here and here for some coverage of PCI DSS Compensating controls) to comply with a specific mandatory requirement.  To repeat my argument in the previous paragraph, an auditor would be hard-pressed to fault you if you were able to clearly articulate that you went about the compliance program  methodically by performing a risk assessment and prioritizing (by risk level) the need for specific controls required by the regulation. If you did that, you would focus on ”ensuring security” and not ignoring it for the sake of compliance.

Do we have a wake-up call in the OIG HHS Report on HIPAA Security Rule Compliance & Enforcement?

If you didn’t notice already, the Office of Inspector General  (OIG) in the Department of Health and Human Services (HHS) published a  report on the oversight by the Center for Medicare and Medicaid Services (CMS) in the enforcement of the HIPAA Security Rule. The report is available to the public here.   As we know, CMS was responsible for enforcement of the HIPAA Security Rule until the HHS  Secretary transferred that responsibility over to the Office of Civil Rights (OCR) back in 2009.

To quote from the report, the OIG conducted audits at seven covered entities (hospitals) in California, Georgia, Illinois, Massachusetts, Missouri, New York, and Texas in addition to an audit of CMS oversight and enforcement actions.  These audits focused primarily on the hospitals’ implementation of the following:

  • The wireless electronic communications network or security measures the security management staff implemented in its computerized information systems (technical safeguards);
  • The physical access to electronic information systems and the facilities in which they are housed (physical safeguards); and,
  • The policies and procedures developed and implemented for the security measures to protect the confidentiality, integrity, and availability of ePHI (administrative safeguards).

These audits were spread over three years (2008, 2009 and 2010) with the last couple of audits happening in March 2010. The report doesn’t mention  the criteria by which these hospitals were selected for audit except that these  hospitals were not selected because they had a breach of Protected Health Information(PHI) .

It wouldn’t necessarily be wise to extrapolate the findings in the report to the larger healthcare space in general without knowing how these hospitals were selected for audit. All one can say is that the findings would paint a worrisome picture if these hospitals were selected truly in a random manner.  For example, if one were to look at ”High Impact” causing  technical vulnerabilities, all 7 audited hospitals seem to have had vulnerabilities related to Access and Integrity Controls, 5 out of  7 had vulnerabilities related to Wireless and Audit Controls and  4 out 7 had vulnerabilities related to Authentication and Transmission Security Controls.

image

What might be particularly concerning is that the highest number of vulnerabilities were in the Access and Integrity Controls categories.  These are typically the vulnerabilities that are exploited most by hackers as evidenced (for instance) by the highlight in this quote from the 2011 Verizon Data Breach Investigation Report – “The top three threat action categories were Hacking, Malware, and Social. The most common types of hacking actions used were the use of stolen login credentials, exploiting backdoors, and man-in-the-middle attacks”.

Wake-up call or not, healthcare entities should perhaps take a cue from these findings and look to implement robust security and privacy  controls. A diligent effort should help protect organizations from the well publicized consequences of a potential data breach.

Next time you do a Risk Assessment or Analysis, make sure you have Risk Intelligence on board

I was prompted to write this quick post this morning when I read this article.

I think it is a good example of what some (actually many, in my experience) risk management programs may be lacking, which is a good quality of Risk Intelligence. In this particular case, I think the original article failed to emphasize that vulnerabilities by themselves may not mean much unless there is a good likelihood of them being exploited, resulting in real risk.  We discussed some details regarding the quality of risk assessments in a previous post.

A good understanding of information risks and their prioritization needs to be the first and arguably the most important step in any information risk management program. Yet, we often see risk assessment initiatives not being done right or at the right quality. We think it is critical that a risk analysis or assessment is headed by someone or performed by a team that has or does the following:

  1. A very good understanding of your environment from people, process and technology perspectives
  2. A very good and up-to-date intelligence on the current threats out there (both internal and external) and is able to objectively define those threats
  3. Is able to clearly list and define the vulnerabilities in your environment. It will often require  process or technology specialists to do a good job of defining the vulnerabilities
  4. Is able to make an unbiased and objective determination of the the likelihood that the vulnerabilities (from Step 3) can be exploited by one or more threats (from Step 2)
  5. A very good understanding of the impact to the business if each vulnerability were to be exploited by one or more threats. Impact is largely a function of the organization’s characteristics including various business and technical factors, so it is important that you involve your relevant business and  technology Subject  Matter Experts.
  6. Based on the likelihood (Step 4) and impacts (Step 5), estimate risks and then rank them by magnitude.

We just can’t stress the importance of steps 1-5 enough. We think it takes “Risk Intelligence” to do these steps well. Without good Risk Intelligence on your team, you may well be wasting precious time, money and resources on your risk assessments.  More importantly, you may not be protecting your business to the extent that you should, with the same budget and resources.

======================================

Important Disclaimer

The guidance and content we provide in our blogs including this one is based on our experience and understanding of best practices. Readers must always exercise due diligence and obtain professional advice before applying the guidance within their environments.

Providers – Is HIPAA Security Risk Analysis in your plan over the next few months?

Security Risk Analysis is something that we recommend all organizations conduct periodically or before a  significant process or technology change. After all, threats, vulnerabilities and impact (three components of risk, see my other post here) often change or evolve over time which means that risk analysis results can soon become outdated.

In the context of Healthcare, Security Risk Analysis is also mandatory for two reasons.

The first reason is that it is required for compliance with HIPAA Security Rule which, by way of the HITECH Act, now applies to Business Associates in addition to Covered Entities.  It is a “Required” Implementation Specification in the “Security Management Process” standard under Administrative Safeguards of the HIPAA Security Rule, as highlighted in the table below.

image

The second (and more urgent) reason to conduct a Security Risk Analysis is that it is a core requirement for providers to achieve Meaningful Use certification of Electronic Health Records (EHRs) and thereby become eligible for Medicare/Medicaid incentives beginning April 2011 or risk Medicare reimbursement penalties beginning 2015 (see below).

image image

clip_image001[3]

Source: Center for Medicare & Medicaid Services (CMS)


So, it is important that providers plan on conducting a security risk analysis within the next few months unless you have conducted one recently. If you have already implemented an EHR system, you will need to ensure that the risk analysis included the EHR system and the related processes or practice workflows. If you plan to implement an EHR system in the next few months, we would recommend conducting risk analysis before the implementation so that any discovered risks can be identified and mitigated by proper design of the system and associated workflows or processes.  Any change to the system or processes after implementation is going to be hard, not to talk of the disruption to the practice and other costs.

The Final Guidance from OCR on Risk Analysis can be a useful reference in planning and conduct of risk analysis efforts.

Finally, I would like to go back to what I said right at the beginning. We recommend that organizations focus on managing all information risks, not just the risk of non-compliance with regulations such as HIPAA.  Therefore, it is critical that personnel performing the risks analysis are up-to-date on the current threat environment. Upon determination of the threats, one must be able to clearly identify the organization’s vulnerabilities to those threats and then the impact resulting from any exploits and various legal or compliance obligations including HIPAA.  Last but not the least, risk analysis must be conducted at appropriate intervals and certainly whenever there is a significant change in processes or technologies.

—————————————-

Important Disclaimer

The guidance and content we provide in our blogs including this one is based on our experience and understanding of best practices. Readers must always exercise due diligence and obtain professional advice before applying the guidance within their environments.

Older posts