Where location information becomes personal data
The Information Commissioner's Office has not published a single document titled "Guidance on Location Data." Instead, the ICO addresses location data across several overlapping publications: its general guidance on data protection, specific opinions issued during the pandemic on contact-tracing apps, guidance on anonymisation and pseudonymisation, and sector-specific materials such as those covering direct marketing and electronic communications. For anyone deploying beacons, NFC, QR codes or indoor navigation in a UK venue, the practical question is not whether a dedicated location-data rulebook exists, but which parts of the ICO's existing guidance apply to the signals you are collecting and what the regulator expects you to demonstrate.
The ICO draws a functional distinction that matters for proximity deployments. Location data becomes personal data when it can be reasonably linked to an identifiable individual, either directly (a device identifier tied to a customer account) or indirectly (a pattern of movement combined with other information that makes the person identifiable). A raw Bluetooth MAC address observed by a beacon gateway is, on its own, less clearly personal data than that same address matched against a loyalty-card database. The ICO's guidance on anonymisation is directly relevant here: the regulator has repeatedly stressed that aggregation alone does not automatically make data anonymous. If a dataset of zone-level dwell times could be combined with publicly available information to re-identify individuals, the ICO's position is that it remains personal data.
Another thread running through the ICO's materials is proportionality. The regulator expects organisations to justify why they need location data at all, and at what granularity. Collecting metre-level positioning for a safety-critical indoor navigation use case in a large transport hub may be justifiable; collecting the same resolution to measure how long someone stands near a promotional display in a small shop is harder to defend. The ICO does not prescribe exact thresholds, but its guidance on data minimisation and purpose limitation sets a clear expectation: you should collect the least precise location data that still meets your stated purpose, and you should document that reasoning.
Because the ICO's guidance is spread across multiple documents, a common error is to read only the direct-marketing guidance and assume it covers all proximity use cases. Venue analytics, indoor wayfinding, asset tracking and proximity-triggered content each sit under different parts of the framework. The direct-marketing rules (covering electronic communications and consent for marketing messages) are strict, but they do not address, for example, whether a museum's collection of anonymous-looking zone-transition counts requires a lawful basis under UK GDPR. For that, you need the ICO's core data protection guidance and its guidance on legitimate interests assessments.
Lawful, transparent and proportionate operation
Retail footfall and dwell-time analytics
Many beacon deployments in UK retail are sold as "anonymous footfall analytics." Under the ICO's guidance on anonymisation, the critical question is whether the data has been irreversibly de-identified before it leaves the premises or reaches any analytics platform. If a gateway logs device identifiers and a backend process hashes or aggregates them, the ICO's position is that the original collection was still of personal data, and the processing chain must comply with UK GDPR from the point of collection. Truly anonymous data, in the ICO's framing, is data that can never be re-linked to an individual by anyone. If your supplier retains the raw identifiers for any period, even briefly, the anonymisation argument weakens considerably.
Practically, this means asking your beacon or analytics supplier exactly what leaves the on-site gateway, in what form, and whether any reversible transformation is applied. If the supplier cannot give a clear answer, or if the contract allows the supplier to retain raw identifiers for "product improvement," the deployment may not meet the standard the ICO describes in its anonymisation guidance.
Museum and gallery zone tracking
Museums commonly use beacons or Wi-Fi probes to understand visitor flow through galleries. The ICO's guidance on legitimate interests is usually the starting point for the lawful-basis assessment here, since consent is difficult to obtain at scale in a free-admission environment. The regulator expects a documented three-part test: identify a legitimate interest, show that processing is necessary to achieve it, and balance that against the individual's rights and freedoms. For a museum, the interest might be improving exhibition layout or understanding congestion. The balancing exercise should consider whether visitors would reasonably expect their movement to be tracked, even in a "public" building, and whether the tracking is obvious or covert.
The ICO has signalled, particularly in its opinion on location data during the pandemic, that covert collection of location data is difficult to justify. Signage at entrances, explaining what is being collected and why, is a minimum practical step. Whether that signage satisfies the transparency requirement in full depends on the specifics of the deployment, but the absence of any notice is a clear red flag under the ICO's framework.
Event venues and temporary deployments
Temporary event deployments present a particular tension. The venue may only exist for a few days, which can make retention policies seem straightforward, but the ICO's guidance on purpose limitation means the data collected cannot simply be repurposed after the event. If zone-level analytics were collected to manage crowd flow during a conference, using those same logs afterwards to build a marketing list or to profile attendee behaviour for future events would exceed the original purpose unless that secondary use was made clear at the point of collection.
For events where attendees have registered and an app is used, the relationship between the app's permissions (particularly location services on iOS and Android) and the ICO's expectations around transparency is worth careful attention. The operating system's permission prompt is not, in the ICO's view, a substitute for a clear privacy notice explaining what the location data will be used for, how long it will be kept, and who will receive it.
QR and NFC interactions
QR scans and NFC taps are often treated as "opt-in by nature," but the ICO's guidance does not automatically treat a physical interaction as consent to broader location tracking. If scanning a QR code on an exhibit triggers content delivery and also logs the visitor's presence in that zone for analytics, the privacy notice at the scan point should explain both functions. The ICO's direct-marketing guidance is also relevant here: if the QR code leads to a page that solicits marketing sign-up, the consent mechanism must meet the UK GDPR standard of being freely given, specific, informed and unambiguous. A pre-ticked box or a buried clause will not satisfy this.
Evidence for launch and later changes
Assuming aggregation equals anonymisation
This is the single most persistent error in proximity deployments. Reducing individual beacon observations to "15 people in Zone 3 between 14:00 and 14:15" does not, by itself, make the data anonymous under the ICO's guidance. If the zone is small, the time window narrow, and the total visitor count low, re-identification may be trivially easy. The ICO's anonymisation guidance describes a risk-based assessment: you must consider the means reasonably likely to be used to identify someone, not just the means you intend to use. For small venues or low-traffic periods, aggregated location data can remain personal data.
Relying on supplier privacy notices alone
A beacon hardware manufacturer or analytics platform will publish its own privacy notice, but that notice covers the supplier's processing as a data processor (or, in some cases, as a separate controller). It does not discharge the venue operator's obligation to provide a clear, accessible privacy notice to visitors. The ICO's guidance on controllers and processors makes this distinction explicit. If your supplier's notice says "we collect anonymised location data" but your deployment does not in fact achieve anonymisation by the ICO's standard, the supplier's wording does not protect you.
Unclear retention periods
The ICO's guidance on data retention is straightforward in principle but frequently mishandled in practice. Location data should not be kept longer than necessary for the stated purpose. For a one-day event, retaining raw or pseudonymised location data for months afterwards is difficult to justify. For ongoing retail analytics, a rolling window (for example, keeping only the most recent 30 days of zone-transition data) is a more defensible approach. The key check is whether your deployment documentation specifies a retention period, whether the technical system enforces it automatically, and whether you can demonstrate both to the ICO if asked.
Overlooking the legitimate-interests balancing test
Many proximity deployments default to legitimate interests as the lawful basis because obtaining individual consent at scale is impractical. The ICO's guidance is clear that legitimate interests is not a blanket exemption. The three-part test must be documented before processing begins, and the balancing exercise must genuinely consider the individual's perspective, not merely assert that the organisation's interest outweighs it. If a deployment involves precise indoor positioning, covert collection, or sharing data with third parties, the balancing test becomes harder to pass and the documentation needs to reflect that difficulty honestly.
Key checks before deployment
- Request your supplier's data-flow diagram showing exactly what data leaves the on-site hardware, in what form, and where it is stored.
- Confirm whether any device identifiers are hashed, truncated or aggregated on-device before transmission, and whether that transformation is reversible.
- Verify that your privacy notice, displayed at the venue, describes location-data collection in specific terms rather than vague language about "improving your experience."
- Ensure your documented lawful-basis assessment covers the actual granularity of data you are collecting, not an idealised version.
- Check that your retention policy is technically enforced, not merely stated in a policy document.
- Confirm whether your supplier acts as a processor or a separate controller, and ensure the appropriate contract (a data-processing agreement under Article 28, or clear controller-to-controller terms) is in place.
- Review whether any location data is shared with third-party platforms (ad networks, CRM systems) and, if so, whether the original privacy notice disclosed that sharing.
Limitations of the guidance itself
The ICO's guidance is principles-based rather than prescriptive. It does not state, for example, that beacon deployments are permissible up to a certain accuracy threshold or that a specific number of visitors in a zone makes aggregation safe. This is deliberate, but it leaves operators needing to make their own risk assessments. The guidance also evolves: positions stated in earlier publications may be refined by subsequent ICO opinions or enforcement actions. Relying on a single guidance document downloaded at the start of a project, without checking for updates, is a practical risk. For deployments with a long operational life, periodic review of the ICO's published guidance and any relevant enforcement notices is a reasonable operational discipline.
Nothing in this article constitutes legal advice. Organisations deploying proximity technology should consult the ICO's current published guidance directly and, where appropriate, seek professional legal counsel for their specific circumstances.
