Debunking 5 Common Myths About SOC 2 Audits

The expansion of the SaaS business model has led to a proliferation of System and Organization Control (SOC) 2 reports to meet the needs of businesses requiring detailed information regarding their IT vendors’ controls related to security, availability, confidentiality, processing integrity, and privacy. Although many organizations using service providers request a SOC 2 report in order to gain assurance over the security of their data, they may not fully understand what a SOC 2 report entails. To clear the air about this increasingly sought-after report, let’s dispel a few of the common myths and misconceptions about SOC 2.

Myth #1: SOC 2 is a certification.

A SOC 2 report is actually a form of attestation whereby a CPA firm will issue a report containing an opinion on whether or not the service organization’s controls were suitably designed and/or operating effectively to meet criteria classified into one or more Categories: Security, Availability, Confidentiality, Privacy, and Processing Integrity. While the Security (a.k.a Common Criteria) category is required, the others can be scoped in depending on the organization’s service commitments and system requirements. The report can be either as of a specific date (Type 1 report), or over a specified period of time (Type 2 report). The key takeaway here is that the CPA firm performing the SOC 2 audit does not issue a “certificate” as part of the SOC 2 attestation process.

When an organization states ‘We are proud to announce that we have achieved SOC 2 certification’ via a press release or on social media, what they are really conveying is that a CPA firm has performed a SOC 2 audit and issued an opinion over one or more categories. It is important to note that this does not necessarily indicate a clean opinion (i.e. unqualified report and without exceptions), and may actually have exceptions or be qualified at either a specific criteria or category level. Another possible outcome is that the auditor issues an adverse or disclaimer opinion, in which case the audit report holds little value to potential clients because it does not provide confidence that the service organization’s controls are suitably designed or operating effectively to meet the applicable criteria. 

Since these audit reports are usually issued over time periods that have already elapsed, a firm will likely need to regularly undergo SOC 2 audits for consecutive periods in order to provide its customers continued assurance over the design and operating effectiveness of its controls.  

Myth #2: A SOC 2 report is solely focused on IT or security-related controls.

IT-related or security controls by themselves will not be sufficient to achieve a clean SOC 2 report. The SOC 2 Trust Services Criteria also requires controls addressing COSO Principles, which focus more on overall company governance, ethics, and culture. This includes “tone at the top” controls such as implementation and dissemination and acknowledgement of the appropriate policies, code of conduct, and employee handbook, and the organization’s ability to attract, develop, and retain employees. Additionally, the organization will need controls over risk identification and assessment, risk mitigation, control activity monitoring, and its vendor management program. Understanding the broader nature of the audit will assist companies in implementing the relevant controls to undergo a SOC 2 examination successfully.

Myth #3: The number and types of SOC 2 controls are mandated. 

The entity undergoing the SOC examination will need to determine the appropriate number and type of controls required to meet the AICPA Trust Service Criteria depending on the categories in scope. As a general rule, the criteria are written in a way that allows flexibility in determining which controls at a particular organization should be put in place to meet them. The Trust Service Criteria are supported by Points of Focus that are meant to serve as guidance for both the organizations and auditors. However, an organization is not required to implement controls for each point of focus specified, only those it deems relevant.

There is no minimum requirement for the number of controls. While 40 controls may be necessary for one company to meet the required Common Criteria, another entity may decide that it will take 100 controls. An organization does need to have sufficient controls to meet all criteria specified for the selected categories, which is also subject to independent verification during a SOC 2 audit. Consequently, a SOC 2 audit is definitely not a check-the-box exercise that can be accomplished by meeting a specified list of requirements — organizations need to determine what is right for them as well as a broad range of their report readers.

Myth #4: The SOC 2 Type 2 audit is an annual examination. 

As mentioned previously, a SOC 2 Type 2 report covers a period of time. 12 months is the most common, but there is no minimum required duration — although typically, the shortest period a CPA firm will accept to audit is three months. There are several scenarios where a duration shorter than a year would make more sense for the entity. For example, a company undergoing a SOC 2 readiness assessment in the middle of the year may require a six month report for the ending period of the audit to align with their year end, or their customers’ fiscal year. Going forward, they could then keep a 12 month reporting period to maintain continuous coverage for their readers. 

Additionally, if the organization has a large customer base with varying audit report timing needs, it may be more practical to undergo the audit every six months for the results to be recent enough for most customers. To sum it up, while there isn’t a required timeframe, the AICPA recommends coverage at least every six months, and most customers require 12 months of coverage.

Myth #5: SaaS organizations relying on a cloud service or IT infrastructure provider can share the sub-service organization’s SOC 2 report in place of undergoing their own examination.

Many organizations believe they can have full coverage over their environment by obtaining their service providers’ SOC 2 reports. While obtaining their SOC 2 reports does provide some coverage, often organizations are only responsible for a subset of controls. It might be tempting, but most customers will not — and should not — accept a SOC 2 report from a SaaS organization’s IT infrastructure provider (i.e. MS Azure, AWS, Rackspace etc.) alone. Due to the shared responsibility model, there are controls that the users of these services (in this case, the service organization itself) will need to perform on their end, and thereby will need to undergo its own examination. This includes controls in place over its use of the cloud/infrastructure service, such as restricting logical access to the appropriate individuals.

In this instance, the IT infrastructure provider will count as a subservice organization, and the SaaS service organization will typically use the ‘carve-out’ method to exclude the subservice organization’s controls from its own SOC 2 report. 

The key point is that SaaS organizations must be aware of their responsibilities so that they can undergo their own SOC 2 audits. Their clients cannot solely rely on third-party reports, and will require an entity-specific report in order to do business.

Conclusion: A Clear View of SOC 2

SOC 2 reports remain an enigma to many in the industry, but they are critical for organizational success and business growth. Whether you are undergoing a SOC 2 audit yourself or are reviewing another service provider’s SOC report as part of your third-party risk management program, gaining an understanding of what a SOC 2 report truly entails will increase your chances of success.