January 31, 2019 | Posted in GRC and Strategy by Corrin Woodard and Mike Pinch


  • In December 2018,  the Healthcare and Public Health Sector Coordinating Council (HPH SCC) released guidance, in coordination with the Department of Health and Human Services (HHS), in order to enhance cybersecurity across the healthcare industry.
  • The guidance is a fairly prescriptive, which comes with pros and cons.
  • It’s a great step right direction, however the depth of guidance in each practice area varies.

It’s no secret that the Healthcare industry, primarily providers, are behind other industries in their cybersecurity posture. Providers are faced with the unique challenges of making health information available electronically both inside and outside of their environments 24/7, complying with a laundry list of regulations, and doing it all while keeping information accurate and secure. Recently, guidance was released by the Healthcare and Public Health Sector Coordinating Council (HPH SCC) in coordination with the Department of Health and Human Services (HHS) in order to try to address this problem.



This is the most prescriptive guidance we’ve seen HHS stand behind. It differs from guidance released in the past because it focuses on technology and capabilities and was built to be adaptable to the size and complexity of an organization. It could provide a detailed technical roadmap for an organization to mature and grow and makes a good board level artifact to measure progress against.

While the level of detail provided varies in each of the 10 practice areas in the guidance, it does deeply dive into technical capabilities in some areas. For example, the practice of “Endpoint Protection Systems” lists detailed controls for basic endpoint security such as turning on endpoint encryption. It goes on to provide specifications for how to implement this control such as encrypting new devices, using an encryption management system that interfaces with multiple operating systems, monitoring encryption status, processes to dispatch teams to troubleshoot errors, using physical locks where endpoint encryption can not be applied, and leveraging network access controls for validation checks.

Each control is accompanied by a description that includes an indication of why the control should be implemented. The guidance goes a step further to tie the practice areas to threats. By implementing the recommended controls listed in the example above an organization could reduce the impact and/or likelihood of equipment loss/theft.  This information could help security leaders provide a clearer picture of capabilities within their organization, and build convincing business cases to gain support from executive stakeholders.

While the guidance is a step in the right direction, sections of the guidance are not structured consistently and the depth of guidance in each practice area varies. In addition, we noticed it skips some cornerstone concepts needed for an effective cybersecurity program.

The mapping to the NIST CSF included in the guidance does not include about 51 sub-categories of the NIST CSF, including many related to risk management and risk assessment. In fact, the terms Risk Analysis, Risk Assessment, and Risk Management only appear briefly in the main document of the guidance. We found this interesting since any good set of controls should be based on the concept of minimizing risks. How does an organization minimize risks if it has not identified its risks? Additionally, we know that performing an annual security risk analysis and implementing a program to manage risk are cornerstones of HIPAA Security compliance.

The guidance is not mapped to the HIPAA Security Rule or other regulations. The lack of clear connections between this guidance and HIPAA indicates to us that following this guidance would not result in an organization being considered compliant with HIPAA. A HIPAA Risk Analysis would still be required on an annual basis.

So, what is the bottom line?

  • Goes beyond what tools you should focus on, including the features and capabilties you should have for those tools
  • Its not overly complex
  • Easier to use as a communciation mechanism then a full-blown framework
  • It is not a security framework
  • Mapping to the NIST CSF is not complete
  • Its not mapped to HIPAA
  • It is not a “get out of jail free card” for HIPAA compliance
  • It is not your HIPAA risk analysis
  • Since this guidance is partially mapped to the NIST CSF, it may be a good way to take something you’re already doing (like a HIPAA Risk Analysis) and provide a clearer lens of capabilities to executive stakeholders, to get support for initiatives.

    While compliance and security are not the same thing, SRA can help your organization meet both of these goals. SRA has embedded this guidance into our services targeted to Healthcare organizations.

    Our existing HIPAA Security Risk Assessment approach covered most of these controls because we understand that the intention of the HIPAA Security Rule goes beyond what is printed in black and white.  Our new, enhanced HIPAA Security Risk Assessment approach maps to this guidance and has been expanded to include each specific sub-practice outlined in the guidance for Medium and Large organizations.

    Our existing NIST CSF Assessment approach has also been modified to create a new HICP Assessment for Healthcare providers, which covers the specific aspects of this guidance as mapped to the NIST CSF. Again, we have mapped this guidance more completely to the NIST CSF for expanded coverage.

    Want to discuss how SRA can help you? Contact Mike Pinch or Corrin Woodard for more information.