This week, a B2B SaaS startup's SOC 2 and ISO compliance claims were publicly questioned across developer and startup communities. The allegations: the certifications existed, but the controls behind them were superficial — a trust layer built for the badge, not the standard.
The reaction from r/startups and r/programming was visceral, not because the story was surprising, but because everyone already suspected it. Buyers have quietly known for years that a compliance badge on a landing page tells you almost nothing about actual security posture.
For general B2B software, this is an uncomfortable business story. For legal tech, it's a five-alarm fire.
What the Scandal Actually Revealed
SOC 2 and ISO 27001 were designed to give buyers confidence that a vendor has implemented real security controls — access management, encryption, incident response, audit logging, and more. A Type II audit means those controls were in place and operating over a sustained period, not just on the day of the audit.
What compliance theater exploits is the gap between the report and the reality. Audits are conducted over a defined scope. If the scope is narrow enough, a company can obtain a SOC 2 report that covers a limited set of systems while the rest of their infrastructure remains completely unaudited. The badge is technically earned. The promise it implies is not.
The Compliance Theater Playbook
- Obtain SOC 2 over a narrow, well-controlled scope
- Display the badge prominently on the pricing page and trust portal
- Never proactively clarify what the report actually covers
- Wait for buyers to not ask
Most buyers never ask. They see the green checkmark, assume the system is secure, and move on. For a HR software vendor or a project management tool, this gamble mostly works. For a platform handling litigation documents, settlement communications, and client medical records — the consequences of that gamble are different in kind, not just degree.
Why Legal Buyers Are Uniquely Exposed
Attorneys operate under a duty of confidentiality that has no equivalent in other professions. Rule 1.6 of the Model Rules of Professional Conduct doesn't say “try to protect client information.” It says you must make reasonable efforts to prevent unauthorized disclosure — and courts have increasingly interpreted that to include vendor due diligence.
The three ways a compliance theater breach becomes a lawyer's problem:
⚠️ Privilege Destruction
When confidential case materials are exposed through a vendor breach, courts have found that attorney-client privilege over those documents can be waived — especially if the attorney failed to exercise reasonable care in selecting the vendor. The privilege doesn't survive careless vendor selection.
⚠️ Disciplinary Exposure
State bars are issuing more formal opinions on cloud storage and AI tools. Several have held that relying on a vendor's marketing page instead of conducting actual due diligence does not satisfy a lawyer's competence obligation under Rule 1.1. “They had a SOC 2 badge” is not a defense.
⚠️ Malpractice Liability
If a client suffers harm from a data breach — opposing counsel gains access to privileged strategy, a settlement number leaks, medical records are exposed — the attorney who entrusted that data to an insufficiently vetted vendor faces direct malpractice exposure. The vendor's misrepresentation does not eliminate the attorney's independent duty.
Five Questions That Separate Real From Theater
The good news: you can cut through compliance theater with five direct questions. Legitimate vendors answer them immediately. Vendors whose compliance is theater stall, deflect, or provide vague answers.
1. “Can I see the actual SOC 2 Type II report, not just the badge?”
The report details the scope of the audit, the controls tested, and any exceptions found. A vendor with real compliance will provide this under NDA. A vendor with theater compliance will tell you the report is “confidential” and offer a summary instead.
2. “Where, physically, is my data stored?”
The answer should be specific: a named cloud provider, a named region, and a clear statement about whether data ever leaves that environment. “We use enterprise-grade cloud infrastructure” is not an answer.
3. “Does your AI train on customer data?”
This should be a contractual guarantee, not a policy promise. Many AI tools use customer inputs to improve their models unless you explicitly opt out — and the default opt-out is buried in settings. Ask for it in writing in the data processing agreement.
4. “Who inside your company can access my client data?”
Access should be role-based, logged, and minimal. If the answer is “our engineers can access it for troubleshooting,” ask what controls exist on that access and whether it is audited. Uncontrolled internal access is one of the most common sources of legal tech data exposure.
5. “What is your documented incident response time?”
Real compliance means a written incident response plan with documented SLAs for detection, containment, and client notification. If they cannot produce this document, their compliance program exists on paper, not in practice.
Defensibility: The Standard Lawyers Actually Need
The word legal buyers should be asking about — and almost never do — is defensibility. Not “is this secure?” but “if this is ever challenged in court or before a bar committee, can I defend the decision I made?”
Defensibility in legal tech means three things:
- Documented chain of custody. Every document access, AI query, and data export is logged with timestamps and user identity. If a privileged document later appears in the wrong hands, you can reconstruct exactly where it went.
- Verifiable architecture. The vendor can show you, in technical terms, that the security controls they describe are architecturally enforced — not just configured as preferences that an administrator can disable.
- Written contractual guarantees. The vendor's data processing agreement explicitly states: what data is processed, where it goes, who can access it, how long it is retained, and that AI models do not train on it. If any of these commitments cannot be made in writing, that is the answer.
The Standard Worth Holding Vendors To
You should be able to sit in front of a bar ethics committee, produce your vendor due diligence file, and explain exactly what security controls you verified before entrusting client data to that platform. “They had a green badge on their website” is not that explanation.
What Real Compliance Looks Like
Real compliance is architecture, not marketing. Here is what it looks like when a vendor has actually built security rather than purchased a badge:
✓ Infrastructure-Level Controls
Security is enforced by the cloud provider's infrastructure, not by application-level settings. AWS IAM policies, for example, cannot be bypassed by a rogue developer or misconfigured deployment — they are enforced at the API level.
✓ Contractual AI Data Isolation
The AI provider — in CaseIntel's case, Anthropic via AWS Bedrock — has contractually agreed that customer data is not used for model training. This is not a default setting. It is a contractual commitment backed by the infrastructure provider's legal obligation.
✓ Immutable Audit Logs
Every document access, every AI query, every permission change is logged in a tamper-evident audit trail. The logs cannot be deleted by an administrator covering their tracks. This is what makes chain of custody defensible in court.
✓ Transparent Scope Disclosure
A vendor with real compliance will tell you exactly what their SOC 2 audit covered — which systems, which controls, and which service boundaries were in scope. They will also tell you what was explicitly out of scope and why.
Your Ethical Obligation as Counsel
The Delve story matters beyond the startup community because it confirmed what sophisticated buyers already knew: the compliance certification market has a trust problem. Certificates can be gamed. Scopes can be narrowed. Auditors can miss things. The badge is necessary but not sufficient.
For attorneys, this is not an abstract concern about vendor risk. It is a question of competence — Rule 1.1 — and confidentiality — Rule 1.6. The ABA and state bars have been increasingly clear: using a legal tech platform without conducting reasonable security due diligence does not satisfy either obligation.
The good news is that doing the due diligence is not complicated. Five direct questions. A review of the data processing agreement. A look at the actual audit report, not the landing page badge. Any vendor worth trusting with your clients' most sensitive information will welcome the scrutiny.
Vendors who resist it are telling you something important.
If your startup's trust layer is fake, your growth is rented.
CaseIntel was built on AWS infrastructure with verifiable, architecturally-enforced controls — not badges. We welcome due diligence.
Start Your Free Trial14-day free trial · No credit card required · Ask us anything about our security architecture
Learn More About CaseIntel Security
Enterprise AI Security
How we built our security architecture
Security FAQ
Common questions about data privacy
Privacy Policy
Full legal disclosure on data handling
Platform Features
What CaseIntel actually does
Questions about our security architecture or compliance documentation? Contact us at security@caseintel.io.