An auditor keeps your security honest. Nothing keeps your privacy policy honest.

On the road to enterprise customers you will, at some point, buy a SOC 2 audit, and probably a platform like Vanta to prepare for it. From then on, compliance feels handled: there is a vendor, a dashboard, and a date in the calendar.

But actually, "compliance" has two components: security (which SOC 2, ISO 27001 and Vanta are about) and legal compliance. Legal compliance means keeping the statements your company publishes about your product true at all times. Your privacy policy and terms must stay accurate as your product changes, and Vanta doesn't help you with that. This is what we built Lawcel for.

The mix-up is easy to make, and nobody selling to you has much reason to point it out. I went through the exercise for Lawcel last week, pricing SOC 2 first and then ISO 27001, and the boundary really is unmarked: the industry calls itself compliance automation and refrains from specifying what they actually mean by "compliance". So here is where the boundary runs: what a SOC 2 audit examines, what Vanta does, and what both of them leave standing unwatched.

What does a SOC 2 audit examine?

A SOC 2 report is an assurance report: a licensed audit firm (a CPA firm, under the framework owned by the AICPA, the American accountants' institute) examines the controls a vendor operates and reports on them, so that customers can assess the risk of outsourcing to you 1. The controls are graded against the Trust Services Criteria, which cover five areas: security, availability, processing integrity, confidentiality, and privacy 1. Security is the baseline every report includes; the other four are added per engagement.

Strip the branding and the controls are mundane organisational facts. Production access is restricted and reviewed. Employees who leave lose their accounts. Incidents have a written response process. The audit samples evidence that these held. A report covers a period and buyers expect a current one, so the examination recurs for as long as you sell.

That recurrence is the reason security posture stays maintained at every serious company: an external check is scheduled, the date is in the calendar, and revenue depends on passing it.

What does Vanta do, if it does not certify you?

Vanta sells the preparation. In its own words, the platform pulls data automatically from 400 or more tools, monitors your controls continuously, automates audit prep and evidence collection, drafts security questionnaire responses, and publishes a Trust Center where buyers can see your posture 2. It supports dozens of frameworks; SOC 2 and ISO 27001 are both on the list 2.

An audit is, at bottom, an evidence-gathering exercise, and the gathering is what used to hurt. Vanta pre-gathers: it connects to your cloud, your repos, your device management and your HR tooling, and keeps timestamped proof that the mundane facts above stayed true. When the auditor arrives, the evidence is already collected and organised. That is genuinely useful, and nothing about it is sneaky. The signature on the report still belongs to the audit firm.

The platform watches your infrastructure so an auditor can vouch for your controls. Every part of that loop, the integrations, the evidence, the report, faces your security. None of it reads the promises you publish.

Who checks the documents your buyer reads first?

Your privacy policy is a set of factual claims about your product: what you collect, who receives it, where it leaves the EEA. Some of those claims are mandatory. Article 13 of the GDPR requires you to disclose, among other things, the recipients of personal data and any transfer to a third country 3.

The obligation does not stop at publication. The transparency guidelines that accompany the GDPR, written jointly by the EU's data protection authorities and endorsed by the EDPB (the board that coordinates them), state that transparency applies "not only at the point of collection of personal data but throughout the processing life cycle" 4. Substantive changes to a privacy notice should always be actively communicated, and a fundamental change should be communicated well before it takes effect. Their examples of a fundamental change: enlarging the categories of recipients, and introducing a third-country transfer 4. Both are things a routine merge produces.

One habit the guidelines reject outright: a line in your policy telling users to check the page regularly for updates is, in their own words, "not only insufficient but also unfair" 4.

So the obligation is continuous, exactly like the security obligations your audit covers. The check is not. Nothing in the audit you are buying is scheduled to read your privacy policy against your product. The careful readers your policy does eventually get are adversarial ones: the buyer's counsel in a vendor review, a regulator after a complaint, opposing counsel after an incident. My cofounder wrote earlier on this blog about what enterprise procurement does with those documents; the short version is that they read them before they read your pricing, and they bill contradictions as risk.

So if you are selling to enterprise buyers, you need a standing check on your privacy policy like the one you are buying for your security controls, or the buyer's lawyer will find the contradictions before you do.

Why is security compliance an industry and legal compliance is not?

The two obligations cost you at different moments, and that difference in timing has produced two entirely different economies.

The audit gates revenue before the sale. Procurement asks for the report by name, the deal waits until it exists, and so a budget line exists, a deadline exists, and a platform market grew up to serve both. You buy SOC 2 to make money.

Document accuracy costs you after something goes wrong. No deal waits on your privacy policy being current this quarter. The cost arrives later, as a stalled vendor review, a regulator's question, or a fine, and costs that arrive later lose to deadlines that arrive first. You fix your policy to avoid losing money, and there is no date in the calendar by which you must.

That asymmetry is my explanation for how every fast-moving company ends up with a security posture that is continuously maintained and legal documents that misdescribe the product: one check has a deadline and the other does not. Nobody had to be negligent. Each merged pull request can move the facts: a new SDK is a new recipient, a new API region is a new transfer, a new analytics tool is both. The policy stands still while the product walks away from it.

None of this contradicts your audit. The report vouches for the criteria you scoped into it 1, and even where the privacy criterion is in scope, the auditor examines your controls on the audit's schedule; nobody reads each release against the text you publish. Certified and misdescribing your product at once is a stable condition.

What would the same discipline look like for your promises?

You can measure your own gap right now. Open your privacy policy and find its last-updated date. Open your merged pull requests, or your release notes, and count what has shipped since that date. Every one of those changes went out unexamined against the claims the policy makes, because no examination exists on that side of the house.

Closing that gap is what we built Lawcel for. Lawcel watches the repository your product ships from, reads each change against the legal documents you publish, and proposes the edits when a merge adds a vendor, a transfer or a data flow your Privacy Policy, ToS or DPA does not describe. It connects to GitHub, Linear or Jira, and it is the loop you just bought for your security controls, pointed at the documents your buyers read first. If the count you just did came back as more than zero, connect your repository. The next change that moves the facts will land as a document update to approve instead of one more unexamined merge.