GDPR privacy policy for a website — what it must say, and where

The GDPR duty to inform sounds like something you "implement". On a website it is one document and a handful of points where the site meets the visitor — and it starts earlier than most owners assume: not at the contact form, but at the first request, because the IP address lands in the server logs before anyone has clicked anything.

This article is about the website, not the company. The record of processing activities, the data protection officer, audits and fines are a separate field with a separate adviser — the boundary is drawn plainly at the end.

What a site collects before anyone fills in a form

This is the place to start, because it moves the whole problem a few seconds earlier.

The IP address is always written to the server logs. Even on a site with no form, no newsletter and no analytics. Under the GDPR that is personal data, and it is the first reason why even a one-page brochure site needs a privacy policy.

An embedded map and fonts served from someone else's server send a request on first render. Not when someone clicks the map — when the page loads. The visitor's IP address travels with that request to a company whose name is not in your policy, because nobody imagined that a typeface could be a transfer of data.

This is not a theoretical point, and the reason is European rather than national. In Breyer (C-582/14, 19 October 2016) the EU Court of Justice held that a dynamic IP address can be personal data for a website operator, because the operator has lawful means of identifying the person behind it with the help of others. Everything that loads from a third-party server carries that address to the third party. The practical consequence is simple: the same fonts, maps and icons can almost always be served from your own server, so the browser never contacts anyone else — and a transfer you do not make needs no justification, no sentence in the policy and no consent.

Advertising pixels and chat widgets do the same, only louder. With a pixel there is an added question of who the controller actually is — because the provider does not process solely on your instructions, but for its own purposes as well.

There is one more distinction here that shapes the content of the policy and is often skipped: not every recipient of data is the same kind of recipient. Your hosting provider and your newsletter tool act on your instructions — they process what you tell them to, for the purpose you set. The GDPR calls them processors. An advertising pixel provider does something else: it also uses the data on its own account, to build its own profiles. Those are two different relationships and two different sentences in the policy, and throwing both into one bucket labelled "partners" is exactly the evasion that produces a policy which informs nobody of anything.

The practical conclusion: before you write the policy, make an inventory of what the site actually sends. Open it in a browser with the Network tab of the developer tools open and read the list of domains the requests went to. There are usually between two and five names on it that nobody in the company knew about — and those, not the form, decide half of what the policy has to say.

Where do they come from, if nobody ordered them? From three places, always the same ones. The theme — design themes routinely load fonts and icons from third-party servers. Plugins — the map, the testimonial carousel, the chat, the form. And old campaigns — a pixel added for one advertising push that ended long ago, with the script left behind. The third case is the most common and the easiest to fix: usually a single line to delete, which has been sending visitor data for two years to a system nobody uses.

The duty to inform — what it means on a website

Article 13 of the GDPR says that when you collect personal data from a person, you have to give them a defined set of information at the time you collect it. On a website, the privacy policy is how you meet that duty — not a separate ritual, not an extra document, just that one.

Three things follow from this, and in practice they get confused.

The policy has to be available at the moment of collection, not afterwards. Since the logs are written the moment someone arrives, the link has to be visible from every page — the footer is fine, as long as it is on every page. A policy linked only beneath the contact form is a whole visit late.

It has to be written so that it can be read. Article 12 requires the information to be given in a concise, transparent, intelligible and easily accessible form, using clear and plain language. That is a legal requirement, not a stylistic one — and it is precisely the requirement broken by policies stitched together from quotations of the regulation.

The duty does not end with informing. Its second half is responding: if someone writes to ask what data you hold about them, or asks for it to be erased, the answer is due without undue delay and in any event within one month, extendable by two further months only where the request is complex. On a company website this happens rarely — but when it does, it usually turns out that nobody knows where the data is. It is worth settling in advance, even in two sentences: who answers, which places the data has to be gathered from, and who has access to them.

At the form, repeat what concerns the form. Not the whole policy — one short sentence saying who the controller is and why the data is being collected, plus a link to the full text. Consent to "processing of data for the purpose of answering the enquiry" is not needed for this — the basis here is usually your legitimate interest or steps taken before entering into a contract, not consent. An extra checkbox that changes nothing legally only lowers the number of forms sent.

One more note, because it is a frequent source of confusion: provider information is not the privacy policy. A business website in the EU also has to make available who runs it — name, geographic address, email, trade register and VAT number where they exist — under Article 5 of the e-Commerce Directive, which in Poland is implemented by Article 5 of the Act on Providing Services by Electronic Means (ustawa o świadczeniu usług drogą elektroniczną): business name, registered address, email, and the registration details — NIP (tax number) and KRS or CEIDG entry. It is a different obligation under a different law. Putting the privacy text inside the imprint, or the other way round, does not satisfy either one more fully; it just makes both harder to find.

What must be in the policy, and what is padding

The left-hand column is not our list of good practices — it is the scope of Article 13. Two items need a comment, because that is where content is most often missing.

Recipients are specific companies, not categories. "Cooperating entities" is not an answer. The hosting provider, the analytics provider, the newsletter system, the accountant — these are recipients, and they have names. If any of them processes data outside the European Economic Area, that is a separate piece of information, together with the safeguard relied on.

The storage period can be given as a criterion. You do not have to invent a number of years for every category: "until you object" or "for the limitation period of possible claims" are correct answers, as long as they are true.

The same goes for the supervisory authority: name it. "A supervisory authority" is not specific enough to be useful to the person reading it. In Poland, where the GDPR is called RODO in official documents, name it: the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych, UODO).

Now the padding test, because the right-hand column grows on its own. For each paragraph of the policy, ask which question on the left it answers. If it answers none, it is padding. This is not a matter of taste: a policy in which the required information drowns in twenty thousand characters of copied regulation fails the requirement of a concise and intelligible form — so it is weaker legally, not just harder to read.

Cookies have their own legal basis — and templates often cite another country's law

This is the most common substantive mistake we see in texts about consent on websites, and it deserves its own section.

Cookies are not governed primarily by the GDPR. They are governed by [Article 5(3) of the ePrivacy Directive](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02002L0058-20091219) — the rule on access to the user's device — and because it is a directive, each member state writes it into its own law. In Poland that law is the Electronic Communications Law (Prawo komunikacji elektronicznej), in force since 10 November 2024, whose Article 399 replaced Article 173 of the 2004 Telecommunications Law (Prawo telekomunikacyjne) — still cited by many guides and old cookie policies. Your policy should cite the current act.

Article 5(3) reads more strictly than it is usually summarised. Storing information on the user's device, or accessing information already stored there, is permitted only if the user has consented, having been given clear and comprehensive information. And the same sentence matters just as much for what it refers to: the information and the consent are defined by EU data protection law, which since 2018 means the GDPR — Article 94(2) of the GDPR turns every reference to the old directive into a reference to the regulation. The Court of Justice confirmed the consequence for banners in Planet49 (C-673/17, 2019): a pre-ticked box is not consent. That is the bridge the next section stands on — the consent standard for cookies comes from the GDPR: freely given, specific, informed, unambiguous, and as easy to withdraw as to give.

The exceptions are narrower than they are applied. Consent is not required where the sole purpose is to transmit a message over a public network, or where storage or access is strictly necessary for the provider to deliver a digital service the user has expressly requested. A shopping basket and a login session fit that without argument. Analytics does not — nobody visits a website expressly requesting a measurement of their own behaviour.

It is only fair to add what the national differences do not mean. The structure is the same everywhere — prior information, consent, narrow exceptions for what the user asked for — because it comes from the same directive; the details of implementation and enforcement are what depend on the member state. But the national layer has two practical consequences. First, a cookie policy that cites another country's act was copied from another country's template — harmless on its own, and visible to anyone who checks, including the person filing a complaint. Second, it is a good indicator of the document's age and care: a policy nobody adapted when it was copied is a policy nobody has read since, and in that time the list of plugins has usually changed as well.

What invalidates a consent banner

Since the consent standard is the GDPR's, the list of things that cancel it is well known.

Pre-ticked boxes. Consent has to be an action, not the absence of one; the GDPR's recitals say in so many words that silence, pre-ticked boxes or inactivity do not constitute consent. A window with every category ticked and a "save" button does not collect consent — it collects a click.

No equally easy refusal. If "Accept all" is a large button and refusing means going into the settings and switching off five toggles, the consent is not freely given. The symmetry is about the number of clicks, not the colours.

Scripts that fire before the decision. The most common technical fault and the only one invisible in a design mock-up: the banner displays correctly, and the analytics and the pixel have already started. Checking takes a minute — open the site in a new private window and see whether identifiers appear before you click. How to wire this correctly on the measurement side is covered in our piece on analytics and consent mode.

Consent forced by access. A wall that will not let people reach the content until they accept marketing makes consent a condition of entry — and therefore not freely given.

No way to withdraw. Under Article 7 of the GDPR, withdrawing has to be as easy as giving. In practice that is one link in the footer that reopens the same settings window.

It is also worth knowing what a banner does not do: it does not replace the privacy policy, and it is not a legal basis for everything the site does with data. They are two different obligations from two different legal acts, and meeting one does not release you from the other.

Three faults we find most often

From our audits, in order of frequency.

The policy lists recipients who are not there and leaves out those who are. The classic symptom of a copied template. We have seen a policy naming a payment provider on a site with no shop, and saying nothing about the analytics running on every page. Checking takes as long as the inventory from the first section.

The banner blocks only its own cookies. The consent tool installs correctly, displays correctly and records the choice — and scripts placed directly in the theme, outside that tool, start regardless of it. A fault invisible from the admin panel and visible in thirty seconds in the browser.

There is no way to withdraw consent. The banner appears once, stores the choice for a year and leaves no link to come back through. The fix is one item in the footer opening the same settings window — five minutes of work, and sometimes the only gap between the current state and a correct one.

The contact form

The most common point of data collection on a company website — and the most common place where more is collected than anyone needs.

The data minimisation principle in Article 5 says data must be adequate, relevant and limited to what is necessary for the purpose. For a contact form, the purpose is to answer the enquiry. To answer, you need a way of answering and the content of the question — usually a name, an email address and a message.

Fields worth removing because they do not serve that purpose: a phone number as a required field, company name, budget bracket, "how did you hear about us". Each is a question you can ask in your reply — and each lowers the number of forms sent, which we cover separately under conversion rate.

Two things to do beyond the form itself:

Check where the enquiries land and how long they stay there. A mailbox holding enquiries from four years ago is a store of data with no defined retention period — and that is a real problem, not a missing checkbox.

Check who has access to it. A shared address that three people log into with one password is a data protection question and a security question at once.

Who is actually responsible

The last distinction, because it decides who receives the bill when something goes wrong.

The controller is the company that owns the site — not the agency that built it, and not the hosting provider. You decide why data is collected and how long it is kept, so the duty to inform is yours. Your contractor can draft it and implement it technically, but cannot take it over.

The contractor and the host are usually processors — they process on your instructions. Article 28 requires that relationship to be governed by a contract, and a data processing agreement is the one document from the whole GDPR area that genuinely should exist between you and your agency. If it does not, and the agency has access to the enquiry mailbox or the database, that is a gap worth closing — however well the collaboration is going.

Pixel providers and some advertising tools can be joint controllers, because they also process the data for their own purposes. Article 26 then expects the arrangement between you to be set out and its essence made available to the people concerned. That changes the content of the policy, but takes nothing off you — on the contrary, it adds the duty to tell people about the arrangement.

The practical consequence is one sentence, and worth saying plainly: outsourcing the website does not move the responsibility to the contractor. You can, and should, require that they implement it correctly — but the question "is your site compliant?" always comes back to the owner.

What to do, in this order

If you are starting from scratch, this is the order in which nothing has to be redone.

1. An inventory of what the site sends — the list of domains from the Network tab. Without it, the rest is guesswork.
2. A privacy policy written around the Article 13 list, with the recipient names from step one.
3. A consent banner wired so that it actually blocks scripts until the visitor decides — and checked in a new private window.
4. A review of the forms: fields, destination, retention period, access.
5. A link to the policy in the footer of every page, a short note at the form, and a permanent link back to the cookie settings.

The first four steps are a day's work on a typical company website. The fifth takes a quarter of an hour and is often skipped because it looks done already.

Something to settle while somebody is in those settings anyway: who in the company owns this document, and when will they next read it. A privacy policy does not age with time; it ages with changes to the site — a new plugin, a new newsletter tool, a new campaign with its own pixel. Each of those adds a recipient of data, and none of them will remind you to add a sentence. The habit that works for us: the policy review sits on the same list as the plugin review, not in a separate legal folder.

What this article deliberately leaves out

• The record of processing activities, the data protection officer, audits and fines. That is the GDPR inside the organisation, not on the website — a different field and a different adviser. We could not keep it current, and it is not what anyone asks us about.
• The GDPR in recruitment and in video surveillance. The same boundary.
• A ready-made policy template to copy. A template copied without step one lists recipients you do not have and omits the ones you do — which makes it worse than nothing.
• Legal advice. This is a description of what we see when building and auditing sites, with the legal bases stated plainly so that you can check them or show them to a lawyer. Doubtful cases belong to the lawyer.

The shortest summary: on a website, the duty to inform is one document, one sentence at the form, and one banner that genuinely blocks. The rest of what ends up in privacy policies was copied from someone else's template — and makes it harder to find the things that have to be there.