On March 8th, I published an article titled Beyond the Dashboard: What SaaS Compliance Tools Can and Can’t Do for PCI-DSS. It wasn’t a hot take or a reaction piece. It was a measured assessment of a structural problem I’ve seen repeatedly as a QSA: organizations treating platform-generated compliance packages as proof of security maturity when they’re not designed to provide that level of assurance.
I named Delve alongside Vanta, Drata, and Secureframe. I described what assessors actually see when these packages land on our desks. Templated policies that don’t match the organization’s real operations. Evidence captured at a single point in time with no indication of sustained enforcement. Scoping decisions that minimize the assessment footprint in ways that look defensible on paper but fall apart under scrutiny.
Eleven days later, on March 19th, an anonymous investigation published on Substack under the name “DeepDelver” alleged that Delve had been doing exactly what the compliance community feared, but at a scale and with a brazenness that even skeptics didn’t anticipate.
What the Investigation Alleges#
The DeepDelver Substack is worth reading in full. The allegations are specific and documented.
The investigation claims that Delve generated auditor conclusions and test procedures before independent review occurred, effectively writing the audit opinion and then routing it to partner firms for a signature. The analysis of 494 SOC 2 reports found 99.8% content similarity across client documents, including identical grammatical errors and nonsensical sentences. Test values that appear to be keyboard mash (“sdf”, “dlkjf”) showed up verbatim across reports from different clients. Trust pages allegedly displayed security certifications for controls that were never implemented.
The investigation also raises concerns about auditor independence. According to DeepDelver, virtually all Delve client reports flowed through two primary audit firms described as operating primarily out of India with minimal US presence. If those firms were signing off on reports that Delve itself generated, that’s not an audit. That’s a transaction.
TechCrunch picked up the story on March 21st. The Hacker News thread quickly accumulated hundreds of comments. By this weekend, the GRC community on LinkedIn was fully engaged.
Why This Isn’t Surprising#
I want to be direct about something: none of the structural problems alleged in the DeepDelver investigation are new to anyone who’s spent time on the assessor side of compliance.
In my March 8th article, I wrote:
“We notice policies that appear to be templates because they reference organizational structures, roles, and processes that don’t quite match the company’s actual operations. We see evidence of controls captured at a single point in time with no indication that the control is enforced consistently.”
That observation wasn’t about Delve specifically. It was about the entire category. The compliance automation market has been growing at over 50% year-over-year. When that much money flows into compressing timelines and reducing friction, the incentive structure starts pulling in a predictable direction: speed becomes the product, and assurance becomes the thing that gets optimized away.
The Delve situation, if the allegations hold up, represents an extreme case. But the underlying pattern is visible across the industry. Startups that have never operated a security control for a sustained period end up with polished compliance packages that look indistinguishable from organizations with mature, battle-tested programs. The dashboards turn green. The PDFs get filed. And the risk gets absorbed by whoever’s on the other end of the vendor relationship.
The Auditor Independence Problem#
The most serious allegation in the DeepDelver investigation isn’t about templates or boilerplate. It’s about auditor independence.
SOC 2 engagements are governed by AICPA attestation standards, specifically AT-C Section 205. The entire framework depends on a clear separation between the entity being examined and the practitioner performing the examination. The company describes its systems and controls. The auditor independently designs tests, performs procedures, and forms an opinion based on evidence they collected and evaluated.
If a compliance platform is generating auditor conclusions before the auditor has performed independent testing, that’s not a process optimization. That’s a structural violation of the independence requirement that gives a SOC 2 report its credibility.
This is where the PCI DSS parallel is direct. The PCI Security Standards Council maintains qualification programs for QSAs specifically to preserve this separation. A QSA company can’t both implement controls for a client and then assess those same controls. The assessment has to involve independent professional judgment applied to the specific environment, the specific data flows, and the specific risks that organization faces. Templates can help organize the work. They can’t replace the judgment.
Implications for vendor risk programs#
One of the most telling comments from the Hacker News thread on this story: “No one cared about security posture. They cared about insurance policies.”
That’s reductive, but it captures something real about how enterprise vendor risk management works in practice. Many programs are built to collect documents, not evaluate them. A SOC 2 report arrives, it gets filed, it satisfies a procurement requirement, and nobody reads past the opinion letter. That workflow works fine when the reports are legitimate. It falls apart completely when they’re not.
The Delve situation forces a question that every enterprise security team should be asking right now: how would we know if a vendor’s compliance report was fabricated?
The honest answer for most organizations is that they wouldn’t. And that’s a problem that existed long before this specific scandal. Delve just made it impossible to ignore.
In my March 8th piece, I listed questions that enterprises should ask when reviewing vendor compliance packages. Those questions are more relevant this week than they were when I wrote them:
Can anyone at the vendor explain their controls in conversation? Not recite them from a dashboard. Explain them. What risk does this control address? What happens when it fails? How do you know it’s working? If the vendor’s compliance team can’t have that conversation without pulling up a platform, the controls may be configured but not understood.
Who performed the assessment, and what was the actual scope? Not the platform that organized the evidence. The firm or individual who validated it. Can you verify their credentials independently? Can the vendor explain the scoping rationale without reading it off a report?
What’s the vendor’s track record with findings? Any organization that has been rigorously assessed will have findings. A vendor claiming a clean record either hasn’t been tested thoroughly or isn’t being transparent about the results.
Has anything changed since the last report? Startups ship new infrastructure, adopt new integrations, and restructure their teams constantly. If the vendor can’t explain how those changes were evaluated against their compliance requirements, their last report may already be stale.
The PCI DSS Connection#
This story broke in the SOC 2 world, but the implications extend directly to PCI DSS.
The same compliance automation platforms serve both markets. The same incentive structures apply. The same compressed timelines get marketed. And the same structural risk exists: a company can end up with a polished PCI compliance package that doesn’t reflect the actual security posture of their cardholder data environment.
PCI DSS 4.0.1 introduced requirements that are specifically difficult to automate well. Targeted risk analyses under the customized approach require documented reasoning about why a control meets the intent of the requirement in the context of a specific environment. Requirements 6.4.3 and 11.6.1 demand ongoing monitoring of payment page scripts, which requires understanding the actual data flows and third-party integrations, not just toggling a setting in a dashboard. Requirement 12.3.1 now mandates that organizations perform targeted risk analyses to support controls where the frequency isn’t explicitly defined by the standard.
A platform can organize the evidence for those requirements. It can’t produce the professional judgment that makes the evidence meaningful. That’s the assessor’s job, and it can’t be templated.
What Should Change#
The compliance automation industry isn’t going away, and it shouldn’t. These platforms solve real problems for organizations that need help navigating complex frameworks. But the Delve situation exposes gaps that the industry and its customers need to address.
Enterprises need to verify, not just collect. If your vendor risk program consists of receiving PDFs and filing them, this story is your wake-up call. Build verification steps into the process. Ask for assessor credentials independently. Ask for evidence that the assessment period involved actual observation of controls over time, not a compressed sprint.
Compliance platforms need to stay in their lane. Evidence collection, control mapping, continuous monitoring, and workflow automation are all legitimate and valuable capabilities. Generating auditor conclusions is not. The line between “assisting with compliance” and “producing compliance artifacts” needs to be clear, visible, and enforced.
Assessors and auditors need to protect the independence model. The credibility of SOC 2, PCI DSS, and ISO 27001 depends on independent professional judgment. When that judgment gets outsourced to the platform being assessed, the entire assurance model collapses. Professional bodies like the AICPA and the PCI SSC need to pay attention to this story and consider whether their oversight mechanisms are catching what they should be catching.
Regulators should be watching. No regulatory body caught 494 allegedly identical SOC 2 reports. An anonymous Substack investigation did. That’s worth reflecting on.
The Takeaway#
Two weeks ago, I wrote that “a compliance report should be the beginning of a conversation, not the end of one.” That statement feels heavier now.
The Delve allegations, whether they’re ultimately proven or not, have exposed a structural vulnerability in how the compliance industry operates. Speed and accessibility are valuable. But when they come at the cost of independent assurance, the reports produced aren’t protecting anyone. They’re creating a false sense of security that gets absorbed by every organization downstream.
If you’re an enterprise evaluating vendor compliance, ask harder questions. If you’re a startup using one of these platforms, make sure you actually understand your controls, not just your dashboard. And if you’re an assessor, keep doing the work that makes these frameworks mean something.
The green checkmarks on the dashboard were never the point. The security underneath them is.
This is a follow-up to my March 8th article, Beyond the Dashboard: What SaaS Compliance Tools Can and Can’t Do for PCI-DSS. If you haven’t read that piece, the context will help.
The Delve situation is still developing. DeepDelver has indicated a Part II is forthcoming. I’ll update this post if material developments change the picture significantly.
