Menu
How to Check If Your SOC 2 Report Is Real
Not every SOC 2 report in circulation was actually audited. Some were generated by software before any auditor reviewed them, signed by entities that don’t hold CPA licenses, and shipped to customers as proof of compliance. The underlying testing — reviewing access logs, verifying controls, sampling evidence — either happened superficially or didn’t happen at all.
If you have a SOC 2 report and a nagging feeling, here’s how to find out whether yours holds up.
Ten checks. Most take five minutes. None require an accounting background. By the end, you’ll know whether your report is structurally sound — or whether you have a real problem.
These checks cover structure and conformance, not the depth of the underlying testing. A structurally clean report can still reflect shallow audit work. The checks here are the minimum bar. The deeper questions live in the linked pieces.
At a Glance: Ten Checks
Section 1: Start with the auditor — before you open the report
Start outside the report. Check who signed it.
Check 1: Confirm the auditor holds an active CPA license
A SOC 2 report can only be issued by a licensed CPA firm. Not a “compliance firm.” Not a “certification body.” Not a company that calls itself an auditor without holding a CPA license. The opinion letter has to come from a licensed practitioner — no exceptions.
Find the firm name on the opinion letter. Search for that firm on the state board of accountancy for the state listed on the report. Every state has a public license lookup. If there’s no active CPA license on file, stop. The document you’re holding is not a SOC 2 report. It looks like one.
Some illegitimate firms list US addresses but hold no CPA licensure — the address is a mailbox or virtual office. The check is the state board, not the address. A city on the letterhead proves nothing.
Check 2: Confirm the auditor is enrolled in the AICPA Peer Review Program
Every CPA firm performing SOC 2 audits must be enrolled in and current with the AICPA Peer Review Program. This is a professional requirement for firms doing attest work — not an optional quality badge.
Search the public file at peerreview.aicpa.org/public_file_search.html. Type in the firm name. Look for: current enrollment, a review date within the last three years, and an opinion of Pass.
What each rating means — and when Pass with Deficiency is acceptable vs. disqualifying — is covered in our AICPA Peer Review guide. For now: if the firm doesn’t appear, or their enrollment has lapsed, that’s disqualifying. Don’t read further until you have an answer.
Section 2: Check the opinion letter
The opinion letter is where the auditor states what they examined and what they concluded. Two structural checks live here.
Check 3: Is the opinion letter dated?
The service auditor’s opinion has to carry a date. No date, no valid report. This is a structural requirement under AICPA professional standards — not a stylistic preference.
Open the report. Find the opinion letter — usually one of the first sections, signed by the CPA firm. Look at the bottom. There should be a date. If there isn’t, the report is nonconforming. Period.
Check 4: Are Management’s Assertion and the auditor’s opinion dated in line with each other?
Management signs an assertion saying the system description and controls are fairly presented. The auditor signs an opinion based on that assertion plus their testing. Standards govern the sequencing: the auditor’s opinion can’t predate the moment they obtained sufficient evidence, which includes a signed assertion from management.
In practice, both are usually dated the same day. A small gap isn’t automatically a problem. The red flag is an auditor’s opinion dated before management’s assertion. That sequence is backwards — the auditor concluded before management made the statement the auditor was supposed to be evaluating. If you see it, ask the auditor to explain in writing.
Section 3: Read the system description
The system description is where the company describes itself: services, infrastructure, people, processes, and data. This is what the auditor tests against. Most structural problems in fabricated reports show up here — writing a real system description requires knowing the company.
The AICPA specifies what this section must contain — nine criteria in all. You don’t need to know all nine. The three below you can check from the outside without specialized training.
Check 5: Does the system description actually describe the data?
One of the description criteria covers system components — and data is one of those components. A conforming description names the categories of data the company handles (customer records, payment information, health data, whatever applies), explains how it’s classified, and shows how it flows through the system.
Look for a section that does more than gesture at data. Named categories. Classification language. Some account of how data moves — ingested, processed, stored, transmitted, deleted. Diagrams are common. A written walkthrough works too.
If the description mentions data in a single sentence — “the system handles customer data” — and moves on, that’s a structural gap. If data doesn’t appear in the system components discussion at all, the description doesn’t conform.
Check 6: If the description mentions what the customer is responsible for, does it actually list those things?
Most SaaS SOC 2 reports include a section about controls the customer — the “user entity” in audit terminology — is expected to implement on their side. These are called complementary user entity controls (CUECs). The description criteria require the system description to disclose them.
Look for a list of things your company is expected to do. It might be labeled “user responsibilities,” “customer controls,” “complementary controls,” or something similar. Items vary by product — password policy management, SSO configuration, data classification on your end — but there should be a list.
If the description references customer responsibilities without listing them, it’s incomplete. And if the report has no CUECs at all for a product that obviously creates shared security responsibilities, that’s a quality signal on top of the structural problem. A real audit of a multi-tenant SaaS product almost always identifies CUECs. A report with none suggests the auditor didn’t look.
Check 7: If the report carves out vendors, does it explain what those vendors are responsible for?
Most SOC 2 reports exclude major infrastructure providers from audit scope — AWS, GCP, and Azure are the common examples, each with their own SOC 2. When a vendor is carved out, the description criteria require the description to: (a) identify the vendor and what it does, (b) describe the controls the company expects the vendor to perform, and (c) explain how the company monitors the vendor.
Search the report for “subservice organization” or the names of major vendors (AWS, GCP, Azure, Snowflake, Stripe). Find the section that addresses them. It should answer three questions: what does the vendor do, what controls do you rely on them for, and how does the company verify they’re performing them.
If any of those three is missing, you have a structural gap. If major vendors aren’t mentioned at all for a product that obviously runs on cloud infrastructure, the description doesn’t reflect reality.
Section 4: Read the opinion and the testing section together
Check 8: Do the Trust Services Criteria in the report match what you signed up for?
A SOC 2 engagement covers specific Trust Services Criteria: Security (always required) plus, in various combinations, Availability, Processing Integrity, Confidentiality, and Privacy. What’s in scope should match the engagement letter.
Pull out the engagement letter. Compare the criteria listed there against what appears in the auditor’s opinion. Agreed to Security and Availability but the report covers only Security? That’s a scope gap. Report covers criteria you didn’t agree to? Ask why.
If you can’t find a signed engagement letter, that’s the first problem to solve.
Check 9: Are all the Trust Services Criteria covered in the testing section?
The testing section — usually Section 4 of the report — is where the auditor documents what they actually tested. For every control: what it is, what testing procedure they used, what they found.
Take the list of Trust Services Criteria from the auditor’s opinion. Skim the headings in Section 4. Every criterion in the opinion should have corresponding tested controls in Section 4. If a criterion appears in the opinion but has nothing tested in the testing section, the report is missing required documentation.
The criteria are named explicitly. The headings are labeled. Five minutes.
Check 10: Are the principal service commitments substantive, or do they read like marketing copy?
The report should include the company’s stated commitments to customers and the system requirements that support them. Specific — tied to actual security controls, availability thresholds, or data handling practices.
Red flag: a commitment that says “we will keep your data secure.” That’s not a service commitment. That’s a sentence. A conforming commitment ties a stated promise to an actual operational requirement — something like “the system maintains 99.5% monthly uptime, supported by redundant load balancing and automated failover.”
If the service commitments section reads like a sales page, the underlying audit work is probably thin.
One structural check most people miss
Bonus check: If the report references “Other Information,” does that section actually exist?
Some SOC 2 reports include an “Other Information” section — typically Section 5 — where the company adds context outside the formal audit scope. If the auditor’s opinion references this section, it has to exist. Standards require the auditor to read any “other information” for material inconsistencies with the audited portions.
If the opinion references a section that isn’t there, the auditor either skipped that step or used a template they didn’t finish filling out. Either way: low care. Possibly worse.
An advanced check — for readers willing to go further
If you have access to a second report from the same auditor, compare them side by side.
Most SOC 2 reports are confidential. But if you have access to another report from the same firm — through a partner, a customer, or a public source — open them together.
What you’re looking for: identical narrative language across two meaningfully different companies. The system description, the testing language, the service commitments — these should differ substantially, because they describe two different systems. If two reports from the same auditor read like the same document with the company name swapped, the auditor isn’t examining systems. They’re shipping a template.
This won’t apply to most readers. For those it does, it’s one of the strongest signals available.
What to do if something’s wrong
The range runs from minor issues a good auditor can fix in an afternoon to problems that suggest the underlying work was never sound. Three paths.
Go back to the auditor. For structural issues — a missing date, incomplete CUEC disclosures, a mismatch between the opinion and the testing section — a qualified auditor can issue a corrected report. The testing may be sound; the documentation may just be sloppy. Ask for the corrected version in writing, with a clear explanation of what changed and why.
Get a second opinion. If the auditor can’t or won’t fix it, or if the problems suggest the testing itself was shallow, bring in a different CPA firm. An independent reviewer can tell you whether a re-audit is needed or whether the existing work can be corrected.
Disclose proactively. If the report is materially wrong and you’ve already shared it with customers as proof of compliance, you may have an obligation to correct the record. This is especially acute if you handle health data or EU resident data. Talk to counsel before deciding. This guide isn’t legal advice.
We match companies with independent CPA firms who can review an existing report or run a new audit. No platforms. No referral kickbacks. No rubber stamps. Find an auditor →
A report that passes every check here isn’t guaranteed to be good. Structural conformance is the floor, not the ceiling. Quality lives in the testing — what the auditor actually examined, how deeply, and what they found.
But a report that fails any of these checks is nonconforming. That’s a different category of problem — one that warrants a direct conversation with whoever signed it.
Better checklists aren’t the long-term answer. The answer is engaging auditors who have their own reputation to protect — firms that stand behind their work because their name is on it, not because a referral pipeline depends on it. The checklist is the minimum. Auditor selection is what raises the bar.
For a deeper look at evaluating the auditor themselves — peer review status, AICPA standing, scope letter analysis — see our AICPA Peer Review guide. For a primer on SOC 2 itself, see SOC 2 Compliance.