Data Minimisation Principles for Proximity
Data minimisation under the UK GDPR and the Data Protection Act 2018 requires that any personal data collected must be adequate, relevant and limited to what is necessary for the specified purpose. In proximity deployments—whether using Bluetooth beacons, NFC tags or QR codes—this principle forces concrete choices about what you record, how often and in what form.
The UK GDPR does not prescribe one universal retention period. The organisation must justify how long each dataset is needed and enforce the decision in the live system.
The first practical question is whether the data you are collecting is actually personal data. A raw RSSI signal from a beacon is not personal data on its own. A device identifier logged alongside a timestamp and a zone label starts to look like personal data if it can be linked to an individual. The moment you connect a Bluetooth scan to a known app user, loyalty account or Wi-Fi login, you are processing personal data and the minimisation obligation applies in full.
Common mistakes in proximity projects include logging every advertising packet at the highest possible frequency, storing MAC addresses before they are hashed, and retaining raw signal data long after the aggregated insight has been extracted. Another frequent error is collecting device movement paths when the business question only requires zone-level dwell times. If you need to know whether a queue is forming at a till, you do not need a metre-by-metre trace of each visitor's route through the shop floor.
When evaluating a beacon or indoor navigation platform, ask the supplier precisely what fields are written to each log entry, whether those fields can be reduced before storage, and whether the platform supports configurable logging levels. A system that only offers an all-or-nothing data capture setting will make minimisation difficult to maintain in practice.
Anonymising and Pseudonymising Location Data
Anonymisation and pseudonymisation are different. Pseudonymisation replaces or separates identifiers but the information remains personal data when a person can be re-identified using additional information. Effective anonymisation requires an evidence-based assessment that identification risk is sufficiently remote in the relevant context; deleting names or hashing an identifier does not automatically achieve it.
A beacon UUID, major and minor value normally identify the installed transmitter, not a visitor. Privacy risk arises on the receiving side when an app, account, cookie or device-level identifier links detections into a person’s journey. Rotating or hashing identifiers can reduce risk, but deterministic identifiers and event histories may remain linkable and therefore personal data.
The real risk with pseudonymised location data is re-identification through pattern analysis. If a device appears at the same desk every weekday at 08:45, the pseudonymised identifier becomes trivially linkable to a specific person even without a name field. Aggregation is the most reliable defence: collapsing individual paths into zone-level counts over defined time windows removes the pattern that enables re-identification.
Practical checks for your deployment include verifying that raw MAC addresses are never written to disk or transmitted off the device, confirming that any hashing uses a salted function rather than a simple deterministic hash, and testing whether your aggregated datasets could be combined with publicly available information to narrow down individual identities. If your supplier claims their data is "fully anonymised," ask what technique they use and whether they have documented a re-identification risk assessment.
Data Retention for Location Analytics
Retention periods for location data should be tied directly to the purpose for which the data was collected. There is no single correct retention window—a museum evaluating exhibit dwell times over a six-month season has different needs from a retail chain comparing week-on-week footfall across financial quarters.
A useful framework is to separate raw event data from derived analytics. Raw event logs—individual zone entries, RSSI readings, timestamped identifier observations—typically warrant shorter retention, often measured in days or weeks rather than months. The aggregated outputs—average dwell time per zone, peak-hour visitor counts, path heatmaps at the corridor level—can usually be retained for longer because they are far less likely to identify individuals.
The mistake to avoid is retaining raw logs indefinitely on the basis that they might be useful later. UK guidance is clear that storage for vague, unspecified future purposes does not satisfy the purpose-limitation principle. If a new analytical question arises after raw logs have been deleted, the answer is to collect fresh data for that specific purpose, not to keep everything on the off-chance.
When setting retention periods, document the justification for each data category and each duration. A supplier that recommends a default 24-month retention for all data types is unlikely to have applied minimisation thinking. You should also consider whether your analytics pipeline can produce the aggregated outputs before the raw data is deleted, and whether those outputs are stored independently so that the deletion of raw logs does not destroy the insight you actually need.
Automated Deletion Policies
An automated deletion policy is only as reliable as the systems that enforce it. In a typical proximity deployment, data may exist in multiple places: on the scanning device or gateway, in a local edge processor, in a cloud ingestion pipeline, in the primary database, in backup storage and in any downstream analytics or reporting tools. Deletion must reach every copy, or the policy is ineffective.
Backup systems are a frequent blind spot. If your primary database automatically purges raw beacon logs after 14 days but your backup regime retains full snapshots for 90 days, the raw data still exists well beyond your stated retention period. You need to verify that your backup schedule and deletion schedule are aligned, or that backups are themselves subject to deletion within the same window.
Verification is the other critical element. An automated deletion job that runs silently can fail without anyone noticing—due to a schema change, a permissions error or a silent exception in the script. Build in a simple check: a daily or weekly count of records older than the retention threshold, with an alert if that count exceeds zero. This does not require complex tooling; a basic query against the database table is sufficient.
When contracting with a platform provider, ask whether deletion is guaranteed within a fixed time window after the retention period expires, whether deletion covers all replicas and backups, and whether they can provide evidence of deletion on request. A clause stating "data will be deleted in accordance with the customer's retention policy" is not adequate if the provider's technical architecture cannot actually enforce it.
Data Sharing with Third Parties
Proximity deployments often involve multiple parties: the venue operator, the beacon hardware supplier, the software platform provider, an analytics contractor and sometimes the landlord or a parent organisation. Each data handoff introduces a minimisation and retention decision that needs to be addressed explicitly.
The starting point is to question whether sharing is necessary at all. If your analytics platform can produce zone-level reports without sending raw event logs to a separate contractor, then sharing those logs is hard to justify. Where sharing is genuinely required—for example, sending pseudonymised path data to an integrator who is building a custom dashboard—the data shared should be the minimum needed for that task. Sending the full event schema when the integrator only needs zone entry and exit timestamps fails the minimisation test.
When a supplier processes personal data on the organisation’s behalf, an Article 28 processor contract is normally required and should cover instructions, security, sub-processors and deletion or return. A disclosure to another independent controller is a different arrangement and needs its own lawful, fair and transparent data-sharing analysis. Do not describe every external recipient as a processor.
Practical questions to put to any party requesting access to your location data include: what specific fields do they need, for what stated purpose, how long they will retain it, whether they will pass it to any sub-processors, and whether they will aggregate it before storage. If a supplier asks for continuous access to raw beacon logs but can only explain the purpose in vague terms, that is a signal to restrict the scope of the data shared or to reconsider the arrangement.
