GDPR privacy policy: does it match what your site does?

The rule

The GDPR does not contain a rule titled “the policy must match the site”. The idea comes from two places: the principle of fair and transparent processing, and the list of things a company has to tell people when it collects their data.

A privacy policy is how most websites meet Article 13. If it names no advertising vendor and one receives the visitor’s data, the policy is open to being set against Article 13’s recipients line. If it says no data leaves the EU and a request goes to a server elsewhere, the sentence and the request disagree.

Penalties sit in the upper tier. Article 83(5)(a) covers “the basic principles for processing”, pursuant to Article 5, and Article 83(5)(b) covers “the data subjects’ rights pursuant to Articles 12 to 22”, which includes the information duties in Article 13. Both carry a ceiling of EUR 20 million or, for an undertaking, 4% of total worldwide annual turnover of the preceding financial year, whichever is higher. Enforcement has mostly concerned missing or unclear information. A literal contradiction between a stated claim and observed behaviour is the narrowest and clearest form, and this check looks for that.

What PeekWell checks and how

EU-05 asks one question per claim: does something your site did contradict a specific sentence in its privacy policy? It looks only for contradiction. Gaps in what a policy discloses belong to sibling checks such as EU-04.

The scan is automated. It reads the privacy policy your site links to and picks out its plain promises, such as “no advertising cookies”, “no third-party sharing” or “data stays in the EU”. It sets each one against what your public pages did when a visitor’s browser opened them. A finding appears only where what the scan saw directly contradicts a specific promise, and the request or cookie that contradicts it is attached.

The scan has limits, and the report says so. It sees the public pages it visited, and the members area when you give it a sign-in. It doesn’t port-scan, try to get in where it isn’t allowed, run any security test or open addresses nobody linked to. A promise a browser visit can’t test, such as how long data is kept, isn’t flagged. Sharing that happens server to server is outside what a visit can see. It doesn’t decide what a word like “share” means in a contract. A Passed means the expected behaviour was observed on the pages scanned. It doesn’t say the site complies.

Why it matters for a company

The Irish authority’s WhatsApp decision of 20 August 2021 carries a fine of EUR 225 million. The authority examined whether WhatsApp had met its transparency obligations toward users and non-users, including information about processing shared with other Facebook companies, and the decision page lists Articles 5 and 13. After the binding decision of the European Data Protection Board of 28 July 2021, it imposed the fine, a reprimand and an order to bring the processing into line. On 10 February 2026 the Court of Justice held that WhatsApp’s action against that binding decision is admissible and sent it back to the General Court, which had not yet ruled on the merits when the Court issued its press release. The WhatsApp inquiry concerned the information WhatsApp gave, not a policy set against site behaviour. It is listed because it shows how the transparency principle is enforced at scale.

At the other end, the Spanish authority’s decision in procedure PS/00080/2023 shows how a policy can fall short next to the behaviour of a site. The consent banner on a lawyer-referral website referred to partners and their “legitimate interest”. The authority found the policy unclear on purposes and legal basis, found the legitimate interests of third parties explained only by opening the separate policies of each vendor on a long list, and found no mention of transfers outside the EU although some of the listed vendors were outside it. It fined the company EUR 2,000 under Article 13. Separately, the authority recorded that “legitimate interest” was pre-ticked for more than half of about 130 vendors (the decision elsewhere describes a far longer list), so objecting meant clearing them one by one. The authority treated that as an infringement of the fairness principle in Article 5(1)(a) and fined EUR 5,000. The resolution also fined EUR 5,000 under the Spanish e-commerce law. The decision does not state the company’s size.

Three consequences follow for a company. A policy is evidence of what people were told, so each sentence in it can be set against the site. Article 5(2) means the company has to be able to show how the two were matched. And a claim true on the day it was written can stop being true when someone adds a tag, so the match needs rechecking after releases.

Smaller companies and larger companies

The rule has no size threshold. What differs is how a mismatch gets there.

In a small company the policy often comes from a generator or a template, written once, with a sentence such as “we do not share your data with third parties”. Later someone adds a chat widget, an advertising pixel or an embedded video, and the page is never touched. Nobody owns the job of comparing the two. A complaint from a visitor is often how it comes to light, as in Spain, where the authority acted after a complaint.

In a larger company legal writes the policy, many teams and agencies change the site, and a tag manager can add vendors without a release. The policy describes the group in general terms while individual sites and apps do different things. In the WhatsApp matter the information gap concerned processing across a group of companies and applied to users and non-users alike.

How to fix it

Write the policy from what the site does, and recheck it when the site changes. Steps 1 and 2 are the same homework as EU-01, which is about trackers that load before consent.

1. List what the site does. Open the site in a private window with the browser’s network tab open. Write down every third-party domain and cookie, then do it again after accepting the banner.
2. Mark each item with a purpose and a recipient. For every vendor on the list, write down what it is for, what it receives and where it is based. Remove any you cannot explain.
3. Pick out the claims in the policy. Find every sentence that starts with “we do not”, “we never” or “your data stays”. Test each one against the list from step 1. Reword or delete a sentence the list contradicts, or remove the vendor.
4. Name recipients and transfers. Make the policy list the categories of recipients or the vendors by name, say what each gets, and state whether data goes outside the EU and on what footing. Replace “may”, “some” and “from time to time” with what actually happens.
5. Tie the policy to releases. Add the policy to the checklist for adding a tag, a plugin or a vendor, so a new request means a new line in the policy before it goes live.
6. Re-scan. Run a scan again after the policy and tags change. The finding should disappear once no claim in the policy is contradicted by the visit.

Whether a rewritten policy satisfies a given authority is for your legal adviser. Peeky reports only what it sees.