Fake Compliance as a Feature
When the people building compliance infrastructure have never actually worked in compliance, this is what happens.
Earlier this year, 400 companies found out their compliance certification might be worthless.
A regulator didn’t catch it. A Substack did.
Delve is a compliance automation startup that raised $32 million promising SOC 2 in days. A whistleblower published a detailed investigation alleging the company was generating audit conclusions before clients submitted any data, fabricating board meeting minutes and test results for events that never happened, and routing everyone through two certification mills operating primarily out of India that rubber-stamped whatever Delve produced. A leaked spreadsheet revealed 494 client reports — 99.8% identical boilerplate. Not one regulatory body flagged a pattern. Not one oversight mechanism caught it.
The company has denied the allegations and called the post misleading. The investigation is ongoing.
But even setting aside what is still alleged versus proven, the story raises a question the compliance technology industry has been quietly avoiding for years: who actually has the right to build these tools?
Part 1: What Delve Allegedly Did, and Why Every Step of It Matters
To understand why the specific allegations against Delve are so serious, you have to understand what each layer of a legitimate compliance process is actually trying to accomplish.
A SOC 2 Type II audit requires a minimum six-month observation period. That period exists because controls don’t prove themselves by existing. They prove themselves by operating under real conditions over time. A control that looks correct on paper and fails under load is worse than no control at all, because it creates false confidence. The observation period is how you find out whether the control actually works.
Board meeting minutes aren’t bureaucratic formality. They’re evidence that governance actually happened — that real people with fiduciary responsibility reviewed real risks and made documented decisions. When a regulator reviews board minutes, they’re not checking a box. They’re reconstructing whether the company’s leadership understood the risks they were carrying and took accountability for managing them.
Auditor independence isn’t a technicality. It’s the entire basis on which a certification means anything. The moment the entity selling you the compliance software is also the entity generating the conclusions about whether your compliance is adequate, the attestation is worthless. Not because the conclusions are necessarily wrong. Because there’s no independent verification that they’re right.
Every single layer that Delve allegedly skipped has a reason behind it. Those reasons weren’t invented by bureaucrats who love paperwork. They were developed over decades of enforcement actions, breaches, and failures that happened because companies cut those corners and their customers paid the price.
The clients who relied on Delve’s certifications are now potentially sitting on criminal HIPAA liability and GDPR exposure they don’t fully understand yet. The startup gets the headlines. Their clients get the consequences.
Part 2: This Isn’t a Delve Problem. It’s a Founder Problem.
Delve’s founders are talented technologists. They studied AI at MIT. They built products that scaled internationally. They made Forbes 30 Under 30. By every conventional measure of startup success, they’re the kind of founders venture capital is designed to back.
Their compliance expertise? They were frustrated customers once. They went through a painful HIPAA compliance process at their previous company and decided the experience was too slow and too annoying. So they built something to make it faster.
Experiencing compliance as a painful obstacle is not the same as understanding why compliance works the way it does. The frustration is real. The pain point is real. But the path from “this was annoying” to “I’ll build something that eliminates the annoying parts” skips the most important question: which parts are annoying because the process is poorly designed, and which parts are annoying because they’re doing something necessary that nobody wants to do?
That distinction requires domain expertise. Not domain familiarity. Not having gone through a compliance process as a customer. Deep, practitioner-level understanding of what each step is protecting against and what the failure modes look like when it’s skipped.
The engineers building fintech compliance tools are not wrong that compliance is slow. They’re wrong about why.
Compliance isn’t slow because the people doing it are bureaucrats who love paperwork. It’s slow because of what’s actually at stake. When a company asks its customers to trust its software with their data, their trade secrets, their customers’ personal information, that trust requires proof, not promises. And proof requires redundancy. You build controls to catch failures. Then you build tests to validate the controls. Then you build monitoring to catch what the tests miss. Then you do it again in two years because the threat landscape has shifted and three of your controls have gaps they didn’t have before.
The whole architecture is a feedback loop built on the assumption that something will always get through. Your job is to narrow that window as much as possible before it does.
Compliance is redundant by design. That is not a bug. That is the entire point.
Delve allegedly raised $32 million because the market wanted to believe SOC 2 in days was possible. Investors funded it. Hundreds of companies bought it. Nobody looked too hard at the how. That’s what happens when an entire ecosystem decides it wants compliance to be fast and cheap and then optimizes for the certificate instead of the program.
The certificate is the output of a process. It cannot exist without the process. When you produce the certificate without the process, you haven’t automated compliance. You’ve manufactured the appearance of it. And manufactured appearances collapse the moment a regulator, a breach, or an investigation applies real pressure.
Part 3: What Compliance Infrastructure Actually Needs
None of this is an argument against technology in compliance. It’s an argument about what kind of technology, built by whom, with what understanding of the domain.
Compliance infrastructure that actually works needs to make the real work faster — not replace the real work with a simulation of it. That means automation that accelerates evidence collection, not automation that generates conclusions before evidence exists. It means monitoring that surfaces control gaps before examiners find them, not trust pages populated before any controls are implemented. It means audit trails that document what actually happened, not templates that document what was supposed to happen.
The difference between those two things is not technical. It’s epistemic. It requires knowing what you’re protecting against, why each step exists, and what the failure looks like when a corner gets cut. That knowledge lives in practitioners — people who have sat across from examiners, managed remediation timelines, written board reports after something went wrong, and rebuilt controls that failed under real conditions.
As AI scales and compliance tooling proliferates, the question of who is building the infrastructure that other companies are staking their reputations on becomes increasingly urgent. Your reputation for trust doesn’t erode slowly. It disappears overnight. One breach, one exposure, one certification that turns out to be a piece of paper — and everything built on top of it is in question.
Technology should make the real work faster. It cannot replace the understanding of why the work exists.
That’s a solvable problem. It just requires building from the inside out.
Rupture Labs is building compliance infrastructure for financial services companies. We write about compliance, regulation, and the technology being built to manage both.
What compliance tool is your company relying on right now that you’ve never actually seen the methodology behind?