The Question at Hand
Your organization wants to deliver location-aware features. Marketing wants proximity targeting. Product wants personalized experiences. Engineering says the architecture's ready. The question lands on your desk: can you process location data by default and let users opt out later?
The Irish Data Protection Commission's 403 million EUR fine against Google Ireland Limited, following an inquiry into location data processing between May 2018 and February 2020, highlights this issue. The DPC found violations in lawfulness, fairness, accountability, and transparency in Google's Web & App Activity, Location History, and Location Accuracy features. But this isn't just about Google. Every team handling location data must decide: does your service architecture assume consent, or does it require it upfront?
The Case for Opt-Out Processing
Some argue that opt-out models enhance user experience. Location services improve as the system learns patterns. If you require explicit consent before processing, users can't experience the feature's value. They're deciding on a feature they haven't tried.
This perspective cites legitimate interest as a legal basis for processing under GDPR Article 6(1)(f). If your location processing genuinely improves service delivery, is expected in context, and offers clear opt-out mechanisms, you might meet the three-part test: legitimate interest exists, processing is necessary, and user interests don't override yours.
Engineering supports this view. Modern applications often bundle location processing with core functionality. Separating "location for navigation" from "location for analytics" from "location for personalization" complicates architecture. A unified opt-out approach simplifies implementation and reduces consent-state mismatches.
There's also the retention argument. Collecting location data only after explicit consent means you can't provide historical insights when users enable features later. The opt-out model lets you build a complete dataset, then apply restrictions if users object. This approach can deliver better outcomes from a product perspective.
The Case for Consent-First Processing
The opposing view treats location data as categorically different. It's continuously generated, highly revealing, and often unnecessary for core service delivery. Processing location data without prior consent can violate the fairness principle in GDPR Article 5(1)(a), regardless of your legal basis.
This view is supported by the ePrivacy Regulation rules on terminal equipment access. Storing or accessing information on a user's device requires prior consent, with exceptions for transmission or strictly necessary functions. Location data rarely qualifies as strictly necessary. Reading location from the device without consent likely violates ePrivacy, even if you've constructed a legitimate interest argument under GDPR.
The transparency violations in the DPC's decision highlight this risk. Google couldn't demonstrate compliance with transparency obligations across all three features examined. Processing first and explaining later builds a transparency debt. Users discover location tracking through privacy settings or data access requests, not clear disclosure at collection.
Accountability failures are equally significant. The DPC found Google couldn't demonstrate compliance with lawfulness, fairness, and transparency principles for Location Accuracy. When you process by default, you must document why each processing activity meets GDPR's requirements. This documentation burden is substantial and often underestimated until a supervisory authority inquiry arrives.
Where Practitioners Actually Land
In practice, most organizations balance based on processing purpose. Essential location features (navigation, local search results, fraud detection) often run on legitimate interest with prominent disclosure and easy opt-out. Non-essential features (Behavioural Advertising, cross-context profiling, analytics not directly serving the user) require prior consent.
The dividing line isn't always clear. Consider a weather app showing local forecasts. Processing coarse location for the forecast might qualify as legitimate interest. Processing precise location to build movement patterns for third-party data brokers doesn't. The same data source, different purposes, different legal bases.
Teams that handle this well maintain purpose-specific processing records. They document why each location feature requires the data it collects, how long retention serves that purpose, and what user controls exist. When the DPC or another supervisory authority launches an inquiry, you need to demonstrate compliance, not construct an argument retroactively.
The Google decision shows that supervisory authorities expect this documentation to exist before processing begins. The six-month compliance order suggests the DPC found systemic gaps, not minor configuration issues. Bringing processing into compliance isn't a quick fix when your architecture assumes data availability.
Our Take
Process location data on a consent-first basis unless you can document a genuine legitimate interest that survives the three-part test and the fairness assessment. The risk calculus has shifted. A 403 million EUR fine isn't an outlier; it's a signal of enforcement priorities.
If you're relying on legitimate interest, document it now. Specify the interest, explain why processing is necessary to achieve it, and record your balancing test showing user interests don't override yours. Update that documentation when features change or new purposes emerge. The DPC's accountability finding shows that "we thought it was obvious" doesn't satisfy Article 5(2).
For non-essential location processing, the consent requirement is clearer. Behavioural Advertising, cross-context profiling, and analytics that serve your business rather than the user need prior consent. Configure your systems to withhold location data until you receive a clear affirmative action. Don't rely on pre-ticked boxes, bundled consent, or continued use as implied agreement.
The tradeoff is real. Consent-first architecture limits your initial dataset and complicates feature rollout. You'll need separate code paths for consented and non-consented states. Some users will never enable location features because they don't understand the value before experiencing it. But that product friction is manageable. A supervisory authority inquiry that finds systemic transparency and accountability failures isn't.
The Google case won't be the last. Location data processing is under active regulatory scrutiny across EU member states. Build your compliance framework assuming you'll need to demonstrate it under examination, because you probably will.
