Transparency failures in privacy policies have become a central enforcement focus for European data protection authorities in 2026. National DPAs have documented a stark finding: most policies fail the most fundamental test. They don’t accurately describe what actually happens on the website.
A visitor arrives at your site. Google Analytics fires. A third-party chatbot loads. Your payment processor collects card data. Yet the privacy policy written three years ago mentions none of this. This gap between what the policy says and what the website does is exactly what regulators are now attacking.
Articles 12-14 of the GDPR set a clear standard: privacy information must be concise, transparent, intelligible and easily accessible. In practice, this means your policy must do three things simultaneously. It must list every data flow, explain why each one happens and use language a non-lawyer can understand. Most policies fail on all three counts.
This article walks through what the law actually requires, shows you what bad looks like next to what good looks like and explains why your policy may already be out of sync with your website.
What GDPR Privacy Policy Requirements Under Articles 12-14 Actually Mean
Articles 12-14 of the GDPR lay out the transparency obligations. These articles don’t just recommend clarity; they mandate it.
The standard itself is this: information must be provided in a form that is concise, transparent, intelligible and easy to understand. The language used must be plain and simple, especially when information is directed at children. This clarity requirement applies to all privacy information – not just the headline claims but every mandatory disclosure.
Most policies treat transparency as optional polish. They bury mandatory information in walls of legal text. Regulators now treat this differently. The policy isn’t compliant just because the information exists somewhere. It must be findable, understandable and presented in a way that someone without legal training can actually use.
The Eight Mandatory Elements Your Policy Must Cover
Your privacy policy must cover eight core elements. Each one is a separate legal requirement. If you leave one out or describe it unclearly, your policy is incomplete.
1. Identity of the controller. Who is making decisions about the data? This should be clear in a single sentence: the organization name, address and contact method. Many policies bury this in a footer or assume the reader knows. Instead, state it explicitly at the start.
2. Purposes and legal bases for processing. For every type of data collection, you must explain why you’re collecting it and what legal right you have to do so. The GDPR lists six lawful bases (Article 6). Your policy must identify which basis applies to each processing activity. If you track visitor behavior for product improvement, that’s likely Article 6(1)(f) – legitimate interest. If you send marketing emails, that’s Article 6(1)(a) – consent. Simply saying “we process data for our legitimate interests” is too vague. Instead, say: “We collect analytics data (page views, time on page, button clicks) to improve the user experience. Legal basis: Article 6(1)(f) GDPR, legitimate interest in service improvement.”
3. Categories of data collected. Don’t just list “name and email.” Be specific about what you track. If you collect IP addresses, device type, browser behavior and geolocation, list each one. If a third-party tool on your website collects its own data, mention that too.
4. Recipients or categories of recipients. This is where most policies fall short. Many say “we may share your data with partners” without naming them. Regulators specifically target this vagueness. Instead, name the actual tools: “We use Hotjar for user session recordings (shared with Hotjar Inc., based in the United States). We use Stripe for payment processing (shared with Stripe Inc., based in the United States).” If you don’t know exactly who receives data, your website setup is non-compliant, not your policy.
5. Data retention periods. How long do you keep the data? State a specific timeframe for each category. Don’t say “as long as necessary.” Instead: “Analytics data is retained for 14 months. Customer account data is retained for the duration of the customer relationship plus 7 years (for accounting purposes). Email list data is retained until the subscriber unsubscribes.”
6. User rights. Every data subject in the EU has seven specific rights. Your policy must clearly explain each one and say how to exercise it. The seven rights are: access (Article 15), rectification (Article 16), erasure (Article 17), restriction of processing (Article 18), data portability (Article 20), objection (Article 21), and decisions based solely on automated processing (Article 22). Don’t assume people know what these mean. For example: “You have the right to request a copy of all data we hold about you. To exercise this right, email privacy@yourcompany.com with your request. We will respond within 30 days.”
7. Right to withdraw consent. If you rely on consent as a legal basis, the policy must explain that consent is optional and can be withdrawn at any time. Importantly, withdrawal doesn’t undo past processing – only future processing. State this explicitly: “You may withdraw consent at any time by [method]. Withdrawal does not affect the lawfulness of processing before you withdrew consent.”
8. Right to lodge a complaint with a data protection authority (DPA). Every EU resident can file a complaint with their national DPA if they believe their data protection rights were violated. Your policy must provide the name and contact information of the relevant DPA. For the UK, that’s the ICO. For EU data subjects, it’s typically the DPA in the country where they live (or where your organization is based, if different).
Why DPAs Are Finding These Policies Non-Compliant
Enforcement actions in 2025 and 2026 reveal a consistent pattern. Regulators scan websites and cross-reference the privacy policy against what they actually observe happening on the site. Four failures stand out.
Vague language around third parties. A policy says “we work with trusted vendors to provide and improve our services.” This tells the user nothing. Who are the vendors? What do they do with the data? The EDPB’s enforcement guidance now requires naming specific processors and their purposes. “We use Google Analytics to track page views and user behavior” is compliant. “We use service providers” is not.
Missing legal bases per processing activity. Many policies lump all processing under a single basis, usually “legitimate interest.” This doesn’t work. A single website might rely on different bases for different activities. Consent for marketing emails, legitimate interest for analytics, contract performance for payment processing, legal obligation for tax data retention. Each basis must map to the activity it actually covers.
Policies that don’t match actual data flows. This is the gap the EDPB is targeting. A policy written in 2023 may not reflect the third-party tools added since then. Or it may describe what the policy author thought was happening, not what’s actually happening. A developer added Google Tag Manager without updating the policy. A new contact form platform was integrated but not disclosed. These gaps are exactly what a privacy audit uncovers – and what regulators now expect you to have caught yourself.
Information buried or hard to find. Some policies are long PDFs with no table of contents. Others are embedded three clicks deep on the website. The GDPR requirement for “easily accessible” means the policy should be reachable in one or two clicks from the homepage. If someone visiting your website has to hunt to find the privacy policy, the policy is not easily accessible by law.
How to Write Each Section: Bad vs. Good Examples
Let’s walk through each mandatory element and show what non-compliant language looks like next to what passes scrutiny.
Identity of the controller
Bad: “Privacy inquiries can be directed to our office.”
Good: “Data Controller: Acme Corp Ltd, 123 Main Street, Dublin, Ireland. Email: privacy@acmecorp.ie. Phone: +353-1-234-5678.”
Why the difference: The bad version doesn’t actually identify anyone. The good version names the legal entity, gives a physical address and provides multiple contact methods.
Purpose and legal basis
Bad: “We collect information to improve our services.”
Good: “We collect page views, time-on-page and click behavior through Google Analytics (legal basis: Article 6(1)(f) GDPR, our legitimate interest in understanding user needs and improving website performance). We collect email addresses from your newsletter signup form to send you our weekly digest (legal basis: Article 6(1)(a) GDPR, your explicit consent, which you can withdraw at any time).”
Why the difference: The bad version is too general and doesn’t identify the legal basis. The good version ties each data type to a specific basis and shows why it’s lawful.
Categories of data
Bad: “We collect personal information.”
Good: “We collect: your IP address, device type, browser type, pages visited, time spent on each page, buttons clicked, and approximate geographic location (inferred from IP). We do not collect name, email or payment data unless you voluntarily submit it through a form.”
Why the difference: Specificity matters. “Personal information” is a label, not a disclosure. Listing each category forces you to confront what you’re actually tracking – which often reveals gaps in your policy or in your consent flows.
Recipients
Bad: “We may share data with third parties to provide better services.”
Good: “Your data is shared with the following third parties: Google LLC (Google Analytics) – based in the United States; Stripe Inc. (payment processing) – based in the United States; Intercom Inc. (customer support chat) – based in the United States. For information about data transfers to the US, see our Data Transfers section below.”
Why the difference: The bad version is not just vague – it suggests data might be shared when the user doesn’t know with whom or why. The good version names actual vendors and allows the user to make an informed choice.
Retention periods
Bad: “We retain data for as long as necessary.”
Good: “Analytics data: 14 months. Customer account data: duration of relationship plus 7 years. Email list data: until unsubscribe or 2 years of inactivity. Support chat conversations: 12 months. Server logs: 7 days.”
Why the difference: “As long as necessary” is subjective. Courts have rejected it. Specific timeframes show you’ve actually thought about retention and can defend it.
User rights
Bad: “You have certain rights under data protection law.”
Good: “You have the right to: (1) request a copy of your data (Article 15 GDPR); (2) correct inaccurate data (Article 16); (3) request deletion (Article 17, subject to legal exceptions); (4) request restriction of processing (Article 18); (5) receive your data in a portable format (Article 20); (6) object to processing (Article 21); (7) lodge a complaint with your DPA (Article 77). To exercise any of these rights, email privacy@company.com. We will respond within 30 days.”
Why the difference: The bad version assumes users know what rights exist and how to exercise them. The good version explains each right in plain language and gives a single point of contact.
Withdrawing consent
Bad: “Consent can be withdrawn.”
Good: “If we rely on your consent to process data, you may withdraw it at any time by emailing privacy@company.com or clicking ‘Unsubscribe’ in any email we send. Withdrawal does not apply retroactively; it only stops future processing.”
Why the difference: The good version explains how to withdraw, clarifies that the user must actively do so (not assumed) and sets accurate expectations about what withdrawal does and doesn’t do.
DPA complaint right
Bad: “You may file a complaint with your data protection authority.”
Good: “You have the right to lodge a complaint with your local data protection authority. If you are in the EU, find your DPA here: https://ec.europa.eu/justice/article-29/structure/data-protection-authorities/index_en.htm. If you are in the UK, contact the Information Commissioner’s Office (ICO): https://ico.org.uk/.”
Why the difference: Naming a DPA and giving contact information removes friction. It signals that you take the right seriously – and that complaints are possible and expected.
The Gap Problem: Your Policy Says One Thing, Your Website Does Another
The most dangerous compliance failure is silence by omission. Your policy doesn’t lie about a data flow. It simply doesn’t mention it.
This happens in three common scenarios.
Scenario 1: The Policy Wasn’t Updated After a Tool Was Added
Your website originally used Mailchimp for newsletters. The policy lists Mailchimp as a recipient. Last year, the team switched to Klaviyo but forgot to update the policy. Now the policy mentions a tool you no longer use and omits the one you do. A visitor downloads your privacy policy and sees no mention of Klaviyo. When they later notice a Klaviyo email in their inbox, they’ve lost trust. A regulator would flag this as a misleading policy.
Scenario 2: The Policy Was Written by Sales, Not by the People Who Actually Know What Happens
The original policy was drafted by someone familiar with the organization’s intentions, not its actual technical setup. It says “we do not collect location data,” but a third-party analytics tool silently infers location from IP addresses. It says “we do not use profiling,” but a recommendation engine is running on the homepage. The policy wasn’t written dishonestly. It was written without knowledge of what the website actually does.
Scenario 3: Embedded Scripts Collect Data Nobody Foresaw
You added a support chatbot to your site. You disclosed it in the privacy policy. But the chatbot vendor loads three additional vendors on their own – heatmap trackers, analytics, session recording. You didn’t know this was happening. The policy never mentioned these tools. Now you’re liable for undisclosed processing.
These gaps reveal why a privacy policy audit requires more than reading the policy. It requires comparing the policy against what’s actually on the website.
Fixing the Gap: Know What Your Website Actually Does
The only way to close the gap between your policy and your reality is to audit the website. This means scanning what actually gets loaded, what data actually leaves the browser and where it goes.
A complete audit answers five questions:
What third-party vendors are loaded? Use your browser’s Network tab or a tool like Nixon Pro to see every third-party domain your website contacts. Screenshot the list. This becomes your vendor disclosure list. If your privacy policy doesn’t mention each one, the policy is incomplete.
What data is sent to each vendor? For each third-party, determine what data they collect. Google Analytics collects page views and click behavior. A heatmap tool collects mouse movements and scrolls. Stripe collects payment information. Document this for each vendor.
When is data sent? Does the data leave before or after consent? This matters legally. If Google Analytics fires before the visitor clicks “accept” on the consent banner, you’re collecting data without consent – which is not allowed. If it fires after, you’re compliant (assuming consent was actually given).
Where is the data stored? Is the vendor based in the EU, US, or elsewhere? If outside the EU, you need a legal mechanism (Standard Contractual Clauses, Adequacy Decision, etc.) to lawfully transfer the data. Your policy should disclose this.
What is your legal basis for each transfer? If data goes to a US company without explicit consent, what GDPR article justifies it? This is where many policies break down. They transfer data under “legitimate interest” without considering that the recipient may not offer equivalent protection. In 2024-2025, several DPAs ruled that transferring personal data to the US without explicit consent violates Article 6. Your policy must address this.
Once you’ve answered these questions, update your privacy policy to reflect reality. Then set a schedule to re-audit quarterly. Website tools change. Your policy must keep pace.
Using Tools to Keep Policy and Practice in Sync
Manually auditing your website for every third-party data transfer is tedious. Tools exist to automate this.
Nixon Platform helps you monitor what data flows are active on your website and alerts you when new vendors appear. You can use it to detect when a tool was added without policy updates, flagging the compliance gap before a regulator does.
Nixon Pro performs a privacy audit on your website. You input your URL, and it scans for all third-party vendors, identifies what data they collect and tells you what your privacy policy should cover. This closes the gap between what you think is on your website and what’s actually there. Rather than manually reading through code or Network tabs, Nixon Pro gives you a report that maps directly to policy obligations.
Both tools are designed around a simple principle: your privacy policy should reflect your actual website. When tools change, both should change. The alternative – a static policy with a dynamic website – is how non-compliance happens.
Putting It Together: A Privacy Policy Template
Here’s a structure that works for most websites:
- Controller identity (1 paragraph)
- What data we collect and why (1 section, broken by data type and legal basis)
- How long we keep data (1 section, table format if many categories)
- Who sees your data (1 section, vendor list with locations)
- How to exercise your rights (1 section, steps for each right)
- Complaint procedures (1 paragraph)
- Cookies and tracking technologies (1 section, cross-reference to cookie policy)
- Updates to this policy (1 paragraph)
Write each section in plain English. Assume the reader has no legal training. Avoid cross-references that force the reader to flip back and forth. Use lists instead of dense paragraphs.
Final Point: Regulators Are Now Checking
The EDPB’s 2026 enforcement action isn’t a one-time sweep. It signals a shift in regulatory focus. DPAs across Europe are now spot-checking websites and comparing policies against actual data flows. When they find gaps – tools mentioned in the website code but not in the policy, or vague language that doesn’t explain what actually happens – enforcement follows.
This doesn’t require a perfect policy. It requires an honest one. One that reflects what your website actually does, explains it clearly, and is kept up to date when your website changes. If your policy was last updated more than a year ago and you’ve added tools since then, it’s time to update it. If you’ve never done a full audit of what your website actually sends to third parties, now is the time to start.
The EDPB’s message is clear: transparency is not decoration. It’s a legal obligation. Your policy must prove it.
Ready to audit your website against your privacy policy? Nixon Pro scans your site and identifies every third-party vendor, tracking technology and data flow. Get a detailed report that shows you exactly what your privacy policy needs to cover. Learn more about Nixon Pro.
For ongoing compliance, use Nixon Platform to monitor your website for new data flows and receive alerts when third-party tools change – ensuring your policy stays in sync with your actual website. Explore Nixon Platform.
The full legal text for the requirements discussed here is in GDPR Articles 12-14.
Related reading: EDPB 2026 enforcement focus: does your privacy policy meet transparency requirements? | Website privacy audit checklist | How to find every tracker on your website
