SOC Review Guidance: Tips for Reading SOC 1 & SOC 2 Reports

Are you reviewing a service organization’s SOC 1 or SOC 2 report or are a service organization answering questions about your organization’s SOC report? Then knowing how to review and understand SOC 1 and SOC 2 is important. When evaluating a service organization or vendor many companies request a SOC 1 or SOC 2 report to review, but what does that really mean? What is being looked for in the SOC reports specifically? Typically, a SOC report is used by someone to gain an understanding of the service organization’s system or service, internal control environment, and whether the related controls are designed and operating effectively. This is done to make sure that both the user entity’s and service organization’s service commitments and system requirements are being met, either prior to engaging the service organization or throughout the relationship.

While most organizations recognize the need for a SOC 1 or SOC 2 from their service organizations, once the SOC reports are received there is typically the question, what do we do with it now? In the following post, I will provide a high-level overview of what you should look for when reviewing a SOC 1 or SOC 2 report, answer some of the common questions asked when it comes to reviewing SOC reports, and provide some general tips on how to read SOC reports.

What Information is Included in a SOC Report?

First off, whether you are the person reviewing the report or the service organization issuing the report, you will want to understand some basics about SOC reports (and the differences between them) in order to understand which report is relevant. SOC 1 and SOC 2 reports are both attestation engagements governed by the AICPA and issued by licensed CPA firms.

Specifically, SOC 1 reports focus on a service organization’s system or service and related controls that impact a user entity’s internal controls over financial reporting. They are typically requested in support of the user entity’s financial statement audit, such as a SOX audit. SOC 2 reports focus on a service organization’s controls relevant to one or more of the five TSCs; security, availability, confidentiality, processing integrity, and privacy. Still confused? Not to worry, below are some more differences between the scope of a SOC 1 and SOC 2 report to help you determine which SOC report you need to review.

How Are SOC 1 & SOC 2 Reports Different?

A SOC 1, as mentioned above, would be appropriate to review if a service organization’s system or service could impact the user entity’s internal controls over financial reporting. For example, a payroll processing system or payment processing system would typically issue a SOC 1 report. A SOC 1 provides information allowing user entities to gain an understanding of the design and operating effectiveness of controls that support the system and could impact the user entity’s internal control over financial reporting. A SOC 1 report scope typically includes control objectives related to a system or service that include both monetary or business process controls and general information technology controls.

A SOC 2 report scope doesn’t focus on controls that impact financial reporting like a SOC 1. Rather, the scope of SOC 2 focuses on controls relevant to the Trust Services Criteria (TSCs), which in general, are more focused on the security of client data stored or used by a system or services. There are five TSCs that can be included in a SOC 2 report, but only one must be included (Security).

• Security (or Common Criteria)
• Availability
• Confidentiality
• Processing Integrity
• Privacy

Most service organizations that collect, store, and/or process client data are asked by their user entities to provide a SOC 2 report at one point or another. This allows user entities to review the controls in place at the service organization and determine whether service commitments and service requirements related to security and any other applicable criteria are being met.

 

Who is Responsible for Reviewing SOC Reports?

It depends on who you ask, but in general SOC reports are reviewed by user entities of the subservice organization’s system or service. In many cases, these reports are forwarded to external and internal auditors for deciphering. Typically, external or internal auditors will use a SOC report review checklist to highlight the key information presented in the report, map relevant controls to the user entity’s environment, and review control testing results. This helps auditors to determine how the user entity’s internal control environment is impacted and the level of risk related to using the service organization’s system or services.

Management at the user entity should also review their service organization(s) SOC reports, in addition to any third-party auditors, to understand if there have been any issues during the period, how their organization is impacted by the issues, and what controls management is responsible for (complementary user entity controls). When considering how one’s own control environment is impacted by a SOC report, management should review the report with their own organization’s service commitments and system requirements in mind, as well as the service organization’s.

With these considerations in mind, management will better understand the relationship and related risks. This might sound like a daunting task without a SOC report review checklist or the background that internal and external auditors have. To ease your SOC review anxiety, the remainder of this post will cover critical areas to review in a SOC report and other things to check for in a SOC report.

 

What Should I Look For When Reviewing a SOC 1 or SOC 2 Report?

If you don’t have a SOC review checklist or the help of internal/external auditors, the following are some suggestions for what to look for when reviewing a SOC 1 and/or SOC 2 report.

Report Scope

Many service organizations issue multiple SOC 1 and SOC 2 reports for the various products and services they offer. Review the title and system description that describes the systems and services included in the scope of the report to make sure the report covers the system/service your organization is using.

Report Period

More than a few service organizations try to pass off old reports as current reports. Make sure you are provided with the current SOC report by checking the report date and the time period covered by the report. Does the testing performed cover the design and operating effectiveness of the controls over a period of time (Type II) or a point in time (Type I)? If the report timing doesn’t provide you with the coverage you require, ask the service organization about it. They may be able to provide you with a bridge letter to cover a portion of your period that isn’t included in the report. It is typical for a Type II SOC 1 and Type II SOC 2 report to cover anywhere from six months to twelve months at a time, with a new report issued semi-annually or annually to provide continuous coverage for their users.

Service Auditor

The name of the service auditor issuing the SOC report is typically located in Section I of the report, in the auditor’s opinion. Do some research on the service auditor issuing the report and determine whether they are a reputable and registered CPA firm. Good resources to review are the AICPA’s peer review page, where peer review reports can be found. As well as the website of the state accountancy board, such as the Colorado Department of Regulatory Agencies – DORA. If you don’t find any information on the service auditor after performing a search on these or related sites, discuss your concerns with the service organization. Something important to note as well is that if the CPA firm does not perform financial statement audits, they will most likely not be registered with the PCAOB as this is not required for performing and issuing SOC audits.

Auditor Opinion

In section I of the report, the opinion of the service auditor can be found. The opinion will indicate the overall results of the audit and take into consideration any exceptions noted in testing. Four types of audit opinions could be used in a SOC report:

• Qualified
• Unqualified
• Adverse
• Disclaimer of opinion

If the report has a disclaimer of opinion, adverse opinion, or qualified opinion, your organization will need to evaluate how this impacts your reliance on the report and the services provided to you by the service organization. If the report opinion is unqualified, that basically means that the controls were designed and operating effectively and any exceptions noted in testing, if any, were not pervasive and did not present a greater risk to the overall operation of the system or services and achieving the applicable criteria/control objectives.

Management’s Assertion

Management is required to include their written assertion in the report stating the report’s accuracy and this is typically found in section II of the SOC report. In some instances SOC reports are being issued without a management assertion or the content of the management assertion differs from the auditor’s opinion. If it’s missing or opinions differ, a conversation with the service organization is warranted.

Location

Service organizations often have multiple locations, which is to be expected in the global economy. Make sure the report and audit testing cover the locations in which the service organization is performing services for your company. The locations covered can often be found in the system description of the report, if it is not obvious, ask the service organization to clarify.

Processes, People, and Systems

The processes, as well as the people and systems that support the processes, should be adequately described in the report. This information is typically found in section III of the report, the system description. The system description should include sufficient detail so users of the report can understand what the service organization is doing and what they are not doing. If a key process or system is not described in the report, ask the service organization about it.

Subservice Organizations

In some instances, a service organization relies on a subservice organization to provide a portion of its services to the user entity. An example of a common subservice organization is cloud hosting and managed services providers used to host an application developed and maintained by a service organization. If a subservice organization is being used, determine whether the carve-out method or inclusive method is being used.

If the carve-out method is being used, the services provided by the subservice organization and the related controls over the services provided are not included in the scope of the SOC report. If this is the case, you may need to request a SOC report directly from the subservice organization if the services they provide are material to your control environment. If the inclusive method is being used, the services provided and the controls at the subservice organization are included in the scope of the SOC report. If any questions arise regarding the subservice organization, the services they provide, and what is being covered in the report, clarify with the service organization.

Complementary User Entity Controls (CUECs)

Complementary user entity controls (CUECs) are controls the service organization is not responsible for, that the user entity should have in place when using the system or services provided. When reviewing a SOC report, the user entity should review the CUECs to determine whether the controls listed are relevant to them and if so, if the controls are in place and operating effectively. Most SOC reports have CUECs listed within them. A quick word search in the SOC report for “complementary user entity controls” should help you quickly locate the section in the report where all CUECs are listed.

Testing Procedures and Results

Based on whether the SOC report you are reviewing is a Type I or Type II report, you will need to review the extent of testing performed and determine if it is sufficient to meet your organization’s needs. The controls tested, the description of the testing performed and the results of the testing can generally be found in Section IV of the report. Review any exceptions/issues identified, including how they were mitigated and/or remediated to determine the risk associated with the issues and if they impact your organization.

It is common for SOC reports to have exceptions, so don’t panic if the one you are reviewing does. What is important is to determine if the findings impact the services provided to your organization or your organization’s control environment. Oftentimes the auditor’s opinion will assist in this process as the report opinion would likely be modified if the exceptions as a whole or standalone had a larger impact on the system or services and related control objectives/criteria. Reviewing management’s responses to exceptions is also helpful to understand how the risks associated with the exceptions were mitigated and/or remediated.

 

SOC Review Highlights

That was a lot of content related to SOC reviews, so here are some quick facts to remember when reviewing SOC reports.

• What information is included in a SOC report? 

• • Depending on the type of report, SOC 1 vs SOC 2 in general, the report will include the auditor’s opinion, management assertion, system description, description of tests of controls, and results.

• Who is responsible for reviewing SOC reports? 

• • It depends, typically user entities management and their internal and/or external auditors are responsible for reviewing SOC reports.

• What do you check for in a SOC report? 

• • Some things to check for are that the report scope covers the relevant system/service and time period required, the auditor’s opinion (qualified vs unqualified opinion or other modified opinion), CUECs, testing results for exceptions/issues, and management’s responses to any exceptions identified.

Key Takeaways for Effective SOC Report Review

I just covered some basic information and guidance to consider when you read and review a SOC report. Hopefully, you now know what to look for when you are reviewing a SOC 1 or SOC 2 report, or better understand why people seem to be asking to review them all the time. Overall, there are different concerns to consider when reviewing a SOC report and the lens through which you review your SOC report should reflect the coverage you need to obtain for your organization.

Often, dialogue with the service organization is required in order to clarify any questions regarding the scope and results of the SOC report. Reviewing the SOC report and understanding the results is important when understanding the system or services being provided and the effectiveness of the service organization’s internal controls.

Linford & Company is a CPA firm that specializes in various audits, including SOC 1 and SOC 2 audits, and other auditing services. If you have further questions on what a SOC audit entails, please review our page and contact us to see how we can further assist you and your organization.

This article was originally published on 10/24/2018 and was updated on 3/26/25.