Almost every company has an unwritten rule for people coming in: “go to reception and sign the book”. Far fewer have an actual policy — a document that says who greets visitors, what gets recorded, who escorts them, what happens in an emergency and how long the data is kept. This guide explains how to write one in plain terms, how to make it stick without slowing down the front desk, and what to expect when an auditor asks to see it.
In short
A visitor management policy (also called a visitor policy or visitor sign-in procedure) is the internal document that sets out who may come in, how they are signed in, who is responsible for them while they are on site and how they leave. Reception needs it to work the same way every day, the health and safety lead needs it to know who is in the building during an emergency, and whoever looks after data protection needs it to handle visitor data properly.
It does not need to be long: two or three well-written pages are almost always enough. What it does need is to be workable every single day, because a policy the front desk cannot follow at eight o’clock on a Monday morning is just a sheet in a binder. The visitor log — on paper, or digital like IRIGuest — is what makes the policy verifiable.
A visitor policy is usually written for one of three reasons: an inspection or audit where somebody asked “how do you control access?”, an unpleasant episode (a stranger found on the shop floor and nobody knew who they were), or the move to a digital visitor log, which forces you to decide once and for all what data to collect. In all three cases the problem is the same: the rules exist, but they live in the head of whoever happens to be sitting at reception.
Writing them down is not red tape. It is how you make sure that the receptionist, the colleague who covers reception in August, the department manager and the night-shift security guard all do the same thing. And, when an audit comes round, it is how you answer with a document rather than with “this is what we normally do”.
This page is a hands-on guide to writing the document. If the question you actually have is the one upstream — whether a visitor log is required by law — we have covered it separately, alongside the rest of our visitor log guides.
A visitor management policy (also known as an access policy or visitor sign-in procedure) describes the path of an external person from the moment they arrive at the entrance to the moment they leave the premises. It is not the log: the log is the record, the policy is the rule that says what goes into the record and who takes care of it.
It serves four very concrete purposes. Security: knowing at any moment who is inside, where and with whom, so you can manage an emergency and keep strangers out of restricted areas. Privacy: collecting only the data you need, telling visitors what happens to it and not keeping it longer than necessary. Image: a welcome that is the same for everyone, orderly and quick, is the first impression your company makes on customers and job candidates. Accountability: being able to show an auditor, a customer or an insurer that access to the site is under control.
The policy covers visitors in the strict sense — customers, candidates, consultants, family members, delegations — and draws the line with the other categories of external people, who follow rules of their own.
The most common risk is not writing a bad policy: it is writing an over-ambitious one — ten pages, forms in triplicate and a flow nobody can follow. The right size is the one reception applies without thinking about it.
A policy works when every step has an owner with a name, or at least a clearly defined role. In small and mid-sized companies there are almost always four people involved.
Approves the policy and sets the ground rules: who may receive visitors, whether escorting is required, which areas are off limits. Without this step the policy remains a reception initiative and gets ignored at the first exception.
Define what visitors must be told (site rules, what to do in an emergency) and, together with whoever handles data protection, decide which data to collect, how long to keep it and what goes into the privacy notice.
The people who apply the policy every day: they greet, sign in, hand out the badge, notify the host and close the visit at sign-out. Involve them in the writing, otherwise the document describes a theoretical flow rather than the real one.
Whoever receives the visit is responsible for the visitor throughout their stay: they collect them, escort them where needed and walk them back to the exit. It is the most neglected role, and the one that matters most when something goes wrong.
A policy with these four roles clearly defined covers 90% of cases. Sites with several gates and shifts add the night security desk or the warehouse, which handles drivers and deliveries with a shorter path. How to keep these people separate from your own staff is explained in our guide on the visitor log versus employee attendance.
There is no mandatory format. In practice, a visitor policy that is complete yet still readable contains the following sections — in the order the front desk meets them during a working day.
| Section | What it contains | How typical |
|---|---|---|
| Purpose and scope | Who it applies to (visitors) and who it does not (contractors, employees, couriers), at which sites and entrances | Essential |
| Roles and responsibilities | Who greets, who signs in, who escorts, who decides on exceptions | Essential |
| Sign-in | Data collected, tool used (paper or digital visitor log), mandatory fields | Essential |
| Identification and badges | Whether and how a visitor badge is issued, what it shows, when it is returned | Common |
| Escorting and areas | Where visitors may go unaccompanied, where they must be escorted, no-go areas | Essential |
| Information for visitors | Site rules, what to do in an emergency, prohibitions (photos, smoking, PPE where required) | Common |
| Privacy | Privacy notice, lawful basis, retention period, who may consult the log | Essential |
| Emergencies | How the roll call list is obtained, who takes it to the assembly point, who accounts for visitors | Essential |
| Sign-out and closure | Sign-out, badge return, closing visits still open at the end of the day | Common |
| Exceptions and review | Out-of-hours visits, large delegations, who authorises exceptions, how often the document is reviewed | Case by case |
If you would rather start from a template, the free visitor log kit includes a GDPR checklist and log templates you can use to draft the sign-in section: the columns of the log are, in effect, the data the policy has to provide for.
The heart of the policy is the operational flow: six moments, always the same, each with an owner. It is the part to write together with the people at the front desk.
The visitor reports to the designated reception point. The policy says what happens if the desk is unattended (intercom, a host to call, a self-service tablet).
The agreed data is collected: name, company, person to see, time in. Nothing more. On a digital log the mandatory fields really are mandatory and the time is recorded automatically.
The visitor reads the privacy notice and the site rules. An on-screen signature keeps a record of what was shown and to whom, with no paper to file away.
Where required, a visible visitor badge with name and company is issued. What to put on it and how to print it is covered in our visitor badge guide.
The host is notified and comes to collect the visitor. In the Cloud version of IRIGuest the notification goes out automatically at sign-in. From this point on, responsibility is theirs.
The visitor returns the badge and the time out is recorded. It is the step a paper book loses on every other line: the policy must say who closes the visits still open at the end of the day.
How these six moments translate into practice on a tablet at reception is described on our page on how visitor sign-in works. The policy should not describe the app: it should describe the rules, and the app should help people follow them.
A visitor log contains personal data, so the policy has to answer the questions the GDPR asks of any processing: which data you collect, why, how long you keep it, who can see it and how you inform the person. You do not need a legal chapter: you need five clear answers.
The practical rule is data minimisation: name, company, host and times are almost always enough. Ask for an ID document only if a genuine security procedure requires it, and in that case note the details rather than photocopying it. The privacy notice should be short, available at the desk and — on a digital log — shown before the signature.
The most delicate point is visibility: a paper book shows each visitor the names of everyone who signed in before them. The policy must ensure the log cannot be read by visitors, which on paper takes some care (single sheets, a closed register) and on a tablet is simply the starting condition.
If privacy is the part that worries you most, our page on the GDPR visitor log goes into the detail of notices, consents and on-screen signatures. Here it is enough to remember that the policy is where those choices are written down, once.
This is, in the end, the reason the log exists. When an evacuation is called, the people at the assembly point need to know who should be there — and visitors do not appear on any staff list. A serious policy says who prints or opens the roll call list, who takes it to the assembly point and who checks that every signed-in visitor has come out.
On paper this step is fragile: the book is at reception, reception is evacuating, and the lines with no time out do not tell you whether the person is still inside. On a digital log the list of visits still open is available at any moment — from another device too, in the Cloud version — and visits that have been signed out do not appear.
The policy must also settle the role of the host: while on site, the visitor is under the host’s responsibility, so it is the host who leads them to the assembly point and reports them present. It is one line in the document, but it is the line that makes the difference in a real emergency.
On production sites with several entrances, the roll call has to be assembled from every gate. It is one of the reasons why, beyond a certain size, the single centralised log described on our page on factory visitor management stops being a luxury and becomes a necessity.
Many companies write their visitor policy the week before an audit. It is not the noblest of motives, but it is a realistic one — so it pays to know what is usually asked, depending on the context. The notes below are indicative only: every certification scheme has its own requirements, and the assessment is up to the auditing body.
| Context | What is typically asked | What to show |
|---|---|---|
| ISO/IEC 27001 (information security) | Control of physical entry to secure areas (Annex A control 7.2): a record of who came in, when, and whether they were escorted | Written policy, accessible log, history searchable by date |
| ISO 9001 / IATF 16949 (quality, automotive) | No log is prescribed, but audits — customer audits above all — check how access to production areas is governed and how product and information are protected | Policy, evidence of escorting, log |
| BRCGS / IFS (food safety) | Controlled access of visitors and contractors to production areas; acknowledgement of hygiene and behaviour rules | Sign-in with signed site rules, policy, badge or identification |
| ISO 45001 and workplace safety | Information about site hazards for external people, emergency arrangements, coordination with contractors | Information handed over at the desk, roll call list, evacuation procedure |
| GDPR (data protection) | Lawful basis, privacy notice, minimisation, retention periods, who has access to the data | Privacy notice, record of processing activities, deletion procedure |
| Customer or insurer (second-party audit) | Who came in, when, who was responsible for them; sometimes who had access to a given area on a given date | Searchable, exportable history |
The good news is that auditors almost always ask for the same three things: the document, the record and proof that the record is actually used (“can you show me who came in on 12 March?”). With a paper book, the third request means leafing through pages; with a digital log, it means a search.
Visitor policies almost always fail for the same reasons, and hardly ever because a regulation was missing from the references.
What working policies do
What makes them fail
The comparison between tools — a sheet, a spreadsheet or a tablet — is covered in our guide on paper, Excel or software for the visitor log. It is worth reading before you draft the sign-in section: the tool shapes what the policy can realistically ask for.
A skeleton to adapt to your company. Each point corresponds to a paragraph of the document: if you can write two or three lines for each, the policy is done.
Ten paragraphs, with a date and a management signature at the bottom. If the document runs past three pages, it is almost certainly describing the app or repeating the regulations: both belong elsewhere.
A well-written policy asks little of the front desk, but it asks it every time. That is exactly where a paper book gives way: the time out nobody filled in, the illegible name, the privacy notice nobody got signed. A digital visitor log does not change the rules: it makes them the path of least resistance. Mandatory fields stay mandatory, the notice appears before the signature, the time is automatic and the roll call list is always within reach.
With IRIGuest the sign-in questions are customisable, consents are signed on screen and the log cannot be browsed by visitors. The free version is enough for a single front desk; the Cloud version adds automatic host notifications, QR-code pre-registration and one shared history across several gates and sites.
What the log does not do, for clarity: it does not open turnstiles or barriers, does not check contractors’ paperwork, does not train external workers and does not replace employee time and attendance. It does one thing, and does it the same way every time: it records who comes in and who goes out, as the policy requires. The wider context it belongs to is that of the digital reception.
Regulatory and technical references for further reading. This page is for information only and does not replace legal advice or the advice of your health and safety or data protection adviser.
In general, no EU or UK law prescribes a document called a “visitor policy”. There are, however, broader duties that make it the simplest way to meet them: emergency arrangements have to account for external people on site, workers from outside companies have to be informed about the risks, and visitor data has to be handled in line with the GDPR. Many certification schemes, starting with ISO 27001, also expect physical entry to be controlled and logged. We look at this in more depth in our guide on whether a visitor log is required by law.
Two or three pages. A longer policy usually describes the tool instead of the rules, or repeats the regulations. Keep the document short and pair it with a condensed version — ten lines — kept at the front desk.
The minimum the purpose requires: full name, company, the person they are visiting, time in and time out. Purpose of visit and vehicle registration only when genuinely needed; an ID document only if a security procedure calls for it, and in that case note the details without photocopying it. Every extra field is extra time at the desk and one more piece of data to look after.
It depends on what you ask of them. The privacy notice must be made available and, if you want to document that it was shown, a signature is the simplest way. The same goes for acknowledging the site rules, which is almost always required in manufacturing and food environments. With IRIGuest the signature is captured on screen and stays attached to the sign-in record.
The policy must cover it explicitly, because it is the most common scenario in smaller companies. The usual answers are a self-service tablet at the entrance, an intercom with a list of hosts, or a rule that the host comes down to collect the visitor. What does not work is leaving the decision to whoever happens to walk past.
The visitor, for the whole visit: they collect them, escort them through any area where they cannot move unaccompanied, lead them to the assembly point in an emergency and walk them back to the exit, where the sign-out is recorded. The policy needs to say so in writing, because it is the role everyone takes for granted and nobody has ever read.
Better one group policy with an appendix per site: the rules (data collected, privacy, roles, emergencies) are the same everywhere; only the entrances, opening hours and hosts change. On the tool side, the Cloud version of IRIGuest lets you apply the same configuration to every site and consult a single shared history.
Typically, that physical entry to secure areas is controlled: anyone coming in must be identified, logged with date and time and, where needed, escorted. They will want to see the policy, the log and proof that the log can be consulted — for instance who had access to a given area on a specific date. The final assessment is always up to the certification body.
The GDPR does not set a single period: it requires the retention period to be defined according to the purpose, stated in the privacy notice and respected. Many companies work with a few months for ordinary visitors and longer for security-related access. What matters is deciding it in the policy and naming who deletes the data when the time is up.
Yes, for a single front desk: the free version works offline, with no time limit, with customisable questions, a privacy notice and signature on screen, and CSV export. Automatic host notifications, QR-code pre-registration, a single log across several gates and sites and centralised reporting are features of the Cloud version.
Try IRIGuest free at your front desk, or watch how a visitor signs in, in two minutes. Nothing to install, no commitment.
