Risk Insights Logo

SAS70 Certification and other common SOC report myths

October 1, 2019

If you use or plan to use a cloud/SaaS/hosted solution, how do you ensure that the service provider is protecting your systems and data?

Rely on their SAS70 reports, right?

Not quite.

In this article, we explain why this is not the right answer and explore a few other common myths.



System and Organization Controls (SOC) reports used to be conducted in accordance with "SAS70" in the US.

A few years ago, SAS70 was replaced by:

  • In the US: SSAE18 (SSAE16 for a brief period).
  • Globally: ISAE3402.
  • In Australia: ASAE3402.

For audits that are conducted in accordance with these standards, a SOC report is produced.

There are various types of SOC reports, including:

  1. SOC 1: Frequently used, focuses on Internal Controls over Financial Reporting.
  2. SOC 2: Less frequent, focuses on Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality or Privacy).
  3. SOC 3 reports: similar to SOC 2, but for general use i.e., can be freely distributed.
  4. SOC for Cybersecurity: Focuses on cybersecurity risk management.
  5. SOC for Supply Chains: (Under development at the time this article was written)

In broad terms, SAS70 reports have been replaced by SOC 1 reports.


SOC 1 Myths


1. Certification or compliance


The outsourced service provider is certified or compliant. Variants of:

  • SAS70 certified
  • Certified under SSAE16 or ASAE3402 or ISAE3402
  • SOC 1 compliant


This is a common misconception.

And a dangerous one. Why? Because it creates a false sense of security.

The REPORTS are provided using well defined standards, but the reports themselves do NOT represent CERTIFICATION.

  • Other standards may allow for "certification" e.g., ISO27001, PCI DSS.
  • SOC 1 reports do not. These are reports with an opinion.
  • An organisation that says they are "certified" may be misrepresenting their status.


2. Qualified Opinions


A qualified SOC report is the same as qualified financials, which is bad.


The nature of, and reason for the qualification (i.e., why the report was qualified) needs to be considered.

A qualification isn’t necessarily a blanket failure:

  • A financial audit opinion relates to the financial records overall, including various processes and controls.
  • SOC 1 reports are largely controls focused, so a qualification will typically be specific to one or more control objectives. The controls usually represent a small subset of the larger control environment related to financial reporting.


3. Use of SOC 1 reports


The reports can be used to determine the level of control over all IT risks.


Again, a dangerous misconception.

Here "risk management" creates more risk, because the reports are relied on beyond their intended purpose.

The reports are designed for specific purposes:

  • SOC 1 reports are designed for financial statement misstatement risk i.e., for use by the external auditors of the service organisation's customers. In fact, the reports will state that this is the intended use.
  • The relevant standards were created because many service organisations (e.g., shared services providers) did not want multiple auditors coming in and asking the same questions, testing the same controls, etc. With the SOC 1 report, auditing is performed once, then relied on by their customer's auditors for customer's financial audits.
  • Using a SOC 1 report to obtain comfort regarding all other risks (e.g. privacy) is dangerous. There may be some overlap in risk/control, but they are not designed to cover related assurance requirements.


Use SOC 1 reports with care.


What you could do instead?

There is no way to completely mitigate the risks (and still be in business).

But you can take steps to manage the risk:

  1. Ask questions at inception, and then regularly, about how your systems and data will be kept secure. As an example, the Shared Assessments organisation has a toolkit.  Others exist. Or you can create your own.
  2. Ask about other types of SOC reports e.g., SOC 2. If opting for SOC 2, check whether this is a type I (point in time) or type II (over a period) report.
  3. Consider other forms of assurance e.g., via the service provider’s Internal Auditors.
  4. Use the elements of the SOC 1 report, as appropriate and with care. Some of it might be relevant, but will generally, as explained above, not cover all the areas you need.
  5. Ask your Internal Audit team or your Risk team for help.


*Note that the information above is a high level summary only and is not to be relied upon. Seek advice from your accountants, auditors, legal, compliance or equivalent.

**SOC used to refer to "Service Organization Controls", this was changed to "System and Organization Controls"

Share this article

Get more insights like this

Blog Post
The Assurance Blog
March 3, 2022

Data in Audit Guide

Read article
Blog Post
The Assurance Blog
December 16, 2021

The Data-Confident Internal Auditor: Software

Read article

Subscribe to our mailing list

Get notified by email about new blog posts and podcast episodes by the Risk Insights Team.