Enterprise buyers read your privacy policy before they read your pricing

The deal is going well. Your champion has run the demo twice, their team likes it, and pricing is next on the agenda. Then an email arrives from someone in Vendor Risk you have never spoken to, and it does not mention your product once. It asks for your data processing agreement, your list of sub-processors, and a completed security questionnaire. One line stands out: "We have reviewed your privacy policy and have some questions."

You wrote that privacy policy before launch. You have shipped every week since.

If you are a founder heading into your first enterprise deal, you need three documents that agree with each other and with your product: a data processing agreement, a current sub-processor list, and a privacy policy that describes what you ship today. My advice is to get them straight before procurement asks. Otherwise the deal waits while you assemble them under deadline pressure, and every contradiction the buyer's lawyer finds before you do reads as a reason not to trust you.

Why does an enterprise buyer read your privacy policy at all?

Because the GDPR tells them to. When a company runs its data through your SaaS, that data is about their users, their employees, their customers. In GDPR terms they are the controller and you are their processor. Article 28(1) says a controller "shall use only processors providing sufficient guarantees" that the processing will meet the regulation's requirements 1. Vetting you is your buyer's own legal obligation. The questionnaire exists because their regulator expects them to show they ran it.

The EDPB, the European Data Protection Board that coordinates the EU's data protection authorities, describes what that assessment looks like in its guidelines on controllers and processors: it will often require an exchange of relevant documentation, and the first two examples it gives are your privacy policy and your terms of service 2. Then come information security policies, audit reports and certifications. Your buyer is not improvising that request; the EDPB wrote the list for them.

Two features of this duty are worth knowing before you reply to that email:

• It is continuous. The EDPB says the obligation does not end when the contract is signed; the controller should re-verify the guarantees at appropriate intervals, including through audits 2. Expect the same questions at renewal, against whatever your documents say by then.
• It runs on what you can show. The guarantees that count are the ones you can demonstrate with documents. Good security practices that exist only in your head do not exist for this assessment.

What will procurement ask for?

Four things cover most first-time vendor reviews:

• A data processing agreement (DPA). Article 28(3) requires a contract wherever a processor handles personal data on a controller's behalf, and it dictates eight stipulations the contract must contain 1. Three are worth reading twice before you sign: you process only on the customer's documented instructions, you delete or return their data when the engagement ends, and you let them audit you. Article 28(9) adds that it must be in writing, electronic form included, so a signable PDF is fine.
• A sub-processor list. Every vendor that touches the personal data you process: your hosting provider, your database host, your email service, your analytics, your LLM API. Article 28(2) forbids engaging one without the controller's prior written authorisation. The standard setup is a general authorisation in the DPA: a blanket approval of the listed vendors instead of a permission request for each one. It comes paired with a duty to inform the controller of changes so they can object 1. The EDPB expects the list in the contract or an annex to it, kept up to date 2.
• Your privacy policy, read closely. For the data you collect from your own users and site visitors, recipients and transfers to countries outside the EEA are mandatory disclosures under Article 13 1. The data you handle for customers is covered by the DPA instead; your policy does not have to describe it. The reviewer still reads the two documents together and checks them for consistency.
• A security questionnaire. Article 32 requires technical and organisational measures appropriate to the risk 1; the questionnaire is the buyer checking yours. The GDPR prescribes no template, so its length and shape are the buyer's choice. Answer what is true. A "no, not yet" reads better in twelve months than a "yes" tested by the audit clause you signed.

What is the buyer's lawyer checking your privacy policy against?

Your other documents, and your product. A vendor review stalls on contradictions between the things you submitted. The patterns to check for first:

• The privacy policy says data stays in the EEA. The sub-processor list has three US companies on it.
• The privacy policy names "trusted partners" as recipients. The product loads scripts from six vendors the policy never mentions.
• The DPA template promises thirty days' notice before a new sub-processor. Nothing in the company tracks when a developer adds one.
• The sub-processor list is missing the LLM API that shipped in the spring.

A contradiction is worse than a gap. A missing document says you have not done this before, and the buyer knew that when they shortlisted you. A document that misdescribes your product says either that you do not know what your own software does, or that you know and wrote something else. The lawyer across the table cannot tell carelessness from concealment, and does not need to; both score as risk.

The buyer's lawyer also knows the transparency guidelines that accompany the GDPR, and those call a "please check this page regularly for updates" clause insufficient and unfair, in so many words 3. A policy that visibly relies on silent updates is itself a flag: substantive changes are supposed to be actively communicated to the people they affect.

Can you assemble all this after the buyer asks?

Yes, and plenty of founders do, in the worst possible conditions: against a deadline, from a template, while the deal waits. I would not plan for that version, for three reasons:

• Template DPAs carry commitments. The sub-processor notice window, the audit rights, the delete-or-return clause: sign them and they bind your product from now on, for this customer and every future customer who gets the same template. Article 28(4) adds that you remain fully liable to your customer when a sub-processor fails 1.
• The sub-processor list requires knowing your stack. Writing it down is the small task. The inventory behind it, every third party that can see personal data, means going through package manifests, script tags, webhooks and the API keys in your environment variables. Almost nobody can produce that list from memory.
• Every contradiction found by the other side costs a review round. Their lawyer sends questions, you draft answers, and the champion who wanted your product waits on a conversation about documents instead.

The drafting is the tractable part. Whether the drafts agree with your product is decided by how well you have tracked your vendors and data flows all along.

How do you keep the documents true after the deal closes?

Signing the DPA converts your document set into standing promises. From then on, every vendor a developer adds is a contractual event: the notice-and-objection mechanism in Article 28(2) entitles your customer to hear about it before it happens 1. Your privacy policy's recipient and transfer disclosures shift the same day your stack does. And none of this is visible at the moment it happens, because a pull request that adds an SDK does not look like a legal event to anyone reviewing it.

If I were heading into that first review, I would start with the inventory, today, before a buyer does it for me: list every third party that can touch personal data in your product, check that list against your privacy policy, and read your own DPA template's sub-processor clause before promising it to anyone.

Keeping that inventory true afterwards is the problem we built Lawcel for. Lawcel keeps a company's legal documents accurate as its product changes: it connects to GitHub, Linear or Jira, analyses each change as it lands, flags the ones that affect your Privacy Policy, DPA or other documents, and proposes the edits. A new vendor in a pull request surfaces as a document update to approve, instead of as a contradiction in your next vendor review. (If you have no documents to your name yet, it drafts the first set from facts about your product, too.) The buyer's lawyer is going to read your documents either way. Better they read the ones that match your product.