Who Will be Held Responsible for SOC1 Reports that Should Have Been SOC2 Reports?

The recently released AICPA Technical Practice Aid TIS Section 9530 includes the following question on page 7.

This question was most certainly asked by a Service Auditor that found themselves in the precarious position of trying to explain to their client that they really need a SOC 2 report, but were met with resistance because the Service Organization was told by their client to provide a SOC1 (aka SSAE16) report.

If you read the AICPA's answer, it essentially says that it is Management's responsibility, but the Service Auditor can help them if they do not understand the difference.  What a relief.  It is Management's responsibility.

What if Management chooses the wrong report despite help from the Service Auditor?  Will Service Auditors be held responsible for following the attestation standards even when a SOC1 is not applicable? Is there really no wrong answer?

So far I have reviewed SOC1 reports, issued by two separate big 4 CPA firms, that should have been SOC2 reports because they were primarily comprised of non-ICFR controls. See my post on Non-ICFR Controls in an Actual SSAE16.  So will Management be held responsible for inclusions of non-ICFR controls in SOC1 reports

Of course not, the Service Auditor will be because including non-ICFR controls in a SOC1 violates the attestation standard.  In fact, service auditors attest to following these standards in every report they sign:

So who is going to hold Service Auditors accountable?  Meet Jim Brackens, AICPA VP of Ethics and Practice Quality.

Jim oversees the AICPA Peer Review Program and is currently looking for CPA firms that are competent to do peer reviews of SOC reports.  There is a task force that is currently reviewing the SOC Report Checklist, and they are welcoming feedback on strengthening the language so that it is clear what a non-ICFR control is.  I have provided feedback to them, and I would love to pass yours along.

The peer review manual lists the reasons why peer review exists, and why CPA firms must undergo what is essentially an audit of the auditor, but basically the process is there to ensure that CPA firms follow standards issued by the AICPA.  I am excited about the upcoming year and have confidence that SOC reports will not share the fate of SAS70 reports.

No More Bridge Letters in SSAE16!

See The Latest Technical Practice Aid from the AICPA (inquiry .19)! 

This is interesting. 

There are many other interesting TPAs included in TIS Section 9520 and TIS Section 9530, but I will reserve those observations for other posts.

SOC1 (aka SSAE16) Reports that Include Non-ICFR (Internal Controls over Financial Reporting) Controls?

On the third page of the AICPA's brochure on Service Organization Controls that was released in November, 2010 it says:

As organizations became increasingly concerned about risks beyond financial reporting, SAS 70 often was misused as a means to obtain assurance regarding compliance and operations. SSAE 16 and ISAE 3402 were drafted to correct these misuses.

So will SOC1 reports, or SSAE16s as they have become known in the market, that are issued this year be free of non-ICFR controls?  The feedback I have received from user organizations is, no, the SOC1 contains most if not all of the controls that were in the SAS70 they received in the previous years.

We cannot fault the CPA firms issuing SOC1 reports this year for including non-ICFR controls; after all the SOC2 guidance did not come out  from the AICPA until June, 2011, so what alternative did they really have?  SOC engagements that are conducted in Q3 and Q4 are planned in Q1 and Q2.  By the time the SOC2 guidance came out, many CPA firms had already begun their SOC1 engagements.  So what about next year?

Looking through the Reporting on Controls at a Service Organization Checklist, I noticed that the only place it mentions that controls need to be relevant to financial reporting is Question AT208: 

“the control objectives stated in management’s description of the service organization’s system are reasonable in the circumstances(for example, the objective is relevant to financial reporting risks?”

It seems to me that this is too vague, and will allow organizations to get a SOC1 report keeping all of their controls that were in their SAS70 in the SOC 1 report as long as someone can make the reasonableness argument.

What can be done to strengthen the wording in this checklist so that leaving non-ICFR controls in a SOC1 cannot be interpreted as “reasonable in the circumstances?”

The Failed Launch of Service Organization Controls (Formerly SAS70) Reports

On June 15, 2011, the Statement on Auditing Standards no. 70 or SAS70 report was replaced by three new reports called Service Organization Controls reports; SOC1, SOC2, and SOC3 that are based on the Statement on Standards for Attestation Engagements no. 16 or SSAE16 and AT101.

The change was prompted by several things, but among them was the need to clarify that SAS70 is not a certification, and there is no such thing as "SAS70 Compliant."  Watch this video from the American Institute of Certified Public Accountants (AICPA) http://bcove.me/9i0iqynv.

Below are Google Images search results on the term "SAS70" that exemplify the kind of misuse that existed in the market.

Only 6 months after the launch of SOC reports, the following logos are already appearing.

These just in:

Without some kind of intervention, it would appear that SSAE16 is bound for the same fate as SAS70.  I believe that we can help prevent that from happening by educating our clients about the assurance a SOC report provides, and encourage them to use the logos provided by the AICPA and CICA.