“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.
SOC 2 Is a Restricted Use Report
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:
- The nature of the service provided by the service organization.
- How the service organization’s system interacts with user entities, subservice organizations, and other parties.
- Internal control and its limitations.
- Complementary user entity controls and complementary subservice organization controls and how those controls interact with the controls at the service organization to achieve the service organization’s service commitments and system requirements.
- User entity responsibilities and how they may affect the user entity’s ability to effectively use the service organization’s services.
- The applicable trust services criteria.
- The risks that may threaten the achievement of the service organization’s service commitments and system requirements and how controls address those risks.
This report is not intended to be and should not be used by anyone other than these specified parties.
The Difference Between SOC 2 vs. SOC 3
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.
