This document provides an overview of Service Organization Control (SOC) reporting, including definitions, background, and types of reports. SOC 1 reports address controls relevant to user entities' internal control over financial reporting, following the new SSAE 16 standards. SOC 2 reports examine controls related to security, availability, processing integrity, confidentiality or privacy using the Trust Services Principles. SOC 3 reports also use Trust Services Principles criteria but do not include testing details. The document outlines key differences between SAS 70 and SSAE 16 reporting and transitions to the new standards.

1. Service Organization Control Reports
An Overview

2. Agenda
• Service Organization Control Reporting
– Definitions
– Background
– Report Types and Guidance
• Transitioning to SSAE 16/SOC 1
– Similarities to SAS 70
– Key Differences from SAS 70
• SOC 2 and 3 Reporting
• Reporting Options
• Summary
• Questions

3. Service Organization Control
Reporting

4. What are Service Organizations?
• Service Organization – provider of services that may
impact a user’s financial reporting or pose a
business risk
 Services such as:
 Cloud computing
 Managed security
 Financial services customer accounting
 Customer support
 Sales force automation
 Health care claims management and processing
 Enterprise IT outsourcing

5. Definition: Service Auditor
• Service auditor – a CPA who examines and
reports on controls at a service organization

6. Who are Users?
• Users – typically considered clients of
service organization
 May need assurance regarding controls over
security, availability, processing integrity,
confidentiality or privacy
• User Auditor – a CPA who performs a audit
on the users financial statements
 Needs assurance regarding the controls in place at
the service organization that impact user financial
statements

7. Background
• Why change?
• SAS 70 has become increasingly misused
• Never intended to offer assurance on compliance or
operations
• No such thing as a SAS 70 “certification”
• Convergence with International Standards
• AICPA is seeking to address needs of the marketplace

8. Background
• Several important changes
– December 2009
• International Auditing and Assurance Standards Board
issued new International Standards on Assurance
Engagements (ISAE) 3402, Assurance Reports on Controls
of Service Organizations
– April 2010
• AICPA issued SSAE 16 Reporting on Controls of Service
Organizations (SOC 1)
• First significant modification on topic since SAS 70 issued in
1992
• Effective for reporting periods on or after June 15, 2011

9. Background
• Several important changes
– May 2011
• AICPA issued a new guide for attestation engagements (AT
101) using Trust Services Principles (SOC 2)
– June 2011
• Anticipated release of SSAE 16(SOC 1) reporting guide

10. Service Organization Control Reports
SOC 1 SOC 2 SOC 3
Purpose Report on controls Report on controls Report on controls
relevant to user related to related to
entities ICFR 1 compliance and compliance and
operations operations
Use of Report Restricted 2 Restricted 3 General
Report Detail Includes Testing Includes Testing No Testing Detail
Detail Detail
AICPA SSAE 16 AT 101 and AT 101 and
Interpretive and AICPA Guide AICPA Trust AICPA Trust
Guidance (forthcoming in Services Services
June) Principles/AICPA Principles
Guide (SOC 2 just
issued)
1InternalControl Over Financial Reporting
2Service Organization Management, Users, Users Auditor
3Service Organization Management, Users, Knowledgeable Parties

11. Transitioning to SSAE 16
SOC 1 Reporting

12. Similarities
• SSAE 16 continues the focus on
controls likely to be relevant to their user entities’
internal control over financial reporting (ICFR)
• SSAE 16 will have SOC 1 reports similar in
scope to the current SAS 70 reports
– Type 1
– Type 2
• The format of the reports will not be significantly
different

13. Similarities
• Narrative description of controls:
Basis for new description of the system
• Treatment of subservice organizations
 Included (inclusive method)
 Excluded (carve-out method)
• Intended users of the report
 Service organization’s management
 Users
 User auditors

14. Key Differences:
SAS vs. SSAE
• Attest standard (Assertion), not an audit
standard (GAAP)
• Consistency with international standards and
existing attestation standards
• Increased focus on service organizations with
services relevant to a user organizations internal
control over financial reporting (ICFR)
• Some SAS 70 reports will move to SOC 2 or
SOC 3 reports

15. Key Differences:
Management Assertion
A Management Assertion will be included in or
attached to the SSAE 16 report
• States*:
 System fairly represented
 System suitably designed and implemented
 The related controls activities were suitably designed
to achieve the stated control objectives
 That the control activities are operating effectively
(Type 2 only)
*The auditor opinion attests to these statements. Type 1 specified
date/Type 2 throughout the period

16. Key Differences:
Management Assertion
• The report will reference that management is
responsible for:
 Preparing the system description
 Providing the stated services
 Specifying the control objectives
 Identifying the risks
 Selecting and stating the criteria for their assertion
(e.g. monitoring activities)
 Designing, implementing and documenting controls
that are suitably designed and operating effectively

17. Key Differences:
Management Assertion
• Auditor’s Opinion – remains in the role of
providing assurance regarding management’s
assertions (same but more emphasis)
• Auditor is not the entity responsible for the
communication (same but more emphasis)
• Subservice organizations must provide a similar
assertion when the inclusive method is used

18. Key Differences:
System Description
• Currently a narrative description of controls
• SSAE 16 requires a description of the system
 Infrastructure
 Software
 People
 Procedures
 Data

19. Key Differences:
System Description
• Components common to existing Descriptions
of Controls
 Services covered
 Period covered
 Control objectives and related control activities
 Complementary user controls
• For inclusive subservice organizations, add
 Related control objectives
 Related control activities

20. Key Differences:
System Description
• Additional elements for the Description of the
System
 Classes of transactions and details on related
procedures and accounting records
 The capturing and addressing of significant events
other than transactions

21. Key Differences:
System Description
• Additional elements for the Description of the
System
 Report preparation processes
 Other relevant aspects of the organization’s:
Control environment
Risk assessment process
Information and communication systems
Control activities and monitoring controls

22. Key Differences:
Risks Assessment
• Management should:
 Identify the risks that threaten the achievement of the
stated services
 Identify the risks that threaten the achievement of the
stated control objectives
 Evaluate whether the identified controls sufficiently
address the risks to achieving the control objectives
• Risks to Services Control Objectives
• Risks to Control Objectives Control Activities

23. Design of Controls: Based on Risk
Risk Assessment Supporting Control Design
Services Provided
Assessment of risks to services leads to:
Control Objectives
Assessment of risk to control objective leads to:
Control Activities

24. Other Key Differences
• Service auditor use of internal audit
– Reliance on / must disclose
– Direct use / no disclosure
• Certain aspects of opinion apply to entire period rather
than a point in time
 Narrative
 Control design
 Control implementation

25. Trust Services Principles
SOC 2 and 3 Reporting

26. SOC 2 Reporting
• Governed by AT 101 – Attestation service
• Criteria for evaluation is Trust Services Principles (TSP)
• SSAE 16 guidance to be used
• Intended for users seeking assurance around one or
more of control areas not relevant to ICFR of User
• TSP Criteria
• Security
• Availability
• Processing Integrity of the system
• Confidentiality of information processed
• Privacy of information processed

27. SOC 2 Reporting
• Limited Use report
– Users generally user entity management not user auditors
– Service Organization
– Knowledgeable parties
• Helps user entity management
– Obtain information about service organization controls
– Assess and address risks
– Carry out its responsibility for monitoring

28. SOC 2 Reporting
• Two Types of SOC 2 Reports
– Type 1
• Reports on fairness of presentation of management’s description of
the service organization’s system
• The suitability of design of controls
• Unlikely to provide sufficient information to assess risks
• Provides an understanding system and controls
• May be useful when:
– Organization is new
– Recently made significant changes
– Other reason insufficient time or history to perform Type 2

29. SOC 2 Reporting
– Type 2
• Same as Type 1 plus
• Service auditor opinion on operating effectiveness
• A detailed description of service auditor’s tests of controls and
results
• Will be most used of SOC 2
• Both Types 1 and 2 include management’s assertion
– Included
– Attached

30. SOC 2 Reporting
• Report Components
– Management’s written assertion about whether in all material
respects and based on suitable criteria, the following:
• Management’s description of the system fairly presents the system
that was designed and implemented
• Controls were suitably designed to meet criteria
• Type 2 controls operated effectively
• If addressing the privacy principle, management complied with the
commitments in its statement of privacy
– All components are for a period of time
– Management must have a reasonable basis for assertion

31. SOC 3 Reporting
• Governed by AT 101 – Attestation service
• Criteria for evaluation is Trust Services Principles (TSP)
• Intended for users seeing assurance around one or more
of control areas not relevant to ICFR of User
• TSP Criteria:
• Security
• Availability
• Processing Integrity of the system
• Confidentiality of information processed
• Privacy of information processed

32. SOC 3 Reporting
• General use report
– Can be published
– For current and prospective customers
– One Type
• Report components like a SOC 2
– Does include management’s written assertion
– Does include a description of the system and its boundaries
– Is for a period of time
• Differences from SOC 2 Report
– Description of system less detailed and not covered by CPA’s report
– No description of test of effectiveness or results
– If privacy principle is addressed there is no description of compliance
with or test results

33. SOC 3 Reporting
• Seal (SysTrust for Service Organizations)
– Can be delivery vehicle for report
– Seal displayed on service organizations website
– SysTrust is registered by AICPA an Canadian Institute of
Chartered Accountants (CICA)
– Practitioners must be licensed with CICA to use seal

34. Reporting Options
• Multiple reports combinations
– SOC 1 and SOC 2
• Services impacting ICFR of user and other services with trust
services principles concerns
– SOC 2 and SOC 3
• Services not impacting ICFR and need to use beyond current users
such as marketing to prospects
– SOC 1 and SOC 3
• Services impacting ICFR of user and other services with trust
services principles concerns or marketing needs

35. Transition Planning
Action Items for Service Providers

36. Transition Planning
• Determine effective date for your organization
• Confirm Type of SOC Report
 ICFR – SOC 1 (SSAE 16)
 Limited Use / Trust Principles – SOC 2
 General Use / Trust Principles – SOC 3

37. Transition Planning
• Develop a Communication Plan
 Within your organization
 To your clients
 Client Internal Audit/Risk Management (i.e., other users of
the report)
 Marketing material
 Web pages
 Contractual references

38. Transition Planning
• Review Scope
 Included/excluded services
 Services that impact your client’s financial reporting
 Key third parties (sub-service organizations)
 Identify all relevant 3rd party service organizations
 Existence and use of their SAS 70/SSAE 16/SOC 2 Report
 Commitments from 3rd party relative to carve out or inclusive
method
 Contractual /SLA impacts

39. Transition Planning
• Review System Description
 Services
 Scope
 Classes of Transactions
 Third parties (inclusive or carve out)
 Risks
 Objectives
 Controls

40. Transition Planning
• Assess Control Design
 Risk based
 Will impact control objectives
 Will impact supporting control activities
 Consider current SOX or other compliance efforts/
governance models and efforts

41. Transition Planning
• Consider Management Assertion
 Review basis for assertion
 Review sufficiency of current monitoring processes
 Need for direct testing of controls not sufficiently
monitored

42. In Conclusion
• Develop a project plan
• Assign responsibilities
• Monitor the plan
• See Risk / Seek Help

43. Contact Information
Jeffrey Paulette
BKD – IT Risk Services
417.865.8701
jpaulette@bkd.com