Establish the baseline and success evidence
Data minimisation is a core requirement under UK GDPR, but in proximity technology and indoor navigation projects, it is frequently treated as an afterthought. The principle is straightforward: you should only process the personal data that is directly relevant and necessary to accomplish a specified purpose. The difficulty arises when defining what "necessary" actually means in a physical space filled with Bluetooth beacons, NFC tags and QR codes.
Proximity hardware is capable of generating a high volume of signal data. A single Bluetooth Low Energy (BLE) beacon broadcasting at a 100-millisecond interval produces ten advertising packets per second. If a gateway or receiver logs every single packet along with the receiving device's MAC address or a hashed identifier, the resulting dataset grows rapidly. The system collects far more information than is required to know that a visitor entered a zone.
The problem often stems from a disconnect between what the technology can capture and what the operational objective actually demands. A venue might deploy beacons to trigger a welcome notification, yet the default configuration of their chosen platform might simultaneously log the precise timestamp, signal strength (RSSI) and device identifier of every smartphone within range. This creates a data store that serves no immediate purpose but introduces significant compliance risk, storage overhead and security liability.
Understanding data minimisation in this context means recognising that the default settings of an IoT platform are rarely aligned with the legal minimum. Operational managers must actively define the narrowest dataset that achieves the goal, whether that goal is triggering a single notification, counting footfall in a corridor or guiding a visitor to an exit.
Build and test the working approach
Applying data minimisation requires mapping each project objective to the exact data points needed to support it. The approach differs significantly depending on the use case.
Retail footfall counting: If the objective is to understand peak times at a store entrance, the system needs to register a unique device once per defined time window—perhaps a 15-minute or 30-minute period. It does not need a continuous log of every RSSI fluctuation as the shopper walks past. The data requirement is an aggregated count, not a movement trace.
Museum exhibit information: When a visitor taps an NFC tag to load an audio guide, the necessary data is the exhibit identifier and the time of the tap. Logging the visitor's route through the preceding three galleries is unnecessary for delivering the audio file. If route analysis is a separate, stated objective, it requires its own justification and distinct data handling rules.
Event wayfinding: Guiding a delegate from a registration desk to a seminar room requires the system to know the delegate's current zone and the target zone. Once the delegate arrives, retaining the step-by-step breadcrumb trail of their walk serves no operational purpose unless specifically required for post-event accessibility analysis.
Vendor platform defaults: Many off-the-shelf beacon management systems and analytics dashboards are designed to capture and visualise as much data as possible. This creates impressive heatmaps but often violates the minimisation principle. Evaluating a platform means asking whether it allows you to configure edge processing—where the gateway determines that a zone entry occurred and only sends that single event to the cloud, discarding the raw packet stream.
Acceptance, records and review triggers
The most persistent mistake in proximity deployments is hoarding data against a hypothetical future need. An operational manager might argue for logging continuous RSSI values because the marketing team "might want heatmaps next quarter." Under UK GDPR, speculative future use does not justify collection. If heatmaps become a requirement later, the data collection parameters can be widened at that point with a fresh assessment.
Another frequent error is conflating data resolution with data quality. High-resolution data—such as logging a device's location every second—feels more accurate, but in indoor environments affected by signal multipath and human absorption, it often produces noisy, unreliable traces. A well-calibrated zone entry event, logged once, is frequently more operationally useful than a hundred raw RSSI readings.
A critical limitation to understand is that data minimisation is largely irreversible at the point of collection. If a system logs raw identifiers and precise timestamps, you cannot easily strip that granularity out later. Aggregating data after collection is possible, but the raw data has already been stored, processed and potentially exposed to risk. Minimisation must happen at the point of ingestion, not as a retrospective cleanup exercise.
To assess whether a deployment is collecting more data than necessary, run these checks against the system configuration:
- Purpose mapping: Can every active data field in the database be tied to a specific, documented project objective? If a field exists solely because it was included in the vendor's default schema, it should be disabled.
- Aggregation settings: Is the system configured to aggregate device sightings at the gateway level, or is it forwarding every individual advertising packet to the cloud?
- Timestamp precision: Does the use case require second-by-second logging, or are minute-level or event-level timestamps sufficient?
- Identifier retention: If the purpose is anonymous footfall counting, are hashed or raw device identifiers being stored indefinitely, or are they being discarded immediately after the count is incremented?
- Vendor contracts: Does the platform provider's own infrastructure log your data for their own telemetry or product improvement? If so, this represents a secondary data flow that must be accounted for.
Addressing data minimisation during the procurement and configuration phase prevents the accumulation of a liability that offers no operational return. It forces clarity on what the deployment is actually trying to achieve, which invariably leads to better system design and more reliable analytics.
