Data Centers with SOC 2 Reports Stand Out

Congratulations to Reliable Networks on their completion of a SOC 2 engagement.  Great press release too!

How to Explain SOC 2 to Your Clients Who Are Still Asking for SSAE 16

If you have made the decision to go with a SOC 2 because it is the right report for your organization, but you still have customers who are asking for a SOC 1 (SSAE 16), here's what you can tell them.

Dear Customer, 

We have determined through careful examination of our services, and in consultation with our CPA firm that SOC 1 (SSAE 16) is not applicable to us because our services do not have the potential to impact the accuracy of our customer's financial statements.  Our customers have expressed the need to obtain assurance pertaining to our internal controls as they relate to the security, integrity, confidentiality, and privacy of the data we process, store, or transmit for them, as well as the availability of the systems we host for them.  Consequently, we have selected to undergo a SOC 2 engagement that is based on the same family of standards as SSAE 16, but is more applicable to the services we provide our customers.  

Our SOC 2 report, based on SSAE 10, 11, 12, and 14; cumulatively referred to as AT-101, provides assurance regarding security, availability, processing integrity, confidentiality, and privacy.  It is not intended to provide our customers with assurance relevant to internal controls over financial reporting (ICFR).  If your internal or external auditors require supporting documentation regarding how we determined that our services  do not pertain to our customer's ICFR process, we will be happy to provide the information to them upon request.

Thank you very much for your business.

You will have to tailor the references to all five TSPC principles if you only received an attestation on a subset of the five (ie. just security and availability).

If your CPA firm has not helped you document why your internal control environment does not have ICFR impact on your customers, then you can contact me at, and I will document it for you using the Degrees of Risk Separation (DoRS) approach to determining ICFR.

Your Vendor's SOC 2 Report may be Inadequate

It took a year and a half, but the market finally understood that SOC 1 (aka SSAE 16) cannot be relied upon for assurance regarding security, availability, processing integrity, confidentiality, or privacy (SAPICP).  The misuses of SOC 1 that I chronicled since December of 2011 have started to taper off, and people are asking for SOC 2, the correct report for assurance regarding SAPICP.  Great.  

Now the challenge for everyone receiving SOC 2 reports from their vendors is the question of adequacy.  For example, take a look at your vendor's controls associated with Security Principle 1.2d "Preventing Unauthorized Access."  This control is a good indicator of whether the company had a thorough assessment of their internal controls or not.

One company's failure to prevent unauthorized access was what enabled a U.S. developer to outsource his own job to China.  The point of failure in this case was the company's lack of VPN concentrator log reviews.  Does your vendor's internal control associated with Security 1.2d or 4.1 include a daily review of VPN connections to the network by a competent and independent person?  What are the criteria that would trigger an investigation?  Keep in mind that internal threats are just as important to consider as external ones.

It is a good idea to compare your own organization's security controls with those listed in your vendor's SOC 2.  If your vendor's SOC 2 does not measure up, their SOC 2 report is inadequate.  Consider sending your security questionnaire to your vendor, and asking them to explain how each control in their SOC 2 maps to your questionnaire.  Below are some control areas that should be addressed in Security 1.2d 

• Remote access controls (including monitoring of logs)
• System account creation, modification, or deletion
• Root admin accounts usage (Unix/Linux environments)
• Service account controls
• Network equipment access controls
• Domain administrator access controls
• Inactivity timer/ automatic log-off
• Account lockout 
• Account re-certification 
• Disabling accounts inactive more than 90 days 
• Sharing of user accounts and passwords
• First time passwords 
• Password history, aging, and length
• Requests for user password reset 
• Password exceptions – non-expiring passwords
• Storing passwords in readable form
• Password complexity

Even within the control areas above, there is opportunity for weak security controls.  One of my favorite vulnerabilities to point out is the minimum password age setting.  For example, if you require password changes every 90 days, and have a 5 passwords remembered policy, but have a minimum password age set to 0, then I can simply change my password 6 times every 90 days, and get back to the password I like.  There are a million examples like this where seemingly secure control environments can be bypassed.

If you are a service organization seeking to provide your customers with a SOC 2 report that will not be rejected as inadequate, I recommend choosing a CPA firm that has security as one their core competencies, or one who has partnered with a security firm like CompliancePoint.