A positive SOC 2 report means an organization has the security controls in place to work with, right? Recent allegations that SOC 2 auditor Delved faked compliance reports reveal the gap between what a document says and what is actually happening inside a vendor’s environment, argues Clarence Chio, CEO of Coverbase.
For years, the SOC 2 report has been the de facto signal of trust in B2B software. Enterprise procurement teams demand it, sales teams race to get it, and once a vendor hands it over, everyone breathes a little easier and moves on. When an independent auditor reviews a company’s security controls and signs off, the implicit message is that there’s no further need to dig deeper.
At least that was the case.
That implicit trust is now under serious scrutiny following allegations against Delve, the Y Combinator-backed compliance startup that raised $32 million at a $300 million valuation. A group calling itself DeepDelver, made up of anonymous, former customers who compared notes, published a detailed investigation based on a leaked internal spreadsheet, alleging that Delve systematically fabricated audit reports for hundreds of clients.
The allegations are significant. According to the investigation, 493 of 494 SOC 2 reports examined were nearly identical, containing the same paragraphs, grammatical errors and nonsensical descriptions, with only the company name and logo changed. The group also accused the auditor of including pre-written conclusions and test procedures in draft reports before clients had submitted any evidence and allowing trust pages to go live the moment clients first logged in. Board meeting minutes were allegedly fabricated. Risk assessments reportedly came pre-filled with default entries.
Delve has denied the allegations, and it is important to note that they remain unproven. But the questions they raise about the SOC 2 framework itself deserve serious attention regardless of how the Delve matter is ultimately resolved.
How did we get here
Delve didn’t invent the underlying problem. What these allegations suggest is that it may have industrialized it.
The original SOC 2 model required an independent, licensed auditor to review a company’s security controls, examine evidence and issue an opinion. The process was expensive and slow because doing it right takes time and genuine expertise. A proper SOC 2 engagement required auditors to spend meaningful time with the team, going through controls in granular detail. That thoroughness was the point. When a vendor showed up with a SOC 2, it meant something.
Over time, the compliance automation market grew rapidly, with new entrants promising to compress months of work into days and significant costs into a fraction of the original investment. For businesses trying to unlock enterprise deals gated by SOC 2 requirements, the appeal was obvious.
The risk was always that when speed and cost become the primary selling points of a compliance product, something could give.
The stakes are not abstract
For most software companies, the consequences of a fraudulent compliance report would be primarily legal and reputational. For companies handling protected health information, the exposure is far more serious. HIPAA violations can result in significant mandatory penalties and potential criminal liability.
The downstream implications of the Delve situation extend well beyond the company itself. At least one public company reportedly marketed “SOC 2 Type II audited” status in SEC filings based on a Delve report. Enterprise customers, including some large technology companies, appear to have accepted Delve-issued compliance documentation as part of their vendor review process.
Every enterprise security team that accepted a Delve report as evidence of a vendor’s security posture may now have a gap in its audit trail, and the document they relied on could, in the end, be worthless.
The right question was never ‘Do you have a SOC 2?’
However the Delve situation plays out, these discussions highlight something the vendor risk management industry has known for some time but has been slow to act on: A document is only as reliable as the process behind it.
The SOC 2 model is built on a chain of trust. The vendor trusts the auditor, the enterprise trusts the report, and the whole system rests on the assumption that the audit actually happened. The allegations against Delve didn’t invent a flaw in the SOC 2 framework. Instead, they revealed how thin that chain of trust can become under pressure.
The question “Does this vendor have a SOC 2?” was always the wrong question. The right question is “Does this vendor actually do what their SOC 2 claims?” Those are not the same question, and the answer to the first tells you almost nothing about the answer to the second.
A SOC 2 Type II report was never meant to be a security guarantee. It is confirmation that specific, scoped controls operated effectively during a defined observation window. When that attestation is generated before any evidence is gathered, it no longer provides evidence of anything.
What the industry needs to reckon with
The vendor risk community’s immediate response, requiring companies that received Delve-issued documentation to seek independent verification before relying on those reports in risk decisions, is the correct protocol for this specific crisis. But it doesn’t resolve the larger question the situation raises.
The deeper issue is that the compliance industry built its trust infrastructure on a foundation of documents and point-in-time attestations. The Delve allegations are an extreme example of what can go wrong, but the underlying vulnerability — that is, the gap between what a document says and what is actually happening inside a vendor’s environment — predates Delve and will outlast it.
Rebuilding trust in vendor risk management means grappling with that gap honestly. It means asking harder questions about what attestations actually measure, how observation windows are defined and whether the evidence behind a certification reflects current operational reality, or is it just a snapshot taken under controlled conditions months ago.
Clarence Chio is CEO and co-founder of TPRM platform Coverbase. 
