Sharing a SOC 2 report with customers: may you forward it?
You may share a SOC 2 report with customers and partners, but usually not with everyone. A SOC 2 report is meant for parties with a defined interest in it, and it is often shared under a confidentiality agreement (NDA). How strict that is depends on the engagement and on the agreements you make with your auditor. Also read the main SOC 2 page, the audit process that produces the report, and the bridge letter for when your report is too old. This page follows common practice. Ask your auditor which distribution applies to your report.
Never send the report as an attachment to a random prospect. It contains details about your system and your controls that you do not want to make public. Share it through a secure route, and only after a confidentiality agreement is signed.
Why the report is not public
A SOC 2 report describes your system, your controls and the tests performed on them. That is information an attacker could use. That is why the report is usually intended for a limited group of readers. Advisers call this “restricted use”. The exact wording is in the auditor’s report (auditorsverklaring). Always read it, because it states who the report is intended for. If you want to share something publicly, ask for a SOC 3 report instead. See the audit process.
That is also why many companies do not put their report on the website. They give a summary, an overview or a reference. Only those who are entitled to it receive the full report.
Who may see the report?
That depends on your engagement and the agreements with your auditor. A practical breakdown:
| Party | May see the report? | Condition |
|---|---|---|
| Existing customer with a contract | Usually yes | Through a secure route, under confidentiality |
| Prospect in a procurement process | Often yes | After an NDA and on request |
| Your own auditor or accountant | Yes | That is their job |
| A regulator | Usually | On request and after consulting your auditor |
| A random third party, for example a journalist or competitor | No | Do not share |
| A subservice partner within your scope | Sometimes | Only the relevant part, and only with permission |
The table is a guideline. Your auditor and your legal adviser set the exact limits. A report you give to a customer is therefore not automatically open to every recipient that customer forwards it to.
An example: a prospect asks for the report
A fictional example. A SaaS company with forty employees receives a request from a large healthcare provider. The buyer wants to see the full SOC 2 Type II report. The company handles it like this:
- It first sends a summary and an overview of the criteria and the period.
- It asks the prospect to sign an NDA.
- After the NDA, it shares the report through a secure customer portal, with a temporary link and a log of who opened it.
- It adds a short note to the email about the scope and the period.
These steps take half a day. They stop the report from circulating without limits, and they prevent later discussion about who was allowed to see what.
What if a customer wants to forward the report?
This happens often. A customer may want to share the report with their own auditor, a parent company or another department. That is usually allowed only if the agreements permit it. Ask your customer to tell you who the recipient is, and to confirm that the recipient is bound by the same confidentiality.
The customer may also not want a full report, but a letter covering the period after the report. That is the role of the bridge letter. That letter is short and gives a statement about the period between two reports.
How to store the report properly
The report is sensitive information. Handle it like your other confidential documents:
- Store it somewhere with limited access, not in a general shared folder.
- Keep a record of whom you gave it to and when.
- Replace the report with the latest version as soon as one is available, and remove the old one from circulation.
- Refer to the version and the period in your communication, so customers know what they are looking at.
Common mistakes
Publishing the report. A public download is in most cases not intended. Use a summary or a secure customer portal.
Sending it without an NDA. An NDA is a simple step that prevents a lot of confusion. Always ask for one.
Not keeping track of who has the report. If a question comes up later, you need to be able to say who has seen it.
Continuing to send an old report. A report from two years ago says little about your current system. Send the latest version and explain which period it covers.
An email you can use
When a customer asks for the report, a short, standard email is useful. It makes clear which conditions apply, so you do not have to think it through each time.
Subject: SOC 2 report, secure access
Hello [name],
Here is access to our SOC 2 report. The report covers the period [start] to [end]
and the following Trust Services Criteria: [criteria].
Before access, we ask you to sign the confidentiality agreement. Once that is
received, we will send you the secure link.
If you want to forward the report to another party, please let us know so that
we can align the conditions.
Kind regards,
[name]Always fill in the period and the criteria. A report without a period is hard for a customer to assess, and that leads to extra questions.
What to do when the report is no longer current
Sometimes a customer asks for a report that is already a year old, while you have already moved into a new period. Then there is a gap. You fill that gap with a bridge letter. You write that yourself as management. Your auditor does not give assurance on it. Send the old report together with the letter, so the customer sees both.
Do not wait until the customer asks. Plan the next audit so that the new report is ready on time, and let the customer know when it is expected.
More information
- What is SOC 2?: the main page of this section
- Bridge letter: what you send when the report is too old
- SOC 2 report: what a Type II report looks like: what is in the report
- Frequently asked questions: answers to the most common questions
- For SaaS companies: how to handle customer questions about SOC 2
Sources
- AICPA SOC services : the American framework in which SOC reports are issued