The Ireland Data Protection Commission's €403 million fine against Google Ireland Limited wasn't about a data breach or a rogue employee. It was about everyday processing decisions that seemed reasonable in product meetings but failed basic transparency and retention requirements under Articles 5, 6, and 13.
Your team likely makes similar decisions every week.
Why These Mistakes Keep Happening
Most transparency failures don't start with malice. They start with product teams who understand user experience but not Article 13's layered transparency obligations. They continue when legal reviews focus on whether a privacy notice exists, not whether it actually explains processing purposes in plain language. They solidify when retention schedules are set by storage capacity rather than purpose necessity.
The DPC's investigation covered processing from May 25, 2018, to February 4, 2020, examining three features: Web & App Activity, Location History, and Location Accuracy. The supervisory authority found violations across lawfulness, fairness, transparency, accountability, and retention. These weren't edge cases. They were core product features used by millions.
If your organization processes location data, behavioral data, or cross-service activity logs, you're making the same category of decisions Google made. Here's where teams go wrong.
Mistake 1: Treating Transparency as a Notice Requirement, Not a Disclosure Obligation
Why it happens: Teams draft privacy notices to satisfy Article 13's checklist, listing purposes in broad categories like "service improvement" or "personalization." Legal signs off because all required fields are present. The notice goes live.
The consequence: The DPC found Google's transparency failures across all three features. Deputy Commissioner Graham Doyle specifically noted that inadequate transparency left users unaware their location data was being used for advertising or interest inference. When your notice says "personalization" but you're actually building ad targeting profiles, you haven't met Article 13(1)(c)'s requirement to specify purposes.
The fix: Map each data element to its specific processing purpose before you draft the notice. If location data from Feature A feeds three different systems (fraud detection, service delivery, and marketing analytics), your notice must explain all three. Don't use umbrella terms. Write: "We use your approximate location to show nearby restaurants in search results and to measure ad campaign performance in your region." Test the notice with someone outside your team. If they can't explain what you're doing with their data after reading it, rewrite.
Mistake 2: Assuming Consent for One Feature Covers Related Processing
Why it happens: You build an ecosystem of connected features. Users enable Location History to see their Timeline in Google Maps. Your analytics team then uses that same location data to improve ad targeting. It feels like a natural extension of the same dataset, so you don't seek separate consent or establish a separate lawful basis.
The consequence: The DPC found Google failed to lawfully and fairly process location data collected through Web & App Activity and Location History. Each processing purpose requires its own lawful basis under Article 6. If users consented to Timeline functionality, that consent doesn't extend to advertising inference unless you specifically disclosed and obtained consent for that purpose at the point of collection.
The fix: Conduct a processing inventory that maps data sources to downstream uses. For each use, document your Article 6 lawful basis. If you're relying on consent (Article 6(1)(a)), verify that your consent mechanism was specific to that purpose. If you're relying on legitimate interests (Article 6(1)(f)), you need a documented legitimate interests assessment for each processing activity, not a blanket assessment for "product improvement." When in doubt, separate your lawful bases and your consent requests.
Mistake 3: Setting Retention Periods Based on Storage Capacity, Not Purpose
Why it happens: Your engineering team sets a default retention policy: "Keep activity logs for 18 months because that's our analytics window and storage is cheap." No one asks whether you actually need 18 months of data for each stated purpose. The policy gets applied uniformly across all data categories.
The consequence: The DPC found Google retained location information collected through Web & App Activity and Location History for longer than necessary. Article 5(1)(e) requires storage limitation: you must keep personal data only as long as necessary for the purposes for which it's processed. If you can deliver Timeline functionality with 90 days of location data but you're keeping three years, you're in violation.
The fix: Review retention periods by processing purpose, not by data category. Ask: "How long do we actually need this specific data element to fulfill this specific purpose?" Document the answer. If you need six months of location data for fraud detection but only 30 days for service delivery, set different retention periods for each processing activity. Implement automated deletion tied to these purpose-specific timelines. Your data retention schedule should be a matrix (data type × purpose × retention period), not a single number.
Mistake 4: Failing to Demonstrate Compliance for Features Without User Accounts
Why it happens: You process data through device-level features that don't require account login. You assume this is lower risk because users aren't authenticated. You don't maintain the same compliance documentation you keep for account-based features.
The consequence: The DPC found Google failed to demonstrate compliance with GDPR requirements for Location Accuracy, an Android feature that works regardless of whether users have a Google Account. Article 5(2)'s accountability principle requires you to demonstrate compliance with all processing principles. "We're not tracking individuals" isn't a defense if you're still processing personal data (and location data from an identifiable device is personal data under Article 4(1)).
The fix: Apply the same compliance rigor to device-level and anonymous-session processing as you do to authenticated user processing. Document your lawful basis, your transparency disclosures, your retention period, and your technical measures. If you're processing location data from Android devices, you need the same compliance evidence whether or not the user is logged into a Google Account. Your accountability documentation should cover every processing activity, not just the ones tied to user IDs.
Mistake 5: Assuming Lead Authority Review Means Automatic Approval
Why it happens: Your European headquarters are in Ireland, so the DPC is your lead supervisory authority under Article 56. You engage with the DPC on major processing questions. You interpret their feedback as approval and assume you're covered.
The consequence: Even with the DPC as lead authority, Google faced an own-volition inquiry launched in February 2020 after complaints from European consumer rights organizations. Lead authority status doesn't create a safe harbor. It determines which supervisory authority coordinates cross-border enforcement, but it doesn't prevent investigations or guarantee that your current practices will withstand scrutiny.
The fix: Treat supervisory authority engagement as consultation, not certification. Document your compliance decisions independently. If you receive feedback from your lead authority, implement it, but don't assume silence equals approval. Maintain your own compliance evidence: documented lawful bases, legitimate interests assessments, data protection impact assessments where required, and records of processing under Article 30. When the DPC (or any supervisory authority) opens an inquiry, your defense is your documentation, not your previous conversations.
Prevention Checklist
Before you launch or modify any feature that processes location, behavioral, or cross-service activity data:
- Map every data element to its specific processing purpose (no umbrella terms)
- Document your Article 6 lawful basis for each purpose separately
- Draft transparency disclosures that explain what you're actually doing (test with a non-expert reader)
- Set retention periods based on purpose necessity, not storage capacity
- Apply the same compliance standards to device-level and account-based processing
- Maintain accountability documentation (records of processing, DPIAs where required, legitimate interests assessments)
- Review consent mechanisms to ensure they're specific, informed, and freely given for each purpose
- Implement automated deletion tied to purpose-specific retention periods
- Schedule annual reviews of processing activities to verify continued compliance
The DPC gave Google six months to correct the infringements. You don't need to wait for an inquiry to start this work.
