What the processing actually involves

Most privacy failures in proximity technology are not the result of deliberate misuse. They stem from deployment teams treating data collection as a technical afterthought rather than a design constraint from the outset. By the time someone in operations notices that beacon identifiers are being logged at one-second intervals alongside device timestamps, the system is already running and the data is already stored.

A professional reviewing privacy-conscious analytics on a tablet
Illustrative example of aggregated analytics and privacy review.

The pattern tends to follow a familiar sequence. A retailer or venue selects a beacon platform, focuses on placement and calibration, and only addresses privacy when a colleague or auditor asks what is actually being recorded. At that point, changing the configuration means reworking integration logic, adjusting analytics pipelines and potentially re-contacting users who have already consented to an earlier, broader wording.

The mistakes that cause the most practical damage fall into three categories: skipping the formal assessment that should precede any deployment, gathering more information than the use case requires, and presenting consent in a way that satisfies a checkbox but not the underlying legal standard. Each of these is avoidable, but only if they are addressed before hardware goes on the wall.

Failing to Conduct a DPIA

A Data Protection Impact Assessment is not a formality invented for compliance paperwork. It is a structured way to identify what personal data a system will process, why, how long it will be kept and what could go wrong. Under UK GDPR, a DPIA is mandatory when a type of processing is likely to result in a high risk to individuals' rights and freedoms. Location tracking in enclosed spaces, particularly where people cannot easily avoid the system, sits squarely in that category.

The mistake organisations make is not necessarily ignoring DPIAs entirely, but conducting one after the procurement decision has been made and the integrator has already quoted for a specific architecture. At that stage, the assessment becomes a retroactive justification rather than a genuine evaluation of alternatives. If the DPIA reveals that the chosen platform logs raw RSSI values with device identifiers when only zone-level counts are needed, the finding arrives too late to influence the purchase.

Practical signs you need a DPIA before proceeding

  • The system will detect or infer the location of individuals within a building or site.
  • There is no straightforward way for a person to opt out without leaving the venue entirely.
  • Data will be combined with other sources, such as a loyalty programme or ticketing system.
  • The deployment targets a group that may include children, vulnerable adults or employees who might feel pressure to consent.

A useful DPIA for a proximity deployment does not need to be a lengthy document. It needs to state the purpose clearly, map the data flow from beacon or sensor through to any analytics dashboard, identify the lawful basis, set a retention period and list the mitigations for each identified risk. If your integrator cannot describe the data flow in those terms, that is a problem in itself.

For current UK guidance on when a DPIA is required and what it should contain, refer to the Information Commissioner's Office documentation on DPIAs. This article offers practical observations from a deployment perspective, not legal advice.

Collecting More Data Than Necessary

Data minimisation is a core principle of UK data protection law, but in proximity systems it collides directly with a common vendor pitch: collect everything now, because you might want to analyse it later. The result is platforms that default to high-granularity logging and leave it to the operator to figure out how to restrict what is stored.

In practice, this manifests in several ways. A beacon management platform may log every individual advertising packet received, complete with a timestamp and the receiving device's identifier, when the actual business question is simply how many people entered a zone during a given hour. An indoor navigation system may record the full path of each user session when the operational need is only aggregate flow patterns through a corridor. A queue detection setup may store individual dwell times linked to device identifiers when the requirement is a real-time count of people in the queue.

The problem is not only legal. Storing data you do not need creates operational overhead. It increases storage costs, complicates any subject access request, broadens the scope of a potential breach and makes it harder to demonstrate compliance to an auditor. When someone asks what you hold on a particular visitor, discovering that the answer is a detailed movement trace rather than a simple zone entry record is an uncomfortable position.

Questions to put to an integrator or platform provider

  • What data fields are logged by default, and which can be disabled before deployment?
  • Does the system store raw RSSI values and device identifiers, or only derived zone entries?
  • Can aggregation be applied at the point of collection so that individual-level data is never written to storage?
  • Where is data processed, and where is it stored? Are there options for on-premises or regional processing?
  • What is the exact retention period for each data type, and is it enforced automatically or manually?

If the provider cannot give clear answers, or if the answer is that everything is logged and you can filter it later in a dashboard, the architecture is working against data minimisation rather than supporting it.

Consent under UK GDPR must be freely given, specific, informed and unambiguous. In proximity deployments, those requirements are frequently met in a technical sense while being undermined in practice. The result is a consent mechanism that would not survive scrutiny if challenged.

The most common failing is bundling location tracking consent with broader terms of service or app permissions. A visitor who downloads a venue app and taps "Accept All" to gain access to a map or ticket has not given specific consent to Bluetooth beacon tracking. They have agreed to a blanket set of terms, and the location element is buried within them. If the consent cannot be separated from other purposes, it does not meet the standard.

Pre-ticked boxes present a similar problem. If a settings screen presents location-based notifications with the toggle already switched on, the user has not actively consented. The same applies to consent wording that is vague about what will actually happen. A statement such as "we may use your location to improve your experience" does not tell the user that beacons will detect their position within the building, that their zone entries may be logged, or that data may be retained for a defined period.

What adequate consent looks like in this context

  • The request is presented at the point where the location function is actually needed, not during initial app onboarding when the user is trying to reach a different feature.
  • The wording names the technology and the specific purpose: for example, "Bluetooth beacons will detect which exhibition zone you are in so we can show relevant exhibit information."
  • The user can refuse without losing access to core functions such as viewing a floor plan or reading general venue information.
  • The consent can be withdrawn at any time through a visible setting, and withdrawal stops further processing without requiring the user to delete the app or leave the venue.
  • The system records when consent was given, what version of the wording was shown and the specific identifier of the user or device.

For web-based approaches using Eddystone or similar protocols, the consent model is different but the standard is the same. A browser notification prompt that simply says "this site wants to send notifications" does not constitute informed consent for location-based messaging. The user needs to understand that accepting will allow the venue to send content triggered by their physical position.

A practical test is to read your own consent wording and ask whether a reasonable person, reading it once at normal speed, would understand what data is collected, why and for how long. If the answer is no, the mechanism needs reworking regardless of what a compliance checklist might suggest.