Service Organization Control (SOC) reports What are they?

Service Organization Control (SOC) reports What are they? Jeff Cook, CPA, CITP, CIPT, CISA June 2015 Introduction Service Organization Control (SOC) reports are on the rise in the IT assurance and compliance world. Even more specifically, the SOC 2 report is being utilized as a premier IT audit report that is being paired with other IT compliance standards to create a do once, use many approach for both service organizations and auditors. With this rapid growth in demand for SOC reports, it is crucial for businesses to understand what the reports are and how an audit works, so that organizations can better plan for and navigate an audit to achieve a successful result. This three-part series on SOC reports will discuss in detail: 1. What are SOC reports? Which SOC report will best serve my organization; SOC 1 or SOC 2? 2. What is involved in a SOC audit? 3. How does the SOC audit relate to and enhance other IT assessments? In the first of this series, we examine: What SOC reports are and their history What the differences are in the various SOC reports What the trust principles are in a SOC 2 What is the structure of a SOC report. Key Players Before delving into the details of SOC assessments, it s important to understand the key roles related to SOC: Service Organization an entity that possesses, stores, or handles information or transactions on behalf of its customers (user entities) User Entity the company that outsources its information or business processes to a service organization Service Auditor a CPA who reports on the controls of a service organization User Auditor a CPA who audits the financial statements of a user entity that uses a service organization 1

What are SOC reports, and where did they come from? Let s get started by taking a look at the origin of SOC reports. Traditionally, user entities utilized service organizations for functions such as payroll processing, medical claims processing, etc. Functions such as these impact user entities financial data. In order to institute controls around these functions, the American Institute of Certified Public Accountants (AICPA) issued Statement on Auditing Standards (SAS) number 70 in 1992. This SAS provides guidance to service auditors reporting on a service organization s controls relevant to user entities financial reporting and the user auditors. The SAS 70 report on the service organization (performed by the service auditor) allowed user entities and their auditors to see that the user entity financial data was being properly processed by the service organization. Without this report, user auditors (on behalf of their user entities) would constantly be bombarding the service organization with questions about the service organization s controls, since it is required for the financial audit of the user entity. The SAS 70 allowed the auditing of those controls to occur one time by the service auditor. Service audit results are documented and provided to the user auditor, saving the service organization time and money. Let s have a look at a graphic to help explain this further. Service Auditor - provides SAS 70 report on controls of the service organization Service Organization (e.g.: payroll processor) - provides processed payroll data to user entity and SAS 70 report to user entity and user auditors User entity (misc. company) User auditor - audits the financial statements of the user entity and its controls (this includes the controls of any service organizations used) 2

As time went on and technology became more advanced, the marketplace for service organizations changed. Service organizations started to offer services such as administrative outsourcing (human resources, document management, etc.), workflow, and cloud computing (applications, data storage, etc.). With these changes to service organization offerings, the SAS 70 reports were used for audits of controls outside of financial reporting, even though the intent of the report remained financial in nature. For example, a data storage service organization has minimal to no impact on a user entity s financial statements, but the service organization controls are still important to the user entity. Service auditors, without a better option, continued to issue SAS 70 audit reports for non-financial controls and the term SAS 70 certified was inappropriately used by user entities. By 2004, the AICPA recognized there was a problem in this reporting and the Auditing Standards Board attempted to clarify the issue by splitting SAS 70 into two standards. The guidance for user auditors remained an auditing standard for financial statements, and the guidance for service auditors became an attestation standard for service organizations. In 2010, that attestation standard became the Statement on Standards for Attestation Engagements (SSAE) No. 16, Reporting on Controls at a Service Organization. Like the old SAS 70, SSAE 16 focuses on guidance for service auditors assessing financial statement controls at the service organization that affects user entities. SSAE then provided the basis for the SOC 1 report. The AICPA recognized that a different report was still needed for service organizations providing nonfinancial services to user entities. To address service organization system controls, rather than just financial controls, the SOC 2 report was launched in 2011. The SOC 2 offered the service auditor guidance on conducting an attestation engagement to report on the service organization s controls related to security, availability, confidentiality, and processing integrity of a service organization s system, or the privacy of the information processed by that system. The SOC 3 report was implemented at the same time, and is a shortform SOC 2 report (i.e., no description of tests of controls and results). The SOC 3 report may be used in a service organization s marketing efforts as the SOC 3 is considered a public report. 3

What are the differences between SOC 1, 2, and 3? Now that you know how we got the different reports, let s see how the AICPA summarizes the differences between SOC 1, SOC 2, and SOC 3. 4

The differences in the three reports can also be compared in the following manner: Report type Intended users Why needed What SOC 1 Management of the service organization User entities User auditors Audit of the financial statements of user entities Controls relevant to user entity financial reporting (e.g., payroll processing) SOC 2 Management of the service organization User entities User auditors Regulators Other Audit of the financial statements of user entities Meeting governance, risk, and compliance programs Oversight Due diligence Controls relevant to a service organization system s security, availability, processing integrity, confidentiality, or privacy SOC 3 Any users with need for confidence in the security, availability, processing integrity, confidentiality, or privacy of a service organization s system Marketing purposes General public information Detail not needed Seal and report on controls 5

The different variations within the SOC reports (type 1 and type 2). Both SOC 1 and SOC 2 reports have different types. The AICPA refers to these types simply as type 1 or type 2. So, what are the differences? A type 1 report focuses on the description of a service organization s system, related control objectives, and the suitability of controls to achieve those objectives as of a specified date. A type 2 report contains the same information as a type 1 report with the addition of an assessment of the operating effectiveness of the controls to achieve the control objectives included in the description throughout a specified period. A type 2 report also includes a detailed description of the service auditor s tests of controls and results. Type 1 Opinion of the system and design of controls How it achieves control objectives in the system description As of a specific date Does not show tests of controls or results Type 2 Same opinion as type 1, plus if the controls are operating effectively Opinion is throughout a specified period for the report Shows descriptions of the service auditor's tests of controls and results of tests Defining the trust principles of a SOC 2. With more and more service organizations getting requests from their user entities for SOC 2 reports, it is important to understand what the trust services are and how they can be reported in a SOC 2. Trust services are a set of services based on a core set of criteria that address the risks and opportunities of IT-enabled systems and/or privacy programs. The following criteria are used in SOC 2 trust services engagements: Security. The system is protected against unauthorized access (both physical and logical). Availability. The system is available for operation and use as committed or agreed. Processing Integrity. System processing is complete, accurate, timely, and authorized. Confidentiality. Information designated as confidential is protected as committed or agreed. Privacy. Personal information is collected, used, retained, disclosed and destroyed in conformity with the commitments in the entity s privacy notice and with criteria set forth in Generally Accepted Privacy Principles issued by the AICPA and CICA (Chartered Accountants of Canada). 6

A service organization can choose to report on any of the trust principles for a SOC 2 engagement. If a system only needs to report on its security, then only the Security criteria would be used for the SOC 2. If a system needs all five criteria, then the SOC 2 would cover all five. Deciding which criteria to report on (and best fits the need) is up to service organization management. It is important to note that conducting a SOC 2 on the first four criteria (security, availability, processing integrity, and confidentiality) uses similar control objectives with minimal variation in testing, so testing these four criteria does not require much more effort from the service organization, or the service auditor, than testing one. Privacy, however, does require an additional set of rules and control objectives requiring a substantial increase in the amount of work needed to complete the SOC 2. Unless a service organization is processing or housing Personally Identifiable Information (PII), typically they will have their SOC 2 done on only the other four trust principles. In 2014, the AICPA changed the reporting for SOC 2 in order to streamline the control objectives to facilitate the process for the service organization, service auditors, and readers of the SOC 2 report. In previous SOC 2 reports, each criteria would get its own set of control objectives, leading to duplicated information for the controls put into place by the service organization, the service auditor s test of controls, and results of the tests. After the 2014 revision, the bulk of the report consists of the common criteria that are related to all four of the trust principles of security, availability, processing integrity, and confidentiality. After the common criteria, there are a small number of controls that will relate specifically to the individual four criteria on their own. It is important to note, however, that privacy still has its own set of criteria and control objectives (nothing changed). 7

Structure of a SOC 1 and SOC 2. For the most part, a SOC 1 and SOC 2 are very similar in report structure. Section 1 is the Independent Auditor s Opinion; Section 2 is Management s Assertion; Section 3 is Description of the System(s) and; Section 4 is Tests of Controls and Results of Tests. Remember, section 4 is only relevant in a type 2 SOC engagement, and the auditor s opinion will vary between a type 1 and type 2 engagement. Let s look at each of the four sections in more detail. Section 1 - Independent Auditor's Report Provides the reader the opinion of the service auditor on the system description, design, and operating effectiveness to meet the control objectives Section 2 - Management's Assertion Provides the reader the facts and assertions made by management of the service organization related to the system(s) under audit Section 3 - Description of the System Provides the detail of the system(s) being reported on (written by management) Includes boundary, infrastructure, controls, and other system information Anything that is included in this section must be able to be audited to meet the control objectives Section 4 - Auditor's Tests of Controls and Results of Tests Shows four columns of information Control to be tested Controls in place at the service organization to meet the objective Auditor's tests of the controls Results of the tests 8

Part 2 Preview. Next month, we will take a more in-depth look into the logistics of preparing for, and navigating through a SOC audit. We will cover: How to determine what your organization should be reporting on Scoping and boundary determination Policies and procedures Preparing your organization for Section 3 and Section 4 of the audit report What are the typical phases and timelines of a SOC audit Jeff Cook is a Strategic Account Manager of Veris Group, LLC, an industryleading, award-winning cybersecurity company headquartered in Vienna, VA. verisgroup.com E: info@verisgroup.com T: 703.760.9160 9