SOC 2 vs. SOC 2 + HITRUST: Why Compliance with One Doesn’t Guarantee the Other

HITRUST Certification is a globally recognized program that validates an organization’s compliance with the HITRUST Common Security Framework (CSF). An alternative to obtaining a HITRUST CSF Certification is the SOC 2 + HITRUST report, which serves as a collaboration between HITRUST and the AICPA. 

Although both frameworks assess comparable principles, completing a SOC 2 audit does not ensure success with SOC 2 + HITRUST due to key differences in control definition, implementation, and evaluation. In this article, we’ll use a real-world example to break down the notable distinctions between SOC 2 and SOC 2 + HITRUST. This way, you’ll better understand how compliance with one framework doesn’t automatically ensure compliance with the other. 

SOC 2 Report vs. SOC 2 + HITRUST Certification 

A SOC 2 report requires that a service organization has sufficient control activities in place to address the Trust Services Principles and Criteria (TSPC) developed by the AICPA. However, there are no stipulations by the AICPA as to what those control activities have to be. As long as the criteria are satisfactorily addressed to align with the risks that a service organization has identified, a service organization has some flexibility with the controls they implement. 

That being said, SOC 2 + HITRUST does not provide that same level of flexibility because HITRUST has predefined their control specifications, which have been mapped to the TSPC to which they apply as additional subject matter. This means that a control activity that was sufficient to satisfy a criterion for SOC 2 may not be sufficient for compliance with SOC 2 + HITRUST. A real-world example is the difference in password management requirements for each framework, as outlined below. 

Password Management Requirements in SOC 2 

The HITRUST control specification “01.d User Password Management” maps to TSP CC6.1 and CC6.6 for SOC 2 compliance. The criteria for CC6.1 and CC6.6 are as follows: 

• CC6.1: The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity’s objectives. 

• CC6.6: The entity implements logical access security measures to protect against threats from sources outside its system boundaries. 

Note that TSPC CC6.1 and CC6.6 require logical access security measures to be in place, but they don’t specify any minimum requirements for the parameters. Therefore, the service organization has some flexibility as to what they feel are sufficient controls for their system, along with the commitments they make as an entity.  

Password Management Requirements in SOC 2 + HITRUST 

The list below outlines the HITRUST control specifications, which must be examined for SOC 2 + HITRUST compliance. 

The following controls shall be implemented to maintain the security of passwords: 

1. Password policies applicable to the organization’s information systems are documented and enforced through technical controls. 
2. The organization changes all default passwords for applications, operating systems, routers, firewalls, wireless access points, and other systems to have values consistent with administration-level accounts before deploying any new devices in a networked environment. 
3. Authentication credentials are provided using a secure method. 
4. User identities are verified prior to performing password resets. 
5. Passwords are not included in any automated log-on process (e.g., stored in a macro or function key). 
6. Users acknowledge receipt of passwords. 
7. The organization has implemented the following controls to allocate and maintain the security of passwords:  
   1. Passwords are changed whenever there is any indication of possible system or password compromise 
   2. Default vendor passwords are altered following installation of systems or software 
   3. Temporary passwords are changed at the first log-on and require immediate selection of a new password upon account recovery 
8. All passwords are encrypted during transmission and storage. 
9. Users sign a statement acknowledging their responsibility to keep personal passwords confidential and to keep group passwords solely within the members of the group. 
10. Temporary passwords are unique to an individual and are not guessable. 
11. Password settings are configured to not display passwords in plain (or clear) text by default. 
12. The organization must:  
    1. maintain a list of commonly used, expected, or compromised passwords 
    2. update the list of commonly used, expected, or compromised passwords at least every 180 days 
    3. update the list of commonly used, expected, or compromised passwords when organizational passwords are suspected to have been compromised, either directly or indirectly 
    4. verify, when users create or update passwords, that the passwords are not found on the organization-defined list of commonly used, expected, or compromised passwords 
    5. allow users to select long passwords and passphrases 
    6. allow users to select passwords and passphrases containing spaces and all printable characters 
    7. employ automated tools to assist the user in selecting strong passwords and authenticators 
13. The organization avoids the use of third-parties or unprotected (clear text) electronic mail messages for the dissemination of passwords. 

Note that specification 12 above requires an organization to update the list of commonly used, expected, or compromised passwords at least every 180 days. This becomes a minimum requirement for SOC 2 + HITRUST and would result in a deviation if the update was performed annually; whereas, if an organization were undergoing a SOC 2 and defined in their policies that an annual update was suitable for the organization’s risk level, the SOC 2 report would have no deviation. 

Moving Forward with SOC 2 or SOC 2 + HITRUST Compliance 

In short, each framework has differences in scope of what is assessed and includes a different level of flexibility in how those controls are examined. Hopefully the example above, which includes several HITRUST specifications, helps demonstrate that what would be sufficient for SOC 2 may not fully address the SOC 2 + HITRUST requirements. 

If your goal is to complete both SOC 2 and SOC 2 + HITRUST, you need to go beyond meeting general criteria. You’ll need to understand HITRUST’s control specificity, align your policies and configurations to HITRUST’s detailed implementation requirements, and conduct a readiness assessment that flags gaps early.  

If you’re ready to proceed with your SOC 2 Examination or SOC 2 + HITRUST Certification, or have additional questions about the differences, processes, or requirements involved, Schellman can help. Contact us today and we’ll get back to you shortly.  

In the meantime, discover additional insights in these helpful resources:  

• The Benefits of Consolidating Compliance Services with a Single Provider 
• What is SOC 2 + HITRUST? 
• 5 Steps to Prepare for SOC 2 Examination Success