A privacy policy is a tedious page to write, so most of them are copied from somewhere. That creates two problems at once: you declare data you never collect, and the data you actually do collect is missing. Either way, the document you are showing visitors is not true.
Fortunately the questions it has to answer are few. There are five, and you can answer all of them by looking at your own site.
One thing first: this is not legal advice. Depending on your sector, the information you handle and how you trade, further disclosures may be required — and if you take payments or handle sensitive data, having a professional check it is the safe move. What follows is the skeleton worth assembling before that conversation.
The five questions
Write in that order and the document acquires a structure by itself. The reason a copied policy is hard to read is usually that these five are tangled together.
Start by counting what you actually receive
This is the step most often skipped. It is easy to think only of the contact form, but a site receives information through more routes than that.
The right-hand column matters most where third-party services are concerned. Video embeds, maps, hosted fonts and chat widgets all make the visitor’s browser connect directly to another company’s servers, and a record is created there. Even if you store none of it, the fact that a route to a third party exists on your site has to be disclosed.
Counting is straightforward. Go through the installed plugin list and note what information each one sends, and where. Forms, analytics, payments, mail delivery, backups and spam filtering are the usual candidates. That list becomes the raw material for the policy — and as a bonus you generally discover plugins you no longer use.
State a retention period you can actually keep
“Destroyed without delay once the purpose is fulfilled” is a common sentence, and very few sites are run that way. Enquiries from three years ago sit in the database, and older ones sit in the backups.
Two decisions are needed here: how long you keep things, and how you will actually delete what is past that point. Without the second, the first is a number nobody honours. It has to be something you can repeat alone — clearing out old enquiries once a quarter, for instance. Decide the backup retention cycle at the same time; data deleted from the live site but still living in backups is the commonest mismatch of all.
There has to be somewhere requests can arrive
If the policy says people may request access, correction or deletion, then an address where such a request will genuinely land has to sit alongside it. Decide in advance what happens when one arrives: how you verify the person, what you delete, and how quickly you reply.
Requests are not frequent. But the one that does arrive takes a long time when nothing is prepared, and a slow response becomes a problem in its own right.
A policy is a promise, not a page
The most practical rule reduces to this: when you change something on the site, look at the policy too. A new form, a different analytics tool, an added payment method — each changes what you collect. Leave the policy alone and the document and the site start drifting apart that day.
The footer is the standard location, and it is worth linking next to any screen where people type something in as well. The point is not to make people read it but to make it readable when they want it. We link ours below the application form and keep the fields on that form to a minimum — information you never collected needs neither protecting nor declaring.
Designing for less collection is covered further in the Security archive, and you are welcome to look at our own application screen as an example of which fields we ask for. A review of site-wide configuration and access is part of our optimization program.