You're deep in a vendor review. The security questionnaire comes back. Box ticked: SOC 2 compliant.

Job done, right?

Not quite.

"SOC 2 compliant" is one of the most casually misused phrases in enterprise sales. Some vendors genuinely have it. Others have a report that's two years old, scoped to cover approximately nothing, and written by an auditor whose independence is... questionable. A few are just hoping you don't ask for the actual document.

This guide tells you exactly what to ask for, what to look for, and what should make you stop and ask harder questions.

First: There's No Central SOC 2 Registry

Let's get this out of the way. Unlike some certifications — ISO 27001, for instance — there is no public database of SOC 2 compliant organizations. No lookup tool. No official list you can cross-reference.

SOC 2 is an attestation, not a certificate. The output is a report, not a badge. And evaluating that report is a critical step in assessing any vendor's genuine commitment to security, privacy, and compliance.

Which means verification comes down to: asking for the right documents and knowing what they should contain.

What to Actually Request

1. The SOC 2 Report Itself (or a Summary Letter)

The most direct form of verification is the full SOC 2 report. Most vendors will share it under NDA — if they won't, treat that as a red flag worth probing.

A complete SOC 2 report should include several key components: an overview of the report, management's assertion, a description of the system and services provided, control objectives, control descriptions, control testing methodology, and the auditor's results and opinion. If any of these sections are missing or vague, that's worth querying.

Can't get the full report? A summary letter from the auditor is acceptable in many contexts. It should confirm:

The audit period
The type of report (Type I or Type II)
The Trust Services Criteria covered
Whether any exceptions were noted

Summary letters are common practice. A flat-out refusal to share either is unusual.

2. Check the Report Date — It Has a Shelf Life

Typically, a SOC 2 report must have been issued within the last 12 months to be considered current. If the report you're looking at is older than that, you're working from stale data — and a lot can change in a year.

If there's a gap between the report period and today, ask for a bridge letter (sometimes called a gap letter). This is issued by the auditing firm to confirm no material changes to controls have occurred since the report period ended. It's not a substitute for a current report, but it's a reasonable stopgap while the next audit completes.

No bridge letter available and the report is getting stale? Ask when the next audit is underway. A compliance-mature vendor will have an answer ready.

3. The Auditor's Credentials

SOC 2 audits must be conducted by a licensed CPA firm. You can verify whether a firm is a registered member of the AICPA's peer review program — a basic quality check on the auditor themselves.

An audit conducted by a well-regarded, specialist firm carries more weight than one from a general practice CPA who treats SaaS audits as a side project. The rigor of the audit process directly affects how much you can trust the results.

What to Look For Once You Have the Report

Type I vs Type II — Know the Difference

This is where a lot of verification falls apart. People see "SOC 2" and assume it means the same thing every time. It doesn't.

SOC 2 Type I evaluates whether a vendor's controls are designed appropriately at a specific point in time. It's essentially a design review — a snapshot. There's no assessment of whether those controls actually worked over any meaningful period.

SOC 2 Type II assesses whether controls were operating effectively over a defined period — usually a minimum of six months. This gauges real operational effectiveness, not just intent. This is the report that actually demonstrates sustained compliance.

If a vendor is waving a Type I report and calling themselves SOC 2 compliant, they're not lying — but they're not telling the full story either. Type I is a starting point. Type II is the standard a lot of enterprise buyers and security teams require.

So, what should you ask for? For any vendor relationship involving sensitive data or customer data, you want Type II. Minimum six-month audit window, ideally 12.

The Scope Section

SOC 2 reports are scoped. The controls reviewed only apply to whatever systems and services the vendor chose to include. A vendor can pass a SOC 2 audit for one product while running a dozen others that were never assessed.

This is one of the most commonly overlooked potential issues in vendor compliance reviews.

Always check:

Which products or services are in scope?
Which data centers or cloud environments are covered?
Are subprocessors included or explicitly excluded?

If the system or product you're using isn't clearly described in the system description section, ask directly whether it's covered. Any compliance-mature vendor will answer without hesitation.

Trust Services Criteria Covered

SOC 2 is built around five Trust Services Criteria (TSC), and understanding which ones are covered is essential for making informed decisions:

Security (Common Criteria) — the only mandatory criteria; covers information security and access controls
Availability — whether systems are available for operation as agreed
Processing Integrity — whether system processing is complete, accurate, and timely
Confidentiality — protection of information designated as confidential
Privacy — how personal information is collected, used, retained, and disposed of

Most service organizations include Security. Some include Availability and Confidentiality. Fewer cover Privacy and Processing Integrity.

What you need depends on your use case. If you're sharing personal data, Privacy criteria matters. If your operations depend on the vendor's uptime, Availability should be there. If data integrity is critical — say, for financial reporting or transaction processing — Processing Integrity belongs in scope too. Match the criteria covered against what actually matters for your specific relationship.

Control Objectives, Control Descriptions, and Testing

Beyond which criteria are covered, dig into the substance of how controls were tested and what the results showed.

A rigorous SOC 2 report will document specific controls, explain the control testing procedures used, and present the results of that testing clearly. What you're looking for is evidence that security controls aren't just written down — they're operating as intended.

Relevant controls should map to real processes: how access is managed, how incidents are handled, how security event management works in practice, how ongoing monitoring is conducted. If the control descriptions are vague or the testing methodology feels thin, that's worth pushing on.

Also worth checking: whether the report references complementary user entity controls (CUECs). These are controls that your organization — as the customer — is expected to implement for the vendor's controls to function effectively.

If CUECs exist and you're not meeting them, the vendor's clean report doesn't protect you.

The Auditor's Opinion — And What Qualifications Mean

This is the part most people skip. Don't.

The auditor's opinion section is where control effectiveness is formally assessed. It will either be:

Unqualified — no exceptions noted. Controls were operating effectively throughout the audit period.
Qualified — exceptions were found. Some specific controls didn't perform as described.

A qualified report isn't automatically a dealbreaker, but it demands a conversation. What were the control failures? What remediation has the vendor completed since? Is there evidence those gaps have been addressed?

An exception on a non-critical control is very different from one on access management, incident response, or data breach handling. Context matters — but you can only apply that context if you actually read the opinion section.

FAQ: Common Questions About SOC 2 Verification

Can I verify SOC 2 compliance without seeing the full report?

Yes — a summary letter from the auditor, or confirmation via a third-party trust center (like Hicomply's public trust pages), is a reasonable starting point. But for any high-risk vendor relationship involving sensitive data or regulatory requirements, the full report under NDA is the standard.

How do I know if a SOC 2 report is still valid?

Check the audit period end date. A SOC 2 report is typically considered current if it was issued within the last 12 months. If it's older than that with no bridge letter in place, the report is stale. Ask when the next Type II audit is scheduled to complete.

Is a SOC 2 certification the same as ISO 27001?

No. SOC 2 is a US-origin attestation framework governed by the AICPA, focused on service organizations and the Trust Services Criteria. ISO 27001 is an internationally recognized certification built around a broader information security management system. They overlap on information security and security controls — but they're different standards with different verification processes and other standards may be more relevant depending on your region and regulatory requirements.

What's a trust center and is it a reliable verification method?

A trust center is a public-facing security page where vendors publish their compliance efforts and status, often with links to certificates or summary reports. They're a useful quick reference — but they're vendor-controlled. Always request the actual report for high-stakes procurement decisions.

Does SOC 2 cover subprocessors?

Not automatically. The report covers what's in scope. Subprocessors (e.g., cloud infrastructure providers, third-party tools) may or may not be included. If your vendor uses AWS, GCP, or Azure, those providers typically maintain their own SOC 2 reports. Your vendor should be able to clarify what's covered under their report and what sits outside their audit scope.

Should I assess a vendor's processes beyond the report itself?

Yes. SOC 2 compliance verification should also include assessing the vendor's processes for ongoing monitoring, incident response, and security event management. A report is a point-in-time or period-based assessment — understanding how a vendor operates day-to-day, and how they respond when things go wrong, gives you a fuller picture of their security posture and ability to mitigate risks going forward.

What Should Make You Pause

A few things that warrant a harder look before you proceed:

The report is Type I only — for an established vendor, this is unusual after the first year. Why haven't they demonstrated operating effectiveness over a sustained period?
The audit window is very short — some vendors rush short-period audits to get a report quickly. Shorter windows mean thinner evidence of sustained control effectiveness.
The auditing firm is unfamiliar or unverifiable — do a basic check. Is it a real, registered CPA firm with a track record in SaaS audits?
The audit scope doesn't clearly cover your product — verify explicitly. Don't assume.
Multiple exceptions with vague remediation — chase this. What were the control failures? What's been fixed, and how can you verify it?
No answer on subprocessors — if a vendor can't tell you whether their key infrastructure providers are covered, that's a gap in their own understanding of their compliance requirements.

None of these is automatically a dealbreaker. But each deserves a clear answer before you sign anything. SOC 2 compliance verification isn't just about checking boxes — it's about building trust and ensuring genuine security practices are in place.

If You're on the Other Side: Making Verification Easy for Your Customers

If you're the vendor fielding these requests — and the process feels like it swallows hours every time — that's a signal your compliance operations need a rethink.

Modern compliance teams don't scramble to find the latest report or draft custom summary letters per request. They operate a living system: audit-ready documentation, a live trust center, automated evidence collection, and a clear record of when the next audit is due. All of it accessible, current, and evidenced.

That's not aspirational. It's what a systematic approach to compliance automation actually delivers. When a prospect asks for your SOC 2 report, the answer should be: "Already uploaded to our trust center. Here's the link." Not three emails, a Slack thread, and a hunt through shared drives.

Continuous assurance — knowing your controls are operating and evidenced at all times, not just in the weeks before an audit — is what separates compliance teams that are genuinely audit ready from those who are hoping the auditor doesn't look too closely.

How Hicomply Helps

Hicomply is built for compliance teams that want SOC 2 done properly — and kept that way.

That means continuous control monitoring, automates evidence collection, audit-ready documentation, and full visibility into what's in scope, what's covered, and what's coming up for renewal. No spreadsheets. No last-minute scrambles. No qualified reports caused by a controls gap nobody spotted until the audit was already underway.

Whether you're achieving SOC 2 Type II for the first time or maintaining it across multiple audit cycles, Hicomply gives you the structure to turn compliance into a process that actually works — and makes verification a five-second job for anyone who asks.

Some just comply. Others, Hicomply.

Ready to make your next SOC 2 audit the least stressful one you've had? Book a demo with Hicomply.