“Why can’t I share my SOC 2 report?” It’s a question we’re asked a lot, and given the time and expense of acquiring a SOC 2 report, it’s understandable. You can share it, but your report is restricted and there are good reasons behind this restriction.

The SOC 2 report is, by definition, a restricted use report. As such, it’s not suitable for public distribution. If you think about it, a SOC 2 report includes a detailed system description and a matrix of controls specific to your company that often includes proprietary information. From a process and security stance, it makes sense not to publish this information for your competitors or people with nefarious intentions to see. This is why if you do a Google search for “example SOC 2 report”, you can’t easily find one.

Suppose you use AWS or Microsoft Azure as your subservice organization and need a copy of their SOC 2 report. In that case, there’s a specific process to verify whether you should be given access to this information. Further, the AICPA standards look to the “intended reader” of the report and whether that reader has sufficient knowledge to understand the report’s content.

Case in point: The following excerpt is standard audit opinion language that appears in all SOC 2 reports detailing “Restricted Use.” You’ll notice that it reinforces the AICPA’s “intended reader” standards:

This report, including the description of tests of controls and results thereof in the section of our report titled “Description of Test of Controls and Results Thereof” is intended solely for the information and use of [Service Organization Name]; user entities of [Service Organization Name]’s [insert title of the description] during some or all of the period [Month XX, 20XX] to [Month XX, 20XX], business partners of [Service Organization Name]’s subject to risks arising from interactions with [Service Organization Name]’s processing system; practitioners providing services to such user entities and business partners; prospective user entities and business partners; and regulators who have sufficient knowledge and understanding of the following:

This report is not intended to be and should not be used by anyone other than these specified parties.

For more general use, a SOC 3 report is an optional add-on for a SOC 2 report that omits detailed control listings and sensitive information and employs modified system descriptions. In effect, it is a summarized version of the SOC 2 Type 2 report. As such, it is defined as a “general use report” and can be distributed freely.

In contrast to the challenges of obtaining Amazon or Microsoft’s SOC 2 reports, both share their SOC 3 reports publicly.

For more information on why SOC 2 reports are restricted use and examples of other, more general alternatives, check out the AICPA’s guidance on the available SOC reports. If you’re considering a SOC 2 report, don’t hesitate to reach out to our team or visit our SOC 2 services page.

As service organizations prepare for SOC 2 examinations, understanding the roles of the Privacy and Confidentiality Trust Services Criteria (TSC) can help them manage risk more effectively and optimize the scope of SOC 2 audits.

Privacy and Confidentiality are two of the five TSCs that can be considered in a SOC 2 review. The Security criteria is mandatory, while Confidentiality and Privacy, along with Availability and Processing Integrity, are optional areas for review.

The Confidentiality and Privacy criteria, although similar in nature, have important differences that a service organization should consider as it decides which criteria should be included in an upcoming SOC 2 review.

It’s important for companies scoping a SOC 2 audit to understand the differences between the Confidentiality and Privacy criteria:

Confidentiality refers to a service organization’s ability to secure proprietary information from unauthorized access or disclosure. The types of data that need to be secured will vary among providers, but typically include:

Privacy refers to the service organization’s ability to collect, use, retain, dispose of, and disclose personally identifiable information (PII) in accordance with client agreements as well as any applicable laws or regulations. This will typically include:

Deciding whether to include one, the other, or both criteria depends on several factors, including the types of data the service organization handles on behalf of its clients and the sensitivity of that data.

For example, the Privacy TSC is important for providers that interact directly with individuals or process PII on behalf of their clients. In these instances, the service organization’s client (and their customers) will share data with the system and thus may also want to understand the steps the service organization follows to protect that sensitive data within the system.

The applicability of the Confidentiality TSC will likely vary among service organizations and their clients, but it often comes into scope when the provider is processing or using information it is contractually required to protect.

For instance, a service organization that provides purchasing software for its clients will need to secure the customers’ purchase history from unauthorized access, but with perhaps less technical rigor than it would apply to someone’s health insurance claim or personally identifiable data.

After classifying data and selecting the appropriate criteria, service organizations will need to design and implement appropriate controls to ensure compliance with the Privacy and Confidentiality TSCs.

Effective Privacy controls often include policies and procedures for:

Effective Confidentiality controls may vary, but often address:

Choosing the right TSC, or a combination of criteria, is important in mitigating risk while also developing an effective and cost-effective scope for a cloud service provider’s SOC 2 audit.

For more information about Privacy vs. Confidentiality or if you need help preparing for your SOC audit, contact our team.