SOC 2 report: what's in it and how to read one

Your auditor has sent the draft SOC 2 report, and the security reviewer at your US prospect is waiting for it. The deal moves when they finish reading. Before you send it, read your SOC 2 report the way they will: the opinion first, then the scope and period, then the exceptions.

This guide is for founders, COOs and security leads at UK B2B tech firms with 25 to 100 staff. It walks through each section of the report from the reader's chair, then gives you two short checks: one for your own report before it leaves the building, and one for the reports your suppliers hand you.

What is a SOC 2 report?

A SOC 2 report is an independent CPA firm's attestation on a service organisation's controls, measured against the AICPA Trust Services Criteria. It contains the auditor's opinion, management's assertion, the system description and, in a Type 2 report, the tests of controls and their results. A reader checks the opinion type, the scope and the period first.

The criteria are the AICPA's 2017 Trust Services Criteria, set by its Assurance Services Executive Committee. For what SOC 2 covers and why buyers ask for it, start with our SOC 2 overview.

A SOC 2 report is an attestation, not a certificate. There is no certificate number to look up. What your customer receives is a CPA firm's opinion on a defined system over a defined period, and the AICPA is clear that only a licensed CPA firm can issue a valid one.

Two neighbouring terms are easy to mix up:

• Type 1 and Type 2. A Type 1 report looks at design at a point in time. A Type 2 report adds whether the controls operated effectively across a period. Choosing between them has its own guide: SOC 2 Type 1 vs Type 2.
• SOC 1. A SOC 1 report covers controls that affect a customer's financial reporting, which is a different examination with a different audience.

How do you read a SOC 2 report, section by section?

Read a SOC 2 report in the order a customer's reviewer does: the auditor's opinion, management's assertion, the system description, then the tests of controls and results. Each section answers a different question, and the opinion tells you how much weight the other three can bear. The AICPA's own review checklist expects test results in section four.

The AICPA publishes an illustrative SOC 2 Type 2 report that contains the same four parts. The table shows what each part is and the question a reader brings to it.

Some reports carry a further section of other information from management, such as responses to exceptions. The AICPA checklist asks reviewers whether that response was audited or not, so be clear in your own report which words the auditor stands behind.

What do the four SOC 2 opinion types mean for a deal?

A SOC 2 report carries one of four opinions: unmodified (often called unqualified), qualified, adverse or a disclaimer. Unmodified is the result customers expect. Qualified means material problems were confined to part of the system. Adverse means they were pervasive. A disclaimer means the auditor could not gather enough evidence to give an opinion at all.

The AICPA SOC 2 report review checklist sets out how each opinion reads. The last column below is our view of how each one tends to land in a customer's security review.

An unmodified opinion can still carry exceptions.

A qualified opinion opens with an "except for" and points to the paragraph that explains why. That paragraph is the one a customer's reviewer will quote back to you, so read it before they do.

The checklist also asks readers to look for any emphasis-of-matter or other-matter paragraph in the auditor's report. Those paragraphs are where the auditor deliberately draws attention to information a reader should weigh.

What is management's assertion in a SOC 2 report?

Management's assertion is your firm's own written statement that the system description presents the system fairly and that the controls were suitably designed and, for Type 2, operated effectively against the Trust Services Criteria. The auditor's opinion is given on those claims, so a reader treats the assertion as your commitment.

The assertion is the reason the report is yours rather than the auditor's. Management states what it believes; the CPA firm then says whether the evidence supports it.

Read your draft assertion as a customer's lawyer would. It names the system, the period and the trust services categories in scope, and the AICPA notes that the in-scope categories typically appear in the first paragraph of both the auditor's report and management's assertion.

If those categories differ from what your sales team has been promising, change the promise or the scope before the report goes out.

What does the system description tell a customer?

The system description is management's account of the service in scope, prepared against the AICPA's description criteria. A customer reads it to confirm three things: the report covers the service they buy, the stated commitments match their contract, and nothing disclosed about incidents or system changes during the period affects them.

The AICPA's description criteria (DC 200) are the benchmark for preparing and evaluating the description. They do not fix a format, so the layout of a description differs from one firm to the next.

A reviewer reading the description looks for:

• The service commitments and system requirements, and whether they cover what the reviewer needs from you.
• Disclosed incidents, where an event during the period could have affected their data or service.
• Significant changes, such as a new platform or a major migration in the period.
• Subservice organisations and CUECs, which change what the report covers and what the customer must do.

Writing a description that holds up is a separate task from reading one, and it deserves its own preparation time well before fieldwork.

How do you read the tests of controls in a SOC 2 Type 2 report?

In a SOC 2 Type 2 report, the tests section lists each control, the auditor's test of it and the result. A clean result records no exception. Where a test found a deviation, the row describes it, often with management's response. A reader judges each exception by how much the control matters to their service, not by the count.

Some readers write it as a SOC 2 Type II report; the content is the same. The AICPA's guidance on vendor management and SOC 2 reviews notes that Type 2 reports, with their operating effectiveness results, offer more comfort than reports covering design alone.

Start with the test method. The AICPA checklist does not accept inquiry alone as a test: the auditor should also have inspected, observed or re-performed the control. A control "tested" only by asking someone whether it works has not really been tested.

Then weigh each exception on three things:

• What it touches. A missed step in a control that protects your data, or one of your own top risks, matters more than one in a control you never rely on.
• What followed. Check whether the deviation caused an incident, or plausibly could have, and whether last year's report recorded the same one.
• What management said. A useful response names the cause, the fix and when it took effect. Note whether the auditor tested that response or it sits in the report unaudited.

A repeated exception is a pattern, not an accident.

How exceptions arise during fieldwork, and how the audited firm should respond to them, belongs to the audit itself. For a reader, the job is to decide whether an exception changes the risk of using the service.

What are complementary user entity controls in a SOC 2 report?

Complementary user entity controls (CUECs) are controls the service organisation expects its customers to run so that its own service commitments can be met. They are listed in the system description. If customers skip them, the vendor's own controls can fall short, so a reviewer maps each CUEC to a named control of their own.

The AICPA's checklist expects CUECs to be rare, on the reasoning that a well-designed system seldom needs its customers to run controls for it. A long CUEC list is worth a question.

The same checklist separates CUECs from user entity responsibilities. Responsibilities are the customer's own housekeeping for getting full value from the service, such as managing who in their team has access. The vendor does not depend on them to meet its commitments.

For your own report, write CUECs a customer can actually run and evidence. A CUEC nobody on the customer side owns is a gap in both firms' controls.

How do subservice organisations change what a SOC 2 report covers?

Subservice organisations are suppliers your vendor relies on to deliver its service, such as a cloud hosting provider. Under the carve-out method, their controls are excluded from the report, and the vendor lists the complementary subservice organisation controls (CSOCs) it depends on. Under the inclusive method, those controls are tested within the report.

Carved out of the report is not carved out of the risk.

With a carve-out, the AICPA's checklist leaves the judgement with the reader: read how the description says the vendor oversees each carved-out provider, and decide whether that oversight is enough for you. Where it isn't, ask for the provider's own SOC report, or an equivalent, and review that too.

For your own report, list every carved-out provider your service depends on, and keep their current assurance reports to hand. A customer's reviewer will ask for them, and a quick answer reads as control.

How current does a SOC 2 report need to be?

A SOC 2 report describes a past period, so its value to a reader fades as that period recedes. Customers check that the period is recent enough to be useful for their review and that there is no gap since the previous report. When there is a gap, a bridge letter covers the timing difference until the next report.

The AICPA's guidance leaves currency to the reader's judgement rather than setting a shelf life, so the standard you have to meet is your customer's.

We recommend planning consecutive report periods so a customer never sees a hole in coverage. If a gap can't be avoided, our guide to the SOC 2 bridge letter explains how to cover it.

Who can you share a SOC 2 report with?

A SOC 2 report is meant for readers with enough understanding of your service and system to interpret it, such as customers, prospects and their auditors. It is not a general-use document. If you need something you can publish, a SOC 3 report covers the same categories with less detail and can be freely distributed.

The AICPA describes SOC 3 reports as general use because they do not provide the same level of detail as SOC 2.

We recommend sharing your SOC 2 report only under a non-disclosure agreement, through a controlled channel such as a gated trust centre, and recording who received which version.

What should you check before you send your SOC 2 report?

Before your SOC 2 report goes to a customer, read it as their reviewer will. Confirm the opinion, the scope and the period, then look for anything a reviewer will raise: exceptions without a clear response, CUECs nobody can explain and carved-out providers you cannot evidence. Each item below is a question you would otherwise receive by email.

1. The opinion. It is unmodified, or you have a short written explanation ready for any qualification.
2. The system name and services. They match what this customer buys from you.
3. The trust services categories. They match what your contract and sales team have promised.
4. The period. It is recent and follows the last one without a gap, or a bridge letter is ready.
5. Every exception. It has a specific management response, and the fix is in place.
6. The CUECs. They are few, specific and something a customer can run.
7. Carved-out providers. Each one is named, and you hold its current assurance report.
8. Distribution. An NDA is in place, and you know which version went to whom.

What should you check when a supplier hands you a SOC 2 report?

When a supplier sends its SOC 2 report, check that it covers the service you use, over a recent period, with an unmodified opinion from a licensed CPA firm. Then work through the exceptions, the CUECs and any carved-out subservice organisations, and record what you concluded and what your own team now has to do.

The AICPA publishes a fuller vendor review checklist that is worth keeping on file. Our shorter version follows the reading order of this guide:

1. Opinion. Is it unmodified? If not, read the reason and decide whether it affects what you buy.
2. Issuer. Is the CPA firm licensed, what was its latest AICPA peer review result, and is it the same firm as last year?
3. Coverage. Do the system, the locations and the trust services categories match the service you depend on?
4. Period. Does it end recently, and follow the previous report without a gap?
5. Testing. Did the auditor inspect, observe or re-perform, rather than just ask?
6. Exceptions. Do any sit in controls that protect your data or your main risks?
7. CUECs. Does each one have an owner and a matching control on your side?
8. Carved-out providers. Is the supplier's oversight of them enough, or do you need their reports as well?

The PRA expects this review to be real. The PRA's supervisory statement on outsourcing and third party risk management (SS2/21) tells firms with material outsourcing to assess the adequacy of supplier reports, not to assume their existence is enough. Expect customers that are banks or insurers to read your report in the same spirit.

If you run an ISO 27001 management system, this review is also the evidence behind your supplier controls under ISO 27001 Annex A 5.19.

What are the most common mistakes when reading a SOC 2 report?

The most common mistakes in reading a SOC 2 report are stopping at the opinion, filing the CUECs unread, assuming carved-out providers are covered and checking the report date instead of the period. Each one leaves a gap between what the reader believes the report covers and what it covers, and supplier risk sits in that gap.

• Treating "unmodified" as "no issues". The opinion can be unmodified while the tests still record exceptions that matter to your service.
• Filing the CUECs. A CUEC that nobody in your team has mapped to a control is not being run.
• Assuming the cloud platform is covered. Under a carve-out, it is not, and the supplier's monitoring of it is all the report gives you.
• Reading the date, not the period. The report date tells you when the auditor signed; the period tells you what was tested.
• Not checking the issuer. A report that a licensed CPA firm did not issue is not a SOC 2 report.

Frequently asked questions