Stop trusting the SOC 2 report

The compliance industry has a comfortable lie it tells every procurement officer: if the vendor provides a SOC 2 Type II report, the risk is managed. We treat these documents like digital vaccines. Once the PDF is uploaded to the GRC tool and the checkbox is ticked, the analyst assumes the data is safe.

This week's leak at tl;dv proves that this logic is broken. Just over 180,000 meeting records were exposed because of a vendor-related security failure. The punchline? tl;dv held a SOC 2 certification.

When a company leaks nearly 200,000 records while sporting a gold-standard audit badge, the problem isn't that the audit was "incomplete." The problem is that we’ve confused an auditor's opinion with actual security. A SOC 2 report doesn't measure how secure a system is; it measures whether a company told an auditor what they were doing and the auditor found those claims plausible based on a sample of evidence.

It's a paperwork exercise. In many cases, "privacy by design" in these reports means the company has a policy document that says they design for privacy, not that they actually built any restrictive controls into the code.

The conventional wisdom is that certifications are the only scalable way to manage third-party risk. You can't possibly send your own engineers to audit every SaaS tool in your stack. So, you rely on the certificate. This creates a dangerous second-order effect: it shifts the liability and the gaze. The procurement team stops asking where the data actually goes and starts asking if the certificate is current.

This laziness exposes the downstream customer. When you trust a certified vendor who in turn trusts another certified sub-processor, you aren't building a secure chain. You're building a chain of assertions. If one link fails—as it did here—the entire stack collapses, and the "certified" status of the participants provides zero protection for the data.

The strongest objection to this is that without these frameworks, we'd have no baseline. Critics will argue that SOC 2 forces companies to implement basic controls they otherwise would ignore. This may be true for a startup in a garage, but for any firm handling hundreds of thousands of records, a baseline isn't enough. A baseline is the floor, not the ceiling.

The reality is that we’ve allowed the "certificate" to replace the "investigation."

If you want to actually manage risk, stop looking at the auditor's signature and start looking at the data flow. Where does the record live? Who has the decryption key? What happens when the vendor's own provider fails? These are operational questions that a SOC 2 report rarely answers with any precision. It prefers to say "controls are in place" rather than "the data is encrypted using AES-256 and keys are rotated every 90 days."

We see this same performance in other areas of compliance. Look at the GDPR fines from the second quarter, which hit just under €225 million. Many of those penalties aren't for a lack of policies; they're for a lack of execution. The regulators aren't fining companies because they forgot to write a privacy notice. They're fining them because the actual practice of data handling contradicted the paperwork.

We should treat vendor certificates as the start of the conversation, not the end of it. A SOC 2 report is a signal that the vendor knows how to hire an auditor. It isn't a guarantee that your meeting records won't end up on the open web.

The industry prefers the certificate because it's clean. It fits in a folder. It satisfies a board. But you cannot audit away the risk of a bad vendor choice.

If we keep treating these reports as proof of security, we're just waiting for the next 200,000 records to leak from another "certified" platform. I'll change my mind when I see a SOC 2 report that includes a mandatory, third-party verified map of every single sub-processor's actual data residency and access logs. Until then, it's just expensive stationery.