Source: Data Protection Commission, 21 September 2026

Source: Data Protection Commission, 21 September 2026

Assessed from the DPC’s per-feature findings, 21 September 2026

Source: Data Protection Commission via The Irish Times, 21 September 2026

Source: BEUC, 27 November 2018 — complainant allegation, unconfirmed against the decision

Retention periods defined as policy but not enforced as an expiry anywhere in the storage path, so “longer than necessary” was the default outcome rather than an exception.

No demonstrable lawful-basis record bound to each processing purpose, leaving accountability unprovable years after the processing had stopped.

Multiple features collecting overlapping location data through separate, un-reconciled collection paths, with no single instrumented inventory of where location entered the estate.

Location data and inferred interests flowing onward into advertising and analytics processing without purpose limitation enforced at the point of transfer.

Users unable to understand from the notice what was collected, or that it would be used to infer their interests — so any consent rested on an invalid basis.

GDPR Art. 5(1)(e) — storage limitation; ISO/IEC 27001:2022 Annex A 8.10 — information deletion

Set the retention ceiling where the data physically lives: object-lifecycle expiration on every bucket holding location events (S3 Lifecycle Expiration, GCS Object Lifecycle Delete-by-age, Azure Blob lifecycle delete action), partition expiry in the warehouse (partition_expiration_days on BigQuery tables, DATA_RETENTION_TIME_IN_DAYS on Snowflake), and a finite retention.ms on every Kafka topic carrying coordinates — never the broker default. Retain the deletion job’s output as the audit artefact: a retention control that leaves no evidence of having run cannot discharge Art. 5(2).

GDPR Art. 5(2) and Art. 6(1); NIST SP 800-53 Rev. 5 PT-2 — authority to process PII; PT-3 — PII processing purposes

Carry purpose and lawful_basis as mandatory column-level tags in the data catalogue, and fail the build in CI when a job reads a column whose declared purposes do not include that job’s own purpose. A lawful-basis register maintained as a spreadsheet drifts from the estate within one quarter; one that gates deployment cannot. Version the register in the same repository as the schema, so the basis and the field change in a single reviewable commit.

GDPR Art. 25(2) — data protection by default; CIS Controls v8.1 Safeguards 3.1 and 3.2 — data management process and data inventory (Implementation Group 1)

Treat location permissions as a release gate rather than a code-review preference: block ACCESS_FINE_LOCATION and ACCESS_BACKGROUND_LOCATION on Android, and NSLocationAlwaysAndWhenInUseUsageDescription on iOS, unless the manifest diff carries a named purpose and a named approver. Maintain an SDK allowlist in the build and diff the application’s outbound hosts every release — a third-party SDK added for analytics is a new collection path whether or not anyone recorded it as one.

GDPR Art. 5(1)(b) — purpose limitation; Art. 28(3) — processor instructions; ISO/IEC 27701:2019 — PIMS controller controls

Evaluate consent state at SDK initialisation so that a refusal means the location API is never called, rather than the event being discarded after collection — in tag-managed stacks, ad_storage, ad_user_data and ad_personalization default to denied before any tag fires. Write a named retention ceiling and an audit right into every processor agreement, then verify it by requesting the processor’s deletion log rather than its retention policy.

GDPR Art. 12(1) — transparent information; Art. 13(1)(c) — purposes of processing

The notice and the catalogue should be one artefact rendered twice, so a new purpose cannot reach production without appearing in the notice. State inference explicitly — that location is used to derive interests and to target advertising — because the DPC’s finding was that users did not understand this, not that it was wholly undisclosed. Deliver the user-facing rules in 5B below as a standing briefing to product, marketing and engineering.

Audience: the people whose everyday decisions create the collection paths — no technical knowledge assumed.

↳ CF-5   GDPR Art. 5(1)(a) and 5(1)(e) — lawfulness, fairness, transparency and storage limitation; ISO/IEC 27001:2022 Annex A 6.3 — information security awareness, education and training.

1.  Write down why you are collecting it, before you collect it.

If you cannot say in one sentence what a piece of data is for, you do not have a reason to collect it — you have a hope that it will be useful later. That hope is not a legal basis. A regulator may ask you for that sentence years after you have forgotten the feature existed.

2.  Ask for an end date, not just a start date.

Every request to collect something new should arrive with the date it gets deleted. If the answer is “keep it forever,” the answer is wrong. Put the deletion date in the ticket, the same way you would put in a launch date.

3.  Say what you actually do with it, in words a customer would use.

“We use your location to work out what you are interested in and to choose which ads you see” is a sentence a person can understand and disagree with. “We process location data to improve and personalise your experience” is not. The second one is the kind that gets fined.

4.  Treat a new tool as a new collection of data.

Adding an analytics or advertising tool to the app or the website starts a new flow of personal data out of the building, even though it feels like a small configuration change. Tell whoever keeps the data inventory before it goes live, not afterwards.

5.  One switch should govern everything it appears to govern.

If someone turns location off in one place and it carries on being collected somewhere else under a different name, they have been misled — whatever the settings page says. Check what your own switches actually do, using a test account, at least once every release cycle.

Articles 5, 6, 12 and 13 (infringements found); Art. 5(1)(a), 5(1)(e), 5(2), 6(1), 12(1), 13(1)(c) (SEG mapping); Art. 83(2) (penalty criteria)

The EDPB records infringements of Articles 5, 6, 12 and 13 (European Data Protection Board, 21 September 2026). The paragraph-level mapping — fairness and lawfulness at Art. 5(1)(a), storage limitation at Art. 5(1)(e), accountability at Art. 5(2), lawful basis at Art. 6(1), transparency at Arts. 12(1) and 13(1)(c) — is SEG’s reading of the DPC’s described findings, not text quoted from the decision. [UNRESOLVED] Paragraph-level attribution requires the full decision, which was not published alongside the announcement.

Article 25(1)–(2) — data protection by design and by default; Article 28(3) — processor instructions

Not findings in this decision. They are the provisions under which the same facts are assessed prospectively, and the ones a remediation plan is written against. Cited here as forward obligations, never as adjudicated failures.

Article 5(3) — access to information stored in terminal equipment; Article 9 — location data

Intersection to flag. Location Accuracy derives position from device-level scanning of nearby networks. Where an EU establishment accesses information stored on terminal equipment, Art. 5(3) consent applies independently of the GDPR lawful basis, and Art. 9 governs location data in electronic communications. This decision is a GDPR decision; the ePrivacy layer is a separate obligation on the same collection path, and it is routinely missed.

PIMS controller controls; ISO/IEC 27001:2022 Annex A 8.10 — information deletion; A 5.34 — privacy and protection of PII; A 5.12 — classification of information

The operational standard mapping directly onto all four DPC findings. A certified ISMS that cannot evidence enforced deletion, or produce a purpose-and-basis register, carries a nonconformity against A 8.10 and A 5.34 irrespective of whether any regulator is involved.

Control 3 — Safeguards 3.1 (data management process), 3.2 (data inventory), 3.4 (enforce data retention), 3.5 (secure disposal), 3.7 (data classification scheme)

Safeguards 3.1, 3.2, 3.4 and 3.7 sit in Implementation Group 1 — the baseline expected of every organisation regardless of size. A retention failure here is therefore an ownership gap rather than a capability gap, and that distinction matters when a regulator asks why the control was absent.

PT-2 — authority to process PII; PT-3 — PII processing purposes; PT-5 — privacy notice; SI-12 — information management and retention

The PT control family exists to make lawful basis, purpose and notice auditable artefacts rather than assertions; SI-12 is the retention counterpart. Useful where a client already runs an 800-53-aligned control set and needs the privacy findings expressed in their own control language.

Recorded so the omissions are visible rather than accidental.

—  GDPR Articles 33 and 34, and NIS2 Article 23, do not apply. This is an enforcement decision, not a personal-data breach: there is no incident, no notification clock and no CSIRT duty. Attaching breach-reporting articles to an enforcement action is the most common mapping error in this class of story.

—  DORA (Regulation (EU) 2022/2554) does not apply. No financial entity and no critical ICT third-party service provider is in scope, and DORA is not a general data-governance framework.

—  EU Cyber Resilience Act (Regulation (EU) 2024/2847) does not apply. No product with digital elements and no vulnerability-handling or reporting obligation is engaged.

—  EU AI Act (Regulation (EU) 2024/1689) does not apply. Inferring interests for ad targeting in 2018–2020 is profiling under GDPR Art. 4(4), not a regulated AI system on these facts, and the Act’s obligations postdate the conduct.

—  NIS2 Article 21 risk-management measures are not engaged. The findings concern data-protection principles, not the security of network and information systems.

[KB UPDATE NEEDED] Digital Markets Act — Regulation (EU) 2022/1925. EU regulation on designated gatekeepers. Art. 5(2) requires a gatekeeper to obtain consent before combining or cross-using personal data across its core platform services — a direct intersection with location collected in one service and used to target advertising in another. Absent from §1 of regulations-reference.md; relevant to any case involving a designated gatekeeper.

[KB UPDATE NEEDED] EDPB Guidelines 05/2020 on consent under Regulation 2016/679. European Data Protection Board guidance defining freely given, specific, informed and unambiguous consent, including interface design that steers a choice. The authoritative reference for the consent standard the 2018 BEUC complaints invoked; regulations-reference.md currently lists no EDPB guidelines at all.

[KB UPDATE NEEDED] ISO/IEC 27555:2021 — Guidelines on personal data deletion. ISO/IEC guidance on establishing deletion rules, deletion classes and retention periods across a data estate. The missing operational companion to ISO/IEC 27701 for exactly the retention failure in this case; not listed in §4 of regulations-reference.md.

SEG builds the retention schedule and the lawful-basis register as enforceable artefacts — mapped to storage-layer expiry settings and to the catalogue that gates your pipelines — and assembles the accountability evidence pack that Art. 5(2) requires you to be able to produce years after the fact.

SEG reviews the actual collection and retention configuration of your SaaS and cloud estate — lifecycle rules, warehouse partition expiry, consent-mode defaults, SDK inventories — and reports where practice diverges from policy. That divergence is what a regulator measures.

SEG assesses the processors and embedded SDKs inheriting your customers’ location and behavioural data, tests the retention ceilings and audit rights in your processor agreements against what each processor can actually evidence, and closes the gap between a signed DPA and a verified deletion log.

SEG delivers the 5B rules above as a standing briefing for product, marketing and engineering — the teams whose routine decisions create the collection paths, the retention defaults and the notices a regulator will eventually read back to you.

SEG validates that privacy controls hold under test: that a consent refusal actually stops collection rather than filtering it downstream, and that a deletion request removes data from backups, analytics copies and third-party systems — not only from the primary store.

This decision draws a line under the era in which privacy governance could live in documents. Every finding the DPC made — retention beyond necessity, an undemonstrable lawful basis, opaque notices — describes a state of configuration, and every remedy Google offered in response describes a setting. The regulatory question is converging with the engineering question: not what your policy says, but what your storage layer does when nobody is watching. Expect the next generation of enforcement to be evidenced the same way — against lifecycle rules, catalogue tags and deletion logs rather than policy PDFs — and note that a six-year lag between conduct and penalty means the configuration you cannot explain today is the exhibit you will be asked about in 2032.

Volodymyr Lytvyn, vCISO / GRC manager

We tell clients that accountability is evidentiary, and this decision is what we mean by it. A regulator opened an inquiry in February 2020 into conduct beginning in May 2018, and closed it in September 2026. Consider what that asks of an organisation: prove the lawfulness of processing you switched off years ago, using records you had no particular reason to believe anyone would ever read. Most of the organisations we assess cannot do it — not because they were reckless, but because their retention schedule lives in a policy document and their lawful basis lives in somebody’s recollection of a meeting. Neither survives contact with a statutory inquiry. What survives is a lifecycle rule with a date on it, a catalogue tag that names the purpose, and a deletion log that proves the job ran. We would rather write three of those for a client than thirty pages of policy. And in our reading the compliance order matters more than the fine: €403 million is a number Google can pay, but six months to bring processing into compliance is an engineering programme with a deadline, and that is the part most of our clients would fail. Under GDPR Article 5(2) the burden of proof sits with you. Build the evidence while the system is still running, because you cannot reconstruct it afterwards.