SOC 2 report: what a Type II report looks like

A SOC 2 Type II report is a document of several dozen pages. It contains the auditor’s opinion, a description of your system, the controls you have set up, and the results of the tests over the observation period. Customers mainly read the auditor’s opinion and the test results, and only then the rest. Below you will find the structure, a fictional example of one control, and the mistakes to avoid. Also read what happens during the audit process, the controls included in the report, and the difference with Type I. Real reports are confidential. For guidance on sharing your report, see sharing the report with customers.

The structure of the report

A Type II report follows a fixed order. That helps you read it, and it helps your customers assess it.

The report is therefore more than a signature. It is a description of how you work, plus evidence that you actually do it.

The example: one control in the testing section

A fictional SaaS company has the control “Multi-factor authentication is mandatory for all administrator accounts”. The observation period is twelve months. In the report, the row could look like this:

A second control, “Access to production data is reviewed every quarter”, has one exception. The third quarter’s review was completed two weeks late. The explanation in the report says what happened, which measure was taken, and that the next review was on time. That is how an exception should be described.

The sample size and the exact testing method differ per auditor and per control. Ask your auditor which method they use and why.

What customers look for in the report

A customer’s procurement team does not read the report from start to finish. They look for a few things:

• The auditor’s opinion: is it unqualified, or is there a modification?
• The period: does the report cover the period they want to see?
• The scope: are the services they use included?
• The exceptions: are there any, and how are they explained?
• Any subservice organisations: which external parties play a role in your system?

That last question comes up more and more often. If you use AWS for hosting, for example, the report names that party as a subservice organisation. There are two approaches: AWS’s controls are included in your report (inclusive), or they stay outside it and your report refers to AWS’s own report (carve-out). See for cloud providers for the details.

The difference between a Type I and a Type II report

A Type I report describes the controls at one moment and tests whether they are set up. The Type II report also tests whether the controls worked during the observation period. You see this directly in the testing section. A Type I has no test results over time, a Type II does.

This is also why a Type II report often takes longer. The observation period cannot be shortened. You can read more about the choice on the Type I vs Type II page.

Reading the report in thirty minutes

You do not need to read the report from beginning to end to know whether it is good. With this order, you can see in half an hour whether it holds up.

1. Read the auditor’s opinion. Check the type of opinion and any qualifications.
2. Check the period on the cover page and in the opinion. Does it match what your customer is asking for?
3. Read the description of the system. Are the services and locations you actually use included?
4. Review the list of criteria and controls. Is there a criterion included that you did not expect?
5. Go to the testing section and look for rows with an exception. Read the explanation.
6. Check the subservice organisations. Do they have a report of their own, and when is it valid?

For every question you cannot answer, ask your auditor. That is not a sign of weakness. It is the purpose of the report.

Common mistakes

Playing down an exception. The auditor describes every exception in the testing section. Do not try to talk it away. A clear explanation with a remediation measure makes the report more credible.

A system description that is not accurate. If your system is described in the report differently from how it works in practice, that is a problem. Keep the description up to date with every major change.

A control that is in the report but not carried out. A control that only exists on paper will produce an exception on the day of testing. Only choose controls you can really prove.

Reading the report only once it is finished. Read the draft. That is the moment to correct errors. See also the final phase in the audit process.

Thinking that a good report is automatically a good sales pitch. The report proves your controls. It does not sell itself. Customers often also want a short explanation of the scope.

What you can do yourself to make the report stronger

A report is only as strong as the evidence behind it. A few habits make the difference.

• For each control, keep a record of who performs it, how often, and where the evidence is kept.
• Document exceptions immediately, with the cause and the remediation measure. Then you do not have to reconstruct what happened.
• Test your own controls once a quarter, before the auditor arrives.

More information

• The audit process: what the auditor does before the report exists
• Common controls: what you can include in your control list
• Collecting evidence: the evidence behind the test results
• Trust Services Criteria: the criteria you are tested against
• Type I vs Type II: which report suits your situation

Sources

• AICPA SOC services : the American framework for SOC reports