Privacy policy generator

1. Fill in your business name, website, a contact email you actually read, and an effective date.
2. Tick only the practices your site genuinely has. Untick anything you are unsure about — you can regenerate later.
3. Name your analytics and payment providers if you use them; those appear in the document by name.
4. Set how long you keep enquiry records. Your tax authority usually sets a floor — ask your accountant.
5. Read the generated policy from top to bottom. A policy you have not read is a claim you cannot stand behind.
6. Download it, publish it as a page, and link it from your footer.

Regenerate it when your site changes. Adding a booking form or turning on analytics changes what the policy should say, and a policy that describes last year's website is worse than no policy at all.

The standard template covers every practice any website might have. The reasoning offered is that a broader document is safer, because you cannot be caught doing something it does not mention.

That gets it backwards in two ways. A privacy policy is a public statement about your business; claiming you share data with advertising partners when you do not is inaccurate, and inaccuracy is not a safe harbour. Regulators looking at a complaint compare what you said against what you do — in both directions.

It also destroys the document's actual purpose. Nobody reads a four-thousand-word policy covering practices that do not apply. A four-hundred-word policy describing exactly what your contact form does is one a customer might actually read, and a customer who reads it is a customer who trusts you slightly more.

There is a practical benefit too. When you know what your policy says, you can answer a customer's question about it without opening it. That is only possible when it is short enough to hold in your head.

• Contact form submissions. Whatever the visitor types — a name, a phone number, a message. This is the main thing most local business sites collect, and often the only thing.
• Analytics, if you turned it on. Which pages were viewed, roughly where the visit came from, what device was used. Many owners are unsure whether they have this; check whether you ever set it up.
• Payment details, handled elsewhere. If you take payment, the processor handles the card and tells you only whether it worked. You almost certainly do not store card numbers, and your policy should say so plainly.
• Embedded content. A Google Map, a video, a review widget. These load from someone else's servers, which means that provider can see the visit and may set cookies you do not control. Easy to forget, and worth disclosing.
• Ordinary server logs. Every web host keeps these. They are unremarkable, and a policy that mentions nothing else should still acknowledge them.

The list of things a small brochure site does NOT do is longer and more interesting: no accounts, no profiling, no data sales, no advertising networks, no cross-site tracking. Saying that explicitly is a genuine trust signal, and it is only available to you if the policy is honest.

If your website collects any personal information at all — and a contact form counts — then privacy law in most jurisdictions expects you to tell people what you do with it. That includes the GDPR in the UK and EU, several US state laws, and equivalent regimes elsewhere. The specifics vary; the general expectation does not.

Beyond the law, there are practical requirements. Payment processors and app platforms generally require a published policy. Advertising platforms require one before they will run your ads. And a visitor who is deciding whether to type their phone number into your form has a reasonable question about where it goes.

The threshold for needing one is much lower than owners assume. A one-page site with nothing but a contact form is in scope. A site with no forms at all is arguably not, but its host still keeps logs, and a two-sentence policy saying so costs nothing.

This produces a plain-language policy describing ordinary small-business practices accurately. That is more than most templates manage and it is not the same as legal advice.

There are situations where you should have a lawyer look at it. If you handle health information, financial data, or anything about children beyond ordinary contact details. If you operate across several countries with different regimes. If you are in a regulated profession with its own confidentiality rules. If you sell data or run behavioural advertising — in which case this generator is the wrong tool entirely.

There are also mechanics this does not implement. Some jurisdictions require specific consent behaviour for advertising cookies — a banner that blocks non-essential cookies until the visitor agrees — and a policy alone does not satisfy that. If you run advertising cookies in a jurisdiction with those rules, you need the mechanism as well as the document.

The most important thing, though, is not legal: read what you publish. A policy you have not read is a public statement you have not checked, and if a customer ever asks about it you will be reading it for the first time in front of them.

Put it on its own page and link it from the footer of every page on your site. That is where visitors look, where payment processors check, and where advertising platforms expect to find it.

Link it next to your contact form as well, in small text. It costs nothing and it answers the question the visitor is silently asking at exactly the moment they are asking it.

Then diarise a review. Every time you change what your site does — add a booking form, turn on analytics, start a newsletter — the policy needs regenerating and the effective date updating. Six-monthly is a reasonable rhythm even when nothing has changed, because things change without being noticed.