GDPR Visitor Sign-In: What Your Log Must Do

A GDPR-compliant visitor sign-in does five things. It collects only the data you need. It tells visitors why at the point of entry. It keeps that data for a defined, limited time. It hides one visitor’s details from the next. And it lets you find, export or delete a person’s record when they ask. A paper book on a reception desk usually fails on at least three of these. A well-configured digital system can meet all five.

This guide is for operations, facilities and health and safety managers. It matters to US organizations too: if you host visitors from the EU or UK, or run a site there, the GDPR or UK GDPR applies to the way you log them. It is general information, not legal advice. For decisions about your own site, talk to your data protection officer or privacy counsel.

TL;DR

• Sign-in data is personal data. Name, company, contact details, vehicle plate and photo are all covered, and so is the time someone was on your site.
• Most organizations can rely on legitimate interests (security and safety) for the basic log. Health declarations or biometrics need a stricter basis.
• Show a short privacy notice at the kiosk or on the QR page: what you collect, why, who sees it, and when it is deleted.
• Set a retention period, write it down and enforce it. The GDPR does not fix a number for you.
• An open paper book fails the test, because every visitor can read everyone who signed in before them.

Table of Contents

• Why a visitor log counts as personal data
• Choosing a lawful basis for sign-in
• Special category data: health declarations and biometrics
• The privacy notice at the point of entry
• How long can you keep visitor records?
• Responding to access and deletion requests
• Why the paper visitor book fails
• What a GDPR-ready sign-in system should do
• Our view: compliance is something you operate
• Setting up a GDPR-aware sign-in: a step-by-step plan
• Sector notes
• Try it on your own front desk
• FAQ
• Sources

Why a visitor log counts as personal data

The GDPR defines personal data as anything relating to an identifiable person. A visitor log is made of exactly that: who someone is, who they work for, where they were and when. The full text of the regulation applies to it whether the log is a notebook, a spreadsheet or software.

That has three practical consequences:

1. You are the controller of the data. You decide what is collected and why, so you carry the responsibility.
2. Any vendor that stores the log for you is a processor. You need a data processing agreement with them.
3. The people in the log have rights over it, including access and erasure.

The same applies to contractors and employees on multi-site rosters. The rules are not only about guests in the lobby.

Choosing a lawful basis for sign-in

Every processing activity needs one of the lawful bases in Article 6. For a standard visitor log, two are realistic.

Legitimate interests (Article 6(1)(f)). This is the common choice for security and safety records. The UK regulator itself uses it: the ICO’s notice for visitors to its own office explains that it asks visitors to sign in and out, may create a badge, and relies on legitimate interests for security and safety. Legitimate interests requires a short balancing test: is the purpose real, is the data necessary for it, and do the visitor’s rights outweigh it? Write the answer down.

Legal obligation (Article 6(1)©). Some sites must know who is on the premises, for example under health and safety or site-access rules. Where a law requires the record, this is the cleaner basis. Check which law and cite it in your notice.

Consent is rarely the right basis for the basic log. Consent has to be freely given, specific, informed and unambiguous, and a visitor who must tick a box to get through the door is not freely choosing. Use consent for genuinely optional things, such as a marketing opt-in or a photo used beyond the badge.

Special category data: health declarations and biometrics

Many sites ask visitors extra questions. Are you carrying symptoms? Do you have a condition we should know about for evacuation? Do you hold a valid medical certificate? Those answers are health data, which Article 9 classes as special category data. Fingerprint or face scanners fall in the same group. The EDPB explains that this kind of data needs a more stringent lawful basis, often explicit consent under Article 9(2)(a), and should be collected only when strictly necessary and proportionate.

In practice:

• Ask for health information only when the site genuinely needs it, such as a clinical area, a food production floor or a construction site with medical fitness rules.
• Prefer a yes/no declaration to free-text answers. “I confirm I have no symptoms” stores far less than a description of a condition.
• Do not use fingerprints or face recognition for ordinary visitors. A QR code or a name on a screen does the job without the risk.
• Keep these answers out of the general log view that reception staff see.

If you want to know who may need help in an evacuation, ask an optional question and explain it, rather than asking everyone about their health.

The privacy notice at the point of entry

The GDPR requires transparency, and the ICO’s guidance is clear that a notice should say what you collect, why, who it is shared with and how long it is kept. For a visitor sign-in that notice has to be where the visitor actually sees it: on the kiosk screen, on the page the QR code opens, or on a sign beside the desk. A link buried in your website footer is not enough.

A workable notice for a sign-in covers:

Keep it to a few lines, with a link to the full policy. If a third-party system handles the data, it should be able to explain how it protects it. Reading a vendor’s own security and data handling page is a useful model for what clear disclosure looks like, even outside the visitor management world.

How long can you keep visitor records?

The GDPR does not set a number. Article 5(1)(e) says data must be kept no longer than necessary for its purpose, so you pick a period, justify it and enforce it. A guide to GDPR retention periods makes the same point: regulators expect you to be able to demonstrate the schedule, not just declare it.

There is no official figure for visitor logs. For a comparable security record, the EDPB’s video surveillance guidelines say data should normally be erased after a few days, typically within 72 hours, unless there is a documented reason to keep it longer. Those guidelines are about cameras, not sign-in books, so treat them as a signal of how strictly regulators view “just in case” retention, not as a rule for your log.

A sensible way to set the period:

1. List why you keep the record: emergency roll call, incident investigation, insurance, contractor compliance.
2. Find the longest period any of those genuinely needs. An emergency roll call needs the record only while the person is on site. An incident investigation may need weeks or months.
3. Check whether a law or contract fixes a minimum, for example for construction site records or regulated sites.
4. Set the period, record the reason and have the system delete or anonymize automatically.

Manual deletion is where most organizations slip. If a person has to remember to tear pages out or clear a spreadsheet, it will not happen on schedule.

Responding to access and deletion requests

Visitors have a right of access under Article 15 and a right to erasure under Article 17. Erasure applies when data is no longer necessary for its purpose, unless a legal obligation requires you to keep it. You generally have one month to respond, a deadline practitioner guidance on visitor data also highlights.

Before a request arrives, make sure you can answer three questions:

• Can you search the log by a person’s name or email in minutes?
• Can you export that person’s records in a readable form?
• Can you delete them without breaking the audit trail for everyone else?

A paper book fails all three. A digital log that is searchable and exportable passes the first two by design. For the third, check how deletion works in the tool you choose.

One point trips up many teams. Deleting a record on request does not always apply if you still have a valid reason to keep it, such as an open safety incident. Document that reasoning and tell the person.

Why the paper visitor book fails

The classic sign-in book was never designed for privacy. Look at one on a reception desk and you will see:

• Every previous visitor’s name, company and sometimes phone number, visible to the next person in line.
• No retention control. Full books sit in drawers for years.
• No way to search for one person without reading through everything.
• Illegible entries, which makes the record useless in an emergency.

Some organizations move to a “one-visitor-per-slip” or peel-off book, which solves the visibility problem but not the retention or searchability problems. A digital system solves all of them if it is set up well.

What a GDPR-ready sign-in system should do

No software is compliant on its own. Compliance depends on how you configure it and what you do around it. The best tool still needs a notice, a retention rule and a trained team. With that said, here is what to look for:

Security of the admin side matters as much as the kiosk. A visitor log protected by a weak shared password is a breach waiting to happen, so insist on unique logins and review basic password security practice with whoever administers the system. If your reception also runs web meetings or remote check-in tools, the same applies there: video conferencing security controls are worth reviewing for the same reason.

Our view: compliance is something you operate

We build visitor management software at EntryWatch, and we see the same misunderstanding often. Teams buy a system and assume they are now compliant. They are not. Compliance is a way of running your front door.

Three things matter more than any feature list:

• Decide what you need before you collect it. If a field does not serve security, safety or a legal duty, leave it off the form. Less data means less to protect, less to delete and less to hand over in a request.
• Keep the live register useful and short-lived. The reason to log arrivals is to know who is on site right now, and to run an accurate roll call in an emergency. That need ends when the person leaves. Long-term history should be kept only for a stated reason.
• Make privacy visible to the visitor. A clear notice on the kiosk builds trust faster than a long policy no one reads.

EntryWatch is built around these needs: contactless sign-in by kiosk or QR code, an auditable real-time record of entries, automatic emergency roll calls, and configurable digital forms for items like health declarations, NDAs and site rules. These give you the tools to follow the principles above. The decisions about notice wording, lawful basis and retention remain yours, and we would rather say so than imply a button can make you compliant.

— Flipmind

Setting up a GDPR-aware sign-in: a step-by-step plan

1. Map your visitors. Guests, contractors, delivery drivers, employees at other sites. Each group may need different fields.
2. Choose the lawful basis for each group and note it. Do a short legitimate interests assessment for the basic log.
3. Trim the form. Name, company, host and time are usually enough. Add vehicle details only where there is parking control. Add health questions only where a rule requires them.
4. Write the notice and place it on the kiosk, QR landing page and invitation emails.
5. Set retention and automate deletion. Record the reasoning.
6. Limit access. Reception sees today’s arrivals. Only a small group sees history.
7. Sign a processing agreement with any vendor that stores the data.
8. Test a rights request. Pick a name, find the record, export it, and time how long that takes.
9. Train the team. Reception and security staff should know who to send a request to and that the one-month clock starts on receipt.
10. Review once a year, or when you add a new site, form or integration.

Sector notes

Different sites weigh these rules differently.

• Healthcare and education: visitor records may be tied to safeguarding as well as security, which can justify longer or stricter handling. See our page on sign-in for public sector and education.
• Construction and manufacturing: contractor inductions, certifications and site rules matter, and some records have legal minimum retention. See site sign-in for construction and manufacturing.
• Data centres: strict access logs are normal, so the balance leans toward more detailed records, with tight access controls. See visitor management for data centres.
• Law and accounting firms: visitor names can reveal client relationships, so confidentiality in the log matters as much as retention. See visitor management for professional firms.
• Events and venues: large volumes and one-off attendees make clear notices and fast deletion especially important. See visitor and event check-in for venues.

Try it on your own front desk

EntryWatch replaces the paper book with a self-service kiosk or QR check-in, a live record of who is on site, host notifications and automatic emergency roll calls. You can add digital forms for NDAs, health declarations and site rules, and print badges. Every complete feature is free for founding customers until 2027, so you can test the whole setup against the checklist above before you commit. Read about the visitor management system or see the founding plan. If you need hardware, we also offer kiosk stands and badge printers.

FAQ

Does the GDPR apply to a US company’s visitor log?

It can. The GDPR applies to organizations established in the EU, and in some cases to those that offer goods or services to people there. If your US office logs visitors, the GDPR is usually not the rule that applies to them, though state privacy laws may be. If you run a site in the EU or UK, the log is covered. Ask counsel which laws apply to each location.

Do I need consent to sign visitors in?

Usually not. For a basic security and safety log, most organizations rely on legitimate interests or a legal obligation, not consent. Consent becomes relevant for optional extras and for special category data such as health declarations, where explicit consent is often the basis. Record whichever basis you choose.

How long should I keep visitor sign-in records?

Only as long as you need them for the stated purpose. The GDPR sets no fixed number, so you decide, document the reason and delete automatically. Roll-call data may only be needed while the visitor is on site, while incident records may justify longer.

What should I do if a visitor asks to see or delete their data?

Verify who they are, search the log, and reply within one month. Provide a copy of their records for an access request. For erasure, delete the data unless you still have a legal or safety reason to keep it, and explain that reason if so.

Is a digital sign-in automatically GDPR compliant?

No. Software can make compliance easier through notices, retention settings and searchable records, but you remain responsible for the lawful basis, the notice, the processor agreement and the training of your team.

Sources

• GDPR full text, EUR-Lex
• ICO: Visitors to the office privacy notice
• ICO: Privacy notice guidance
• EDPB: Guidelines on video surveillance
• EDPB and Commission joint guidelines (special category data)
• Secure Privacy: GDPR data retention periods
• Visitor Data Privacy and Retention Best Practices
• Security and data handling example
• Password security guidance
• Video conferencing security controls

Recommended

• 13-Section Visitor Policy Template: Ready to Use for HR and Facilities
• Visitor Journey Mapping: Link Sign In to Evacuation for Site Managers
• iPad Visitor Sign In: Six Point Setup to Deploy Fast