The Irish Data Protection Commission's €403 million fine against Google for unlawful location data processing isn't just another headline. It's a technical blueprint of what breaks when transparency obligations, lawful basis requirements, and accountability measures fail at scale. The investigation covered practices from GDPR's inception through February 2020, examining three specific services: Web & App Activity, Location History, and Location Accuracy. Your organization processes location data differently than Google, but the compliance principles are identical.
Why This Matters Now
Location data intersects with Articles 5, 6, and 13 of the GDPR. It reveals patterns about where people live, work, worship, and seek medical care. The Irish DPC found Google failed in lawfulness and fairness of processing (Article 5(1)(a)), accountability (Article 5(2)), and transparency (Articles 13-14). These aren't abstract violations. They mean users couldn't understand what data was collected, how long it was kept, or how it influenced outcomes like ad targeting.
Your team faces similar exposure if you're processing location data through mobile apps, employee tracking systems, fleet management, or analytics platforms. The six-month compliance deadline Google received applies to any controller the supervisory authority finds in breach.
Preparing for Compliance
Before making any changes, gather these materials:
Documentation Audit
- Current privacy notices for every service handling location data
- Consent flows (screenshots and code) for location permissions
- Data retention schedules showing location data lifecycles
- Records of processing activities (Article 30) entries covering location processing
- Any legitimate interests assessments if you're not relying on consent
Technical Inventory
- List of systems collecting precise vs. approximate location (GPS coordinates vs. city-level)
- Mobile SDKs and their location permission requests
- Backend services storing location timestamps
- Analytics platforms receiving location parameters
- Third-party processors with location data access
Legal Clarity
- Confirmed lawful basis for each location processing purpose (you can't use "legitimate interests" for one purpose and consent for another within the same data stream without clear separation)
- Defined retention periods with documented justification
- Data protection impact assessment if your processing is likely high-risk
You'll need write access to privacy notice content management, mobile app codebases, backend configuration, and analytics platform settings. Budget three weeks for a mid-sized implementation if you're starting from non-compliance.
Step-by-Step Implementation
Week 1: Transparency Layer
Start with Article 13 obligations. Users must understand location processing before it happens, not buried in a policy they'll never read.
Draft service-specific notices. Don't write one generic privacy policy covering all location uses. The Irish DPC found Google's approach insufficient because users couldn't distinguish between Web & App Activity's location tracking and Location History's mapping feature. Create separate, concise explanations for each distinct purpose.
Your notice must specify:
- What location data you collect (precise coordinates, cell tower triangulation, IP geolocation)
- Why you're collecting it (the specific purpose, not "to improve services")
- Your lawful basis (probably consent under Article 6(1)(a) for most location processing)
- How long you'll keep it (specific periods, not "as long as necessary")
- Who else receives it (named processors or categories if processors aren't yet determined)
Place these notices at the point of collection. If you're requesting Android location permissions, show your explanation in the permission dialog flow, not three clicks away in settings.
Week 2: Consent and Control Mechanisms
Implement granular consent for each location processing purpose. If you're using location for delivery tracking and personalized recommendations, those require separate consent requests. Users must be able to accept one and decline the other.
Build these controls:
- Per-purpose toggles in account settings
- Withdrawal mechanism that stops processing within 24 hours
- Confirmation that withdrawal doesn't require account deletion
- Clear labels (the Irish DPC criticized Google's "Location Accuracy" label as insufficiently transparent about what the feature actually did)
For mobile apps, separate your permission request from your consent request. Android and iOS location permissions are technical gates. GDPR consent is the lawful basis. You need both, and they're not interchangeable. Request system permission, then immediately explain what you'll do with that access and ask for GDPR consent.
Week 3: Retention and Accountability
Configure automatic deletion. The Irish DPC found Google retained location data longer than necessary. Define your retention period based on the purpose. If you're using location for delivery, you don't need coordinates after the delivery is confirmed and any dispute period expires.
Set these policies:
- Automated deletion jobs running monthly
- Retention periods documented in your Article 30 records
- Aggregation rules (if you need historical patterns, aggregate and anonymize, then delete the precise data)
Build accountability documentation:
- Decision log explaining why you chose your retention periods
- Technical specification showing how auto-deletion works
- Test results proving deletion actually runs
- Processor agreements (Article 28) requiring your vendors to follow the same retention limits
Implement monitoring. Create alerts for:
- Location data older than your retention period
- Consent withdrawal requests not processed within 24 hours
- New location data collection points added without privacy notice updates
Validation - How to Verify It Works
Run these checks before considering yourself compliant:
User Journey Testing Walk through your app as a new user. Can you understand what location data you're sharing before you share it? Can you find the controls to withdraw consent? Time how long it takes to locate the privacy information. If it's more than two taps from the location permission request, you're failing transparency obligations.
Technical Verification
- Query your database for location records older than your retention period (there should be none)
- Disable a location processing purpose in settings, then verify the backend stops receiving those coordinates
- Check your processor contracts for location data handling requirements
- Review analytics dashboards to confirm you're not inferring sensitive information from location patterns without appropriate lawful basis
Documentation Review
- Compare your privacy notices against Articles 13 and 14 checklists (supervisory authorities publish these)
- Verify your records of processing activities include all location processing purposes
- Confirm your data protection impact assessment covers location tracking risks
- Check that your legitimate interests assessment (if applicable) includes the legitimate interests assessment
Create a test account, enable location features, wait 48 hours, then submit a DSAR requesting all location data. The response should match what your privacy notice promised you're collecting.
Ongoing Maintenance
Schedule these recurring activities:
Monthly
- Review deletion job logs to confirm automated retention is working
- Check for new third-party SDKs or services added to your stack that might access location
- Monitor consent withdrawal volume (sudden spikes indicate user confusion about what they consented to)
Quarterly
- Update privacy notices if you've added location processing purposes
- Re-test the user consent journey on new OS versions (iOS and Android permission models change)
- Review processor audit reports for location data handling
Annually
- Reassess your retention periods against actual business need
- Update your data protection impact assessment with new processing activities
- Train product teams on location data compliance requirements before they ship new features
The Irish DPC's decision makes clear that post-collection fixes don't satisfy GDPR. Google claimed it had "significantly evolved" its practices since 2019, but that didn't prevent the penalty for the historical violations. Your compliance work must happen before you process the first location coordinate, not after a supervisory authority opens an inquiry.
When your product team proposes a feature requiring location access, your first question isn't "can we build it?" It's "can we explain it clearly enough that users genuinely understand what they're agreeing to?" If the answer is no, the feature needs redesign, not a longer privacy policy.
