Learn · SOC Reports
Is a SOC 2 Report
Confidential?
Yes — a SOC 2 report is a restricted-use document. The auditor's report inside it names the specified parties who may use it, and expects them to understand the system, the criteria and the limits of what an examination proves.
Two mechanisms wear the same word. Restricted use is printed in the auditor’s report and defines who the report is for. Confidentiality is contractual, and it is the only one of the two that gives you a remedy if a recipient publishes it.
Plain-English explainer · AT-C 205 examination · Last reviewed August 2026
A SOC 2 report is restricted-use. The closing paragraphs of the independent service auditor’s report state that it is intended solely for the information and use of a named set of parties — the service organization, its user entities, business partners exposed to the system, those parties’ practitioners, prospective user entities and business partners, and regulators — each expected to have sufficient knowledge and understanding of the system and the criteria. The restriction is required by the attestation standards, not a marketing preference. What it does not do is make the report legally confidential in a recipient’s hands: the CPA firm restricts the use of its report and gives you no cause of action against a customer who posts it. That comes from your contract. The question is therefore not “may we share it?” but “under what control?”
What the alert says
Restricted use, precisely
SOC 2 is an attestation by a licensed CPA firm under the AICPA’s attestation standards — AT-C section 105 for concepts common to all attestation engagements, AT-C section 205 for assertion-based examinations. Those standards require an alert restricting use in defined circumstances, including where the criteria are appropriate only for a limited number of parties, and where the report contains information whose use should be restricted to parties with sufficient knowledge of the system. A SOC 2 report is restricted because of what it contains: a description prepared under DC section 200, the control matrix, and the auditor’s tests and results — material only a reader who understands the system and the criteria can interpret. The same criteria, reported without that detail, produce a general-use SOC 3.
The service organization
The party that engaged the CPA firm and signed the assertion.
User entities during the period
Customers who used the system during some or all of the period. Note the tense: one who onboarded after it closed is a prospect, not a user entity.
Business partners exposed to the system
Parties subject to risks arising from their interactions with the system, where the template names them.
Practitioners serving those parties
The customer’s own auditors and advisers — which is why their audit firm may ask you directly.
Prospective user entities and business partners
Named in the standard alert, so a live sales cycle is contemplated. The friction is commercial, not a standards problem.
Regulators
Regulators with a supervisory interest, subject to the same condition.
Each is qualified by the same condition, spelled out in the alert.
01
The nature of the service provided by the service organization.
02
How the system interacts with user entities, partners and subservice organizations.
03
Internal control and its inherent limitations.
04
Complementary user entity and subservice organization controls, and how they interact with the organization’s own.
05
User entity responsibilities, and how they affect its ability to use the service.
06
The applicable trust services criteria.
07
The risks that may threaten the service commitments and system requirements.
Read that as a test applied to the recipient, not as boilerplate. The condition recipients most often fail is the fourth. A procurement analyst working through a SOC 2 without engineering input cannot evaluate a complementary user entity control: they cannot tell whether their own organisation actually enforces the single sign-on configuration, the key rotation or the log review the report assumes of them, so the section gets skimmed or copied into a spreadsheet unread. The practical answer is not to withhold the report but to send it with a one-page CUEC cover note naming which controls the recipient must operate on their side, and where in the report each one sits. It is also the fastest way to shorten the questionnaire that follows.
Two consequences follow, both routinely misstated. First, the restriction binds the report, not you: the attestation literature is explicit that a practitioner is not responsible for controlling a client’s distribution of a restricted-use report. What binds you is the distribution clause in your engagement letter. Second, restricted use is not confidentiality — it creates no obligation on the recipient.
What is actually inside
Why you genuinely should not publish it
Read a full Type 2 report as an attacker or a competitor would.
| Content | Where it sits | Why publishing it hurts |
|---|---|---|
| System component inventory | Section 3 — system description | Infrastructure, software, tooling, sometimes hosting regions — a target map for an attacker. |
| Subservice organization names | Section 3 | Your fourth-party chain in one paragraph — competitor intelligence, and sometimes a problem for the vendors named. |
| Control-by-control detail | Section 4 | Frequencies, thresholds and owners — how long an unauthorised change can sit before anyone looks. |
| Test procedures and sample sizes | Section 4 | Useful to a reviewer, corrosive in public: which populations were sampled, and how thinly. |
| Exceptions and management responses | Sections 4 and 5 | The most quotable material in the report and the easiest to strip of context. |
| Named individuals and roles | Sections 3 and 4 | Social-engineering fuel — and, in several jurisdictions, personal data processed on a basis that never contemplated publication. |
| Incidents disclosed | Section 3 | The description criteria require disclosure of incidents that resulted from control failures or a significant failure to meet service commitments: fine under contract, unhelpful in a search result. |
One internal-consistency point. If the Confidentiality criteria are in scope — C1.1 on identifying and maintaining confidential information, C1.2 on disposing of it — the report is itself confidential information you have undertaken to handle.
Why the posture looks suspicious
Buyers are comparing it with a certificate
Almost nobody arrives at this conversation neutral. The buyer’s folder already holds ISO 27001 certificates from other vendors: one public page each, with a number they can check. Against that, a vendor who will not send its SOC 2 without paper reads as evasive. The comparison is the real source of the friction, and the way out of it is factual rather than rhetorical — the two documents are not the same kind of object.
| ISO 27001 certificate | SOC 2 Type 2 report | |
|---|---|---|
| What the document is | A certification body’s statement that a management system was audited and certified against ISO/IEC 27001:2022. | A licensed CPA firm’s opinion, under AT-C section 205, on whether controls were suitably designed and — in a Type 2 — operated effectively across a period. |
| Length and contents | One page. Scope statement, certificate number, certification body, issue and expiry dates. No controls, no testing, no results. | Typically sixty pages or more. A system description prepared under DC section 200, the full control matrix, the auditor’s procedures, and every exception with management’s response. |
| How it is distributed | Public by design. Commonly posted on a trust page, and often checkable through the certification body’s own directory. | Restricted-use, because of everything in the row above. There is no register to check it against and no public copy to point at. |
That is the honest answer to “what are you hiding?”. A SOC 2 is restricted because it says more, not because it says less. A certificate is a claim you can verify; a SOC 2 report is the working paper behind that kind of claim, and working papers travel differently.
Redaction
Can we redact it?
Almost always no, and the obstacle is ownership rather than sensitivity. The report is the CPA firm’s work product. Your engagement letter governs how it may be distributed, and most firms’ terms prohibit distributing an altered, excerpted or partial copy of it. There is a substantive reason behind the contractual one: the opinion refers to the description and to the tests and results, so an opinion travelling without them is no longer the document the auditor signed. Ask your firm once, get the answer in writing, and record it as a standing position rather than re-litigating it deal by deal.
The real lever is upstream, and it is pulled before issuance rather than after. Section 3 is management’s document — you draft it, the auditor evaluates it — and the drafting choices you make there decide how much you will later wish you could redact. Three of them carry most of the weight. Name roles rather than individuals, so the report says “the security engineering lead” where it would otherwise print a person’s name. Name subservice organizations at the level the description criteria require, without volunteering every downstream tool that happens to touch the system. And describe hosting at the level of architecture rather than inventory — regions and deployment model, not account identifiers and instance families. None of that hides anything a reviewer needs. All of it removes material you would otherwise be sending to every prospect for the next twelve months.
If a recipient still insists on less than the full report, the answer is a different document, not a marker pen. The SOC 3 and the management summary letter are both yours to give. A redacted SOC 2 is neither: it is the auditor’s report with the auditor’s context taken out, which makes it the version most likely to be misread — and, because it looks like a courtesy, the version most likely to be forwarded on.
The four routes
Distribution options by audience
Four mechanisms cover nearly every request: an NDA, an MSA clause, a portal with recorded click-through terms, and a SOC 3 for anything public. Match the mechanism to the audience rather than negotiating each request.
| Audience | What to send | Control required | Notes |
|---|---|---|---|
| Existing customer under an MSA | Full Type 2 report | Confidentiality clause — check it covers assurance material | No separate NDA if the clause is broad enough and in force. |
| Prospect in security review | Full report | Mutual NDA, or a portal with click-through terms | The NDA creates an obligation, not eligibility. |
| Prospect who will not sign | SOC 3, or a summary letter | None — SOC 3 is general-use | Answers “were they examined?”, not “how?”. |
| Anonymous website visitor | SOC 3 on a trust page | None | The only sanctioned route to the open internet. |
| Customer’s auditor or assessor | Full report | Confirm the NDA permits onward disclosure to advisers | Named in the alert; the question is contractual permission. |
| Investor or acquirer | Full report | Data-room NDA plus watermarking | Investors are neither user entities nor business partners, so this sits outside the alert’s wording — a management decision on distribution, logged as one. |
| Insurance underwriter or broker | Full report, or SOC 3 plus a summary | NDA — brokers redistribute by design | A broker shopping five carriers is five distributions. Also outside the alert’s specified parties: a management decision, not a standards-sanctioned release. |
| Vendor-risk exchange or platform | Full report only where you set the rules | Platform terms reviewed; per-recipient approval | Some exchanges are hosting; others are redistribution. Also outside the alert — confirm your position with the CPA firm and log the release. |
Three of those audiences — investors and acquirers, underwriters and brokers, and vendor-risk exchanges — sit outside the alert’s specified parties. None of them is a user entity, a business partner exposed to the system, or a practitioner serving one. Releasing to them is a decision management takes and records, not a release the alert contemplates. Take your CPA firm’s view once, write the position down, and then apply it rather than re-deciding under deal pressure.
The SOC 3 deserves its own note, because most teams discover it too late. It comes from the same examination as the SOC 2 — same period, same criteria, same testing — and contains the auditor’s opinion, management’s assertion and an abbreviated system overview, omitting the description detail, the controls, and the tests and results. With nothing sensitive left in it, it is general-use. In practice SOC 3 reports are issued for a period rather than a point in time, so a SOC 3 will not stand in for a Type 1. Scope it into the engagement letter — adding it later is a separate deliverable with its own fee.
The refusal
When a prospect will not sign an NDA
Name the decision correctly first. Nothing in the standards stops you releasing the report to a prospect without an NDA — prospective user entities are in the alert. The NDA protects you. The question is not “are we allowed?” but “what are we willing to risk?”
Step 1
Establish what they actually need
Most refusals are answered by a narrower ask. A reviewer chasing the CUEC list, scope and opinion type does not need Section 4.
Step 2
Offer the general-use artefacts
The SOC 3, then a management summary letter: CPA firm, period, scope, opinion type. No auditor content beyond that, and no assurance — say so in the letter. Clear the firm’s name with them first; engagement letters often restrict how it may be used outside the report.
Step 3
Offer the low-friction paper
A one-way NDA in the buyer’s favour is easier for their legal team than your mutual template. An addendum to the MSA is easier still — it removes the standalone agreement.
Step 4
Price the exception
If they sign nothing, the decision is commercial: the deal against an uncontrolled copy. Escalate it to whoever owns that trade-off.
Worked scenario — illustrative, not a client engagement
A 60-person payments-infrastructure company holds a Type 2 covering 1 January to 31 December 2025, report dated 20 February 2026. On 4 March a prospect — a US insurance carrier, roughly $180,000 of annual contract value — asks for it. Their policy: no vendor NDAs for diligence materials.
5 March. The vendor sends the SOC 3 and a summary letter: CPA firm, period, categories in scope (Security and Availability), opinion type, and confirmation that the next period began 1 January 2026. 9 March. The carrier’s risk team objects, correctly: the SOC 3 carries no complementary user entity controls, and their standard requires them to record which CUECs they have adopted. 11 March. The vendor offers three routes — a mutual NDA on either template; a confidentiality addendum to the MSA; or a read-only portal session, which their own control rules out because they must retain the artefact. 17 March. Legal approves the addendum: the objection was never confidentiality, it was a standalone agreement. 18 March. The report goes out through the portal, watermarked to one recipient and logged against the addendum.
Thirteen days, no policy exception on either side. Two things made it work: a general-use artefact ready on day one, and reading “we do not sign NDAs” as a statement about a document type. That 18 March release appears twice more on this page — as a row in the register, and as the evidence the service auditor asked for a year later.
Going public
“Can we just post it?”
Not the report — but the useful answer is an architecture rather than a refusal. A trust page has two tiers, and most of the argument about publishing dissolves once you draw the line between them. Build the public tier so that a reviewer who never asks you for anything still gets most of what they came for; build the gated tier so that the one artefact you must control is the only one behind the gate.
Public tier — no gate, no paper
- The current SOC 3, dated, and swapped for the new one on issuance rather than left to age.
- Your ISO 27001 certificate, if you hold one — a one-page public artefact buyers already expect to find.
- A penetration-test attestation letter from the testing firm: scope, dates, methodology and remediation status. Not the test report.
- The subprocessor list, with a stated change-notice window — how many days’ notice before a new subprocessor begins processing customer data.
- A signable DPA template and your standard security exhibit, so procurement can start without asking.
- A status page carrying incident history, with a stated commitment on how quickly it is updated during an incident.
Gated tier — behind a recorded request
- The full Type 2 report for the current period.
- The complementary user entity controls, pulled out as a one-page matrix a reviewer can action — the single most requested extract.
- The penetration-test report itself.
- The current bridge letter, where the period end is now some months behind you.
- Pre-completed questionnaire responses — CAIQ, SIG, or your own standard answer set.
The gate is where trust pages usually fail, because a gate that records nothing is just a download button with a form in front of it. Four mechanics are worth specifying before anyone builds one.
01
Verify a business email domain rather than accepting free-mail addresses. Without it, the gate is a download button with extra steps.
02
Watermark per recipient at generation time, not once at upload — two copies loose on the internet should be distinguishable from each other.
03
Expire the link on a fixed window and support revocation, so supersession and contract termination have a mechanism behind them.
04
Store the accepted terms version identifier against the release row. Live terms with no version history prove nothing a year later, which is exactly when you will need them.
One badge question comes up on every build. The AICPA SOC logo can sit on the public tier: service organizations obtain it through their CPA firm and use it under the AICPA’s logo usage terms, which lets you advertise that an examination happened without distributing anything from it. Check the current terms with your firm rather than copying another vendor’s placement. Whatever the terms allow, keep the surrounding copy accurate — a SOC 2 is an attestation, not a certification, so nothing on the page should read as “SOC 2 certified” or imply a certificate exists.
Evidence
What the CPA firm actually requests
Distribution control is not a criterion in itself. It becomes testable when you write it into your control set — against C1.1 and C1.2 where the Confidentiality category is in scope, and otherwise against the common criterion on restricting the transmission, movement and removal of information (CC6.7), or the one on communicating with external parties (CC2.3). The service auditor then tests it like any other control: define the population, prove it is complete, sample, inspect.
| Artefact | Population | What is requested | Commonly rejected |
|---|---|---|---|
| Report release register | Every release in the period, every channel | A system-generated export — portal or DMS download log — with query parameters visible, plus why that channel is the only one. | A spreadsheet built the week before fieldwork, with no evidence of when rows were added. |
| Executed NDAs | One per recipient not covered by an MSA clause | The executed PDF showing both signatures and dates, matched to the release. | An NDA countersigned after the report went out, or undated. |
| Portal access grants | Every grant and revocation in the period, not current access | A period-scoped export: requester, company, approver, timestamp, version, expiry. | A screenshot of today’s access list — current state does not evidence March. |
| Click-through acceptances | Every acceptance replacing a signed NDA | The acceptance record joined to a versioned copy of the terms in force then. | Terms on a live page with no version history — nobody can prove what they said. |
| Disposal and revocation | Every disposal event in scope | Certificates of destruction, ticketed revocations, or logs showing link expiry, where disposal of confidential information is in scope. | An assertion that access “expires automatically” with no configuration evidence. |
On sample sizes: no AICPA standard fixes them. Service auditors size samples by control frequency and assessed risk, drawing on the AICPA’s audit sampling guidance; the bands firms work to are convention, not rule — one instance for an annual control, two for quarterly, a handful for monthly, more for daily. Report releases are an ad-hoc population: release it eighteen times and expect all eighteen inspected, not sampled.
What catches teams out is completeness. A list you compiled evidences every release you remembered, not every release. What satisfies a reviewer is an argument from design: the report exists in one system, that system logs every download, and no other copy is reachable — so its log is the population.
Concretely, take the 18 March release from the scenario above. At the following year’s examination the service auditor asked for three things and then joined them: the portal’s download-log entry for that report version, showing recipient identity, timestamp and watermark identifier, exported with the query visible rather than screenshotted; the executed MSA addendum as a PDF with both signature dates legible; and the register row itself. The join is the test, and the dates are the point of it. The addendum was executed on 17 March and the release ran on 18 March. Had the countersignature landed on 20 March instead, the same paperwork would have failed: the release would have gone out with no legal basis in force at the moment it went out, which is the thing being tested.
It is worth knowing what happens when that join fails, because almost nobody rehearses it. If an inspected release has no NDA, no MSA clause and no click-through record behind it, the service auditor records a deviation. Whether the deviation is reported as an exception in Section 4 depends on how your control is written and how the firm assesses its severity against the criterion; a single administrative miss on a distribution control you imposed on yourself does not normally modify the opinion. What it does do is print. The exception text, and management’s response beside it, then sit in the report you send to every customer, prospect and regulator for the next twelve months, with no erratum available. The drafting implication runs backwards from that. Write the control narrowly enough to be satisfiable — reports are released only through the distribution portal, which records the legal basis, approver and watermark identifier for each release — rather than broadly, as in “all report releases are approved.” The broad version turns every emailed copy in the period into a deviation. The narrow version makes the portal the control, and the portal keeps its own evidence.
Designing that control and assembling its evidence is readiness work TCSA does. The examination and the opinion belong to the independent CPA firm. TCSA coordinates the engagement; it never audits, certifies or signs the report.
Record-keeping
The release register
Eight fields, one row per release. It answers three questions: who holds a copy when the next report supersedes it, what the legal basis was if one leaks, and how the control operated.
01
Release date and channel.
02
Recipient organisation and named individual.
03
Legal basis: MSA clause, NDA date, or click-through acceptance ID and terms version.
04
Report version and period, plus the watermark identifier.
05
Approver — a named person, not a team inbox.
06
Purpose: deal, renewal, audit support, underwriting, diligence.
07
Expiry or refresh action, so the recipient is re-served on the next report.
08
Revocation status, and how it was evidenced.
Abstract fields are easy to agree with and hard to fill in, so here is the actual row for the 18 March release in the scenario above.
| Field | Value recorded |
|---|---|
| Release date and channel | 18 March 2026 · distribution portal — the only release channel, because the file does not exist anywhere a person could attach it to an email. |
| Recipient organisation and individual | The carrier, by legal entity name · one named third-party-risk reviewer. Not a shared mailbox, because a mailbox cannot be revoked. |
| Legal basis | Confidentiality addendum to the MSA, executed 17 March 2026. Both signature dates visible; the executed PDF is stored against this row. |
| Report version and watermark | FY2025 Type 2, 1 January – 31 December 2025, report dated 20 February 2026 · per-recipient watermark identifier printed on every page. |
| Approver | The named security lead who approved the release, captured by the portal at approval time rather than recalled afterwards. |
| Purpose | New business — security review on a deal of roughly $180,000 annual contract value. |
| Expiry or refresh action | Link expires on a fixed window; the recipient is re-served automatically when the FY2026 report is issued. |
| Revocation status | Not revoked. Triggers recorded on the row: supersession by the next report, or termination of the contract. |
Re-serve current recipients on each new report, so nobody relies on a stale report you could have replaced. A bridge letter belongs in the register too — management’s document, so no alert of its own, but it travels under the same terms.
Where this gets contested
Edge cases worth a written rule
The ordinary cases resolve themselves. These arrive on a Friday afternoon with a deal attached, and they are the ones worth deciding once, in writing, while nobody is waiting.
They want it uploaded into their risk platform
Their platform, their retention rules, their sharing settings — and, sometimes, their other tenants. Ask three questions in writing before uploading: how long the artefact is retained after the assessment closes, whether it is visible to anyone outside the assessing organisation, and whether the platform reuses it to answer other buyers’ assessments. Some exchanges are hosting on the buyer’s behalf; others are a distribution business whose product is your report. Where the answers are unclear or the terms reserve broad rights, host it yourself and give them a per-recipient link instead.
A public-sector RFP requires it as an attachment
Documents submitted into government procurement can, in some jurisdictions, become subject to public-records or freedom-of-information disclosure — a route by which a restricted report becomes genuinely public months later, with no leak and no bad actor anywhere in the story. Submit the SOC 3 where the tender permits it. Where the tender insists on the full report, use the process’s confidential-attachment or commercially-sensitive-material route, mark the document accordingly, and have counsel confirm what that marking actually does in that jurisdiction rather than assuming it does what it sounds like.
A customer asks for your vendor’s SOC 2
You may not redistribute it. You are a specified party of your subservice organization’s report; your customer is not, and forwarding it breaches the alert on that report and, usually, your contract with that vendor. Answer with what you do own: that you obtain and review the report annually, the scope and opinion it carried, when you last reviewed it, and how you have implemented the complementary user entity controls it places on you. That last part is what a competent reviewer is actually testing, and it is the part only you can answer.
A customer quotes an exception publicly
Your NDA is the instrument here, which is why it matters more than the alert — restricted use gives you no remedy against whoever published the quote. Move on two tracks at once. Commercially: reply with the context the quote removed — the criterion, the population size, how many instances were affected, management’s response, and whether the opinion was unmodified. Internally: log it as a failure of the distribution control with the release row attached, because the next examination will ask what you did about it and “nothing” is a poor answer.
Sales wants to attach it to outbound email
The most common leak is internal and almost never malicious — it is a rep with a copy in a folder, sending it to move a deal a day faster. Policy does not fix this; architecture does. Take the file out of shared drives, mailboxes and the CRM, and make the portal the only place it exists. If the only reachable copy sits behind an approval step, over-sharing becomes impossible rather than discouraged, and your release log becomes complete by design — which is the property the service auditor is really testing.
A deal needs the report before it is issued
Common, and the place teams improvise worst. You may share your readiness position and the observation-window dates. You may not share a draft carrying the CPA firm’s name, letterhead or draft opinion — no reputable firm will permit it, and a draft opinion in circulation is a serious problem for them. The sanctioned substitute is a management letter on your own paper: the firm engaged, the period start date, the categories in scope, the expected issuance date, and an explicit line that it conveys no assurance. Then commit to serving the report on issuance, and register the recipient so the commitment is kept.
Legal process compels production
A subpoena, a discovery request or a regulator’s demand overrides your NDA, and most NDAs already carry the carve-out. Sequence matters more than outcome. Notify your CPA firm, because it is their report; notify counsel for any counterparty whose confidentiality obligations are touched; ask counsel whether a protective order or a confidentiality designation is available to limit onward use; and produce what the order requires and nothing beyond it. Then log it in the register as a compelled release, with the legal-basis field naming the instrument rather than pointing at an NDA that did not apply.
The buyer wants the period covering their contract, not the latest report
Regulated buyers evidencing their own vendor review often need the report covering the months they were actually being served, not your newest one. That means keeping superseded reports retrievable rather than destroying them the moment a new one is issued, and pairing the historical report with a bridge letter covering the gap to the current period. Both travel under the same terms as the current report and both belong in the register. If your retention schedule quietly deletes old reports on supersession, this is the request that will find it.
Two of those — the pre-issuance request and the request for a historical period — are really questions about timing rather than confidentiality. Both are covered in more detail in what to tell customers while the audit is in progress and in how long a SOC 2 report stays current.
Objection handling
What the buyer’s security team says back
None of these are unreasonable. Answers that work in enterprise sales concede the reasonable part first.
“Every other vendor just emails it to us.”
Most do, and it still goes out under something — their release register will show an MSA clause or a portal acceptance behind it, because their own auditor tests that register. Ours does the same. So we are not really asking you to sign a new agreement; we are asking which instrument already covers this: your MSA confidentiality clause, an addendum to it, or an NDA on either template. Whichever is fastest for your legal team is fine with us.
“Our policy prohibits signing NDAs for diligence documents.”
Then we will not ask you to. Two routes work without one. A confidentiality addendum inside the MSA you would be signing anyway — which is usually what the policy is protecting against, a standalone agreement rather than the obligation itself. Or the SOC 3, which is general-use and needs no paper at all. Tell us which questions you have to close and we will say plainly whether the SOC 3 closes them, rather than sending it and letting you find out.
“If you have nothing to hide, why is it confidential?”
Because of what is in it, not what is missing from it. The report carries our component inventory, our subservice organizations, our control frequencies and the auditor’s sampling — publishing that weakens the controls it describes. Note also that the restriction is printed in the auditor’s own report; we did not add it. Compare it with an ISO 27001 certificate: one public page, no controls, no test results. A SOC 2 is the working paper behind that kind of claim, which is why it travels differently.
“Your report is ten months old.”
Fair, and the answer has two halves. The report covers the period stated on its face; the next period is already running and the next examination is scheduled — we can tell you the dates. For the gap between period end and today, we can provide a bridge letter from management stating that no material changes to the control environment have occurred since. Be clear on what that is: management’s representation, not the auditor’s. It extends context, not assurance.
“We need it to cover our region, or the entity we contract with.”
The report covers a system, not a customer and not a geography, so your answer sits in two specific places. Section 3 describes the system boundary — infrastructure, services and locations in scope — and that is the passage to read against your requirement. Separately, management’s assertion and the auditor’s opinion name the legal entity examined; check that it is the entity on your contract. If either does not line up, that is a genuine scope gap and worth raising with us directly.
“We must retain a copy — a portal link will not do.”
Standard for regulated buyers who have to evidence their own vendor review to their own examiner, and we do not argue with it. Take the copy under the NDA or the MSA clause, with a per-recipient watermark on every page. In return we ask for two things on the record: a retention period, and a named custodian. That is so we know where the copy sits when the next report supersedes this one, and who to serve the replacement to.
“Remove the watermark.”
The watermark is what makes a leak traceable, and traceability is the reason controlled distribution means anything at all — without it, a copy on the internet is a copy from nobody in particular and the control is decorative. If it is breaking a document-parsing tool or an accessibility requirement, tell us which, and we will move it to the page footer or reduce it to a plain identifier. That keeps the property we need and removes the problem you have.
“A SOC 3 tells us nothing.”
It tells you four things: the CPA firm, the period examined, the categories in scope and the opinion reached. What it omits is the description detail, the control matrix and the test results. So if your question is “were they examined, by whom, against what, and with what result?”, it answers it completely. If your question is about our complementary user entity controls or about a specific exception, it does not — and that is precisely the argument for putting paper in place.
Frequently Asked Questions
Is a SOC 2 report confidential?
It is restricted-use, which is related but not identical. The independent service auditor’s report states that it is intended solely for the information and use of specified parties — the service organization, its user entities during the period, business partners exposed to the system, those parties’ practitioners, prospective user entities and business partners, and regulators — who have sufficient knowledge of the system and the criteria. Enforceable confidentiality, and any remedy if a recipient publishes it, comes from your NDA rather than from the alert.
Do I have to make customers sign an NDA before sending our SOC 2?
No standard requires it. It is near-universal market practice, and it serves you rather than the auditor: the restricted-use alert creates no obligation on the recipient, so without a contract you have no remedy if the report is forwarded, uploaded or quoted. Many organisations skip a standalone NDA where the executed MSA already carries a confidentiality clause broad enough to cover third-party assurance material — but read the clause before relying on it, because some are drafted narrowly around “Customer Data” and do not reach a document you provide about yourself. Whichever instrument applies, record which one it was against that release; the record is what your own service auditor tests later.
Can I share my SOC 2 report with a prospect who is not yet a customer?
Yes. The standard restricted-use wording names prospective user entities and business partners among the specified parties, so releasing the report during a sales cycle is contemplated rather than exceptional. The qualifying condition still applies: the reader should have sufficient knowledge and understanding of the system, the criteria and the limitations of internal control. Send it under an NDA or through a portal that records acceptance, and log the release.
Can I publish our SOC 2 report on our website?
You should not. It contains your system component inventory, subservice organization names, control frequencies, the auditor’s test procedures and sample sizes, and every exception with management’s response — material that helps an attacker and misleads a casual reader. It also contradicts the restriction printed in your own auditor’s report. The sanctioned public alternative is SOC 3, produced from the same examination with the description detail and test results removed.
A prospect refuses to sign an NDA. What should I send them?
Work down a ladder rather than refusing outright. Establish what they actually need — many reviewers want the scope, the period, the opinion type and the CUEC list, not the full report. Offer the general-use artefacts next: the SOC 3, and a management summary letter stating the CPA firm, period, scope and opinion type, noting that it carries no assurance. Then offer easier paper: their one-way NDA, or a confidentiality addendum to the MSA.
Can we send just the auditor’s opinion page instead of the whole report?
Some organisations do, and it is a judgement call rather than a rule. It keeps the system description and the control matrix out of circulation, and the restricted-use alert sits in that section, so the restriction travels with the excerpt. The objections are that an opinion divorced from its scope is easy to misread, and that CPA firms differ on how comfortable they are with excerpting, since the report is their work product. Ask your firm once and adopt a standing position.
Can we redact parts of our SOC 2 report before sending it?
Usually not: the obstacle is ownership rather than sensitivity. The report is the CPA firm’s work product, and most engagement letters restrict distributing an altered, excerpted or partial copy — ask your firm once and record the answer as a standing position. The effective lever sits upstream. Section 3 is management’s document, so choices made before issuance do the work: naming roles rather than individuals, describing hosting at the level of architecture rather than inventory, and naming subservice organizations at the level the description criteria require. Each removes material you would otherwise want redacted. If a recipient needs less than the full report, send a different document — the SOC 3 or a management summary letter — rather than an edited one.
Can we share our SOC 2 report before it has been issued?
Not the report, and not a draft carrying the CPA firm’s name, letterhead or draft opinion; no reputable firm permits that, and a draft opinion in circulation is a serious problem for them. What you can share is your own position: that the firm is engaged, that the observation period runs from a stated date, which categories are in scope, and when issuance is expected. Put it in a management letter on your own paper with an explicit line that it conveys no assurance, and clear the firm’s name with the firm before it appears anywhere. Then commit to serving the report on issuance and add the recipient to your release register, so the commitment survives the deal closing.
Can a customer share our SOC 2 report with their own auditor?
Usually yes on the standards side — practitioners providing services to user entities appear in the standard restricted-use wording, which is why a customer’s audit firm may request it directly. The real constraint is contractual. Check whether your NDA carries a permitted-recipients clause reaching the counterparty’s professional advisers: language along the lines of disclosure to its auditors, accountants and legal advisers who are bound by equivalent obligations of confidentiality. Many templates are silent, and silence is not permission. Where it is silent, a one-line acknowledgement from the customer naming the firm is usually quicker than amending the agreement. Either way, log the auditor as a recipient in your own register so you know where copies sit.
How long should we keep records of who received the report?
At least through the next examination covering the period in which the release happened, and in practice through your general contract-retention period, since the register is the evidence behind any confidentiality claim you make later. Keep the release date and channel, the recipient organisation and individual, the legal basis with its reference and date, the report version and watermark identifier, the approver, the purpose, and the revocation status. Keep the underlying artefacts beside it too — the executed NDA or addendum, the click-through acceptance record, and a versioned copy of the terms in force at the time. The register alone is an assertion; the artefacts are what turn it into evidence.
Related reading: SOC 3 explained, types of SOC reports, how to read a SOC 2 report, CUECs and CSOCs, opinions and exceptions, subservice organizations, SOC 2 and security questionnaires, and the SOC 2 hub.
Written By Expert Auditors
Keep Exploring
Related Reading
Does SOC 2 Replace Security Questionnaires?
What the report answers, what it never could, and how to use it to compress a questionnaire.
Read moreSOC 3 Report
The public-facing version of a SOC 2 report, for marketing.
Read moreHow to Read a SOC 2 Report
All five sections annotated, an 8-step reviewer checklist, and the red flags.
Read moreSOC 2 for Enterprise Sales
What a report de-blocks in security reviews — and what it will not do.
Read moreSOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreTypes of SOC Reports
SOC 1 vs SOC 2 vs SOC 3 — audiences, criteria, and which one buyers ask for.
Read moreGet in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours