Ireland's Data Protection Commission recently fined Google €403 million for GDPR violations related to location data processing. The investigation focused on Web and App Activity, Location History, and Location Accuracy. Each feature had different permission models, retention schedules, and transparency mechanisms, and each failed in its own way.
This isn't just a Google problem. If your team processes location data at scale, you're facing a similar choice: centralize control over location permissions and retention, or distribute control across product teams and features. The Google case underscores why this decision is crucial and which path aligns with your compliance needs.
The Decision You're Facing
Your organization collects location data through various channels: mobile apps, web services, analytics platforms, and advertising systems. Each team wants autonomy to optimize its feature, with different retention needs. You need to decide:
Centralized governance: One policy framework, one retention schedule, one consent mechanism for all location data processing.
Distributed governance: Feature-specific policies, differentiated retention periods, and separate consent flows tailored to each use case.
Hybrid model: Centralized policy with distributed implementation authority and local opt-in mechanisms.
The wrong choice doesn't just create compliance risk. It leads to operational friction, user confusion, and audit complexity that compounds over time.
Key Factors That Affect Your Choice
Regulatory jurisdiction scope: If you operate primarily under GDPR Article 6(1)(a) (consent-based processing), you'll need granular, feature-specific consent mechanisms. If relying on Article 6(1)(f) (legitimate interest), centralized policies may suffice, but you'll need stronger transparency documentation.
Data retention variability: The DPC found Google retained location data "longer than necessary" through Web & App Activity and Location History. If your features have different retention needs (e.g., fraud detection requires 90 days; navigation optimization needs 24 hours), distributed control allows proportionate retention. If retention needs are similar across features, centralization reduces the risk of violations.
User awareness requirements: GDPR Articles 13 and 14 require specific, accessible information about data processing. If users interact with location features in distinct contexts (in-app navigation vs. background analytics), distributed consent flows provide clarity. If location processing is invisible across services, you're creating the "loss of control" the DPC cited in Google's case.
Cross-functional data sharing: Do product teams share location data with advertising, analytics, or third-party services? Centralized governance simplifies data flow mapping. Distributed models require rigorous data processing agreements between internal teams, documented under Article 28.
Audit and documentation burden: You'll need to demonstrate compliance for every processing activity. Centralized policies mean one Statement of Applicability (SoA), one data flow diagram, and one retention schedule to defend. Distributed models multiply your documentation requirements by the number of features.
Path A: Centralized Governance (When to Choose This)
Choose centralized governance if:
You process location data primarily for back-end optimization: If users don't interact directly with location features but you use coordinates for service improvement, fraud detection, or infrastructure planning, a single consent mechanism and retention policy reduces complexity.
Your regulatory risk tolerance is low: If you're in a high-scrutiny sector (finance, healthcare, critical infrastructure under NIS2 Directive), centralized control provides defensible consistency.
You lack mature product governance: If your engineering teams don't have embedded privacy expertise or formal data protection impact assessment processes, centralization prevents drift.
Implementation approach: Establish a single location data policy that applies across all features. Define retention as the longest period required by any legitimate use case, but implement automated deletion at that boundary. Create one consent flow that explains all location processing up front. Document every downstream use in your Article 30 register.
Trade-off: You'll over-collect consent for features users don't use, creating unnecessary friction. Your retention period will be longer than some features require, expanding your data inventory. But you'll have one compliance story to tell regulators.
Path B: Distributed Governance (When to Choose This)
Choose distributed governance if:
Location features serve distinct user-facing purposes: If you operate like Google did, with navigation services, ad personalization, and device accuracy improvements as separate value propositions, users need granular control.
You can enforce strong privacy engineering standards: Distributed models only work if every product team can implement GDPR-compliant consent flows, retention automation, and documentation.
Feature-level retention optimization matters: If precise retention boundaries significantly reduce your risk exposure, distributed control lets each feature minimize its footprint.
You operate across multiple jurisdictions with varying requirements: If some features target California users (CCPA/CPRA), others target EU users (GDPR), and others serve federal contractors (NIST SP 800-171), distributed policies let you tailor compliance per feature.
Implementation approach: Treat each location-processing feature as a separate processing activity under Article 30. Conduct individual data protection impact assessments. Implement feature-specific consent mechanisms with clear explanations of purpose, retention, and data sharing. Automate retention at the shortest defensible period for each use case.
Trade-off: You'll create user confusion if consent flows proliferate. Your documentation burden multiplies. You need strong internal data processing agreements and regular cross-team audits to prevent policy drift. But you'll minimize data collection and retention, reducing both regulatory exposure and breach impact.
Path C: Hybrid Model (When to Choose This)
Choose a hybrid approach if:
You have a small number of high-risk features and many low-risk uses: Separate out features that involve sensitive inferences or long retention periods, and give them dedicated consent flows. Consolidate routine operational uses under a central policy.
You're transitioning from centralized to distributed governance: Start with a single policy, then carve out exceptions as product teams build privacy engineering capability.
Your organization has federated compliance responsibility: If business units operate semi-autonomously but share infrastructure, hybrid governance lets each unit manage its own location features while corporate sets baseline standards.
Implementation approach: Define a default location data policy that covers routine operational processing. Require separate consent flows and documentation only for features that exceed baseline retention periods, share data with third parties, or enable sensitive inferences. Create a governance framework that specifies when features must "graduate" to distributed control.
Summary Matrix
| Factor | Centralized | Distributed | Hybrid |
|---|---|---|---|
| Consent complexity | Single flow | Multiple flows per feature | Baseline + exceptions |
| Retention period | Longest needed across all uses | Optimized per feature | Default + extended for specific uses |
| Documentation burden | One Article 30 entry | Multiple entries per feature | Baseline + high-risk supplements |
| User transparency | Generic, covers all uses | Feature-specific, detailed | Default disclosure + detailed for sensitive features |
| Regulatory defensibility | Strong if retention is short | Strong if properly documented | Moderate, depends on exception management |
| Engineering complexity | Low | High (requires distributed capability) | Moderate |
| Best for | Low-risk operational uses | User-facing features with distinct purposes | Organizations building privacy maturity |
The Google fine shows what happens when you distribute location processing across features without distributing accountability for transparency and retention. If you choose Path B or C, every product team needs the capability to implement GDPR principles independently. If they don't have that capability yet, Path A protects you while you build it.
Your choice isn't permanent. Google's response to the DPC investigation shows evolution: they've added centralized deletion controls while moving Maps Timeline storage to devices. Start with the governance model that matches your current privacy engineering maturity, then migrate as your capabilities grow. Just don't let features proliferate under the assumption that someone else owns the compliance obligation.
