SOC 2 Report Review: 9 Red Flags

A SOC 2 report can be authentic, recently issued, and irrelevant to the product you are buying.

Before approving a vendor, connect the report to your purchase: the service, the data it will receive, and the controls your organization needs.

Each of these nine red flags is a reason to investigate. A narrow report can suit a narrow service. An exception may have a credible resolution. Decide what needs an explanation, evidence, or escalation before approval.

1. Are you getting a badge instead of a reviewable report?

A badge or completion letter cannot show you the scope, opinion, and detailed findings needed for a report review. Ask for the issued SOC 2 report through the vendor's approved sharing process.

An NDA request is ordinary. SOC 2 reports have a restricted audience; Schellman explains their restricted-use status. A public SOC 3 report is a different deliverable with less detail, as the AICPA's SOC 3 overview confirms.

Investigate when an eligible buyer cannot assess the vendor, even through controlled access. Identify the issuing CPA firm and use our auditor selection guide for background checks.

Ask: Can our security reviewer access the complete issued report, and what sharing restrictions apply?

2. Does the scope match the product and entity you will use?

A company name on the cover does not establish coverage for every product, subsidiary, or hosting environment. Compare the system description with your order form and architecture.

Check the legal entity, service names, deployment model, locations, and exclusions. Renaming may need an explanation; an acquired platform may require separate assurance.

Also check the included Trust Services Categories. Security coverage does not mean every other category was examined. Schellman's scoping guidance explains how system boundaries and category selection define the examination. See our SOC 2 requirements guide.

Ask: Which report sections connect our contracted service and deployment to the audited system?

3. Is a Type 1 report being treated as evidence over time?

Type 1 evaluates control design and implementation at a specified date; Type 2 also evaluates operating effectiveness over a specified period. A-LIGN explains this distinction.

A Type 1 report can be useful. Trouble starts when it substitutes for historical testing your procurement policy requires. Agree on any interim acceptance conditions and planned Type 2 delivery.

Read our Type 1 versus Type 2 comparison and guide to SOC 2 in two weeks before accepting a fast delivery claim.

Ask: What type was issued, and what assurance does it provide for our decision?

4. Is the time since the examination left unexplained?

The coverage end date matters separately from the date the auditor issued the report. A recently issued document may describe an earlier operating period.

Record both dates and ask about subsequent incidents, migrations, acquisitions, or material control changes. Judge that gap against your vendor policy and the service's importance. There is no universal expiry date to substitute for that judgment.

A bridge letter supplies management's statements about the intervening period. It does not extend the auditor's testing. Linford's bridge-letter guidance explains that management signs it and that it cannot replace the report. Our audit timeline guide helps separate the stages.

Ask: What changed after the period ended, and when is the next report expected?

5. Does the auditor's opinion need more explanation?

A qualified opinion, adverse opinion, or disclaimer requires careful attention to the auditor's stated basis.

A qualification identifies material issues whose effects, or possible effects from missing evidence, are limited rather than pervasive. An adverse opinion indicates material and pervasive issues. A disclaimer means the auditor could not obtain sufficient evidence to express an opinion. The AICPA's report review checklist explains these distinctions in Appendix 4.

Escalate an adverse opinion or disclaimer for a critical service to the vendor risk owner. An unmodified, also called unqualified, opinion still applies only within the examined system and period.

Ask: How does the basis for this opinion affect our data or service, and what evidence supports the proposed resolution?

6. Are exceptions dismissed without context or evidence?

An exception needs interpretation: the affected control, test results, frequency, impact, and response all matter.

An isolated documentation lapse and repeated failures to remove privileged access create different questions. Read sample information, compensating controls, and management's response. Check prior reports for recurrence. Schellman explains that exceptions do not automatically produce a qualified opinion.

A promise to fix an issue is not evidence of a completed fix. Request proportionate remediation evidence, distinguishing management's explanation from independent retesting. Our SOC 2 evidence guide introduces common evidence types.

Ask: What failed, who was affected, what changed, and who verified that change?

7. Are carved-out providers being counted as audited?

Under the carve-out method, relevant subservice organization controls are excluded from the examination's testing. Their appearance in the system description does not change that boundary.

Carve-outs are legitimate. A hosting service may support commitments you rely on while its controls sit outside this examination. Linford explains how inclusive and carve-out treatment differ.

Identify complementary subservice organization controls, or CSOCs, and ask how the vendor evaluates them. See our vendor management gaps guide.

Ask: Which relevant providers were carved out, and what assurance and monitoring support those dependencies?

8. Do customer obligations have no owner on your side?

A report can assume actions that your organization must perform, so assign those actions before deployment. Read any complementary user entity controls, or CUECs, and other customer responsibilities.

These terms are distinct. CUECs are necessary, together with the vendor's controls, to achieve its service commitments and system requirements. Other user responsibilities help customers obtain the intended benefit of the service without being necessary to meet the vendor's commitments. A report can legitimately have no CUECs, as K Financial explains using AICPA guidance.

For each applicable obligation, identify an owner, implementation step, and evidence. Approval should account for whether your team can perform it.

Ask: Which obligations apply to our deployment, and who will demonstrate that we meet them?

9. Is a new AI feature borrowing the older product's assurance?

A report covering an existing platform does not, by itself, establish coverage for a later AI feature. Match the feature's release, data flows, model providers, and permissions to the described system and examination period.

Ask where prompts and outputs go, how agent actions are authorized, and which controls address changes and monitoring. These questions help establish scope. Schellman's AI guidance also explains that SOC 2 does not cover every AI risk.

Inspect identities and permissions with our AI agents and SOC 2 guide.

Ask: Which evidence covers this AI feature, and which risks require separate evaluation?

What should you record in a buyer's SOC 2 checklist?

Record what supports approval, what remains unresolved, and who will act. Copy this checklist into your review, adding a report section or evidence reference beside each item:

• Record the issued report's version, CPA firm, and sharing restrictions.
• Locate the entity, product, deployment, and categories supporting this purchase.
• Confirm that the report type meets our assurance need.
• Record coverage dates, subsequent changes, and the next expected report.
• Explain the opinion's implications for our use of the service.
• Document relevant exceptions and the evidence supporting remediation.
• Identify carved-out dependencies and how the vendor monitors them.
• Assign applicable customer obligations to named owners.
• Match AI features to evidence and record any separate evaluation needed.

Finish with: Decision, rationale, open issue, owner, due date, and next review trigger. Unresolved items may require conditional approval or escalation under your policy.

FAQ

Does a SOC 2 exception mean we should reject the vendor?

No. Evaluate its relevance, severity, recurrence, and remediation evidence against your intended use and risk policy.

Does a bridge letter renew a SOC 2 report?

No. It provides management's statements about a later period without extending the auditor's examination.

Is refusing to publish a SOC 2 report publicly suspicious?

No. Restricted sharing is expected. Investigate an unexplained refusal to provide sufficient review information through an appropriate controlled process.

Does SOC 2 prove an AI feature is safe?

No. Verify feature coverage and the relevant controls, then evaluate risks outside the report's scope separately.