Skip to content
LobbyExpress
Search

Guide

GDPR and visitor data: a practical guide for reception

What to collect at sign-in, which lawful basis fits, how to show a privacy notice on a kiosk, how long to keep records, and how to handle photos, ID scans and subject access requests.

By LobbyExpress Editorial

Every visitor record is personal data. A name, a company, a car registration, a photo on a badge, the time someone arrived and who they came to see: under the UK GDPR and the EU GDPR, all of it is information about an identifiable person, and all of it comes with obligations.

Reception teams rarely think of themselves as running a data processing operation, but that is what a sign-in screen is. The good news is that the obligations are manageable if you settle a handful of decisions before the system goes live, rather than after the first awkward question from a visitor.

This guide walks through those decisions. It is not legal advice: your data protection officer, or whoever holds that responsibility, should sign off the choices you make.

Start with purpose, then decide the fields

The data minimisation principle says you should collect what is adequate, relevant and limited to what is necessary for your purpose. So the first job is to write down the purposes. For most organisations they are some combination of: knowing who is on site in an emergency, notifying the host, controlling access to restricted areas, keeping a record for security investigations, and meeting health and safety duties for contractors.

Then go through every field on the sign-in screen and ask which purpose it serves. Fields that serve none should go. Fields that serve a purpose only for some visitor types should appear only for those types.

Sorting sign-in fields by how much justification they needThree columns of typical sign-in fields. Usually justified: name, organisation, host, arrival and departure time. Justify per visitor type: phone number, vehicle registration, photo on badge, signed site rules. Avoid by default: copies of ID documents, date of birth, health questions, home address.Usually justifiedServes safety and hostingJustify per visitor typeOnly where a purpose needs itAvoid by defaultNeeds a strong, written caseFull nameOrganisationPerson being visitedArrival and departure timeMobile numberVehicle registrationPhoto on the badgeSigned site rules or NDAStored copy of ID documentDate of birthHealth questionsHome addressExample grouping. Your own purposes decide which column a field belongs in.
An example of sorting fields. The same field can move columns: a vehicle registration is justified at a site with a managed car park and hard to justify at one without.

Pay particular attention to anything that could reveal special category data. A health questionnaire, a question about dietary needs or a request for accessibility requirements can all touch on health or religious belief, which need an additional condition under the GDPR and more careful handling. Often the right answer is to ask the host to handle such needs directly, rather than storing them in the visitor log.

Choose and record a lawful basis

You need a lawful basis for each purpose. For visitor sign-in, two usually fit.

Legitimate interests covers processing that is necessary for a genuine interest of your organisation, such as security and knowing who is on site, provided it is balanced against the visitor’s interests and reasonable expectations. If you rely on it, record a legitimate interests assessment: the interest, why the processing is necessary for it, and why it does not override the visitor’s rights.

Legal obligation can apply where the law requires you to process the data, for example parts of your health and safety duties. Be specific about which obligation, rather than citing it generally.

Consent is rarely a good fit. Consent must be freely given and can be withdrawn at any time. If signing in is a condition of entering the building, the visitor has no real choice, and you could not stop processing if they withdrew. Public bodies, including schools, may rely on public task for some of their processing; their DPO will advise.

Put the privacy notice where the data is collected

Visitors are entitled to know, at the time you collect their data, who you are, what you are collecting it for, your lawful basis, how long you keep it, who you share it with and what rights they have. A notice pinned to the wall behind reception does not do that well.

A layered notice works best on a kiosk: a short summary on the sign-in screen itself, and the full notice one tap or one QR code scan away.

A layered privacy notice on a sign-in kioskAn example sign-in screen with annotations. The first layer, shown on the screen, says who is collecting the data, why, and how long it is kept. A link and QR code lead to the second layer, the full privacy notice, which covers the lawful basis, recipients, rights and contact details.Your nameWho are you visiting?Sign inLAYER ONE, ON SCREENWho is collecting your dataWhat it is used forHow long it is keptLAYER TWO, ONE TAP OR SCAN AWAYLawful basis, sharing, rights, contactsShort enough to readwhile standing at a deskTwo or three sentences above thesign-in button, in plain English,with the full notice linked.
An illustrative layered notice. The first layer must be visible before the visitor presses sign in; the second must be reachable without asking the receptionist.

Keep a printed copy of the full notice at reception for visitors who cannot or will not scan a code, and make sure the same information is in the pre-registration email for visitors who are invited in advance.

Photos and ID scans

Badge photos are personal data, and a photo of a face is not automatically biometric data. It becomes biometric data under the GDPR when it is processed through specific technical means to uniquely identify someone, such as facial recognition matching. If your system does that, or plans to, talk to your DPO first: you will need a condition for special category data and very likely a data protection impact assessment.

Scanning identity documents raises a separate question. Often the purpose is to confirm that the person in front of you is who they say they are, which can be done by looking at the document and recording that the check happened. Storing an image of a passport or driving licence creates a store of high-value data that you then have to protect, retain and delete. If you do need to keep an image, record why, restrict who can see it, and give it the shortest retention period you can justify.

Set a retention schedule the system can enforce

The GDPR does not set a retention period for visitor records. Storage limitation says you must not keep personal data for longer than you need it for your purposes, which means you have to decide, write it down and justify it. Different record types usually justify different periods.

Illustrative retention schedule by record typeAn illustrative chart showing how long five types of visitor record might be kept. An ID document image is checked and not stored. A delivery driver log is kept for a short period. A general visitor log is kept for a short to medium period. A contractor record is kept for the length of the engagement plus a defined period. Records linked to an incident are held under the incident policy. Periods are examples only.ILLUSTRATIVEAT CHECKWEEKSMONTHSLONGERID document imageDelivery driver logGeneral visitor logContractor recordIncident-linked recordChecked, not storedShort, fixed periodSet by security needLength of engagement plus a set periodHeld under the incident or legal hold policy, then reviewedExample only. Agree actual periods with your DPO and record the reasoning.
An illustrative schedule, not a recommendation. The point is the shape: different record types justify different periods, and only records tied to a specific incident should be held outside the normal schedule.

Two practical checks matter more than the exact numbers. First, confirm the system can apply different retention periods to different visitor types, and that deletion is automatic rather than a task someone has to remember. Second, check what happens to backups, exports and badge-printer queues, which can hold copies long after the main record has gone.

Subject access and other rights

Visitors can ask for a copy of the data you hold about them. Under the UK GDPR and the EU GDPR, you normally have one month to respond, extendable in limited circumstances, and you usually cannot charge a fee.

Handling a visitor’s subject access requestA five-step process from left to right: log the request and the date received, confirm the requester’s identity, search the visitor system and related records, remove other people’s data, and respond. A bracket beneath shows that the whole process normally needs to finish within one month.Log itVerifySearchRedactRespondRecord the dateit arrivedConfirm who isaskingVMS, exports,badges, emailsRemove otherpeople’s dataCopy pluskey detailsNormally one month
The clock usually starts when the request is received, not when it reaches the right person. Reception staff need to know how to recognise a request and where to send it.

A request can arrive at the front desk, verbally or in writing, and it does not need to use any particular wording. Make sure reception knows to pass it on the same day. The search should include anywhere visitor data ends up: the visitor system itself, exported reports, email notifications to hosts and any paper fallback records. Visitor logs often include other people’s details, which may need removing before disclosure.

Visitors also have other rights, including rectification and, in some circumstances, erasure. The right to erasure is not absolute; whether it applies depends on your lawful basis and purpose. Your DPO should decide each case.

Do not forget the supplier

If you use a hosted visitor system, the supplier is very likely acting as your processor. You need a written contract that meets the GDPR’s processor requirements, a list of their sub-processors, and clarity on where data is stored and whether it leaves the UK or EU. Add the visitor system to your record of processing activities, and consider whether a data protection impact assessment is needed, particularly if you use ID scanning, watchlist screening or facial matching.

Where to go next

If you are still running a paper book, read the real cost of the paper sign-in book, which covers the privacy exposure of an open log. If you are about to buy, fold these decisions into your requirements using how to write a visitor management RFP, and use the four kinds of visitor management product to understand what you are comparing. You can then filter the directory by cloud deployment or browse the full directory.