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.
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:
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.
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.
SOC 2 reports include:
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.
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.
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:
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.
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:
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:
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.
Unlike the section bearing their name, management actually writes this section for review by the auditor. It describes the following:
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.
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.
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:
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.