HITRUST Part 2: Taking a First Look at the CSF

As a continuation of the HITRUST blog series, in this post I would like to take a closer look at the Common Security Framework CSF, and what it’s all about.

The CSF is designed based on the ISO/IEC 27001:2005 and ISO/IEC 27002:2005 standards. Additionally, the framework currently includes:

• NIST 800 series of standards
• ISO/IEC 27799:2008 Health Informatics
• COBIT
• PCI
• HIPAA
• HITECH Act
• FTC 16 Red Flags Rules

HITECH is planning to add other regulatory requirements and standards, such as EHNAC’s Healthcare Network Accreditation Program (HNAP-EHN), Healthcare Information Technology Standards Panel, and CMS Information Security (IS). However, the real value of the framework is not in that it provides a clear cross-reference between these and future requirements, since this information is already available within a broad range of compliance management tools, but rather that the reconciliation of the different standards and the additions of the controls are based on experiences and best practices from the HITRUST participants.

Each control described within the framework includes basic information such as control objectives, descriptions, and a few different categories that it may be associated with. Additionally, each control includes the following, which differentiates it from others:

• Control Implementation – This is a prescriptive description of a control that provides     detailed information about different aspects of implementation.
• Control Audit Procedures – Detailed instructions that clearly document the steps that CSF assessors should take in order to accurately ascertain compliance with the specific control.
• Control Standards Mapping – All regulatory requirements and standards that apply to the particular control.
• Alternative Controls – Compensating controls that have been approved by HITRUST, that may be used in place of the controls listed. All organizations may submit their alternative or compensating controls to HITRUST for approval, which will subsequently include them in the framework for the benefit of other companies.
• Required for Certification – Some controls are marked as required for certification, while others are only recommended for compliance with specific regulatory requirements. (I know that ability to certify while not being compliant is odd, but hang in there, I will tackle this topic in the next blog post).
• Organizational or System – Organizational controls are implemented for the entire organization, while system controls should be implemented and audited on each system containing ePHI.

The engine supporting the framework allows easy searching and navigation of the framework. Additionally, all regulatory requirement and standards references are presented as hyperlinks that will navigate directly to the original authoritative sources. HITRUST also has created several reports that can enable companies to determine gaps within any of the regulatory standards, based on the framework control references. Overall, since the framework is available free of charge, I strongly recommend people to register with HITRUST and browse around.

In addition to providing a list of controls, HITRUST has also incorporated different levels of implementation for different controls. These are guided by the size of the organization, and range from Level 1 (most basic implementation) to Level 3 (most advanced security). Therefore, in order to understand which level of implementation would be applicable for a specific organization, it’s important to pay attention to the organizational and system factors, which include a wide range of consideration such as the need for PCI compliance, number of patient visits or hospital beds, number of employees, internet connectivity, or many others. However, in order to allow for easier and more automated determination, HITRUST has created spreadsheets where an organization simply needs to fill out some basic information, and the next tab will provide the required levels of implementation for each control.

To summarize, the CSF is specific, prescriptive, and scalable, providing not only guidance for implementation, but also for validation and attestation of compliance. The framework is intended to be in continuous development, by addition of formally accepted alternative controls, as well as entity type specific implementation requirements. Another important misconception is that CSF is a new standard. In truth, the CSF is an interpretation of other existing standards. Therefore, even if adopting a relatively new framework seems like a risky investment of time and resources, I would encourage organizations to at least become familiar with it. You never know, you just might find some great ideas that may be applicable for your environment.

In the next post in this series, I will focus on the topic of HITRUST certification, and what it means in the context of compliance with other regulatory requirements such as HIPAA, HITECH, and PCI.