When to Screen for a DPIA
A Data Protection Impact Assessment (DPIA) is a structured process for identifying and minimising data protection risks before a new system goes live. Under UK GDPR, a DPIA is not optional when a type of processing is likely to result in a high risk to individuals’ rights and freedoms. Proximity systems—using Bluetooth beacons, NFC readers, Wi-Fi tracking or indoor navigation platforms—frequently cross that threshold.
The trigger for a mandatory DPIA in proximity deployments usually stems from two criteria. First, the technology involves systematic monitoring of a publicly accessible area on a large scale. A retail floor, a museum gallery or an exhibition hall qualifies as a publicly accessible space, and a dense grid of beacons or Wi-Fi access points constitutes systematic monitoring. Second, proximity systems often rely on new technologies. BLE signal processing, MAC address observation and indoor positioning algorithms are still treated as novel processing methods in regulatory guidance.
A proximity DPIA is not a software compliance form. It is a technical risk assessment that must follow the data from the physical antenna to the final database deletion. The assessment must describe the nature, scope, context and purposes of the processing; assess the necessity and proportionality of the operation; and identify risks to individuals. For proximity technology, this means documenting exactly what signal leaves the beacon, what the receiving device does with it, what data is transmitted to a server, and who has access to the resulting location logs or analytics.
The assessment must be completed before the pilot phase begins. Running a beacon trial to "see what data we get" and then writing a DPIA afterwards breaches the fundamental requirement to assess risk prior to processing.
- Screen whether the planned processing is likely to create high risk.
- Describe purposes, people, data sources, recipients, storage and deletion.
- Assess necessity and proportionality against simpler alternatives.
- Identify risks to people, not only risks to the organisation.
- Record mitigations, residual risk, consultation and approval.
- Review the DPIA when the data flow, venue, supplier or purpose changes.
Mapping Processing and Assessing Risk
Retail footfall and dwell-time mapping
If a retailer deploys beacons to measure footfall and dwell times in specific aisles, the DPIA must address the technical reality of the data collection. If the system relies on observing MAC addresses from smartphones, the assessment must document how the retailer handles iOS and Android MAC randomisation, which breaks continuous tracking for most modern devices. If the retailer instead relies on an opt-in app, the DPIA must evaluate whether the app collects coarse zone data or precise coordinates, and whether that granularity is proportionate to the goal of understanding queue lengths. The assessment should explicitly state whether individual journey maps are created and retained, or whether data is aggregated into counts at the edge or server level.
Museum wayfinding and exhibit tracking
When a museum uses beacons for indoor navigation, visitors often download an app and grant location permissions. The DPIA here must evaluate the risk of inference. A visitor’s route through a museum can reveal sensitive information: spending twenty minutes in an exhibition about a specific health condition, or repeatedly visiting a gallery related to a particular faith. The assessment must question whether raw coordinate logs are necessary, or whether the system can be engineered to calculate the next turn instruction on the device and only send anonymised, aggregated exhibit counts back to the server. The technical architecture directly dictates the privacy risk, and the DPIA must capture that link.
Event badge scanning and stand analytics
At exhibitions, organisers often use NFC or BLE badges to track attendee movement between stands. The DPIA must distinguish between two distinct data flows: the lead-retrieval scan where an exhibitor explicitly taps a badge, and the passive background scanning of badges by ceiling-mounted readers to generate venue heatmaps. Attendees may expect the former but not the latter. The assessment must document whether attendees are given granular control to opt out of passive tracking while still allowing their badge to be tapped for contact exchange. It must also address who owns the passive tracking data—the organiser, the venue, or the exhibitor—and what contractual controls prevent secondary use.
Mitigation, Sign-off and Ongoing Review
Treating the DPIA as a static document
A common failing is completing the DPIA at the procurement stage and filing it. Proximity environments are physically dynamic. Exhibits move, retail layouts change, event infrastructure is temporary, and beacon firmware is updated. Any change that alters the data flow—such as switching from a broadcast-only beacon to one that accepts connections, or changing the app to log coordinates every second instead of every ten seconds—requires a review of the DPIA. The assessment should include a trigger list of changes that mandate a formal review.
Assuming aggregated data is automatically anonymous
Many proximity vendors claim their analytics are "anonymous" because they show heatmaps rather than individual names. A DPIA must look past the dashboard. If a dataset is small enough, or if the location data is combined with a CRM system or a Wi-Fi captive portal login at a later date, the data can be re-identified. The assessment must evaluate the risk of re-identification across the entire data lifecycle, not just the immediate output format. If a vendor cannot explain how aggregation is performed and whether any raw identifiers are retained in a separate data lake, the DPIA cannot conclude that the risk is mitigated.
Overlooking the hardware and firmware layer
DPIAs often focus heavily on the app, the database and the privacy notice, while ignoring the physical devices. The assessment must cover whether beacons can be reconfigured remotely by a third party, whether firmware updates are signed and verified, and whether the NFC tags are locked against unauthorised rewrites. If a beacon is tampered with to broadcast a different identifier, it could trigger malicious notifications or skew analytics. The DPIA should document the physical security controls for the hardware inventory.
Key checks for operational managers
- Necessity test: Can the business objective—such as measuring queue times—be achieved with a less intrusive method, such as a single overhead camera with on-device processing, rather than tracking individual devices across a floor plan?
- Data flow mapping: Can the integrator produce a diagram showing exactly which data points leave the phone, which leave the beacon, and what arrives at the server, without relying on vague terms like "usage data"?
- DPO involvement in physical placement: Is the Data Protection Officer or privacy lead involved in deciding where beacons are placed, or are placement decisions made purely by the marketing or operations team based on signal coverage?
- Residual risk acceptance: Does the DPIA clearly document which risks cannot be fully eliminated—such as the possibility of a visitor being tracked by another person using a BLE scanner app—and justify why the deployment proceeds despite those risks?
- Pilot scope: Does the DPIA for the pilot explicitly limit the number of devices, the duration of the trial, and the data retained, preventing a "soft launch" from becoming a full deployment by default?
A DPIA for proximity technology is only as reliable as the technical information fed into it. If the operational team cannot answer detailed questions about RSSI filtering, advertising intervals, MAC randomisation handling and server-side aggregation, the assessment will contain gaps. The process works best when the integrator provides technical specifications directly to the privacy lead, bypassing marketing summaries, so the actual data flows can be scrutinised before any hardware is fixed to a wall.
