Two days from launch with no privacy policy. Twelve facts have to be true.

You are shipping on Thursday. Stripe reviews the website behind your account and can ask you to put a policy page up, the App Store submission form has a required field for a publicly reachable privacy policy URL, and your first three paying customers are in Germany, which means somebody over there is eventually going to read the thing.

So you do what everybody does. You paste your domain into a free privacy policy generator, tick a dozen boxes, and out comes a document that looks exactly like a real Privacy Policy. It says you keep personal data for twenty four months. It says you do not transfer personal data outside the EEA.

Neither sentence is one you have checked. Nothing in your database has ever been deleted on a schedule, because you have not written that job yet. And your app runs on Vercel, emails through Resend, charges through Stripe and posts every user prompt to an OpenAI endpoint, each of which may or may not keep that data in Europe depending on the region and the contracting entity you ended up on. You publish it anyway, because launch is in two days and this is not what you are going to spend them on.

The thing is, the law does not require you to publish a privacy policy document. What is required is a specific list of information about what happens to your users' data. If that list is inaccurate you might as well not have one, except that now the wrong version is public, under your own company name.

The good news is that it is a finite list, and pretty straightforward to get right.

What has to be in a Privacy Policy?

A Privacy Policy is essentially an implementation of GDPR Article 13, and you do not need a long document to satisfy it. Where you collect personal data directly from a person, which is what a signup form is, Article 13(1) and 13(2) together name twelve items you have to provide 1:

1. Your identity and contact details.
2. The contact details of your data protection officer, if you have one.
3. The purposes you are processing the data for, and your legal basis for each.
4. If that basis is legitimate interests, what those interests are.
5. The recipients or categories of recipients of the data.
6. Whether you send data to a country outside the EEA, and what makes that lawful.
7. How long you keep it, or how you decide.
8. The rights people have over their data.
9. The right to withdraw consent, if you are relying on consent.
10. The right to complain to a supervisory authority, meaning a national data protection regulator.
11. Whether they are obliged to give you the data, and what happens if they do not.
12. Whether you decide things about them by purely automated means that have a legal effect or affect them just as significantly, and if so, meaningful information about the logic.

The numbers are mine, because the GDPR does not number them. Items 1 to 6 are Article 13(1)(a) to (f) and items 7 to 12 are 13(2)(a) to (f), in that order. I use the numbers for the rest of this post.

One addition to item 1 if your company is established outside the EU: Article 27 makes you appoint a named contact inside the Union, and that person's details go in the document alongside yours 1.

Two of those twelve are close to boilerplate: item 8, the rights list, and item 10, the complaint right. The complaint right is identical for everyone. The rights list is nearly identical, with one exception. The right to object exists only where you are relying on legitimate interests or a public-interest task, and the right to data portability only where you are relying on consent or a contract, so two of the rights you list depend on the legal basis you already picked in item 3 1. Let a generator draft both. Item 1, your company's identity, you type in and it is correct, unless you are outside the EU and have not appointed that representative.

The other nine are claims about the software you just built. Nobody can check them for you. The generator cannot check them either, because it has never seen your repository, your vendor invoices or your database. It has your answers, and if your answers were guesses, the document is a guess with legal formatting. That gap has been measured: Zimmeck et al.'s scan of a million Android apps found the policies apps did publish often silent on the practices the apps actually performed.

Why does item 5, the vendor list, go wrong first?

Item 5, the recipients of the data, goes wrong first and stays wrong. It is the list of every outside service your product hands user data to, and it lives in your dependency manifest and your card statement rather than in anybody's head. Item 6, whether any of that data leaves the EEA, goes wrong along with it 1. Amos et al.'s analysis of a million privacy policies spanning two decades found exactly this: policies consistently failing to disclose the tracking technologies and third parties actually present.

For a modern SaaS neither is a short list. Your hosting and database providers see it. Your transactional email provider sees the address and the name. Your error tracker sees whatever ended up in that stack trace. Your analytics tool sees behaviour tied to an identifier. Your payment processor sees the buyer. Your LLM vendor sees whatever the user typed into the box.

Almost nobody can produce that list correctly from memory, and I do not hold my own in my head either. Each of those vendors got added on a different afternoon, for a good reason, by somebody who was solving a different problem at the time. There is never a moment when writing them all down is the most urgent thing, so nobody ever does. It shows in what gets published: 60% of Product Hunt sites load a foreign vendor their policy never mentions.

Hand-waving with "we use third-party service providers" does not get you out of holding the real list. Item 5 does let you publish either recipients or categories of recipients. But in 2023 the Court of Justice of the EU, the court that settles what the GDPR's words mean for every member state, ruled on what happens when a user asks: under the right of access in Article 15(1)(c), you have to give that person the actual identity of the recipients, and may fall back to categories only where identifying them is impossible or the request is manifestly unfounded or excessive 2. So you can publish the tidy categorical version, and you still need the real names on file for the day somebody emails and asks.

There is a practical version of this you can do today. Open your dependency manifest and your environment variables, then open your card statement or your billing dashboard, because the vendors that matter are almost always the ones you pay. Write down every service that receives anything about a user, what it receives, why, and which country the company sits in. That list answers items 5 and 6, and about half of the security questionnaire your first enterprise customer is going to send you.

What happens to those twelve facts the week after launch?

This is where the "just generate one before launch" advice quietly fails people.

Article 13 attaches the obligation to a moment: you provide the information at the time the personal data are obtained 1. For a live product that moment is not launch day. It is every single signup, forever. So the document does not have to be true once. It has to be true on the day each new user hands you their email, which means the honest way to read Article 13 is as a standing obligation on a system that keeps changing.

Your product changes weekly. You add Sentry in March. You swap Mailgun for Resend in May. You put an AI summary in the sidebar in July and now every note in the app is going to a model provider that was not on any list. The CNIL, the French data protection regulator, puts this plainly in its guide written for developers: inform people again when there are substantial changes or particular events, and it names new purposes and new recipients as exactly those events 3. The EU-level transparency guidelines read Article 13 the same way: accountability for transparency applies throughout the processing life cycle, and a wider recipient list or a first transfer outside the EEA should reach users before the change takes effect 4.

Nobody sits down and decides to publish something false. What happens is that the pull request adding the vendor is a good pull request, it ships, and the Privacy Policy is a file nobody has opened since launch. Six months later the document describes a product that existed for one week in February.

Which of the twelve get published wrong?

Item 3 tends to go missing rather than wrong: only 45% of Product Hunt privacy policies name a legal basis at all.

Item 12, the automated decisions with a legal or similarly significant effect, goes wrong in both directions. A summary an LLM writes in your sidebar is almost certainly not one of those, so do not disclose a decision you do not make. Automatically declining a signup, cancelling an account or setting a price with no person in the loop plausibly is, so do not skip it because the feature did not feel like a decision when you built it.

Item 7, retention, is the one I would be most careful with. Publishing a period you have not implemented is the claim most likely to be checked against reality, by a customer's procurement team long before a regulator, and "we say twenty four months" against "we have never deleted anything" is an uncomfortable gap to explain.

Where do you start?

Not with the generator. Start with the list. Go back up to the twelve and write down the nine that are about you, in your own words, with your repository and your billing dashboard open. Then draft the document in whatever tool you like: a plainly written policy that is true beats a longer one that says the same things less clearly.

Holding that list is what we built Lawcel to do. Lawcel keeps a company's legal documents matching the product it actually ships: it watches where product change shows up, mostly pull requests and issue trackers, and tells you when a change has made one of your published documents wrong. Before it can do that it has to know the facts, so signing up starts by crawling whatever is on your website today, which two days from launch is usually nothing, and then asking you fifteen questions we require answers to before we will draft anything. Three of them you can answer out of your repository instead of out of your memory.

The document comes out of your answers rather than out of a template with your company name substituted in, and the answers are kept as a record in their own right. That matters most the week after launch: when a pull request adds a vendor or changes a retention window, there is something specific to compare it against, so we can point at the sentence that stopped being true instead of telling you to reread the whole document.

Either way, the work is the same nine facts, and you need them for the security questionnaire anyway. Do it in a text file if you prefer. We built Lawcel because the text file is the one nobody opens again after launch, and by then the document is describing a product you no longer ship.