Posts Tagged ‘SSAE 16’

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,” was her reply (fictional name).

Confused, I asked for clarification. “ 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? 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 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, 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.

SAS 70 is Dead

April 28, 2011 1 comment

If you haven’t heard already, SAS 70 is no more.  As of June 15, 2011, the AICPA is laying Statement on Auditing Standards Number 70 to rest permanently.  Why?  The official reason has to do with the convergence of International Accounting Standards.  The unofficial reason also included trying to gain control over what has become a de facto “certification” based on a misused audit standard (SAS 70).

The original intent of SAS 70 was for auditors of an organization’s financial statements could get an understanding about the controls over the services being  provided by a third party service organization.   The audit standard (SAS 70) was only applicable if the transactions processed were significant to the user organization’s financial statements.  In fact, the SAS 70 standard clearly states that it was NOT relevant in situations where “The services provided are limited to executing client organization transactions that are specifically authorized by the client…”

Note that the premise of the audit was for service organizations that process transactions on behalf of a user organization.   So why do so many co-location facilities and data centers that don’t process any transactions on behalf of their customers claim to be “SAS 70 Certified”?  Because the customer is always right.

Do a Google image search for “SAS 70 Certified”.  You will get thousands of hits.  Logos of all shapes and sizes on websites of service providers claiming to be “SAS 70 Certified”.  The truth of the matter is there is no such certification.  All the logos are merely creations of marketers trying to promote the fact that their organization has undergone a SAS 70 audit.

To figure out how this all got out of control you have to go back to 2004 and the beginning of the SOX era.  SOX changed the auditing process significantly.  Auditors suddenly had to actually understand the controls that were in place around financial statements.  Outsourcing of IT, payroll, benefits administration had been going on for a while.  But now, the auditor had to have some way of understanding what really went on in those third party service organizations.  Enter SAS 70.  A little known and less understood audit standard that seemed to be the silver bullet.

The big 4 auditors began asking for a SAS 70 report for all the third party service providers that their clients were using.  It became a checklist item as part of the yearly financial statement audits.  “Is this business process performed by a third party?  If so, request a copy of the SAS 70.”  Nevermind that most of the junior auditors that filled out the checklist had no clue what SAS 70 was or how it should be used.

Since the auditors needed it, it had to be important.  Eventually, the procurement groups at big corporations began requiring a SAS 70 report of any service provider that did business with the company.  Somewhere along the way, the vernacular changed, and the question became “Are you SAS 70 certified?”.   In order to do business with larger clients, the service organizations had to have a SAS 70 audit performed, whether it made sense or not.  Why?  Because the customer is always right.

In my next blog, I will discuss the new AICPA standards for service organization controls (SOC) audits and why they won’t fix the problem.  Stay tuned.

Categories: SOC Audits, Uncategorized Tags: ,