Compliance automation tools promise audit-readiness in weeks. But a recent controversy has put a sharper question in front of the industry. Delve, a Y Combinator-backed compliance automation startup, recently parted ways with YC after public reporting raised questions about the independence of its audit process.
I'm not going to litigate the specifics here. Delve has disputed the allegations, and there are competing accounts of what actually occurred. But the story has brought to the forefront a question I think about a lot, because we built Aptible around a specific answer to it: when a compliance automation tool generates your audit evidence, what does the resulting report actually certify?
The answer depends entirely on what is being documented and whether that documentation accurately reflects how your systems actually operate.
What compliance automation tools do well
The core function of tools like Vanta, Drata, and Sprinto is legitimate. They connect to your cloud provider, identity management system, endpoint management, and code repositories, then pull evidence against a control framework continuously. Instead of manually gathering screenshots of IAM policies, access logs, and employee device states before every audit window, the platform collects that evidence automatically and keeps it current.
That removes a real category of error. It also changes the compliance workflow: instead of a two-month scramble before your annual audit, you maintain readiness year-round. For a startup that needs to close a healthcare contract or respond to a security questionnaire, that readiness is a business asset.
Beyond evidence collection, these tools handle policy management, employee security training, vendor risk tracking, and control monitoring. The administrative side of compliance is genuinely time-consuming. Reducing that burden frees engineering time and reduces the chance that something falls through in a crunch.
None of this is marketing hype. It's why the category exists and why adoption has been rapid.
But the value of these tools depends entirely on what they're sitting on top of.
What a compliance audit certifies
A SOC 2 Type II report is a third-party attestation. A licensed CPA firm is saying, after independent testing, that your security controls existed and operated effectively over a defined period. The entire value of that report rests on the independence of the person signing it.
When a customer asks to see your SOC 2, they're not checking whether you filled out a form, because who cares. They're relying on the fact that someone with no stake in the outcome examined your actual systems and confirmed the controls are real. That's why AICPA independence standards exist. The auditor can't be working from a script the platform vendor wrote.
The Delve situation is a clear illustration of what happens when that independence breaks down. The specific allegations are still being disputed, but the failure mode is unambiguous: a report where the conclusions are written first and the evidence is assembled around them is not an attestation. It's formatted paperwork.
This matters because the people reading your report aren't just checking a box. A healthcare customer evaluating you as a vendor will ask follow-up questions: how is PHI isolated, who has access, what does your incident response process look like. If your SOC 2 says one thing and your architecture says another, that due diligence call exposes it.
The HHS Office for Civil Rights (OCR) operates the same way: when investigating a breach, they don't take your attestation at face value. They look at what your systems actually did. A report that doesn't reflect your real posture doesn't protect you in either of those situations. It just adds a false confidence layer on top of the actual exposure.
In most industries, that's a serious problem. In healthcare, it's a different category of risk entirely.
Why the stakes are higher in healthcare
SOC 2 is a market credential. Failing to maintain it accurately is embarrassing and costly. HIPAA carries federal enforcement authority, which is a whole other beast.
OCR can issue fines, require corrective action plans, and in serious cases pursue criminal referrals. The parties who care whether your controls are real include every entity you've signed a BAA with, OCR if there's a breach investigation, and the healthcare systems and payers running security reviews before contracting with you. Those reviews go way beyond the PDF. They ask about your architecture, your incident response history, your access control model. If those answers don't match your report, the report becomes a liability rather than an asset.
Which brings us to the question the compliance automation category doesn't have a great answer for.
What compliance automation can't substitute for
Compliance automation tools are documentation tools. Very good ones, in the right conditions. The condition they require: the controls being documented have to exist.
Encryption at rest is either configured or it isn't. Network segmentation is either enforced or it isn't. Access controls are either scoped and logged or they aren't. A compliance platform can verify those things, collect evidence that they're in place, and present that evidence to an auditor. It can't configure them for you, and it can't make a report true that describes controls you haven't implemented.
We built Aptible because we kept seeing this pattern: teams in healthcare had gotten a compliance credential but hadn't secured their infrastructure, and those two things were being treated as the same problem. They're not. The infrastructure is the posture. The credential documents the posture. You need both, in that order.
This is the struggle of the compliance automation industry, and it’s structured in such a way that no one is likely to tell you about it…
The incentive problem: why compliance automation tools won't tell you your infrastructure isn't ready
The platforms with the most commercial incentive to help you get a clean report quickly are also the ones with the least incentive to tell you your infrastructure isn't ready for one. This is a structural problem across the board (there's a whole Reddit thread about it if you don't believe me).
Compliance automation tools compete on speed. The marketing promise is "get your SOC 2 in weeks, not months." That pitch and an honest assessment of your infrastructure readiness are in direct tension. An honest evaluation that concludes your infrastructure isn't ready slows the sales cycle, risks losing the deal to a competitor who doesn't ask hard questions, and produces a bad outcome on the metric the company actually optimizes for: accounts with passing reports.
There's also no accountability loop after the report is issued. The platform collected its subscription fees. The downstream consequences of an insufficient security posture (a breach, an OCR investigation, a failed due diligence review) are your problem, not theirs. Their incentive ends at the signed PDF. Yours doesn't.
The auditor economics compound this. Platforms that offer preferred auditor networks are referring clients to those auditors. Auditors who pass clients reliably get referrals. Auditors who ask hard questions and fail clients don't. The incentive runs all the way through the process.
Given all of that, here's what to actually ask when you're evaluating one of these platforms.
Questions worth asking any compliance tool vendor
The right questions are more about what the platform is attesting to on your behalf than about features or integrations.
Who signs the audit report, and are they independent? The auditor should be a licensed CPA firm with no economic relationship to the platform. If the vendor has a preferred auditor network, find out how independent those firms are in practice: whether they conduct actual independent testing or review pre-assembled evidence and sign off.
What evidence does the platform generate versus what comes from your systems? Tools that pull real signals from AWS Config, Okta, your MDM, and your CI/CD pipeline are documenting what's actually happening in your environment. Platforms that populate fields like "zero security incidents this quarter" or "all employees completed training" before you've provided any input are generating information with no relationship to your actual state.
What happens when a control fails? A legitimate compliance tool should surface control failures clearly and prevent a passing report until they're resolved. If the platform makes it easy to obtain a clean report regardless of what the underlying testing shows, that's the signal that matters.
Is the underlying infrastructure compliant, or just the paperwork? This is the question compliance automation vendors can't answer for you. It's about your infrastructure, not their platform. And it's the one that determines whether the rest of the process reflects something true.
If you're in healthcare, two more questions to consider:
Does the platform itself require a BAA? If your compliance tool touches any PHI-related documentation or data, it may qualify as a business associate. A lot of teams don't think to ask this about their compliance tooling specifically. Find out before you're in a due diligence conversation and someone else notices.
Does HIPAA coverage go beyond a SOC 2 add-on? Many tools satisfy HIPAA's risk analysis requirement (§164.308(a)(1)) by reusing whatever risk assessment you produced for SOC 2, relabeling it, and checking the box. But a SOC 2 risk assessment doesn't ask the HIPAA-specific questions: where does your ePHI live, which systems touch it, what are the specific threats to it. For a full breakdown of what HIPAA actually requires, see our HIPAA compliance checklist. The form looks the same, but the substance isn't. Similarly, some tools surface their existing vendor management module, let you upload BAA documents, and call it HIPAA coverage without prompting you to identify which vendors qualify as business associates or flagging gaps where a BAA is missing. If a tool's HIPAA offering is a feature flag on top of its SOC 2 workflow, that's worth knowing before you rely on it.
Where Aptible fits
Aptible handles compliance at the infrastructure layer. Encryption, network isolation, access controls, audit logging, and backup configuration are part of how the platform deploys and runs your workloads by default. The controls aren't something you configure after the fact as part of audit prep; they're how the infrastructure operates.
Compliance automation tools work well on top of that foundation because they have something real to document. The evidence they collect reflects what your environment actually does. That's a different situation than running the same tools over infrastructure where the underlying controls haven't been set up.
If you're evaluating compliance tooling, the infrastructure question comes first. The tool that helps you get a report faster is only valuable if the report reflects something true. Get the infrastructure right first. The documentation follows from that.
Aptible is a HIPAA-compliant infrastructure platform built for regulated startups. Learn how it works.