SERVICE ORGANIZATION CONTROL (SOC) REPORTS: WHAT ARE THEY?

WHITE PAPER SERVICE ORGANIZATION CONTROL (SOC) REPORTS: WHAT ARE THEY? JEFF COOK DIRECTOR CPA, CITP, CIPT, CISA North America Europe 877.224.8077 info@coalfire.com coalfire.com

TABLE OF CONTENTS Summary... 3 Key players... 3 What are SOC reports, and where did they come from?... 3 What are the differences between SOC 1, 2, and 3?... 5 SOC 1 SM Report... 5 SOC 2 SM Report... 5 SOC 3 SM Report... 5 The different variations within the SOC reports (type 1 and type 2)... 6 Type 1... 6 Type 2... 6 Defining the trust principles of a SOC 2... 7 Structure of a SOC 1 and SOC 2... 7 Section 1: Independent auditor's report... 8 Section 2: Management's assertion... 8 Section 3: Description of the system... 8 Section 4: Auditor's tests of controls and results of tests... 8 How to successfully prepare for A SOC audit... 8 The phases of a SOC audit... 10 Multi-Use benefits of a SOC 2... 11 2

SUMMARY 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 used as a premier IT audit report that is paired with other IT compliance standards to create a do once, use many approach for 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 they can better plan for and navigate an audit to achieve a successful result. In this white paper, we answer the following questions to help you improve SOC understanding: 1. What are SOC reports? Which SOC report will best serve your 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? 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 WHAT ARE SOC REPORTS, AND WHERE DID THEY COME FROM? Let s get started by looking at the origin of SOC reports. Traditionally, user entities worked with service organizations for functions such as payroll processing, medical claims processing, etc. These functions impact user entities financial data. 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 s financial data was properly processed by the service organization. Without this report, user auditors (on behalf of their user entities) would have to constantly bombard the service organization with questions about its controls to meet requirements for the financial audit of the user entity. 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. 3

Let s have a look at a graphic to help explain this further. As time went on and technology advanced, the marketplace for service organizations changed. Service organizations started to offer administrative outsourcing (human resources, document management, etc.), workflow, and cloud computing (applications, data storage, etc.) services. With these changes to service organization offerings, the SAS 70 reports were used for audits of controls outside of financial reporting, even though the report s intent 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. NOTE: The SSAE 16 guidance will be superseded by SSAE 18 effective May 1, 2017. The AICPA recognized that a different report was 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 its system, or the privacy of the information processed by that system. The SOC 3 report was implemented at the same time, and is a short-form 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. 4

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 among SOC 1, SOC 2, and SOC 3. SOC 1 SM Report Reporting on controls at a service organization relevant to user entities internal control over financial reporting Meets the needs of user entities management and auditors as they evaluate the effect of a service organization s controls on a user entity s financial statement assertions. These reports are important components of user entities evaluation of their internal controls over financial reporting for purposes of compliance with laws and regulations and for when user entity auditors plan and perform financial statement audits. SOC 2 SM Report Reporting on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy For those who need to understand internal control at a service organization as it relates to security, availability, processing integrity, confidentiality, or privacy. These reports can play an important role in oversight of the organization, vendor management programs, internal corporate governance and risk management processes, and regulatory oversight. Stakeholders who may use these reports include management or those charged with governance of the user entities and of the service organization, customers, regulators, business partners, and suppliers, among others. SOC 3 SM Report Trust services report for service organizations Designed to accommodate users who want assurance on a service organization s controls related to security, availability, processing integrity, confidentiality, or privacy, but do not have the need for the detailed and comprehensive SOC 2 report. It can be used in a service organization s marketing efforts. 5

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 Public information Detail not needed Seal and report on controls 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. 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 throughout a specified period for the report Shows descriptions of the service auditor's tests of controls and results of test 6

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 Chartered Accountants of Canada (CICA). 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 criterion 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 completed on only the other four trust principles. In 2014, the AICPA changed the reporting for SOC 2 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 criterion 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 the trust principles of security, availability, processing integrity, and confidentiality. After the common criteria, a small number of controls will relate specifically to the individual four criteria. In 2016, the trust service principles were revised again. Minor changes were made to security and confidentiality, but the major change affected privace. The privacy criteria were simplified to make it a more more attainable SOC 2 principle. A summary of the changes in the privacy principle can be found here. In 2017, the AICPA will revise the trust service principles yet again, resulting in control objectives that will be based on the COSO 2013 framework. Watch for updates from Coalfire on the 2017 changes. STRUCTURE OF A SOC 1 AND SOC 2 For the most part, a SOC 1 and SOC 2 are similar in report structure. Section 1 is the independent auditor s opinion;; section 2 is management s assertion;; section 3 is a description of the system(s);; and section 4 includes the control objectives and controls in place at the service organization, tests of controls, and results of tests. Remember, 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. 7

Section 1: Independent auditor's report Provides the reader the service auditor s opinion 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 the service organization s management related to the system(s) under audit Section 3: Description of the system The detail of the system(s) being reported on (written by management) Boundary, infrastructure, controls, subservice organizations, user entity controls, and other system information Inclusions in this section should be capable of being audited to meet the control objectives Section 4: Auditor's tests of controls and results of tests Shows four columns of information: Control objective (related to the applicable trust service principles) Controls in place at the service organization to meet the objectives Auditor's tests of the controls Results of the tests HOW TO SUCCESSFULLY PREPARE FOR A SOC AUDIT Preparing your service organization for a SOC audit is similar whether you re pursuing SOC 1 or SOC 2. The first thing to consider is the trust service principles (SOC 2) or control objectives (SOC 1) that you want to report on. As a service organization, you need to ask, What do readers of this report want to know? Knowing your audience and what information they need is essential to providing the correct information in your SOC report. Your service organization should only report on what is relevant to the user entities. A critical element of this is defining the scope and boundary of the audit because it helps all parties (service organization, service auditor, user entities, and user auditors) understand what is and is not reported (and audited). For example, if you are a data center that only houses client servers, you might report on the trust services criteria of security and availability, but your internal SharePoint system may not be relevant to the user entities, so you would not include that in the boundary of your report. After you determine the system(s) on which to report, make sure policies and procedures are in place to meet the requirements of a SOC audit. Examples include (but are not limited to): System security plan (SSP) Incident response plan Disaster recovery Security awareness (and training) Human resources plans (hire, termination, handbook, etc.) Rules of behavior Configuration management Password policy 8

The policies should be robust in their content and structure. Many organizations start with policy guidance provided by the National Institute of Standards and Technology (NIST) or the SysAdmin, Audit, Networking, and Security (SANS) Institute. Along with making sure the policies are complete for the system(s), you should ensure: 1. The procedures in place are adequate and follow the written policies. 2. You have documented the communication of the policies and procedures to your employees. 3. There is evidence of monitoring the policies and procedures, as well as the system(s). After you determine the scope and boundary of the system(s) being reported on and establish the policies and procedures, you should prepare for a SOC audit by writing section 3 of the audit report and performing internal testing to validate that audit procedures will be met. Section 3 is the system description and acts as a security assessment plan (SAP) for the service auditor. It provides the service auditor guidance on what is included in the system boundary, scope, and current internal controls. A completed section 3 gives the service auditor the best guidance on how to plan and perform the audit. Once section 3 is completed, you or a hired advisor can take the testing guidance for a SOC 1 or SOC 2 and perform internal tests. This mock audit allows you to remediate any problems before the auditors perform their work. Here is a visual summary you can use to prepare for a SOC audit. 9

THE PHASES OF A SOC AUDIT Your service organization is ready for an audit, so what is next? While not required, a gap analysis by the CPA who will perform the actual audit or consultants (can be CPA or non-cpa) is recommended. The key to a successful analysis is that the person(s) performing the review have a detailed understanding of SOC to properly assess if you will meet the requirements of the formal audit. The reviewer should provide a gap analysis related to the testing section (section 4), identifying areas that you would currently fail during a formal audit. If the reviewer also evaluated the system description (section 3), then comments to improve the write-up should be included. After the gap analysis is performed and the reviewer has provided comments, you can remediate the findings. Fixing identified issues gives you a better opportunity for a successful, clean (unqualified) audit. Remediation can include updating policies, hardening the system(s), solidifying procedures, and having better substantive evidence of procedures, communication, and/or monitoring. Once ALL remediation is completed, you are ready for formal audit. Ideally, the audit period will not begin until AFTER remediation is completed. This results in a cleaner audit report. The audit procedures by the CPA firm may occur during the period under audit or after the audit period. The audit procedures performed will follow the applicable SOC guidance and should have a similar feel to the gap analysis. Let s look at the phases and related timing in an example below: 10

This example assumes that the service organization wants a cleaner audit report, so the audit period does not start until after remediation. That is NOT required. A SOC audit period can be for any timeframe. If the service organization chose a calendar year audit (January 1 to December 31), the audit report would show deficiencies (or exceptions) if conducted before the system findings were remediated. This leads to the potential for a qualified (i.e., bad) audit opinion. Many companies prefer minimal deficiencies in their first audit and elect to start the period later as seen in our example. After the first audit year, assuming there are no significant changes to the system(s), the next audit period can be a 12-month basis (January 1 to December 31) if desired, as presumably the identified deficiencies would be fixed. MULTI-USE BENEFITS OF A SOC 2 Many companies pursue a SOC 2 for the obvious benefit of simply obtaining a SOC 2 audit opinion. What they don t realize is that a properly implemented SOC 2 assessment can open doors to NIST SP800-53, PCI, ISO, HIPAA, and other accreditations (or vice versa) and consequently, a larger market share. A SOC 2 audit shares a large portion of documentation requirements with these other assessments. SOC 2 and many of these other assessments are based on the underlying framework of transparency of design and operation of controls. Because of this, a company that has invested in a SOC 2 audit has already completed a large portion of the work, for example, for an ISO 27001 accreditation. This gives companies an edge on their competition and access to a different market through reduced cost and faster assessments. Coalfire mapped required SOC 2 controls to various other assessment requirements based on our extensive experience completing these assessments. This mapping allows us to either utilize other IT security work performed and repurpose it for SOC 2 use, or start with a SOC 2 audit and use it as the groundwork for other accreditations. This do once, use many approach reduces the time and of Coalfire assessments now and in the future. Another example of the SOC 2 gaining momentum as a compliance standard has been the recent SOC 2 leveraging of the Common Security Framework (CSF) for HITRUST reporting. The American Institute of Certified Public Accountants (AICPA) and HITRUST worked together to create a mapping of SOC 2 controls to the CSF, which led to the development of a SOC 2 + HITRUST report. This report allows both frameworks to be reported on in a single, all-inclusive report. Our experience leading streamlined, comprehensive SOC 1 and SOC 2 compliance efforts gives Coalfire the advantage of understanding the underlying concepts of SOC engagements, how those concepts relate to other IT compliance standards, and how to best fit those concepts to specific client requirements. In tandem with this understanding, we have extensive experience performing streamlined and effective certification assessments under multiple requirements using a standardized and repeatable assessment methodology. In fact, our team has conducted more than 700 security assessments including those for FedRAMP, FISMA, HIPAA/HITECH, HITRUST, and PCI-DSS compliance. Coalfire has the most FedRAMP experience of any Third Party Assessment Organization (3PAO), having assessed more systems than any accredited 3PAO. 11

Through our detailed understanding of the SOC requirements, experience preparing companies for their accreditations, and mapping required controls for SOC audits to NIST SP800-53, HITRUST, PCI, ISO, and other requirements, Coalfire can grant your company access to new market share by not only supporting your SOC 1 and SOC 2 compliance efforts, but also using that framework to reduce the effort and cost of future assessments. ABOUT COALFIRE As cybersecurity risk management and compliance experts, Coalfire delivers cybersecurity advice, assessments, testing, and implementation support to IT and security departments, executives, and corporate directors of leading enterprises and public sector organizations. By addressing each organization s specific challenges, we re able to develop a long-term strategy that improves our clients overall cyber risk profiles. Armed with our trusted insights, clients can get to market faster with the security to succeed. Coalfire has offices throughout the United States and Europe. Coalfire.com Copyright 2014-2017 Coalfire Systems, Inc. All Rights Reserved. Coalfire is solely responsible for the contents of this document as of the date of publication. The contents of this document are subject to change at any time based on revisions to the applicable regulations and standards (HIPAA, PCI-DSS et.al). Consequently, any forward-looking statements are not predictions and are subject to change without notice. While Coalfire has endeavored to ensure that the information contained in this document has been obtained from reliable sources, there may be regulatory, compliance, or other reasons that prevent us from doing so. Consequently, Coalfire is not responsible for any errors or omissions, or for the results obtained from the use of this information. Coalfire reserves the right to revise any or all of this document to reflect an accurate representation of the content relative to the current technology landscape. In order to maintain contextual accuracy of this document, all references to this document must explicitly reference the entirety of the document inclusive of the title and publication date;; neither party will publish a press release referring to the other party or excerpting highlights from the document without prior written approval of the other party. If you have questions with regard to any legal or compliance matters referenced herein you should consult legal counsel, your security advisor and/or your relevant standard authority. WP_ServiceOrgControl_041017 12