The European Data Protection Board announced in late 2025 that its 2026 coordinated enforcement action would target transparency and information obligations — specifically Articles 12, 13, and 14 of the GDPR. In March 2026, that action officially launched, with supervisory authorities across EU member states actively auditing how organizations communicate their data processing practices to users.
Translation: regulators are looking at privacy policies right now. Not as a background activity — as their explicit enforcement priority for the year.
The fines for transparency failures aren't small. The GDPR allows penalties up to €20 million or 4% of global annual turnover for violations of the transparency principles. And the enforcement record shows that supervisory authorities don't just go after the big tech companies. A telecommunications company in Germany received a €300,000 fine this year specifically for transparency and accountability failures. A utility company got €300,000 for pre-checked consent boxes and vague data notices.
The EDPB's 2026 coordinated enforcement action targets Articles 12-14 — the transparency and information obligations that govern what your privacy policy must say. Every EU member state supervisory authority is participating.
Here's what makes this harder than it sounds: most companies wrote their privacy policy once, probably copied significant chunks from a template, and haven't touched it since. The document might look long and official. It can still be non-compliant in multiple ways that aren't obvious without knowing what regulators specifically look for.
These are the seven mistakes I see most consistently — and the ones regulators are most likely to flag in 2026.
1. Vague processing purposes with no lawful basis
Stating purposes without specifying the legal basis for each one
Article 13(1)(c) requires you to state both the purpose of processing and the lawful basis for it. Most policies state purposes ("to provide our services," "to send you updates") but never specify which of the six GDPR lawful bases applies to each activity.
The six bases are: consent, performance of a contract, compliance with a legal obligation, protection of vital interests, performance of a public task, and legitimate interests. You must name the specific one — and if you're relying on legitimate interests, you must describe what those interests are.
HOW TO FIX ITCreate a processing activities table or clearly structured list. For each activity, state: what data, what purpose, and which lawful basis. If you use legitimate interests, add a brief explanation of the interest and why it isn't overridden by user rights.
2. "We keep data as long as necessary"
Using retention language that tells users nothing
Article 13(2)(a) requires you to specify the period for which personal data will be stored, or if that isn't possible, the criteria used to determine that period. "As long as necessary for the purposes described above" is not a period. It's not even criteria. It's a placeholder.
This comes up in almost every enforcement action involving privacy notices. The Dutch DPA, the ICO, and the CNIL have all issued guidance making clear that this phrasing doesn't satisfy the requirement.
HOW TO FIX ITBreak out retention by data category: account data (deleted 30 days after account closure), purchase records (7 years per tax law), marketing preferences (2 years from last interaction), support tickets (1 year). Specific timeframes are better; specific criteria (e.g., duration of contractual relationship plus 3 years) are acceptable when exact periods can't be set.
3. Listing rights without explaining how to exercise them
Enumerating data subject rights as a bullet list with no practical instructions
Most privacy policies include a section listing the rights: right of access, right to rectification, right to erasure, right to portability, right to restriction, right to object, rights related to automated decision-making. That section satisfies Article 13 only if you also explain how users actually exercise those rights.
Article 12(2) requires you to facilitate the exercise of data subject rights. A list with no contact information, no process, and no timeframe isn't facilitation — it's a formality that provides nothing of practical use.
HOW TO FIX ITAdd a clear statement: how to submit requests (email address, web form, or portal), what information to include in the request, and that you'll respond within 30 days (the statutory maximum under Article 12(3)). If you have a designated DPO, include their contact details separately.
Not sure if your privacy policy covers all of this?
PolicyAudit scans your privacy policy against GDPR's transparency requirements automatically — including lawful basis, retention periods, and data subject rights. The free tier checks up to 3 documents.
Check your privacy policy free →4. International transfers with no mechanism named
Disclosing that data leaves the EEA without identifying the transfer safeguard
If you transfer personal data outside the European Economic Area — which most companies do, because AWS, Google Cloud, Salesforce, HubSpot, Stripe, and hundreds of other US-based vendors process your users' data — Article 13(1)(f) requires you to identify the transfer and the "safeguards in place" or the "means by which to obtain a copy of them."
Saying "we may transfer data internationally" isn't enough. You need to name the mechanism: adequacy decision (covers countries like the UK, Japan, and South Korea), Standard Contractual Clauses (the most common mechanism for US transfers), Binding Corporate Rules, or an approved certification.
The TikTok €530 million fine from Ireland's DPC in 2025 was specifically about unauthorized data transfers to China with no adequate safeguard. That's an extreme case, but the principle applies at every scale.
HOW TO FIX ITAudit which vendors receive personal data and where they process it. For US-based vendors (most SaaS tools), confirm they have SCCs in place with their EU/EEA data processors. Name the mechanism in your privacy policy: "For transfers to the United States, we rely on Standard Contractual Clauses approved by the European Commission."
5. Automated decision-making isn't mentioned
Ignoring Article 22 obligations around profiling and automated decisions
Article 13(2)(f) requires you to disclose "the existence of automated decision-making, including profiling" and provide "meaningful information about the logic involved, as well as the significance and the envisaged consequences."
Most companies think this only applies to fully automated decisions like credit scoring or loan applications. It doesn't. It applies wherever you use personal data to evaluate, analyze, or predict things about individuals — behavioral analytics, lead scoring, email segmentation based on activity, personalized pricing. If you use any modern marketing or analytics stack, you're likely doing profiling under the GDPR definition.
HOW TO FIX ITWalk through your marketing and analytics tools and identify any that perform scoring, segmentation, or behavioral modeling. If none produce "solely automated decisions" with legal or significant effects, you can state that and briefly describe the profiling activities that do occur. If you do make automated decisions with significant consequences, you must explain the logic and give users the right to human review.
6. Describing third-party sharing in generic terms
Listing recipient "categories" so broadly they convey nothing
Article 13(1)(e) requires you to identify "recipients or categories of recipients of the personal data." Many privacy policies satisfy this technically but fail it practically by listing categories like "service providers," "business partners," "analytics providers," and "advertising partners" — categories so broad that a user has no real understanding of who actually has their data.
The EDPB's guidance on transparency is clear that the description should be specific enough to be meaningful. "Third-party analytics providers" covers both a small A/B testing tool and Google. Those aren't the same risk profile and shouldn't be described the same way.
HOW TO FIX ITName specific vendors where practical, or at minimum provide genuinely specific categories: "cloud infrastructure providers (AWS, Google Cloud)," "CRM tools (HubSpot)," "payment processors (Stripe)." For advertising partners, this is where specificity matters most — list the actual platforms if you use third-party tracking pixels or ad networks.
7. Treating your cookie banner as a substitute for your privacy policy
Conflating the ePrivacy Directive cookie obligations with GDPR transparency obligations
Cookie consent and privacy policy transparency are legally separate requirements. The cookie banner (or cookie consent tool) satisfies your obligations under the ePrivacy Directive for consent to non-essential cookies. The privacy policy satisfies your GDPR Article 13 obligations to inform users about all data processing activities.
A lot of companies have implemented a cookie consent tool — which is good — and then treated this as having handled their privacy obligations. It hasn't. Even with a perfect cookie banner, your privacy policy still needs to cover all the items in this list: lawful bases, retention periods, data subject rights, transfer mechanisms, automated processing, and third-party recipients.
The other common failure here is the reverse: using your privacy policy to obtain consent to cookies. Consent buried in a privacy policy isn't valid GDPR consent for cookies — it needs to be specific, informed, and given at the point of collection, not inferred from someone reading a document.
HOW TO FIX ITKeep these as separate, linked documents that each serve their own purpose. Your privacy policy covers GDPR Article 13 obligations. Your cookie policy or consent banner covers ePrivacy consent. Neither substitutes for the other.
How to actually check your privacy policy
Reading through this list and trying to manually audit your own privacy policy is painful. You're looking for specific omissions in a document you probably wrote (or inherited), and it's easy to miss gaps when you're too close to it.
There are a few ways to approach this more systematically:
- Map your data flows first. You can't write an accurate privacy policy if you don't know what data you collect, where it goes, and how long you keep it. A data inventory — even a rough one — surfaces the gaps that need to be addressed.
- Use a structured checklist against Articles 12-14. The EDPB has published guidelines on transparency that spell out exactly what's required. Reading the text directly, then checking whether each element is in your policy, is tedious but thorough.
- Automated scanning gives you a faster starting point. PolicyAudit checks your policy document against GDPR's transparency requirements and flags what's missing or vague. It's not a replacement for legal review on complex questions, but it identifies the obvious gaps — missing lawful bases, absent retention language, no data subject rights process — in under a minute. The free tier handles up to 3 documents.
Whatever approach you use, don't put this off. The EDPB's 2026 enforcement action means supervisory authorities are specifically looking at privacy notice compliance this year. Getting this right now is substantially cheaper than dealing with an inquiry after the fact.
This post covers the technical requirements from the GDPR text and EDPB guidance. For complex situations — cross-border data flows, sensitive data categories, AI systems, or regulated industries — work with a qualified data protection lawyer or a DPO. Automated tools and guides like this one identify common gaps; they don't replace legal judgment.
Frequently asked questions
Check your privacy policy against GDPR requirements
PolicyAudit scans your policy document against GDPR's transparency obligations and highlights what's missing. Free for up to 3 documents — no credit card required.
Scan your privacy policy free →