Soc2 PDF
Soc2 PDF
Disclaimer
ISACA® has designed this publication, SOC 2SM User Guide (the “Work”), primarily as an
educational resource for user entities. ISACA makes no claim that use of any of the Work will
assure a successful outcome. The Work should not be considered inclusive of all proper information,
procedures and tests or exclusive of other information, procedures and tests that are reasonably
directed to obtaining the same results. In determining the propriety of any specific information,
procedure or test, user entities should apply their own professional judgment to the specific
circumstances presented by the particular systems or information technology environment.
Copyright
© 2012 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced,
modified, distributed, displayed, stored in a retrieval system or transmitted in any form by any
means (electronic, mechanical, photocopying, recording or otherwise) without the prior written
authorization of ISACA. Reproduction and use of all or portions of this publication are permitted
solely for academic, internal and noncommercial use and for consulting/advisory engagements, and
must include full attribution of the material’s source. No other right or permission is granted with
respect to this work.
ISACA
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Phone: +1.847.253.1545
Fax: +1.847.253.1443
Email: [email protected]
Web site: www.isaca.org
Feedback: www.isaca.org/SOC2
Participate in the ISACA Knowledge Center: www.isaca.org/knowledge-center
Follow ISACA on Twitter: https://twitter.com/ISACANews
Join ISACA on LinkedIn: ISACA (Official), http://linkd.in/ISACAOfficial
Like ISACA on Facebook: www.facebook.com/ISACAHQ
AICPA
1211 Avenue of the Americas
New York, NY 10036-8775
Phone: +1.212.596.6200
Fax: +1.212.596.6213
Email: [email protected]
Web site: www.aicpa.org
Follow AICPA on Twitter Feeds, LinkedIn Networks, Facebook Communities and YouTube
Channels: www.aicpa.org/News/Pages/SocialMedia.aspx#twitter
Acknowledgments
ISACA wishes to recognize:
Development Team
Floris Ampe, CISA, CGEIT, CRISC, CIA, ISO 27001, PwC, Belgium
Bart Peeters, CISA, PwC, Belgium
Sara Weiland, CISA, PwC LLP, USA
Work Group
Phillip J. Lageschulte, CGEIT, CPA, KPMG LLP, USA, Chairman
George Galindo, CISA, CPA, PwC, USA
Chris Halterman, CPA, Ernst & Young LLP, USA
Mary Stoltenberg-Smith, CISA, CISM, CRISC, Federal Reserve Bank Chicago, USA
Expert Reviewers
Barbara Baldwin, SVP, Ocean First Bank, USA
Rich Chew, CISA, CISM, CGEIT, Emerald Management Group, USA
Everett C. Johnson Jr., CPA, Deloitte & Touche LLP (retired), USA
Chris Kradjan, CRISC, CPA, Moss Adams LLP, USA
John W. Lainhart IV, CISA, CISM, CGEIT, CRISC, IBM Global Business Services, USA
Jon Long, CISA, CompliancePoint, USA
Rena Mears, CISA, CISSP, CPA, Deloitte & Touche, USA
Tom Patterson, CISA, CGEIT, CRISC, CPA, IBM Global Business Services, USA
Richard Reinders, GCFA, GCIH, Sec+, Lake Trust Credit Union, USA
Lily Shue, CISA, CISM, CGEIT, CRISC, Sunera LLC, USA
David A. Williams, CRISC, PMP, Ocean First Bank, USA
Daniel Zimerman, CISA, CEH, CISSP, CPT, GCIH, IQ Solutions, USA
Acknowledgments (cont.)
Knowledge Board
Marc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, Chairman
Steven A. Babb, CGEIT, CRISC, Betfair, UK
Thomas E. Borton, CISA, CISM, CRISC, CISSP, Cost Plus, USA
Phillip J. Lageschulte, CGEIT, CPA, KPMG LLP, USA
Salomon Rico, CISA, CISM, CGEIT, Deloitte, Mexico
Steven E. Sizemore, CISA, CIA, CGAP, Texas Health and Human Services Commission, USA
Special Recognition
ISACA New Jersey Chapter for its financial support
ASIS International
Hewlett-Packard
IBM
Symantec Corp.
Table of Contents
Section 1. Introduction...............................................................................................7
Background............................................................................................................7
Scope and Approach..............................................................................................8
Purpose of the SOC 2 User Guide (Benefits and Value)......................................8
Who Should Use This Guide?...............................................................................9
Glossary.....................................................................................................................53
Section 1. Introduction
Background
From the early days of the SAS 70 report, user entities have sought a “SAS 70-like”
report that addresses more than just their financial reporting controls. In May 2011,
AICPA issued Report on Controls at a Service Organization Relevant to Security,
Availability, Processing Integrity, Confidentiality or Privacy (SOC 2), which uses
AICPA’s Trust Services Principles and Criteria to report on controls at a service
organization. The SOC 2 report provides service organizations and user entities
more flexibility related to both compliance and operational reporting controls.
Although the distribution is restricted, the limitations make it as broad as possible
and available to customers who can understand the report’s content. However,
the report should not be distributed to unintended users such as other user entity
vendors unless an agreement has been made with the service organization.
The SOC 2 report is designed to meet user entity requirements beyond that of a
SSAE 16 SOC 1 report. A SOC 2 report addresses risk of IT-enabled systems
and privacy programs beyond the controls necessary for financial reporting.
Additionally, SOC 2 uses predefined standard control criteria for each of the
defined principles (see section 3), which allows for more direct comparison of
service organizations’ internal control environments.
This user guide focuses on the SOC 2 report issued by service organizations
relevant to the effectiveness of the design and operation of their controls related to
security, availability, processing integrity, confidentiality or privacy. The guide is
structured as follows:
• Section 2 briefly describes various service organization reports (SOC 1, SOC 2
and SOC 3).
• Section 3 provides a detailed explanation of the standards used and the types,
scope and content for a SOC 2 report.
• Section 4 evaluates how to determine the user entity’s needs when obtaining a
SOC 2 report.
• Section 5 explains how to communicate the user entity’s needs to the
service organization.
• Section 6 explains how to interpret the SOC 2 report provided by the
service organization.
Together, AICPA and ISACA are releasing this guide to provide the reader
with information needed to interpret the SOC 2 reports received from a service
organization. This guide also complements the companion piece for the SOC 1
guide which can be found at www.isaca.org/service-auditor-standard.
To assess and address the risk associated with an outsourced service, the user
entity’s management needs information about the effectiveness of the design and
operation of a service organization’s controls over the system through which the
services are delivered. To gather this information, user entity management may ask
the service organization for a SOC 2 report. The report may address the design and
operating effectiveness of controls over the service organization’s systems that are
relevant to the systems’ security, availability or processing integrity, or it may cover
the confidentiality or privacy of the information processed for user entities.
There are three types of SOC reports that can be issued by the service organization,
depending on the intended purpose:
• SOC 1—Report on Controls at a Service Organization Relevant to User Entities’
Internal Control over Financial Reporting (ICFR)
• SOC 2—Report on Controls at a Service Organization Relevant to Security,
Availability, Processing Integrity, Confidentiality or Privacy in accordance with
AT Section 101 and Trust Services Principles Criteria and Illustrations
TPA Section 100
• SOC 3—Report on Controls at a Service Organization Relevant to Security,
Availability, Processing Integrity, Confidentiality or Privacy in accordance
with AT Section 101 and Trust Services Principles Criteria and Illustrations
TPA Section 100
SOC 1 and SOC 2 reports are intended to provide user entities with a description of the
service organization’s system as well as a detailed understanding of the design of
controls at that service organization and the tests performed by the service auditor to
support his/her conclusions on the operating effectiveness of those controls. Meaning
that the service auditor evaluates that controls have been put in place by the service
organization to address the identified risk and whether those controls are performed
(operating) over the period of time specified; e.g., 1 January 2012 to 31 December 2012.
This gives the user entity the understanding when evaluating the SOC report where
comfort over controls for the services outsourced can be achieved.
SOC 1 addresses service organization system controls that are likely to be relevant to
user entities’ financial statements; SOC 2 addresses the system controls that are relevant
to one or more of the Trust Services principles of Security, Availability, Processing
Integrity, Confidentiality or Privacy, regardless of whether the controls are significant to
user entities’ internal controls over financial reporting. Both SOC 1 and SOC 2 reports
are intended for an exclusive distribution list and are restricted-use reports (e.g., service
and user organization management, internal/external auditors). However, the SOC 2
report can be distributed to any customer who can understand the report’s content with
the service organization’s agreement. The report should not be distributed to unintended
users, such as subvendors, without the service organization’s permission.
A SOC 3 report covers the same principles as a SOC 2 report, but does not include the
detailed understanding of the design of controls and the tests performed by the service
auditor. This report provides the auditor’s opinion on whether the service organization
maintains effective controls over its systems and is typically intended for users who do
not require a more thorough report that includes a detailed description of the design of
controls or tests performed by the service auditor.
SOC 3 reports are intended for general use and can be freely distributed and publicly
promoted via use of the AICPA SOC 3 seal on the service organization’s web site.
The SOC 1 and SOC 2 reports are meant to complement each other and have
several similarities and differences. Figure 1 compares the two reports to
emphasize their purpose, focus, distribution and use.
SOC 1
The following examples of SOC 1 reports clarify the intended use:
• A user entity outsources the maintenance of its accounting software to a service
organization. The management of the user entity would like to know that the
service organization performs its operations in a way that does not result in
misstatement in its financial reporting. Therefore, management requests a
SOC 1 report to ensure that the risk related to the financial reporting process
is adequately addressed by the service organization’s effectively designed and
operated controls.
• Investor entities may purchase mortgage loans or participation interests in such
loans from thrifts, banks or mortgage companies. These loans become assets of
the investor entities, and the sellers may continue to service the loans. Because
the investor entities may have little or no contact with the mortgage servicers
other than receiving monthly payments and reports from the mortgage servicer,
the investor entities may request a SOC 1 report to ensure that risk related to the
financial reporting process are adequately addressed by the seller’s
service organization.
SOC 2
The SOC 2 report can be used for a range of services provided by the service
organization to the user entity, to provide the user entity comfort over the controls
at the service organization relevant to security, availability, processing integrity,
confidentiality or privacy. The following are examples of potential SOC 2 reports
and their intended use:
• With regard to printing service for client trust and/or tax statements, the service
organization is responsible for transferring the required information to the correct
printer and printing the documents. This requires that the service organization
provide the user entity with comfort over the confidentiality, security and privacy
of the information being printed, which may be accomplished by issuance of a
SOC 2 report.
• Application service providers (ASPs) provide packaged software applications
and a technology environment that enables customers to process operational
transactions. An ASP may specialize in providing a particular software package
solution to its users, may provide services similar to traditional mainframe data
center service bureaus, may perform business processes for user entities that they
traditionally had performed themselves, or may provide some combination of
these services. This requires that the service organization provide the user entity
with comfort over the confidentiality, security and privacy of the information
being printed, which may be accomplished by issuance of a SOC 2 report.
A SOC 2 report cannot be extended to include financial controls, but can include
principles and criteria that are related to IT general controls.
• For example, a cloud provider is hosting a financial application. The user entity may
require the system details from the cloud provider and may also need to gain comfort
over the internal controls on financial reporting for the financial system. In this case,
testing performed to prepare a SOC 2 report can be used to prepare a SOC 1 report to
provide assurance over the IT general controls of the financial application. Figure 2
summarizes the main reasons to use a SOC 2 report vs. SOC 1.
To assess the relevance of a SOC 2 report, the user entity must understand the
report coverage and whether:
• The services relevant to the user entity are included.
• There is a clear system description providing sufficient detail to understand the
processes at the service organization.
• The controls are relevant, demonstrate consideration of planned reliance on the
operational and compliance controls, and take into account the relationship to
complementary user entity activities.
• The report covers a period of time or a point in time, and that time period is
relevant to the user entity’s coverage needs.
• There is contiguous coverage between reports, and relevant locations are included
that the user entity considers in scope.
• User entity auditors and others in the user organization planning to rely on the
SOC 2 report may be require to examine the design and effectiveness of user
complementary controls.
Following is a brief overview of AICPA’s AT Section 101 and the Trust Services
principles used by service organizations to create SOC 2 reports for distribution to
user entities.
The standard used for a SOC 2 report is AICPA’s AT Section 101, Attest
Engagements, which applies to engagements in which a practitioner is engaged to
issue an examination of an assertion about subject matter that is the responsibility
of another party.
Trust Services are defined as a set of professional attestation and advisory services
based on principles and criteria that address the risk and opportunities of IT-enabled
systems and privacy programs. Trust Services principles and criteria are issued by
AICPA and the Canadian Institute of Chartered Accountants (CICA). Trust Services
Principles, Criteria, and Illustrations for Security, Availability, Processing Integrity,
Confidentiality, and Privacy provides guidance when providing assurance services
or advisory services (or both) on IT-enabled systems including electronic commerce
(e-commerce) systems. It is particularly relevant when providing services related to
security, availability, processing integrity, confidentiality and privacy.
The Trust Services principles and criteria are organized into four broad areas:
• Policies—The entity has defined and documented its policies relevant to the
particular principle. (The term “policies” as used here refers to written statements
that communicate management’s intent, objectives, requirements, responsibilities
and standards for a particular subject.)
• Communication—The entity has communicated its defined policies to
responsible parties and authorized users of the system.
• Procedures—The entity has placed procedures in operation to achieve its
principles in accordance with its defined policies.
• Monitoring—The entity monitors the system and takes action to maintain
compliance with its defined policies.
The Trust Services introduce a list of criteria against which these four areas are
evaluated to assess whether one or more of the following five principles, which
were developed by AICPA and CICA for use by practitioners in the performance of
trust services engagements, have been achieved:
• 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 (GAPP) issued by
AICPA and CICA.
applicable Trust Service criteria and controls. The service auditor is engaged to
perform either a Type 1 or Type 2 engagement.1 The following describes both
types of reports:
• Type 1 reports on the design of controls and only at a specific point in time.
• Type 2 reports on the design and operating effectiveness of controls covering a
period of time.
Type 1
For a Type 1 report, the service auditor provides an opinion as to whether:
• The service organization’s description “fairly presents” the system that was
designed and implemented.
• The controls were suitably designed to meet the criteria as of a specified date.
Type 1 reports do not address the operating effectiveness of controls, nor do they
provide an opinion over a period of time. This means that the report only provides
information on controls that are in place (designed) at a specific point in time and
not whether the controls are operating on a continuous basis throughout a specified
time period. Due to the limited scope of the service auditor’s opinion in a Type 1
report, a Type 2 report is generally preferable unless the user entity wants only to
understand the nature of the controls at the service organization and whether they
are adequately designed.
Type 2
For a Type 2 report, the service auditor provides an opinion on whether:
• The service organization’s description “fairly presents” the system that was
designed and implemented.
• The controls were suitably designed to meet the criteria.
• The controls operated effectively during the specified period of time.
• The service organization is in compliance with the commitments in its statement
of privacy practices, if the report covers the privacy principle.
A Type 2 report is necessary if the user entity plans to use the report for reliance on
internal control or if the user entity’s management or auditor plans to use the report
for the assessment of internal controls.
The Type 2 report opinion clearly identifies the period of interest. If the period of
time is for less than two months, the user entity will likely need to consider whether
the resulting report is useful, particularly if many of the controls are performed on a
monthly or quarterly basis.
If the controls have changed, or if the service provider discloses deviations, the
user entity should evaluate the impact of those changes and/or deviations and may
choose to perform additional test procedures to gain comfort over the controls in
place at the service organization. Additionally, it is important for the user entity to
receive the report as soon as possible upon publication so the information is most
relevant to the organization.
1
AICPA, SOC 2 Audit Guide, USA, 2012, Section 1.31
© 2012 ISACA. All rights reserved.
20 SOC 2 User Guide
Several components comprise a SOC 2 report and they vary depending on whether
it is a Type 1 or Type 2 report. In most cases, SOC 2 reports do not include all
the principles—only those that the service organization’s management deemed
appropriate for the report. Therefore, it is important for the user entity to evaluate
the report and determine which principles are covered.
This section should clearly describe the systems, services, transactions, reports
and business processes performed at the service organization that are relevant to
the specified TSP principles and criteria that are the subject of the report. This
will enable the user entity to gain an understanding of the structure and processes
supported for the specific services being provided. In addition, the depth of detail
should enable the user entity to clearly identify risk areas where the principles and
the control criteria should be put in place by the service organization. In this way,
the user entity can identify any design gaps within the report.
The description of the system made by the management of the service organization
generally includes the following information:
• Types of services provided by the service organization and the related procedures
by which they are provided
• Types of transactions processed and procedures by which they are performed
• System components including infrastructure, software, people, procedures, data
• System boundaries or aspects relevant to the report
• How reports are prepared for user entities
• How incorrect information is identified and corrected, and how information is
transferred to user entity reports
• How the system captures and addresses significant events and conditions,
including notification to users
• Principles, control criteria and complementary user entity controls
• The risk assessment process, information and communication systems, and
monitoring controls
• The scope of the report (specific principles covered)
• Servicing locations included in the scope of the report and any differences among
the processes that are performed at the various locations
• The description of various oversight and monitoring functions in place that relate
to the services provided
• The description of the various laws and regulations with which the organization
complies, and how the organization monitors compliance
• The identification of any services performed by a subservice provider and the
vendor management controls in place
New user accounts are provisioned by the access management group within the
security team, or by persons or systems delegated to do so on their behalf. New
internal user access requests must be submitted via the Ticketing System to the
access management group and must come from an authorized requestor—either
the new user’s manager or human resources (HR) department. Requests for access
changes or user termination are submitted through the Ticketing System by the
user’s manager. New users are created using access management utilities or they
can be created via a scripted process if there are multiple users to be created.
A terminated user’s group access membership is revoked and the user’s account
is disabled automatically via a script based on termination data fed from the
personnel management system. User accounts are reviewed monthly by the access
management group and any account that has not been used within the last 90 days
is disabled.
• For each principle being reported on, the related criteria in TSP Section 100
(applicable Trust Services criteria) and the related controls designed to meet those
criteria, including, as applicable, the following:
– Complementary user entity controls contemplated in the design of the service
organization’s system
– Controls at the subservice organization when the inclusive method is used to
present a subservice organization
• If the service organization presents the subservice organization using the
carve-out method:
– The nature of the services provided by the subservice organization
– Each of the applicable Trust Services criteria that are intended to be met by
controls at the subservice organization, alone or in combination with controls at
the service organization, and the types of controls expected to be implemented
at carved-out subservice organizations to meet those criteria
• Any applicable Trust Services criteria that are not addressed by a control and the
reasons why
• Other aspects of the service organization’s control environment, risk assessment
process, information and communication systems, and monitoring of controls that
are relevant to the services provided and the applicable Trust Services criteria
It is important to note that a SOC 2 report may not include all of the principles.
The service organization, with input from its users, identifies the principles that the
report will cover.
Note that under (a)(i)(6) in the previous example, it states “for each principle being
reported on,” meaning that not all principles may be included within the SOC 2 report.
Within the report, for each principle, the criteria and the controls in place to
meet each criterion are described. Additionally, the testing details and results are
documented for Type 2 reports, as shown in figure 3. For example:
• The service organization will perform the following to determine if controls are
suitably designed:
– Identify risk that threatens the achievement of the principle, improving
understanding of risk and vulnerabilities.
– Determine that risk will not prevent principles from being achieved if controls
operate as described, which increases the understanding of the controls’ impact
when meeting the principle(s).
The service organization will perform the following to determine whether controls
operated effectively throughout the period specified in the report, which improves
the monitoring of controls:
• The controls were consistently applied as designed for the specified period.
• Manual controls were applied by individuals who have the appropriate
competence and authority.
© 2012 ISACA. All rights reserved.
Section 3. Using the SOC 2 Report 2525
The criteria for each principle stated in section 1 (management’s description of the
service organization’s system) are the criteria for the opinion. The principles have
been defined by the AICPA/CICA and are selected by the service organization
based on their relevance to the needs of user entities. Based on that, the service
auditor will communicate within the report the results of his/her assessment by
expressing an opinion on the following:
• Management’s description of the service organization’s system fairly presents
the service organization’s system that was designed and implemented throughout
the specified period (or, in the case of a Type 1 report, as of a specific date).
The report:
– Presents how the service organization’s system was designed and implemented
– Does not omit or distort information relevant to the service organization’s system
• The controls related to the criteria stated in management’s description of the service
organization’s system were suitably designed throughout the specified period.
• The controls were consistently applied as designed and operated effectively
throughout the specified period. If applicable, complementary user entity controls
were consistently applied as designed and operated effectively throughout the
specified period.
• If applicable, compliance with the commitments in the statement of privacy
practices throughout the specified time period (when the report includes the
privacy principle)
In our opinion, in all material respects, based on the Description Criteria identified
in client’s assertion and the applicable Trust Services criteria:
a. The description fairly presents the system that was designed and implemented
throughout the period 1 January 2011 to 31 December 2011.
b. The controls stated in the description were suitably designed to provide
reasonable assurance that the applicable Trust Services criteria would be met
if the controls operated effectively throughout the period 1 January 2011 to
31 December 2011, and user entities applied the complementary user entity
controls contemplated in the design of the client’s controls throughout the
period 1 January 2011 to 31 December 2011.
c. The controls tested, together with the complementary user entity controls
referred to in the scope paragraph of this report, if operating effectively, were
those necessary to provide reasonable assurance that the applicable Trust
Services criteria were met, operated effectively throughout the period 1 January
2011 to 31 December 2011.
COBIT 5
The COBIT 5 process reference model is shown in figure 4 and subdivides the
IT-related practices and activities of the enterprise into two main areas—governance
and management—with management further divided into domains of processes:
• Governance ensures that enterprise objectives are achieved by evaluating
stakeholder needs, conditions and options; setting direction through prioritization
and decision making; and monitoring performance, compliance and progress
against agreed direction and objectives (Evaluate, Direct and Monitor [EDM]).
• Management plans, builds, runs and monitors activities in alignment with the
direction set by the governance body to achieve the enterprise objectives (plans,
builds, runs, monitors [PBRM]).
2
ISACA, COBIT® 5, USA, 2012, www.isaca.org/cobit
© 2012 ISACA. All rights reserved.
Section 3. Using the SOC 2 Report 2727
EDM01 Ensure
Governance EDM02 Ensure EDM03 Ensure EDM04 Ensure EDM05 Ensure
Framework Setting Benefits Delivery Risk Optimisation Resource Stakeholder
and Maintenance Optimisation Transparency
MEA01 Monitor,
Evaluate and Assess
APO09 Manage Performance and
APO08 Manage APO10 Manage APO11 Manage APO12 Manage APO13 Manage Conformance
Service Risk Security
Relationships Agreements Suppliers Quality
In summary, COBIT 5 allows managers to bridge the gap with respect to control
requirements, technical issues and business risk, and communicate that level of
control to stakeholders. It enables the development of clear policies and good
practice for IT control throughout enterprises.
To assess whether a SOC 2 report will meet a user entity’s particular needs, the
user entity needs to identify the purpose for obtaining the report and view the
report from a holistic point of view. For instance, a report requested by corporate
for performance measurement for vendor management purposes has a different
purpose than a report requested by the internal audit department for operational
risk purposes. A report used for vendor management purposes likely focuses more
on the business processes in place at the vendor site and how those processes are
effectively managed by controls designed to meet the criteria applicable to the
principles relevant to the user entity, specifically, evaluating the narrative and
controls. On the other hand, one focus of an internal audit reviewer may be on the
adherence of the controls to leverage for reporting purposes, specifically focusing
on operational risk to determine how management is monitoring and/or managing
the risk.
A SOC 2 report allows a user entity to understand the significant risk related to the
business and gives the user entity the opportunity to see how the risk is assessed
and monitored by the management of the service organization.
The assessment of each key risk to the user entity should be identified by all
affected service users and should include the steps in figure 5.
5. Identify any
control gaps
3. Select the 4. Map the where identified
2. Evaluate the applicable Trust control criteria risk is not
1. Identify service process Services criteria to the principle(s) addressed. If
products/services and identify required to to ensure that applicable, map
provided. the users meet the user all elements of internal user
entity’s risk. entity needs. the principle organizational
are met. controls to
address gaps
identified.
The user entity must gain an understanding of the key processes needed at the service
organization to support the services it wants to outsource. This includes reading
the SOC 2 report to understand the processes and procedures by which services are
provided, including how transactions are initiated, authorized, recorded, processed,
corrected and reported. The user entity needs to verify that the report includes the
technology platforms, applications, systems, IT and/or business processes, locations
or services that support the user entity’s specific systems or outsourced operations.
A well-written SOC 2 report clearly identifies the scope of what is included and not
included within the report. If the report does not cover the areas or services provided
that are relevant to the user entity, the usefulness of the report may be limited. In this
situation, the user entity should consider the risk related to the areas not addressed
in the scope and, depending on the risk, either identify and test the controls it uses
to manage the service organization’s effectiveness or identify and test the relevant
controls performed by the service organization.
2. Evaluate the Service Process and Identify the User Entity’s Risk
An end-to-end understanding of the processes at the service organization and user
entity will enable the user entity to identify key risk areas and to determine whether
the necessary controls have been implemented to mitigate those risk areas. The
user entity should provide the specifications needed for controls at the service
organization to ensure that (1) the risk is effectively addressed and (2) such controls
are included in the service auditor’s report.
For example, several areas of risk for the user entity exist within the user access
management process. These may include terminated employees remaining active in
the system, new employees gaining too much access in the system, or changes of
job function within the organization (e.g., from purchasing to payables) that result
in segregation of duties conflicts. Additionally, companies may be concerned with
compliance risk as it relates to privacy and the protection of sensitive information.
Each of these areas creates a different risk, and the user entity should expect that
the service organization has principles with control criteria in place to mitigate the
risk areas identified.
3. S
elect the Applicable Trust Services Principles and Criteria Required to
Meet the User Entity Needs
The user entity should consider which Trust Services principles and criteria are
most relevant to the services being provided by the service organization. After
defining these requirements, the user entity must validate that the identified Trust
Services principles and criteria are included accordingly in the SOC 2 report.
4. M
ap User Entity Control Requirements to the Applicable Trust Services
Criteria Associated with the Principles to Be Included in the SOC 2
Report
In the SOC 2 report, each control addressing specific criteria is listed under the
principle it supports. Criteria may have one or more controls to ensure that all
parts of the principle are achieved. When mapping the controls to the criteria, it is
a good technique to break down the list of requirements into sections named after
the applicable principles to determine what controls should be implemented at the
service organization to satisfy the necessary principles.
Regardless whether gaps exist, the user entity should evaluate its own internal
controls (especially those considered as user entity complementary controls) to
determine if all identified risk are mitigated. These complementary user entity
controls are a critical component of the report and illustrate to the intended user of
the report that the user entity has certain roles, responsibilities and obligations in
helping the service organization achieve the principles stated and, therefore, it is
common to list these controls within the description in the SOC 2 report. Examples
of complementary user entity controls include:
• User entity controls related to system access and acceptable use for all systems
that interface with the service organization’s systems (directly or indirectly)
• User entity timely deactivation or removal of user accounts for user entity
terminated employees previously involved in functions or activities involving
service organization’s systems
• User entity timely deactivation or removal of user accounts for user entity
terminated employees previously involved in functions or activities involving
systems interfacing with service organization’s systems
• User entity controls implemented to protect data transmitted to the service
organization (appropriate methods must be implemented to ensure security,
availability, integrity, confidentiality or privacy accordingly)
Please note that the term complementary “user entity controls” may also be
expressed as “user organization controls,” “complementary customer controls” or
any other similar name or phrase that refers to controls implemented and managed
by the user entity.
Vendor management enables the user entity to build a relationship with the service
organization that can provide value to and strengthen both businesses. The value
is created when the user entity works continually with the service organization to
discuss changes and come to mutually beneficial agreements.
The user entity’s sharing of information and priorities with the service organization
is an important success factor for vendor management. This means that the user
entity provides the necessary information to the service organization at the right
time so the service organization can better meet the user entity’s needs. This is
important for several reasons, including scoping of the SOC 2 report so that the
service organization knows what reliance is being placed on the report by the user
entity and service agreements, and contracts can be negotiated appropriately.
In many cases, a service level agreement (SLA) that outlines the services to be
provided is signed between the user entity and the service organization. When
the services in question are complex in nature, measuring their quality (and thus
the fulfillment of the service organization’s promise) becomes a challenge. In
these cases, a SOC 2 report may help both parties evaluate how compliance and
operational risk is controlled by the service organization.
The user entity should identify what processes are outsourced and what operational
risk arises from the performance of these processes. As a next step, the management
of the user entity should outline the specifications needed of the third-party assurance
reports to ensure that the risk is effectively addressed by relevant controls.
Working with the appropriate representatives, the user entity can identify the
products that are being outsourced along with the associated financial or operational
risk. (Section 4, Evaluating the User Entity Needs, provides details on how to
perform this assessment.)
The user entity may need to ask some of the following questions to determine the
type of report required to meet its needs:
• Will the scope of the system(s) covered be appropriate to the user entity needs?
• Will the principles being reported on be relevant to user entity needs?
• Will significant activities performed by subservice organizations be included or
carved out?
• If significant activities will be carved out, are there other sources of information
and assurance about such activities (e.g., another service-auditor report on the
carved-out activities)?
• Is it likely that the opinion of the service auditor will include significant
exceptions and, if so, how might these affect risk at the user entity?
• Who is going to use this report and for what purpose?
• Does the audience include auditors or others who need details about controls and
test results, or will a general use report fulfill audience needs?
• What coverage period is required: point in time or over a period of time?
Some user entities require very detailed and elaborate control descriptions to
address high risk while other user entities may be satisfied with less. To determine
the appropriate level of detail can be challenging for service organizations so it is
important for the user entity to establish a relationship and communicate its needs
and expectations when receiving a SOC 2 report. User entities should be cautious
with service organizations that do not provide a thorough SOC 2 report and work to
establish a mutually beneficial relationship where each organization’s requirements
can be discussed.
Some service organizations may not understand how SOC 2 reports can help their
business so they may be reluctant to invest in obtaining one. A primary advantage
to service organizations is the competitive advantage they obtain by applying best
practice advice when implementing and reporting on their controls. A service
organization that is the only company within its industry that does not provide a
SOC 2 report to its users is likely to find itself at a significant competitive disadvantage.
Data privacy, security and confidentiality are increasing concerns for enterprises
that collect and process certain types of data as regulators tighten the rules on data
governance. User entities that are concerned with security, confidentiality and
privacy are more likely to partner with service organizations that are audited by
an independent auditor and can provide a SOC 2 report on the principles outlined
in this guide. In addition, user entities that are concerned with availability and
processing integrity are more inclined to partner with service organizations that can
provide a SOC 2 report on their operational controls. Most companies are utilizing
IT systems to perform their critical operations; they need to be sure that their service
organizations have procedures and controls in place to provide reliable services.
The user entity should note whether the SOC 2 report is a Type 1 or a Type 2 report.
(See section 3 for an explanation of the differences between the two types of reports.)
Because the scope of the service auditor’s opinion is limited in a Type 1 report, a
Type 2 report is generally preferable, unless the user entity wants to understand only
the nature of the controls at the service organization and whether they are adequately
designed. A Type 2 report is necessary if the user entity’s auditor plans to use the
report for reliance on internal control or the report is to be used by the user entity’s
management or auditor for the assessment of internal controls.
Description/Narrative Section
Why is this important to the user entity? How can it be used (e.g., gaining an
understanding)? How can the user entity evaluate the depth of detail?
The user entity should determine whether the service organization has included
sufficient detail in the description section of the report provided. The description
should clearly detail the systems, services, transactions, reports and business
processes performed at the service organization to enable the user entity to understand
the structure and processes supported. The depth of detail should enable the user
entity to identify risk areas where controls that address the criteria associated with
each principle have been in place by the service organization. This will make it
possible for the user entity to identify any design gaps within the report.
Monitoring
XYZ management team, with support from its internal audit department, monitors
the effectiveness of the company’s controls over security through the performance
of semiannual audits of such controls and ongoing review and testing procedures
performed by management. Identified security deficiencies are generally corrected
within 24 hours.
Example 2 Description That Lacks Sufficient Detail Regarding Selected
Monitoring in Place at XYZ Service Organization
Monitoring
XYZ management team, with support from its internal audit department, monitors
the company’s system of internal control. Deficiencies in the company’s system of
internal control are reported to management.
Management’s Assertion
Why is this important to the user entity and how should it interpret this?
The service organization is required to provide a written assertion that states the
scope of the report. The assertion also affirms management’s responsibility for the
content of the report, including the description of IT systems/business processes,
principle(s) and control criteria. Specifically for the SOC 2 report, this includes
the assertion by management that security, availability, processing integrity,
confidentially and privacy controls are fairly presented and suitably designed (Type
1 and 2) and are operating effectively (Type 2 only) to achieve a specific principle.
For privacy, specifically in a Type 2 report, the written assertion will include a
statement regarding compliance with the commitments in the Statement of Privacy
Practices throughout the period. This assertion is available for auditors and users of
the organization’s services.
The user entity should interpret management’s assertion as an indication from the
service organization’s management that it formally takes responsibility for the
SOC 2 report and its content.
Through the assertion, management communicates its responsibility for the fair
presentation of the description of the organization’s controls and for establishing
and maintaining appropriate controls related to the processing of transactions for the
user entity. It also conveys management’s belief that controls are suitably designed
to achieve the principle(s) specified in the description of system controls. This
demonstrates management’s ownership of the services provided and the underlying
principle(s) and controls in place to achieve those principle(s).
Principles
The selection of principles being reported on is strictly up to the service organization.
Additionally, all criteria, unless they are deemed not relevant for the selected
principles, are expected to be included in the report. The main issue that should be
considered by the user entity is the following question: Are the principles selected
(covered by the report) appropriate for the needs of the user entity?
For example, a report on the processing integrity principle where system processing
is complete, accurate, timely and authorized is of little use to a user entity seeking
assurance about privacy. The user entity would expect that a service organization
requiring compliance with the commitments in its statement of privacy principles
would include the Generally Accepted Privacy Principles and Criteria. Some
privacy components include policies addressing the use, retention and disposal of
sensitive information.
Design of Controls
A SOC 2 report identifies the control criteria designed to achieve the principles,
including potential controls that the service organization intends for the user entity
to implement (referred to as “complementary user entity controls”). While the
specified controls should address the risk that threatens the achievement of the
principle for most user entities, individual user entity needs may vary. As a result,
the user entity should consider the risk that would threaten the achievement of the
principle from its own perspective and consider whether the controls identified
adequately address the risk. If the user entity believes that any risk areas are not
addressed by the service organization’s controls, the user entity should discuss
those risk areas with the service organization.
Additionally, the report may include complementary user entity controls. These
controls are a critical component of the report and illustrate to the intended user of
the report that the user entity has certain roles, responsibilities and obligations in
helping the service organization achieve the principles stated and, therefore, it is
common to list these within the description for a Type 1 and Type 2 report.
Subservice Organizations
What is a subservice organization and how can it have an impact on the user entity?
outsourced services. If the service organization uses the carve-out method to present
a subservice organization, the description of the service organization’s system
identifies the following:
• The nature of the services provided by the subservice organization
• If the description addresses the privacy principle, any aspects of the personal
information life cycle for which responsibility has been delegated to the
subservice organization, if applicable
• Each of the applicable Trust Services criteria that are intended to be met by
controls at the subservice organization alone or in combination with controls at
the service organization
• The types of controls expected to be implemented at carved-out subservice
organizations that are necessary to meet the applicable Trust Services criteria,
either alone or in combination with controls at the service organization
• If the description addresses the privacy principle, the types of activities that
the subservice organization would need to perform to comply with the service
organization’s privacy commitments
The description of the service organization’s system and the service auditor’s
engagement exclude all other aspects of the subservice organization’s infrastructure,
software, people, procedures and data relevant to the services provided.3
When the inclusive method is used, the following is performed to produce the report:
• Obtaining acknowledgement and acceptance of responsibility for the matters from
management of the subservice organization
• Obtaining an understanding of the portion of the system provided by the
subservice organization
• Obtaining and evaluating evidence about the fairness of the presentation of the
description for the portions of the system provided by the subservice organization
• Obtaining evidence about whether the described controls have been implemented
at the subservice organization
• Evaluating the suitability of the design of controls at the subservice organization
• For a Type 2 report, obtaining evidence of the operating effectiveness of controls
at the subservice organization
• Obtaining evidence of the subservice organization’s compliance with the privacy
commitments it has made to the service organization, if applicable
• Obtaining a written assertion that is relevant to the services provided by the
subservice organization
• Obtaining written representations about the matters that are relevant to the
services provided by the subservice organization
3
AICPA, SOC 2 Audit Guide, USA, 2012, Section 3.29
© 2012 ISACA. All rights reserved.
Section 6. Interpreting the Report 4141
Scope
We have examined the attached description titled “XYZ Service Organization’s
Description of the Adaptable Cloud Computing System Throughout the Period
1 January 2011 to 31 December 2011” (the description) and the suitability of the
design and operating effectiveness of controls to meet the criteria for the privacy
principle set forth in TSP Section 100, Trust Services Principles, Criteria, and
Illustrations for Security, Availability, Processing Integrity, Confidentiality, and
Privacy (AICPA, Technical Practice Aids) (applicable Trust Services criteria),
throughout the period 1 January 2011 to 31 December 2011.
Scope
We have examined the attached description titled “XYZ Service Organization’s
and ABC subservice organization’s Description of the Adaptable Cloud
Computing System Throughout the Period 1 January 2011 to 31 December 2011”
(the description) and the suitability of the design and operating effectiveness of
controls to meet the criteria for the security, availability, processing integrity, and
confidentiality principles set forth in TSP Section 100, Trust Services Principles,
Criteria, and Illustrations for Security, Availability, Processing Integrity,
Confidentiality, and Privacy (AICPA, Technical Practice Aids) (applicable Trust
Services criteria), throughout the period 1 January 2011 to 31 December 2011.
ABC subservice organization is an independent service organization that
provides certain computer processing services to XYZ service organization.
XYZ service organization’s description includes a description of those elements
of its system provided by ABC subservice organization, the controls of which
help meet certain applicable Trust Services criteria.
4
AICPA, SOC 2 Audit Guide, Section 4.40
© 2012 ISACA. All rights reserved.
42 SOC 2 User Guide
Inherent limitations
Because of their nature and inherent limitations, controls at a service organization
or subservice organization may not always operate effectively to meet the
applicable Trust Services criteria. Also, the projection to the future of any
evaluation of the fairness of the presentation of the description or conclusions
about the suitability of the design or operating effectiveness of the controls to
meet the applicable Trust Services criteria is subject to the risk that the system
may change or that controls at a service organization or subservice organization
may become inadequate or fail.
Opinion
In our opinion, in all material respects, based on the criteria identified in XYZ
service organization’s and ABC subservice organization’s assertions:
a. The description fairly presents XYZ service organization’s [type or name
of] system and the elements of the system provided by ABC subservice
organization that were designed and implemented throughout the period [date]
to [date].
b. The controls of XYZ service organization and ABC subservice organization
stated in the description were suitably designed to provide reasonable assurance
that the applicable Trust Services criteria would be met if the controls operated
effectively throughout the period [date] to [date].
c. The controls of XYZ service organization and ABC subservice organization
that were tested, which were those necessary to provide reasonable assurance
that the applicable Trust Services criteria were met, operated effectively
throughout the period from [date] to [date].
Restricted use
This report and the description of tests of controls and the results thereof are
intended solely for the information and use of XYZ service organization and
ABC subservice organization; user entities of XYZ service organization’s [type
or name of] system; and those prospective user entities, independent auditors,
and practitioners providing services to such user entities and regulators who have
sufficient knowledge and understanding of:
• The nature of the service provided by the service organization
• How the service organization’s system interacts with user entities, subservice
organizations and other parties
• Internal control and its limitations
• Complementary user entity controls and how they interact with related controls
at the service organization and subservice organization to meet the applicable
Trust Services criteria
• The applicable Trust Services criteria
• The risks that may threaten the achievement of the applicable Trust Services
criteria and how controls address that risk
This report is not intended to be, and should not be, used by anyone other than
these specified parties.
What does this mean and how does it affect the user entity?
The service auditor must disclose when the internal audit function’s work has been
used to form the service auditor’s opinion. The documentation of the use of internal
audit’s test steps and results can be inserted in the test of controls section of the
report. The service auditor should not reference the work of internal audit in the
opinion section because the internal audit function is not independent of the service
organization. The service auditor has sole responsibility for the opinion expressed
in the service auditor’s report, and accordingly, that responsibility is not reduced by
the service auditor’s use of the work of the internal audit function.
The following example shows how the service auditor would document the use
of internal audit’s work within the SOC 2 report. This allows the user entity
the ability to easily identify the work that is being performed by the company’s
internal audit team.
This reporting provides transparency to the user entity and allows the user
entity to identify which controls are tested by the service organization’s internal
audit department.
Nature of Tests
The higher and more pervasive the risk relating to a given Trust Services criterion,
the greater the need for assurance on relevant preventive and detective controls
to meet the relevant Trust Services criteria and the more likely the control is
assessed with greater significance. Several factors, including the existence of
other complementary, compensating or redundant controls may be considered to
determine the significant level of a control. This means that the multiple controls
that are necessary to meet the Trust Services criteria will be tested for design (Type
1 and Type 2) and operating effectiveness (Type 2 only).
There are several ways to test a control: inquiry, examination, observation and
re-performance. The nature of the test to be performed depends on the level of
comfort required and the history of the control’s performance. Therefore, the
extent and the nature of the tests performed should be evaluated to ensure that they
provide the right level of assurance that the controls are designed and operating
effectively to meet the principle(s).
The nature, timing and extent of the procedures to evaluate the design or operating
effectiveness should be included in the report. The following should be considered
when evaluating the report:
• Whether the control as designed meets the criteria
• Timeliness of the control procedures
• Rigor and precision at which the control is designed to operate
• The period covered in the SOC 2 report—This should be the same period that the
user entity is relying on for the test results.
• Timing of the of the tests performed by the service auditor
• Test of compliance with privacy commitments
• Evaluation of the use of internal audit’s work
The service auditor designs tests of controls to meet the needs of the typical user
entity; however, professional opinions may vary on the sufficiency of tests of
controls. The user entity should also focus on the key controls that meet the Trust
Services criteria and consider whether the tests performed by the service auditor
are sufficient to evaluate the effectiveness of those controls. Certain control testing
techniques inherently provide more assurance. For example, re-performance of a
control generally provides more assurance than inquiry and observation provide.
Independent tests of controls by the service auditor provide more independence and
objectivity than tests performed by the internal audit function, on which the service
auditor may choose to rely. Any questions on the sufficiency of testing should be
addressed with the service organization.
Deviations/Observations
What are deviations and how does the user entity evaluate them (e.g., context
behind them)?
SOC 2 reports include results of tests so user entitys can perform separate
evaluations of the impact of control deviations on the user entity’s environment.
As noted previously, this is done because it is understood that the needs of user
entities differ. In evaluating the reported deviations, user entities should consider
the importance of the control meeting the criteria. To assist the user entity in
this evaluation, the service organization or the service auditor may disclose
compensating controls or mitigating factors that would reduce the impact of the
deviations. If compensating or mitigating controls are provided, the user entity
should consider the strength of those controls and whether the compensating or
mitigating controls were tested in the report.
The following example illustrates the documentation of tests of controls for which
deviations have been identified. It is assumed that, in each situation, other relevant
controls and tests of controls would also be described:
• Criteria—Procedures exist to restrict physical access to the defined system,
including, but not limited to, facilities; backup media; and other system
components, such as firewalls, routers and servers.
• Example service organization’s controls—Security personnel deactivate
physical security access cards of terminated employees on a daily basis using a list
generated by the human resources (HR) system.
•S ervice auditor’s tests of controls—The auditor selected a sample of terminated
employees from a list generated by the HR system and compared the termination
date with the access card deactivation date for each employee.
• Results of tests of controls—For one terminated employee in an initial sample of
25, the employee’s physical access security card was not deactivated until 90 days
after the employee’s last day of work. In an additional sample of 15 terminated
employees, no additional deviations were noted.
• Management’s response—The terminated employee’s name was not listed
on the report from the HR system until 90 days after termination. Subsequent
investigation determined that the report used for removing physical access was
generated based on the last payroll date of the employee, rather than the last date
employed. This employee was one of 15 employees who were a part of a reduction
in force and received the severance benefit. These employees each continued on
the payroll system for 90 days after termination. The physical access cards of all
employees receiving severance have been deactivated, and the report from the HR
system has been changed to generate the list based on the last date of employment.
The user entity should evaluate the severity of all identified control deficiencies
applicable to services being provided and consider potential implications with
regard to the effectiveness of other controls (e.g., the company’s IT general controls
and other components when the deviation relates to control activities).
5
AICPA
© 2012 ISACA. All rights reserved.
48 SOC 2 User Guide
The following questions should be considered when evaluating the impact on the
user entity (this list is not intended to be exhaustive):
• Are there any compensating controls at either the user entity or service organization?
• Were the criteria met?
• What were the nature, timing and extent of testing?
• Was the deviation remediated during the period under review?
• Is/was management taking action to address the deviation?
• How many deviations were noted and what was the nature?
• Do the nature and frequency of the deviations indicate other potential risk, such as
a lax control environment or ineffective monitoring?
6
AICPA
© 2012 ISACA. All rights reserved.
Section 6. Interpreting the Report 4949
This may mean that the user entity or its auditor should not place reliance on the
controls supporting a particular area at the service organization. Depending on the
risk assessment performed, the user entity auditor may consider performing his/her
own testing at the service organization, if the service organization failed to
correct the deviations noted within the report and the qualified opinion remained
unchanged; or the user entity may request a memo from the service organization
detailing the corrective action taken.
7
AICPA
© 2012 ISACA. All rights reserved.
50 SOC 2 User Guide
In our opinion, in all material respects, based on the description criteria identified
in [client]’s assertion and the applicable Trust Services criteria:
• The description fairly presents the system that was designed and implemented
throughout the period from [date] to [date].
• The controls stated in the description were suitably designed to provide
reasonable assurance that the applicable Trust Services criteria would be met
if the controls operated effectively throughout the period [date] to [date], and
user entities applied the complementary user entity controls contemplated in the
design of [client]’s controls throughout the period from [date] to [date].
• The controls tested, which together with the complementary user entity controls
referred to in the scope paragraph of this report, if operating effectively, were
those necessary to provide reasonable assurance that the applicable Trust Services
criteria were met, operated effectively throughout the period [date] to [date].
• If the report addresses the privacy principle, the service organization complied
with the commitments in its Statement of Privicy Practices throughout the period.
If the service organization has a qualified opinion, the following questions should
be considered to evaluate the impact on the user entity (this list is not intended to
be exhaustive):
• Are there any compensating controls at either the user entity or service
organization?
• What were the nature, timing and extent of testing?
• Was the deviation remediated during the period under review? If so, how long
was the deviation in place?
• Is/was management taking action to address the deviation?
• How many deviations were noted and what was the nature?
• What period is affected?
Subsequent Events
Subsequent events are those events that occur after the “period end date” and
prior to the issuance of the final report. For example, if the “period end date” is
31 December 2011 and the report issuance date is 1 March 2012, an event that
occurred on 29 February 2012 that affected the report would be considered a
subsequent event. Disclosure of that event is required.
The service organization may wish to disclose such events in a separate section of
the description of the service organization’s system; the disclosure may be titled,
for example, “Other Information Provided by the Service Organization.” In a format
similar to the description, this section will describe what has occurred since the
“period end date.”
There may also be situations in which the event discovered subsequent to the period
covered by management’s description of the service organization’s system up to the
date of the service auditor’s report would likely have no effect on management’s
assertion because the underlying situation did not occur or exist until after the
period covered by management’s description of the service organization’s system;
however, the matter may be sufficiently important for disclosure by management in
its description and, potentially, the service auditor in an emphasis paragraph of the
service auditor’s report.
Glossary
Applicable The criteria in TSP Section 100, Trust Services Principles,
Trust Services Criteria, and Illustrations for Security, Availability,
criteria Processing Integrity, Confidentiality, and Privacy, that are
applicable to the principle(s) being reported
Assurance An objective examination of evidence for the purpose of
providing the reader or user of the report with a level of
comfort that security goals have been adequately met through
the organization’s risk management and governance processes
Boundaries of The specific aspects of a service organization’s infrastructure,
the system software, people, procedures and data necessary to provide
its services. When the systems for multiple services share
aspects, infrastructure, software, people, procedures and data,
the systems will overlap, but the boundaries of each service’s
system will differ. In a SOC 2 engagement that addresses the
privacy principle, the system boundaries cover, at a minimum,
all of the system components as they relate to the personal
information life cycle within well-defined processes and
informal ad hoc procedures.
Business A plan used by an enterprise to respond to disruption of
continuity plan critical business processes. It depends on the contingency plan
(BCP) for restoration of critical systems.
Carve-out A method of addressing the services provided by a subservice
method organization, whereby management’s description of the
service organization’s system identifies the nature of the
services performed by the subservice organization and
excludes from the description (and scope of the service
auditor’s engagement) the subservice organization’s controls
to meet the applicable Trust Services criteria. The description
of the service organization’s system and the scope of the
engagement include controls at the service organization
that monitor the effectiveness of controls at the subservice
organization, which may include the service organization’s
review of a service auditor’s report on controls at the
subservice organization.