Start with purpose and reasonable expectations

A Data Protection Impact Assessment (DPIA) is a structured process for identifying and reducing the data-protection risks of a project before it launches. Under the UK GDPR, a DPIA is mandatory when a type of processing is "likely to result in a high risk to the rights and freedoms of individuals." The Information Commissioner's Office (ICO) publishes a screening checklist that helps organisations decide whether one is required.

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

Proximity and indoor-location deployments frequently cross that threshold. When beacons, Wi-Fi sniffers, or camera-based analytics track device identifiers or physical movements through a retail floor, museum gallery, or event venue, the processing often involves systematic monitoring of publicly accessible areas, large-scale location data, or technologies that make it difficult for individuals to understand what is happening. Any of these characteristics can trigger the legal obligation to complete a DPIA before the system goes live.

Failing to conduct a DPIA when one is required is itself a breach of the UK GDPR. The ICO can issue enforcement notices, fines, or reprimands. In practice, the more immediate consequences for a venue or retailer tend to be operational: a deployment that cannot be lawfully switched on, wasted hardware and integration spend, and the need to halt or redesign the project while an assessment is carried out retrospectively. A late DPIA also means risks were not identified or mitigated at the point where design changes were cheapest.

It is worth distinguishing guidance from legal advice here. The points in this article reflect the ICO's published guidance and general good practice for proximity deployments. Organisations with specific compliance questions should seek their own legal counsel and refer directly to the ICO's current documentation.

Controls for collection, use and disclosure

When a proximity deployment typically requires a DPIA

Several common proximity scenarios should prompt a DPIA screening at the very start of planning:

  • Beacon-based analytics in retail. If a shop floor uses beacons to count visits, measure dwell time near displays, or build heatmaps from MAC addresses or advertising identifiers, this is systematic location tracking in a public space. Even when identifiers are pseudonymised, the ICO generally treats this as high-risk processing.
  • Wi-Fi probe-request logging. Some venue systems listen for probe requests from smartphones to estimate footfall and movement paths. This captures signals from devices without the owners' knowledge or interaction, which the ICO has repeatedly flagged as requiring careful justification and, in most cases, a DPIA.
  • Museum or gallery visitor tracking. Cultural venues deploying beacons or camera-based analytics to understand which exhibits attract the longest visits are processing location data at scale in a space open to the general public.
  • Event badge tracking. Conferences that use RFID or BLE badges to log session attendance, stand visits, or networking interactions are tracking individuals' movements in detail, often linking that data to registration records containing names and contact details.

What the assessment actually involves

A DPIA for a proximity deployment is not a form-filling exercise. It requires a documented description of the processing, an assessment of necessity and proportionality, a systematic identification of risks to individuals, and measures planned to address those risks. The ICO expects to see evidence that the organisation genuinely considered alternatives, such as using aggregated count data rather than individual device paths, and that it chose the least intrusive option that meets the operational objective.

For operational managers, this means the DPIA should happen during the design phase, not after hardware is procured. If the assessment concludes that the original plan poses unacceptable risks, the design may need to change: reducing the granularity of location data, shortening retention periods, or switching from device-level tracking to zone-level counts. These changes are far cheaper to make before beacons are mounted and cabling is run.

The integrator's role

IoT integrators and platform vendors can supply technical inputs to a DPIA, such as details of what data the hardware actually transmits, whether identifiers are hashed at the device level, and what retention controls the platform offers. However, the legal responsibility for completing and recording the DPIA rests with the data controller, which is normally the venue, retailer, or event organiser, not the technology supplier. Relying on a vendor's assurance that "the system is GDPR-compliant" does not satisfy the obligation.

DPIA screening, monitoring and review

Mistakes that leave deployments exposed

  • Screening only after installation. Completing the ICO's screening checklist once beacons are already on the ceiling means the organisation has already incurred costs for a system it may not be able to lawfully operate. Screening should be one of the first project tasks.
  • Assuming pseudonymisation removes the need for a DPIA. Hashing a MAC address or using a rotating advertising identifier reduces risk but does not automatically take the processing below the high-risk threshold. The ICO's guidance is clear that pseudonymised location tracking in public spaces still requires assessment.
  • Conflating a privacy notice with a DPIA. Putting up a sign saying "we use beacons for analytics" addresses the transparency requirement but does not replace the risk-assessment process. Both are separate obligations.
  • Treating the DPIA as a one-off document. If the deployment changes, such as adding new zones, introducing a new data use like proximity notifications, or switching from aggregated to individual-level tracking, the DPIA needs to be reviewed and updated.

Limitations of the DPIA process

A DPIA identifies risks and documents mitigations, but it cannot guarantee compliance on its own. The assessment is only as good as the information fed into it. If the technical team understates what data the platform collects, or if the operational team does not mention that marketing will later want to link location data to loyalty-card records, the DPIA will be incomplete. Cross-functional input, from operations, IT, marketing, and whoever handles data protection, is essential.

Another limitation is that a DPIA does not resolve ambiguity in the law. For some proximity use cases, reasonable professionals disagree about whether a DPIA is strictly mandatory. The pragmatic approach, and the one the ICO encourages, is to treat borderline cases as requiring a DPIA anyway. The cost of conducting an unnecessary assessment is small compared to the cost of being wrong in the other direction.

Key checks before going live

  • Has the ICO's screening checklist been completed and documented, with a clear record of the decision and who made it?
  • If a DPIA was required, has it been completed before any personal data is processed by the live system?
  • Does the DPIA record genuine consideration of less intrusive alternatives, with reasons for rejecting them?
  • Have the planned mitigations actually been implemented in the platform configuration, not just described on paper?
  • Has the DPIA been reviewed by someone with data-protection expertise, whether internal or external?
  • Is there a process to revisit the DPIA when the deployment scope or data use changes?

Getting the DPIA right does not eliminate every privacy risk in a proximity deployment, but skipping it or treating it as a rubber-stamp exercise creates a structural weakness that can halt an entire project. For UK venues and retailers investing in beacons, indoor navigation, or location analytics, building the assessment into the earliest stage of planning is a practical safeguard, not a bureaucratic hurdle.