Sharing SOC 2
Handing out your SOC 2 report without losing track of it.
Almost every security review ends with the same request: send us your SOC 2. The report was written for a defined circle of readers, and three separate things decide who enters that circle. The auditor writes a use restriction into the report, you agree confidentiality terms with each reader, and you run a release process. With all three in place, sharing becomes routine.
Back to SOC 2 services01 · Three layers
Three things that govern who reads it
One comes from the auditor. Two come from you.
- Layer 1The auditor's restrictionA paragraph in the report limits its use to readers expected to understand the system: your management, customers and prospective customers, business partners, and the practitioners who advise them.
- Layer 2Your confidentiality termsThe restriction says what the report is for. It does not bind anyone to secrecy. That comes from an NDA, a confidentiality clause in the customer contract, or click-through terms on a trust portal.
- Layer 3Your release processWho may approve a release, how the file is delivered, and a record of every copy. Without it, the first two layers are hard to enforce.
A reader who lacks the background could take a sampled deviation for a breach, or a carved-out vendor for a gap. That risk of misreading, more than secrecy, is why the AICPA aims a SOC 2 at specified users rather than the public.
02 · Requests, sorted
Who is asking, and how to answer
Most requests fall into a handful of patterns.
| Who is asking | Usual route | Watch for |
|---|---|---|
| A current customer | Send under the contract's confidentiality clause, or through your trust portal | Check that the clause really covers audit reports |
| A prospect in an active deal | Mutual NDA or portal terms, then the full report | Requests from people with no visible role in the evaluation |
| A customer's own auditor | Through the customer, on the customer's terms | Confirm whom the auditor is working for |
| An investor or acquirer in diligence | Ask the CPA firm whether the reader fits the restriction; use a diligence NDA | Data-room copies that outlive the deal |
| A visitor to your website | A line saying the report is available on request, or a SOC 3 | Never a downloadable SOC 2 |
| A researcher or journalist | Your public security page, and a SOC 3 if you have one | No duty to release the full report |
03 · Handling mistakes
Five ways a shared report goes wrong
Each one is easy to avoid once you know it exists.
- Posting the PDF publicly. The description lists systems, vendors and control frequencies, and the tests show where samples failed. That map should not sit one search away from an attacker.
- Editing or blacking out pages. The report is issued under the CPA firm's opinion, so altering it misstates it. Raise sensitive content with the firm before the report is issued.
- Sending extracts. A page lifted from the testing section loses the opinion, the carve-outs and the complementary controls around it. Share all of it or none.
- Circulating a draft. Drafts can change before the firm signs. Only the final, signed report should leave the company.
- Letting an ageing report travel alone. Once the period end is months behind, pair the report with a bridge letter, which has its own page.
04 · The public option
When a SOC 3 is the better thing to hand over
A general-use report that leaves out the detail.
A SOC 3 reports on the Trust Services Criteria for the same system but is written for anyone to read. It carries the auditor's opinion, management's assertion and a short account of the system, and omits the test procedures and their results. That makes it safe for a website and thin for a serious reviewer, who will want the SOC 2 under terms anyway.
SOC 2
- Detailed system description
- Tests and results, in a Type 2
- Specified users, under your terms
SOC 3
- Brief overview of the system
- Opinion without the test detail
- General use, including your website
CPA firms commonly issue a SOC 3 alongside a Type 2 when it is planned into the engagement letter, so decide early.
05 · Release log
A release log your auditor can test
If your description includes a control over sharing, it gets sampled like any other.
- Requester and organisation. A named person at a named company, not a shared inbox.
- Basis for release. Customer contract, signed NDA or portal acceptance, with the record attached.
- Approver. The person who said yes, in the role your policy names.
- Version sent. Which report and period, and whether a bridge letter went with it.
- Delivery method. A portal with watermarking or an expiring link, rather than an email attachment.
Sources: AICPA guide, SOC 2 Reporting on an Examination of Controls at a Service Organization (restricted-use alert and report contents); AICPA attestation standards, AT-C section 205, examination engagements; AICPA SOC suite of services overview (SOC 3 as a general-use report).
Questions about handing it over
Can a prospect forward our report to their consultant?
Only if your terms allow it.
Their adviser may well fit the restriction as a practitioner serving the prospect. Whether onward sharing is allowed is set by your NDA, so say so in the terms.
Can we put the SOC 2 behind a login on our website?
Yes, if access comes with terms.
A trust portal that asks visitors to register, accept terms and leaves a download log is a common way to share. A login with no terms is a public link with an extra step.
Must the CPA firm approve each recipient?
No, but ask about unusual readers.
The restriction describes classes of reader. For ordinary customers and prospects, the decision is yours. For anyone outside those classes, check with the firm first.
How long can we keep sending the same report?
Until buyers stop accepting its age.
No rule ends a report's usefulness on a fixed date. Buyers decide what age they accept, which the report validity page covers.
Share the report on your terms.
A SOC 2 readiness assessment from Auditify covers the trust page, the release process and, where it suits you, planning for a SOC 3.