A visitor management system only reduces risk after someone owns the rules it enforces. Buying the platform answers which product to deploy. It does not decide who may enter a lab, how long a contractor keeps a badge, or which record an auditor can trust six months later. Those decisions sit with facilities, security, and IT, and they drift when each site invents its own version.
This guide is for Directors who already have a system, or who have chosen one, and need it to operate the same way at every regulated location. It covers policy ownership, site exceptions, contractor access, and the evidence those controls leave behind. Product scoring belongs in the guide to evaluating a visitor management system, not here.
Schedule a Security Risk Assessment with BCS365
Summary: Name one policy owner, one operations owner per site, and one technical owner. Split those roles and the system becomes a reception tool with no one accountable for the record.
Facilities usually runs the lobby. Security usually decides who is allowed past it. IT usually connects the platform to identity, the network, and the access-control system. If all three "own" the visitor management system, none of them does. A workable model gives each a job that the others cannot quietly absorb.
The policy owner is typically the head of corporate security or a facilities-security lead. That person approves visitor classes, escort rules, retention periods, and any exception that lasts more than a single visit. The site operations owner, often the facility manager, runs the local workflow and reports breaks. The technical owner, inside IT or a managed partner, keeps integrations, identities, and logging healthy.
Write the split down. A one-page RACI is enough. It should name who can change a global rule, who can approve a site exception, and who restores a failed integration. Without those names, a helpful receptionist will waive a check "just this once," and the waiver will become the process.
Governance starts when three named owners share one rule set, not when the kiosk goes live.
Summary: Define visitor classes, the assurance each class requires, where each class may go, and how long the record is kept. Leave any of those blank and every site will fill the blank differently.
Start with classes, not screens. A courier, an escorted guest, an interviewer, and a contractor working inside a controlled lab are not the same risk. For each class, state the host, the approval, the identity check, the escort rule, the areas that stay closed, and the maximum visit window. Put the same statement in the platform and in the written procedure so a configuration change cannot outrun the policy.
NIST SP 800-53 gives a useful control frame even though it is not a lobby manual. The Physical and Environmental Protection family covers physical access authorizations, access control for transmission and output, monitoring, and visitor access records. Treat PE-2 and PE-8 as the questions your policy must answer: who is authorized, and is the visit recorded well enough to reconstruct it later. Read the control catalog in NIST SP 800-53 Rev. 5 and map your classes to it. Do not paste the catalog into the lobby script.
| Visitor class. | Approval before arrival. | Assurance at the door. | Default access. |
|---|---|---|---|
| Escorted guest. | Host confirms the window. | Name, host, and photo badge. | Lobby and the named meeting room. |
| Courier or delivery. | Dock or reception schedule. | Company and host match. | Dock or mail point only. |
| Interview candidate. | Hiring manager plus reception. | Identity match to the invite. | Escorted path with no system access. |
| Contractor or vendor. | Sponsor, security, and the site lead. | Identity, training, and an active sponsor. | Named zones with a time-bound badge. |
| Regulated-area visitor. | Security plus the area owner. | Identity, escort, and a safety check. | An escort is required for the whole visit. |
Retention is part of the same policy. Keep a visitor record only as long as an investigation, a safety review, or a contractual duty needs it, then delete it on a schedule. A photograph, a government ID image, and a watchlist result need a shorter, named purpose than a name and a check-in time. If legal has not signed the schedule, do not store ID images just because the feature is on.
A policy that names the class, the check, the zone, and the retention period is enforceable. A feature list is not.
Review the access-control design that supports your visitor policy
Summary: Allow local differences only through a written exception with an owner, an expiry, and a review. Unwritten local habits are how a global standard disappears.
Multi-site organizations do have real differences. A manufacturing plant escorts every contractor. A downtown office may allow a known vendor to a mailroom unescorted. A UK site and a US site may face different notice rules for personal data. Those differences are legitimate only when someone approved them.
Use a short exception record. It should name the site, the rule being varied, the reason, the compensating control, the approver, and the date the exception dies. A 90-day expiry is a practical default. On that date the exception ends unless the policy owner renews it. Standing exceptions with no end date are how a pilot lobby becomes a permanent hole.
Configure the platform to match the record. If the written rule says a lab visitor needs an escort, the badge should not open the lab door. If the written rule says a courier stops at the dock, the kiosk should not offer a building-wide host search. CISA's physical security guidance treats facility protection as layered controls, not a single device at the front desk. The same idea applies here: the CISA physical security resources are a planning frame, and the visitor management system is one layer inside it.
Review exceptions in one monthly meeting, not in side chats. The policy owner reads the list. Site leads defend anything they want to keep. IT confirms the configuration still matches the paper. Anything nobody defends gets closed that day. The same meeting should confirm that lobby hardware on the intercom and visitor management service still follows the written rule, rather than a local workaround.
An exception without an expiry is a second policy, and the second policy is the one people follow.
Summary: A contractor badge is a temporary authorization tied to a sponsor, a scope, and an end date. When any of those changes, the badge and the visitor record must change the same day.
Contractors create more visitor risk than guests because they return, learn the building, and often need doors that guests never see. The failure mode is stale access. The project ends, the sponsor leaves, and the badge still works on Monday.
Bind every contractor record to four facts: the sponsoring employee, the statement of work or ticket, the zones required, and the last date those zones are needed. The visitor management system should refuse a check-in when the sponsor is inactive or the end date has passed. It should also refuse a badge that grants a zone the sponsor is not allowed to approve.
Run a weekly reconciliation, not an annual cleanup. Compare active contractor badges in the access-control system with active visitor records. Investigate any badge with no matching record, and any record whose sponsor no longer works at that site. Door hardware and credential design are covered in the planning guide for commercial access control systems. This reconciliation is the operating habit that keeps that design honest.
Contractor access is safe only while the sponsor, the scope, and the end date are still true.
Summary: An auditor, an investigator, or a safety lead should be able to reconstruct one visit without asking the receptionist what "usually" happens.
Store the minimum that answers a later question. For each visit, keep the class, the host, the approver, the arrival and departure times, the badge identifier, the zones the badge could open, and any exception that applied. Keep the identity evidence only when the class requires it, and keep it under the retention rule already signed by legal and privacy.
Separate operational logs from the story people tell about them. A kiosk event that says "checked in" is not proof of escort. Proof of escort is a named escort, a zone list that required one, and a departure event. Proof of a denied visit is the rule that fired, the person who saw the denial, and whether an override was used. Overrides deserve their own report. A high override rate means the policy and the building do not match.
Role-based access matters as much as the fields. Site staff should see their building. Investigators should see the visit they are assigned. Executives should see counts, not photographs. Exports should be logged. A CSV that anyone in reception can download, with ID images included, is an incident waiting for a lost laptop.
Test the record twice a year. Pick five visits at random, including one denial and one exception, and rebuild them from the system alone. If the rebuild needs a phone call, the record is not audit-ready. That test is also the right moment to confirm the visitor layer still fits the wider program described in the guide to a unified commercial security program.
If five random visits cannot be rebuilt from the system, the system is a sign-in sheet with extra steps.
Summary: Daily site checks, a weekly contractor reconciliation, and a monthly exception review will catch drift before an audit or an incident does.
Daily, the site operations owner confirms the kiosk, the badge printer, and the host-notification path worked, and notes any manual fallback. A fallback day is not a failure by itself. An unlogged fallback day is. Write down who was admitted on paper and enter those visits before the next shift ends.
Weekly, IT and the site lead run the contractor match described above and clear the unmatched list. Monthly, the policy owner chairs the exception review and reads three numbers: override rate, visits with a missing departure, and contractor badges older than their end date. A number that moves the wrong way for two months gets a named fix, not another dashboard.
After any real emergency, reconcile the visitor list against who was accounted for. Do this while memories are fresh. The goal is not a new product feature. The goal is a list responders already trust because the ordinary days were clean. BCS365 can staff the technical owner role when an internal team is thin. Review BCS365 managed IT services when assigning that operating responsibility. The policy decision stays with the customer.
The cadence is the control. The software only records whether the cadence happened.
Book a Security Risk Assessment
Summary: Strong visitor governance depends on clear ownership, time-bound exceptions, current contractor access, and records that can stand on their own during review.
No. The system enforces a policy that people have already written. If visitor classes, escort rules, and retention periods are not decided, the platform will record whatever each site improvises.
The policy owner approves it, the site lead requests it, and IT configures only what the approval names. The record needs a reason, a compensating control, and a date it expires.
Weekly. Match active badges to active visitor records on sponsor, zone, and end date. Disable anything that no longer matches and log the person who did it.
For a sampled visit, the class, host, approver, times, badge, zones, and any exception, without a phone call to the front desk. Identity images should appear only when the class and the retention rule allow them.
Selection is a separate decision. Use the evaluation guide to choose the platform, then use this operating model so the chosen system still means the same thing at every site a year later.