How to know if your Data Center is Serious About Controls

Every day I get an alert from Google for any new press releases about SSAE 16 reports.  The vast majority of the alerts come from co-location and “cloud” data center providers.  I believe I have already beaten the “SSAE 16 is not intended for general IT controls” horse to death in other blogs so I won’t go into that.  What I will continue to bring up is the colo, data center,  and cloud industry’s apparent unwillingness to recognize the importance of the SOC 2 report, especially now that the AICPA and Cloud Security Alliance have endorsed SOC 2, along with the Cloud Controls Matrix, as “likely to meet the assurance and reporting needs of the majority of users of cloud services”.  http://www.journalofaccountancy.com/News/20137424.htm

I’m sure that many readers will jump all over the semantics of cloud vs. data center vs. colo.  But conceptually all three house IT infrastructure at a facility that is not controlled by the customer.  As a result, IT general controls (non-ICFR) are extremely important.  The reason SOC 2 exists is to address all those IT general controls.  A customer of a colo, data center, or cloud provider that maintains responsibility for the initiation, processing, and reporting of transactions through IT infrastructure housed at a remote facility should be asking their provider for a SOC 2.  The Trust Services Principles and Criteria are the pre-established general controls criteria that have been missing from SAS 70 and SSAE 16 reports.  Without some type of framework, SSAE 16 reports are subject to all manner of missing and irrelevant controls.  The inconsistency in both structure and content is one of the primary reasons that information security professionals laugh at the mention of SSAE 16 and SAS 70.

Does your data center, colo, cloud provider offer a SOC 2 report?  If so, you can be a lot more confident that they are serious about providing you with meaningful information regarding their IT general controls.  They have taken the time to understand the new AICPA standards for SOC reporting and have made the decision to provide the appropriate report to their customers.  If your provider is still providing  only the SSAE 16 report, you really need to read the report and ask yourself “What’s missing?” because chances are, there are important controls being glossed over or ignored.

An easy way to test your provider’s SSAE 16 report is to compare the controls being tested and described to any number of controls frameworks, including the Trust Services Principles and Criteria or the Cloud Controls Matrix or COBIT or whatever you think is the best and most appropriate for the services being provided.  Chances are you will find that the report is missing important details.

 

Division Among the Ranks

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

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.

SSAE 16 “First to Fail”?

I’m still waiting for a service organization to write a press release that is:

1. accurate
2. replete of the word “certification“
3. shows a moderate level of understanding about SOC attestations
4. announces that the service organization conducted the right SOC attestation

This morning I was greeted with a press release from First To File ®, announcing that they have “passed” their SSAE 16 audit “for the third year in a row”.   Hmmm.  Considering the SSAE 16 standard wasn’t released until 2010 that’s a pretty neat trick!  But that isn’t really why I’m writing about this press release.  And I really am not trying to pick on First To File ®.  Their press release just happens to contain many of the issues I have been trying to address with this blog.  Apologies in advance.

It appears to me based on the description of  First to File’s® business (patent prosecution support and document management service) that the SOC 1 audit was probably not the right type of SOC review for them to undertake in the first place.  One of the primary reasons that the AICPA decided to do away with SAS 70 and create the SOC standards was because SAS 70 was being misused.

The AICPA white paper describing the new SOC standards says it best: “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.” ¹  SOC 1 reports focus “solely on controls at a service organization that are likely to be relevant to an audit of a user entity’s financial statements.” ²

So if First to File® is in the business of document management, how do their services have any relevance to a user entity’s financial statements?  They are merely storing intellectual property (IP) in a web-based environment for their customers.  The only impact to the financial statements of their customers would be the fees paid by the customer for the services rendered.  You might even stretch things and conclude that the value of the IP is at risk since it is being stored and protected by a third party.  But that still does not justify the use of a SOC 1 (SSAE 16) report.

Certainly their customers would be interested in knowing what types of controls over the security and confidentiality of that intellectual property First to File® has in place.  This is precisely the scenario that the AICPA created the SOC 2 report for.  It is intended for situations where a report is needed about controls at a service organization intended to mitigate risks related to security, availability, processing integrity, confidentiality, or privacy.  Of these, it appears to me at first glance that customers of a company providing document management services would certainly be interested in controls around security, confidentiality, and privacy.  Perhaps even availability since it would be important to know that the web-based services would be available when needed.

So why would First to File® decide to ask their auditor for an SSAE 16 report?  Because the AICPA and many CPA firms have not sufficiently educated the marketplace regarding the intent and appropriateness of SOC 1 vs SOC 2 vs SOC 3.    Which is why I felt compelled to share this blog.

I can’t really blame the marketing and public relations folks that drafted the First to File® press release.  If CPAs and other controls experts can’t figure out the new standards, we shouldn’t expect marketing folks to get it.  If anyone is at fault, it would be the CPA firm that undertook the engagement.  They should have done a better job of explaining the options and steered the customer away from SOC 1 and toward SOC 2.  If after thoroughly understanding the options, the company still elected to have a SOC 1 (SSAE 16) report prepared, then all we can say is “the customer is always right“.

¹  Service Organization Controls: Managing Risks by Obtaining a Service Auditor’s Report – AICPA, Nov 2010

 ² ibid

 

SOC 2 is NOT SSAE 16

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.

Why Data Centers don’t need SAS 70 or SSAE 16

Most large Data Center and Colocation providers that have Fortune 500 customers have been providing SAS 70 reports for several years.  Now that SSAE 16 has been announced as the “replacement” for SAS 70, most all of them are undergoing SSAE 16 reviews.   You can check my prior blogs SAS 70 is Dead and SSAE 16 is the New SAS 70 for more on the history of how we got here and the fact that “the customer is always right”.

I am continually amazed by how adamant many auditors and IT controls people are about why a data center or colocation provider needs an SSAE 16 audit.  I agree that DCs provide certain fundamental general controls that may impact the systems that are maintained there.  But even those general controls do not constitute Internal Controls over Financial Reporting (ICFR) which is clearly a requirement for performing a SOC 1 (SSAE 16) review.  With few exceptions, DCs and colocation centers do not WANT to be able to alter the processing of their customer’s transactions and do everything in their power to avoid direct access with their systems.

So what exactly is ICFR?  The SEC are the overlords of Sarbanes-Oxley compliance and the purveyors of wisdom regarding ICFR.  They define ICFR as:

“A process designed by, or under the supervision of, the registrant’s principal executive and principal financial officers, or persons performing similar functions, and effected by the registrant’s board of directors, management and other personnel, to provide reasonable assurance regarding the reliability of financial reporting and the preparation of financial statements for external purposes in accordance with generally accepted accounting principles and includes those policies and procedures that:

(1) Pertain to the maintenance of records that in reasonable detail accurately and fairly reflect the transactions and dispositions of the assets of the registrant;

(2) Provide reasonable assurance that transactions are recorded as necessary to permit preparation of financial statements in accordance with generally accepted accounting principles, and that receipts and expenditures of the registrant are being made only in accordance with authorizations of management and directors of the registrant; and

(3) Provide reasonable assurance regarding prevention or timely detection of unauthorized acquisition, use or disposition of the registrant’s assets that could have a material effect on the financial statements.^“

Now that’s a very long definition but important to understand what ICFR is.  Several key phrases stand out in that definition noting policies and procedures that:

• “Pertain to maintenance of records” – does a data center maintain records? No. A DC maintains an environment of physical security, environmental controls, and connectivity.  The user organization is responsible for maintaining the records.
• “Provide reasonable assurance that transactions are recorded as necessary” – Does a DC provide assurance?  No, the user organization does that.
• “Provide reasonable assurance regarding prevention or timely detection of unauthorized acquisition, use or disposition of … assets” – Does a DC provide this assurance?  No, not unless they are providing managed services in addition to basic data center services.

So where is the link to ICFR?  When examining the types of controls that a typical DC or colo facility provides, there is no relevant link to ICFR.

“So Barton, are you saying that user organizations shouldn’t be concerned with controls at their third party colo or DC?”  Absolutely not.  I am saying that a SOC 1 SSAE 16 report is not the right answer for a colo or DC.  The more appropriate SOC report would be a SOC 2 report.

SAS 70 (and subsequently SSAE 16) were never meant to be a report on IT general controls.  They became popular for DCs and colos because auditors didn’t know of any alternatives to SAS 70 for understanding controls at service organizations.   Now that the AICPA is promoting SOC 2 as an alternative to SAS 70 for understanding IT general controls, there is no reason for a DC or colo to undergo an SSAE 16 review.

For most DCs and colos, the services provided are no different from those provided by the building management companies for large office buildings throughout the country.  Building management companies lease space.  That space includes physical security and environmental controls.  They don’t typically provide connectivity but there may be some that do.  DCs and colos lease space that includes physical security, environmental controls, and connectivity.  Those services do not constitute ICFR under the SEC definition.

So don’t ask your DC or colo provider to give you an SSAE 16 report.  Instead, look into an alternative like the SOC 2 or SOC 3 report to get an understanding of the IT General Controls they provide.