Presentation - Effectively using SOC1, SOC2, and SOC3 ... · — SOC 1 and SOC 2 reports each can be issued as a Type 1 or Type 2 — SOC reports most commonly cover the presentation,

Outsourced operations

Effectively using SOC 1, SOC 2, and SOC 3 reports for increased assurance over outsourced operations

May 2019

kpmg.com

1© 2019 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative (“KPMG International”), a Swiss entity. All rights reserved. NDPPS 551743

With you TodayDak Mhlanga, Manager ITA&A• KPMG IT Audit and Attestation (ITA&A) practice with over 10 years experience

• Focus on evaluating information technology controls for Financial Statement Audit clients, IT Internal Audit Outsourcing, Service Organization Controls (SOC) and Sarbanes-Oxley assistance services (SOX)

• Higher education, Healthcare, Insurance, Broker Dealer experience

Parker Davis, Senior ITA&A Consultant • KPMG IT Audit and Attestation (ITA&A) practice with over 4 years experience

• Focus on evaluating information technology controls for Financial Statement Audit clients, IT Internal Audit Outsourcing, Service Organization Controls (SOC) and Sarbanes-Oxley assistance services (SOX)

• Federal Government, Financial Institutes, Broker Dealer experience


Agenda

— Introductions— History— Overview of SOC 1, SOC 2,

and SOC 3 reports — SOC reports for different

scenarios— How companies are

considering SOC 2 and SOC 3 reports

— Contrasting the level of detail provided by SOC 2 and SOC 3 reports

— SOC reports structure

— Type 1 vs. Type 2 SOC reports

— SOC engagement type summary

— Introduction of SOC 2 andSOC 3 system components

— Overview of SOC 2 and SOC 3 trust services principles

— SOC 2 and SOC 3 principles— Trust services principles and

criteria summary (2014 Version)

— Trust services principles and criteria summary

— SOC 2 and SOC 3 –Overview of common criteria

— Expanding SOC 2 reporting— Example SOC 2 + CSA

CCM— Example SOC 2 + NIST

800-53 framework— Example SOC 2 + HITRUST

common security framework— Leading practices for user

organization adoption of SOC reports

— Leading practices for user organization evaluation of SOC reports

— SOC 2 and SOC 3 adoption – Frequently asked

questions— Conclusion


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 SOC 1, SOC 2, and SOC 3 reports

— Internal control over financial reporting — Operational controls

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

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 domain options

— Transaction processing controls— Supporting information technology

general controls

— Security— Availability— Confidentiality— Processing integrity— Privacy— SOC 2+ additional criteria

Level ofstandardization

— Control objectives are defined by the service provider, and may vary depending on the type of service provided.

— Principles are selected by the service provider.— Specific predefined criteria are evaluated against rather than

control objectives.

SOC1 SOC2 SOC3


SOC reports for different scenariosSOC 1 Financial

Reporting Controls SOC 2 and SOC 3

— Financial services

— Asset management and custody services

— Healthcare claims processing

— Payroll processing

— Payment processing

— Cloud ERP service

— Data centercolocation

— IT systems management

— Cloud-based services (SaaS, PaaS, IaaS)

— HR services

— Security services

— E-mail, collaboration, and communications

— Any service where customers’ primary concern is security, availability, or privacy

Financial/Business Process and Supporting System Controls

SecurityAvailability

ConfidentialityProcessing Integrity

Privacy


How companies are considering SOC 2 and SOC 3 reports

Third-party Relationships

(all)

Data Management and Analysis Services

(Security, Availability, Confidentiality,

Processing Integrity) Asset Management(Security,

Confidentiality)

Cyber Security (Security)

SOC2 Over Processing Centers

(Security, Processing integrity)

HIPAA Business Associates(Security,

Confidentiality, SOC 2+ HITRUST)

Regulatory and Client Due Diligence Purposes

(Availability, Security)

Corporate Services, Fiduciary Asset Management,

and Client Accounting Services (Security and

Processing Integrity)

Data Center Hosting

(Security and Availability)

Electronic Banking(Security,

Confidentiality)

Business Outsourcing

Services(Security,

Processing Integrity)

Billing and ClaimPayment Services

(Security, Processing

Integrity)

Infrastructure(Availability,

Security)


Contrasting the level of detail provided by SOC 2 and SOC 3 reports

Common benefits

— Detailed report based on defined criteria for Security, Availability, Confidentiality, Processing Integrity, and/or Privacy

— Report includes a description of the system— Report includes management’s assertion

regarding controls

— Where subservice providers are used, management may include its monitoring controls over those operations.

— Report includes a description of the system— Report includes management’s assertion

regarding controls

Unique benefits

— SOC 2 is more flexible than SOC 3 for the service provider in that it permits carve-out of supporting services provided by subservice providers.

— SOC 2 includes detail on the service provider’s controls as well as the auditor’s detailed test procedures and test results, enabling the reader of the report to assess the service provider at a more granular level.

— SOC 3 provides an overall conclusion on whether the service provider achieved the stated Trust Services Criteria, and the user does not need to digest pages of detailed control descriptions and test procedures.

— May be distributed publicly; no limits to distribution

Potentialdrawbacks

— The user may need to obtain additional reports from applicable subservice providers to gain comfort over their activities.

— The user may not want to review the detail of the report (controls, tests, etc.) rather than an overall conclusion.

— Distribution of the report is more limited than SOC 3

— SOC 3 does not permit carve-out of significant subservice provider activities. If it is not feasible to cover those activities as part of the service provider’s audit, SOC 3 is not an available option.

SOC2 SOC3


SOC reports structure

Auditor’s opinion Auditor’s opinion Auditor’s opinion Auditor’s opinion

– Management assertion Management assertion Management assertion

System description (including controls)




Control objectives Control objectives Criteria Criteria (referenced)

Control activities Control activities Control activities –

Tests of operating

effectiveness*

Tests of operating

effectiveness*

Tests of operating

effectiveness*–

Results of tests* Results of tests* Results of tests* –

Other information (if applicable) Other information (if applicable) Other information (if applicable) –

Historical SAS 70 SOC 1 SOC 2 SOC 3


Type 1 vs. Type 2 SOC reports

— Period of time

— Covers the design of controls

— Covers the operating effectiveness of controls

— Point in time

— Covers the design of controls

— SOC 1 and SOC 2 reports each can be issued as a Type 1 or Type 2

— SOC reports most commonly cover the presentation, design, and effectiveness of controls over a period, usually 12 months (Type 2)

— A SOC report may cover a shorter period of time if the system/service has not been in operation for a full year or if annual reporting is insufficient to meet user needs

— A SOC report may also cover only the design of controls at a specified point in time for a new system/service for the initial examination of a system/service

Example – if a user organization requires a period of time report covering Security and Availability for a particular system, the user organization would request a SOC 2 Type 2 Security and Availability report from the service provider.

Type 1 Report – Design Type 2 Report – Design andOperating Effectiveness


SOC report type summary

Readiness Assessment

Develops an understanding of procedures and controls that will have relevance to a Type 1 Report or Type 2 report

Identifies control weaknesses that should be corrected before a formal SOC report engagement is performed

Compiles a complete list of control objectives and supporting control procedures

Assists in the development of the client’s Type 1 or Type 2 report

Provides an opportunity to evaluate and consider key processes and procedures and serves as a foundation for a Type 1 or Type 2 review

Allows the client to informally make changes to their procedures and controls while creating a framework for establishing a strong control environment

Type 1SOC Report

Detailed report that describes the service provider’s control objectives and control procedures and includes the auditor’s specific test procedures and results

The opinion covers whether the controls were fairly presented and suitably designed as of a point in time

Has informational value to customers

Can be issued in the near term to provide comfort over the design of controls before the Type 2 SOC report process begins

Serves as the foundation for subsequent Type 2 report

Type 2SOC Report

Detailed report that describes the service provider’s control objectives and control procedures and includes the auditor’s specific test procedures and results

The opinion covers whether the controls were fairly presented, suitably designed, and operating effectively over a period of time, typically 6 – 12 months in length

Can address customer’s requirements for testing the operating effectiveness of the service provider’s controls

Provides details and comfort regarding the effectiveness of the service provider’s controls

Report Description Benefits


Introduction of SOC 2 and SOC 3 system componentsA set of principles and criteria (trust services principles and criteria) have been developed to be used in evaluating controls relevant to the security, availability, processing integrity of a system, and the confidentiality and privacy of the information processed by the system. A system is designed, implemented, and operated to achieve specific business objectives (for example, delivery of services, production of goods) in accordance with management-specified requirements. The system components can be classified into the following five categories:

Infrastructure The physical structures, IT, and other hardware (for example, facilities, computers, equipment, mobile devices, and telecommunications networks)

Software The application programs and IT system software that supports application programs (operating systems, middleware, and utilities)

People The personnel involved in the governance, operation, and use of a system (developers, operators, entity users, vendor personnel, and managers)

Processes The automated and manual procedures

Data Transaction streams, files, databases, tables, and output used or processed by a system

DefinitionsSystem Components


Overview of SOC 2 and SOC 3 trust services principles

Security — The system is protected against unauthorized access, use, or modification.

Availability — The system is available for operation and use as committed or agreed.

Confidentiality — Information designated as confidential is protected as committed or agreed.

Processing Integrity — System processing is complete, valid, accurate, timely, and authorized.

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 (GAPP) issued by the AICPA and CPA Canada.

PrincipleDomain


SOC 2 and SOC 3 principles

Security— The system is protected against

unauthorized access, use, or modification.

— Required for every SOC 2 and SOC 3 report

— Security criteria 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

Availability— The system is available for

operation and use as committed or agreed.

— 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

Confidentiality— Information designated as

confidential is protected as committed or agreed.

— Most applicable where the user requires additional assurance regarding the service provider’s practices for protecting sensitive information

ProcessingIntegrity

— System processing is complete, valid, accurate, timely, and authorized.

— 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

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 GAPP issued by the AICPA and CPA Canada.

— 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

Report Trust Services Principle Applicability


Trust services principles and criteria summary

— Organization and Management

— Communications

— Risk management and design and implementation of controls

— Monitoring of controls

— Logical and physical access controls

— System operations

— Change management

— Capacity management

— Environmental and backup controls

— Disaster recovery

— Life cycle protection

— Access from within and outside system

— Vendor commitments and compliance

— Changes to commitments

— Error handling

— System inputs

— Data processing

— Data retention

— System output

— Data modification

— Notice and communication

— Choice and consent

— Collection

— Use, retention, and disposal

— Access

— Disclosure and notifications

— Quality

— Monitoring and enforcement

Common Criteria (Security)

Availability Confidentiality Processing Integrity Privacy

*Note: This version of the TSP was amended in March 2016 and effective for periods ended on, or after, December 15, 2016.


SOC 2 and SOC 3 – Overview of common criteria

Organization and management

The criteria relevant to how the organization is structured and the processes the organization has implemented to manage and support people within its operating units. This includes criteria addressing accountability, integrity, ethical values and qualifications of personnel, and the environment in which they function.

CommunicationsThe criteria relevant to how the organization communicates its policies, processes, procedures, commitments, and requirements to authorized users and other parties of the system and the obligations of those parties and users to the effective operation of the system.

Risk management and design and implementation of controls

The criteria relevant to how the entity (i) identifies potential risks that would affect the entity’s ability to achieve its objectives, (ii) analyzes those risks, (iii) develops responses to those risks including the design and implementation of controls and other risk mitigating actions, and (iv) conducts ongoing monitoring of risks and the risk management process.

Monitoring of controls

The criteria relevant to how the entity monitors the system, including the suitability, and design and operating effectiveness of the controls, and takes action to address deficiencies identified.

Logical and physical access controls

The criteria relevant to how the organization restricts logical and physical access to the system, provides and removes that access, and prevents unauthorized access to meet the criteria for the principle(s) addressed in the engagement.

System operationsThe criteria relevant to how the organization manages the execution of system procedures and detects and mitigates processing deviations, including logical and physical security deviations, to meet the objective(s) of the principle(s) addressed in the engagement.

Change managementThe criteria relevant to how the organization identifies the need for changes to the system, makes the changes following a controlled change management process, and prevents unauthorized changes from being made to meet the criteria for the principle(s) addressed in the engagement.

For the principles of availability, processing integrity, and confidentiality, a complete set of criteria is comprised of all of the common criteria and all of the criteria applicable to the principle(s) being reported on. Privacy uses the GAPP criteria.

Criteria DescriptionsCategory

Presenter

Presentation Notes

Building on what Dave and Marty have said, provide summary of the SOC2/3 criteria topics Explain modular structure, integration of security baseline criteria into the other principles SOC2/3 provides a great mechanism for gaining assurance regarding SOC2/3 criteria align well with other standards (i.e., ISO 27001 and the Cloud Security Alliance – Cloud Security Matrix based controls can be used to address criteria topics)


Expanding SOC 2 reporting

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

Approach Summary Examples


Example SOC 2 + CSA CCM

— Application and Interface Security

— Audit Assurance and Compliance

— Business Continuity Management and Operational Resilience

— Change Control and Configuration Management

— Data Security and Information Life Cycle Management

— Datacenter Security

— Encryption and Key Management

— Governance and Risk Management

— Human Resources

— Identity and Access Management

— Infrastructure and Virtualization Security

— Interoperability and Portability

— Mobile Security

— Security Incident Management, E-Discovery and Cloud Forensics

— Supply Chain Management, Transparency and Accountability

— Threat and Vulnerability Management

SOC 2 Confidentiality CriteriaSOC 2 Availability Criteria

SOC 2 Common Criteria (Security)

Additional Criteria based on CSA Cloud Controls Matrix


Example SOC 2 + NIST 800-53 framework

IDENTIFY

— Asset Management

— Business Environment

— Governance

— Risk Assessment

— Risk Assessment Strategy

PROTECT

— Access Control

— Awareness and Training

— Data Security

— Information Protection Processes and Procedures

— Maintenance

— Protective Technology

DETECT

— Anomalies and Events

— Security Continuous Monitoring

— Detection Processes

RESPOND

— Response Planning

— Communications

— Analysis

— Mitigation

— Improvements

RECOVER

— Recovery Planning

— Improvements

— Communications



Additional Criteria based on NIST 800-53 Framework


Example SOC 2 + HITRUST common security framework

The additional controls listed above are not intended to be all-compassing, and additional controls may be necessary based on each organization’s environment.

— Clear Desk and Clear Screen Policy

— Remote Diagnostic and Config Port Protection

— Network Connection Control

— Mobile Computing and Communications

— Teleworking

— Contact with Authorities

— Contact with Special Interest Groups

— Addressing Security When Dealing with Customers

— Addressing Security in Third-party Agreements

— Identification of Applicable Legislation

— Intellectual Property Rights

— Regulation of Cryptographic Controls

— Inventory of Assets

— Ownership of Assets

— Acceptable Use of Assets

— Cabling Security

— Outsourced Software Development

— Control of Technical Vulnerabilities

— Including InfoSec in the BC Management Process



Additional Criteria based on HITRUST Common Security Framework (CSF) Version 7


Leading practices for user organization adoption of SOC reports

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.

Criteria DescriptionsKey Activities


Leading practices for user organization adoption of SOC reports (continued)

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.

DescriptionsKey Activities


Leading practices for user organization evaluation 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?

Description of Considerations to EvaluateKey Areas


Frequently asked questions

What is the process to review SOC report?

— Identification of report subject matter and review of criteria— Definition of the system including infrastructure, software, people, procedures and data— Qualified of Unqualified report— Exceptions handling

Timelines — How far back can we rely on a SOC report

What to do when you can not rely on a SOC report

— ?


Questions


Conclusion— Three types of SOC reports have been defined to address distinct user requirements:

- SOC 1 focuses on matters relevant to user entities’ internal control over financial reporting.

- SOC 2 and SOC 3 reports apply more broadly to operational controls covering security, availability, confidentiality, processing integrity, and/or privacy across a variety of systems.

- SOC 2 and 3 can supplement a SOC 1 report by taking a “deeper dive” into key areas.

— Service providers should consider how SOC 2/SOC 3 reports can improve the efficiency and effectiveness of their efforts to meet customer and other compliance requirements related to operational controls.

— Customers of outsourced service providers should consider how SOC 2/SOC 3 reports can improve the efficiency and effectiveness of their vendor risk management programs.

— SOC 2 and SOC 3 adoption is growing significantly where vendor risk management concerns are more focused on security/availability/confidentiality/processing integrity/privacy than financial reporting risks.

— SOC 2 Enhanced Reporting and SOC 2 + Additional Criteria have been developed as effective tools to cover various compliance requirements and show synergies with other compliance mechanisms such as SOC1, ISO 27001, NIST, HITRUST, FedRAMP, etc.

© 2019 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative (“KPMG International”), a Swiss entity. All rights reserved. NDPPS 551743

The KPMG name and logo are registered trademarks or trademarks of KPMG International.

Some or all of the services described herein may not be permissible for KPMG Audit clients and their affiliates.

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.

kpmg.com/socialmedia

Documents

Presentation - Effectively using SOC1, SOC2, and SOC3 ... · — SOC 1 and SOC 2 reports each can be issued as a Type 1 or Type 2 — SOC reports most commonly cover the presentation,