How to share a SOC 2 report safely
Emailing your SOC 2 report as an attachment is how most companies start, and it is the habit your own auditor and your largest customer will eventually ask about.
Share a SOC 2 report through one controlled channel: a trust centre or a request form that collects a signed NDA, checks the requester is a customer or an active prospect, releases the report, and logs who received which version. A SOC 2 report is a restricted-use document. The auditor's report states it is intended for you and for user entities and prospects with sufficient knowledge to understand it, which is why it is not published openly.
Why can't we just publish our SOC 2 report?
The report describes your system and your controls in detail, including where exceptions were found. That detail is useful to a customer's reviewer and to an attacker. The AICPA's reporting framework restricts its use for that reason. If you want a document you can publish freely, a SOC 3 report is the general-use version, which your auditor can issue alongside the SOC 2 for an added fee.
How do we share a SOC 2 report?
- Decide who may receive it. The common rule is existing customers and prospects with an open opportunity in your CRM. Anyone else goes to an approver.
- Put an NDA in front of it. A short click-through NDA on your own template, signed before release. Enterprise buyers often have their own NDA with you already; accept that where it covers security documents.
- Release it through one channel. A trust centre, or a request form that routes to one person. Ad hoc email attachments are the source of every "who has our report" question.
- Log every release. Requester, company, date, report period and version, and who approved it.
- Watermark and expire. A watermark with the recipient's name discourages forwarding. Expiring links stop a two-year-old report circulating.
Send the current period only
A buyer reviewing you in November does not want a report whose period ended last December with no bridge letter. Keep one current report in the library, add a bridge letter for the gap, and retire the old one.
What should go alongside the report?
- A bridge letter covering the time since the report period ended.
- Your management response to any exceptions, so the reviewer reads your answer next to the finding.
- A complementary user entity controls summary, the controls the report assumes your customer runs, in plain language.
- The subprocessor list, because the report may carve out subservice organizations the reviewer will ask about.
What record do we need to keep?
Keep a log that answers "who has our report" in one lookup: name, company, date, document and version, NDA reference and approver. Your auditor may ask how restricted documents are controlled, and a large customer's contract may limit onward sharing. A trust centre platform or a managed service produces this log automatically. A spreadsheet works at low volume if one person owns it.
Common questions
Do we need an NDA to share our SOC 2 report?
It is the normal practice and the safest one. The report is restricted use, and an NDA documents that the recipient accepts that restriction. An existing master agreement with confidentiality terms covering security documents can serve instead.
Can a prospect share our SOC 2 report with their own auditor?
Usually yes, when their auditor is assessing their use of your service. Your NDA should allow sharing with the recipient's auditors and advisers under the same confidentiality terms, and say so plainly.
What is the difference between SOC 2 and SOC 3 for sharing?
A SOC 2 report is detailed and restricted use. A SOC 3 report is a short general-use summary of the same examination, suitable for publishing on your trust centre without an NDA. Most enterprise reviewers still ask for the SOC 2.
Set up controlled report sharing
A trust centre with logged NDA requests, set up or run for you.
Get matched