7 Privacy Policy Mistakes That Are Getting Businesses Fined
On 21 January 2019, France’s data protection authority fined Google €50 million. No servers were breached, and no user data was stolen. Investigators had simply followed the steps a new Android user would take when setting up their phone and creating a Google account. To find out how Google used data for ad personalisation, a user had to click through five separate documents. Geolocation required six. The legal basis Google listed in its privacy policy contradicted itself, citing consent in one place and legitimate interests in another. The CNIL found that users could not measure the extent of Google’s data processing or the degree of intrusion into their private lives. That’s how the fine came about.
That case established something regulators across Europe have acted on ever since. A privacy policy is a legal document. When it is vague, internally inconsistent, or structured in a way that makes key information hard to find, it becomes grounds for enforcement on its own. Transparency failures under Articles 13 and 14, covering incomplete privacy notices, missing data retention disclosures, and inadequate information about data subject rights, now account for 22% of all GDPR fines.
The seven mistakes below are the ones that keep appearing in regulatory decisions across the EU. They are specific, documented, and in most cases entirely avoidable.
Top 7 Privacy Policy Mistakes Under GDPR
Mistake 1: Using Vague Purposes
Article 5(1)(b) of the GDPR requires that personal data be collected for purposes that are “specified, explicit and legitimate.” That word “specified” carries legal weight. A purpose has to be concrete enough that a user reading your privacy policy can understand exactly what will happen to their data and why. A phrase like “we may use your data to improve our services” tells a user nothing. It does not say which data, which services, how the improvement works, or how long the data will be held for that purpose. Regulators have read thousands of privacy policies. They know filler language when they see it.
When the CNIL investigated Google’s privacy policy, it ruled that describing data purposes in broad, high-level terms across multiple documents fell squarely short of the Article 13 transparency standard. As noted earlier, this lack of clarity formed the core of the €50 million penalty – a landmark decision that France’s highest administrative court later upheld in full.
Five years later, the same issue resurfaced in a different case. In November 2024, the Dutch Data Protection Authority fined Netflix €4.75 million after a five-year investigation found that its privacy statement failed to clearly explain the purposes and legal bases for collecting and using personal data, what data was shared with others and why, and the security measures in place when transferring data outside Europe. The company had a privacy policy. It was just not specific enough.
The problem with vague purpose language goes beyond the transparency obligation. Under Article 5(1)(b), the purposes you state in your privacy policy also set the boundaries for what you can legally do with the data. Using broad statements such as “to improve our services” or “for business purposes” does not meet the GDPR requirement that purposes be specified and explicit, and vague or generalised language can undermine the validity of any consent obtained on that basis. In practical terms, if a user consents to data use for “service improvement” and you later use that data to build a behavioural profile for advertising, you have no valid consent for the second purpose and no documented legal basis to fall back on.
The fix is straightforward. For each processing activity in your privacy policy, state the specific purpose in plain terms, the data involved, the legal basis under Article 6, and how long the data is kept for that purpose. “We use your email address to send you order confirmation and shipping updates. We retain this for 12 months after your last order” is compliant. “We may use your contact details to enhance your experience with us” is not.
Mistake 2: Listing Third-Party Tools Without Disclosing What Data They Actually Receive
Take a look at your privacy policy and find the section on third-party tools. It probably reads something like: “We use Google Analytics, Mailchimp, and Stripe to operate our website and services.” That sentence is nearly useless from a compliance standpoint.
Article 13(1)(e) requires you to disclose the recipients of personal data. Not their brand names. The data they receive. Google Analytics collects IP addresses, device information, browser type, and a detailed record of how a user navigated your site. Mailchimp receives email addresses and whatever else your signup form collects. Stripe processes payment card data, billing addresses, and identity information. These are three completely different data flows, each requiring its own explanation in your privacy policy.
The reason this matters is that a user reading your privacy policy is trying to understand what happens to their data when they visit your site. If the policy names tools without explaining what those tools actually receive, the user cannot make an informed assessment. That gap is exactly what Article 13 is designed to close, and data protection authorities know how to spot it.
The fix is to treat each third-party integration as its own disclosure. State what data is transferred, why, and on what legal basis under Article 6. If any of those tools are based outside the EEA, you also need to address the transfer mechanism under Article 46. That is a separate obligation, but it starts with the same question: what data are you actually sending, and where is it going?
Mistake 3: Burying Data Subject Rights in Dense Legal Language
Article 12 sets a clear standard. Information about data subject rights must be provided in a concise, transparent, intelligible, and easily accessible form, using clear and plain language. Regulators treat this as a testable requirement, where they ask: could an ordinary person read your privacy policy and understand what rights they have and how to use them?
When Ireland’s Data Protection Commission investigated WhatsApp, that test became central to the outcome. The DPC found that WhatsApp had failed to provide information to users in a concise, transparent, intelligible, and easily accessible form. The policy addressed rights in language users could not practically navigate. The investigation ran for three years and ended with a €225 million fine in 2021.
Most businesses land in this situation not because they ignored data subject rights but because the section was written by someone thinking about legal coverage rather than user comprehension. The result is a paragraph that lists rights in one long sentence, references applicable legislation without explaining what it means in practice, and gives no indication of how a user would actually submit a request.
Under Articles 15 through 22, users hold eight distinct rights: access, rectification, erasure, restriction of processing, data portability, objection, and rights related to automated decision-making. Each one applies differently depending on how you process data. Your privacy policy needs to explain each right in plain terms, state any limitations that apply to your specific processing activities, and tell users exactly how to submit a request. A contact email or a direct link to a request form is the minimum.
Mistake 4: Copying a Template Policy Without Updating the Contact Details and DPO Information
Somewhere on your website there is a privacy policy that mentions a data controller. The question is whether the name, address, and contact details in that section actually belong to your business, or whether they are still carrying the placeholder text from the template you downloaded two years ago.
This happens more than regulators care to admit. A business finds a free GDPR privacy policy template, swaps in the company name, publishes it, and moves on. The contact details section still reads “insert email address here.” The DPO field either references a role that was never filled or names someone who left the company eighteen months ago.
Under Article 13(1)(a), a privacy policy must state the identity and contact details of the data controller. Under Article 13(1)(b), if a DPO has been appointed, their contact details must also be included. These are the baseline information a user needs to exercise any of their rights under the regulation. If the contact details in your policy lead nowhere, a user attempting to submit a data subject access request has no functioning route to do so, and that failure sits squarely with you.
The DPO obligation carries its own layer of exposure. Under Articles 37 to 39, certain organisations are required to appoint a DPO, including those that carry out large-scale systematic monitoring of individuals or process special categories of data on a large scale. Failing to appoint one when legally required is a Tier 1 violation under the law, carrying fines of up to €10 million or 2% of global annual turnover. A German DPA has already fined an SME €10,000 specifically for failing to appoint a DPO despite being obliged to do so and being formally requested to act.
The fix takes twenty minutes. Check that your privacy policy names the correct data controller, lists a functioning contact email, reflects the current DPO if one has been appointed, and includes an EU or UK representative if your business is based outside those jurisdictions but serves users within them.
Mistake 5: Not Naming the Legal Basis for Each Type of Data Processing
Article 6 of the GDPR lists six lawful bases on which a business can process personal data: consent, contract, legal obligation, vital interests, public task, and legitimate interests. Every processing activity your business carries out must rest on one of these six. More importantly, your privacy policy must state which one applies and for which specific processing activity. Leaving this out is one of the most consequential mistakes a business can make, and enforcement data confirms it. Article 6 violations account for 34% of all GDPR fines, making insufficient legal basis for processing the single largest source of enforcement action under the regulation.
The cases that have defined this area of enforcement carry numbers that are hard to ignore. In January 2023, the Irish Data Protection Commission fined Meta €390 million after finding that the company had changed the legal basis for processing user data from consent to contract necessity, without giving users adequate clarity on why that processing was necessary or what legal basis applied. Meta’s argument was that using Facebook or Instagram constituted a contract, and that delivering personalised advertising was part of fulfilling that contract. That reasoning was, however, rejected by the privacy watchdogs. Behavioural advertising is not necessary to deliver a social media service, which meant contract necessity was the wrong legal basis, and users had never been asked to consent to it under the correct one.
LinkedIn faced the same problem in October 2024, when the Irish DPC fined it €310 million for processing user data for behavioural analysis and targeted advertising without a valid legal basis, having similarly relied on contract necessity and legitimate interests in ways the regulator found unlawful.
For smaller businesses, the mistake takes a more straightforward form. A privacy policy that describes several categories of data processing but assigns no legal basis to any of them leaves the business legally exposed across every one of those activities. Under Article 13(1)(c), where personal data is collected directly from the individual, the privacy policy must state the legal basis for each processing purpose and, where legitimate interests is being relied on, must specify what those interests are. Stating that you process data “in accordance with applicable law” or “as required for our services” satisfies none of this. Those phrases do not identify a legal basis. They describe an outcome.
The practical approach is to map each processing activity in your privacy policy to the relevant Article 6 basis. Customer order data processed to fulfil a purchase sits on contract. Tax records sit on legal obligation. A mailing list built on opt-in sign-ups sits on consent. Marketing to existing customers may sit on legitimate interests, but that requires a documented balancing test and a clear statement in the policy. Each one is a separate entry, with a separate basis attached to it. Regulators read privacy policies looking for exactly this structure, and its absence is one of the clearest signals that a business has not thought carefully about why it is collecting data in the first place.
Mistake 6: Not Updating the Privacy Policy When Processing Activities Change
Think about what your business looked like two years ago compared to today. You may have added a live chat tool, started running retargeting ads, brought in a new payment processor, or begun collecting data through a mobile app. Each of those changes introduced a new processing activity. The question is whether your privacy policy reflects any of them.
Under Article 13, the obligation to inform users about how their data is processed applies at the time the data is collected. That obligation does not expire after the first version of the policy goes live. When processing activities change in a material way, the policy must be updated to reflect those changes, and users must be informed. A privacy policy describing data practices from three years ago is not a live compliance document. It is a record of how the business used to operate.
The risk here is more practical than it might seem. When a regulator opens an investigation, one of the first things they do is compare what a business’s privacy policy says against what the business is actually doing. If your policy mentions two third-party tools and your website is running seven, that gap is documented. If your policy says you use data for order fulfilment and you have since added a behavioural analytics platform, the processing that platform carries out has no disclosed purpose, no stated legal basis, and no retention period. Every one of those omissions is a separate breach of Article 13.
The fix is to treat the privacy policy as a document that needs reviewing every time something changes, not once a year as a compliance checkbox. A new tool, a new marketing channel, or a new data sharing arrangement- any of these triggers an update. The update needs to state what changed, why, and on what legal basis the new processing activity is being carried out.
Mistake 7: Cookie Consent Notices That Contradict the Written Privacy Policy
In September 2025, France’s CNIL fined SHEIN €150 million following an inspection of its website. Investigators found that advertising and analytics cookies were firing on page load, before users had interacted with the consent banner at all. When users clicked “Reject all,” certain cookies kept firing anyway. The written privacy policy described a consent-based approach to cookies. The website was doing something else entirely. The CNIL issued the full fine even after SHEIN corrected the violations during the investigation.
This is the kind of discrepancy that regulators can detect without interviewing a single employee. Automated scanning tools used by data protection authorities identify which cookies fire, when they fire, and whether they fire before or after a user makes a choice. When those results contradict what your privacy policy says, the evidence is already documented.
The legal obligation spans two instruments. Article 5(3) of the ePrivacy Directive requires that non-essential cookies only be placed after a user has given informed consent. Article 4(11) of the GDPR then defines what that consent must look like: freely given, specific, informed, and unambiguous. A privacy policy that describes a consent-based process while the website places tracking cookies before consent is registered breaches both.
The check itself takes under an hour. Run a cookie scanning tool against your website and record what fires, when, and under which category. Then open your privacy policy and compare. Most businesses that do this for the first time find at least one tracker firing outside the parameters their policy describes. That gap is where enforcement starts.
Conclusion
A privacy policy does not protect a business simply by existing. What matters is whether it accurately describes what the business actually does with personal data, names the legal basis for doing it, and gives users enough information to understand and exercise their rights. Regulators have spent the last seven years building the tools, the precedents, and the cross-border coordination to find the gap between those two things.
These mistakes show up in enforcement decisions across the EU, in businesses of every size, and in privacy policies that were written with genuine compliance intent. The difference between a policy that holds up under scrutiny and one that becomes the basis for a fine is usually a handful of specific, fixable omissions.
Start with the most recognisable problem in your current policy and work from there.