What information the service actually handles
In proximity and indoor navigation deployments, "data sharing" rarely means handing over a spreadsheet. It typically involves sending location signals, device identifiers, zone entry logs or aggregated footfall figures to another organisation that processes that information on your behalf or for its own purposes. The distinction matters because UK data protection law treats these situations differently.
The UK GDPR and the Data Protection Act 2018 apply whenever location data can be linked, directly or indirectly, to an identifiable individual. Even if your beacons only broadcast and your system stores no personal data itself, the moment a third-party analytics platform receives device identifiers alongside timestamps and zone labels, that platform is processing personal data. The legal basis for that processing, and the relationship between your organisation and the third party, must be clear before any data leaves your systems.
Two roles recur in proximity deployments. The data controller decides why and how personal data is processed — typically the venue, retailer or event organiser. The data processor acts on the controller's instructions — commonly the analytics provider, beacon management platform or IoT integrator. When both parties decide independently how to use the data, they may be joint controllers, which creates separate disclosure and liability obligations. Misclassifying the relationship is a frequent source of compliance problems.
Data minimisation, a core principle under UK law, applies as strongly to sharing as it does to collection. Sending a full device identifier and precise timestamp to a contractor who only needs to know whether a zone was occupied at a given hour fails that test. The practical question is not whether you can share the data, but whether the specific data elements you are sending are necessary for the stated purpose.
Minimisation, notice and access controls
Analytics and platform providers
Most beacon and indoor navigation platforms receive raw signals — RSSI values, MAC addresses or advertising payloads — and return processed outputs such as zone counts, dwell times or path maps. Here, the platform is almost always a processor acting under your instructions. The key practical check is whether the platform retains raw identifiers after processing, and if so, for what purpose. Review the provider's documentation and data processing agreement to confirm that raw data is not used for the provider's own product improvement, benchmarking or advertising unless you have explicitly consented to that as a separate controller purpose.
IoT integrators and maintenance contractors
An integrator may need access to beacon management systems to adjust transmit power, update firmware or troubleshoot interference. That access can expose location logs and device identifiers. Practical safeguards include time-limited access credentials, read-only permissions where configuration changes are not needed, and contractual clauses preventing the integrator from exporting or copying data beyond what is required for the specific maintenance task.
Shared venues and multi-tenant spaces
In shopping centres, exhibition halls and shared office buildings, individual tenants often request footfall or dwell-time data for units near their premises. The centre operator, as controller, can share aggregated and anonymised zone-level counts without triggering the same obligations as sharing identifiable data. However, if a tenant requests data specific to their own unit and that unit is covered by a single beacon, the zone count may be so granular that it could identify an individual's visit pattern when combined with other information. The practical test is whether a reasonable person could re-identify someone from the shared dataset.
Event co-organisers and sponsors
At conferences and exhibitions, sponsors commonly receive reports on stand visits, session attendance or queue lengths. If these reports are based on aggregated counts, the sharing is relatively straightforward. If they include individual attendee journeys — even identified by a badge number rather than a name — the sponsor becomes a processor (or joint controller) and needs a formal agreement. A practical mistake is embedding sponsor-branded tracking within the event app without making the data flow transparent in the attendee privacy notice.
Operational contractors
Cleaning teams, security firms and facilities management companies may receive real-time occupancy data to allocate staff. In most cases, they need zone-level counts, not device-level logs. Supplying the minimum necessary data reduces both compliance risk and the operational burden of handling data the contractor does not need.
Review triggers, records and deletion
Assuming aggregation always removes personal data
Aggregating data reduces identifiability but does not automatically eliminate it. A zone count for a large exhibition hall is unlikely to identify anyone. A zone count for a small meeting room with four registered attendees, updated every thirty seconds, is a different matter. Before treating aggregated data as non-personal, consider the granularity of the zones, the frequency of updates, the number of people typically present and what other data sources a recipient could combine with it.
Sharing raw identifiers without a clear legal basis
Sending unhashed MAC addresses, advertising identifiers or profile IDs to a third party without a documented lawful basis — typically legitimate interests with a documented balancing test, or explicit consent — is a straightforward compliance failure. Where raw identifiers must be shared, pseudonymisation at the point of export (for example, hashing with a salt that only your organisation holds) limits what the recipient can do with the data.
Omitting data processing agreements
A data processing agreement is not optional when a third party processes personal data on your behalf. For proximity deployments, check that the DPA covers the specific data types in your system — device identifiers, timestamps, zone labels, RSSI values — rather than relying on a generic template that references "customer data" without specifying location signals.
Not auditing what recipients actually do with the data
Contractual restrictions are only effective if they are monitored. If you share data with an analytics provider, request evidence of their data retention practices, access controls and sub-processor arrangements. If a sub-processor is based outside the UK, confirm that appropriate transfer mechanisms are in place. Periodic audits, even lightweight ones in the form of written questionnaires, provide a practical record of due diligence.
Overlooking the privacy notice
Your visitor or attendee privacy notice must describe any sharing of location data with third parties in sufficiently specific terms. "We may share your data with trusted partners" does not meet the transparency requirement. Name the categories of recipients — analytics providers, event sponsors, facilities contractors — and explain the purposes for which each category receives data.
Key checks before sharing
- Purpose test: Does the recipient have a documented, legitimate need for this specific data?
- Minimisation test: Are we sending the narrowest dataset that serves that purpose?
- Role test: Is the relationship correctly classified as controller-processor, joint controller or independent controller?
- Legal basis test: Is there a clear lawful basis for the transfer, documented before the data moves?
- Contract test: Does a signed DPA or equivalent agreement cover the data types and purposes involved?
- Notice test: Does the public-facing privacy notice accurately describe this sharing?
- Retention test: Are there contractual or technical limits on how long the recipient may keep the data?
- Audit test: Do we have a practical way to verify that the recipient is honouring these restrictions?
Data sharing in proximity technology is not inherently problematic, but it demands the same rigour applied to collection. Each external data flow should be justified, documented and limited to what the recipient genuinely needs. Where a proposed sharing arrangement cannot pass the checks above, the correct response is to narrow the dataset or decline the request, not to proceed and address compliance later.
