“Why can’t I share my SOC 2 report?” It’s a question that gets asked a lot, and given the time and expense of acquiring a SOC 2 report, it’s understandable, but you actually can share it, but it 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, and as such, it’s not to be made publicly available. 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 has proprietary information. From a process and security stance, it makes business sense not to publish this information for your competitors or others 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, you’ll notice a specific process they make you go through 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 and understanding to understand the report.
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.7
- 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 freely distributed.
In contrast to the hoops you would have to go through to obtain Amazon and Microsoft’s SOC 2 reports, both publicly share their SOC 3 reports.
I hope this provides insight into why SOC 2 reports are restricted use and other alternatives if you would like a more general document. For more information, check out the AICPA’s guidance on the different SOC reports available, and if you’re considering a SOC 2 report, don’t hesitate to reach out to our team or visit our SOC 2 services page.
