What is a SOC 2 Attestation Report?

It’s the pot of gold at the end of the service authorization control (SOC 2) audit journey. These reports—issued by independent CPAs—affirm that a company’s data management practices meet criteria issued by the American Institute of Certified Public Accountants (AICPA). Increasingly a requirement for security-conscious enterprises that rely on cloud service providers, the SOC 2 report has become a vital tool for building trust with prospects and winning deals that make them customers. Cloud migration now touches every industry, making SOC 2 compliance a valuable achievement for any company. Organizations needing to demonstrate SOC 2 compliance include but are not limited to software-as-a-service (SaaS) providers, companies that provide business intelligence or analytics, and financial services institutions.

What is a SOC 2 Report? About this SOC 2 Report Example

The AICPA developed the SOC 2 requirements specifically to measure the veracity of an organization’s data security and privacy controls. The SOC 2 report is the result of a SOC 2 audit process that is meant to ferret out information regarding a company’s overall data security posture, specifically as it relates to the security standards and controls covered by SOC 2. These controls refer to the policies, processes, and procedures deployed by an organization to mitigate risk.

SOC 2 framework is built on five Trust Services Criteria (TSC) laid out by the AICPA:

• Security: How well does a company use tools such as firewalls and multi-factor authentication to protect information from unauthorized access?
• Availability: Are the systems in place for things like disaster recovery and performance monitoring adequate to ensure employees and customers can rely on an organization’s application or service to perform as expected and without service interruption?
• Confidentiality: Do the access control and encryption protocols in place adequately protect confidential information by limiting access, storage, and use?
• Processing integrity: Can an organization consistently verify its systems operate as intended?
• Privacy: Does the security infrastructure in place properly leverage encryption and access control tools to adequately protect sensitive user information from unauthorized access?

When complete, the SOC 2 report demonstrates how well a service organization has implemented these security controls. SOC 2 reports all share a similar structure but can vary based on industry or audit criteria. Organizations and service auditors often do present the contents differently, but regardless of layout, the content is the content. There will always be at least four sections (sometimes five) in addition to a cover page that calls out which criteria are in scope. 

SOC 2 Report Example

So what does a SOC 2 report look like? The AICPA offers an illustrative SOC report layout as an example of what organizations should look for from the auditors. This document is a good reference tool for those trying to make sense of SOC 2 auditing and reporting.

The big ticket items in this example are the auditor’s opinion and management assertions. The auditor prepares a detailed description of the systems and processes used to deliver services, as well as the controls in place to manage risk. They assert that description is accurate and complete, then render an opinion regarding control suitability and effectiveness. The management assertion should identify all relevant products and services for the customer or prospect viewing the report.

It’s also wise to look for exceptions and any verbiage (terms like omission or disclaimer) that would be cause for concern about controls in place. The following break down of a SOC 2 report will help with review, analysis, and understanding of its contents.

Breaking Down the SOC 2 Report

SOC 2 reports include:

• Section I - Management Assertion
• Section II - Independent Service Auditor’s Opinion
• Section III - Systems Description
• Section IV – Description of Controls and Test Results
• Section V (If applicable) – Management’s Response to Exceptions

The report’s primary purpose is to determine if systems meet the audit criteria by providing detailed information about the audit itself, the systems evaluated, and management’s commitment to SOC 2 compliance.

Section I - Management Assertion

Management assertion is a letter from company leaders that includes a summary of the product and services as well as the structure of IT systems, teams, and controls. It provides the reader with a list of facts and assertions, or statements, made by the service organization’s management related to the systems. Management assertions are drafted by the service auditor who will provide the document to an executive at the organization to sign. Needless to say, the person signing the assertion should read the document carefully to ensure that all statements in it are true.

Section II – Independent Service Auditor’s Opinion

Also known as the Report from the Auditor, this section usually follows the structure of the AICPA model linked above. Though a SOC 2 audit is not technically a pass/fail process, a clean or unqualified opinion is generally considered a successful outcome.

In addition to the desired outcome of an unqualified opinion from the auditor, there are three other possible outcomes. The four types of auditor opinions are: 

Unqualified 

This means that the controls tested as part of the report are designed and operating effectively. An unqualified opinion can still have issues and exceptions. When these appear in an unqualified opinion, then the organization and its auditors were able to mitigate or remediate the risks presented by the exceptions, meaning the control in place was deemed effective.

Page 7 of the AICPA report is an example of an unqualified opinion.

Qualified

A qualified opinion states that a control or controls are not designed and/or operating effectively and that the issues identified are enough to label one or more controls ineffective. Qualified opinions come about frequently and while not as problematic as an adverse or disclaimer opinion, they do indicate that one or more controls in place will require improvement.

Exceptions are the result of:

• Misstatements referring to an error or omission in the description of systems or services.
• Deficiency in the design of a control occurs when a control necessary to achieve the control objective or criteria is missing or an existing control is not properly designed.
• Deficiency in the operating effectiveness of a control means a properly designed control does not operate as designed or when the person performing the control does not possess the necessary authority or competence to perform the control effectively.

When these exceptions occur, the auditor will provide a high-level statement about these exceptions to explain why they qualify their opinion. Example language could be:

• “The description does not fairly present the system that was designed and implemented throughout the audit period.” 
• “The controls related to the control objectives stated in the description were not suitably designed to provide reasonable assurance that the control objectives would be achieved if the controls operated effectively throughout the audit period.”
• “The controls tested, which were those necessary to provide reasonable assurance that the control objectives stated in the description were achieved, did not operate effectively throughout the span of the audit.”

Adverse

This is a suboptimal outcome, because the auditor reports the company’s systems and controls can’t be trusted. It will cite multiple exceptions or instances of controls not working as intended. The auditor will lay out the points of failure in detail, using language similar to that of a qualified opinion.

Section III – System Description of the System

Unlike the section bearing their name, management actually writes this section for review by the auditor. It describes the following:

• Company Background
• Overview of the System (service or product) 
• Key Features of the System
• Principle Service Commitments and System Requirements
• System Boundaries 
• Trust Services Criteria Not Applicable to System
• Subservice Organizations
• Relevant Aspects of the Control Environment, Risk Assessment, Information and Communications and Monitoring
• Incidents and System Changes
• Complementary User Entity Controls

This section can be challenging for many companies, because director-level personnel and those in the C Suite don’t have a lot of experience writing IT compliance reports. The AICPA example report is helpful for creating this section, but without a resource with time on their hands who is well versed in drafting a system description or an automation tool that can accelerate creation, this part of the process can slow down the audit process and delay the report.

Section IV - Description of Controls and Test Results

This section is prepared by the auditor and provides support for their opinion. Every control identified by management in the preceding section is tested. This section is where the controls are described, and the results of the testing revealed. The description will include applicable trust service categories, test criteria, any related controls, and tests of controls. These are followed by the results of those tests.

The auditor always includes information about how tests were performed along with a table of results.

Section V (If applicable) – Management’s Response to Exceptions

This optional section can appear at the front or back of the service auditor’s report. It’s designed to provide additional relevant information not covered in the report itself, and therefore references elements not tested by the auditor. 

Management can include this section to provide information such as: 

• The organization’s future plans for new systems,
• Key aspects of the control environment not covered in the report that the organization wishes to communicate to its customers and prospects,
• Detailed explanation of their response to a qualified opinion.

The Case for Automated, Efficient SOC 2 Reporting

SOC 2 reports can be a challenge for many organizations. Delays can translate into lost customers and frustrated sales teams losing deals to more responsive competitors. Strike Graph can help.

After years of drafting system descriptions, Strike Graph created a semi-automated and highly efficient way for an organization to generate SOC 2 reports — cutting preparation time by as much as 75%. Find out how here or schedule a demo today.