Archive

Posts Tagged ‘SOC 1’

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.

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.

SOCs Rocks? or not……

May 6, 2011 2 comments

So, the AICPA has killed off a defacto brand, SAS 70, and created three new reporting standards, SOC 1, SOC 2, and SOC 3 to replace it.  If that sounds a bit like a Dr. Seuss book, you are in good company.   SOC stands for Service Organization Controls which is what these new reporting standards are supposed to address.

SOC 1 is the “new” SAS 70.  The official standard is SSAE 16, or “Statement on Standards for Attestation Engagements number 16” to be precise.  When the AICPA announced the demise of SAS 70, they simultaneously introduced SSAE 16 as its replacement.  So naturally, as a service organization who has had SAS 70 audits for years, and is already “SAS 70 certified”, you will ask your auditor for an SSAE 16 report for 2011, right?  Yes, you will.  And that is precisely why the new SOC reports will not accomplish what the AICPA wants them to.

The biggest problem with SAS 70 was that it has been misused and abused since Sarbanes-Oxley (the other SOX) became law.  It was never intended to be an audit of general IT controls for an unrestricted audience.  It was created by auditors for other auditors who were performing financial statement audits.  The guidance for SSAE 16 clearly states that a SOC 1 report is also intended for auditors performing financial statement audits.  But  the service organizations that have had SAS 70 reports are now asking their auditors for SSAE 16 reports because their customers are asking for SSAE 16 report because it is the “new SAS 70”.  Those customers don’t care that the report is intended for use in financial statement audits.  They just want the report so that when their auditors ask for the SSAE 16 report (which they inevitably will) it will be available.

SOC 2 and SOC 3 reports could have been the next big thing for companies seeking some kind of assurance over the IT general controls for their cloud and colocation service providers.  The reports are based on a standard set of control principles which makes it easy to know that a given service organization has all the right kinds of controls in place.  But because the AICPA did such a poor job of preparing everyone for the change and educating them on which report was best, everyone will just ask for SSAE 16 because it is the replacement for SAS 70.  The people in the trenches who are asking for these reports don’t care about whether it is appropriate or not.  They just want to be able to give the report to the auditors when they ask for it.

And by the way, the auditors asking for the report really don’t care either.  As long as they can check the box on their working papers that will soon say “SSAE 16”, it won’t matter if the service being provided has a financial statement impact to their client or not.  They are covered and that is all that matters.

Meanwhile we still don’t have a certification or a standardized audit to ensure that Cloud Provider A and Cloud Provider B have appropriate IT general controls in place.