Today, Friday, June 15th, 2012 is the one year anniversary of the launch of SOC (formerly SAS 70) reports, so I think it is an appropriate time for reflection on what went wrong with the launch, and a good time to ask for your help in pushing a solution forward that I have presented to the AICPA. I assume that, by now, everyone knows what SOC reports are, so I will not go into detail about them. Instead I will speak about what I hoped they would be, and express the reason I believe that SOC 2 is destined to fail unless we take action now. I will also explain how we have the opportunity to keep SOC 2 from failing if we unite behind an approach I call the Degrees of Risk Separation (DoRS) method.
The first time I heard about SOC reports, and learned that SOC 2 would be a report that offers assurance regarding security, availability, processing integrity, confidentiality, and privacy (SAPICP), I was pretty excited that the market would finally get period-of-time assurance from third parties regarding those important domains. Despite claims to the contrary, it is a fact that every other attestation and "certification" currently available in the market is a point-in-time assurance. I have explained the differences and why period-of-time is a superior assurance in previous posts. However, when I read that SOC 2 could incorporate "other subject matter" such as ISO 27001, PCI, HIPAA, NIST, and the Cloud Controls Matrix, I saw HUGE opportunity.
As I have explained in depth in previous posts, SOC 2 has the potential to be a report that unifies the risk assurance industry by consolidating multiple audits, standards, and compliance requirements clients have, under one umbrella engagement. The SOC 2 report will never be able to replace the other compliance requirements, but combining the audits will enable testing to be conducted just once if CPA firms partner with firms specializing in the other compliance areas or specialize in the areas themselves. The potential for SOC 2 is monumental for service organizations. Not only will organizations be able to reduce their overall compliance related costs, they will also be receiving a superior period-of-time assurance. SOC 2 screams success for everyone involved: service organizations get reduced audit fees by combining audit requirements, user entities get better assurance from their vendors, service auditors get to expand their domains into the security market, and security professionals get to work along side of CPA firms winning engagements they may not have previously won as a result.
My expectation was that the market would see SOC 2 for the huge opportunity that it is, but I was wrong. I began seeing signs that the market did not understand the potential of SOC 2 back in December of last year when I received a SOC 1 report from my company's data center and reviewed it to see if there were any differences in the controls that were covered by the report. There were no differences. All of the controls that were previously covered by the data center's SAS 70 were covered by the SOC 1 report. It was about the same time that I became active in social media, and noticed a flurry of companies reporting that they had received their "SAS 70 replacing SSAE 16 report." They claimed that their SOC 1 report proves how secure and reliable their environment is, but SOC reports were supposed to correct this misuse and misinterpretation that prevailed under SAS 70. Like SAS 70, SOC 1 (aka SSAE) is not designed to provide assurance regarding SAPICP. Fictitious logos touting "SSAE 16 Certification" popped up on websites everywhere, and I decided that I had to try to do something, so I started blogging and trying to raise awareness.
I believe that the launch of SOC reports failed in year one because no one was forced to adhere to the standards behind SOC reports that require SOC 1 reports to address only internal controls over financial reporting (ICFR). If service organizations were required to remove non-ICFR controls from their reports, they would have had to transition to SOC 2 to provide the same assurance they were previously providing their customers with their SAS 70 reports. There is a problem though. No one has defined what an ICFR control is, and there is no official approach to determining what an ICFR control is either. The only test the AICPA standard provides is that the control must be "reasonable in the circumstances." I understand why the AICPA used this language. It is very important to make sure auditors are given latitude to exercise professional judgement so they can accommodate various circumstances that may exist in particular client environments. If however, the market is allowed to define anything as ICFR, or say that inclusion of non-ICFR controls in SOC 1 is okay in some cases as one leading firm did recently, SOC 2 is destined to fail. The reason is that SOC 2 is more rigorous, and many service organizations would rather receive an audit they are comfortable passing than transition to SOC 2 and risk failing.
This is where I had an idea...what if there were a standardized, official approach to determining what an ICFR control is that preserves auditor judgement and accommodates circumstances in specific client environments? I have introduced the approach I use in previous posts, but finally finished a whitepaper on the DoRS method over the weekend after I was asked to do so by a Fortune 100 company. You can review and download the whitepaper below.
I have also started a petition to the AICPA for the official adoption of the DoRS method, and would like to ask for your support. At the time of this post, we already have over 65 signatures, and momentum is building. Please consider endorsing the DoRS approach to determining what an ICFR control is thereby helping to ensure that SOC 2 does not fail. The petition form is also below.