by Alan DeVaughan
The last several years have seen a dramatic increase in organizations using a third-party to perform key business or technology functions. Organizations are utilizing third-party hosting providers (e.g., Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP)), relying on a managed service provider (MSP) for network and system monitoring, or transmitting sensitive data back and forth with another entity. While outsourcing these functions may be a sound business decision, it increases your cybersecurity risk.
Effective vendor management plays a critical role in mitigating this risk. A comprehensive vendor management program establishes requirements for selection of potential vendors, appropriate due diligence of these vendors, cybersecurity requirements, contracting/legal requirements, and ongoing vendor performance monitoring. Many vendor management programs use an evidence-based approach and include a due diligence requirement to obtain a third-party attestation report for that vendor, if one is available.
One of the most frequently requested reports is a SOC 2 examination report. This third-party attestation provides reassurance that the controls contained within the report and system description were designed and operated effectively over a period of time (SOC 2 Type 2 report). However, obtaining the report is only the first step in appropriate vendor due diligence. The next step is to read and understand what the SOC 2 report is telling you.
So how do you read and understand a vendor’s SOC 2 report now that you have it? Let’s walk through the various report sections, discuss what they cover, and identify key items you should review.
First, we’ll start with a few key terms used throughout this article.
- Service Auditor: The auditing firm who is reporting on controls at the service organization. This is the CPA firm who is providing the opinion regarding the design and operating effectiveness of controls. An example would be Meditology Assurance.
- Service Organization: The organization which is providing services to its customers or other user entities. An example would be an organization providing a healthcare application which tracks personal health goals.
- Subservice Organization: An organization which is providing services in support of a service organization’s offerings to its clients. An example would be an organization which is using AWS to host an application suite used by the organization’s customers.
General Considerations
There are two type of SOC 2 reports, Type 1 and Type 2. While very similar, they differ in two key aspects:
- A Type 1 report provides an opinion on the design of controls noted within the report as of a specific point in time (e.g., 12/31/23). This means the controls were designed effectively and were in place as of that date.
- A Type 2 report provides an opinion on the design and operating effectiveness of the controls over a set time period (e.g., 10/1/22 to 9/30/23). This means the controls were designed and operated effectively throughout the entire period covered by the report.
Generally, a Type 2 report is preferred as it provides assurance that controls were in place for a longer time period. However, a Type 1 report is still useful as it gives you a reference point where controls were designed and in place. Many organizations will have a Type 1 report done for their first SOC 2 report and then follow-up with a Type 2.
If the effective date or reporting period is more than a year old, ask the organization if they have an updated report. It is possible the new report is not yet finalized and could be sent to you once completed.
Bridge Letters
Your vendor may send you a bridge letter. This document serves as an attestation by the service organization that the controls in place on the SOC 2 report have not changed, nor had any significant failures. This letter will cover the time from the end of the SOC 2 reporting period to the date of the bridge letter. Note that this letter is issued by the service organization and therefore not audited by the SOC 2 service auditor.
A bridge letter could be issued to allow for a full calendar year to be covered. For example, the SOC 2 Type 2 report period could be 10/1/22 to 9/30/23. A bridge letter would be issued on 12/31/23 stating the SOC 2 scope didn’t change and that the controls were still in place. This would provide some assurance that for the calendar year 2023, the SOC 2 controls are still operating as expected.
Report sections
A SOC 2 report typically has four sections but may have an additional fifth section. These sections include:
Section 1: Auditor’s Opinion
This section is the formal opinion by the service auditor which contains standard language required by the American Institute of Certified Public Accountants (AICPA). The auditor’s opinion details the scope of the report, the effective date or reporting period, and the auditor’s opinion regarding the design and effectiveness of the controls contained in the system description (Section 3).
You should review the system(s) in scope and the relevant dates to determine if they meet your vendor due diligence needs. SOC 2 reports can cover one or more systems so be sure the vendor’s system you are using is covered by the report. This information is in the very first paragraph of the opinion in the “Scope” section. It will read like this:
“We have examined <<COMPANY NAME>>’s accompanying description of its <<SYSTEM NAME(S)>> found in Section 3 titled “<<COMPANY NAME>>’s Description of its <<SYSTEM NAME(S)>> System” throughout the period January 1, 202X to September 30, 202X, (description) based on the criteria for a description of a service organization’s system set forth…”
A Type 1 report will substitute “…as of <<DATE>>” for the time period.
This section will also tell you if the auditor’s opinion is qualified for any reason. A SOC 2 report with a qualified opinion will have a paragraph in Section 1 titled “Basis for Qualified Opinion” and explain which Trust Services Criteria (TSC) were affected. We’ll explain more about qualified opinions later in this article.
You may also see paragraphs in the scoping section which address subservice providers and complementary user entity controls. We’ll discuss what those terms mean and their importance after describing the report sections.
Section 2: Management’s Assertion
This section is an assertion from the service organization stating that the organization has prepared the system description covered by the report. This section also has statements from the organization saying the description is accurate, and that the controls were designed (Type 1) and operating effectively (Type2) for the designated effective date or reporting period.
Like the opinion section, most of this section’s language is dictated by the AICPA. The opening paragraphs closely mirror the scope from Section 1. As long as this section covers the same scope and time period as the opinion, you should be good. You should also see matching subservice provider and complementary user entity control paragraphs, if applicable.
NOTE: Some CPA firms who issue reports will have the Management Assertion as section 1 and the Auditor’s Opinion as section 2. This is a style preference and does not affect the meaning of the report. Some firms prefer to have the management assertion first as the auditor’s opinion confirms that the assertion is valid.
Section 3: System Description
This section is especially important when it comes to vendor due diligence. The system description provides information regarding the system(s) in scope, the relevant services provided by the service organization, and a narrative version of the controls which were tested by the service auditor.
This section is provided by the service organization. While the same information is provided in each SOC 2 report, the way it is presented will vary greatly depending on the service organization and service auditor. Each service organization can choose which controls should be included so the description of those controls will depend on what is in scope for the report.
Generally, you should see items such as these:
- Company overview
- Services provided
- Principal service commitments and system requirements
- Components of the system used to provide the services covered by the report
- High-level detail about the service organization’s relevant infrastructure, software, people, policies and procedures, and data
- Relevant aspects of the control environment, risk assessment process, information and communication, and monitoring
You’ll see short paragraphs describing control environment items such as logical security, incident response, change management, network security, and other areas.
When reading the system description, you should ensure it covers the services and/or systems which you are using. For example, if you are using AWS to host your application, you want to obtain the AWS SOC 2 Type 2 report which covers the data center(s) and systems which are being used to host your application.
You also want to ensure that there are not any control areas important to your organization which you do not see in the report. For example, if you are relying on the service organization to handle data backup/replication activities, you want to see those areas described within the system description. If you are using a third-party to perform software development, you want to see their software development and change management controls covered in their SOC 2 report.
This section will also describe any significant control failures or incidents (if they occurred) and significant changes to the system which occurred during the reporting period. Ensure those incidents or changes don’t affect the services being provided to your organization.
If there are controls which did not operate, or TSC sections which were deemed not applicable (e.g., an organization does not have a board of directors), you’ll see that information contained in this section. Make sure these non-occurring controls, or non-applicable criteria, are not relevant to your needs.
You’ll also see more details about subservice providers and control areas for which they are responsible, and relevant complementary user entity controls.
Section 4: Trust Services Categories, Criteria, Related Controls, and Tests of Controls
In a SOC 2 Type 2 report, this section contains a table showing the SOC 2 TSCs, the service organization’s controls related to each TSC, the service auditors testing procedures, and the results of the tests. This section will tell you if the auditor noted any exceptions during their testing procedures.
Most people jump to this section when first reviewing a SOC 2 Type 2 report to see if any exceptions were noted, which controls were affected, and the significance of each exception. However, not all exceptions mean the same so you should read the system description to ensure you understand the purpose of each control, and whether an exception to that control is material to your needs.
For example, assume the service organization has a control stating new employees are required to complete information security training within 30 days of their start date. When you find that control in Section 4 (probably in CC1.4), you see the testing results notes an exception stating, “1 of 15 sampled new hire employees did not complete information security training within 30 days of their start date.” This does not indicate a systemic control failure but notes at least one person didn’t complete training on time. However, it could be that the employee completed their information security training within 45 days of starting. It’s an exception but probably nothing to be concerned about.
Compare that to a change management exception stating, “13 out of 20 sampled infrastructure changes were not approved before being implemented into production.” This is more concerning as it could indicate the service organization’s change management process is regularly skipping a vital step. This may lead to bigger problems, which may affect your services/systems.
For a Type 1 report, Section 4 will only include each TSC and the related controls. Since a Type 1 report is a test of control design, there won’t be a listing of testing procedures and the results of tests as those are only for tests of operating effectiveness.
Section 5: Other Information Provided by Service Organization (OPTIONAL)
Some SOC 2 reports may have a section 5 which contains other information provided by the service organization to anyone reading the report. Information in this section varies but is generally either management responses to testing exceptions, or additional information which wasn’t covered by testing.
If a service organization would like to provide more information or respond to testing exceptions, this information could be included in section 5. You might see the control wording, the exception noted by the service auditor, and a formal response from the service organization. They may describe what happened or provide information about procedures they have implemented to prevent the exception from happening in the future
Another example of other information included could be related to disaster recovery. A service organization may not include the availability category within their SOC 2 TSC control set but may want to provide details about their disaster recovery or business continuity plans. However, since these controls weren’t tested by the service auditor, this information doesn’t belong in Sections 3 or 4.
If section 5 is included in a SOC 2 report, the auditor’s opinion will have a paragraph stating the existence of a section 5, a note that the information in that section was provided by the service organization, and that the information was not tested by the service auditor. Therefore, the service auditor will state that their opinion excludes the information in section 5.
NOTE: You probably won’t ever see this in a SOC 2 report, but there might be a section 6 titled “Other Information Provided by the Service Auditor” which contains additional information.
Now that we’ve covered the sections within a Type 2 report, let’s address other important aspects you’ll see throughout the report.
Qualified Opinion
A qualified opinion means the results of the auditor’s tests concluded that one or more SOC 2 TSC did not have sufficient controls which were designed and operated effectively during the reporting period. This is a greater indication of design and/or operating effectiveness failures than control exceptions.
Remember, control exceptions do not necessarily mean there will be a qualified opinion. A TSC section may have seven controls. If one or two of those controls have exceptions, that doesn’t automatically require a qualification.
When a qualified opinion exists, the service auditor will add a paragraph in Section 1 (auditor’s opinion) titled “Basis for Qualified Opinion.” This paragraph will detail the relevant TSC(s), describe the expected control(s) performance, and the reason for the qualification. If you see this in a SOC 2 report, review the information, look at the test results in Section 4, and determine if the identified control performance issues are material to your organization. A qualified opinion may read like this:
<<COMPANY NAME>> states in the description that access to <<COMPANY NAME>>'s facilities is restricted and managed in accordance with job requirements, and that physical access rights are provisioned, modified, and revoked consistently following onboarding, transfer, or termination. However, as noted in trust services criteria CC6.4 of the description of tests of controls and results thereof, controls related to physical access authorization, physical access revocation, visitor identification, and physical access reviews were not consistently performed. Therefore, these controls were not operating effectively throughout the period <<REPORTING PERIOD>>. As a result, controls did not provide reasonable assurance that the service organization’s service commitments and system requirements were achieved based on the applicable trust services criteria.
Subservice Providers/Subservice Organizations
As mentioned earlier, you may see information regarding subservice organizations within both the auditor’s opinion and management assertion sections of a SOC 2 report. A subservice organization is a third-party entity which is being used by the service organization to provide one or more services. The most common subservice organization used is a hosting provider such as AWS, Microsoft Azure, or GCP. A subservice organization could also be an MSP who is providing server, workstation, or network monitoring services.
These subservice organizations are being relied upon to perform functions in support of the service organization’s offerings to its clients. There is an assumption that the subservice organization has certain controls in place which act to support the controls in place at the service organization. For example, if the service organization is using AWS to host their application, there is an assumption that AWS has appropriate physical security controls in place for its data centers.
The service organization and the service auditor determine during SOC 2 examination planning whether the controls at the subservice organization will be included in the testing (inclusive method) or not included in the testing (carve-out method). The language in the auditor’s opinion and the management assertion will tell you which method is being used. Typically, these controls are carved-out but not always.
If the controls are included, the system description and testing results will detail the controls included and indicate whether those controls were designed and operating effectively. If the controls are carved-out, the system description will have a description of the control expected to be in place at the subservice provider, and the associated TSC(s).
Complementary User Entity Controls
Most SOC 2 reports have information towards the end of the system description listing Complementary User Entity Controls (CUECs). The user entity (e.g., your organization or the reader of the report) should have these controls in place to complement the controls listed in the SOC 2 report. Assuming CUECs are present in the system description, there will be a paragraph added to both the auditor’s opinion and management assertion regarding CUECs. The service auditor does NOT test these controls.
Here is an example of a CUEC you might see in a SOC 2 report. The service organization provides an application which allows their clients to track and report on eating habits. Each client is given an account to access the application. This account has administrative rights to the client’s portion of the application and that master account can add other accounts. A CUEC could be the following:
User entities are responsible for notifying the service organization of changes made to technical or administrative contact information.
Since the service organization doesn’t know when people are terminated at their client, they are relying on someone at the client to tell the service organization that the person with the master account should not have access. The client’s logical access control process serves as a complement to the service organization’s controls.
Conclusion
SOC 2 Type 2 audit reports have become one of the most common and cost-effective vehicles for demonstrating controls relevant to security, availability, confidentiality, processing integrity and/or privacy to your customers and partners.
Meditology Assurance can perform SOC 2 readiness assessments and SOC 2 examinations. Our SOC 2 reports demonstrate your compliance with AICPA’s Trust Service Criteria for security, availability, processing integrity, confidentiality, and/or privacy.
Meditology can also provide you with assistance in developing a solid vendor management program. We would be glad to answer any questions or discuss how we can help initiate or strengthen your vendor management program. Whether it’s helping you interpret audit reports such as a SOC 2 Type 2 examination, developing policies and procedures, issuing a SOC 2 examination report, or performing vendor management functions, we’re here to provide you the support you need.
If you want to take vendor management to the next level, our sister company, CORL, provides comprehensive third-party risk management (TPRM) solutions that leverage technology, industry expertise, and managed services. CORL assesses vendor risks and provides detailed results through the CORL portal, giving you peace of mind.
About the Author
Alan DeVaughan is an experienced compliance and information security senior manager specializing in assisting organizations with SOC 2 readiness assessments and examinations for over 10 years. In addition to leading the firm's SOC 2 service line, he serves as a consultant team leader focused on advising healthcare clients of varying size and complexity in areas of IT, privacy, security, and compliance. Alan has in-depth knowledge of security technology frameworks such as NIST, HITRUST, SOC 1 / SOC 2, HIPAA, and FFIEC. With a background in network administration, he has over 25 years’ experience in information technology consulting for a wide variety of organizations and industries.