There are distinct differences between SOC 1 and SOC 2 reports, but these reports also certainly overlap. For example, the security principle in a SOC 2 report refers to the protection of the system from unauthorized access (logical and physical) and limited access to the system to prevent potential system abuse; resource theft; software misuse, improper access or usage; and the alteration, destruction and disclosure of information.
Key elements for the protection of the system include granting authorized access based on relevant needs and preventing unauthorized access to the system in all other instances. Some of this language is seen in a general computer control objective in a SAS 70 and will continue to be seen in a SSAE16/SOC 1 report. System abuse and resource theft are not often internal controls over financial reporting (ICFR) concerns or a SSAE16/SAS 70 risks.
It is important to determine whether the data hosted or processed at your vendor is secure and protected and whether your service organization’s system will be available for critical business operations. Does this mean you need a SOC 2? That’s a business decision, not a compliance factor. If your service organization processes data for your organization, then the integrity of processing is of paramount importance. However, if the control objectives within the SOC 1 are worded properly and address the risk to financial statement assertions and disclosures, then a SOC 2 is typically not necessary. Based on the AICPA Trust Services Principles, processing integrity means that system processing is complete, accurate, timely and authorized. These same assertions should be found in the transaction-level control objectives in a SOC 1.
There are some similarities between SOC 1 and SOC 2. First, both engagements focus on defined attributes of a “system” consisting of five components: Infrastructure, Software, People, Procedures and Data. However, if using the Framework, a SOC 1 engagement is focused on five distinct components of an process designed to achieve certain objectives: one of them being external .
The five COSO components under the updated Internal Control Integrated Framework are:
- Control environment
- Risk assessment
- Control activities
- Information and communication
- Monitoring activities
The recipients of the SOC 1 will likely be evaluating its internal controls system based on the five COSO components. So, the SOC 1 “slips right in” to the user organization’s description of its internal controls system.
Secondly, the SOC 2 requires a management assertion. However, instead of asserting on the operating effectiveness of control objectives (designed to meet user organization needs regarding ICFR), management asserts on the operating effectiveness of the controls when meeting the selected applicable Trust Services criteria. SOC 2 organizations select the applicable criteria and controls from the Trust Services Principles, Criteria and Illustrative Controls.
In a SOC 2 engagement, management must develop a description of the system based on the criteria that will be subject to examination, which are different than the criteria used to describe the system under the SSAE 16/SOC 1 requirements. The benchmark for assessing the description of the system under SSAE 16/SOC 1 is determined by answering the question: “Is the system description adequately describing processes, control objectives and controls at the service organization that are relevant for me, the user entities and internal controls over financial reporting?” You won’t receive this assurance from a SOC 2.
Nonetheless, can you use some of the SOC 2 control testing? Maybe, but more work is required to make the SOC 2 useful for your risk control matrix and internal controls evaluation. Therefore, question whether you truly need the report. The SOC 1 report is intended for management of the service organization, its user entities and the auditors of the user entities. The SOC 2 report is intended for management of the service organization and other specified parties who have sufficient knowledge of the following:
- The nature of the services provided by the service organization
- The way 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 to meet the applicable Trust Services Criteria
- The applicable Trust Services Criteria
- Risks that may threaten the achievement of the applicable Trust Services Criteria and how controls mitigate those risks
Chances are you will not feel partial to raising your hand as one of these other specified parties.
Can a SOC 1 report be prepared from the work performed by a SOC 2 engagement? Work performed during the SOC 2 engagement can be used by the same service organization auditors to prepare a SOC 1. However, if you’re a client in this situation, consult with your user organizations and their auditors to verify their needs before the SOC 2 engagement starts and money is spent.
Third, under both SOC 1 and SOC 2, there are criteria to use as benchmarks when measuring and presenting the subject matter and against which the service auditor evaluates the subject matter. In a SOC 1, the criteria are the control objectives as specified by management. In a SOC 1 report, the external auditors are required to assess the suitability of criteria used by management to present its description. This includes evaluating whether management’s description of the service organization’s system omits or distorts information relevant to the service organization’s system and includes determining whether the control objectives are reasonable, based on the user organization auditor’s needs.
In a SOC 1, the service auditor, after determining the appropriateness of the control objectives when addressing the financial statement assertions relevant to the user organization and its auditors, determines which controls at the service organization are necessary to achieve the control objectives. In a SOC 2, the service auditor addresses the design of controls needed to meet the applicable Trust Services Criteria, a different set of criteria prescribed for management under Trust Services Principles (“TSP”) section 100.
When evaluating the SOC 1 report by a reputable firm, ensure that the service organization auditor evaluates materiality with respect to the fair presentation of management’s description of the service organization’s system, the suitability of the design of controls to achieve the related control objectives stated in the description, and, in the case of a Type 2 report, the operating effectiveness of the controls to achieve the related control objectives. Materiality only relates to the risk of material financial misstatement and will only be considered in a SOC 1.
Learn more about SOC Reporting on KnowledgeLeader through the resources listed below:
On the Road to SOC 2 Readiness: What Service Organizations Need to Know
Service-Level Agreement Controls Audit Work Program
IT Vendor Management Audit Work Program
