System and Organization Controls (SOC) Reports

With the proliferation of Software as a Service (SaaS) applications the AICPA’s System and Organization Controls (SOC) report has become the default way for service organizations to define their control environment over the software. Sometimes, these reports are referred to as “Service Organization Control” reports. So, what is the functional purpose of these reports?

Customers (users) of a SaaS application use (or should use) this report to understand:

• The operating environment

• The controls the service organization has put in place over the environment

• Any gaps in those controls as noted by an independent auditor

• The controls the service organization indicates the customer should have in place to complement the service organization controls

That is certainly a lot, so let’s break it down.

A SOC report can provide many perspectives, but one key aspect is to help organizations who have outsourced business processes understand the controls that have been applied to those environments. This can help management operate the entire business process (even those that are outsourced) in a controlled manner and be able to show evidence of that controlled environment to applicable stakeholders.

While the focus of this article is SOC reports focused on outsourced software, there are several different SOC reports whose purpose differs in the focus and scope:

• SOC 1 Report - Pertains to the controls at a service organization that are relevant to the user entities’ Internal Controls over Financial Reporting (ICFR) environment. These reports are intended to be distributed to user organizations and their financial auditors. An example would be a payroll processor (service organization) whose controls impact a customer’s financial statements.

• SOC 2 Report - Pertains to the controls at a service organization that are relevant to the security, availability, processing integrity, confidentiality or privacy of data at the user entity. These reports are intended to be distributed to users who have a specific need related to the service being provided. An example would be a SaaS solution (service organization) who hosts customer data in the cloud.

• SOC 3 Report - Pertains to the controls at a service organization that are relevant to the security, availability, processing integrity, confidentiality or privacy of data at the user entity but does not provide the same level of detail as the SOC 2 report. These reports can be distributed freely.

• SOC for Supply Chain - Pertains to the controls at a service organization over supply chain risk.

• SOC for Cybersecurity - Pertains to the controls at a service organization over cybersecurity risk, not just a specific system or service like the SOC 2 report.

SOC 1 and SOC 2 reports come in two perspectives in terms of coverage.

• Type 1 reports only cover the assessment of the control design at a point in time.

• Type 2 reports cover the assessment of the control design and operating effectiveness across a defined period of time.

SOC reports are generally broken down into four key sections as described below.

• Description of the service organization and the services covered by the SOC report.

• Description of the service organization controls that management has put in place over the environment.

• The independent auditor’s attestation opinion over the service organization controls.

• Description of Complementary User Entity Controls (CUECs). These are controls that the user entity should have in place for the service organization’s controls to be effective.

A bridge or gap letter is a letter issued by the management of the service provider that the controls are still operating as they were at the time that the SOC report was issued by the auditor. These are generally used to obtain SOC report coverage when the fiscal year of the customer does not match the time frame of the SOC report.

• Service Organization - The entity offering the service that is being covered by the SOC report issued by the service organization’s external auditor. In our example, the SaaS application vendor is the service organization.

• Subservice Organization - A vendor the service organization has contracted with to perform, manage or otherwise support the service organization’s process being assessed by the SOC report.

• Customer (User) - The entity that has utilized the service organization’s solution as part of their business process.

• Service Organization Auditor - The auditor who has been hired by the service organization to test management’s controls over the specific environment and who will perform the testing and issue an attestation report with their opinion.

• Customer Auditor - The auditor who provides audit services to the customer and utilizes the SOC report as part of their assessment of the customer’s control environment.

A SOC report relies on the premise that the management of the service organization has put the described controls in place and is executing them as detailed in the auditor’s attestation. It also assumes that the independent auditor has carried out adequate testing to provide an attestation that is accurate, reliable, and supported by evidence. Each SOC report and the ecosystem developed by the AICPA is built on trust. There have been recent reports and claims of a SOC report mill that was simply churning out SOC attestation reports at scale (and at low prices) without doing the actual work it would require to perform one properly. This should be a wake-up call and a call for integrity and accountability in the accounting industry to uphold the standards set by the AICPA to ensure that SOC attestation reports can continue to be trusted and relied upon. As technology advancements through artificial intelligence (AI) continue to create a more complex operating model, the ecosystem will need the assurance and clarity that a SOC attestation report can provide.

• Does your organization have a complete inventory of SaaS applications within your business process and technology stack?

• Do you currently request and review a SOC report for each SaaS application within your business process?

• Have you reconciled out all Complementary User Entity Controls (CUECs) to confirm your business is aware of and has all of these controls in place?

Would you like to discuss this topic further? Contact Brian Howell from Crestview.io