Don't Mess With SOX

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.

The driving force behind SAS 70 was the Sarbanes Oxley (SOX) act, and service organizations were required to provide it to their customers who are publicly traded.  SOC 2 is not relevant to ICFR, and therefore is not relevant to SOX, but SAS 70 was being relied on for more than ICFR!  It had morphed into the defacto standard for providing assurance regarding security, availability, processing integrity, confidentiality, and privacy.  SOC 1 is not designed to provide assurance regarding security, availability, etc., and it cannot contain controls that do not relate to ICFR.

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.

Datacenters Do Not Need a SOC 1 Just Because They Host a Financially Relevant Application

I have heard on more than one occasion that a datacenter was told by their service auditor that they need an SSAE 16 (SOC 1) report because they are hosting applications that are relevant to their customer's financial reporting.

Okay, well what if the datacenter does not have logical access to the server?  What if backup processes are controlled by the client?  Then we are left with physical access, and environmental controls.

I have walked through the types of scenarios that would need to occur before these kind of controls could have any relevance to financial reporting, and have demonstrated that it is unreasonable to conclude that they are ICFR domains.

I would like to challenge anyone out there to take a control from such a datacenter's SOC 1 report and walk through a scenario to demonstrate how the absence or failure of that control could impact their customer's financial statements.  You can leave a comment on this post, or upload your analysis here.

SOC 2 is Destined to Fail Unless We Take Action

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.

Petition for the Adoption of the DoRS Approach to Determining ICFR

One of the challenges that face auditors of service organizations when conducting SOC1 (aka SSAE16) engagements is determining when a control is "reasonable in the circumstances." What that means, according to the SSAE 16 attestation standard, is that a control must have relevance to Internal Controls Over Financial Reporting (ICFR) for it to be included in a SOC1 report.

Without an objective approach to determining what an Internal Control Over Financial Reporting is, service organizations will continue to misuse SOC 1 (SSAE 16) reports. Details of the DoRS approach can be found here.

Many of the service organizations I speak with are frustrated with the lack of clarity around SOC reports and they do not want to be put at a competitive disadvantage by paying more for a SOC 2 report when their competitors are allowed to keep things as they were under SAS 70.

I have also spoken with service organizations on the opposite side that hope SOC 2 fails. They are more than happy to undergo a SOC 1 engagement because of the low cost and high likelihood of passing. They are actually hoping that their customers will continue to ask for a SOC 1 thinking that it addresses their security concerns.

Please consider signing this petition, and passing it along to anyone who might be concerned about the direction that service organization control reports are heading.


Jon Long, CISA, QSA
(404) 368-9228