SOC 2 Report Red Flags: What Customer Reviewers Look For

Customers’ security reviewers read a SOC 2 report for the opinion, the period, the scope, the testing detail, and the firm that signed it. Trust drops when the report is described as more than it is, covers short or broken periods, arrives with its findings explained away, or shows signs of a thin audit. Most of these come from choices the company being reviewed makes itself, so most can be fixed.

Each flag below covers what the reviewer sees, what you can do instead, and a question for reviewers. To read a report section by section, see how to read a SOC 2 report; for signs of a faked one, see how to check if a SOC 2 report is real.

The 13 red flags at a glance

Thirteen signals that lower a reviewer's trust in a SOC 2 report, and what the company being reviewed can do about each.

Red flag	What the reviewer sees	What to do instead
"SOC 2 certified" or "SOC 2 compliant"	A claimed status the report does not grant	Name the report type, criteria, period, and CPA firm
The report offered as proof the product is secure	A claim broader than an opinion on named controls over a past period	State the system, criteria, and period the report covers
A badge or trust page in place of the report	No way to read the opinion, scope, or test results	Share the full report under NDA through a set request process
A Type 1 where the customer needs a period	Design on one date, with no operating-effectiveness testing	Give the Type 2 start date and expected report date
Every report covers 3 months	Little evidence the controls run the same way outside audit windows	Plan back-to-back, lengthening periods at the first engagement
Months no report covers	Time no auditor tested	Start each period where the last one ended
A scope that misses the product being bought	A clean report about a different service or environment	Scope the audit to what customers buy, and say upfront what sits outside it
Exceptions called "normal"	A request to judge an average report instead of this one	Bring the cause, fix, and dated evidence for each exception
Disputing findings after issuance	A vendor account that conflicts with the signed report	Raise disagreements on the draft, then show the fix
Zero exceptions alongside thin testing	A clean result the test descriptions cannot explain	Choose an auditor whose tests name your systems and samples
Templated or inquiry-heavy testing	Test steps that could describe any company	Ask how the firm tailors its tests before you sign, and check the draft
A report dated very soon after the period ended	A timeline that may not fit the work described	Choose a firm on its approach, not its turnaround promise
No findable peer review or license for the signing firm	No outside check on the auditor	Confirm the license and read the peer-review result before you sign

How you describe the report

Do you call it “SOC 2 certified” or “SOC 2 compliant”?

Calling a SOC 2 report a certification is a red flag because SOC 2 produces an attestation report, a CPA firm’s opinion on controls, and no certificate. It usually appears as “SOC 2 certified” or “SOC 2 compliant” on a website, sales deck, or questionnaire answer. A Journal of Accountancy article on SOC report quality describes compliance as “a term never used in SOC 2 examinations”. The wording does not weaken the report, but it can suggest the company does not know what its report says, and the reviewer reads everything else more closely.

What to do instead: describe the report the way it describes itself, for example a SOC 2 Type 2 report on the security criteria for a named product, covering a stated period, issued by a named CPA firm. Fix it on the website, trust page, sales decks, and stored questionnaire answers. Our page on whether SOC 2 is a certification has suggested answers to “Are you SOC 2 certified?”

If you are the reviewer, ask: which report type, criteria, period, and CPA firm stand behind this claim?

Do you say the product is secure because of the report?

Claiming that a SOC 2 report proves the product is secure is a red flag because the report is narrower than the claim. A security page might say the report proves the platform is secure, but a Type 2 report is a CPA firm’s opinion that the described controls were suitably designed and operated effectively over a past period, for the system and criteria the company chose to put in scope. It says nothing about the time since the period ended, systems outside the scope, or risks the criteria do not address. A claim that reaches past those limits can lead the reviewer to discount the company’s other claims.

What to do instead: state what the report covers (the system, the criteria, and the period) and let the reviewer draw the security conclusion.

If you are the reviewer, ask: which system and period does the opinion cover, and what falls outside it?

Is a badge or trust page offered instead of the report?

Offering a badge, trust page, or letter instead of the SOC 2 report lowers a reviewer’s trust because none of them shows the opinion, the scope, or the exceptions. The reviewer gets a logo, a trust-center summary, or a letter saying an audit took place, with no route to the report itself. SOC 2 reports are restricted to specified parties, so a request to sign an NDA first is normal. Refusing an eligible customer any access is not.

What to do instead: keep a public trust page that names the report type, period, and auditor, and share the full report under NDA through a defined request process. Our short answer on whether customers can see your SOC 2 report covers what to publish and what to gate.

If you are the reviewer, ask: can we read the complete issued report, and on what terms?

Is a Type 1 offered where the customer needs a period?

Offering a Type 1 where the customer needs a Type 2 delays the review because a Type 1 report covers the design of controls on a single date and contains no tests of operating effectiveness.

What to do instead: call the Type 1 what it is and give the start date of the Type 2 period and the expected report date. SOC 2 Type 1 vs Type 2 explains which report customers accept.

If you are the reviewer, ask: when does the Type 2 period start, and when is that report due?

What the period shows

The period dates sit near the front of the report, in the auditor’s opinion and management’s assertion. Reviewers who see more than one report read the pattern across them.

Does every report cover only 3 months?

Reports that always cover 3 months lower a reviewer’s trust because they show one tested quarter a year, with the remaining months untested. A 3-month first Type 2 is a common way to get a report out for a near-term deal, but a second or third report that still covers 3 months reads differently. The AICPA publishes no minimum Type 2 period in its SOC 2 reporting guide, so the length is a choice the company and its CPA firm make, and reviewers read it as one.

What to do instead: plan the path to back-to-back periods at the first engagement. If a short first window fits the deal, agree with the CPA firm at the same time when the next period starts and when the periods lengthen. Our observation-period guide covers how customers read the period you choose.

If you are the reviewer, ask: why this length, and when will the periods reach the length our policy expects?

Are there months no report covers?

Months that no report covers are a red flag because no auditor tested that time. The reviewer lines up the periods of successive reports and finds months between one period’s end and the next one’s start. A bridge letter cannot fill them, because it covers only the time after the latest period ends and it is signed by management, not the auditor.

What to do instead: start each period the day after the previous one ended, and keep a bridge letter ready for the time since the latest period. If a gap already exists, explain it plainly and show how the next period closes it. The SOC 2 audit renewal playbook covers keeping periods continuous.

If you are the reviewer, ask: do the periods run back to back, and what covers the time since the latest one ended?

Does the scope miss the product the customer will use?

A scope that misses the product the customer is buying leaves the purchase uncovered, however clean the opinion. The system description names the products, environments, and criteria in scope, and reviewers compare it with the order form. A product, region, or newer feature outside that boundary is not covered.

What to do instead: scope the audit around what customers buy, and when something sits outside it, say so before the reviewer finds it, with the plan to bring it in. The vendor questions in our guide to reading a SOC 2 report show how reviewers test scope.

If you are the reviewer, ask: which part of the system description covers the service in our contract?

How you handle findings

Are exceptions called “normal” or the opinion “typical”?

Calling exceptions “normal” or a qualified opinion “typical” lowers a reviewer’s trust because it asks them to judge an average report instead of this one, and it usually leads to a closer read. The reviewer hears that everyone gets exceptions on that control, or that a qualified opinion is standard.

What to do instead: for each exception, bring the cause, the fix, and dated evidence that the corrected control has operated since. Our exceptions guide covers what helps and what backfires when customers review your exceptions.

If you are the reviewer, ask: what caused each exception, and what evidence shows the fix has worked?

Do you dispute the auditor’s findings?

Disputing the auditor’s findings after the report is issued costs credibility, even when the company has a point, because the reviewer holds the CPA firm’s signed report and was not part of the fieldwork. A management response, or a sales call, says the auditor got a finding wrong. Management’s response is unaudited, and reviewers read it as the company’s claim.

What to do instead: disagree while the report is still a draft. Correct misstated processes and give the auditor any evidence it did not see. Once the report is final, accept the finding as written and show what changed. The chair of the AICPA’s SOC 2 Working Group told the Journal of Accountancy that companies which value a proper examination realize “findings are an opportunity to improve controls”.

If you are the reviewer, ask: was this raised with the auditor before issuance, and what has changed since?

Zero exceptions everywhere: is that a flag?

Zero exceptions is not a red flag on its own, but it lowers a reviewer’s trust when it comes with templated or generic test descriptions, because a clean result tells the reviewer only as much as the testing behind it. A well-run program with a careful auditor can produce a Type 2 with no exceptions, and treating every clean report as suspect penalizes the companies that did the work. It becomes a question when the test descriptions are so generic that a reviewer cannot tell how the auditor reached any result.

What to do instead: never try to manufacture or hide findings. What you control is the auditor. A firm whose tests name your systems, populations, and samples lets a clean result read as clean.

If you are the reviewer, ask: for the controls we rely on, what population was tested and how was the sample chosen?

What the audit itself shows

These flags come from the auditor’s work, but the company chose the auditor, the price, and often the timeline. Customers notice the difference. The Journal of Accountancy article warns that “a savvy partner will spot a cookie-cutter report”.

Does the testing look templated or inquiry-only?

Test descriptions that look templated or rest mostly on inquiry lower a reviewer’s trust because steps that could describe any company do not show how the auditor reached a result. The reviewer finds the same wording for every control, no mention of the company’s systems, no populations or sample counts, and many tests that rest on asking staff. The AICPA’s May 2026 guidance to peer reviewers, reported in the Journal of Accountancy, flags engagements with “identical reports, risk assessments, sample sizes, and testing procedures”. Peer review treats such engagements as “nonconforming”, meaning not performed in line with professional standards. A February 2026 Journal of Accountancy article adds that a rushed or overly automated report may “rely too heavily on inquiry”, and suggests companies check whether a finished report is “tailored to the specifics of the system being examined”.

Test descriptions usually name one or more of these methods:

Inquiry rests on what people say, so on the controls they rely on, reviewers usually look for at least one of the other methods.

Illustrative example, not from a real report, for the control “new users are approved before they get access”:

A reviewer looks for named systems, the population, the sample, and evidence from the period. The templated version shows none of them.

What to do instead: before you sign, ask the firm how it tailors its risk assessment and tests to your system and what sampling procedures it will use. When the draft arrives, check that the test descriptions name your systems and populations. The side-by-side comparison in our authenticity checks shows what templated wording looks like across two reports.

If you are the reviewer, ask: for the controls we rely on, which tests went beyond inquiry?

Was the report dated very soon after the period ended?

A report dated very soon after the period ended gives a reviewer a reason to ask whether the timeline fits the work described. The reviewer compares the end of the period with the date on the auditor’s opinion, and the AICPA has asked peer reviewers to look at the reasonableness of SOC 2 engagement timelines, and to treat timelines that “appear unreasonable” as a sign of elevated risk. No AICPA rule sets a minimum number of days between the period end and the report, and a well-prepared company whose auditor tested during the period can receive its report quickly. A fast report is a question a reviewer may ask, not a finding.

What to do instead: choose a firm on its approach rather than a promised turnaround. Ask how much testing happens during the period, and keep that answer ready for reviewers.

If you are the reviewer, ask: when was the testing done, and how much of it happened during the period?

Can you find the signing firm’s peer review and license?

A signing firm with no findable peer review or license leaves the reviewer with no outside check on the auditor. The reviewer looks up the CPA firm named in the opinion in the AICPA Peer Review public file and with the state board of accountancy. The Journal of Accountancy’s advice to companies buying a SOC 2 report includes this step: “Evaluate the firm’s qualifications, experience, and peer review results.” A firm that does not appear in the public file is a question for the vendor, not proof of a problem.

What to do instead: run both checks before you sign the engagement letter, not after a customer runs them for you. Our peer review guide explains each result, and the CPA licensing guide covers state-board lookups. You can filter the SOC 2 auditor directory by AICPA peer-review status.

If you are the reviewer, ask: what is the firm’s latest peer-review result, and is it licensed to issue this report?

If you are reviewing a report and find these flags

A flag is a reason to ask for more, not a verdict. Three steps usually cover it:

1. Ask for the evidence the flag calls for, such as test detail for a control you rely on, or dated evidence that a fixed exception has operated since.
2. Decide whether safeguards or contract terms cover the residual risk, for example a right to the next report or notice of material changes. Our guide to SOC 2 vendor management requirements covers vendor due diligence and contract terms.
3. Escalate where a flag touches the data or service you rely on. For a qualified opinion, see exceptions and qualified opinions.

What to settle before your next audit

Most of the flags above are settled before fieldwork starts. Five decisions cover them:

1. Wording. Replace “certified” and “compliant” on the website, trust page, sales decks, and stored questionnaire answers with the report type, criteria, period, and CPA firm.
2. Period plan. Agree with the CPA firm how each period will follow the last with no gap, and when the periods will reach the length your customers expect.
3. Auditor. Read the firm’s peer-review result, confirm its license, ask how it tailors tests and selects samples, and question any offer that looks unrealistically fast or cheap.
4. Findings. Name who reviews the draft and raises disagreements before issuance, and who prepares the cause, fix, and evidence for each exception.
5. Report sharing. Set the NDA, the request route, and the person who answers reviewers’ questions, and keep a bridge letter ready.

To compare firms by peer-review status, pricing, and timeline, use the SOC 2 auditor directory. To see what firms would charge for your scope, request ballpark quotes; your company stays anonymous until you choose who to talk to.

Frequently asked questions

Can you fail a SOC 2 audit?

There is no pass or fail grade, but a report can come back with a qualified, adverse, or disclaimer opinion instead of an unmodified one, and customers’ reviewers read that opinion first. What happens if you fail a SOC 2 audit covers the path back to a clean report.

Is a SOC 2 report confidential?

Yes. A SOC 2 report is restricted to specified parties, so companies share it under NDA rather than posting it publicly. A SOC 3 report is the short public version. See whether customers can see your SOC 2 report.

How long is a SOC 2 report good for?

The AICPA sets no expiry date. Customers set their own rule, and many expect a report whose period ended within roughly the last 12 months. A management-signed bridge letter can cover a short gap after the period ends. See the bridge letter guide and the SOC 2 audit renewal playbook.