SSAE 16 data center compliance seems to be a timely consideration due to the new AICPA Statement on Standards for Attestation Engagements (SSAE ) No. 16 replacing SAS 70, at least in part, with the advent of the new Service Organization Control (SOC) reporting framework, which consists of SOC 1, SOC 2, and SOC 3 reporting. Many accountants, auditors, and data center industry participants alike have assumed that the switch from SAS 70 to SSAE 16 is merely academic in that their historical SAS 70 reports will simply be carried over to the new SSAE 16 standard, with minimal changes. If this simple an incorrect approach is undertaken by some within the data center industry, then they will be hindering the actual deployment and the intended benefits of the new SOC framework reporting regimen. The overall SOC framework, which consists of SOC 1, SOC 2, and SOC 3 reporting options, functionally represents categories of compliance based on a service organization’s nexus to “internal controls over financial reporting” (ICFR). Learn more about NDB's complimentary SOC 1 Policy Packets and SOC 2 Policy Packets. They truly make a big difference in helping service organizations save thousands of dollars on SOC compliance.
1. SOC 1 vs. SOC 2 for Data Centers
If you look at the true intent of the new AICPA Service Organization Control (SOC) reporting framework, there is a sincere effort to try and separate service organizations into their proper and respective reporting platforms. The SOC 1 framework, for which SSAE 16 is the domestic professional standard used for issuing these reports, is focused towards entities that have a definable financial accounting and reporting nexus and “internal controls over financial reporting” (ICFR) for an identifiable user organization group or category.
Likewise, SOC 2 & SOC 3 reports are for reporting on service organizations over "Security, Availability, Processing Integrity, Confidentiality, and/or Privacy". The exponential growth of Software as a Service (SaaS), cloud computing, managed service providers, and many other I.T. related entities became one of the critical components for revamping service organization reporting.
The over extension of the previous SAS 70 standard and the misguidance of financial statement auditors with regard to the possible existence of ICFR at a specific service organization and the overall three tiers of the SOC Framework are seeming to frustrate the technical merits and intent of the new AICPA SOC framework. Erroneously, many audit practitioners and data center industry compliance officials have simply attempted to adopt the SSAE 16 standard as the de facto reporting standard in replacement of SAS 70, with little regard or consideration given to the new SOC 2 reporting option, which is fundamentally the correct reporting tool.
Simply search on the internet for phrases such as "SSAE 16 data center" and you'll likely find numerous press releases, blogs, and other marketing announcements proclaiming this very notion. In short, the SOC 2 framework is much better aligned for the reporting requirements necessary to illustrate the control framework within a given data center, but as of now, there seems to be little attention given to that notion. Data centers do what they do for their clientele, generally not involving any clearly identifiable ICFR
2. Provisions within SSAE 16 “may” allow Data Centers to achieve SSAE 16 Compliance
Even with all the arguments against using SSAE 16 for data center compliance, the "relevancy" phrase within the standard seems to allow enough flexibility within the SSAE 16 standard for data centers when demanded to provide SSAE 16 reporting by user organizations or their auditors.
For example, “general computing controls” at a service organization (such as a data center) deemed critical to functions being performed by a user organization that may have relevancy to the ICFR concept, can technically result in using the SSAE 16 standard for issuing a report on controls. These general controls in data centers may include physical security, environmental security, logical security, and network security, just to name a few. Of course, all these controls would sufficiently be addressed in SOC 2 reporting, thereby confirming the inappropriateness of using SSAE 16 reporting for a data center.
An example of how this scenario might play out is as follows: The ABC data center provides “ping, power, and pipe” (as it is commonly referred to) along with managed services to the XYZ company. The XYZ company has racks of servers in place that hold critical financial information (i.e., general ledger software, financial applications pertaining to revenue and expenses) for third party organizations. Thus, the ABC data center or XYZ might argue that SSAE 16 is the better suited reporting option as it is protecting critical financial information, thus they've established a link with the internal control over financial (ICFR) concept, a core component of SSAE 16 compliance. Of course, this is all false as they are not the responsible party for the ICFR but are participants in providing ancillary services aligned with the actual responsible party for ICFR, which is XYZ in this scenario. SOC 2 reporting should more than adequately provide coverage for the relevant general controls of interest for the auditor at either XYZ or the third party.
It seems the failure to more fully embrace the SOC 2 reporting platform rather than SOC 1 reporting platform (SSAE 16) is due in large part to the obscurity and unknown of SOC 2 and the failure of the Big 4 accounting firms to provide the needed clarity and knowledge base to discriminate between the organizations that should be adopting either standard. This may change as participants and key players within the industry become more informed and educated on the true merits of a SOC 2 report conducted under the AT 101 professional standard. Again, the SOC 2 framework is considered favorable and appropriate for reporting on controls at data centers. After all, a significant component of a data center's daily operations are in place for ensuring the Security, Availability, Processing Integrity, Confidentiality, and/or Privacy of information and their supporting assets for clients. It should be clearly stated that the term SOC 2 does not mean that it is in some way deficient or behind a SOC 1 reporting, as the uninformed might interpret from the numbers 1 & 2. This is simply a classification used by the AICPA that may be interpreted as enumerating reporting with regard to nexus with ICFR. Probably no broader assumption should be made by the numbers.
3. Multiple Reports may be the norm, but inappropriate
Curiously, some overzealous CPA firms have been issuing both SOC 1 (SSAE 16) and SOC 2 (AT 101) reports for data centers, claiming each report has its own merits and qualifications. While this may be their argument, practitioners should strive to find a common ground for the data center industry in utilizing the SOC 2 reporting standards, resulting in a unified reporting process that illustrates a comprehensive and in-depth examination and testing of the relevant control environment, including both trust services and general computing controls present at the service organization. The goal of the new SOC framework is not to double the reporting requirements or compliance needed by data centers by performing audits for two reports or an incorrect report. The same erroneous behavior that resulted in the over application of SAS70 to generic technology trust services may very well result in this unified reporting being SSAE 16 in lieu of AT 101, which may become professionally acceptable if the controls are a true representation of the entity being assessed and relevant for use by the user organizations and their auditors.
When specifically requested by service organizations or demanded by the relevant user organizations or the user organization auditors, NDB may issue a report for a service organization that is adjacent or complimentary to the SOC Framework or may be specific to the requests of a user organization or the user organization auditors. In any case, NDB will strive to fundamentally perform the standard for reporting that is appropriately envisioned by the SOC framework, with any additional reporting following based on requests as provided by service organizations and/or determined relevant user organizations.
NDB Accountants & Consultants (NDB) is a boutique CPA firm established with the mission to provide superior knowledgeable audit services on a nationwide platform. For further information relevant to your organization’s compliance needs for SOC 1, SOC 2, SOC 3, PCI, HIPAA, GLBA, and many other regulatory requirements, please contact us directly at 800-277-5415, ext. 706.