Archive

Posts Tagged ‘SOC 2’

Division Among the Ranks

September 11, 2012 4 comments

There is no shortage of strong opinions regarding the state of third party attestation today. On one side we have the proponents of the new SOC 2 standard. On the other, we have those that want to stick with the tried and not-so-true legacy of SAS 70, aka SSAE 16/SOC 1. The real conflict appears to be around how to determine what ICFR is.

ICFR is the acronym for Internal Control over Financial Reporting. Why is this understanding so important? Because it helps determine the most appropriate report for a given service organization and what should be included in the report. At the root of the disagreement is whether or not it is appropriate to include certain general technology controls (e.g. physical security, redundant network and power feeds, etc.) in a SOC 1 (SSAE 16) report.

There is no question about the purpose and applicability of SSAE 16. The preface to the guidance from the AICPA is crystal clear: “Statement on Standards for Attestation Engagements (SSAE) No. 16, Reporting on Controls at a Service Organization (AICPA, Professional Standards, AT sec. 801), establishes the requirements and guidance for reporting on controls at a service organization relevant to user entities’ internal control over financial reporting. The controls addressed in SSAE No. 16 are those that a service organization implements to prevent, or detect and correct, errors or omissions in the information it provides to user entities.”

Based on that guidance, it would appear that if a control does not prevent, detect and correct errors or omissions in the information that a service organization provides to its customers, then it does not belong in a SSAE 16 report. A more fundamental question can be derived from the guidance. That is; what information does the service organization provide and is it relevant to ICFR?

So perhaps the question is not so much whether a particular control itself is or is not related to ICFR. Rather, the question is, does the control prevent, detect and correct errors or omissions in the information provided? If we examine the information provided by a service organization it should help us determine whether the controls are relevant to ICFR.

I have recently seen some blog postings where certain firms are being “called out” for including what the author believes are clearly non-ICFR controls in SSAE 16 reports.  The intent of the postings are to point out that the firm producing the report is somehow violating the SSAE 16 standard by including non-ICFR controls in the report. But it seems to me that the author is himself violating the standard by making portions of a restricted report ( one intended only for management and the service organization’s customers) publicly available.

Healthy disagreement about how to interpret standards, laws, and rules helps improve those same standards, laws, and rules. That is why we have multiple layers of courts in our country. Discussions among professionals in an appropriate forum in order to provide additional clarity over the interpretation of a very complex, very technical standard like AT 801 (the real standard behind the SOC 1 report) will advance the profession.

Copying entire sections of restricted reports in an attempt to support an argument about what controls should or should not have been included will not advance the profession. It will only add more confusion to an already confused customer base and allow some other reporting mechanism to replace SOC reports as the market leading third-party attestation. That would be bad for our profession and bad for our customer base.

Let’s focus on giving our customers a reporting solution that works for them and stop bickering among ourselves as to who is right and who is wrong.

Advertisements

Passing the Buck

June 16, 2012 2 comments

I had an interesting discussion with a SaaS vendor the other day at a networking event. This particular vendor supplies a system to automate certain functions of a company’s accounts payable process. They extract data from the customer and place it in a web based portal for suppliers to utilize for checking on payment status, expediting payment, resolving payment disputes, etc. Clearly this service has a direct impact on financial reporting for their customers, so I asked “Who performs your Service Organization Control examination?” Of course I had to follow with a reference to SAS 70 so that she knew what I was talking about.

“Oh, LargeHosting.com” was her reply (fictional name).

Confused, I asked for clarification. “LargeHosting.com performs your SOC examination?” I asked.
“No, they provide it for us. We host our services with them.”

Now the picture was getting clearer. “So I’m guessing then that you don’t have an SSAE 16 or SOC 2 review performed independently?”
“No, why should we? LargHosting.com is responsible for all of the redundancy, backup and security of our services.”
“What about the controls around the actual sending and receiving of data from your customers? You know, like how do you ensure that if Acme sends you 115 invoice records, that you receive them all and they were accurately filed in the data base to the correct customer?”
“OH! We do that regularly with our customers. If we have a file transmission issue, we call them and tell them to resend the data.”
“What happens if your programmers make a mistake in the code resulting in errors for your customers that impact their financial statements?”
“We have a very robust change management process that would catch any errors like that. If one did happen to get through we would obviously correct the error and apply a patch to our code as quickly as possible.”

Here we have a large publicly traded company outsourcing a key part of the management of their Payables function to a SaaS vendor that does not have any third party attestation around the services they perform. The SaaS provider is relying completely on their hosting company to provide evidence of controls to satisfy the needs of their customers’ auditors and management. And as a result, the customer and their auditors have no third party attestation of the fundamental controls over the development, update, management, and operation of the application controlling this significant business process.

The troubling thing is, this is not the first instance of this scenario that I have encountered. I’ve had several SaaS providers tell me they don’t need to have a SOC report because their hosting company provides them with one.

I am curious to know if the auditor for the publicly held customer has any idea that the controls they should be most interested in understanding (interfaces, input, processing, output, reporting) for the purposes of their financial statement audit are not being addressed by the SOC report provided by LargeHosting.com on behalf of their auditee’s SaaS provider. My guess is the audit team did what most audit team’s do – they asked for the “SAS 70” for the SaaS provider, received a copy of the SOC report for LargeHosting.com, checked the box on the appropriate audit work paper, and moved on.

As a result, their audit of financial statement controls is missing an important component to a critical financial statement line-item. Does your SaaS provider provide you with independent attestation? If not, perhaps it’s time you ask for it.

SOC 2 is NOT SSAE 16

December 21, 2011 2 comments

I just saw the following link related to a data center audit:

Cbeyond One of First SSAE 16 Certified Cloud Companies

Just when I thought things were getting better, along comes this press release that is wrong on so many levels I don’t even know where to begin….. but I’ll try.

First off, SSAE 16 is NOT a certification as I have pointed out MANY times.  (see Just as I Predicted…)  Secondly, SOC 2 is totally unrelated to SSAE 16.  Statement on Standards for Attestation Engagements (SSAE) 16 is specific guidance to CPA firms for planning and conducting Service Organization Control (SOC) 1 reviews. Those are reviews intended for controls at service organizations likely to be relevant to user entities’ internal control over financial reporting.

So far, the AICPA has not released any specific SSAE for SOC 2.  There is an official “guide” to conducting a SOC 2 engagement, but there is not a specific Statement on Standards for Attestation Engagements (SSAE).

The following paragraph highlights the rampant confusion that exists in the marketplace regarding the new AICPA standards for Service Organization audits that replaced the old SAS 70 standard:

“Considered the second-generation data center audit standard, SSAE 16 SOC 2 reviews evaluate the design and operational effectiveness of a center’s controls against a strict series of international standards. Earning SSAE 16 certification demonstrates that Cbeyond Cloud Services is fully compliant with all necessary security and privacy specifications, and demonstrates that its customers are served and hosted in a highly secure, controlled facility.”

Neither SSAE 16 (SOC 1) or SOC 2 is a “data center audit standard”.  And the SOC 2 criteria are NOT an “international standard”.

It is difficult to tell from this press release exactly what Cbeyond did since the press release is mixing SSAE 16 (SOC 1) and SOC 2 together.  Claiming “certification” is just more of the same ignorance that most of the industry shares.

If you are writing or reading press releases from data centers and cloud providers as a normal part of your day, please take the time to understand the new standards and what they mean.  Press releases like this one do nothing to clear the confusion created by the new SOC standards.  If you have questions about the standards, please speak to a qualified member of a CPA firm in order to ensure you are writing and reading with a full understanding.