How do you share a SOC 2 report with prospects without breaching its restrictions?
A prospect who needs proof before signing should receive the full SOC 2 report only after signing an NDA, because use of a SOC 2 report is generally restricted. The full report goes to identified recipients, and a SOC 3 report is the document you can publish for anyone to read. The intended users of a SOC 2 are agreed between the service organization and its management, not chosen by the sales team on the day a deal is closing. That means the route depends on who is asking, what kind of report they need, and what your customer and partner agreements already allow.
The split of roles matters here. The organization decides who receives its report and under what terms, and it owns the distribution list. The CPA firm issues the report and sets the restrictions printed on it, so the organization cannot widen the audience by relabeling the document. Before sending anything, confirm with your auditor which parties are named as intended users and whether your own contracts promise customers a copy. Keep a log of each recipient, the date and the NDA on file, so you can show who held the report if a customer or regulator asks later.
A practical check is to ask whether the prospect is a customer's own auditor, a regulator, or a commercial buyer doing vendor due diligence. A buyer's security team reviewing a Type 2 report usually needs the full document under NDA, while a prospect that only wants assurance of a general nature may be satisfied by the SOC 3 report and a trust page. If the prospect asks for the full report but is not one of the intended users, confirm the position with the CPA firm and your counsel before sending it. Discuss the choice early with your auditor so that the report and the sharing process are settled before the first sales call.
Gated trust pages and public SOC 3 pages: what each should hold
A trust center gives prospects a clear path from public assurance to restricted evidence. Each component answers a different question at a different stage of the buying process, so each has a different audience and a different level of access.
Public SOC 3 download
A SOC 3 report is the item that belongs on a public page. It covers the same trust services categories as a SOC 2 in less detail, and the AICPA treats it as a general use report that can be freely distributed. Post the current SOC 3 only, confirm its period and scope match the service you sell, and check that the auditor's name and opinion appear in the document. Do not describe it as a substitute for the SOC 2 report, because it often lacks the control-level detail a security reviewer will ask for.
Gated SOC 2 report area
The full SOC 2 report sits behind a click-through NDA because its use is generally restricted to customers and other intended recipients named with management. The gate should record who accepted the agreement, when, and for which report version, so you can show the intended users if asked. Serve the report from the gate only, never as a public file link. Ask your auditor whether the NDA wording matches the intended-user language in your engagement.
Bridge letters
A bridge letter covers the gap between the end of a Type 2 period and the date a buyer is reviewing the report. Management writes it, and it states whether controls operated as described during the gap. Keep a dated, signed letter in the gated area alongside the report, and make clear it is management's statement rather than an auditor's opinion. Buyers often request one when the period ended several months earlier.
Penetration test summaries
A penetration test summary shows that security testing happened, who performed it, when, and what categories of findings were closed. Share a summary in the gated area rather than the full report, which can reveal exploitable weaknesses. Confirm the tester's independence, the test date and the retest status before you share anything. This item supports the security criteria in the report, but it does not replace the SOC 2 opinion.
Questionnaire contact route
Prospects who cannot find an answer on the page need a named route to a person who can respond, such as a security or compliance mailbox. Track requests so answers stay consistent across buyers, and route anything about the report's scope or exceptions to the people who own the control environment. Keep the contact visible on both the public and gated pages, and state a response expectation you can meet.
Keep off public pages
Nothing that reveals the full control set belongs on a public page. Keep the SOC 2 report, control matrices, system descriptions, exceptions, network diagrams, architecture details, employee names, and unredacted penetration test results out of public view. Also avoid any claim that the company is SOC 2 certified or that the AICPA approved the organization, because a SOC 2 is an examination report rather than a certificate. Review the page against the AICPA's logo guidelines before using the SOC logo.
Who may receive the full report: customers, auditors, regulators and prospects
A SOC 2 report is generally restricted in use, so the service organization decides who receives it through its contracts and its report distribution process. Customers that already buy the service are usually the intended users, and the right to receive the report is normally written into the master agreement, a security addendum or the order form. The route is set by the contract, not by the customer's request alone, so the first step is to check what your agreements already promise.
- Contract clauses: Look for a clause that commits you to provide the most recent SOC 2 report on request and states how often it will be refreshed.
- Named users: The intended users are identified in agreement with management, so confirm that the customer's organization is among them before sending.
- Secure delivery: Share the report through a controlled channel, such as a portal or a time-limited link, and keep a record of who received which version.
- Bridge letters: When the report period has ended and a newer one is not yet issued, the contract may require a bridge letter; confirm what your agreement specifies.
- Updates: Track each customer's report version so that a superseded report is not treated as current.
Before sending, check that the requesting party is the contracted customer and that your agreement permits onward sharing with its own auditors or advisers.
Banks and other regulated customers must oversee their third parties, and a SOC 2 report is one of the main pieces of evidence they use. The interagency guidance on third-party relationships published in the Federal Register on June 9, 2023 (88 FR 37920) describes how banking organizations should assess and monitor the risk of their vendors, and the 2026 proposals published on September 15, 2026 (91 FR 58438 and 91 FR 58536) address third-party risk management for community banking organizations and more broadly. Regulators and bank risk teams are generally intended recipients, but the right to receive the report still depends on the agreement with you.
- Written intended users: Confirm that the bank or regulator is named in the agreed list of intended users before providing the report.
- Regulator requests: Ask your legal and compliance team how to respond when a supervisor requests a report directly, since the request may need to go through the customer.
- Due diligence packs: Banks often ask for the report together with a bridge letter, exception summary and complementary user entity controls list; prepare these as a set.
- Proposal status: Confirm the current status of the 2026 proposals with your customer's compliance team, since they are proposals and their final form may differ.
- Scope questions: Expect questions on subservice organizations and the categories covered, and answer from the report rather than from memory.
Check the customer's own third-party risk policy, which often sets the documents and frequency it expects.
A prospect has no contract with you yet, so it is not an intended user and should not receive the full restricted-use report by default. The usual approach is to require a signed non-disclosure agreement before releasing the report, and to limit access to the individuals who are evaluating the service. The NDA should name the report, state that it is confidential, limit use to the evaluation, and prohibit onward distribution. Your counsel should draft or approve the terms.
- Pre-release review: Confirm the prospect's legal entity and signatory before sharing, and do not send the report to a personal address.
- Watermarking and tracking: Some teams add the recipient's name and a date to the document and track downloads, which helps trace copies.
- Gated trust pages: A trust page can publish general information while the full report sits behind an NDA gate.
- Public alternative: Where the prospect only needs assurance that a SOC 2 exists, a SOC 3 report can be shared more widely; see the rest of this page.
- Expiry: Set a time limit on access and revoke it when the evaluation ends.
Check that the NDA allows the prospect's advisers to view the report if your agreement permits that, and record every disclosure.
Other parties, such as the customer's external auditor, a consultant or an insurer, may have a legitimate need to see the report, but their need does not automatically make them intended users. The test is whether the recipient fits the intended users agreed with management and set out in the report and engagement documents. A customer's own auditor may fall within the intended users when the agreement says so, while a general consultant or a marketing agency usually does not. Where the fit is unclear, the answer is to ask before sending.
- Customer auditors: Confirm in writing that the customer's auditor is covered by the agreement and the report's use restriction.
- Consultants and vendors: Share only the parts they need, or ask whether a SOC 3 or a summary letter will meet their purpose.
- Insurers and brokers: These recipients often ask for control summaries; check that the answer does not disclose more than the agreement allows.
- Contract changes: Update the intended users list when a new category of recipient is agreed.
- Record keeping: Keep a log of who requested the report, who approved it and what version was sent.
Before releasing the report to any party outside the contract, ask your CPA firm or counsel whether the recipient fits the intended users in your engagement.
A SOC 3 report is the general use version. The AICPA describes SOC 3 reports as covering the same categories as SOC 2 in less detail, and they can be freely distributed or posted on a website. That makes a SOC 3 the right answer for a public audience, while the full SOC 2 report remains restricted. The trade-off is that a SOC 3 usually lacks the control-level detail that a reviewing customer needs, so it does not replace the full report for due diligence.
- Public posting: Post a SOC 3 only when it is the current version and covers the scope you actually offer.
- Period check: Confirm the period and date on the SOC 3 before publishing, since older versions remain in circulation.
- Full report boundary: Do not post or email the SOC 2 report publicly, even as a link that appears unprotected.
- Logo rules: A SOC logo on a website must follow the AICPA logo guidelines, which should be read before use.
- Cloud examples: Some large providers publish SOC 3 reports publicly while keeping SOC 2 reports behind an NDA; the same split applies to your own service.
Before publishing, confirm with your CPA firm that the SOC 3 is the current issued report and that the scope described matches your marketing claims.
Can you use the AICPA SOC logo on your website?
Yes, but only if your organization holds a qualifying report. The AICPA's SOC for Service Organizations logo may be used by any service organization that has received a SOC 1, SOC 2 or SOC 3 report from a licensed CPA or a non-US equivalent. A SOC 2 report that is still in the planning stage, or a readiness assessment, does not qualify. Before you download or place the logo on a trust page, read the AICPA's logo guidelines for service organizations, which set out how the mark may be displayed. Treat that document as the controlling rule, not this summary.
Two points deserve a check before publication. First, a 2016 *Journal of Accountancy* article said that a service organization with a SOC 1, SOC 2 or SOC 3 report issued within the past year may use the service organization logo in promotional material or on a website. Confirm with the AICPA that this window still applies and that the guidelines have not changed since. Second, the logo sits alongside a separate set of marks: SOC 1, SOC 2 and SOC 3 are registered trademarks of the AICPA, so write those names in running text as the AICPA's own materials do, and do not rename or stylize them in product or sales copy.
Assign one owner, usually the person who manages the trust page, to hold the report date, the issuing CPA firm and the current logo guidelines in one place. Each time the report is renewed, check the date again and remove the logo if the one-year window has passed. The logo shows that a report exists; it does not show what the report covers, so keep the scope and period visible wherever you use it. Ask your auditor which wording they accept when they describe the report publicly.
Which marketing claims about SOC 2 cross the line
Vendors often overstate what a SOC 2 report proves when they write web copy, sales decks and RFP answers. The cards below cover the claims that imply a certification, a guaranteed outcome or an AICPA endorsement, and the checks that keep every statement tied to the report period and scope.
Calling the company SOC 2 certified
A SOC 2 is an examination report issued by an independent CPA firm, not a certificate, and no one is SOC 2 certified in the sense of passing a pass or fail test. Saying "SOC 2 certified" on a website or in a proposal misstates what the report is. Write instead that the company received a SOC 2 Type 2 report from a named CPA firm, with its period and scope stated.
Claiming a clean audit is assured
Promising that an audit will come back clean, or that a future report will carry no exceptions, is a guaranteed outcome that the AICPA Code prohibits in its examples of misleading advertising. An auditor cannot promise an opinion before testing is done. Keep forward-looking statements to what the company is doing, such as planning a Type 2 examination, without predicting its result.
Implying the AICPA approved the CPA firm
The AICPA does not approve or endorse individual auditors, and describing a CPA firm as AICPA-approved is listed among the prohibited examples in the Code. A reader may take the phrase as a quality guarantee. Name the CPA firm only as the issuer of the report, and confirm its licensing status with the relevant state board before publishing the name.
Applying the report to the wrong period
A report covers a stated period, and an opinion covers only the system and services described in it. Saying the company is "SOC 2 compliant today" when the last observation period ended many months ago, or extending a report to a product line it did not cover, is misleading. Check the period end date, the trust services categories and the included systems before any claim goes live.
Using the SOC logo beyond its rules
The SOC logos are AICPA trademarks, and the AICPA requires organizations to read its logo guidelines before displaying one. A service organization may use its logo only when it holds a SOC 1, SOC 2 or SOC 3 report issued by a licensed CPA. Placing the logo next to an expired report, a gap in coverage or a product outside scope tests those rules, so review the logo use against the guidelines.
Sending a restricted report as a public claim
A SOC 2 report is restricted in use, so publishing its contents, quoting exceptions out of context or linking to the full report from a public page can breach the distribution terms. Public marketing should cite only a SOC 3 report, which is general use, while the SOC 2 stays behind an NDA. Check that every sentence on a public page could be read by a reader who has no SOC 2 access.
Who owns the report, the trust page and the evidence behind them
The organization that runs the service owns its controls, its NDA and its trust page. It decides which people in the organization are responsible for each control, what the system description says, and who receives the report. Management is also the party that signs the written representations the CPA firm relies on during the examination, so the organization carries the accountability for what it claims. An NDA is the organization's own contract with a prospect, and the organization decides its terms, its gate and who may sign it.
- Controls and their owners: Named internal owners are responsible for each control, including access reviews, change approvals and incident response, whether or not an outside party helped build them.
- The NDA: The organization drafts or approves the confidentiality terms that govern a prospect's review of the report, and decides when a counterparty is ready to sign.
- The trust page: The organization publishes and maintains what appears on its public or gated trust page, including any SOC logo use and the wording of every claim.
- Representations to the auditor: Management signs the representation letter that accompanies the examination, so the organization owns the statements about its environment.
- Distribution decisions: The organization chooses which prospects, partners and regulators receive the restricted report, within the limits the CPA firm sets.
Before sharing anything, confirm with your legal team who signs the NDA and who approves trust page copy.
An implementation partner such as DeployOpen can help prepare the material a prospect sees and the evidence behind it. That work is preparation, not attestation. The partner can structure the trust page, assemble evidence packs that map to the criteria, and design the workflows that control who gets access to a gated document. It cannot issue a SOC 2 report, decide what the report says, grant the use of the report to anyone, or authorize the SOC logo on the organization's behalf.
- Trust page content: The partner can draft layout, navigation and supporting text for the organization to review, but the organization approves every claim before publication.
- Evidence packs: The partner can gather and organize the records an auditor samples, such as access review exports, change tickets and backup restore logs, so the organization can answer questions quickly.
- Access workflows: The partner can configure how a request for the report is received, how an NDA is checked and how a reviewer's access is granted and later removed.
- Logo and claim review: The partner can check proposed marketing wording against the AICPA logo guidelines and the SOC trademark rules, and flag claims that go too far. The organization decides what is published.
- Limits on the partner's role: The partner does not sign the report, does not authorize its release, and does not represent the CPA firm in front of prospects.
Ask any partner to put these boundaries in the written scope before work starts.
The independent CPA firm performs the SOC 2 examination and issues the report and its opinion. Only the firm can determine whether the controls meet the criteria, and only the firm can set the use restrictions printed in the report. Under the attestation standards the examination is assertion-based, which means the firm obtains written representations from management and tests the controls against them. Because the firm's opinion is the product that customers rely on, its independence and its signature are what give the report meaning.
- The opinion and the report: The firm issues the report, including the description of the system and the opinion on design or operating effectiveness, depending on the report type.
- Use restrictions: The firm states who may use a SOC 2 report. A SOC 2 is generally restricted, so the intended users are identified with management, and the firm's wording governs what the organization may share.
- General use reports: A SOC 3 report is a separate document that the firm issues for general distribution, and it carries no restriction on use.
- Engagement terms: The engagement letter defines the scope, the period and the services. Confirm that it covers the SOC 3 report if you plan to publish one.
- Questions to send the firm: Ask whether a prospect's NDA is compatible with the restricted-use language, and whether the firm reviews the trust page wording that refers to its report.
Check the firm's current report and use restriction language before you promise a prospect any access.
Common questions about sharing SOC 2 reports
Can I post my SOC 2 report publicly on my website?
Generally no. A SOC 2 report is a restricted-use report, and its use is limited to the intended users identified with management, such as customers, prospects under NDA, regulators and business partners. Posting a full Type 1 or Type 2 report on an open page puts it in front of people who were never intended recipients. If you want a public document, a SOC 3 report is the usual answer because it is a general use report that can be freely distributed. Before you publish anything, confirm the distribution terms in your engagement letter and report with your CPA firm, and ask counsel to review the wording you plan to use.
What should an NDA cover before a prospect receives a SOC 2 report?
An NDA for a SOC 2 request should name the report, limit its use to evaluating your service, restrict distribution to the individuals who need it, and prohibit copying, forwarding or posting it. It should also say what happens when the recipient's engagement ends, how the report is returned or destroyed, and whether the recipient may share it with its own auditors or regulators. Regulated buyers often need a carve-out for examiners. Have counsel draft or review the clauses, and check with your CPA firm that the wording matches the report's stated intended users.
Is a SOC 3 report enough for a bank that is evaluating my service?
Often it is not. A SOC 3 report covers the same trust services categories as a SOC 2 in less detail, and it usually lacks the control-level descriptions, test procedures and exceptions that a bank's third-party risk team needs. Banking regulators expect a bank to assess the operation of its vendors' controls, which typically means reading the full SOC 2 under NDA and reviewing its scope and period. Offer the SOC 3 as the public summary, and be ready to provide the restricted SOC 2 when the bank's due diligence requests it. Ask the bank's risk team which document they require.
Can I use the SOC logo on my website before I receive a report?
No. The AICPA's SOC logo may be used only by a service organization that has received a SOC 1, SOC 2 or SOC 3 report from a licensed CPA or a non-US equivalent. Showing the logo while an examination is still in progress, or as a stand-in for one, is the kind of claim that creates ethics and trademark exposure. Read the AICPA's logo guidelines before downloading or displaying the mark, and check the current wording of the service organization logo rules with your CPA firm and counsel, because usage terms can differ between logo types.
How much effort does a trust page take to maintain?
The effort depends on how many documents you publish, how often your controls and scope change, and whether requests come through a gated process. A useful trust page usually links a SOC 3 report, a description of your in-scope services and subservice organizations, your security overview and a request form for the restricted SOC 2 under NDA. Ongoing work includes updating dates and periods after each audit, keeping subservice lists accurate, and reviewing logo and marketing wording. Ask your team to estimate this from the number of documents and the approval steps, and confirm the approval chain with your CPA firm and counsel before launch.
Can an implementation partner share our SOC 2 report on our behalf?
Only in the ways your organization authorizes, and only the report itself is the organization's document to distribute. An implementation partner prepares systems, controls and evidence for the examination, but it does not issue the report, and it should not send the report to prospects unless you have agreed in writing that it may do so under your NDA and distribution rules. Decide who holds the request queue, who signs NDAs and who logs each disclosure. Confirm these roles in the written scope, and ask your CPA firm whether any distribution by a third party affects the report's intended users.
How DeployOpen prepares trust material and evidence for sharing
DeployOpen works with your team to decide what a prospect may see, how the restricted report and public material fit together, and what evidence sits behind each claim. The organization owns its controls and its report; DeployOpen prepares the systems, documentation and evidence that an independent CPA firm examines and that your team then shares.
How we scope
- Written scope agrees which systems, trust pages and sales materials are covered before work starts.
- We map which audience gets the restricted SOC 2 report under NDA and which gets a SOC 3 summary.
- Engagements are fixed-scope, and ongoing support is available as a retainer.
How we build
- We set up a gated trust page structure that controls access to the restricted report.
- We review draft trust content against the report's system description, period and scope.
- We check logo use and marketing claims against the AICPA guidelines before anything is published.
How we hand over
- Deliverables include a written sharing procedure, NDA workflow notes and a claims checklist.
- Documentation records who approved each published statement and when it was reviewed.
- Your team receives the material and the evidence trail, with open items listed for your CPA firm to confirm.
How we support
- Retainer support can refresh trust content when the report period, subservice list or scope changes.
- We help your team answer prospect questions with approved, report-backed wording.
- Re-checks follow each new report issue, so public statements keep matching the current examination.
