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.

3 comments:

  1. Good points Jon. I think there is a lot of confusion with SOC 1 and 2. The confusion is compounded by the trends in outsourcing (software as a service, etc). Everyone want some assurance regarding their outsource providers, but the extent of that assurance varies greatly depending on the organization, who's asking, amount of reliance on the service provider, etc.

    ReplyDelete
  2. Thanks for your comment Robert. I agree. Companies need real assurance regarding security and availability, not the kick to the tires level security and availability assurance that SSAE 16 provides. My goal is to wake the market up to the fact that the AICPA says that SSAE 16 is not designed to provide assurance regarding security, availability, processing integrity, confidentiality, or privacy.

    Removing controls from SOC 1 that are not relevant to internal controls over financial reporting (ICFR)is how we correct the misunderstanding in the market. When user entities see that the controls they are used to seeing are not in their vendor's SOC 1 reports, they will ask for SOC 2.

    ReplyDelete
  3. Let's get back to the basics. There shouldn't be any control topics covered in an audit, that exceed the responsibilities in service contracts.

    No data center includes being responsible for a CFO's financial statement accuracy in their contract - nor should they be.

    Any potential control the data center might have is indirect.

    The PCOAB doesn't allow external auditors to rely on another firm's report anyway now - except as part of the risk assessment, where only direct controls are considered.

    Therefore, why would a data center ever build a SOC 1 scope? And if they did, where are their financial reporting objectives as required by AT 101.

    AT 101 applies to ALL attestations; not just SOC 2/3.

    ReplyDelete