Short answer. Almost every website needs a privacy policy: a contact form, analytics or advertising cookies already make you a data controller. The policy explains what personal data you collect, why, on what lawful basis, how long you keep it and who receives it. Publish it on every page and link it from every form.
Who needs a privacy policy
What makes you a data controller is not the size of your business but the fact of processing. A lead form with a name and phone number, a newsletter signup, user accounts, comments — all of that is personal data collection. Analytics scripts and advertising pixels collect visitor identifiers, browsing behaviour and device parameters, and many cookies can single out an individual visitor. Even a landing page with no forms but with an analytics tag is processing personal data.
Being a controller comes with duties: tell people transparently what you do with their data, obtain consent where consent is the lawful basis, protect the data you hold and answer data subject requests. Under the GDPR these duties apply whenever you offer goods or services to people in the EU or monitor their behaviour — your own location does not matter.
Privacy policy, privacy notice and consent: what is what
The terms overlap, but the roles differ. A privacy policy (or privacy notice) is your document: it informs visitors about your processing. Consent is the visitor's action: a freely given, specific, informed agreement to a particular processing operation — for example, ticking a checkbox before submitting a form. The policy is published unconditionally; consent is collected only where consent is your lawful basis. Other lawful bases — contract, legal obligation, legitimate interests — must still be named in the policy.
A policy copied from another company, with someone else's legal entity still named in it, is itself a compliance failure — and a clear signal to any regulator that nobody in your company has read the document.
Sections your policy must contain: a sample structure
There is no universal template — the document must describe your real processes. But the skeleton of a working website privacy policy is nearly always the same:
- controller identity, legal details and a contact for privacy requests;
- categories of personal data collected: name, email, phone, cookie and analytics identifiers;
- purposes of processing, mapped to each data category;
- lawful basis for each purpose: consent, contract, legitimate interests;
- how the data is processed and by whom;
- retention periods or the criteria used to set them;
- recipients and processors: hosting, CRM, email services, analytics providers;
- international data transfers and the safeguards applied;
- cookies and tracking technologies: what is set and why;
- data subject rights and how to exercise them;
- how to withdraw consent;
- security measures and the date of the current revision.
Fill each section with facts: which forms exist on the site, which third parties receive data, where it is stored. Vague statements like "we take appropriate measures" with no specifics work against you in any audit.
Where and how to publish the policy
The policy must be easy to find before a visitor hands over any data. The standard pattern is a footer link on every page pointing to a stable URL. Publish it as an HTML page rather than a PDF: a page opens on any device, is indexable and works with screen readers.
<footer>
<nav>
<a href="/en/privacy">Privacy policy</a>
</nav>
</footer>
Every form that collects data needs a link to the policy and, where consent is the lawful basis, an unticked consent checkbox. A pre-ticked box is not valid consent: the visitor must act.
<label> <input type="checkbox" name="consent" required> I agree to the processing of my personal data as described in the <a href="/en/privacy">privacy policy</a> </label>
Cookie consent banner: when you need one and what it must do
Strictly necessary cookies — a shopping cart, a login session — do not require consent. Everything else does: analytics, A/B testing, advertising and social media pixels must not fire until the visitor agrees. That is the combined effect of the ePrivacy rules and the GDPR consent standard: consent must be prior, informed, freely given and as easy to withdraw as to give.
A compliant banner briefly explains which cookies are used and why, links to the policy, offers a real choice — accept or reject with equal prominence — and keeps the site usable after rejection. Typical violations: pre-ticked boxes, "by continuing to browse you agree" wording, no reject button, and analytics tags loaded before the visitor answers.
A banner that drops analytics cookies before the visitor has answered is worse than no banner at all: it documents that you knew consent was required — and ignored it.
Test what your site actually does with a cookie banner check: it shows which cookies are set before consent. While you are at it, review the cookies' own attributes — Secure and HttpOnly — covered in this guide to cookie security flags.
Fines and risks
GDPR fines are tiered: the most serious violations — including processing without a lawful basis and ignoring data subject rights — can cost up to 4% of global annual turnover, and the lower tier is still painful. National regulators also enforce cookie consent rules separately, and enforcement decisions are public: reputational damage often outlasts the fine itself.
| Violation | Framework | Typical consequence |
|---|---|---|
| No policy or an incomplete one | GDPR transparency duties | orders to comply, fines, public enforcement record |
| Invalid consent, pre-ticked boxes | GDPR consent standard | fines up to the top tier for systematic violations |
| Tracking before consent | ePrivacy rules | national fines, orders to change the banner |
| Data breach with poor security | GDPR security duties | largest fines plus mandatory breach notification |
Technical posture matters as much as the paperwork: a form posting over plain HTTP or a vulnerability exposing your customer base turns a formal gap into a real breach. Check your SSL certificate, run a basic website security check, and see what a security check should cover.
Operating in Russia: what applies on top
If your site serves Russian users, local law 152-FZ adds its own layer: a published operator policy, consent checkboxes wired to specific wording, and a notification to Roskomnadzor, the local regulator, before processing starts. The requirements overlap with the GDPR but do not mirror it. A dedicated 152-FZ compliance check highlights the gaps, this walkthrough of 152-FZ website compliance explains the details, and ongoing monitoring for Russia-facing sites keeps the status under control.
Self-audit checklist
- the policy is published and reachable from every page;
- it names your legal entity, not a template placeholder;
- data categories and purposes match the forms and tags actually on the site;
- every form links to the policy and uses an unticked consent checkbox;
- no analytics or advertising cookies fire before consent;
- retention periods are stated and actually enforced;
- forms submit over HTTPS with a valid certificate;
- the current revision date is visible;
- the policy is reviewed whenever forms or third-party services change.
FAQ
Do I need a privacy policy for a landing page with analytics but no forms?
Yes. Analytics collects visitor identifiers and behavioural data, so processing happens even without a single form. The policy and a cookie disclosure are required for such a page too.
Can I copy another site's policy?
Someone else's text describes someone else's processes: different forms, different processors, different retention. A mismatch between the document and reality is itself a violation. Use a template as a skeleton, but rewrite every section for your site.
What is the difference between the policy and consent?
The policy is your document describing the processing; consent is the visitor's affirmative action allowing a specific processing operation. One never substitutes for the other.
Do strictly necessary cookies need a banner?
No — session, cart and security cookies work without consent. But they still belong in the policy's cookie section, and the moment you add analytics or advertising tags, the banner becomes mandatory.
Does a simple email form trigger Russian 152-FZ duties?
If the site targets Russian users — almost certainly yes: an email plus a name is personal data, and the exemptions from notifying the regulator are narrow. Run a 152-FZ check to see the full list of requirements for your site.