Privacy policy: writing one that describes what you actually do

A privacy policy tells people what personal data you collect, why, what you do with it, who else sees it, how long you keep it, and what rights they have over it. In most regimes with modern data protection law it is a legal requirement rather than a courtesy, and the obligation is specifically to describe your actual processing — which is why a generated policy that mentions services you do not use is worse than no policy at all.

The practical failure is easy to spot from the outside. A one-person consultancy publishes a policy referencing advertising cookies it does not set, a data protection officer it does not employ, and transfers to countries it has never sent data to. That is not a technicality: it demonstrates the disclosure was never checked, which is exactly the impression you cannot afford when somebody complains.

What the policy has to answer

• Who you are, as a legal entity, with a contact route for privacy questions specifically.
• What data you collect. Be concrete: names and emails from the contact form, order and delivery details from purchases, analytics data from the site.
• Why, and on what basis. Most regimes expect a stated lawful basis — a contract, consent, a legitimate interest — per purpose rather than in general.
• Who else receives it. Your hosting, payment processor, email provider, analytics, delivery company. Naming the categories is normal; naming the actual providers is better and increasingly expected.
• Where it goes, if data leaves your region, and on what safeguard.
• How long you keep it, tied to a real retention position rather than as long as necessary, and covered properly in data retention policy.
• What rights people have — access, correction, deletion, objection — and how to exercise them, which is the mechanics side of subject access request.
• How to complain, including to the supervisory authority where one exists.
• When the policy last changed.

Write the policy after listing what you actually collect, not before. Half an hour with your own site — every form, every embedded script, every integration — usually turns up two or three things nobody remembered: an old analytics tag, an embedded map that sets cookies, a chat widget. That list is the policy. Doing it in the other order produces a document describing an imaginary business.

Privacy policy, cookie notice, terms

Three documents that keep getting merged and should not be. The privacy policy is the disclosure about personal data. The cookie notice concerns storage and tracking on the device, usually with a consent mechanism attached, and is covered in cookie notice. The terms and conditions are the contract between you and the user. They reference each other and do different jobs, and a regulator looking for one will not accept a section heading inside another.

Keeping it true

1. Review it whenever you add a tool that touches personal data — a new form, a new analytics package, a new mailing platform. That is the moment it goes stale.
2. Date the last revision visibly, and keep old versions for the same reason you keep old terms.
3. Match it against the cookie banner. Contradictions between the two are the most common inconsistency and the easiest for anyone to check.
4. Make the privacy contact route real and monitored. Requests have deadlines in most regimes, and the clock does not wait for somebody to check a neglected mailbox.
5. Say it in plain language. Several regimes explicitly require it to be intelligible, and impenetrable text is a compliance problem rather than a protection.

Where it lives

Ettex Sites hosts the page and keeps it linked from the footer of every page and from the forms that collect data, which is where it is legally expected to be reachable. What the site itself collects through forms is visible in Ettex Forms, and the marketing side of consent is covered in marketing database.

Being direct: we do not generate privacy policies, do not review them and cannot tell you what your jurisdiction requires. The obligations differ substantially — the GDPR, the UK regime, various state laws in the US, and others besides — and the one thing that is universally true is that the document has to describe your processing rather than somebody else's. Where the business handles anything sensitive, a lawyer who read your actual data flows is money well spent.