Until last week, most security teams reviewed vendor SOC 2 reports with a basic checklist: is it Type II, does it cover the right trust service criteria, are there any exceptions? The Delve scandal just added a new prerequisite to that list: is this report even real?
With 494 fabricated SOC 2 reports now in the wild, enterprise security teams and vendor risk analysts need new heuristics. Here are the 10 red flags that indicate a SOC 2 report may be fraudulent, template-generated, or otherwise unreliable.
The 10 red flags
1. The report was completed suspiciously fast
A legitimate SOC 2 Type II requires a minimum observation period of 3-12 months during which controls must be operating. Type I requires no observation period but still takes weeks of genuine audit work. If a company went from zero to SOC 2 Type II in under three months, something was skipped.
Delve marketed SOC 2 "in days." That should have been the first warning sign for everyone involved.
2. The system description is generic
Section 3 of a SOC 2 report is the system description, written by the service organization. It should describe your specific infrastructure, data flows, people, and processes. If the system description reads like it could apply to any SaaS company — generic references to "cloud infrastructure," "encryption at rest and in transit," "role-based access controls" without naming specific products, architectures, or configurations — it may be templated.
In the Delve reports, every client received the same system description. A healthcare AI company processing PHI had the same description as a dev tools startup.
3. Zero exceptions across the entire report
A clean SOC 2 report with zero exceptions is not inherently suspicious. But across hundreds of organizations? Every single Delve Type II report claimed zero security incidents, zero personnel changes, and zero deviations during the observation period. That is statistically impossible.
If you are reviewing a vendor's SOC 2 and see zero exceptions, ask follow-up questions about how they handled specific scenarios during the observation period. A company that genuinely has zero exceptions should be able to explain in detail how they avoided them.
4. You cannot verify the auditor
SOC 2 audits must be performed by a licensed CPA firm. Verify the firm exists, is licensed, and has a real practice. Delve used firms like Accorp (traced to Indian operations using virtual US addresses) and Gradient Certification (registered in Wyoming through a mailbox agent).
Check the CPA firm's state board registration. Check their AICPA peer review status. Look at their website, their team page, their client list. If the audit firm is harder to verify than the company being audited, that is a red flag.
5. The report has identical formatting to known Delve templates
The leaked Delve reports contained specific grammatical errors that appeared in nearly every document, including "has developed an organization-wide Information Security Policies" (incorrect pluralization) and "because there no security incidents reported" (missing verb). If a vendor's SOC 2 report contains these specific errors, it was generated by Delve's system.
6. The trust page shows 100% completion on everything
Delve-powered trust pages displayed 100% completion across all controls, often listing penetration tests, disaster recovery simulations, and security training that never actually occurred. No real compliance program is 100% at all times. Genuine compliance involves ongoing work, and honest trust pages reflect that.
7. The vendor cannot explain their controls in conversation
This is the simplest and most effective test. Ask the vendor's engineering or security team to walk you through a specific control mentioned in their SOC 2 report. How do they handle access reviews? What does their change management process look like? What happened during their last incident?
A company with genuine controls can discuss them confidently and in detail. A company with a Delve-generated report will struggle to answer because the controls described in the report may not match their actual operations.
8. No complementary user entity controls (CUECs)
A well-written SOC 2 report includes CUECs — controls that the service organization's customers need to implement on their end. The absence of CUECs suggests the auditor did not deeply consider the actual deployment model and data flow. Template reports rarely include meaningful CUECs because they require understanding the specific service.
9. The observation period is suspiciously convenient
Look at the observation period dates in the report. Does the period align with when the company likely started their compliance effort? If a company was founded in January and has a SOC 2 Type II with an observation period starting in February, the timeline is implausible for genuine control operation.
10. The vendor uses an unknown compliance platform
Not all compliance platforms are created equal. Established platforms like Vanta, Drata, and Secureframe have track records and are well-understood by the auditor community. If a vendor uses a platform you have not heard of, especially one that promises unusually fast timelines or low costs, investigate further before accepting the report at face value.
What to do when you find a red flag
Finding one or two of these red flags does not definitively mean the report is fraudulent. But it warrants additional diligence:
- Request a bridge call with the vendor's security team to discuss their controls directly
- Ask for supplementary evidence such as penetration test reports, access review logs, or incident response records
- Verify the auditor independently through state CPA board registrations and AICPA peer review records
- Compare reports if you have SOC 2 reports from other vendors audited by the same firm, compare the language and structure
- Consider a security questionnaire as a supplement to the SOC 2 report, not a replacement
The post-Delve standard: A SOC 2 report should be the starting point of vendor risk assessment, not the end of it. The report tells you what the auditor tested. Your job is to verify that the auditor's work was genuine and that the controls are real.
Need help with vendor risk assessment?
We help organizations evaluate vendor security beyond checkbox compliance. Real assessments, real findings, real security.