Last week I wrote about data centers, that only provide hosting services to their clients, not needing a SOC 1, and I received more comments than I've ever received from auditors arguing that physical security is relevant to ICFR. I think I've finally figured out why SOC 2 was ignored for the most part in year one of SOC reports.
I assumed that the lines were as clear to everyone as they are to me about what is relevant to ICFR and what is not. I thought service auditors would require their audit clients to remove non-ICFR controls from their SOC 1 system descriptions, and that user organizations who had become used to receiving assurance regarding non-ICFR domains would require their vendors to provide them a SOC 2.
Judging by everything I've heard, read, and observed, I think that most people are comfortable with considering almost any ITGC control as relevant to ICFR. If non-ICFR controls get to stay in SOC 1, then there is no need for SOC 2. SOC 1 may not be designed to provide, but can provide adequate assurance regarding security and availability when enough non-ICFR controls are allowed in .
If SOC 1 can contain any and all ITGC controls, and SOC 2 is just supposed to be a deeper dive, then it is no wonder that people took a pass. Put yourself in their shoes. My customers have been happy with the report I've given them every year, and my auditor is not going to make me eliminate any of the controls that were previously included in my SAS 70 report. Hmmm, hard decision, I'll take a SOC 1 please.
We have to be honest with ourselves, and ask the question, "Why did SAS 70 get misinterpreted as providing assurance regarding security and availability?" Could it be that it was because SAS 70 contained security and availability related controls? I think the answer to this question will tell us what needs to happen in order to correct the path that SOC 1 is on.