In December 2025, around 500 artificial intelligence startups made an uncomfortable discovery. The confidential data they had handed over to their compliance provider, including legal entity names, infrastructure vendors, security contacts and audit timelines, was publicly accessible through an unprotected Google Sheet.
The provider was called Delve. It had been hired specifically to validate that those companies’ data was secure.
The irony writes itself. There is, however, a deeper layer worth exploring, because this story is not only about Delve and not only about those 500 companies.
One Google Sheet. Data from 500 companies. Fully public.
According to a detailed investigation published on DeepDelver, the leak occurred through a Google Sheets document configured with public visibility. Inside it sat a structured list of Delve clients with direct links to their confidential audit reports.
The exposed data included legal entity names, cloud infrastructure providers such as AWS, GCP and Azure, system descriptions, security contact email addresses and complete audit cycle timelines. The affected companies held SOC 2 Type 1, SOC 2 Type 2 and ISO 27001 certifications, many of them operating in high-risk sectors: healthcare AI, fintech, legal tech. Sectors where data confidentiality is not a preference but a regulatory obligation.
When clients became aware of the exposure, Delve responded by denying that the data had actually been accessible. The investigation proved otherwise.
The paradox: the security guarantor as the vulnerability
There is a precise narrative structure to this story, and it is worth naming it.
Those 500 startups had done the right thing. They had gone through a formal audit process and invested significant time and money, in Delve’s case between $6,000 and $15,000 per contract, to demonstrate to enterprise clients, investors and partners that their security posture was solid and independently verified.
They had outsourced the risk. Or at least they believed they had.
What they had actually done was introduce a new point of vulnerability: the vendor itself. That vendor was managing its internal data collection process on a spreadsheet accessible via a public link.
This is not a story about a sophisticated attack. There was no breach, no ransomware, no APT. There was a sharing setting configured incorrectly. The risk those companies were trying to eliminate was already inside the watchman’s house.
The systemic problem: compliance as an annual event
It is easy to read the Delve case as an anomaly: a negligent vendor, a startup that grew too fast, an isolated human error. That reading, however, misses the point.
The model Delve operated under, and that much of the compliance market still operates under, is structurally fragile because it treats conformity as a discrete event rather than a continuous process.
You get the certification. You publish the trust page. You fill out vendor questionnaires. For the next eleven months the topic disappears from the agenda, until the next renewal window.
In this model, the compliance vendor becomes the custodian of everything: the data, the evidence, the reports, the credentials. It becomes a single point of failure dressed up as a security guarantee. When that point fails, through negligence, human error or a misconfigured sharing setting, the exposure does not only affect the vendor. It affects every company that had entrusted it with its most sensitive data. The compliance is not a checkbox to tick once a year. It is an ongoing operational discipline. The moment you treat it as something to be outsourced, you are building your security posture on someone else’s internal process, one you cannot see, cannot audit and cannot control.
The data you never wanted made public
It is worth pausing to consider what it actually meant to be among the 500 companies on Delve’s spreadsheet.
- The legal entity name, not the brand name but the registered legal entity, is a piece of data that in the wrong hands enables targeted social engineering attacks, document fraud and impersonation against vendors and partners.
- The infrastructure provider, whether AWS, GCP, Azure, Render or Railway, identifies the company’s cloud attack surface. It is precisely the kind of information a malicious actor uses to calibrate an attack before launching it.
- The security contact email is the privileged entry point for any spear-phishing operation targeting the technical team.
- The audit timelines reveal internal operational cycles, observation periods and the windows during which controls are active or under review.
None of this data was secret from Delve: it had been shared voluntarily as part of the onboarding process. The problem is that it had been shared with the implicit expectation that it would be handled with the same level of care that Delve was certifying in its clients. That expectation was reasonable. It turned out to be wrong.
What would have made this failure structurally impossible
The question every compliance officer and C-suite should take from this story is not how to choose a more reliable vendor. It goes deeper: does our compliance stack have the same single points of failure?
A spreadsheet with a public link is an extreme example. The underlying logic, built on manual processes, data centralised in generic tools and dependence on individual diligence rather than structural controls, is far more widespread than most organisations would like to admit.
The answer is not to replace one vendor with another. It is to change the model.
A reliable compliance AI platform is not the one that produces reports fastest or costs least. It is the one built on infrastructure that makes certain types of failure structurally impossible, not merely unlikely. Infrastructure where confidential data does not pass through generic tools, where every access is logged and audited, and where the vendor’s own security is independently certified by third parties.
At Aptus.AI, we built our platform on these principles. Our infrastructure is certified ISO/IEC 27001:2022. Our clients’ data is never used to train our models. Every feature, from real-time regulatory monitoring to risk analysis, is designed to return control to the professional, not to concentrate it in an opaque process they cannot inspect.
The lesson no audit can certify
The 500 companies on Delve’s spreadsheet had done the right thing. They had sought external validation of their security posture, invested in a formal process and taken seriously an obligation that many companies of their size ignore.
The system they trusted let them down.
This is not a criticism of those companies. It is a criticism of the model. A model in which compliance is treated as a product to be purchased rather than a capability to be built. In which the vendor becomes the custodian of everything, including the risk it was hired to eliminate. In which no one asks who watches the watchmen, until the answer arrives on its own in the form of a public link on Google.
Compliance is not something you outsource. It is something you own.
Frequently asked questions
Does the Delve case only affect US companies?
No. Among the companies exposed in the leak are organisations that process data of European citizens and are therefore subject to the GDPR. The exposure of data such as security contact emails and system descriptions may trigger notification obligations to supervisory authorities and direct liability under Article 83 of the GDPR.
How can I tell whether my compliance vendor handles my data securely?
Ask directly: are they ISO/IEC 27001 certified? Is your data hosted in Europe? Is it used to train AI models? Do you have access to an access log for your data? If even one of these questions receives a vague or evasive answer, that is a signal you should not ignore.
What is a single point of failure in compliance?
It is any element of the process, a vendor, a tool or a person, whose compromise or unavailability exposes the entire security posture of the organisation. Delve’s spreadsheet was a single point of failure: one document contained the confidential data of hundreds of companies and was accessible via a simple link.
How do you build a structurally resilient compliance practice?
By distributing controls rather than centralising them, choosing vendors whose infrastructure is independently certified and audited, and treating regulatory monitoring as a continuous operational process rather than a periodic obligation. The most advanced financial institutions have followed this approach for years. It is a replicable model.
