Effectively using SOC1, SOC2, and SOC3 reports for increased assurance over outsourced control Jessica Thompson, KPMG Managing Director, US SOC Network Project Manager June 12, 2018

Agenda Introductions and Background SOC Reports Overview 1 Introductions and Background 2 SOC Reports Overview 3 SOC 2 Deeper Dive 4 Evaluating SOC Reports 5 Questions

1: Introductions and Background

2: SOC Reports Overview

History Organizations are increasingly outsourcing systems, business processes, and data processing to service providers in an effort to focus on core competencies, reduce costs, and more quickly deploy new application functionality. Many organizations have historically relied upon Statement on Auditing Standards (SAS) 70 reports to gain broad comfort over outsourced activities. SAS 70 was intended to focus specifically on risks related to internal control over financial reporting (ICOFR), and not broader objectives such as system availability and security. With the retirement of the SAS 70 report in 2011, Service Organization Control (SOC) reports have been defined by the American Institute of Certified Public Accountants (AICPA) to replace SAS 70 reports and more clearly address the assurance needs of the users of outsourced services. Three types of SOC reports —SOC 1, SOC 2, and SOC 3 —have been defined to address a broader set of specific user needs.

Overview of SOC1, SOC2 and SOC3 Reports The AICPA defined three types of SOC reports (summarized below) including reporting guidelines and application of reporting. Internal control over financial reporting (ICOFR) Operational controls SOC1* SOC2 SOC3** Summary Detailed report for users and their auditors Detailed report for users, their auditors, and specified parties Short report that can be more generally distributed, with the option of displaying a Web site seal Applicability Focused on financial reporting risks and controls, specified by the service provider. Most applicable when the service provider performs financial transaction processing or supports transaction processing systems Focused on: Security Availability Confidentiality Processing Integrity Privacy Applicable to a broad variety of systems * Sometimes also referred to as an SSAE 18, AT 801 or ISAE 3402 report ** Sometimes also referred to as a SysTrust, WebTrust, or Trust Services report

Scope of SOC1 and SOC 2 Reports Classes of Transactions Procedures for processing and reporting transactions Accounting records of the system Handling of significant events and conditions other than transactions Report preparation for users Other aspects relevant to processing and reporting user transactions Infrastructure Software Data INTRODUCE the SOC 2 report and then BRIEFLY DESCRIBE the similarities and differences between the 3 types of reports, and how they apply to different scenarios. DISCUSS the following key points: SOC 1: ICOFR; focused on financial reporting risks and controls specified by the service provider. Most applicable when the service provider performs financial transaction processing or supports transaction processing systems. SOC 2: Operational Controls; Focused on Security, Confidentiality, Availability, Processing Integrity and/or Privacy; applicable to a broad variety of systems. SOC 3: Same as SOC 2 without disclosing detailed controls and testing. A SOC 2 report is appropriate only for specified parties with sufficient knowledge and understanding of the service organization and the system, whereas a SOC 3® report is ordinarily appropriate for general use. EXPLAIN that for SOC 2 and SOC 3, a system is “the infrastructure, software, procedures, and data that are designed, implemented, and operated by people to achieve one or more of the organization’s specific business objectives in accordance with management specified requirements.” EXPLAIN that SOC2 and 3 are not intended for ICOFR purposes, but can be performed over a system that processes transactions related to ICOFR. EMPHASIZE that SOC 1 reports cannot be combined with SOC 2 or 3 reports. Each report should be a distinct deliverable. NOTE TO FACILITATOR: gauge the experience level of participants and consider expanding further on what a SOC 2/3 report covers, its purpose, how it relates to a SOC 1 report (for example, how a system that processes transactions for ICOFR could have both a SOC 1 and SOC 2/3), etc. TELL participants that in the past, sub-service organizations could not be carved-out of a SOC 3 report, but this has since changed. Procedures People

SOC Reports for Different Services SOC1SM Financial Reporting Controls SOC2SM/SOC3SM Operational Controls Financial services – Custodial services Healthcare claims processing Payroll processing Payment processing Cloud ERP service Data center co-location IT systems management Enterprise cloud email Cloud collaboration SaaS-based HR services Security-as-a-service Any service where third parties’ primary concern is security, availability or privacy Facilitator Notes: DEBREIF: In the far right column are those scenarios where a SOC2/SOC3 report would likely apply. Many service organizations are now being asked for both a SOC1 and SOC2 report

SOC Report Business Purposes Besides the differences on the types of services provided each SOC report has a different business purpose and requirements from the user entities’ perspective. SOC 1 SOC 2 Supports financial transaction and ICOFR reporting for management Supports the financial statement audit and ICOFR examination for external auditors User groups typically include: SOX Compliance Internal Audit Controllers Group Report needs to cover processing and supporting controls for significant transactions Report needs to cover most of the period of their financial statements with a “bridge” letter to cover the rest May require additional procedures if there are exceptions, the period is considered “stale” or there is a significant event or issue Supports operational and compliance risk management User groups typically include: Vendor risk management Regulatory compliance Information Security Business Continuity Procurement Report needs to cover the key services provided which represent a significant operational risk to them Report not tied to a period; rather their VRM cycle based on risk assessment May be part of the procurement process

Type 1 versus Type 2 Report Type 2 – period of time Type 1 – point in time Section I – Service auditor’s report Section II – Management’s assertion Section III – Management’s description of the system Section IV – Objectives or Criteria, related controls and tests of controls Section V – Other information provided by the service organization Same as Type 2; the controls matrix can be included in Section III or Section IV Operating effectiveness is not tested TOD procedures and results are not included Introduce the module. SAY: Now that we have discussed the differences and commonalities between SOC 1 and SOC 2 reports, let’s take a deeper dive into the components of the SOC 2 report. DESCRIBE the layout of the SOC 2 report and the differences between type 1 and type 2 reports. EXPLAIN to participants that in this module we will focus on Sections I through III, due to the guidance changes relating to the service auditor’s report, management’s assertion, and required components of management’s description. In the next module will cover the details of section IV, including the updated Trust Services Criteria. TELL participants that for type 1 reports, the control matrices can be included in section III or section IV. However, it is very important that we do NOT list any test procedures or results. Some teams have attempted to present tests of design. However, that can be misleading and should be avoided in type 1 reports.

Contrasting SOC 1 versus SOC 2 reports Required focus Internal control over financial reporting Operational controls Defined scope of system Classes of transactions Procedures for processing, and reporting transactions Accounting records of the system Handling of significant events and conditions other than transactions Report preparation for users Other aspects relevant to processing and reporting user transactions Infrastructure Software Procedures People Data Control domains covered Transaction processing controls* Supporting information technology general controls *Note: In certain cases, a SOC 1 report might cover supporting IT controls only, depending on the nature of services provided. Security Availability Confidentiality Processing Integrity Privacy Level of standardization Control objectives are defined by the service provider, and may vary depending on the type of service provided. Categories are selected by the service provider Specific predefined Points of Focus and Criteria are used rather than control objectives.

CUECs and CSOCs CSOCs only apply when the carve-out method is used Definitions: Complementary User Entity Controls (CUECs) – Controls that management of the service organization assumes, in the design of the service organization’s system, will be implemented by user entities and are necessary to achieve the control objectives or criteria stated in management’s description of the service organization’s system. Complementary Subservice Organization Controls (CSOCs) – Controls that management of the service organization assumes, in the design of the service organization’s system, will be implemented by the subservice organizations and are necessary to achieve the control objectives or criteria stated in management’s description of the service organization’s system. CUECs are not intended to be a broad list of user responsibilities. CUECs and CSOCs should be specific and relevant to the services provided to user entities and the control objectives or criteria. We are required to evaluate whether CUECs and CSOCs included in the description are adequately described. CSOCs only apply when the carve-out method is used Facilitator Notes: CUECs are defined as controls that the service organization assumes, in the design of its service, will be implemented by user entities. CUECs are not intended to be a broad list of user responsibilities. CUEC’s should only include controls that are necessary to achieve the control objectives.   Not all CUECs listed in the service auditor's report will be applicable. KAM 48.1425   12

CUECs and CSOCs Service Organization Subservice Organization User Services Outsourced Provided Subservice Organization Services Provided Outsourced User Entity Scope of a SOC Report CSOCs Scope of a SOC report (Carve-Out Method) CUECs Scope of a SOC Report – Carve Out Method Explain CSOCs and CUECs, and how they are needed for controls objectives to be met.

Organization (Payroll Services) CUEC Example Service Organization (Payroll Services) Payroll Services User Entity Scope of a SOC Report Scope of a SOC Report – Carve Out Method CUECs In this example, the service organization provides payroll services to user entities and electronically receives payroll data from user entities, and includes the following control objective in its description: Controls provide reasonable assurance that input to the payroll application is authorized. This control objective could not be achieved without the implementation of input controls at the user entities, because transaction initiation and authorization rests with them. The service organization can only be responsible for determining that input transactions are received from authorized sources as established by the user entity. In this scenario, a CUEC would be included such as: Controls should be established to provide reasonable assurance that input to the payroll application is authorized. Alternatively, the control objective could be modified so that it could be achieved without a complementary user entity control, such as the following: Controls provide reasonable assurance that input is received from authorized sources. The facilitator should EXPLAIN that alternatively, the control objective could be modified so that it could be achieved without a complementary user entity control, such as the following: Controls provide reasonable assurance that input is received from authorized sources. Facilitator should EXPLAIN that if a service organization uses an application hosting subservice organization to manage all of its information technology systems, controls at the application hosting subservice organization are likely to be necessary for the service organization's application controls to operate effectively. Accordingly, the description would include a complementary subservice organization control consideration, such as the following: Controls provide reasonable assurance that changes to application programs and related data management systems are authorized, tested, documented, approved, and implemented to result in the complete, accurate, and timely processing and reporting of transactions and balances.

CSOC Example Service Organization (Payroll Services) Subservice Application Hosting Subservice Organization (Payroll Application Software Provider) Scope of a SOC Report – Carve Out Method Scope of a SOC report (Carve-Out Method) CSOCs In this example, a service organization uses an application hosting subservice organization to manage all of its information technology systems. The controls at the application hosting subservice organization are likely to be necessary for the service organization's application controls to operate effectively. Accordingly, the description would include a complementary subservice organization control consideration, such as the following: Controls provide reasonable assurance that changes to application programs and related data management systems are authorized, tested, documented, approved, and implemented to result in the complete, accurate, and timely processing and reporting of transactions and balances. Facilitator should EXPLAIN that if a service organization that provides payroll services to user entities and electronically receives payroll data from user entities would include the following control objective in its description: Controls provide reasonable assurance that input to the payroll application is authorized. This control objective could not be achieved without the implementation of input controls at the user entities because transaction initiation and authorization rests with them. The service organization can only be responsible for determining that input transactions are received from authorized sources as established by the user entities. Accordingly, the description would include a complementary user entity control consideration, such as the following: Controls are implemented by user entities to provide reasonable assurance that input to the payroll application is authorized. Alternatively, the control objective could be modified so that it could be achieved without a complementary user entity control, such as the following: Controls provide reasonable assurance that input is received from authorized sources. Facilitator should EXPLAIN that if a service organization uses an application hosting subservice organization to manage all of its information technology systems, controls at the application hosting subservice organization are likely to be necessary for the service organization's application controls to operate effectively. Accordingly, the description would include a complementary subservice organization control consideration, such as the following: Controls provide reasonable assurance that changes to application programs and related data management systems are authorized, tested, documented, approved, and implemented to result in the complete, accurate, and timely processing and reporting of transactions and balances.

Carve-out vs. Inclusive Method There are two methods for addressing the services provided by a subservice organization: In order for Management's criteria to be suitable for either method, they must include the services performed by a subservice organization, if any, including whether the carve-out method or the inclusive method has been used in relation to them. The inclusive method is generally feasible if, for example, the service organization and the subservice organization are related, or if the contract between the service organization and the subservice organization provides for the use of the inclusive method. Inclusive method - The subservice organization's relevant control objectives and controls are included in the description and in the scope of our examination. Carve-out method - The subservice organization's relevant control objectives and controls are excluded from the description and from the scope of our examination. Facilitator Notes: If a service organization uses a subservice organization, the service auditor's report may use either the inclusive method or a carve out method of reporting. An inclusive method report, includes subservice organization's relevant control objectives and related controls. In the service organization's description of its system as well as in the scope of the service auditor's engagement. Conversely if it is a carve out method of reporting then the subservice organization’s relevant control objectives and related controls are not included in the report.

3: SOC 2 Deeper Dive

SOC 2 and SOC 3 Trust Services Categories Security Availability Confidentiality Privacy Processing integrity EXPLAIN that a SOC 2 may apply to any type of system, not only financial reporting systems. DESCRIBE each of the 5 Trust Services Criteria categories on the slide and their associated applicability. EXPLAIN that a SOC 2 report can contain one or more of the 5 trust service criteria categories. AUGMENT the discussion with the following details around the Trust Services criteria categories: Security: Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems and affect the entity’s ability to meet its objectives. Availability: Information and systems are available for operation and use to meet the entity’s objectives. Confidentiality: Information designated as confidential is protected to meet the entity’s objectives. Processing Integrity: System processing is complete, valid, accurate, timely, and authorized to meet the entity’s objectives. Privacy: Personal information is collected, used, retained, disclosed, and disposed to meet the entity’s objectives. TELL participants that for SOC 2 and SOC 3, management is responsible for meeting its commitments to customers. Therefore, the objectives in a SOC 2 or 3 engagement relate to meeting its commitments to customers and system requirements. TELL participants: Trust Services common criteria constitutes a complete set of criteria for the Security category. EXPLAIN that in the past, the security category was required for every SOC 2/3 report, but that is no longer the case. EMPHAISE that the common criteria are applicable to all of the categories. There are additional category-specific criteria for availability, processing integrity, confidentiality, and privacy. TELL participants that regardless of the criteria categories being covered, the common criteria apply and should be included.

SOC 2 Trust Services Categories Security Availability Confidentiality Privacy Processing integrity Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems and affect the entity's ability to meet its commitments and system requirements. DISCUSS Security at a high level. Note: We will not review the details of the Security Trust Services category here. REMIND participants that the common criteria are applicable to all of the trust services categories. There are additional category-specific criteria for availability, processing integrity, confidentiality, and privacy. TELL participants that regardless of the trust services categories being covered, the common criteria apply and should be included.

SOC 2 Trust Services Categories (continued) Security Availability Confidentiality Privacy Processing integrity Applicability Most common category in SOC 2 and SOC 3 reports Security criterion are incorporated into the common criteria set because security controls provide a foundation for the other domains Applicable to all outsourced environments, particularly since users of the system require assurance regarding the service provider’s security controls for any system, nonfinancial or financial EXPLAIN that Security refers to the protection of: - information during its collection or creation, use, processing, transmission, and storage and - systems that use electronic information to process, transmit or transfer, and store information to enable the entity to meet its principal service commitments and system requirements. Controls over security prevent or detect the breakdown and circumvention of segregation of duties, system failure, incorrect processing, theft or other unauthorized removal of information or system resources, misuse of software, and improper access to or use of, alteration, destruction, or disclosure of information.

SOC 2 Trust Services Categories Security Availability Privacy Information and systems are available for operation and use to meet the entity’s commitments and system requirements. Processing integrity Confidentiality REVIEW A 1.0 Availability. EXPLAIN that this Trust Services category addresses how the organization provides information and systems to be available for operation and use to meet the entity’s commitments and system requirements.

SOC 2 Trust Services Categories (continued) Security Availability Confidentiality Privacy Processing integrity Applicability Commonly included-particularly where disaster recovery is provided as part of the standard service offering Most applicable where enterprise users require assurance regarding processes to achieve system availability SLAs as well as disaster recovery which cannot be covered as part of SOC 1 reports EXPLAIN that Availability refers to the accessibility of information used by the entity's systems, as well as the products or services provided to its customers. The availability objective does not, in itself, set a minimum acceptable performance level; it does not address system functionality (the specific functions a system performs) or usability (the ability of users to apply system functions to the performance of specific tasks or problems). However, it does address whether systems include controls to support accessibility for operation, monitoring, and maintenance.

SOC 2 Trust Services Categories Security Information designated as confidential is protected to meet the entity's commitments and system requirements. Privacy Availability Processing integrity Confidentiality REVIEW C 1.0 Confidentiality EXPLAIN that this Trust Services category addresses how information designated as confidential is protected to meet the entity’s commitments and system requirements. EXPLAIN that the need for information to be confidential may arise for many different reasons. For example, the information may be proprietary, intended only for entity personnel. Confidential information may include personal information as well as other information, such as trade secrets and intellectual property. REMIND participants that when performing an engagement that addresses the confidentiality Trust Services category, the system boundaries should cover, at a minimum, all the system components as they relate to the confidential information life cycle which consists of collection, use, retention, disclosure and disposal.

SOC 2 Trust Services Categories (continued) Security Availability Confidentiality Privacy Processing integrity Applicability Most applicable where the user requires additional assurance regarding the service provider’s practices for protecting sensitive information Processing integrity Confidentiality EXPLAIN that Confidentiality addresses the entity's ability to protect information designated as confidential from its collection or creation through its final disposition and removal from the entity's control in accordance with management's principal service commitments and system requirements. Information is confidential if the custodian (for example, an entity that holds or stores information) of the information is required to limit its access, use, and retention and restrict its disclosure to defined parties (including those who may otherwise have authorized access within its system boundaries). Confidentiality requirements may be contained in laws or regulations or in contracts or agreements that contain commitments made to customers or others. The need for information to be confidential may arise for many different reasons. For example, the information may be proprietary, intended only for entity personnel. EMPHASIZE that Confidentiality is distinguished from privacy in that privacy applies only to personal information, whereas confidentiality applies to various types of sensitive information. In addition, the privacy objective addresses requirements regarding collection, use, retention, disclosure, and disposal of personal information. Confidential information may include personal information as well as other information, such as trade secrets and intellectual property. EXPLAIN that clients often assume that the Privacy Trust Services category should be covered for their system, when they actually should select the Confidentiality category. While both categories cover the information life cycle, the Privacy category is significantly more extensive, and addresses only Personally Identifiable Information (PII). Conversely, the confidentiality category addresses the client’s ability to protect information that they designate as confidential, which could include PII. Also, we will see later in this module that the additional criteria and associated points of focus for confidentiality are not as extensive as they are for privacy.

SOC 2 Trust Services Categories Security System processing is complete, valid, accurate, timely, and authorized to meet the entity's commitments and system requirements. Privacy Availability Processing integrity Confidentiality REVIEW PI 1.0 Processing Integrity. EXPLAIN that this Trust Services category addresses how the organization managed the completeness, validity, accuracy, timeliness, and authorization of system processing to meet the entity’s commitments and system requirements.

SOC 2 Trust Services Categories (continued) Security Availability Confidentiality Privacy Processing integrity Applicability Potentially applicable for a wide variety of nonfinancial and financial scenarios wherever assurance is required as to the completeness, accuracy, timeliness, and authorization of system processing EXPLAIN that Processing integrity refers to the completeness, validity, accuracy, timeliness, and authorization of system processing. Processing integrity addresses whether systems achieve the aim or purpose for which they exist and whether they perform their intended functions in an unimpaired manner, free from error, delay, omission, and unauthorized or inadvertent manipulation. Because of the number of systems used by an entity, processing integrity is usually only addressed at the system or functional level of an entity.

SOC 2 Trust Services Categories Security Personal information is collected, used, retained, disclosed, and disposed to meet the entity’s commitments and system requirements. Privacy Availability Processing integrity Confidentiality EXPLAIN that this trust service category considers how personal information is collected, used, retained, disclosed, and disposed of in conformity with the commitments in the entity’s privacy notice and with their system requirements.

SOC 2 Trust Services Categories (continued) Security Availability Confidentiality Privacy Processing integrity Applicability Most applicable where the service provider interacts directly with end users and gathers their personal information Provides a strong mechanism for demonstrating the effectiveness of controls for a privacy program EXPLAIN that Privacy addresses the entity's ability to protect personal information as it is collected, used, retained, disclosed, and disposed. EXPLAIN that a company will give notice to the consumers regarding their policies. The company’s commitments are those made in the notice and the company needs to have controls to ensure they are in compliance with that notice. Here are some example controls: - The Chief Privacy Officer reviews the notice and documents his or her approval that the notice includes the appropriate disclosures. - The entity provides notice of its privacy practices to data subjects of the system (upon data collection, from each mode of collection, and when any changes are made to the entity's privacy practices through email and surface mail). - Before personal information is collected, the entity communicates to the internal and external users the purpose and use of the collection of personal information, including detailed use, ability to opt-out, enhancement (enrichment) or inference, sharing, disclosure, access, security, retention, and disposal of personal information. - The privacy staff reviews procedures to assess the nature of the information collected to determine whether personal information received requires an explicit consent. Members of the privacy staff verify that the entity has legal ground to collect data from the data subjects and that such legal grounds are documented prior to collection. Additionally, members of the privacy staff verify, on a test basis, that the entity has requested and received explicit written consent from the data subjects, when such consent is required. For the confidentiality category, information is designated as confidential by commitment or agreement. This is between two businesses and not directly with the consumer, as it is for privacy. Here are some example controls: -The Company has a defined information classification scheme for the labeling and handling of data, which classifies data into four levels: public, internal use, confidential, and restricted. -Changes to the confidentiality policies that affect customer contracts are formally communicated. TELL participants that if the system that is the subject of the SOC 2 examination does not create, collect, transmit, use, or store personal information, or if the service organization does not make commitments to its system users related to one or more of the matters described in the preceding paragraph, a SOC 2 examination that addresses the privacy criteria may not be useful because many of the privacy criteria will not be applicable. Instead, a SOC 2 examination that addresses the confidentiality criteria is likely to provide report users with the information they need about how the service organization maintains the confidentiality of sensitive information used by the system.

Organization of Common Criteria Control Environment Communication and Information 9 Risk Assessment Monitoring Activities Common Criteria Control Activities Logical and Physical Access Controls Classifications System Operations EXPLAIN that the Trust Services criteria have been aligned to the 17 criteria (known as principles) presented in Internal Control—Integrated Framework, which was revised in 2013 by COSO. Control environment, Communication and information, Risk assessment, Monitoring activities, and Control Activities (COSO components) contain the 17 principles. In addition to the 17 principles, the Trust Services criteria include additional criteria supplementing COSO principle 12: The entity deploys control activities through policies that establish what is expected and procedures that put policies into action (supplemental criteria). The additional criteria are included under Logical and physical access controls, Systems operations, Change management, and Risk mitigation. BRIEFLY REVIEW each of the classifications   of the 9 common criteria: Control Environment (CC1 series), Communication and Information (CC2 series), Risk Assessment (CC3 series), Monitoring Activities (CC4 series), and Control Activities (CC 5 series). EXPLAIN that the control activities classification is further broken down into the following sub-classifications: Logical and Physical Access Controls (CC6 series), System Operations (CC7 series), Change Management (CC8 series), and Risk Mitigation (CC 9 series). Change Management Risk Mitigation

Expanding SOC 2 Reporting Approach Summary Examples SOC 2 Enhanced Reporting Other Information section of the SOC 2 report includes mappings to demonstrate alignment of tested controls with the requirements of a specific standard or common vendor security questionnaire topics. Mapping to ISO 27001/27002 control objective topics Mapping to HIPAA security requirements Mapping to relevant PCI DSS requirements Mapping to relevant NIST 800‑53 requirements SOC 2 + Additional Subject Matter Includes additional criteria or additional subject matter based on other standards and specifically covered by opinion Permitted since the creation of the SOC 2 reporting framework SOC 2 + Cloud Security Alliance Cloud Controls Matrix SOC 2 + NIST 800‑53 Framework SOC 2 + HITRUST SOC 2 + COBIT 5.0 SOC 2 + COSO 2013 Framework SOC 2 + ISO 27001 EXPLAIN that the Trust Services criteria have been aligned to the 17 criteria (known as principles) presented in Internal Control—Integrated Framework, which was revised in 2013 by COSO. Control environment, Communication and information, Risk assessment, Monitoring activities, and Control Activities (COSO components) contain the 17 principles. In addition to the 17 principles, the Trust Services criteria include additional criteria supplementing COSO principle 12: The entity deploys control activities through policies that establish what is expected and procedures that put policies into action (supplemental criteria). The additional criteria are included under Logical and physical access controls, Systems operations, Change management, and Risk mitigation. BRIEFLY REVIEW each of the classifications   of the 9 common criteria: Control Environment (CC1 series), Communication and Information (CC2 series), Risk Assessment (CC3 series), Monitoring Activities (CC4 series), and Control Activities (CC 5 series). EXPLAIN that the control activities classification is further broken down into the following sub-classifications: Logical and Physical Access Controls (CC6 series), System Operations (CC7 series), Change Management (CC8 series), and Risk Mitigation (CC 9 series).

4: Evaluating SOC Reports

Leading practices for user organization adoption of SOC reports Key Activities Criteria Descriptions Inventory vendor relationships Inventory existing outsourced vendor relationships to determine where the organization has obtained, and requires third‑party assurance going forward. Assess vendor risks Assess the key risks associated with significant outsourced vendors (e.g., Security, Availability, other risks). Identify relevant reports Determine whether a SOC 1 report is required for financial reporting purposes. Determine whether detailed SOC 2 reports or summary level SOC 3 reports are required for key service providers. Also determine which principles should be covered within the SOC 2/SOC 3 reports (i.e., Security, Availability, Confidentiality, Processing Integrity, and/or Privacy). Contractual provisions Assess what, if any, specific audit reports are required by contract, and whether contracts have right to audit clauses. Determine how any historical SAS 70 references should be updated to the relevant types of SOC report. Determine whether SOC 2/SOC 3 reports should be required by contract. Vendor monitoring Determine the frequency with which key outsourced vendors will be assessed. Build the process of obtaining and reviewing SOC reports, and following up on any areas of concern into the vendor monitoring process. * Note: Applicable for Type 2 reports

Leading practices for user organization adoption of SOC reports Key Activities Descriptions Vendor due diligence Consider requesting relevant SOC reports as part of the due diligence process for assessing, and on‑boarding new outsourced service providers. Communication plan Where assurance reports are desirable, key points should be communicated, and confirmed with the service providers: Scope of the system covered Specific report to be provided (SOC 1, SOC 2, SOC 3) Type of report to be provided, and period covered (i.e., Type 2 for a specified period, or in certain cases, Type 1 as of a specified point in time) Control domains covered (included control objectives for SOC 1, included principles for SOC 2/SOC 3) Existence of any key supporting subservice providers (e.g., data center providers, IaaS providers), and whether they are included in scope Expected report delivery date. * Note: Applicable for Type 2 reports

Leading practices for user organization adoption of SOC reports Opinion What is the scope of the report? What is the period covered; is there a significant gap from the end date of the report period to your year‑end date? Is a subservice organization disclosed, was the “Inclusive” or “Carve‑out” method used? If the “Carve‑out” method was used, based on the significance and relevance of the service being provided by the subservice organization, you may need to obtain and evaluate an assurance report from that subservice organization. Was the opinion unqualified or qualified? Description of System and Controls Understanding the system and its related processes and determining the relevancy and significance to your control environment Do the control objectives and controls (SOC 1), principles, and criteria (SOC 2/3) address the risks relevant to your processing environment? Complementary User Entity Controls To achieve the stated control objectives, or principles and criteria, does the report highlight specific control activities for which the user is responsible? Were these complementary user entity controls present and operating effectively during the period? Control Objectives (SOC 1) Principle/Criteria (SOC 2 and SOC 3) Does the report cover all of the relevant control objectives for the user organization’s purposes? (SOC 1) Do the controls and testing adequately support the objectives? (SOC 1) Does the report cover the relevant principle(s) and criteria? (SOC 2/3) Is the report properly scoped to cover all of the relevant areas for the user organization’s purposes? (SOC 2/3) Do the controls and testing adequately support the criteria? (SOC 2) Results of Tests (N/A for SOC 3) Does the report need to include the service auditor’s test procedures and associated results? Were there exceptions noted by the service auditor; how might the exception(s) impact your risk assessments? Changes noted during the period Have any significant changes in systems, subservice providers, or controls occurred during the examination period and, if so, do they have any impact on the user? Key Areas Description of Considerations to Evaluate

Monitoring of Subservice Organizations by Management Management’s description, and the scope of our engagement includes controls at the service organization that monitor the effectiveness of controls at the subservice organization, which may include some combination of ongoing monitoring to determine that potential issues are identified timely and separate evaluations to determine that the effectiveness of internal control is maintained over time. Reviewing and reconciling output reports, Holding periodic discussions with the SSO Making regular site visits to the SSO to discuss the design and effectiveness of controls, planned changes, operating issues, etc. Testing controls at the SSO by members of the service organization's internal audit function, Reviewing type 2 SOC reports on the SSO’s system, Monitoring external communications, such as customer complaints relevant to the services by the SSO, and Logging and tracking the resolution of issues that result from the SSO’s processing Monitoring activities include: Facilitator Notes: Discuss the various steps that management can take to monitor subservice organization, these include (but not limited to) Periodic meetings Testing controls at subservice organizations Customer complaints, issue tracking Regardless of whether the inclusive or carve-out method is used, we are required to evaluate whether management has included a description of the monitoring activities they perform in their description. 35

5: Questions

Thank you

Some or all of the services described herein may not be permissible for KPMG audit clients and their affiliates. kpmg.com/socialmedia The information contained herein is of a general nature and is not intended to address the circumstances of any particular individual or entity. Although we endeavor to provide accurate and timely information, there can be no guarantee that such information is accurate as of the date it is received or that it will continue to be accurate in the future. No one should act on such information without appropriate professional advice after a thorough examination of the particular situation. © 2018 KPMG LLP, a Delaware limited liability partnership and the US member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative (“KPMG International”), a Swiss entity. All rights reserved. NDPPS 780062 The KPMG name and logo are registered trademarks or trademarks of KPMG International.