Google Ireland Limited just paid 403 million EUR to answer that question. The Irish Data Protection Commission's decision following its inquiry into Google's location data processing between 25 May 2018 and 4 February 2020 didn't just penalize past violations. It revealed where organizations often fail when designing consent mechanisms for location services.
You're facing this decision right now: how do you design location data processing that satisfies Articles 5, 6, and 30 without compromising user experience or operational workflows? The wrong choice doesn't just risk fines. It creates technical debt that compounds with every product update.
The Decision You're Facing
Your organization processes location data through mechanisms like explicit location features (such as Google's "Location History"), background collection tied to other services (like "Web & App Activity"), or system-level accuracy settings (like "Location Accuracy"). Each mechanism requires different legal bases, transparency disclosures, and retention schedules.
The Irish DPC's findings identified failures in lawfulness, fairness, transparency, accountability, and retention. Your decision tree must address all five simultaneously.
Key Factors That Affect Your Choice
Processing Purpose Clarity: Can you clearly articulate why you need location data for each feature? The DPC found Google couldn't demonstrate lawfulness and fairness for Web & App Activity and Location History. If your purpose statement reads "to improve services," it's not defined enough.
User Control Granularity: Do users control each location processing activity independently, or are controls bundled? Bundling location collection with unrelated service improvements violates fairness under Article 5(1)(a).
Documentation Completeness: Can you demonstrate compliance with Article 5(2)'s accountability principle? The Irish DPC cited Google's failure to demonstrate compliance for Location Accuracy. Your Records of Processing Activities under Article 30 must prove lawfulness, not just assert it.
Transparency Mechanism Design: Are your disclosures visible at the point of data collection, or buried in privacy policies? The DPC found transparency violations across all three Google features examined. Article 13 requires information "at the time when personal data are obtained."
Retention Justification: Can you defend why location data from 18 months ago remains necessary for your stated purpose? The Irish DPC found retention violations in Web & App Activity and Location History. Article 5(1)(e) demands you limit retention to what's necessary.
Path A: Explicit Location Features With Standalone Legal Basis
Choose this path when location data is the core product feature, mapping services, location sharing, geofenced alerts.
When to choose this: Your service cannot function without location data. Users expect location processing. The feature provides direct, immediate value tied to real-time or historical location.
Requirements that drive this path:
- Article 6(1)(a) consent as your legal basis (or 6(1)(b) if location is necessary for contract performance)
- Separate, specific consent requests, not pre-ticked boxes bundled with account creation
- Granular controls that let users enable/disable this feature independently
- Transparency disclosures at the point users activate the feature, explaining what location data you'll collect, why, and for how long
- Retention schedules tied to feature utility, if historical location isn't necessary after 90 days, delete it at 90 days
Implementation specifics: Your Article 30 Record of Processing Activities must document the legal basis, purpose limitation, and retention schedule for this feature. When users disable the feature, you must stop collection immediately and delete data according to your stated schedule. Your privacy notice must explain this feature separately from other processing activities.
Path B: Background Location Collection for Service Improvement
Choose this path when location data enhances features but isn't the primary service, fraud detection, content personalization, analytics.
When to choose this: Location data improves accuracy, security, or user experience for non-location services. Users don't expect location processing as the core function. The benefit is indirect or aggregate.
Requirements that drive this path:
- Article 6(1)(f) legitimate interests as your legal basis (with mandatory balancing test documentation)
- Transparency disclosures that explain the indirect benefit clearly, "We use approximate location to detect unusual login patterns" passes; "to improve your experience" fails
- Opt-out mechanisms that don't disable core service functionality
- Data Minimisation (Article 5(1)(c)) applied aggressively, collect city-level, not GPS coordinates, if city-level suffices
- Retention limits that reflect the analytical window, if you analyze login patterns over 30 days, delete location data after 30 days
Implementation specifics: Your Article 30 Record must include your legitimate interests assessment, documenting why location processing is necessary, what user interests you've balanced, and what safeguards you've implemented. Update it when processing purposes change.
Path C: System-Level Location Settings That Enable Multiple Features
Choose this path when location accuracy settings affect multiple services simultaneously, OS-level permissions, device configuration, infrastructure optimization.
When to choose this: You're a platform provider where a single location setting enables multiple downstream uses. Different features controlled by the same setting have different legal bases. Users configure location at the system level, not per-feature.
Requirements that drive this path:
- Article 5(2) accountability obligations demand you document the legal basis for each downstream use, even if users control them through a single setting
- Transparency requirements compound, you must explain every processing activity this setting enables, not just the setting itself
- You need layered transparency: summary at the setting level, detailed disclosures for each enabled feature
- Retention schedules must apply to each downstream use independently
Implementation specifics: Your Article 30 Record becomes a matrix, one setting, multiple processing activities, each with its own legal basis, purpose, and retention schedule. When users disable the system setting, you must stop all processing activities it controlled and apply each activity's retention schedule independently.
Summary Matrix
| Factor | Path A: Explicit Features | Path B: Background Collection | Path C: System-Level Settings |
|---|---|---|---|
| Legal Basis | Article 6(1)(a) consent or 6(1)(b) contract | Article 6(1)(f) legitimate interests | Multiple bases documented separately |
| User Expectation | Location is the product | Location enhances other features | One setting controls multiple uses |
| Transparency Trigger | Feature activation | Service registration + ongoing notice | System configuration + per-feature disclosure |
| Data Minimisation | Collect what feature requires | Collect minimum for improvement goal | Apply separately to each enabled use |
| Retention Driver | Feature utility window | Analytical necessity period | Shortest necessary across all uses |
| Accountability Evidence | Article 30 Record for feature | Legitimate interests assessment | Matrix of legal bases per use |
| Irish DPC Risk Area | Fairness if bundled with unrelated processing | Lawfulness if purpose unclear | Accountability if downstream uses undocumented |
The 403 million EUR fine and the six-month compliance order Google received reflect failures across all three paths. Your decision isn't just which path to choose, it's whether you can demonstrate compliance for the path you've chosen. The Irish DPC didn't penalize Google for collecting location data. It penalized Google for failing to prove lawfulness, fairness, and transparency.
Document your choice. Then document why it satisfies Articles 5, 6, 13, and 30. That documentation is your defense when your supervisory authority asks the same questions the Irish DPC asked Google.
