Visitor Management Security Guide

Visitors are the one group an organisation deliberately lets through its perimeter without knowing them well, and the visitor management system that records them is itself an identity store full of personal data, photos and integration credentials. This guide covers the controls around visitors from invitation to departure: pre-registration, identity checks at arrival, temporary credentials, escorts, contractor and delivery handling, and the security and privacy of the visitor system itself, including its integrations with access control, directories and guest Wi-Fi. It is written for site security leads, facilities managers, identity teams and privacy officers who own or are reviewing a visitor process. The rules a policy should state are in the Physical and Environmental Security Policy Template; this page explains how to design and run them.

Key takeaways

Pre-registration is the main control. A visit that a named host books in advance can be checked, approved and given a time-limited credential; walk-ins should be the exception with a stricter path.
Check identity once, properly, at the right point. Compare a photo ID with the person at reception, record that it was checked, and avoid copying the whole document unless a documented need exists.
Temporary credentials must expire on their own. Visitor badges and access cards should be visibly different, limited to the zones and hours of the visit, and deactivated automatically at checkout or end of day.
Escorting is a duty, not a courtesy. Define where escort is required, how many visitors one escort may manage, and what the host does if a visitor is unaccounted for.
The visitor system is in scope for identity and privacy controls. It holds personal data, often photos and ID images, and service credentials to access control and directories; apply data minimisation, retention, SSO and secrets management.

The visitor journey and where it goes wrong

Every visit passes through the same stages. Each has a typical weakness that intruders, social engineers and opportunists use.

Stage	Control objective	Typical weakness
Invitation and pre-registration	A named host vouches for the visit, purpose and areas in advance	Reception accepts anyone who names an employee; hosts not notified
Arrival and identity check	Person matches a pre-registered record and a photo ID	No ID check, or a check that cannot be evidenced later
Credential issue	Time-limited, zone-limited, visibly temporary credential	Reusable paper stickers; access cards with no expiry; staff-style badges
Briefing and escort	Visitor knows the rules; host maintains control in non-public areas	Visitors left alone in meeting rooms with network ports and unlocked screens
Departure	Credential returned or deactivated; sign-out recorded	Cards not collected and still active; no sign-out, so evacuation lists are wrong
Records and data	Minimal, protected, deleted on schedule	Years of visitor names, photos and ID scans in an unmanaged cloud tenant

Pre-registration and approval

Host-initiated invitations: visits are booked by an employee with an SSO account in the visitor system, stating visitor name, organisation, date, purpose, areas needed and host. The host owns the visitor for the whole visit.
Approval by zone: visits to public and general office areas need only the host. Visits to restricted areas (comms rooms, laboratories, data halls) need the area owner's approval, recorded in the system.
Advance notice when risk is raised: ProtectUK's tactic DB3 sets a 24-hour notice requirement for visitors and contractors when the threat level is raised or after an incident, collecting identity, employment status, nationality where applicable, the person visited, purpose, and sign-in and sign-out times, so that screening, verification and pass preparation can happen before arrival. Use it as an escalation mode that the site can switch on.
Screening where justified: some sites check visitors against a denied-entry list held by security (former employees with access revoked for cause, people subject to court orders). Keep any such list small, lawful, reviewed and restricted to security staff.
Walk-ins: a visitor who arrives without a booking waits in reception while the host is contacted and confirms in the system. No host confirmation, no entry.

Identity checks at arrival

The purpose of the check is to confirm that the person in front of reception is the person the host invited. ProtectUK's access control guidance says passes must be signed for once the identity of the recipient has been confirmed.

Check level	What reception does	What is recorded	When to use
Basic	Match name to pre-registration; host collects from reception	Name, host, times	Public and low-risk office areas
Standard	Visual comparison of a government photo ID with the person	That ID was checked, document type, staff member who checked	General office and most contractor visits
Enhanced	Photo ID check plus pre-arrival verification (employer confirmation, contractor company booking reference)	As standard, plus verification reference	Restricted zones, raised threat level, high-value sites

Scanning and storing an image of every visitor's passport or driving licence feels thorough, but it creates a store of identity documents that is valuable to fraudsters and hard to justify under data minimisation. GDPR Article 5(1)(c) requires data to be limited to what is necessary, and NIST SP 800-53 PE-8(3) asks organisations to limit personally identifiable information in visitor access records to the elements identified in a privacy risk assessment. Recording "photo ID checked, type, by whom" usually meets the security need. See the Data Minimisation guide.

Temporary credentials and badges

Visibly different: visitor badges use a distinct colour or design from staff badges, show the visitor's name, host, date and, where used, a photo printed at reception. Contractors may have their own design.
Display and no transfer: visitors wear the badge visibly at all times and may not lend it. Staff challenge anyone in a non-public area without a visible badge.
Expiry built in: printed badges carry the date and, where available, use self-expiring materials. Access cards issued to visitors are encoded only for the zones and hours of the visit and are deactivated at sign-out or at a fixed time that day, whichever comes first. ProtectUK says temporary passes issued out of hours must be of limited duration.
Controlled issue: only reception or security issues credentials, from a counted stock. Reconcile issued against returned cards daily and deactivate any not returned.
Card technology: visitor cards should use the same secure credential technology as staff cards. If visitor cards are an older, easily copied format, a lost card becomes a cloneable key. See the Legacy Access Card Migration Guide.

Escorts, briefings and behaviour on site

NIST SP 800-53 PE-3 requires organisations to escort visitors and control visitor activity in the circumstances they define. Make those circumstances explicit:

Escort zones: escort required outside public areas and reception, or only in restricted zones, depending on site risk. Write it into the zone map.
Escort ratio: set a maximum number of visitors per escort. The US Department of Energy headquarters procedure, for example, sets no more than five visitors per escort in standard areas and three per cleared escort in security areas.
Visual control: the escort keeps the visitor in sight in escorted areas, arranges another escort if the group splits, and stops visitors from overhearing sensitive discussions or seeing screens.
Briefing: visitors receive a short safety and security briefing at sign-in: badge display, escort rules, photography rules, evacuation routes and assembly points.
Meeting rooms: rooms used by visitors should have network ports disabled or on a guest VLAN, no unattended equipment, and locked screens. A visitor alone in a meeting room is an unescorted visitor.
Missing visitor: if a visitor is unaccounted for, the host informs security immediately, security checks access logs and CCTV, and the visitor credential is disabled until they are found.

Tailgating by visitors and by people posing as visitors is the most common way escort rules fail. See the Tailgating and Piggybacking Guide.

Contractors, deliveries and repeat visitors

Group	Recommended handling	Specific risk
One-off contractor	Pre-registered by the commissioning manager with work order reference; standard ID check; escort or permit-to-work in restricted areas	Contractor uniform used as cover by an intruder
Long-term contractor	Managed as a worker identity with sponsor, end date and periodic review, not as a daily visitor	Daily visitor passes reused for months with no review
Delivery and courier	Received at reception or a goods-in point; no entry beyond it	Delivery pretext used to reach floors or loading docks
Frequent visitor (auditor, partner)	Pre-approved visitor profile with expiry; ID still checked each visit	Profile outlives the relationship
Job candidate	Host collects from reception; interview rooms in public zone	Candidate left waiting in office areas

Long-term contractors belong in the identity lifecycle, with joiner, mover and leaver processes. See the Contractor Identity Lifecycle Guide.

Where identity fits: the visitor system as an identity store

A modern visitor management system is a SaaS application with users (hosts, reception, security, admins), a database of external people, and integrations that can create physical and network access. Treat it like any other identity system.

Workforce access: hosts and reception sign in through SSO with MFA. Admin roles are few, named and reviewed. Leavers lose access through the identity provider, not by manual deletion.
Integration credentials: connections to the access control system (to issue cards), the directory (to look up hosts), guest Wi-Fi (to issue vouchers), messaging (to notify hosts) and HR use API keys, OAuth clients or service accounts. These non-human identities can often create access cards or read the staff directory. Store them in a secrets manager, scope them to the minimum, rotate them and assign an owner. See the API Key Management Guide.
Access control write path: if the visitor system can encode cards or grant door access, restrict which access levels it may assign, so a compromised visitor tenant cannot grant entry to the data hall.
Kiosks: self-service sign-in tablets are shared devices in a public space. Lock them to the visitor app, manage them through device management, remove local admin access, prevent other visitors' names from appearing in auto-complete or lists, and physically secure them.
Guest network access: vouchers issued at sign-in should expire with the visit and land on an isolated guest network.

Visitor data: privacy and retention

Visitor records are personal data, and photos, ID images and health or dietary declarations add sensitivity. Design the data set before configuring the system.

Purpose: security of the site, emergency evacuation roll calls, and evidence for investigations. ProtectUK's tactic DB3 notes that sign-in and sign-out records can be crucial in an emergency evacuation, and that records of visitor security decisions provide evidence to investigations and help in defending legal claims. GDPR Article 5(1)(b) purpose limitation means the same data should not drift into marketing.
Minimum fields: name, organisation, host, purpose, times, ID-checked flag, and badge number. Collect photos or document images only where the site's risk assessment justifies them.
Retention: set a fixed period (many organisations choose around 12 months, matching the policy template default) and enforce automatic deletion, in line with Article 5(1)(e) storage limitation. Hold records longer only under a documented legal hold.
Visibility: sign-in screens and paper books must not expose earlier visitors' names and companies to the next person.
Vendor terms: a SaaS visitor platform is a processor; confirm hosting location, sub-processors, encryption and breach notification terms. See the GDPR Article 28 Processor Guide.
Biometrics: face recognition sign-in turns the visitor database into a biometric store with stricter legal duties. Avoid it unless there is a clear need, and see the Biometric Privacy Laws Map.

How to implement

Map sites and zones. For each site, record public areas, escort zones and restricted zones, and who approves visits to each.
Define the data set and retention. Agree minimum fields, ID check levels and retention with privacy and legal, and record it in a DPIA or privacy assessment where required.
Configure the system securely. SSO and MFA for all staff users, role-based access, integration credentials in a secrets manager, kiosk lockdown, and automatic deletion.
Integrate access control with limits. Allow the visitor system to issue only defined visitor access levels with automatic expiry; test that an expired visitor card is refused.
Pilot at one site. Run for a month with reception, hosts and security. Measure walk-in rate, check-in time and unreturned credentials.
Train hosts and reception. Cover host duties, challenge culture, escort rules and what to do with a missing visitor. ProtectUK recommends that staff feel able to challenge anyone without the correct pass.
Roll out by site with a fallback. Keep a paper process and a printed list of expected visitors for system outages, and record what happened during any outage.
Test. Run authorised social engineering tests at reception and tailgating tests at escort zone doors, and review results with the site lead.

Detection and measurement

Review visitor records: NIST SP 800-53 PE-8 requires visitor access records to be maintained, reviewed at a defined frequency and anomalies reported. Look for visits outside hours, repeated visits by the same person to different hosts, visitor cards used at doors outside their access level, and credentials still active after sign-out.
Correlate with access control: every visitor card event should match an open visit. Card use with no open visit is an alert.
Audit the system: admin role changes, bulk exports of visitor data, new API keys and integration changes.

Metrics:

Percentage of visits pre-registered by a host (target: above 90 percent for office sites).
Visitor credentials not returned or not deactivated by end of day (target: zero active).
Percentage of visits to restricted zones with recorded area owner approval.
Pass rate of reception and tailgating tests.
Visitor records older than the retention period still held (target: zero).

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	PE-8 Visitor Access Records; PE-8(1) Automated Records Maintenance and Review; PE-8(3) Limit Personally Identifiable Information Elements	Visitor logs, automated review, minimal data
NIST SP 800-53 Rev. 5	PE-2 Physical Access Authorizations; PE-3 Physical Access Control	Authorisation, credential issue, escorting visitors
NIST SP 800-53 Rev. 5	SI-12 Information Management and Retention	Visitor data retention
NIST CSF 2.0	PR.AA-06	Physical access managed, monitored and enforced
ISO/IEC 27001:2022 Annex A	7.2 Physical entry; 5.34 Privacy and protection of PII	Entry controls and visitor data
GDPR	Article 5(1)(b), (c), (e), (f)	Purpose limitation, data minimisation, storage limitation, integrity and confidentiality

Common failure patterns

Name-dropping works: reception admits anyone who names an employee, without host confirmation.
Cards that never expire: visitor access cards left active after the visit, sometimes for months, and not reconciled.
Visitor book as an open directory: a paper book or kiosk list that shows every earlier visitor's name, company and host to the next arrival.
ID scans kept forever: images of passports and licences collected by default and never deleted.
Integration keys with broad rights: a visitor platform API key that can assign any access level or read the full staff directory, owned by nobody.
Contractors as permanent visitors: long-term contractors signed in daily as visitors, never entering the identity lifecycle or access reviews.

Practitioner checklist

Require host pre-registration for all visits, with area owner approval for restricted zones.
Define ID check levels and record that a check was made rather than copying documents.
Issue visibly different, zone-limited credentials that expire automatically and reconcile them daily.
Set escort zones, escort ratios and a missing visitor procedure.
Put the visitor system behind SSO and MFA, with named admins and reviewed roles.
Store integration credentials in a secrets manager, scope them tightly and assign owners.
Limit the visitor system to defined visitor access levels in the access control system.
Minimise visitor data fields and enforce automatic deletion at the end of the retention period.
Review visitor records and card events for anomalies on a fixed schedule.
Test reception and escort controls with authorised social engineering exercises.

Visitor Management Security: Controls for Checks, Escorts and Visitor Data