What must a privacy policy contain? The GDPR requirements point by point

Most websites process personal data — a contact form, an order, an analytics tool or simply logged IP addresses is enough. The GDPR then requires that visitors get clear information about the processing, and in practice the privacy policy is where that information lives. The requirements are not just about the policy existing: articles 13 and 14 list exactly what must be stated, and article 12 additionally requires that all of it is written clearly, plainly and is easy to access. Here we walk through the full list, the most common gaps and how to fix them.

GDPR art. 12–14

What does the law say?

The word "privacy policy" does not appear in the GDPR. What the law requires is that whoever processes personal data informs the data subjects about the processing — and a consolidated policy page is the established way to do that. Article 13 applies when the data is collected from the person themselves (forms, purchases, accounts), article 14 when it comes from another source (registers, partners, purchased lists). The lists largely overlap, but article 14 adds the requirement to state where the data comes from.

Article 12 adds a requirement on top of the content: the information must be clear and transparent, written in plain language and easy to access. Intelligibility is a legal requirement in its own right — a policy that contains every mandatory item but is written so that an ordinary visitor cannot understand it still falls short of article 12.

What the privacy policy must contain

The points below follow articles 13 and 14. Not everything applies to everyone — if you have no data protection officer nothing needs to be stated, and automated decision-making is only relevant if it occurs — but every point must be included when it applies:

The controller's identity and contact details — which company or organisation is responsible for the data, with a working way to reach them.
The purposes of the processing — why the data is collected, in plain terms: order handling, newsletters, statistics.
The legal basis for each processing activity — consent, contract, legal obligation or legitimate interest. Where legitimate interest is relied on, the specific interest must be stated, not just the phrase.
The categories of data — what kinds of data are involved: name, email, IP address, purchase history. Mandatory when the data comes from a source other than the person themselves, and good practice in every policy.
Recipients or categories of recipients — who the data is shared with. Categories are enough ("payment providers", "IT hosting providers"), but something must be stated.
Third-country transfers — if data is moved outside the EU/EEA this must be disclosed, together with the safeguards used, for example the EU's standard contractual clauses or an adequacy decision.
Retention period — how long the data is kept, or the criteria used to determine it when an exact period cannot be given.
The data subject's rights — access, rectification, erasure, restriction, objection and data portability.
The right to withdraw consent — where the processing relies on consent.
The right to complain to the supervisory authority — in Sweden IMY, the Swedish Authority for Privacy Protection.
Automated decision-making and profiling — if it occurs, with meaningful information about the logic involved and the consequences for the data subject.
Where the data comes from — when it was not collected from the person themselves (article 14).
Contact details for the data protection officer — where one is required, including for public-sector bodies.

Intelligible, easy to find — and in the visitor's language

Article 12 makes the form part of the requirement. The policy must be findable from every page — in practice a link in the footer — and readable without obstacles. Two traps we see regularly: the link to the policy is broken, or the text sits in an embedded document viewer that the cookie banner blocks, so the visitor has to accept cookies before they can read what the consent means.

Language belongs here too. A website aimed at a Swedish audience should have its policy in Swedish — that follows from the requirement that the information be intelligible to the audience, and for public-sector bodies also from the Language Act. More language versions are of course welcome, but the Swedish one must exist.

Common issues we see

The most common problem is not that the policy is missing, but that it is a template that was never finished — or was written years ago and then forgotten. The signs are easy to recognise:

Leftover placeholders like "[Company name]" — the policy was published straight from the template without being filled in.
References to Datainspektionen, the Swedish supervisory authority renamed IMY in 2021, or to the Personal Data Act (PUL), replaced by the GDPR in 2018 — the text has not been touched in years.
The wrong company named as controller — the policy was copied from another website.
No last-updated date, so nobody can tell whether the text is still accurate.
"Legitimate interest" cited as the legal basis without the interest ever being specified.
Recipients described only as "trusted partners" — which tells the visitor nothing about where the data actually goes.
The rights are listed, but there is no contact channel for actually exercising them.
Retention is not mentioned at all, or only as "as long as necessary" with no criteria.

How CompliantHQ tests this

The scanner locates the website's policy pages, reads them as documents and runs deterministic checks that the mandatory parts exist — every point in the list above has its own check: controller, purposes, legal basis, recipients, retention, rights, the right to complain, withdrawal of consent, third-country transfers and the data protection officer. We also check for the signs of a dead template: placeholders, references to PUL or Datainspektionen, a missing update date and the wrong company name.

On top of that, our compliance AI reviews what requires judgement: is the policy intelligible to an ordinary visitor (article 12), are the recipient descriptions too vague, is legitimate interest relied on without the interest being stated? AI assessments are always presented as exactly that — assessments, never established violations.

All of these checks already run during the trial.

How to fix it

Go through the checklist above against your current policy and tick off every applicable point — that is the fastest route to a complete text.
Name your own organisation as controller, with the registration number and a working contact channel.
Make the typically vague parts concrete: what the legitimate interest is, which categories of recipients receive the data and how long the data is kept.
Write in plain language — short sentences, headings per topic, no article references without explanation. Intelligibility is a legal requirement, not a bonus.
Publish in the audience's language, date the text and update it when the processing changes — a new analytics tool or a new supplier should show up in the policy.
Link the policy in the footer and verify that it can be read without accepting cookies.

What the check covers

That a privacy policy exists and is reachable.
That the links to the policy pages work and don't lead to error pages.
That the policy can be read without first being forced to accept cookies.
That the policy names which company is responsible for the personal data.
That the policy doesn't name the wrong company as responsible — a common trace of copied templates.
That the party responsible for the data can be contacted — email, phone, address or a contact page.
That the policy explains why the data is collected and what it is used for.
That the policy states on what legal footing the data is handled — for example consent, a contract, or a legal obligation.
That the policy describes what kinds of data are handled — for example name, email, IP address or purchase history.
That the policy tells you who the data is shared with — for example suppliers, payment services or analytics tools.
That the policy states how long the data is kept — or how that is decided.
That the policy lists the visitor's rights — to see their data, have it corrected or deleted, and more.
That it's clear how to exercise those rights in practice — an email address, a form or a contact page.
That it's clear you can complain to the Swedish privacy authority (IMY) if you believe your data is mishandled.
That it's clear a given consent can be withdrawn. Applies when the site relies on consent.
That the policy explains what protection is used when data is sent outside the EU — for example the EU's standard contractual clauses — instead of merely noting that it happens.
That the policy tells you when we've measured data actually being sent to recipients outside the EU — for example US ad platforms.
That the policy carries a last-updated date.
That the policy contains no leftover template blanks like "[Company name]" or "Lorem ipsum" — signs of a copied template that was never filled in.
That the policy doesn't reference Datainspektionen — the authority was renamed IMY in 2021, so such a reference is a strong sign the policy hasn't been maintained.
That the policy doesn't reference the old Swedish Personal Data Act (PUL) — it was replaced by the GDPR in 2018, so the reference means the policy is out of date.
The AI judges whether the policy is comprehensible to an ordinary reader — the GDPR requires clear and plain language.
When the policy uses the legal basis "legitimate interest": does it explain which interest is actually meant — or is only the phrase used?
The AI judges whether the description of who the data is shared with is too vague — "trusted partners" says nothing.
That it's clear whether data collected for one purpose is later used for something else — and if so, how.
That it's clear whether decisions about the visitor are made automatically or profiles are built — for example automated credit assessments.
That it's clear where the data comes from when the person didn't provide it themselves — for example purchased address lists.
That it's clear how to say no to marketing mailings.
That the policy explains on what legal footing sensitive data is handled — health, religion, political opinions and more have extra-strong protection under the GDPR.
Healthcare-specific review: the legal footing for health data, the Swedish Patient Data Act, and that the website is kept separate from the medical-record system. Applies to care providers.
Municipality-specific review of the legal footing — public authorities can rarely ask citizens for consent, since the citizen has no free choice. Applies to municipalities and public-sector bodies.

Common questions

Does every website need a privacy policy?

The information duty applies to everyone who processes personal data — and almost every website does, through contact forms, orders, accounts or analytics tools. In practice: yes, if the site collects anything at all, it needs a privacy policy.

Is starting from a template enough?

A template can be a good start, but it must be completed and adapted to your actual processing — your purposes, your recipients, your retention periods. Leftover placeholders and the wrong company name are among the clearest gaps we find.

Does the policy have to be in Swedish?

If the website is aimed at a Swedish audience the policy should be available in Swedish — the information must be intelligible to the audience under article 12. For public-sector bodies the requirement also follows from the Language Act.

Do we have to state an exact retention period?

Preferably, but it is not always possible — in that case the GDPR allows you to state the criteria used to determine the period instead, for example "for as long as the customer relationship lasts and thereafter as required by accounting law". A bare "as long as necessary" with no criteria is not enough.

Is the cookie policy the same thing as the privacy policy?

No — the privacy policy describes the processing of personal data under the GDPR, while the cookie information covers which cookies and trackers are set and rests on the consent requirement in the ePrivacy rules. The information can live in the same document, but both parts must exist.

Want to see what we find on your site?

Run a free scan — all four modules included for 30 days, no card required.

Start free scan See pricing