In short
A privacy policy must identify who you are, what personal data you collect, why, on what lawful basis, who you share it with, how long you keep it, what rights people have and how to exercise them, and how to complain to a regulator. It has to describe your actual practice — a copied policy makes false statements about your business, which is a worse position than an imperfect honest one.
What it must contain
Who you are. The legal entity, not just a trading name, with a contact route. If you have a data protection officer, their details.
What data you collect. Specifically. Not "information you provide" but the actual categories: name and email from the contact form, IP address and device information from analytics, payment details handled by your provider.
Why you collect each thing. Purpose by purpose, since the same data can be collected for several reasons.
The lawful basis for each purpose. Consent, contract, legitimate interests, legal obligation. Where you rely on legitimate interests, say what that interest is.
Who you share it with. Name the categories, and ideally the actual providers — hosting, analytics, email, payments, support. People are entitled to know where their data goes.
Where it is processed, if outside the EU, and what safeguard applies.
How long you keep it, per category. "As long as necessary" alone is not informative; say what determines the period.
What rights people have and how to exercise them, including the right to complain to a supervisory authority.
Cookies and similar technologies, or a link to a separate cookie notice.
How you handle changes to the policy.
Why copying one is worse than nothing
A copied policy makes specific factual claims about your organisation. Almost all of them will be wrong.
It will name tools you do not use and omit ones you do. It will state retention periods you do not observe. It will describe a lawful basis you never considered. It may reference a jurisdiction you do not operate in.
That is not a technicality. If someone makes a complaint, the document describing your practice does not describe your practice — which is a worse position than having an imperfect policy that is honest.
It also fails the underlying purpose. The requirement is to inform people, and a document describing someone else's business does not.
Write it to be read
The requirement is that information is provided in a concise, transparent, intelligible and easily accessible form, in clear and plain language.
In practice:
Use headings people can scan. Most readers want one thing — usually what you do with their email, or how to delete their account.
Write in plain sentences. "We use your email to send order confirmations" rather than "personal identifiers may be utilised for transactional communication purposes."
Use a table for the data-purpose-basis-retention mapping. It is genuinely clearer than prose, and it makes gaps obvious while you are writing it.
Put the practical answers near the top — how to get a copy, how to delete, how to unsubscribe, who to contact.
Say when it was last updated.
A readable policy also has a side benefit: writing one forces you to find out what your site actually does, which is usually the more valuable exercise.
Writing it accurately
The only reliable method is to audit first.
List every system touching personal data — host, analytics, email platform, form handler, CRM, support tool, error tracker, payment provider, any embedded third-party content. For each, note what it receives, why, and how long it retains it.
That list is the raw material. Most of the policy writes itself from it, and the gaps it exposes are the things worth fixing before publishing a document describing them.
Check the embeds specifically. Fonts, maps, video players and social widgets send data to third parties, often before consent, and they are routinely omitted because nobody thinks of them as data collection.
Keeping it accurate
A policy is accurate on the day it is written and drifts from then on.
Review it when you add a tool. Adding analytics, a chat widget or a new email platform changes what the policy should say. Making this part of the process of adding anything is the only approach that works.
Review it annually regardless.
Give it an owner, or it will not be reviewed at all.
Version it, so you can say what the policy was at a given time — occasionally relevant.
What not to put in it
Legal boilerplate that says nothing. Padding reduces the chance anyone reads the parts that matter.
Promises you cannot keep. "We never share your data with anyone" is untrue the moment you use a hosting provider.
Vague reassurance in place of specifics. "We take your privacy seriously" is not information.
Terms of service. Different document, different purpose.
The honest position
A short, accurate, plainly written policy describing what you actually do is better than a long one copied from a larger company — both as a matter of compliance and as a matter of being straightforward with people.
And the audit that makes it accurate is worth doing for its own sake, since it usually surfaces data being collected that nobody intended to collect.
This is general information rather than legal advice. For anything with significant risk, have a lawyer review it.
If you are not certain what your site is currently sending to third parties, book a call — that check is usually an hour and frequently surprising.
Common questions
What must a privacy policy include?
Who you are as a legal entity, what personal data you collect, why, the lawful basis for each purpose, who you share it with, where it is processed, how long you keep it, what rights people have and how to exercise them including complaining to a regulator, and how you handle changes to the policy.
Can I copy a privacy policy from another website?
It is worse than having none, because it makes specific factual claims about your organisation that will be wrong — naming tools you do not use, omitting ones you do, stating retention periods you do not observe. If a complaint is made, your policy does not describe your practice.
How do I write an accurate privacy policy?
Audit first. List every system touching personal data — host, analytics, email, forms, CRM, support, error tracking, payments, and embedded third-party content — and note what each receives, why, and how long it keeps it. The policy largely writes itself from that list.
How long should a privacy policy be?
Long enough to cover your actual practice and no longer. The requirement is that information is concise, transparent and in plain language, so padding works against you. A table mapping data to purpose, lawful basis and retention is clearer than prose and exposes gaps as you write it.
How often should a privacy policy be updated?
Whenever you add a tool that touches personal data — analytics, a chat widget, a new email platform — and annually regardless. Make it part of the process of adding anything, give it a named owner, and version it so you can say what the policy was at a given time.
