The modern GRC industry built itself around one goal: getting audits done faster. Platforms for ‘continuous compliance / compliance automation’ compete on speed-to-SOC 2, dashboards track framework completion percentages, and the entire value chain rewards certificates over actual security outcomes. The Delve scandal, where a $300M-valued startup allegedly fabricated audit reports for hundreds of clients, is the logical endpoint of that incentive structure. But the fix isn’t better audit tooling. The fix is flipping the sequence entirely: govern change, manage risk continuously, and let compliance become the output of real work rather than the starting point.
Log into most modern GRC platforms and the first thing you see is a progress bar. Eighty-three percent toward SOC 2. Seventy-one percent toward ISO 27001. The dashboard tells you how close you are to completing what you need for a given compliance framework. And it tells you absolutely nothing about your actual risk posture.
That single design choice reveals everything about where this industry went wrong.
In this post we will cover:
- The Dashboard That Tells You Nothing
- Speed Became the Only Metric That Mattered
- The Delve Debacle: Rock Bottom for Speed Over Substance
- Your SOC 2 Report Doesn’t Actually Matter
- Flip the Sequence
- Risk First, Compliance Follows
The Dashboard That Tells You Nothing
The largest modern ‘continuous compliance’ platform positions its SOC 2 product around speed and readiness. Their messaging leads with phrases like “scope with confidence and be ready in weeks” and “eliminate manual evidence collection.” The entire content ecosystem they’ve built, dozens of guides on how long audits take, how to speed up the timeline, how to automate evidence gathering, orients around one thing: getting you through the audit faster.
And all of the other modern GRC tools / compliance automation tools tell a similar story. Their dashboards show framework completion. Their marketing leads with time-to-certificate. The whole product experience is oriented around “how close are you to done?”
But “done” with what, exactly? A SOC 2 report tells your customers you had controls in place during an observation period. It doesn’t tell you whether a new feature introduced unreviewed risk last Tuesday. It doesn’t tell you whether an exception expired three weeks ago and nobody noticed. The certificate is a snapshot of a moment in time. Your risk posture changes with every commit, every architecture decision, every vendor integration.
Speed Became the Only Metric That Mattered
When the audit itself becomes the goal, speed becomes the differentiator. And once speed is the differentiator, shortcuts become inevitable.
Some of those shortcuts are benign. Pre-built policy templates save teams from writing boilerplate from scratch. Automated evidence collection pulls data from cloud providers instead of requiring screenshot marathons. Nothing wrong with reducing friction in a genuinely tedious process.
But the incentive structure kept pushing. Customers wanted SOC 2 faster. Vendors competed on timeline. And the logical extreme of “compliance as fast as possible” arrived in March 2026, wearing a $300M valuation and a Forbes 30 Under 30 badge.
The Delve Debacle: Rock Bottom for Speed Over Substance
Delve, a Y Combinator-backed compliance startup, raised $32 million and claimed over 1,500 customers. The company promised to use AI agents to compress months of compliance work into days. In March 2026, an anonymous investigation alleged that Delve had been systematically fabricating SOC 2 reports for nearly 500 clients, using what investigators described as certification mills to rubber-stamp reports that hadn’t been properly verified. Trust pages were allegedly populated with claims about completed vulnerability scans and penetration tests before any of that work had actually been performed. Pre-fabricated board meeting minutes and risk assessments could reportedly be adopted with a single click.
Delve has denied the allegations, calling the investigation misleading and stating that customers are responsible for reviewing and finalizing their own materials. But the fallout has been swift. TechCrunch reported that technology firms began distancing themselves from the company, and at least one major customer, Lovable, publicly confirmed it had already left for a competitor.
The Delve situation, regardless of how the allegations ultimately resolve, exposed a fundamental vulnerability in the compliance automation model. When the system rewards speed above everything, and when customers measure value by how quickly they get a certificate rather than how well they manage risk, the incentive to cut corners becomes enormous.
And that’s the core issue. Delve didn’t appear out of nowhere. The entire market created the conditions for a company like Delve to thrive by treating compliance as a speed problem rather than a risk management problem.
Your SOC 2 Report Doesn’t Actually Matter
Provocative? Maybe. But consider the logic.
A SOC 2 Type II report proves that your controls were designed properly and operated effectively during an observation period. The audit is a verification artifact. The real question is: what generated the evidence that the auditor reviewed?
If you’re running a well-governed risk management program, where every change is assessed for risk, every decision is traceable, every exception is tracked with compensating controls and expiry dates, and evidence accumulates naturally from real work, then compliance is a standing condition. Your audit-ready evidence package exists on demand because it’s a byproduct of how you actually operate. The SOC 2 report becomes trivial to produce because the underlying risk management work is already being done.
But the industry built it backwards. Platforms start with the framework checklist, work backward to the evidence requirements, and then try to automate the collection of that evidence. The audit is the starting point, and everything flows backward from there. Controls exist to satisfy auditors rather than to manage real risk. Evidence is collected for the report rather than generated from actual governance work.
When you invert the purpose, you get exactly the dysfunction the market has created: compliance programs that look great on paper while changes ship unreviewed, exceptions go untracked, and risk accumulates in the gaps between audit cycles.
Flip the Sequence
So what does the right order of operations look like? It seems almost too obvious once you see it.
Start with change. Every new feature, architecture decision, infrastructure modification, and vendor integration creates potential risk. Track all of it. Automatically correlate design docs, tickets, pull requests, and deployments into unified initiative records so you can see what’s actually happening across your SDLC.
From there, assess risk. Run security, privacy, and compliance assessments against every change, using your actual policies, your actual environment context, and your actual threat landscape. Flag high-risk changes for human review. Gate what needs gating. Track exceptions with compensating controls and expiry dates.
And then let evidence accumulate. When decisions are captured in real time, when approvals have conditions attached, when controls are verified against actual code changes, audit-ready evidence isn’t something you scramble to produce. It’s already there, born from the work itself.
The platform that GRC directors and security architects need doesn’t ask “how close are you to your next audit?” It asks “what is your risk posture right now, based on what’s actually changing in your environment?” A change-native approach to compliance, one where risk posture is derived from reality and not hand-entered into a spreadsheet, makes compliance a natural output rather than the primary objective.
Risk First, Compliance Follows
The GRC industry spent the last several years building faster audit machines. And in the process, it lost sight of what the audit is actually for.
An audit exists to verify that you’re managing risk well. If the management is real, the verification is easy. If the management is absent and you’re just optimizing for the verification step, you end up with speed-optimized compliance theater that delivers certificates and little else. In the worst case, you end up with Delve.
The dashboard on your GRC platform should show you your risk posture. It should surface unreviewed changes, expiring exceptions, and drifting controls. It should tell you what’s governed and what’s exposed. The framework completion percentage? Tuck it in a sidebar. It matters, but it’s an output, not the mission.
GRC teams deserve tooling that’s built around the actual work of managing risk, not just the artifact that proves you tried.
FAQ
The market evolved around a specific buyer need: enterprise customers requiring SOC 2 or ISO 27001 reports before signing contracts. Vendors optimized for that buying trigger, which meant speed-to-certificate became the primary competitive differentiator. GRC directors and compliance leads who manage multiple framework cycles simultaneously would benefit from platforms that surface risk posture alongside audit readiness, rather than treating the certificate as the finish line.
In March 2026, an anonymous investigation alleged that Delve, a Y Combinator-backed compliance startup valued at $300M, had been fabricating SOC 2 reports for hundreds of clients. The allegations included using unaccredited certification bodies and auto-generating evidence before compliance work occurred. Delve denied the allegations. The situation highlighted the risks inherent in any compliance model that prioritizes speed over substance, particularly for organizations in regulated industries handling sensitive data.
Yes, if your underlying risk management program is sound. Organizations that continuously assess changes for risk, track decisions with traceability, and generate evidence from real governance work will produce the documentation an auditor needs. A change-native GRC approach, where evidence is born from actual work artifacts like PR checks, approval records, and policy enforcement, creates audit readiness as a standing condition rather than a quarterly project.
Traditional compliance automation (Drata, Vanta, and similar platforms) monitors whether infrastructure controls are configured correctly and automates evidence collection at the controls layer. Change-native GRC starts upstream: it tracks every initiative and change in the SDLC, assesses risk at the point of change, enforces policies, captures decisions, and generates evidence automatically. Security architects managing hundreds of monthly reviews can use change-native platforms to govern what’s actually happening in code, not just verify that infrastructure controls exist.
Not necessarily. Platforms like Drata and Vanta serve a real purpose at the infrastructure compliance layer. The gap is at the SDLC level, where changes introduce risk before they ever reach production. A change-native GRC platform complements existing compliance automation by feeding it with change-derived risk intelligence, decision logs, and evidence from real development work. GRC directors working across SOC 2, ISO 27001, and HIPAA simultaneously benefit from both layers working together.
