Can my organization successfully complete a SOC 2 but still not successfully complete a SOC 2+HITRUST?

The short answer is...yes.

Now for the long answer - 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.  For that examination, HITRUST has predefined their control specifications, which have been mapped to the TSPC to which they apply as additional subject matter.  So, a control activity that was sufficient to satisfy a criterion for SOC 2 may not be sufficient for SOC 2+HITRUST. 

Here’s an example. 

HITRUST control specification “01.d User Password Management” maps to TSPC CC5.1 and CC5.3.  The criteria for those two TSPC are as follows:

CC5.1: Logical access security software, infrastructure, and architectures have been implemented to support (1) identification and authentication of authorized internal and external users; (2) restriction of authorized internal and external user access to system components, or portions thereof, authorized by management, including hardware, data, software, mobile devices, output, and offline elements; and (3) prevention and detection of unauthorized access to meet the entity’s commitments and system requirements as they relate to security, availability, processing integrity, confidentiality, or privacy, or any combination thereof.

CC5.3: Internal and external users are identified and authenticated when accessing the system components (for example, infrastructure, software, and data) to meet the entity’s commitments and system requirements as they relate to security, availability, processing integrity, confidentiality, or privacy, or any combination thereof.

Note that the two TSPC require user authentication parameters 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.  However, below is what the HITRUST control specification states and must be examined for SOC 2+HITRUST:

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

1. Passwords shall be prohibited from being displayed when entered;
2. Passwords shall be changed whenever there is any indication of possible system or password compromise; and
3. User identity shall be verified before performing password resets.

The allocation of passwords shall be controlled through a formal management process:

1. The use of third parties or unprotected (clear text) electronic mail messages shall be avoided;
2. Users shall acknowledge receipt of passwords;
3. Default vendor passwords shall be altered following installation of systems or software;
4. When users are required to maintain their own passwords they shall be provided initially with a secure temporary password, which they are forced to change immediately;
5. Temporary passwords shall be changed at the first log-on;
6. Temporary passwords shall be given to users in a secure manner;
7. Passwords shall be changed at least every 90 days or based on the number of accesses;
8. Passwords for privileged accounts shall be changed at least every 60 days;
9. Passwords shall require at least eight (8) characters which are:
   1. Easy to remember;
   2. Not based on anything somebody else could easily guess or obtain using person related information (e.g., names, telephone numbers, and dates of birth etc.);

   3. Not vulnerable to dictionary attack (do not consist of words included in dictionaries);

   4. Free of consecutive identical characters; and

   5. A combination of alphabetic, upper and lower case characters, numbers, and special characters (combination of any three [3] of the above four [4] listed is acceptable);

10. Passwords shall be prohibited from being reused for at least four (4) generations for users or six (6) generations for privileged users; and
11. If the operating environment allows, at least four (4) changed characters are changed when new passwords are created.

Alternatively, passwords/phrases must have a strength (entropy) at least equivalent to the parameters specified above.

Password policies that are applicable to mobile devices shall be documented and enforced through technical controls on all company devices or devices approved for BYOD usage, and shall prohibit the changing of password/PIN lengths and authentication requirements.

If you’re still reading this article after all that HITRUST requirement text, kudos to you. Now, note that specification 8 above requires password expiration of 60 days for privileged accounts.  That becomes a minimum requirement for SOC 2+HITRUST and would result in a deviation (exception) if the configuration was set for 90 or even 75 days; whereas, if an organization was undergoing a SOC 2 and defined in their policies that 90-day expiration was suitable for the organization’s risk level, the SOC 2 report would have no deviation.

In short, each examination focuses on the differences in scope of what is examined and a different level of flexibility in how those controls are examined. Given the previous example, which included several HITRUST specifications, hopefully this clarifies the method for future examinations--what may be sufficient for SOC 2 may not fully address SOC 2+HITRUST requirements.