Beware of Compliance Theater
Beware of “Compliance Theater”: What the Delve Scandal Actually Teaches SaaS Founders
A recent controversy involving Delve, a fast-growing startup backed by Y Combinator, has sparked an uncomfortable question for SaaS founders:
Are we confusing compliance with the appearance of compliance?
For years, startups have been sold on a simple promise:
“Automate your SOC 2 or ISO 27001 and get compliant fast.”
But the reality is more nuanced—and more dangerous if misunderstood.
The real risk isn’t “fake reports”—it’s false confidence
Let’s be precise.
Most modern tools don’t literally generate “fake” reports. The real issue is subtler:
They can make your company look compliant without ensuring your systems actually are.
Standards like SOC 2 and ISO 27001 are not about documents—they’re about operational integrity over time.
Auditors don’t just ask:
- “Do you have a report?”
They ask:
“Are your controls real?”
“Are they consistently enforced?”
“Can you prove it with evidence over time?”
Automation helps collect evidence—but it does not replace the underlying controls.
Why startups fall into this trap
This happens for three predictable reasons:
1. Speed is prioritized over rigor
Early-stage teams are under pressure:
close deals
pass security reviews
unlock enterprise customers
Compliance becomes a checkbox instead of a system.
2. Founders underestimate complexity
Compliance sounds straightforward—until it isn’t.
In reality, it touches:
infrastructure
access control
employee processes
incident response
vendor management
No single tool can abstract all of that away.
3. “Automation” is misunderstood
Automation tools are incredibly useful—but only in the right role.
They are best at:
aggregating logs
tracking evidence
monitoring drift
They are not a substitute for:
designing controls
enforcing policies
making judgment calls
The developer mistake: optimizing for outputs instead of systems
From an engineering perspective, the failure mode is subtle but common:
Teams optimize for passing audits, not for building auditable systems.
That leads to:
point-in-time screenshots instead of continuous logs
manual exports instead of real-time visibility
scattered evidence instead of a coherent system of record
The result is fragile compliance:
It works when you're preparing for an audit
It breaks under real scrutiny
What real compliance actually looks like
If you strip away the buzzwords, strong compliance systems behave more like well-designed data systems.
They have:
1. Continuous evidence streams
Not snapshots—flows of data over time:
access logs
billing events
infrastructure changes
permission updates
2. Enforced, observable controls
It’s not enough to define policies—you need to:
enforce them at the system level
observe them in real time
detect when they break
3. A unified audit layer
At any point, you should be able to answer:
Who accessed what?
What changed?
When did it happen?
Was it expected?
Without stitching together five different tools.
In practice, this often comes down to having a reliable audit trail across your systems.
Shameless Plug:
We’ve been building an audit table in Pollynate that tracks changes flowing in and out of core business systems—so instead of reconstructing events during an audit, the history is already there by default.
A better mental model: compliance as a data problem
This is where most teams go wrong.
They treat compliance as:
documentation
checklists
external audits
But in practice, compliance is a data consistency problem:
Are the signals from your systems consistent with the controls you claim to have?
That shift in thinking changes everything.
Instead of asking:
- “Do we have a SOC 2 report?”
You ask:
- “Do our systems continuously produce evidence that our controls are working?”
Where automation actually fits
Automation still plays a critical role—but in a different layer than most people think.
The most effective setups use automation to:
ingest signals from systems like payments, infrastructure, and auth
normalize them into a consistent audit trail
detect anomalies or policy violations in real time
This is less about “generating reports” and more about maintaining observability over your controls.
In that sense, the problem starts to look a lot like:
monitoring
analytics
or even debugging distributed systems
The emerging pattern: compliance as observability
A more robust approach is starting to emerge:
Treat compliance like you treat production systems.
You don’t trust your system because it should work
You trust it because you can observe that it is working
The same should apply to:
access control
billing integrity
data handling
security policies
This is the gap most tools miss—and where a new category is forming.
Not compliance automation, but compliance observability.
Systems that:
sit across your stack
continuously ingest operational data
and make your controls provable by default
The takeaway
The lesson from the Delve situation isn’t that automation is broken.
It’s this:
You can’t outsource accountability—but you can instrument it.
The goal isn’t to generate better reports.
It’s to build systems where:
compliance is continuously verifiable
evidence is generated as a byproduct of operation
and audits become a formality, not a fire drill
Final thought
If you’re building a SaaS company, ask yourself:
Are our controls real—or just documented?
Can we observe them in real time?
Or do we only see them when we’re forced to?
Because in the end:
Compliance isn’t what you say in a report.
It’s what your systems prove—every minute they run.