What information the service actually handles
Under the UK GDPR and the Data Protection Act 2018, individuals hold specific rights over their personal data. For organisations running beacon networks, NFC touchpoints, QR code campaigns or indoor navigation systems, three rights demand particular attention: the right of access, the right to erasure and the right to object.
The right of access allows a person to ask what personal data you hold about them and how you process it. In a proximity context, this typically covers device identifiers linked to a profile, location histories built from beacon detections, NFC tap logs associated with a user account, and any analytics segments you have assigned to that individual.
The right to erasure, often called the right to be forgotten, entitles a person to request deletion of their personal data. This is not absolute, but in proximity marketing and indoor location tracking, the grounds for refusal are narrow. If you retained location data solely for marketing or analytics that no longer serves a purpose, deletion will usually be required.
The right to object allows individuals to oppose certain types of processing. For direct marketing based on location data, this right is absolute: once someone objects, you must stop using their data for that purpose. For other processing grounded in legitimate interests, the individual can object on grounds relating to their particular situation, and you must then demonstrate compelling legitimate grounds that override their interests.
A critical distinction in proximity systems is between personal data and genuinely anonymous aggregate data. If your analytics platform only stores counts of devices passing a zone, with no identifiers retained and no way to link detections back to an individual, those counts fall outside the scope of these rights. However, the moment you store a hashed device address, link a beacon detection to a CRM record, or build a journey profile that could identify someone, the data becomes personal and the rights apply in full.
Controls for collection, use and disclosure
Retail proximity marketing
A shopper who previously opted in to receive entrance-point notifications later objects to further marketing. Your system must be capable of flagging that device identifier or associated profile and suppressing all future proximity-triggered messages. If the same identifier also appears in footfall analytics, you need a clear policy on whether that data can continue to be processed under a separate lawful basis or must also be deleted.
Museum and gallery visits
A visitor who used an NFC audio guide or indoor navigation app submits a subject access request. They want to know which exhibits they interacted with, when, and what inferences your system drew about their interests. If your platform logs each NFC tap against a session ID that can be linked back to a ticket purchase or Wi-Fi registration, you must compile and provide that information. If the taps are stored only as anonymous counts per exhibit, you can explain that no personal interaction log exists.
Event venues and temporary deployments
At a multi-day conference, attendees use a wayfinding app that detects beacons to provide indoor navigation. After the event, an attendee requests deletion of all their movement data. This raises practical questions about data that has already flowed into post-event analytics reports, been exported to spreadsheets, or cached in backup systems. A robust process must trace the data through each stage and confirm deletion or anonymisation where possible.
Technical feasibility of fulfilling requests
Before going live with any proximity system, you need to confirm that your platform and any third-party processors can actually isolate and delete an individual's records. Some beacon analytics tools are designed around aggregate reporting and lack a per-device deletion function. Others can flag a device identifier but cannot reach into archived log files. If the technical capability does not exist, you have a compliance gap that should be resolved before deployment, not after a request arrives.
Verifying the requester
For subject access and deletion requests, you must verify the identity of the person making the request. In a proximity context, this can be awkward: the individual may know only their device type and approximate visit dates, not any identifier your system uses. If you link beacon detections to an account or loyalty programme, verification is straightforward. If you rely on device-level identifiers with no account, you need a practical method, such as asking the person to present their device so you can read the broadcasting identifier and match it against your logs.
Evidence for launch and later changes
Common mistakes
- Assuming anonymisation removes all obligations. Pseudonymised data, such as hashed MAC addresses that can be re-linked to a device, remains personal data. True anonymisation requires that the data cannot reasonably be linked back to an individual by any means.
- Treating all objections the same. An objection to direct marketing is absolute and must be actioned immediately. An objection to processing under legitimate interests requires a case-by-case assessment. Conflating the two leads to either over-deletion or unlawful continued processing.
- Ignoring informal requests. A person does not need to use specific wording or a form to exercise their rights. A verbal request at a reception desk, an email to a general inbox, or a social media message can all constitute a valid request.
- Overlooking third-party processors. If your beacon management platform, analytics provider or NFC content host holds copies of personal data, you remain responsible for ensuring they act on deletion requests. Check processor contracts and technical capabilities before you need them.
- Keeping data longer than necessary. Retaining location histories for years "just in case" makes deletion requests harder to fulfil and harder to justify. Define retention periods during the planning stage and enforce them automatically where possible.
Limitations
No proximity platform can guarantee instant, irreversible deletion across every possible storage layer. Backup systems, log aggregation pipelines and third-party caches may retain copies for defined periods. What matters is that you have documented processes, reasonable timelines, and can demonstrate that you have taken all steps required to delete the data within your control. For guidance on specific timeframes and what constitutes a reasonable response period, consult the current ICO guidance on individual rights, as these details are subject to regulatory interpretation and change.
Another limitation arises in systems that mix personal and non-personal data within the same dataset. If a single analytics table contains both individual device identifiers and aggregate zone counts, deleting the individual rows may distort the aggregate figures. Some organisations address this by separating personal and anonymous data at the point of ingestion, rather than trying to unpick them later.
Key checks before deployment
- Can your beacon or NFC platform isolate all records associated with a single individual or device identifier?
- Does your analytics pipeline allow per-record deletion, or does it only support aggregate roll-ups?
- Have you mapped every system and third-party processor that receives or stores personal data from your proximity infrastructure?
- Is there a documented process for receiving, verifying, fulfilling and logging rights requests?
- Have you defined and enforced retention periods that align with your stated purposes?
- Can you distinguish between data processed for direct marketing, where objection is absolute, and data processed under other lawful bases?
- Have you tested a sample deletion end-to-end, including checks on backup and archive storage?
Handling individual rights is not a one-time setup. As your beacon fleet changes, as you add new NFC touchpoints or switch analytics providers, the data flows shift and your processes must keep pace. Regular audits of where personal location data actually resides, rather than where you assume it resides, are the most reliable way to stay compliant.
