Google's €403 million fine from Ireland's Data Protection Commission isn't just another regulatory headline. It's a detailed examination of how location data processing can fail, even at companies with significant compliance resources. The investigation covered practices from 2018 to February 2020 and found violations in Web & App Activity, Location History, and Android's Location Accuracy feature.
These weren't obscure technical violations. They were fundamental processing failures: unlawful basis, unfair treatment, and lack of transparency in how location data moved through Google's systems. If your team processes location data, these same mistakes might be lurking in your infrastructure.
Why These Mistakes Keep Happening
Location data is easy to collect, valuable for functions like mapping and recommendations, and legally sensitive because it can reveal private behavior patterns. This combination creates a compliance gap. Engineering teams often build features that use location data simply because it's available. Product teams might assume consent from one feature covers another. Legal reviews often occur after architecture decisions are locked in. By the time someone asks, "What's our lawful basis for this specific processing activity?", the answer is often, "We inherited it from the previous system."
The Irish regulator's finding that Google failed to process location data "lawfully or fairly" across multiple services suggests this pattern: feature development outpaced lawful basis documentation.
Mistake 1: Treating Location Data as a Single Category
Why it happens: Teams create one "location permissions" toggle, assuming it covers all location processing activities. The Android permission model encourages this: apps request location access once, then use it for multiple purposes.
The consequence: Each distinct purpose requires its own lawful basis under Article 6 GDPR. Web & App Activity, Location History, and Location Accuracy serve different functions. Collecting location for navigation doesn't authorize using it for ad targeting. The regulator found Google's processing unlawful because these distinctions weren't maintained.
The fix: Map every location data flow to a specific processing purpose and document the lawful basis for each. If you're processing location for fraud detection (legitimate interests), that doesn't cover using the same data for analytics (which likely needs consent). Your data flow inventory should show: collected element → processing activity → specific purpose → lawful basis → retention period. When those five elements don't align, you have an Article 6 violation waiting to happen.
Mistake 2: Relying on Inherited Consent
Why it happens: A user consented to location tracking in 2017 for Feature A. In 2019, you launch Feature B that also uses location data. The assumption is that existing consent covers the new use case because "they already gave us location access."
The consequence: Consent under Article 7 must be specific to each processing purpose. Historical policies that predated GDPR or assumed broad consent don't satisfy the specificity requirement. When Deputy Commissioner Graham Doyle noted that location data "can reveal a significant amount of information about an individual," he signaled that generic consent doesn't suffice for this data category.
The fix: Implement purpose-specific consent gates. When you add a new location-dependent feature, trigger a new consent request that explains exactly what this feature does with location data and how it differs from existing uses. Your consent records should timestamp each purpose separately. If you can't show when a user consented to a specific processing activity, you don't have valid consent for it.
Mistake 3: Conflating Transparency with Disclosure
Why it happens: Teams write a privacy policy that discloses location data collection, then assume they've met the transparency obligation. The policy mentions "we collect location data to improve services" in a lengthy document.
The consequence: The regulator found Google "failed to be lawful, fair and transparent" in processing location data. Transparency under Articles 13 and 14 isn't just about disclosure, it's about making processing practices genuinely understandable at the point of collection. Burying location processing details in a comprehensive privacy policy doesn't satisfy the fairness requirement when users encounter location requests in-app.
The fix: Provide just-in-time transparency at each collection point. When your app requests location access, the prompt should explain the specific use: "We'll use your current location to show nearby stores" or "We'll track your route to provide turn-by-turn directions." Your privacy policy provides comprehensive detail; your collection prompts provide contextual clarity. Both are required.
Mistake 4: Assuming Platform Permissions Equal Lawful Basis
Why it happens: Mobile operating systems require apps to request location permissions. When a user grants that permission, teams assume they've obtained lawful basis for processing. The OS permission dialog becomes a substitute for GDPR compliance.
The consequence: Platform permissions are access controls, not lawful basis. The fact that Android or iOS granted your app location access doesn't mean you have consent, legitimate interests, or any other Article 6 basis for a specific processing activity. The Irish investigation examined Location Accuracy in Android itself, finding that even platform-level location processing requires proper lawful basis.
The fix: Treat platform permissions as a prerequisite, not as compliance. Your compliance documentation should show: (1) platform permission granted, (2) lawful basis established for specific purpose, (3) user informed of that purpose, (4) processing limited to stated purpose. If you're processing location data in ways the OS permission dialog didn't describe, you're creating exposure.
Mistake 5: Letting Feature Teams Define Data Minimization
Why it happens: A product manager says "we need continuous location tracking to improve recommendations." Engineering implements it. No one asks whether periodic location checks or coarse location would serve the same purpose.
The consequence: Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary." When Graham Doyle noted that location data "can greatly enhance the utility of online services, but it can also reveal a significant amount of information," he was pointing to the minimization tension. Collecting more location data than necessary for a stated purpose violates the adequacy principle, even if users consented.
The fix: Require data minimization analysis before implementing location features. Document: What's the stated purpose? What's the minimum location precision needed (exact coordinates vs. city-level)? What's the minimum collection frequency (continuous vs. on-demand)? Can we achieve the purpose with derived data instead of raw location? If your documentation can't answer why you need the granularity you're collecting, you're probably over-collecting.
Mistake 6: Treating Historical Practices as Immutable
Why it happens: Your location data architecture was designed in 2016. GDPR took effect in 2018. Redesigning the system is expensive, so teams assume they can grandfather existing practices under "legitimate interests" or claim users implicitly consented by continuing to use the service.
The consequence: Google's statement that "this case centers around historical policies that have since been updated" and that they "significantly evolved practices from 2019 onwards" acknowledges this trap. The investigation covered 2018-2020 precisely because regulators don't accept grandfathering. Pre-GDPR architectures must be brought into compliance, not justified as legacy systems.
The fix: Schedule compliance reviews of location data processing every 12 months. Document: What processing activities existed before GDPR? What lawful basis do we claim now? Where does current processing exceed what we've documented? What architectural changes would close the gap? If you're still processing location data the same way you did in 2017, you're carrying compliance debt that will eventually come due.
Prevention Checklist
Before implementing or modifying location data processing:
- Document the specific purpose for this processing activity (not "improve services")
- Identify the Article 6 lawful basis that applies to this specific purpose
- Confirm platform permissions describe the actual processing, not generic location access
- Verify that location precision and collection frequency match documented necessity
- Implement just-in-time transparency at the collection point
- Create purpose-specific consent records if relying on Article 6(1)(a)
- Map location data flows from collection through retention to deletion
- Separate consent for each distinct processing purpose
- Schedule annual reviews of location processing practices against current Technical and Organisational Measures
- Document why historical processing practices have been updated or why they remain compliant
The Irish Data Protection Commission has three ongoing investigations involving Google. Location data processing remains under regulatory scrutiny because it's both valuable and revealing. Your compliance approach should assume that every location data flow will eventually face the same examination Google just received.
