When Proximity Data Becomes Personal Data

Location data is not automatically a special category of personal data under the UK GDPR. It falls within the data-protection framework when it relates to an identified or identifiable person, including where a persistent device or account identifier allows someone to be singled out. In a proximity system, the same physical interaction can create non-personal aggregate data in one architecture and detailed personal data in another, so the assessment must start with the actual identifiers and data flows.

A professional reviewing a privacy and analytics dashboard in a modern office
Illustrative example of privacy-aware reporting and analytical review.

Legal update for July 2026: the Data (Use and Access) Act 2025 changed parts of the UK data-protection and PECR framework, and the ICO confirms that all relevant provisions are now in force. This guide is a planning overview and not legal advice.

When a receiver records that a stable device or account identifier entered a zone at a particular time, the record is likely to be personal data if the organisation or another party can identify or single out the person behind the journey. A short-lived event that is immediately aggregated may be assessed differently. The identifier, persistence, linkability and access to additional information all matter.

When planning a deployment, four UK GDPR principles dictate how you handle this data:

  • Lawfulness, fairness and transparency: You must have a valid legal basis to process the location data, and the user must understand what is happening.
  • Purpose limitation: Data collected for indoor wayfinding cannot later be repurposed for targeted marketing without a fresh legal basis.
  • Data minimisation: You should only collect the level of location granularity necessary for the specific task. Precise coordinate logging is difficult to justify if zone-level presence is sufficient.
  • Storage limitation: Raw location logs must not be kept indefinitely simply because they might be useful later.

It is a common misunderstanding that hardware can be "GDPR-compliant". Compliance rests entirely on how the data is processed, the legal basis you rely upon, and the transparency of your privacy notices. A beacon is a transmitter; your system does the processing.

Applying the Rules to Common Venue Scenarios

For optional promotional notifications, consent is commonly relevant and PECR may impose channel-specific rules, including limited exceptions such as the soft opt-in in appropriate circumstances. Operational uses may rely on another lawful basis if the necessity and balancing tests are met. Treat each purpose and communication method separately rather than applying one answer to the whole system.

Retail footfall and queue detection

If a system detects devices to count how many people are near a till point, the immediate question is whether the data is anonymised at the point of collection. If the system logs a hashed MAC address and stores it for days to distinguish unique visitors from returning ones, that is still personal data. To rely on legitimate interests for queue management, you must demonstrate that tracking individuals is necessary and proportionate, and that you cannot achieve the same insight through anonymous, real-time aggregate counting (such as a simple infrared counter).

Museum and venue wayfinding

If an indoor-navigation app sends an authenticated user’s location trail to a server, that trail is personal data. The organisation should separate what is necessary for navigation from optional analytics or marketing. Where consent is relied upon, choices should be specific to those purposes; where another basis is used, the necessity and user-expectation analysis should be documented.

Event QR and NFC check-in

A QR scan or NFC tap at an event entrance becomes personal data when it is linked to a named or identifiable ticket holder. Access-control processing may be necessary for the ticketing service, while later marketing or behavioural analytics requires its own analysis. The deliberate tap or scan does not by itself authorise every downstream use.

Capturing consent for location

For consent to be valid under UK GDPR, it must be freely given, specific, informed and unambiguous. In a proximity context, this means avoiding pre-ticked boxes and steering clear of blanket statements like "I agree to location services". The prompt should specify the action: "Allow Venue X to detect your proximity to exhibits to display relevant audio content." The mechanism to withdraw consent must be as easy as it was to give it, typically within the app settings or via a QR code on the premises that links to a preference centre.

Governance Checks Before Launch

Deployments frequently stumble not on the technology, but on the assumptions made about privacy. Recognising these pitfalls early prevents costly rework or regulatory scrutiny.

  • Assuming MAC randomisation solves the problem: Modern iOS and Android devices randomise Bluetooth MAC addresses to prevent long-term tracking. While this limits some passive tracking methods, it does not remove your GDPR obligations if your system uses app-based identifiers, fingerprinting techniques, or if the randomised address is still logged and combined with other data points.
  • Bundling location consent: Grouping location tracking consent with general terms and conditions or generic marketing opt-ins invalidates the consent. It must stand alone.
  • Retaining raw logs "just in case": Storing raw RSSI feeds and timestamped device IDs for months without a defined purpose breaches storage limitation. If you need historical data for trend analysis, aggregate and anonymise it promptly—for example, converting individual pings into hourly zone counts—and delete the raw logs.
  • Ignoring third-party processors: If your beacon management platform, analytics dashboard, or integrator has access to the location data, they are a data processor under UK GDPR. You need a written contract in place specifying what they can do with the data and requiring them to delete it according to your instructions.

Limitations of the regulatory framework

UK GDPR is principles-based, which means there is no statutory checklist stating exactly how long you may keep a beacon log or what specific wording your privacy notice must use. This flexibility is a double-edged sword: it allows you to tailor your approach to your specific deployment, but it requires rigorous documentation of your reasoning. If the ICO questions your approach, they will look for evidence that you actively considered data minimisation and purpose limitation, rather than defaulting to the most data-intensive option.

Key checks before going live

Before activating a proximity system, work through these practical questions with your integrator and legal team:

  • What exact identifiers are being logged (device ID, MAC address, user ID), and where are they stored?
  • Is the location data aggregated before it reaches any analytics dashboard, or can an individual’s path be reconstructed?
  • What is the documented legal basis for each distinct processing activity (e.g., access control vs. marketing vs. footfall analytics)?
  • How does a visitor withdraw consent, and does the system automatically stop processing their location data when they do?
  • What is the defined retention period for raw location logs, and is the deletion process automated?
  • Have all third-party platforms accessing the data signed a Data Processing Agreement?

Answering these questions does not constitute legal advice, but it provides the operational clarity needed to run a proximity deployment that respects visitor privacy and aligns with current ICO expectations. For deployments involving systematic location tracking, a Data Protection Impact Assessment will be the necessary next step to formalise this reasoning.