A location platform can show where a worker, visitor or critical asset was at a particular moment. The harder question is what should happen to that record afterwards. RTLS data retention determines whether valuable operational evidence is available when it is needed, without holding detailed location history for longer than the organisation can justify.

For a facilities provider, a time-stamped presence record may resolve a dispute about whether a scheduled inspection took place. In a manufacturing environment, historical asset movements may help investigate a production delay. Following an SOS alert, location history may support a safety review. Keeping every location point indefinitely, however, creates privacy, security and storage obligations with little operational benefit.

What RTLS data retention means

A real-time location system, or RTLS, uses technologies such as ultra-wideband (UWB), Bluetooth Low Energy (BLE), GPS and connected gateways to establish the location of people or assets. UWB can provide highly accurate indoor positioning in a supported deployment, while BLE is often suited to presence, proximity and zone-based applications. GPS supports outdoor location, and gateways receive and relay data from badges, tags and sensors.

RTLS data retention is the policy and technical process for deciding which of those records to keep, where they are held, who can access them and when they are securely deleted or anonymised.

It is not one type of data. A platform might create raw location observations, calculated coordinates, zone-entry events, task-completion records, SOS alerts, device health data and audit logs. These have different value and different retention needs. Treating them all as one permanent location history is rarely the right design.

Why a single retention period does not work

The right retention period depends on the purpose of each record. A live map designed to dispatch the nearest qualified engineer needs current information, not years of movement data. A proof-of-service record may need to remain available for the length of a client contract or dispute period. A serious safety incident may require a controlled evidential hold while it is investigated.

This distinction matters for privacy as much as operations. Under UK data protection law, personal data should not be kept longer than necessary for the purpose for which it was collected. Where worker location is involved, organisations should be able to explain the purpose clearly, apply proportionate controls and keep their policy under review. The Information Commissioner’s Office expects organisations to consider retention as part of their wider accountability arrangements; high-risk processing may also require a data protection impact assessment.

There is no universal answer such as “keep RTLS data for 90 days”. A sensible policy is purpose-led, documented and capable of applying different rules to different data sets.

Separate live operational data from evidence

A practical retention model starts by classifying data according to how it is used. The following four groups are a useful basis for a retention schedule:

  • Live location data supports immediate coordination, safety monitoring and resource allocation. It normally has the shortest useful life once the live operational window has passed.
  • Operational event records include arrival at a verification zone, task acceptance, proof of completion and equipment handover. These may need to be retained long enough for service validation, payroll queries or contract management.
  • Safety and security records include SOS activations, fall-detection alerts, access exceptions and incident-related location trails. They require tighter access control and may need longer retention where an investigation is active.
  • System and audit records show who viewed, exported, changed or deleted data, alongside device and gateway health. They support governance and troubleshooting, but their retention should still be defined rather than assumed.

The distinction between a raw signal and a meaningful event is especially useful. A badge might generate frequent BLE or UWB observations as it moves through a workplace. In many cases, the organisation does not need to retain every observation. It may only need a verified record that a worker entered an authorised zone, responded to a lone-worker check-in or completed a task at the required location and time.

This approach reduces the amount of detailed personal location data held while preserving the evidence operations teams actually use.

Design retention around the operational question

Before setting any period, ask what question the data must answer after the event. If an engineer confirms attendance at a customer site, how long can the customer reasonably challenge that service record? If an asset is routinely misplaced, how far back does a supervisor need to review movement patterns? If a worker raises an emergency alarm, what information will an incident review require?

Then test whether a less detailed record would answer that question. A facilities team may only need the time a tagged cleaning cart entered and left a floor, rather than a continuous route through the building. A construction site may need a geofence event confirming entry into a restricted area, rather than storing a minute-by-minute history of every worker.

The more precise the positioning, the more carefully this choice should be made. UWB’s accuracy can be valuable for locating a person in an emergency, identifying the nearest asset or verifying work at a specific point. That same precision means organisations should avoid retaining detailed trajectories by default when zone-level evidence is sufficient.

Build controls into the RTLS platform

A retention policy that cannot be applied automatically will eventually become inconsistent. Configure the RTLS platform so retention is linked to data category, site, workflow and incident status where appropriate. Standard records can expire on schedule, while authorised incident records are placed on hold until the review is complete.

Access controls matter just as much. A control room may need live visibility to protect staff and coordinate response. A contract manager may need proof-of-completion events but not access to individual movement trails. IT and security teams need clear rules for administrator access, exports, backups and deletion verification.

For organisations using connected workplace technology, the data design should reflect the physical deployment. Sense Presence, for example, combines proprietary badges, tags, gateways, buttons and sensors with software and location-aware workflows. A badge-triggered SOS event, a gateway-confirmed zone entry and an environmental alert should not automatically receive identical retention treatment simply because they arrive in the same platform.

The same principle applies across sites. GPS records from field teams, UWB coordinates within a hospital or factory, and BLE presence events in a retail estate may each serve different purposes. A central policy can set governance standards, but local operational owners should validate whether each retention rule remains necessary.

Privacy, transparency and worker trust

Location data programmes work better when people understand what is collected and why. Explain the operational purpose in plain language: protecting lone workers, improving emergency response, locating critical equipment, verifying attendance at a work zone or allocating nearby tasks. Avoid vague statements about monitoring productivity if that is not the defined purpose.

Workers should know when location collection is active, what devices are used, who can see live and historical data, how long records are held and how concerns can be raised. Consultation with employees, safety representatives and relevant staff groups can expose practical issues early, particularly where a deployment changes established working practices.

Policies should also cover exceptions. What happens when a badge is shared, lost or left in a vehicle? Can supervisors correct an incorrectly assigned task? How are subject access requests, deletion requests and legal obligations handled? These are governance questions, not merely technical settings.

Review retention as the use case changes

Retention periods should be reviewed after a new workflow, site rollout, incident type or integration is introduced. A system initially deployed for asset visibility may later support lone-worker safety or proof of service. That can change the categories of data created, the people with access and the justification for retaining particular records.

Measure whether retained history is genuinely being used. If a team has not needed six months of raw location data, but regularly relies on 30-day task-verification records, the policy can be refined. Conversely, if incident reviews repeatedly need a longer evidence window, document that operational requirement and apply it only to the relevant event category.

Frequently asked questions

How long should RTLS location data be retained?

Keep it only for as long as it is necessary for the stated purpose. Live coordination data may have a short retention period, while verified task records, safety incidents or contractual evidence may need longer. Define periods by data category rather than applying one blanket rule.

Is RTLS data personal data?

It can be. Location information connected to an identifiable worker, visitor or contractor is likely to be personal data. Organisations should assess their particular processing, document the purpose and apply appropriate UK data protection controls.

Should raw RTLS coordinates be retained?

Only if they are necessary. Often, a zone event, attendance confirmation or proof-of-completion record delivers the operational value with less detailed history. Retain raw coordinates where they are needed for a defined safety, investigation or operational purpose.

Can an RTLS record be kept longer after an incident?

Potentially, where there is a documented need to investigate an incident, meet an obligation or manage a dispute. Use a controlled hold process, restrict access and delete the record when the reason for retaining it has ended.

The useful test is simple: if a retained location record cannot answer a real safety, service or operational question, it is probably time for it to expire.