Last updated: 1 November 2026

A SOC 2 report is an independent auditor's report on a service organisation's controls for security and, optionally, availability, processing integrity, confidentiality and privacy. If you are buying software or outsourcing a service, it is usually the strongest single piece of evidence a vendor can hand you, but only if you read it properly. This guide explains what a SOC 2 report contains, the difference between Type 1 and Type 2, and gives you a 10-step review checklist, an exception triage table and a worked example from the buyer's side.

Most SOC 2 content is written for vendors trying to get a report. This page is for the people on the other side of the table: procurement, security, privacy and risk teams who receive a 90-page PDF and need to decide whether it is enough.

What is a SOC 2 report?

SOC 2 is part of the AICPA's System and Organization Controls (SOC) suite, a set of reports that CPA firms issue on controls at service organisations. A SOC 2 examination tests the vendor's controls against the AICPA's 2017 Trust Services Criteria (with revised points of focus, 2022), which are grouped into five categories:

Category What it covers When you need it in scope
Security Protection against unauthorised access, use or disclosure (the "common criteria") Always. This is the baseline for any vendor touching your data or systems
Availability System uptime and resilience commitments The service supports a business process you cannot run without
Processing integrity Complete, accurate, timely and authorised processing The vendor calculates, transforms or transacts on your behalf (payroll, billing, payments)
Confidentiality Protection of information designated as confidential The vendor holds your trade secrets, contracts, financials or IP
Privacy Collection, use, retention and disposal of personal information The vendor processes personal information as part of the service

Two points matter for buyers. First, a SOC 2 is an attestation, not a certification: the auditor gives an opinion on the vendor's description and controls, and there is no "SOC 2 certificate". Second, the vendor chooses the scope. A report that covers only security tells you nothing about the vendor's privacy practices, however good the security opinion is.

Note on upcoming changes: on 28 October 2026 the AICPA published an exposure draft of proposed 2027 SOC 2 Trust Services Criteria, including new points of focus on AI governance and model monitoring. Comments are open until 15 January 2027. If approved, the new criteria would apply to engagements beginning on or after 31 December 2027, with early adoption permitted. Until then, the reports you receive will be prepared against the 2017 criteria. Nothing in this review method changes either way.

SOC 2 Type 1 vs Type 2 (and where SOC 1 and SOC 3 fit)

Report What the auditor tests Who it is for How useful it is for vendor due diligence
SOC 2 Type 1 Whether the controls are suitably designed and in place at a single point in time Customers, under NDA Limited. Shows intent, not that controls worked over time. Acceptable for a vendor's first year
SOC 2 Type 2 Design plus whether controls operated effectively over a period (often 6 to 12 months) Customers, under NDA The one to ask for. Section 4 shows the tests performed and any exceptions
SOC 1 Controls relevant to the customer's financial reporting Customers' finance teams and external auditors Useful for payroll, billing or payments vendors, but not a substitute for SOC 2 on security
SOC 3 Same criteria as SOC 2 but with far less detail Anyone. The AICPA describes SOC 3 reports as general use reports that can be freely distributed Good for a quick check on low-risk vendors. Too thin for critical vendors because it has no test results

If a critical vendor offers you a SOC 3 or a Type 1 only, ask when their Type 2 period ends and plan a follow-up date.

What's inside a SOC 2 report: the five sections

Auditors lay reports out slightly differently, but almost every SOC 2 Type 2 report contains the same building blocks. Knowing where each one sits saves most of the reading time.

Section What it is What to look for
1. Independent service auditor's report The auditor's opinion The opinion type (unmodified, qualified, adverse or disclaimer), the period, the categories in scope and any paragraph that starts "except for"
2. Management's assertion The vendor's statement that its description is fair and its controls were designed and operated effectively Whether it matches the opinion and names the same period and categories
3. System description The vendor's own description of the system: services, infrastructure, software, people, data, procedures, subservice organisations and complementary user entity controls Whether the product you are buying is actually in scope, which hosting and other providers are carved out, and what the vendor expects you to do
4. Trust services criteria, controls, tests and results A table mapping each criterion to the vendor's controls, the auditor's test and the result Every result other than "no exceptions noted"
5. Other information (optional) Unaudited content added by the vendor, often management responses to exceptions Remediation commitments and dates. Remember the auditor has not tested this section

How to review a vendor's SOC 2 report: a 10-step checklist

This is the order that gets you to a decision fastest. For a critical vendor, expect the review to take one to two hours. For a low-risk vendor, steps 1 to 4 are often enough.

Step 1: Confirm the entity, product and locations

Check the legal entity named in the report and the services described in Section 3. Vendors with several products often scope SOC 2 to one platform. If the module, region or hosting environment you will use is not described, the report does not cover it, however clean the opinion is.

Step 2: Check the report type and the period

Prefer Type 2. Note the period end date and calculate the gap to today. A report whose period ended more than 12 months ago is stale. For a gap of a few months, ask for a bridge letter (sometimes called a gap letter): a letter signed by the vendor's management, not the auditor, confirming there have been no material changes to the control environment since the period ended. Treat it as a management representation, not audit evidence.

Step 3: Read the opinion first

An unmodified opinion means the auditor found the description fair and the controls suitably designed and, for Type 2, operating effectively. A qualified opinion means one or more criteria were not met; the "basis for qualified opinion" paragraph tells you which. An adverse opinion or a disclaimer is a red flag for any vendor handling sensitive data and should trigger escalation.

A clean opinion can still contain exceptions. Do not stop here.

Step 4: Compare the categories in scope with what you need

Use the category table above. A payroll vendor with only security in scope has not been tested on processing integrity or privacy. Record the gap and cover it with targeted questions from your vendor risk assessment questionnaire rather than rejecting the vendor outright.

Step 5: Find the subservice organisations

Section 3 lists the vendor's own key providers, typically cloud hosting, payments or customer support platforms. Reports treat them in one of two ways:

  • Carve-out method: the subservice organisation's controls are excluded from testing. The report will list the controls the vendor expects that provider to perform (complementary subservice organisation controls). You need separate assurance, usually the provider's own SOC 2.
  • Inclusive method: the subservice organisation's relevant controls are included in the description and tested.

Carve-out is the norm for large cloud providers. It is not a weakness in itself, but it means the vendor's report is only half the picture. This is where fourth-party risk lives.

Step 6: Map the complementary user entity controls (CUECs) to owners

CUECs are controls the vendor assumes you perform for its controls to work. Typical examples: you review user access to the platform periodically, you remove leavers promptly, you protect API keys, you notify the vendor of security incidents. If you do not operate them, the vendor's controls may not achieve their objective for your organisation, and that gap is yours.

Copy every CUEC into your vendor record, assign an internal owner and confirm each one is in place. This is the step most reviews skip, and it is the one auditors and regulators ask about.

Step 7: Triage every exception in Section 4

An exception is a test result where the auditor found a control did not operate as described, for example 3 of 25 sampled leavers kept access for more than the vendor's stated window. Use the triage table below to grade each one, and look for patterns: several exceptions in the same area (access management, change management, monitoring) matter more than one isolated miss.

Step 8: Read management's responses

Vendors often respond to exceptions in Section 5 or in a separate section. Check that the response explains the root cause, the fix and a date. Remember this text is not audited, so for high-severity exceptions ask the vendor for evidence of remediation.

Step 9: Check the auditor

Confirm the report is signed by a licensed CPA firm and that the firm name, date and signature are present. You do not need to judge the audit's quality in depth, but an unknown firm, an unsigned report or one that reads like marketing copy warrants a second look.

Step 10: Record your conclusion and follow-ups

Write a short review memo (template below), attach the report to the vendor record, log open points as issues with owners and due dates, and set a reminder for the next report or bridge letter. This record is what you will show an auditor, regulator or customer who asks how you assure your suppliers.

SOC 2 exception triage table

This is our own suggested grading model, not an AICPA standard. Adjust it to your risk appetite.

Severity Typical examples What to do
High Exceptions in logical access, privileged access, encryption, incident response or backup restoration for a vendor handling sensitive or personal data; qualified opinion on security; repeated exceptions in the same control Escalate to the risk owner. Require remediation evidence before contract signature or renewal, or add contractual commitments. Consider compensating controls on your side
Medium Isolated exceptions with a clear root cause and remediation date (for example late completion of annual security training, one missed quarterly access review) Log as an issue with a follow-up date. Check the next report or bridge letter
Low Documentation timing, controls not relevant to your use of the service, exceptions already remediated within the period with evidence Note in the memo. No further action

Worked example: reviewing a payroll vendor's SOC 2 report

Illustrative example. The vendor and figures are invented.

A mid-sized company is renewing a payroll SaaS vendor that processes employee personal information and bank details. The vendor sends a SOC 2 Type 2 report.

Check Finding Conclusion
Entity and product Report covers the vendor's payroll platform hosted in the EU region the company uses In scope
Type and period Type 2, 12-month period ending 30 June. Review date 1 November: four-month gap Request bridge letter (received)
Opinion Unmodified Acceptable
Categories Security and availability only Gap: processing integrity and privacy not tested. Send 8 targeted questions on payroll calculation checks and personal data retention
Subservice organisations Cloud hosting and payment file transfer provider, both carved out Obtain the hosting provider's SOC 3 and confirm the transfer provider is on the vendor's sub-processor list
CUECs 6 listed, including quarterly user access review and immediate removal of leavers 5 already operated by HR; quarterly access review not happening. Raise internal issue, owner HR systems lead, due in 30 days
Exceptions 2 noted: one terminated vendor employee retained access for 9 days (1 of 25 samples); one change deployed without documented approval (1 of 40 samples) Both Medium: isolated, root cause given, remediation dated. Follow up on next report
Overall Renew, with two open issues and a 6-month follow-up for the next report Approved by risk owner

Two things stand out. The biggest real risk found was on the buyer's own side (the missing access review), and the report's scope did not cover the processing integrity and privacy questions that matter most for a payroll vendor. A quick read of the opinion alone would have missed both.

What a SOC 2 report does not tell you

A clean SOC 2 is strong evidence of a working security control environment. It does not answer every due diligence question. Use it alongside, not instead of, your vendor risk assessment.

Question Why SOC 2 may not answer it Where to get the answer
Is the vendor compliant with GDPR, UK GDPR or POPIA? SOC 2 tests controls against AICPA criteria, not against privacy law. Even with privacy in scope, it does not assess lawful basis, transfers or data subject rights handling Data processing agreement, privacy questions, transfer assessment
Where exactly is my data stored and who are the sub-processors? System descriptions summarise infrastructure; they are not a live sub-processor list Vendor's published sub-processor list and contract
How does the vendor govern the AI features in its product? The 2017 criteria predate most generative AI. AI points of focus are only proposed for 2027 AI-specific due diligence questions
What is the vendor's financial health? Out of scope Financial checks, credit reports
Has anything changed since the period ended? The report is backward-looking Bridge letter, ongoing monitoring

How SOC 2 evidence supports your regulatory obligations

Regulators do not require you to obtain a SOC 2 report, but several laws require you to assure your suppliers' security, and a reviewed SOC 2 is a recognised way to evidence it.

Law What it requires of you How a reviewed SOC 2 helps
GDPR Article 28(1) Use only processors "providing sufficient guarantees" of appropriate technical and organisational measures Independent evidence of the processor's measures
GDPR Article 28(3)(h) Processor must make available information to demonstrate compliance and allow for and contribute to audits, including inspections A SOC 2 report is often how processors meet information requests, reducing the need for on-site audits
GDPR Article 32(1)(d) A process for regularly testing, assessing and evaluating the effectiveness of security measures Type 2 testing over a period, reviewed annually
NIS2 Article 21(2)(d) and 21(3) Supply chain security, taking into account each direct supplier's vulnerabilities and the overall quality of their cybersecurity practices Structured evidence of supplier practices, with exceptions logged as findings
DORA Article 28(1) and Article 30(3)(e) Manage ICT third-party risk as part of ICT risk; for critical or important functions, contracts must give rights to monitor the provider and unrestricted rights of access, inspection and audit Supports ongoing monitoring. It does not replace the contractual audit rights DORA requires
POPIA section 19(2)(c) and section 21(1) Regularly verify that safeguards are effectively implemented, and ensure by written contract that operators establish and maintain security measures Evidence that an operator's safeguards were tested, recorded as part of your operator oversight. See our POPIA compliance guide

What if the vendor does not have a SOC 2 report?

Many good vendors, especially outside North America, never get one. SOC 2 is a US-originated framework, and European and South African vendors more often hold ISO/IEC 27001 certification. Acceptable alternatives, in rough order of strength:

  1. ISO/IEC 27001 certificate plus the Statement of Applicability. Check the certificate's scope, issuing body and expiry date. The certificate alone does not show test results, so ask for a summary of the latest surveillance audit findings for critical vendors.
  2. SOC 3 report. Confirms an opinion exists, but has no detail on tests or exceptions.
  3. Independent penetration test summary from the last 12 months, with remediation status.
  4. Completed security questionnaire with evidence, using the tier that matches the vendor's risk.

For low-risk vendors, a questionnaire may be proportionate. For critical vendors with no independent assurance at all, record the risk explicitly and decide whether contractual audit rights or compensating controls are enough.

SOC 2 review memo template

Copy this into your vendor record for each report you review.

  • Vendor: [legal entity]
  • Service in scope: [product, region]
  • Report: SOC 2 Type [1/2], period [start] to [end], auditor [firm], opinion [unmodified/qualified/adverse/disclaimer]
  • Bridge letter: [received/not required/requested], covering to [date]
  • Categories in scope: [security, availability, processing integrity, confidentiality, privacy]
  • Gaps against our needs: [categories or services not covered, and how they were addressed]
  • Subservice organisations: [name, carve-out/inclusive, assurance obtained]
  • CUECs: [number listed], [number confirmed in place], [open items with owner and due date]
  • Exceptions: [number], highest severity [High/Medium/Low], summary
  • Conclusion: [accept / accept with conditions / escalate / reject]
  • Follow-ups: [issues raised], next review due [date]
  • Reviewed by / date: [name, date]

FAQ

What is a SOC 2 report used for?

Customers use a SOC 2 report to get independent assurance that a vendor's controls over security, and any other categories in scope, are designed and operating effectively. It replaces or reduces long security questionnaires and on-site audits, and it is a common input to vendor onboarding and annual reviews.

Is SOC 2 a certification?

No. SOC 2 is an attestation report in which an independent CPA firm gives an opinion. There is no SOC 2 certificate or certifying body. If a vendor sends you a "SOC 2 certificate" badge instead of the report, ask for the full report under NDA.

How long is a SOC 2 report valid?

There is no formal expiry date. In practice, buyers treat a Type 2 report as current for about 12 months after its period end and ask for a bridge letter to cover the gap until the next report.

What is a SOC 2 bridge letter?

A bridge letter is a letter from the vendor's management, not the auditor, covering the time between the end of the last report's period and the date you need assurance for. It states whether there have been material changes to the system or controls. It is useful, but it is not audited.

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

Complementary user entity controls (CUECs) are controls the vendor assumes its customers perform, such as reviewing user access or protecting credentials. They are listed in the system description. If you do not operate them, the vendor's controls may not achieve their objectives for you, so map each one to an owner in your organisation.

Can we share a vendor's SOC 2 report?

Usually not. Vendors normally share SOC 2 reports only under a non-disclosure agreement, and the report itself usually states who it is intended for. Check the contract and the report's use restrictions before passing it on. If you need something you can share more widely, ask whether the vendor has a SOC 3, which is a general use report.

Track SOC 2 reviews in one place

A SOC 2 review is only useful if the conclusion, the CUECs and the exceptions end up somewhere people will act on them. Core GRC's third-party risk management module lets you keep vendor records, assessments and evidence together, log findings as issues with owners and due dates, and see what is due for review next, as part of a wider GRC programme. If you are starting from a spreadsheet, the free vendor risk register is a good first step.

Cover photo by Vitaly Gariev on Unsplash