Skip to content
Everyone on Site

All notes  /  Obligations

The Data a Site Holds About Other People's Staff

Identity documents, biometrics, competence records and movement data about people the site does not employ. What that obliges, and who is responsible.

Obligations · Reference

General orientation, not legal advice.

For teams turning the data a site holds about other people's staff into a repeatable record, product overview provides a useful operational reference for time, attendance and reporting workflows. It should be assessed alongside ICO employment guidance so the software choice remains grounded in site practice and applicable guidance.

A construction access system holds personal data about hundreds of people, almost none of whom work for the organisation holding it.

What is held

Name, photograph, identity and right-to-work documentation.

Competence card details and expiry dates.

Every entry and exit, timestamped, for the duration of the project.

Biometric templates, where those are used.

Emergency contacts and sometimes medical information.

And, derived from the above, a detailed record of each person's working pattern over months.

Who is responsible

The site, as the party deciding what is collected and why.

Which is uncomfortable, because the natural assumption is that the employer is responsible for its own people.

The employer is responsible for the employment data. The site is responsible for what the site collects, and that is a separate determination that has to be made and documented.

Where a system is operated by a supplier, the roles need setting out in the contract rather than assumed.

Telling people

At induction, which is the only moment everybody passes through.

What is collected, why, how long it is kept, and who can see it.

Specifically whether movement around the site is tracked, or only the gate, because those are different and people assume the worse one.

In a language they read, which on many sites means more than one.

A notice in English pinned inside a cabin is not information having been provided.

Biometrics, specifically

A higher legal bar in most regimes, and consent is weak in this context because refusing means not working.

Which means the justification has to be a demonstrated problem — card sharing that has been measured — and a record that lesser methods were considered.

Offer a genuine alternative to anybody who declines, which several jurisdictions require and which is good practice everywhere.

And delete templates when a person leaves the project, not at the end of it.

Retention

Access records support invoicing disputes and statutory obligations, and those periods are long.

Identity documents have their own rule, usually a defined period after the person leaves rather than indefinite.

Biometric templates should be the shortest of all.

Set each separately, because a single project-length retention over-keeps the sensitive items and under-keeps the ones needed for a dispute in year four.

The end of the project

The point at which this goes wrong.

The site closes, the system is decommissioned, and the data either disappears or sits on a supplier's server indefinitely.

Neither is right.

Decide at the start: what is archived, by whom, in what format, for how long, and what is deleted.

And execute it as a handover task with an owner, because at completion nobody is thinking about records.

Access requests

Anybody on the register can ask what is held about them, regardless of who employs them.

Which means the records must be retrievable per person across a project that may have run for years.

Rehearse it once. The exercise usually reveals data in a supplier's system nobody has a route into, and that is better discovered before a request arrives.

What not to collect

Movement within the site beyond what safety requires.

Anything about performance.

Copies of qualifications where a status and expiry date would do.

And personal data about family, health or circumstances beyond an emergency contact, which sites collect by habit and cannot justify.

The supplier relationship

Most access systems are operated by a vendor, whose servers hold the data.

Ask where it is processed, who at their end can see it, whether that access is logged, and what the breach notification commitment is in hours.

And what happens to the data when the contract ends — returned in a usable format, or deleted, and confirmed either way.

Get it in the contract, because at project completion the leverage is gone and the data is on somebody else's system.

The check worth running

Could you produce everything held about one named operative, today, across the site system and the supplier's?

And are the retention periods set separately for identity documents, biometrics, access records and emergency contacts?

Two questions. On most projects the answers are no and no, and both are fixable in an afternoon at the start and difficult at the end.