A Y Combinator-backed compliance startup raised $32 million, earned a $300 million valuation, and promised to get companies compliant in days using AI. Then a whistleblower exposed what was allegedly happening behind the platform: pre-filled evidence, fabricated board minutes, rubber-stamped audit reports, and certification mills posing as independent U.S.-based auditors.
The Delve scandal is not just a story about one company. It is a case study in what happens when organizations treat compliance as a checkbox to clear quickly rather than a function to build correctly. And it raises urgent questions about how companies evaluate compliance automation vendors before handing over control of their most sensitive programs.
If your organization relies on a third-party platform for SOC 2, ISO 27001, HIPAA, or any other framework, the lessons here apply directly to you.
What happened at Delve, and why it matters beyond one startup
In March 2026, an anonymous whistleblower published a detailed investigation on Substack accusing Delve of systematically misleading hundreds of customers into believing they were compliant with privacy and security regulations when they were not.
The key allegations, as reported by TechCrunch, Inc., and others:
- Pre-fabricated evidence. The platform allegedly generated fake board meeting minutes, risk assessments, and security simulation records that customers could adopt with a single click, without performing any actual work.
- Certification mills as auditors. Instead of the “U.S.-based CPA firms” Delve marketed, over 99% of clients were allegedly routed to firms like Accorp and Gradient, described by the whistleblower as offshore operations with minimal U.S. presence that rubber-stamped reports generated by Delve itself.
- Platform acted as both implementer and examiner. Audit conclusions, test procedures, and final reports were allegedly pre-written by Delve before any independent review occurred, a structural violation of AICPA independence requirements under AT-C Section 205.
- Insight Partners scrubbed its investment endorsement. Delve’s lead investor reportedly deleted a promotional post about its $32 million investment following the allegations.
- Delve paused product demos. The company suspended demonstrations as the story gained traction across Hacker News, Reddit, and X.
Affected companies reportedly include Lovable, WisprFlow, Cluely, Bland, Browser Use, and NASDAQ-traded Duos Edge, among hundreds of others. Many of these companies process protected health information (PHI) for millions of U.S. consumers.
Delve has denied the allegations, calling the Substack post “misleading” and stating that final reports and opinions are issued solely by independent, licensed auditors. The situation remains developing.
The real risk is not AI. It is vendor opacity.
The initial reaction to the Delve story focused on whether AI can be trusted in compliance, but there’s a different angle we want to explore.
AI and automation have a legitimate, valuable role in compliance programs. Evidence collection, continuous monitoring, policy gap analysis, questionnaire automation: these are real efficiency gains that reduce manual work and help teams focus on judgment-intensive tasks.
The problem at Delve, based on the public allegations, was not that they used AI. The problem was that their customers could not see what was happening behind the platform.
When a compliance automation vendor controls what evidence is generated, which auditor reviews it, and what the final report says, the customer has no independent way to verify that their program is real. That is a third-party vendor risk management failure, not a technology failure.
Consider the pattern the whistleblower described:
- Policies were pre-populated with security claims the platform could not deliver on. Customers adopted them without modification because they trusted the vendor’s process.
- Integrations were labeled as automated when they actually required manual screenshots. The platform displayed 120+ integrations, but the whistleblower alleged only a small fraction functioned as real integrations.
- Trust pages went live before any work was completed, listing security measures that were never implemented.
- When customers raised concerns, Delve’s response was to get them on a call, name-drop high-profile clients, and send donuts.
Every one of these issues could have been identified through proper vendor due diligence before signing a contract. The question is whether your organization has a framework for doing that evaluation, or whether you are relying on logos, demos, and sales pitches.
If you have ever read about substance over form in compliance programs, this is the vendor-side equivalent. A platform that produces the appearance of compliance without the underlying controls is just as dangerous as a policy that exists on paper but is not followed in practice.
7 questions to ask before you trust a compliance vendor
Vendor due diligence for compliance platforms should be at least as rigorous as the vendor risk assessment you perform on any critical third-party service provider. If you are trusting a platform with your SOC 2, ISO 27001, or HIPAA program, these seven questions should be part of your evaluation.
1. Who is the auditor, and who chose them?
Delve allegedly routed the vast majority of clients to a small number of audit firms that the whistleblower described as “certification mills.” Clients were not always aware of who was auditing them until the process was already underway.
What to ask: Can I bring my own auditor? Are the auditors in your network accredited by ANAB (for ISO 27001) or licensed CPAs in good standing with the AICPA (for SOC 2)? Can I verify their credentials independently?
2. Can I see the raw evidence before the report is finalized?
The Delve allegations describe a process where evidence was pre-filled by the platform and customers could adopt it without review. Some customers reportedly received fake evidence for employees who had never completed any compliance tasks.
What to ask: Do I review and approve every evidence artifact before it is submitted to the auditor? Is there a documented sign-off process that proves my team verified each piece of evidence?
3. What percentage of evidence is auto-generated vs. manually verified?
Automation is valuable when it pulls real data from your actual systems. It becomes a liability when it generates synthetic evidence that represents work that was never performed.
What to ask: For each control, can you show me exactly what the platform automates and what requires human input? What is the ratio of automated evidence collection to manual review in a typical engagement?
4. Does the platform separate evidence collection from audit judgment?
This is the structural issue at the heart of the Delve allegations. Under AICPA rules (AT-C Section 205), the party implementing controls cannot be the party attesting to their effectiveness. If the platform writes the auditor’s conclusions, the independence requirement is violated and the entire attestation is potentially invalid.
What to ask: Does the platform generate any portion of the auditor’s report, test procedures, or conclusions? Is there a clear independence wall between the platform’s role and the auditor’s role?
5. How does the vendor handle integrations it cannot automate?
The whistleblower alleged that many of Delve’s listed integrations were simply containers for manual screenshots, not real data connections. The gap between “we integrate with 120+ tools” and “you need to manually screenshot your firewall settings” is significant.
What to ask: For my specific tech stack, which integrations pull data automatically and which require manual input? Can I see a live demo of the integrations I would actually use?
6. Can I export my compliance data to another platform?
If you cannot leave a vendor, you cannot independently verify your compliance posture. Vendor lock-in creates a dependency that compounds risk over time, especially if the vendor’s process turns out to be deficient.
What to ask: Can I export all evidence, policies, and reports in a standard format? If I switch vendors, what do I retain and what do I lose?
7. Has the vendor’s own security posture been independently assessed?
Following the Delve allegations, a security researcher reportedly identified significant vulnerabilities in Delve’s own infrastructure. A compliance vendor that cannot secure its own systems is a material risk to every client on the platform.
What to ask: Where is your own SOC 2 Type 2 report? Has your platform undergone independent penetration testing, and can I see the results? How do you handle responsible disclosure?
What a trustworthy compliance automation workflow actually looks like
Compliance automation, done correctly, follows a clear separation of responsibilities. Here is what the process should look like when the vendor, the customer, and the auditor each stay in their lane.
- You define scope and controls with a qualified advisor. A compliance professional (internal or external) helps you identify which controls apply to your business, your products, and your risk profile. This is not a step that should be skipped or auto-generated.
- The platform automates evidence collection from your actual stack. Real integrations pull real data from your cloud infrastructure, identity provider, code repository, HR system, and other tools. The platform organizes this evidence against your control framework.
- You review and approve every artifact. Your team and your compliance advisor review the evidence before it goes anywhere. Nothing is submitted to an auditor without your explicit sign-off.
- An independent auditor, selected by you, assesses the evidence. The auditor designs their own test procedures, evaluates the evidence independently, and forms their own conclusions. They are not reading a script written by the platform.
- The auditor issues the opinion. The final report is the auditor’s professional judgment, not a document generated by the platform and signed by the auditor after the fact.
Contrast this with the Delve model as described by the whistleblower, where steps 1, 3, and 4 were allegedly collapsed. The platform defined the controls (with pre-populated templates), generated the evidence (including fabricated artifacts), and wrote the auditor’s conclusions before any independent review took place.
The difference between these two workflows is the difference between a compliance program that protects your business and one that exposes it.
Why this matters for your SOC 2, ISO 27001, HIPAA, or PCI DSS program
The framework you are pursuing determines the specific risks you face if your vendor cuts corners.
SOC 2. A Type 2 report covers a defined observation period during which controls are supposed to be operating. If evidence was fabricated during that period, the auditor’s opinion is worthless. Your enterprise customers will discover this during their own vendor reviews, and the reputational damage compounds from there.
ISO 27001. Certification bodies can revoke certificates. If your auditor was not properly accredited, or if the certification was issued without genuine independent assessment, your certificate may not survive scrutiny from a prospective client’s security team or a regulatory inquiry.
HIPAA. False compliance with HIPAA carries the most severe consequences. Willful neglect of HIPAA requirements can result in criminal charges and prison time. If a compliance vendor led you to believe you were HIPAA-compliant when the underlying controls were never implemented, the liability falls on you. The vendor’s assurances do not constitute a legal defense.
PCI DSS. Non-compliance discovered after a data breach means your organization absorbs the full financial liability, including card brand fines, forensic investigation costs, and potential lawsuits. A PCI DSS attestation built on fabricated evidence provides zero protection when it matters most.
In every case, the organization holding the certification bears the regulatory and legal risk. The compliance vendor does not.
How Equinox approaches compliance differently
We are compliance operators, regulatory strategists, legal advisors, counsel, and auditors who build, assess, and stand behind these programs firsthand. Our approach is grounded in substance, not just automation:
- We provide both readiness and audit capabilities. We design and implement compliance programs and support audit activities through qualified auditors. Organizations can move from build to validation without reworking their foundation or changing partners.
- We preserve independence where required. Where independence is necessary for SOC 2, ISO 27001, or similar attestations, audit activities are performed by auditors who are independent of the program build. We do not audit our own work where independence is required.
- We distinguish real programs from generated output. Many tools generate policies, controls, and evidence artifacts automatically. We do not. Every control is implemented, validated, and understood by your team before it is presented for audit or review.
- We distinguish clearly between compliance and legal. Our team includes compliance professionals and licensed legal counsel. Legal advice is provided where appropriate, and compliance advisory remains distinct to align with regulatory expectations.
- We operate as practitioners. We have built and run compliance programs within banks and fintech companies. That experience shows up in how controls are designed, tested, and defended.
- We build programs that withstand scrutiny. Enterprise security reviews, regulatory examinations, investor diligence, and board-level oversight are the real test. We design programs that hold up when examined in detail, not just when summarized in a dashboard.
Compliance is not a documentation exercise. It is an operational system that must function under scrutiny. We build programs that work in practice, not just in presentation.
