A vendor’s SOC 2 report can be useful third-party assurance evidence, but it should not be accepted blindly. Not on its own. Before relying on it for procurement, vendor due diligence, or audit support, confirm what the attestation covers, what it excludes, whether the examined period is relevant, and what follow-up you need to document.
What Is a Third-Party SOC 2 Attestation?
A third-party SOC 2 attestation is basically an independent examination of a service organization’s controls for a defined system and scope. It results in a SOC 2 report, not a certification or blanket statement that the vendor is “SOC 2 compliant.” AICPA professional guidance describes SOC reports as examinations performed by CPAs under AICPA attestation standards, providing independent assurance to user entities about the subject matter examined (Journal of Accountancy).
“Third-party” matters because the assurance comes from an independent examiner, commonly a CPA firm or service auditor, rather than only from the vendor’s own security claims. The vendor still describes its system and controls, but the service auditor performs procedures and issues an opinion within the limits of the engagement.
SOC 2 examinations use the AICPA Trust Services Criteria and address controls relevant to one or more of security, availability, processing integrity, confidentiality, and privacy (AICPA & CIMA). Not every SOC 2 report covers all five categories, so the reviewer must verify the categories named in the report.
What a SOC 2 Report Proves — and What It Does Not
A SOC 2 report provides scoped assurance about the design and, for Type II reports, operating effectiveness of controls relevant to the selected Trust Services Criteria. It does not prove that every security risk is eliminated, it does not prove that the vendor satisfies every legal or regulatory requirement, or that the report applies to every product the vendor sells.
The report type sets the time dimension. A Type I report addresses control design and implementation as of a specified date; it does not address operating effectiveness over time. A Type II report also addresses operating effectiveness throughout a specified period and includes the service auditor’s tests and results (FORVIS).
Reliance is limited by the report’s:
- Covered system, products, services, locations, and processes.
- Examination period or point-in-time date.
- Trust Services Criteria included.
- Service auditor’s opinion.
- Testing exceptions and related management responses.
- Subservice organization treatment and carve-outs.
- Complementary user entity controls or other customer responsibilities.
- Any gap between the report period and the date of your risk decision.
Even an unmodified opinion is not a no-risk guarantee. The AICPA’s SOC 2 report review tool notes that an unmodified opinion can coexist with testing exceptions, so reviewers should evaluate exceptions in context, including affected controls, relevant criteria, recurrence, related incidents, and the detail and status of management’s response (AICPA & CIMA).
Why Customers Ask Vendors for SOC 2 Attestations
Customers and business partners often request SOC 2 reports to understand the design, operation, and effectiveness of controls and to help assess risks from outsourced services (AICPA & CIMA). In practice, the report may support procurement reviews, vendor risk assessments, security questionnaires, enterprise sales reviews, or audit evidence collection. That is the usual reason. More precisely, it gives the customer something concrete to review instead of relying only on a vendor’s answers.
There are two different use cases:
- Obtaining your own SOC 2 report: your organization undergoes an examination of its own controls.
- Reviewing a supplier’s SOC 2 report: your organization evaluates third-party assurance evidence before relying on a vendor.
This article focuses on the second case: what to do when a vendor sends you a SOC 2 report.
How to Review a Vendor’s SOC 2 Report Before Relying on It
Use the report as evidence only after reviewing it against your intended use. The AICPA’s vendor-review aid prompts reviewers to confirm the system, processes, locations, report type and period, Trust Services categories, service auditor, opinion, exceptions, CUECs, subservice organizations, bridge-period coverage, follow-up, and conclusion (AICPA & CIMA).
Third-Party SOC 2 Attestation Review Checklist
| Review item | What to check | Why it matters |
|---|---|---|
| Report identity | Vendor name, report title, service auditor, report date, and opinion. | Confirms you are reviewing the correct report from an independent examiner. |
| Report type | Type I or Type II. | Type I is point-in-time; Type II covers operating effectiveness over a period. Match this to the assurance needed. |
| Audit period or date | For Type II, the period examined; for Type I, the as-of date. | A report may not support a current decision if the examined period leaves a material gap. |
| In-scope services | Products, systems, environments, locations, and processes covered. | A report for one platform or environment may not cover the service your organization uses. |
| Trust Services Criteria | Security, availability, processing integrity, confidentiality, privacy, or a subset. | Do not assume privacy, availability, or confidentiality are covered unless the report says so. |
| Opinion | Unmodified, qualified, adverse, or disclaimer, if stated. | Modified opinions or disclaimers may require escalation before relying on the report. |
| Exceptions | Testing exceptions, affected controls, recurrence, related incidents, and relevance to your use case. | Exceptions may be acceptable, require follow-up, or make the report insufficient depending on risk. |
| Management responses | Specificity, remediation status, timing, and whether the response is inside or outside the auditor’s opinion. | Management’s response may be unaudited unless the report says otherwise. Treat it accordingly. |
| Subservice organizations | Whether key cloud, hosting, infrastructure, or other providers are included or carved out. | Carved-out providers are outside the examined scope and may require separate assurance or review of vendor monitoring. |
| Complementary user entity controls | Customer responsibilities expected for the controls to operate as intended. | If your organization cannot meet those responsibilities, the vendor’s controls may not provide the intended assurance for your environment. |
| Bridge period | Gap between the end of the report period and today; bridge letter or other current assurance. | A bridge letter may help address a gap, but it is management representation, not an extension of the audit. |
| Follow-up questions | Scope gaps, missing criteria, exceptions, remediation, subservice carve-outs, or user responsibilities. | Converts uncertainty into a documented vendor response or escalation. |
| Evidence retained | Completed checklist, review notes, decision, follow-up, approvals, and references to supporting artifacts. | Shows that the report was reviewed rather than merely collected. |
1. Confirm the report type
Start by identifying whether the report is Type I or Type II. A Type I report may be useful when you need evidence that controls were designed and implemented at a specific date. A Type II report is usually stronger evidence for ongoing reliance because it includes operating effectiveness over the examined period, but it still needs to match the service, criteria, scope, and risk decision.
2. Check the audit period
For a Type II report, record the beginning and end dates of the examination period. Assess whether the period is current enough for your current decision and whether significant changes occurred after the period ended.
If there is a meaningful gap, request a bridge letter, the next SOC 2 report, or other current assurance. A bridge letter is issued by service-organization management to address the gap after the SOC report period; the service auditor is not involved, so it does not extend the auditor’s examination or provide the same independent assurance as an updated report (FORVIS).
3. Confirm the in-scope products and services
Read the system description and scope carefully. The report should cover the product, environment, data flow, or managed service your organization will use. If you are buying the vendor’s production SaaS platform, a report covering only a different product line, corporate IT environment, or limited region may not be sufficient.
4. Review the Trust Services Criteria covered
SOC 2 can address security, availability, processing integrity, confidentiality, privacy, or a combination of those categories. Security is common, but do not infer that other categories are included. If your risk decision depends on availability commitments or privacy controls, verify that those categories are explicitly in scope.
5. Identify subservice organizations and carve-outs
Many vendors depend on cloud, hosting, infrastructure, support, or other service providers. The report should explain whether those subservice organizations are included in the examination or carved out.
When a relevant subservice organization is carved out, its controls are excluded from the examined scope. The buyer should review the vendor’s monitoring of that provider and consider separate assurance if the carve-out leaves an important risk unaddressed for the buyer’s purpose (AICPA & CIMA). A carve-out is not automatically a failure, but it is not something to ignore.
6. Review exceptions and management responses
Do not stop at the opinion. Review the testing results and note any exceptions affecting controls relevant to your use of the service.
For each relevant exception, ask:
- Which control and Trust Services Criteria were affected?
- Was the exception isolated or recurring?
- Did it affect systems, data, or processes relevant to your use case?
- Was there a related incident or customer impact described?
- Has management provided a specific remediation plan?
- Is the response time-bound and verifiable?
- Is the response part of the audited report or unaudited management information?
A vague response such as “management will review the process” usually requires more follow-up than a dated remediation statement with an owner, implemented fix, and evidence of retesting or monitoring.
7. Review complementary user entity responsibilities
Complementary user entity controls are controls the service organization expects customers to implement so its service commitments or system requirements can be met (AICPA & CIMA). These may include customer responsibilities for access administration, secure configuration, user provisioning, encryption choices, logging, or incident escalation.
Your review should confirm whether those responsibilities apply to your organization and whether you can meet them. If the vendor’s control environment assumes customers perform actions your team does not perform, the report may not provide the assurance you expect.
8. Document follow-up questions
Follow-up is appropriate when the report leaves uncertainty about scope, period, criteria, exceptions, remediation, bridge coverage, user responsibilities, or subservice organizations. Keep questions specific:
- “Does this report cover the EU production environment we will use?”
- “Was the access review exception remediated, and was remediation tested?”
- “Is the cloud infrastructure provider carved out, and can you provide separate assurance?”
- “Do the listed CUECs apply to our deployment model?”
- “Can you provide a bridge letter or updated report for the period after the audit end date?”
9. Retain evidence of the review
A SOC 2 report is useful as assurance evidence only if the review decision is documented. Retain a completed review record, decision, follow-up evidence, and references to bridge letters or compensating controls in accordance with your access controls, contract or NDA terms, report-use restrictions, and records policy.
How to Decide Whether the SOC 2 Report Is Sufficient
The decision should be based on your intended reliance, the vendor’s role, and the risks created by the outsourced service. The matrix below is editorial guidance, not a legal rule, AICPA standard, or guarantee that another auditor or stakeholder will accept the report.
| Review outcome | What it means | Typical action | Example signals |
|---|---|---|---|
| Accept as sufficient | The report appears aligned to the service and risk decision. | Record the decision and retain review evidence. | Current report; Type and period fit the use case; relevant Trust Services Criteria included; scope covers the service used; no relevant unresolved exceptions; CUECs understood and manageable. |
| Accept with follow-up or compensating controls | The report is usable, but some uncertainty or residual risk remains. | Obtain clarification, document compensating controls, or set a re-review trigger. | Bridge period needs management representation; minor or remediated exceptions require confirmation; scope mostly aligns but needs clarification; CUECs require internal owner confirmation; carved-out subservice provider needs additional review. |
| Escalate or decline as insufficient | The report does not provide enough assurance for the decision. | Escalate to security, GRC, procurement, legal, or risk owners before onboarding or continued reliance. | Report does not cover the service used; required criteria are missing; opinion is modified in a way relevant to the risk; significant unresolved exceptions affect relevant controls; critical carve-outs are unaddressed; user responsibilities cannot be met; report period leaves an unacceptable gap. |
The key is not to force every finding into a pass/fail answer. Some gaps can be resolved with clarification or compensating controls. Others change the risk decision and should probably be escalated before the vendor is approved, at least in most cases.
What Evidence to Retain After Reviewing a Third-Party SOC 2 Attestation
Retained evidence should show that the report was received, reviewed, and used in a reasoned decision. At minimum, keep a record of:
- Vendor and report reviewed.
- Reviewer, review date, and approval or escalation owner.
- Report type, period, service auditor, and opinion.
- In-scope products, systems, locations, and Trust Services Criteria.
- Exceptions reviewed and relevance to your environment.
- Management responses and remediation status considered.
- Subservice organizations and carve-out analysis.
- Complementary user entity responsibilities and internal owners.
- Bridge letter or other current assurance, if requested.
- Follow-up questions and vendor responses.
- Final decision: accept, accept with conditions, or escalate/decline.
- Compensating controls, remediation commitments, or re-review date.
Avoid copying restricted report content into broad-access systems unless your contract, NDA, and internal policy allow it. Where storage is restricted, retain enough metadata, review notes, and approval evidence to show the decision trail without violating report-use limitations.
Making SOC 2 Attestation Reviews Repeatable
One-off SOC 2 reviews become fragile when teams review many vendors or need to support their own audits. A repeatable process should define intake requirements, a review checklist, decision criteria, evidence retention rules, follow-up ownership, and re-review cadence.
That process also reduces confusion between collecting a report and relying on it. The useful control activity is the documented review: confirming scope, period, criteria, exceptions, subservice dependencies, user responsibilities, and the final risk decision. It is easy to mix those up when everyone is busy and the report is just sitting in a folder somewhere.
Ciphrix can support the operational workflow around compliance evidence and risk decisions, but it should not replace professional judgment, vendor risk ownership, or the service auditor’s work. Treat SOC 2 attestation review as a living compliance workflow: structured intake, reusable review evidence, clear ownership, and documented decisions that can be revisited when the vendor, service, or risk changes.