GDPR & RTLS — the employee-tracking question.
RTLS systems that can identify an individual employee — even indirectly — fall under GDPR. The deployment is not illegal, but it is regulated, and the architecture choices determine whether it stays legal. This is the operator-level summary of what is required.
Where GDPR applies, and where it doesn't
GDPR engages whenever location data can be attributed to an identifiable person, directly or by combination with other data. Anonymous people-counting and aggregated occupancy do not engage GDPR. Tag-on-badge tracking does.
Vehicle tracking engages when the driver is identifiable. Aggregated zone heat-maps usually do not, unless the team is small enough that an individual can be inferred. The right threshold question is: ‘could a reasonable person link a position event back to a named worker?’
The six lawful bases and which apply here
Six lawful bases exist in Article 6 — for employee location tracking, only three are realistic: legitimate interests (with a documented balancing test, the most common basis for safety RTLS),
legal obligation (specific compliance regimes), and explicit consent (rarely the right basis in an employment context because consent is not freely given).
Most safety-driven RTLS deployments rely on legitimate interests with a documented DPIA. We help you draft both.
Works councils, unions and the consultation question
In Germany, France, the Netherlands, Austria and many other EU jurisdictions, employee monitoring requires formal works-council (Betriebsrat / Comité Social et Économique / Ondernemingsraad) consultation and often a written agreement.
Skipping this step is the single most common reason RTLS deployments stall in DACH.
We design the deployment specification with the works-council questions built in — what's collected, what's not, retention, access, transparency — so the consultation is constructive rather than adversarial.
Design choices that change the GDPR picture
Several architecture choices materially reduce GDPR exposure: separating tag identity from staff identity at the platform layer; configurable retention with auto-deletion (typically 7-30 days for raw position events);
role-based access where supervisors see aggregate, not individual; and ‘alarm-only’ modes where location is invisible until a duress event fires.
None of these are vendor-specific — they are deployment-design choices we bake into stage 1 (Design) of the TRACIO Programme Method.
Frequently asked questions
Do we need a DPIA for RTLS?
Almost always, yes, where employees can be identified. A DPIA (Data Protection Impact Assessment) documents the lawful basis, balancing test, risks, mitigations and review schedule. We produce a DPIA template tailored to RTLS during stage 1, signed off jointly with your DPO.
Can we use legitimate interest as the lawful basis?
For safety-driven deployments, usually yes, with a documented balancing test showing safety benefits outweigh privacy intrusion and that less-invasive alternatives are not viable. For productivity monitoring, legitimate interest is harder to defend; consult your DPO early.
What retention period is defensible?
Raw position telemetry is typically retained 7-30 days; aggregated analytics longer. Alarm events (duress, mustering) longer still where required by safety regulation. The principle is data minimisation: collect for the named purpose, retain only as long as necessary.
How do we handle works-council consultation in Germany / France?
Treat it as a stage 1 deliverable, not an afterthought. We have produced works-council-ready specifications for DACH and French deployments that include scope, access, retention and review cadence. Engage the council before signing the SOW, not after.
Last updated: