When the Irish Data Protection Commission fined Google €403 million for location data practices from 2018 to February 2020, compliance teams across the tech sector saw more than just a headline. They recognized potential gaps in their own programs.
These myths persist because location data is technically complex, legally nuanced, and commercially valuable. Your legal team might assume engineering handles consent flows. Engineering might think product manages user communication. Product might believe legal signed off on the retention schedule. Meanwhile, no one owns the end-to-end accountability chain the General Data Protection Regulation (GDPR) actually requires.
Let's dismantle the most dangerous misconceptions.
Myth 1: Transparency Means Publishing a Privacy Policy
Reality: Article 5(1)(a) requires processing to be "lawful, fair, and transparent." The Irish DPC's finding against Google focused on this triad, not just policy disclosure.
Transparency under the GDPR means users understand what's happening with their data at the moment of collection and throughout processing. Google's Web & App Activity and Location History features failed this standard because users "could have been unaware that their location was being used to, for example, influence them with ads or to infer their interests," according to Deputy Commissioner Graham Doyle.
Your privacy notice might be comprehensive, but if it's disconnected from the user experience where data collection occurs, you're not meeting the standard. Transparency requires contextual, just-in-time communication that connects the data you're collecting to the specific purposes you're using it for.
Operationally, your product team can't ship a location-dependent feature without integrated, purpose-specific disclosure at the point of data capture. Your consent management workflow must tie specific processing activities to specific legal bases, documented in your Records of Processing Activities under Article 30.
Myth 2: Consent Covers Everything Once You Have It
Reality: The lawfulness and fairness requirements operate independently of your consent mechanism.
Even when users technically consented to Google's location features, the commission found violations because the processing didn't align with users' "reasonable expectations" and because Google retained location data "longer than necessary."
You can have valid consent under Article 7 and still violate Article 5's fairness principle if your actual data use diverges from what users reasonably anticipated when they clicked "agree." This is why your Data Protection Impact Assessments under Article 35 must map not just legal bases, but user expectations against actual processing activities.
For location data specifically, if you're collecting precise GPS coordinates but users think you're only tracking city-level information for service delivery, that expectation gap creates compliance risk regardless of your consent record. If you're retaining historical location trails to train recommendation algorithms but users believe you're only storing recent data for navigation, you've got a fairness problem.
Myth 3: Platform Features Are Separate Compliance Domains
Reality: The Irish DPC assessed three Google services together because they formed an interconnected data processing ecosystem.
Web & App Activity, Location History, and the Android Location Accuracy feature were evaluated as a system, not isolated products. This matters because your compliance program probably mirrors your org chart: the team managing your mobile SDK doesn't coordinate retention policies with the team running your web analytics platform.
The GDPR doesn't recognize those internal boundaries. Article 5(2) puts accountability on you as the controller to "demonstrate compliance" across all processing activities involving the same categories of personal data.
Practically, your Records of Processing Activities must show how location data flows between systems, who has access at each stage, what retention periods apply to each processing purpose, and how you're enforcing Data Minimisation across the entire chain. When auditors or regulators examine your location data practices, they'll follow the data across product lines, not respect your team structure.
Myth 4: Technical Controls Equal Accountability
Reality: Article 5(2)'s accountability obligation requires documented governance, not just security measures.
Google's violation included failing to meet "accountability obligations" for Location Accuracy. Accountability under the GDPR means you can demonstrate that you've implemented appropriate technical and organizational measures, that you've assessed risks, and that you've embedded data protection into your processing operations.
Your encryption, access controls, and Data Minimisation techniques are necessary but insufficient. You also need documented decisions: why did you choose a 90-day retention period instead of 30 days? How did you determine that city-level location serves your legitimate interest while precise coordinates don't? What alternative processing methods did you evaluate?
This documentation proves to regulators that you're making deliberate, risk-informed choices rather than defaulting to "collect everything, keep it forever." Your Statement of Applicability in an ISO/IEC 27001 program or your system security plan under NIST SP 800-53 can support this, but they must explicitly address GDPR accountability requirements, not just information security.
Myth 5: Fixing Historical Practices Resolves Compliance Risk
Reality: The investigation covered practices from May 2018 to February 2020, but the penalty arrived in 2026.
Google told regulators it had "significantly evolved" its practices since 2019, implementing auto-deletion, not saving precise locations in Web & App Activity, and consolidating location information. The commission still issued the penalty and ordered compliance within six months.
Legacy processing creates ongoing exposure. Your current privacy-by-design practices don't retroactively fix data you've already collected under insufficient legal bases or retained beyond necessity. You're carrying compliance debt that supervisory authorities can and will assess years after the processing occurred.
For your program, conduct a historical data audit. Identify datasets collected under pre-GDPR practices or early implementations that wouldn't meet your current standards. You need documented decisions on whether to delete, anonymize, or obtain fresh consent for continued processing. Your Data Protection Officer should maintain a register of these legacy risks with remediation timelines.
What to Do Instead
Build accountability into your data governance operating model. Assign a single executive owner for each category of personal data you process. For location data, that owner must coordinate across product, engineering, legal, and data science to maintain a unified view of collection points, processing purposes, retention schedules, and user communications.
Implement purpose limitation rigorously. Every location data point you collect must tie to a documented, specific purpose with a defined retention period. When product teams propose new uses for existing location data, treat it as new processing requiring legal basis assessment and, often, fresh consent.
Audit your transparency mechanisms quarterly. Don't just review your privacy policy. Walk through every user touchpoint where you collect location data and verify that the contextual disclosure accurately describes what you're doing with that data and why. If your ads team started using location for audience segmentation since your last review, your disclosure must reflect that.
Document everything. Your Records of Processing Activities, Data Protection Impact Assessments, and vendor due diligence files aren't bureaucratic exercises. They're your evidence when a supervisory authority asks you to demonstrate compliance with Article 5(2). If you can't produce a documented risk assessment explaining why you retain location data for 18 months, you can't meet your accountability obligation.
The Irish DPC gave Google six months to bring its processing into compliance. Your supervisory authority won't be more generous. The question isn't whether your location data practices will face scrutiny, but whether you can demonstrate lawfulness, fairness, transparency, and accountability when they do.
