How to Evaluate a Vendor’s SOC2 Report
2026 Procurement Guide
Most enterprise security and procurement teams receive SOC2 reports without a clear framework for evaluating them. This guide covers the four sections of a SOC2 report, what matters in each, five green flags, ten red flags, and the questions to ask your vendor after review.
A SOC2 report has 4 sections: management assertion, system description, trust services criteria, and auditor opinion. The most important section for procurement purposes is the auditor opinion (Section IV) combined with the exceptions sub-section in Section III. Read those two areas first. The system description (Section II) tells you whether the audit scope actually covers the product and data you care about. Many procurement reviews fail because teams accept a report without checking whether the scope matches their use case.
The 4 Report Sections and What to Look for in Each
Management Assertion
A statement from vendor management asserting that the description of their system is accurate and that the controls were suitably designed and operating effectively.
This section requires little scrutiny — it is management's own statement. Its main value: confirm it is signed by an appropriate executive (CISO, CEO, CFO) and that the assertion period matches the observation period you care about.
System Description
A narrative description of the vendor's system: infrastructure components, data flows, security controls, personnel, and subservice organizations.
This is where you verify scope. Confirm: (1) the products you use are explicitly described, (2) the data types you share (PII, financial records, health data) are included in scope, (3) all infrastructure providers that touch your data are disclosed as subservice organizations, (4) the geographic regions where your data is processed are listed.
Watch out: Narrow scope is the most common procurement trap. A SOC2 that covers an internal tool or a sandbox environment does not provide assurance about the production environment you are actually using.
Trust Services Criteria — The Core
The detailed control testing section. For each TSC in scope (Security, Availability, Confidentiality, etc.), the auditor lists the control, describes how they tested it, and notes any exceptions found.
Go directly to the exceptions sub-section. Count the exceptions. Read each exception description. Categorize them: (a) administrative/documentation failures, (b) operational control failures. Operational failures (encryption not implemented, access not revoked) are more concerning than documentation failures (review performed but not evidenced). Note which TSC contains exceptions and whether those TSC are relevant to your risk profile.
Auditor Opinion — What You Actually Care About
The CPA firm's professional opinion on whether the controls were suitably designed and operating effectively during the observation period.
Four possible opinions: Unqualified (clean — all tested controls effective), Qualified (specific controls failed, report otherwise valid), Adverse (controls broadly failed — rare), Disclaimer (insufficient evidence to form opinion — very rare). Unqualified is the standard expectation. Anything else requires follow-up. Also note: the name of the issuing CPA firm, the observation period dates, and whether the opinion is a Type 1 or Type 2.
Watch out: Verify the issuing CPA firm independently via the AICPA firm search. Reports issued by non-CPA entities are not valid SOC2 reports regardless of how they are labeled.
5 Green Flags: Signs of a Strong Report
Unqualified opinion with zero or minimal exceptions
Clean opinion with no exceptions in the exceptions section means all tested controls operated effectively throughout the observation period.
12-month observation period
A full 12-month period demonstrates sustained control operation across all four quarters, including periods of likely stress (year-end, hiring surges, product launches).
Comprehensive system description with named subservice organizations
A detailed system description that clearly names infrastructure providers, describes data flows, and discloses all relevant subservice organizations shows the audit was thorough.
Multiple TSC in scope
Security TSC is baseline. Availability and Confidentiality in scope (with relevant controls tested) indicates a more mature security program attuned to enterprise customer requirements.
Report from a recognized audit firm
Firms like Schellman, Coalfire, A-LIGN, Johanson Group, and Prescient Assurance have established SOC2 practices. Name recognition is not a guarantee of quality, but it reduces the risk of an underprepared auditor.
10 Red Flags: Warning Signs in a Vendor’s Report
Qualified or adverse opinion
The most serious signal. Read the exceptions section immediately. Adverse opinions are rare and mean the controls broadly failed. Qualified opinions identify specific control failures. Assess the severity and whether the failed controls are relevant to how you use the vendor.
More than 3–5 exceptions in the report
Even with an unqualified opinion, the exceptions section may list control deviations that did not rise to the level of qualification. More than 3–5 exceptions, especially in access control or data protection domains, signals an immature compliance program.
Short observation period (less than 6 months)
A SOC2 Type 2 with a 3-month observation period is technically valid but provides far less assurance than a 12-month period. A very short period may indicate the vendor rushed to certification with minimal evidence of sustained control operation.
Suspiciously narrow scope
Check the system description carefully. If the audit scope covers only a single non-production environment, excludes subservice organizations that process your data, or describes a system that bears little resemblance to what you actually use — the report may not apply to the services you are procuring.
Unknown audit firm — verify AICPA license
SOC2 reports must be issued by a licensed CPA firm. Any firm can claim to offer SOC2 audits. Verify independently via the AICPA firm search or your state CPA board that the issuing firm holds a current CPA license. Reports from non-licensed entities are not valid SOC2 reports.
Report older than 12 months
SOC2 reports do not technically expire, but a report dated more than 12–18 months ago provides limited current assurance. Controls and environments change. Ask the vendor for their current report or, if it is genuinely outdated, require a bridge letter from the auditor attesting that no material changes have occurred.
Missing subservice organization disclosures
If the vendor uses AWS, GCP, Azure, or other critical infrastructure providers, the report's system description should disclose these subservice organizations and explain whether their controls are included (carved-in) or excluded (carved-out) from scope. Missing disclosure may mean the scope is narrower than the vendor is implying.
Vague or generic system description
The system description should describe the vendor's actual environment: specific products, infrastructure components, data flows, user types, and geographic locations. A vague description that could apply to any cloud company suggests the description was not written for the actual system being audited.
No penetration test mentioned
While SOC2 does not require penetration testing, its absence from a report is a signal. Most mature security programs include annual pen tests, and auditors often reference them as evidence for vulnerability management controls. Ask your vendor about their pen test cadence separately.
CPA firm with no SOC2 history
Verify that the issuing firm has performed multiple SOC2 engagements before. New entrants to the SOC2 auditing market sometimes lack the depth to identify genuine control failures. Check the firm's published experience, client references, and whether they are on any vendor's approved auditor list.
Questions to Ask Your Vendor After Reviewing
These questions should be part of your standard vendor security review template. Ask them in writing and retain the responses as part of your vendor risk documentation.
Which specific products and environments are included in the audit scope? Which are excluded?
Are there any exceptions or control deviations noted in the report, and what is the remediation status for each?
When is your next observation period scheduled to end, and when do you expect to issue your next report?
Do your subservice organization disclosures include all infrastructure providers that process our data?
Can you provide a bridge letter if your current report is more than 6 months old?
Has your penetration test been performed within the last 12 months? Can you share the executive summary under NDA?
Are there any material changes to your control environment since the last audit period?
What a Qualified Opinion Means for Your Vendor Relationship
Receiving a report with a qualified opinion from a vendor you are already using requires a structured response — not an automatic termination, but not silence either.
Identify which controls failed. Cross-reference against your contract and DPA. Assess whether the failed controls relate to how you use the vendor — a failure in the vendor's HR training program is less relevant to your risk than a failure in their access controls.
Ask the vendor in writing: what failed, what did they do about it, and when do they expect a clean opinion. A vendor with a credible, documented remediation plan is in a very different position than one that responds defensively or with vague assurances.
Some MSAs require you to notify your customers of upstream vendor security findings. Your legal team should review before you take any action — either demanding remediation from the vendor or communicating with your own customers.
If the failed control represents a gap you care about, consider whether you can implement a compensating control on your end (e.g., additional access logging, data minimization, network segmentation) while the vendor remediates.
For more context on what a qualified opinion means from the vendor side, see the qualified opinion emergency guide and the 10 most common SOC2 control failures.
Frequently Asked Questions
What is the most important section of a SOC2 Type 2 report?
For enterprise procurement purposes: Section IV (Auditor Opinion) first, then the exceptions section within Section III (Trust Services Criteria). The opinion tells you the high-level result. The exceptions section tells you exactly which controls failed, what the auditor found, and how many deviations occurred. A clean opinion with 6 exceptions is meaningfully different from a clean opinion with zero exceptions.
What is the difference between a Type 1 and Type 2 SOC2 report?
A SOC2 Type 1 report assesses whether controls are suitably designed at a point in time — it does not test whether they actually operated effectively. A SOC2 Type 2 report covers an observation period (typically 6–12 months) and tests whether controls operated as designed throughout that period. For enterprise procurement, Type 2 is the standard. Type 1 is acceptable only for early-stage vendors who have not yet completed a Type 2.
How do I handle a vendor who only has a Type 1 report?
For non-critical vendors, a Type 1 combined with a vendor questionnaire is usually acceptable. For critical vendors — those with access to production data, PII, or financial information — require a timeline for Type 2 completion and build a contractual commitment into your MSA. Do not accept a Type 1 indefinitely for critical vendors. Set a review date 6 months out and require Type 2 completion before renewal.
Can I request a SOC2 report from a vendor who has not shared it?
Yes. Enterprise vendors with SOC2 are expected to share reports under NDA on request. If a vendor refuses to share their SOC2 report with a legitimate enterprise buyer, treat that refusal as a serious red flag. Legitimate reasons to delay sharing include: report in progress, NDA not yet signed, or legal review required. An outright refusal without a credible explanation is a dealbreaker for most enterprise security teams.
What should I do if the vendor's SOC2 report covers a different product than what I am buying?
Ask the vendor to clarify whether the scope explicitly covers the specific product, environment, and data type you are procuring. A SOC2 for 'Product A' does not provide assurance about 'Product B' even if they run on the same infrastructure. If the scope does not cover your use case, treat the vendor as if they have no SOC2 and evaluate accordingly.