As a security professional, you’ve no doubt heard about Service Organizational Control (SOC) Reports in security conversations. When the need arises for determining how “secure” prospective vendors’ and business partners’ data centers are, simply ask for their SOC 1 or SOC 2 report. That is, if it hasn’t already been shoved in your face.
SOC 1 reports (typically the Type II version) are the go-to documents for seemingly all things security related. The problem is they’re creating a false sense of security. I’ve seen this first-hand time and time again, going back to the SOC’s predecessor, the SAS70. SOC 1 and SOC 2 audits/reports most definitely have their place in business, and the AICPA has done a good job developing these standards and there are many capable auditors performing the audits. The problem is not with the SOC audits or reports themselves but rather with those who are reading them.
The trouble begins when non-technical – and sometimes technical – managers and executives review SOC reports to, presumably, help them make informed decisions about who they’re doing business with. You see, every SOC report I’ve ever reviewed, and no doubt most of the others that are floating around, paint a positive picture of security. Everything, or at least most things, look good, on these reports. Therefore all must be well. Not so fast. Security goes much deeper and you need to be prepared to see, as Paul Harvey used to say, the rest of the story.
Here are just four examples of security flaws that will likely never be documented in a SOC report but can create immeasurable security risks for all parties involved:
These items can create way more risk than any higher-level administrative, physical, and incident management policies and procedures reviewed by SOC auditors.
So before you assume all is well with the security based on a vendor’s SOC reports, you have to dig in deeper. Ask to see their latest penetration test or vulnerability assessment report. Look at the technical issues even more closely that you would higher-level policies and procedures.
If you skip over the technical issues, there’s no way to truly understand the security posture of the environment in question. You can’t afford a security vulnerability that flies under the radar, especially once the flaw gets exploited and you get called out. Ensure that everything that matters is found and fixed, and not just the tip of the iceberg.
Receive notifications of new posts by email.