What Your Website's Privacy Policy Actually Needs Under GDPR

Most privacy policies fail GDPR not because the site owner is reckless, but because they copied a template that was written for a different jurisdiction, a different business model, or a different decade. The General Data Protection Regulation is specific about what a privacy notice must contain, and regulators have fined sites whose policies were technically present but missing required disclosures.

Here's what GDPR actually demands your website's privacy policy include, with the article references so you can verify each item against the regulation itself.

The Two Articles That Define the Requirements

Privacy policy obligations for websites come almost entirely from Article 13 (when you collect data directly from the user) and Article 14 (when you obtain data from a third party). Article 12 sets the tone: information must be provided in a concise, transparent, intelligible and easily accessible form, using clear and plain language.

That last clause is doing real work. Walls of legalese have been ruled non-compliant. If your policy reads like a software license, you have a problem before you've even gotten to the content.

Mandatory Disclosures Checklist

At minimum, a GDPR-compliant website privacy policy must include the following:

1. Identity and contact details of the controller — legal name, address, and an email or contact form. A first name and a Gmail address is not sufficient for a registered business.
2. Contact details of the Data Protection Officer, if you're required to have one (public bodies, large-scale monitoring, or processing of special categories).
3. Purposes of processing — for each category of data, why you're collecting it. "To improve our service" is too vague. "To send order confirmations and shipping updates" is specific.
4. Lawful basis for each purpose, chosen from the six in Article 6: consent, contract, legal obligation, vital interests, public task, or legitimate interests.
5. Legitimate interests, where relied on — you must name them. "Network security" or "fraud prevention" works; "our business needs" does not.
6. Recipients or categories of recipients — third parties you share data with (payment processors, analytics providers, email platforms, hosting).
7. International transfers — if data leaves the EEA, name the mechanism (Standard Contractual Clauses, adequacy decision, etc.) and tell users how to get a copy of the safeguards.
8. Retention periods — either the exact period or the criteria used to determine it. "As long as necessary" alone is insufficient.
9. Data subject rights — access, rectification, erasure, restriction, portability, objection, and rights related to automated decision-making.
10. Right to withdraw consent, where consent is the lawful basis, and how to do it.
11. Right to lodge a complaint with a supervisory authority.
12. Whether providing data is a statutory or contractual requirement and the consequences of not providing it.
13. Automated decision-making and profiling, including the logic involved and the expected consequences.

Common Failures in Real Policies

Listing GDPR rights without telling users how to exercise them

Many policies recite the rights verbatim from Article 15-22 but provide no email, form, or process. The regulation requires that requests be facilitated, not just acknowledged in theory.

Hiding the lawful basis

Saying "we process your data lawfully" is not a lawful basis. You must state which of the six bases applies to each processing activity. If you process the same data for multiple purposes, each may have a different basis.

Copying a US-style policy

CCPA and US-style notices often use "opt-out" language and frame personal data around sale and sharing. GDPR is opt-in for most marketing and treats nearly all online identifiers (IP addresses, cookie IDs, device IDs) as personal data. A CCPA-flavoured policy almost always under-discloses for EU users.

Missing the cookie and tracker layer

Cookies aren't governed solely by GDPR — the ePrivacy Directive requires prior consent for non-essential cookies. Your privacy policy should reference your cookie notice and explain the categories of cookies, their purposes, and how consent is managed.

Static retention periods

"We keep data for 7 years" applied to every category is rarely defensible. Order records may need to be retained for tax purposes; a newsletter signup does not. Break retention down by data category.

What Your Page Actually Needs to Do Technically

Compliance isn't just the words on the page. The page itself has to behave correctly:

• Be reachable from every page on the site, typically via a footer link.
• Load without requiring cookie acceptance — users must be able to read the policy before consenting.
• Have a clear last-updated date, and a changelog or notification mechanism for material changes.
• Be served over HTTPS. A privacy policy delivered over plain HTTP is a poor signal at best.
• Be available in the languages your site targets. A German-language storefront with an English-only privacy policy is a red flag.

If you're auditing an existing site, run the URL through a header and SSL check to confirm the policy page is served correctly, indexable, and on a valid certificate. Mixed-content warnings or a redirect chain on the legal page itself undermine trust.

Drafting Sequence That Actually Works

1. Inventory your processing. List every form, cookie, pixel, analytics tag, server log, CRM sync, and email tool. You can't disclose what you haven't mapped.
2. Assign a purpose and lawful basis to each. Be honest. If you're relying on legitimate interests, document the balancing test.
3. Identify processors and sub-processors. Check each vendor's DPA and where they host data.
4. Set retention rules per category. Tie them to a business or legal reason.
5. Write the disclosures plainly. Short sentences. Concrete examples. No "may" when you mean "do".
6. Build the request workflow. An inbox, an SLA, and a templated response set for access and erasure requests.
7. Review on a schedule. Every six months, plus whenever you add a tool or change a processor.

Generate a Compliant Starting Point

If you're starting from zero or rewriting a policy that's drifted out of alignment, use the AXOX Hub Privacy Policy Generator to produce a GDPR-aware draft you can adapt to your specific processing activities. It's free, it covers the Article 13 disclosures, and it gives you a structured skeleton rather than another generic template to paste in.