SOC 2 – Not your prior year SAS 70
After a 20 year reign as the service auditor’s report, the SAS 70 was retired this summer with much fanfare. After being used to communicate the design, implementation and operating effectiveness of controls at every type of service organization imaginable, the AICPA published new standards that better align the type of service organization and service provided to the report used to communicate the design, implementation and operating effectiveness of controls to the user of the report.
For the service organizations that process transactions that impact internal controls over financial reporting there is a quasi-seamless transition to the SSAE16 SOC 1 report. Other than some housekeeping items related to management’s assertion and potential changes to the description of controls to ensure the people, processes and technology components are adequately described, there is little impact to the service organization’s migrating to a SOC 1 report. In general, the report structure and testing requirements for the control objectives and related control activities remains relatively the same. I don’t think it is necessary to dive in to the SAS 70 to SSAE 16 SOC 1 transition in detail, as it has been documented, blogged and tweeted extensively this year.
But what about the other guys? What about the service organizations that process transactions or provides services that do not impact internal controls over financial reporting? What is the impact to those service organizations in the migration from SAS 70? How do they transition from controls which management defined, to the concept of Trust principles and criteria which are outlined by an authoritative body? We are seeing a larger challenge for those transitioning from a SAS 70 to a SOC 2 audit.
The criteria/control activities the service auditor is required to test are specified in published standards for the SOC 2 engagement. Furthermore, there is much less room for management to specify the control activities to be tested during the SOC 2 audit. The service organization either has a policy, procedure or control activity to map to the criteria outlined in the trust principle or they don’t, which may lead to an exception in the report. It is a more black and white form of auditing. So what does this mean for the service organization that has focused on the control objectives and specific activities outlined in their prior year SAS 70? Are they going to receive testing exceptions or even a qualified opinion under SOC 2 after years of successful audits under SAS 70? Possibly.
I would like to explore a few examples of the challenges service organizations are experiencing as they migrate to SOC 2 and then discuss what the service organization should do now to prepare for their next SOC 2 audit. I will focus on the Security and Availability principle, but the concept applies to all of the principles outlined in SOC 2.
You don’t have to read deep in to the Security criteria before you hit your first challenge. Criteria 1.2 under the Security principle states “The entity’s security policies include, but may not be limited to, the following matters:” and goes on to list 14 concepts that should be included. So the auditor will ask for your information security policy and tie each of the 14 concepts, if applicable, back to your information security policy. Now compare that to the control activity that may have been used under SAS 70. “The service organization has an information security policy that communicates management’s expectations regarding information security to the organization”. I have seen one page policy statements and 30 page information security documents used to meet the control activity in the SAS 70, neither of which would pass muster with criteria 1.2 of the SOC 2 Security principle.
Let’s fast forward to criteria 3.1 of the Security principle which states “Procedures exist to (1) identify potential threats of disruption to systems operation that would impair system security commitments and (2) assess the risks associated with the identified threats.” Yes, the criteria requires a formal risk assessment that identifies potential threats and risk to the service organization. I would say that the next logical step is that the service organization has identified controls to mitigate those threats, although it is not explicitly stated. Now tie that back to your prior year SAS 70. There is a risk assessment section as a COSO component of the report, but I suspect that most of you reading this article used informal management involvement or open communication with subject matter experts to support this requirement in the SAS 70. I don’t remember seeing many SAS 70 reports with a formal risk assessment process, but it is here now.
The Availability principle has similar examples of where the service organization may be required to meet new criteria that was not included in their prior year SAS 70. The one example I would like to discuss involves business continuity planning. The criteria states “Procedures exist to provide for backup, offsite storage, restoration, and disaster recovery consistent with the entity’s defined system availability and related security policies.” The first portion of the criteria is included in the computer operations section of most SAS 70s, but what about the business continuity planning portion of that criteria?
Historically the service auditor has included a summary of the service organization’s business continuity or disaster recovery plan in the unaudited section of the SAS 70 report. However, it is now required for the service organization to have a disaster recovery plan. I am not arguing that a service provider should not have a documented disaster recovery plan. My point is, this criteria that the service organization must now adhere to was not a requirement during their SAS 70 audit.
I write this blog entry from the airport, on my way home from performing a SOC 2 audit for a new client. At the conclusion of our exit meeting the client commented on how the SOC 2 was different than the prior year SAS 70. We encountered a few areas where they were not prepared to meet the new criteria. Fortunately this was a Type 1 engagement so the client can address some of the identified exception, but that may not be the case for clients performing their Type 2 audit towards the end of the review period.
So what should clients do now to ensure their SOC 2 audit engagement flows as smoothly as the SAS 70 audit of prior years? Prepare now. The SOC 2 principles are available from your service auditor or online from the AICPA. Discuss which principles are relevant to your processing environment with your service auditors. Know which criteria are going to be audited and evaluate your level of preparedness. You should begin by mapping the control activities in your prior year SAS 70 to criteria in the relevant SOC 2 principles. This will show the areas where additional control activities need to be identified. Communicate with your service auditor early to ensure you are both in agreement regarding the principles, criteria and control activities that will be included in your upcoming SOC 2 audit. The time spent now understanding the new SOC 2 requirements will pave the way for a smooth transition from your prior year SAS 70.