Look at a few visitor sign-in screens and you'll often see the same checkbox: "I consent to my details and photograph being recorded." It looks careful. For a visitor log, it isn't, and it's one of the first things a Data Protection Officer will question.
Why consent is the wrong basis for a visitor log
Under UK GDPR, consent has to be freely given, specific, informed and as easy to withdraw as it was to give. A visitor log struggles with all of that:
- It isn't freely given. If refusing means you can't enter the building, the choice isn't a real one.
- It can't really be withdrawn. You can't stop recording someone who is already on site, and you'd still need the record if there were an incident.
- You'd process the data anyway. The ICO's guidance is that if you would still process the data without consent, asking for it is misleading.
What to use instead: legitimate interests or public task
The right basis depends on who you are. Your organisation, as the controller, decides which applies, and your privacy notice should say which.
- Companies, charities, care homes and independent schools: legitimate interests (Article 6(1)(f)). Keeping the site secure, safeguarding the people in it and knowing who is on the premises in an emergency are all genuine interests.
- Public authorities, such as councils, maintained schools and academies, and NHS bodies: public task (Article 6(1)(e)). UK GDPR doesn't let public authorities rely on legitimate interests for processing they do in carrying out their tasks, so a council notice that says "legitimate interests" gets the basis wrong in the same way "I consent" does.
If you rely on legitimate interests, do a short legitimate interests assessment, with three questions:
- Purpose: is there a genuine interest? Security, safeguarding and fire safety clearly are.
- Necessity: is each item you collect actually needed for it? This is where you justify a photo, or decide you don't need a vehicle registration.
- Balance: do visitors' interests override yours? Short retention, minimal fields and no hidden uses all help you here.
If you rely on public task, note which of your functions the visitor log supports, and apply the same necessity test: collect only what that function needs, and keep it only as long as it needs it.
Tell visitors, then record that you told them
Whatever the basis, visitors have a right to be told what happens to their details (Article 13): who you are, why you're collecting the data, the lawful basis, how long you keep it, and their rights. Two practical points make this stand up:
- Make the privacy notice its own visible block. A notice squeezed into a checkbox label is easy to argue was never really given.
- Ask for an acknowledgement, not consent. "I acknowledge I've read how my information is used" is accurate. Record when they ticked it and which version of the notice they saw, so you can prove it later.
Collect less to begin with
- Replace a free-text "reason for visit" with a short preset list. Free text is where sensitive details about other people creep in.
- Think hard before recording who the visitor is seeing. It adds personal data about staff, and the reason category often covers the need.
- If you take photos, use a live camera rather than uploaded images. Uploaded phone photos can carry location data.
- Set retention periods, and keep photos for less time than names.
How Visitor Book handles it
Visitor Book is built this way by default: a separate "What happens to this information" notice that states whichever basis applies to that customer, legitimate interests or public task, an acknowledgement checkbox that has to be ticked before sign-in, the time of acknowledgement and the notice version recorded with each visit, preset reasons, a live camera snapshot with no location metadata, and retention you control. Read the FAQs or talk to us.
This article is general information, not legal advice. Your own DPO or adviser should confirm the right lawful basis for your organisation.