Category: Security Operations

A contractor sign in sheet is the record, kept at the gate or reception, of every contractor who comes on site to work. It captures who they are, who they work for, why they are there and when they arrive and leave. Unlike a visitor who is escorted for a meeting, a contractor is often on site for hours, moving through areas staff do not watch, sometimes doing work that carries its own risk. The sign in sheet is where accountability for that starts.

Most contractor sign in sheets fail for one reason: the template is missing the fields that matter, so the record has gaps exactly where you later need proof. This guide sets out the eight fields every contractor sign in sheet template should have, and why a digital sheet closes the gaps a paper one cannot.

Why a contractor sign in sheet matters

A contractor is not a guest. They carry tools, they may work alone in a plant room, and the task itself, hot work or an electrical isolation for example, can be the very thing that causes an incident. The sign in sheet is the first control that ties a named person to a company, a task and a window of time on your site.

It matters in three moments. In an evacuation it tells the fire marshal how many contractors are still inside and where they were working. In a safety review it links each person to the permit or approval that authorised their work. After an incident it answers the question every investigation opens with: who was here, and who let them in.

The weakness of the paper sheet is that it relies on the contractor to fill it in fully and honestly, and on nobody being able to walk past the desk unchecked. A clipboard left on a counter is not a control at all. That is what the right fields, and a digital format, are there to fix.

The 8 fields every contractor sign in sheet needs

1. Contractor name – the full name of the individual, so the entry is attributable to a person and not just a company.
2. Company – the firm the contractor represents, so you can trace the work back to a supplier.
3. On-site contact or host – the member of staff who authorised the work and is responsible while the contractor is on site.
4. Purpose of work – what the contractor is there to do, in enough detail to match it against any permit.
5. Permit or approval reference – the number of the work permit or access approval that authorised entry, where the task requires one.
6. Time in – the arrival time, recorded at the gate.
7. Time out – the departure time, recorded when the contractor leaves. This is the field paper sheets lose most often, and the one an evacuation depends on.
8. Pass or badge number – ties the contractor to the physical or digital pass they were issued for the day.

Higher-risk sites add two more: a photo of the contractor and a scan of a photo ID, so the person at the gate can match the badge to the face. In AVES, each access pass is issued with an approval step, a QR code and an id or profile photo, so the entry is tied to a verified identity rather than a name written by hand. Where the work is hazardous, the hot work permit adds an invitation, an approval, a QR check-in and a terms and conditions acknowledgement on top of the sign in, so a contractor cannot start high-risk work without an authorised permit on record.

Paper sign in sheet versus a digital one

A paper template works until the moment it matters. The recurring failures are always the same: the time-out field left blank, handwriting no one can read, a permit reference nobody wrote down, a page that has gone missing. None of these is visible until you need the record and find it incomplete.

A digital contractor sign in sheet captures the same eight fields as structured data. Required fields cannot be skipped, entries are legible because they are typed or selected, and the departure is recorded when the pass is scanned or returned rather than relying on the contractor to sign out. The record is searchable, so you can pull every visit by one firm, or everyone on site during a shift, in seconds. For the full workflow around passes, approvals and access, see the AVES visitor management system. To see how contractor access differs from payroll-style management, see contractor management for security teams.

Common contractor sign in sheet mistakes

No sign-out. The single most common gap. Without a time out you cannot prove when a contractor left or run an accurate evacuation count.

No permit link. A contractor doing hazardous work with no permit reference on the sheet means there is no record that the work was ever authorised.

An unattended clipboard. A sheet on the counter with no one checking it lets anyone write anything, or nothing.

No named host. If no staff member authorised the work, no one is accountable for where the contractor goes or what they do.

No identity check. A name with nothing behind it is trivial to fake, and a contractor pass is easy to reuse the next day.

Keeping old sheets on display. A completed sheet shows every prior contractor’s details to the next person who signs in. That is a privacy failure. Records should be stored securely, not left face-up on the desk.

Contractor sign in sheet checklist

• Every entry has a contractor name, company and named host.
• Purpose of work is recorded in enough detail to match a permit.
• A permit or approval reference is captured where the task requires one.
• Both time in and time out are recorded.
• A pass or badge number ties the person to a pass issued for the day.
• Higher-risk sites add a photo and ID check.
• The sheet is controlled by a person, not left unattended.
• Prior entries are not visible to the next contractor.
• Records are stored securely and retained only as long as needed.

Frequently asked questions

What is a contractor sign in sheet?
A contractor sign in sheet is a record kept at a site entrance of every contractor who comes on site to work, capturing their name, company, host, purpose of work and their time in and out. It supports evacuation roll calls, permit control and after-incident accountability.

What fields should a contractor sign in sheet have?
Contractor name, company, on-site host, purpose of work, permit or approval reference, time in, time out and pass number. Higher-risk sites also add a photo and an ID check.

What is the difference between a contractor and a visitor sign in sheet?
A visitor is usually escorted for a short meeting, so a name and host is often enough. A contractor works on site for longer, sometimes on hazardous tasks, so the sheet also needs a purpose of work and a link to the permit that authorised it.

Do contractors need a work permit as well as a sign in sheet?
For hazardous tasks such as hot work, yes. The sign in sheet records entry; the permit authorises the specific work. The permit reference should appear on the sign in record so the two tie together.

How do you stop a contractor pass being reused?
Control the sheet at the gate rather than leaving it out, and issue a pass tied to an approval and an identity check. A digital pass with a photo and a QR code ties each day’s entry to a verified person.

Move your contractor sign in off the clipboard

If your gate still runs on a paper sheet, the gaps are only a matter of time, and with contractors the gap is often a missing permit link or a blank time out. AVES issues every contractor an access pass with an approval step, a QR code and a profile photo, ties hazardous work to an authorised hot work permit, and records each visit as a private, searchable entry with the time out captured when the pass is scanned.

Book a 30-minute demo and we will show you the actual access pass, approval and permit screens: Book an AVES demo

Prefer to explore first? Start a free account: Create your AVES account

Follow AVES on Instagram: instagram.com/avessecurity

A security patrol report is the record that proves a guard actually walked the site. It documents where they went, when they got there, and what they found along the way. Without it, a patrol is just a claim. With it, you have verifiable evidence that the checkpoints were covered, the round was completed, and any issue was seen and logged.

The value of the report depends entirely on what it records. A report that says “all clear, 10pm” proves nothing; the guard could have written it from the gatehouse. A report that ties each checkpoint to a GPS location, a scan time and a photo is evidence. This guide sets out the seven things every security patrol report must record, and how a digital patrol makes each one verifiable.

Why the security patrol report matters

A patrol report answers three questions that clients and courts both ask. Did the guard cover the whole site, or just the easy parts? When exactly were they at each point? And what did they do about anything they found?

The report matters most when something goes wrong. If a break-in happens between two checkpoints, the report shows whether the round was on schedule or whether a section was skipped. If a client disputes that the site was patrolled at all, the report is the proof. This is why proof of patrol is a real requirement, not a formality: it is the difference between a defensible service and a guard’s unverified word.

The 7 things every security patrol report must record

1. Guard and shift – who patrolled and on which shift, so the round is attributable.
2. Date and start and end times – when the patrol began and finished, from the waypoint start and end times, not a figure written afterwards.
3. Checkpoints visited – each checkpoint on the route, confirmed by a QR scan so the guard had to be physically present to log it.
4. Time at each checkpoint – the scan time at each point, which shows the round was walked in sequence and on schedule.
5. GPS location – the location captured at each scan, tying the guard to the place, not just the time.
6. Verification media – a selfie or photo where required, adding a further layer of proof.
7. Observations and issues – anything found on the round: an unlocked door, a hazard, a suspicious person, with the action taken.

AVES patrols capture exactly these: checkpoints visited with GPS location and scan time, a QR code at each point, an optional required selfie, waypoint start and end times, and the total distance covered. That last figure, total distance, is a quiet but powerful check: a full round covers a known distance, and a short one shows on the record.

How a digital patrol report is verified

A paper patrol log can be written anywhere, which is precisely its weakness. A digital patrol removes the ability to fake it. The guard must scan a QR code fixed at each checkpoint to log it, and the scan captures the GPS location and the exact time automatically. Where a selfie is required, the guard cannot log a point without it.

The result is a report that is verifiable rather than merely claimed. A supervisor can see the route as it was actually walked, the time spent, the distance covered and any gaps. For the full patrol and checkpoint workflow, see the AVES guard tour system. For why unverified patrols are a genuine liability, see missed patrol verification.

Common security patrol report mistakes

Written from the gatehouse. A report completed without walking the round proves nothing. QR scans at fixed points remove this.

No time per checkpoint. A single end-of-round timestamp hides whether the patrol was on schedule. Each checkpoint needs its own scan time.

No location. A time with no place does not prove the guard was where they should have been.

Skipped checkpoints not flagged. A report that silently omits a missed point is worse than one that records the gap.

Vague observations. “All fine” is not an observation. Note what was checked and anything found.

Security patrol report checklist

• Guard and shift recorded.
• Patrol start and end times captured automatically.
• Every checkpoint confirmed by a scan at the point.
• A time recorded at each checkpoint, not just at the end.
• GPS location captured at each scan.
• Selfie or photo verification where required.
• Observations and actions logged.
• Total distance or route completeness visible, so gaps show.

Frequently asked questions

What is a security patrol report?

A security patrol report is a record proving a guard patrolled a site, documenting the checkpoints visited, the time and location of each, and any issues found. It is used as proof of patrol for clients, insurers and investigations.

What should a security patrol report include?

The guard and shift, start and end times, each checkpoint with its scan time and GPS location, verification media where required, and observations with actions taken.

How do you prove a patrol actually happened?

By tying each checkpoint to a QR scan that captures the GPS location and time automatically, so the guard must be physically present to log it. A single written “all clear” does not prove a patrol.

What is the difference between a patrol report and a daily activity report?

A patrol report covers a specific round and its checkpoints. A daily activity report summarises everything across a shift. The patrol report feeds the wider activity record.

Can a digital patrol report be faked?

It is far harder. Because a checkpoint is only logged when the guard scans a fixed QR code, and the scan captures location, time and often a selfie, a report cannot be completed without being at the points.

Give your patrols proof, not just a signature

If your patrol reports are still handwritten logs, you cannot prove the round was walked. AVES patrols log each checkpoint by QR scan with GPS, time, an optional selfie and the total distance covered, so every report is verifiable.

Book a 30-minute demo and we will show you the actual patrol and checkpoint screens: Book a demo.

Prefer to explore first? Start a free account.

Follow AVES on Instagram.

A visitor sign in sheet is the printable template that sits at your front desk: the single page a visitor completes on arrival, capturing who they are, who they are here to see, and when they came and went. It is the input at the point of entry, the thing a receptionist hands across the counter. This guide is about that sheet as a document: the columns your template must have before you print it, not the running record it eventually feeds.

Most sign in sheets fail for the same reason: the printed template is missing the columns that matter, so every entry has gaps exactly where you later need proof. Below are the seven columns every visitor sign in sheet template should carry, the front-desk mistakes that make one worthless, and where a paper sheet stops being enough. For the ongoing record those sheets build up into, see the AVES visitor log book guide.

Why a visitor sign in sheet matters

The sheet does more than log names. In an evacuation it is the roll call that tells a fire marshal how many non-staff are in the building. In a security review it is how you tie a person to a time and a host. After an incident it is the record that answers the only question that matters: who was here.

The weakness of the paper sheet is that it depends on the visitor filling it in honestly and completely, and on nobody being able to read what the person above them wrote. A sheet left unattended on a counter is not a control at all. That is the problem the right columns, and a digital format, are there to fix.

The 7 columns every visitor sign in sheet needs

1. Visitor name – full name, so the entry is attributable.
2. Company or affiliation – who the visitor represents.
3. Host – the member of staff responsible for the visitor while on site.
4. Purpose of visit – meeting, delivery, contractor work, interview.
5. Time in – the arrival time, recorded at entry.
6. Time out – the departure time, recorded when the visitor leaves. This is the column paper sheets lose most often, and the one an evacuation depends on.
7. Pass or badge number – ties the visitor to the physical or digital pass they were issued.

Higher-security sites add two more: a photo of the visitor and a scan of a photo ID, so the person at the desk can match the badge to the face. AVES issues each visitor pass with an approval step, a QR code and an id or profile photo, so the entry is tied to a verified identity rather than a name written by hand.

Paper sign in sheet versus a digital one

A paper template works until the moment it matters. The recurring failures are always the same: the time-out column left blank, handwriting no one can read, a visitor who signed in as someone they are not, a page that has gone missing. None of these is visible until you need the record and find it incomplete.

A digital sign in sheet captures the same seven columns as structured data. Required fields cannot be skipped, entries are legible because they are typed or selected, and the departure is recorded when the pass is scanned or returned rather than relying on the visitor to sign out. The record is searchable, so you can pull every visit by a contractor or everyone on site on a given afternoon in seconds. For the full workflow around passes, approvals and access, see the AVES visitor management system. To understand why unreturned passes are a risk worth tracking, see visitor pass tracking.

Common visitor sign in sheet mistakes

No sign-out. The single most common gap. Without a time out you cannot prove when someone left or run an accurate evacuation count.

An unattended clipboard. A sheet on the counter with no one checking it lets anyone write anything, or nothing.

No host column. If no staff member is named, no one is accountable for where the visitor goes.

No identity check. A name with nothing behind it is trivial to fake.

Keeping old sheets on display. A completed sheet shows every prior visitor’s details to the next person who signs in. That is a privacy failure. Records should be stored securely, not left face-up on the desk.

Visitor sign in sheet checklist

• Every entry has a name, company and named host.
• Purpose of visit is recorded.
• Both time in and time out are captured.
• A pass or badge number ties the person to a pass.
• Higher-risk sites add a photo and ID check.
• The sheet is controlled by a person, not left unattended.
• Prior entries are not visible to the next visitor.
• Records are stored securely and retained only as long as needed.

Frequently asked questions

What is a visitor sign in sheet?

A visitor sign in sheet is a record kept at a site entrance of every non-staff visitor, capturing their name, host, purpose and their time in and out. It supports evacuation roll calls, security accountability and compliance.

What columns should a visitor sign in sheet have?

Name, company, host, purpose of visit, time in, time out and pass number. Higher-security sites also add a photo and an ID check.

What is the difference between a visitor sign in sheet and a visitor log book?

They are different stages of the same process. A sign in sheet is the printable template a visitor fills in at the desk, one page at a time. A visitor log book is the ongoing record those sheets accumulate into, kept for roll-call and retention. This guide covers the sheet; the log book guide covers the record.

Is a paper visitor sign in sheet GDPR-safe?

A paper sheet that displays previous visitors’ details to the next person signing in is a privacy risk. A digital sheet keeps each entry private and lets you retain and dispose of records securely.

How do you stop people signing in as someone else?

Control the sheet at the desk rather than leaving it out, and add an identity check. A digital pass with a photo and an approval step ties each entry to a verified person.

Move your sign in sheet off the clipboard

If your entrance still runs on a paper sheet, the gaps are only a matter of time. AVES issues every visitor a pass with an approval step, a QR code and a profile photo, and records each visit as a private, searchable entry with the time out captured automatically.

Book a 30-minute demo and we will show you the actual visitor pass and approval screens: Book a demo.

Prefer to explore first? Start a free account.

Follow AVES on Instagram.

An incident report form is the blank template a guard fills in when something goes wrong on site: an injury, a theft, a trespass, a near miss, property damage. Before a word is written, the form itself decides how good the record can be. A template that prompts for the right fields, in the right order, produces a report an insurer or a court will accept. A blank box that just says “describe the incident” produces three vague lines and no evidence.

This guide is about the form as a document: the eight fields your template must contain before you hand it to a guard, the mistakes that make a filled-in form worthless, and when a printable paper form is enough versus when you need a digital one. If what you need is how to write up the report once you have the form, that belongs in our security incident report format guide; this piece stays on the form itself.

Why the incident report form matters

The report is written in minutes but read for months. It is the document a claims adjuster uses to decide a payout, the record a lawyer reads before a liability case, and the evidence a client reviews when they ask what their security provider actually did. If a detail was not captured at the scene, it usually cannot be recovered later.

A structured form matters because it removes the guesswork under pressure. A guard dealing with an injured person should not have to remember what a complete report needs; the form should ask. That is what separates a system that produces usable evidence from one that produces a pile of inconsistent notes.

The 8 fields every incident report form must include

1. Date and time of the incident – the actual time it happened, not the time the report was written.
2. Location – the specific place on site, precise enough that someone who was not there can picture it.
3. Reporter details – the name and role of the guard completing the form, so the account is attributable.
4. People involved – names and roles of everyone present: victims, witnesses, staff, third parties.
5. Description of what happened – a factual, chronological account, without opinion or blame.
6. Action taken – what the guard did: first aid given, police called, area secured, supervisor notified.
7. Evidence – photos, video or audio from the scene. AVES incident forms capture six-sided photo evidence (front, back, left, right, top, bottom) plus video and audio.
8. Findings and follow-up – the outcome, any corrective action, and whether a police report or investigation was raised.

Together these eight answer the questions every reader asks: what, when, where, who, what was done, and can you prove it.

How a digital incident report form works

A paper form relies on the guard remembering to fill every box and on the handwriting being legible weeks later. A digital incident report form removes both risks. The fields are mandatory where they need to be, so a report cannot be submitted half-finished. Photos, video and audio attach directly to the record rather than living on someone’s phone. The timestamp and the reporter are captured automatically.

Because the report is data rather than paper, it is searchable and it routes to the right person for review the moment it is submitted. For the full workflow around logging, escalating and analysing incidents, see the AVES incident reporting software. If you need the specific layout conventions, the security incident report format guide covers structure.

Common incident report form mistakes

Opinion instead of fact. “The visitor was aggressive” is a judgement. “The visitor raised his voice and struck the counter” is an observation. Reports record observations.

Missing the time of the incident. Recording only when the report was written loses the single most important timestamp.

No evidence. A description with no photo is an assertion. A single photo of a wide area proves little. Capture the scene from multiple angles.

Blame and speculation. A report that guesses at cause or assigns fault undermines its own credibility. Record what was seen; leave conclusions to the investigation.

Gaps left blank. An empty field is a question left unanswered, and it is often the answer the reader needs most.

Written hours later. Memory fades fast. A report completed at the scene is far more reliable than one reconstructed at the end of a shift.

Incident report form checklist

• Date and time of the incident recorded, separate from the report time.
• Specific location captured.
• Reporter named, with role.
• All people involved listed with roles.
• Factual, chronological description with no opinion.
• Action taken recorded.
• Evidence attached: photos from multiple angles, plus video or audio where relevant.
• Findings and follow-up noted, including any police report.

Frequently asked questions

What is an incident report form?

An incident report form is a structured document that records the details of an incident on site: what happened, when and where, who was involved, the action taken and the evidence captured. It is used for insurance, liability and investigation.

What should an incident report form include?

At a minimum: date and time of the incident, location, reporter, people involved, a factual description, action taken, evidence, and findings or follow-up.

What is the difference between an incident report form and a witness statement?

The incident report is the guard’s structured account of the event. A witness statement is a separate first-person account from someone who saw it. Both support the same case. See the AVES witness statement form.

Should incident reports be written on paper or digitally?

Digital is more reliable. Paper forms are prone to blank fields, illegible handwriting and lost evidence. A digital form enforces the required fields, attaches photo, video and audio directly to the record and timestamps it automatically.

How soon should an incident report be completed?

As close to the incident as possible, ideally at the scene. Memory and evidence both degrade quickly, so a report written hours later is weaker.

Give your guards a form that captures real evidence

If your incident reports still come in as a few handwritten lines, the evidence you need after an incident is not there. AVES incident forms prompt for every required field and capture six-sided photo evidence plus video and audio, so every report is complete and defensible.

Book a 30-minute demo and we will show you the actual incident form and evidence-capture screens: Book a demo.

Prefer to explore first? Start a free account.

Follow AVES on Instagram.

A shift change request form is how a guard asks to swap, drop or move a shift, and how a manager approves or rejects that change on the record. It sounds like a small piece of admin. In practice it is the difference between a roster you can trust and a roster where a post quietly goes uncovered because two people agreed a swap in a WhatsApp message no supervisor ever saw.

Most shift change request form entries fail for the same reason a paper visitor sheet fails: the request is verbal or informal, so there is no record of who agreed to what, and no approval step to confirm the site is still covered. This guide sets out the seven fields every shift change request form should capture, and why a digital request beats a paper slip or a text message.

Why a shift change request form matters

Security rosters are coverage promises. A client pays for a post to be manned from a set time to a set time, and the roster is how you keep that promise. The moment a guard cannot make a shift, that promise is at risk, and the shift change request form is the control that protects it.

A good shift change request form does three things. It captures the request in writing so there is no dispute later about who asked for what. It forces the swap to name a replacement, so a change never leaves a gap. And it routes the request to a manager for approval, so no change goes live until someone accountable has confirmed the post is still covered.

Without a form, changes happen in the gaps: a guard tells a colleague they will cover, the colleague forgets, and the first anyone hears of it is an empty post at 2am. The form exists to stop that conversation ever being informal.

The 7 fields every shift change request form needs

1. Requesting employee – the guard asking for the change, so the request is attributable.
2. Original shift – the date, time and site or post the guard is currently rostered for.
3. Type of change – a swap with a named colleague, a drop, or a move to a different date or time.
4. Replacement or cover – who will work the shift instead. A swap request that names no replacement is not a plan, it is a gap.
5. Reason – why the change is needed. This lets a manager judge the request and spot patterns, such as one guard repeatedly avoiding night shifts.
6. Date submitted – when the request was made, so late requests can be distinguished from those raised with proper notice.
7. Manager decision – approved or rejected, by whom, with the date and time. This is the field that turns a request into an authorised change.

Keep the form to these fields and it stays quick to complete, which matters because a form guards will not fill in is no better than no form at all.

Paper shift change slip versus a digital shift change request form

A paper slip or a group chat works right up to the moment it matters. The recurring failures are always the same: a swap agreed verbally that one party forgets, a slip that never reaches the supervisor, a change approved by someone with no authority to approve it, or a request lost so completely that no one can say whether it was ever agreed.

A digital shift change request form captures the same seven fields as structured data and routes it for approval automatically. In AVES, shift change requests are raised by staff and sent to a manager for approval, so a change is only live once it has been authorised, not the moment two guards shake hands on it. Because the request sits against the roster, an approved swap updates the schedule the whole team is working from rather than living in one person’s memory.

The roster it updates is generated and managed in the same system. For how the underlying schedule is built, see the AVES security guard duty roster. For what the guard coming on shift should confirm at handover once a change has gone through, see the shift handover checklist. And because a swap only counts once the replacement actually turns up, geofenced attendance is what confirms the covering guard was on site.

Common shift change request form mistakes

No named replacement. A request to drop a shift without saying who covers it is not a swap, it is a hole in the roster waiting to be found.

Verbal-only agreements. A swap agreed in a corridor or a chat leaves no record. When the post is missed, there is nothing to show what was agreed or by whom.

No approval step. If a change goes live the moment two guards agree, no manager has confirmed the site is still covered or that the replacement is qualified for that post.

Approval by the wrong person. A colleague saying “fine by me” is not authorisation. The decision field must record a manager, not a peer.

Late requests treated the same as planned ones. Without a submission date you cannot tell a request raised a week ahead from one raised an hour before the shift. The reason and date fields let you manage notice periods fairly.

Shift change request form checklist

• The requesting guard and their original shift are named.
• The type of change is clear: swap, drop or move.
• A replacement is named for every swap or drop.
• A reason is recorded.
• The submission date is captured.
• A manager, not a peer, approves or rejects the request.
• The decision, the approver and the date and time are all recorded.
• An approved change updates the roster the whole team works from.

Frequently asked questions

What is a shift change request form?

A shift change request form is a record of a guard’s request to swap, drop or move a rostered shift, capturing the original shift, the replacement, the reason and a manager’s approval. It keeps roster changes authorised and on the record rather than informal.

What should a shift change request form include?

The requesting employee, their original shift, the type of change, the named replacement or cover, the reason, the date submitted and the manager’s decision with the date and time.

What is the difference between a shift swap and a shift change request?

A shift swap is one type of change, where two people exchange shifts. A shift change request is the broader form that also covers dropping a shift or moving it to a different time, each still needing a named replacement and manager approval.

Why does a shift change need manager approval?

Because only a manager can confirm the post is still covered and the replacement is qualified for it. Without an approval step, a change agreed between two guards can leave a site uncovered or manned by someone not cleared for that post.

Can a shift change request be handled digitally?

Yes. A digital shift change request form captures the same fields, routes the request to a manager automatically and updates the shared roster once approved, which removes the verbal agreements and lost slips that paper processes rely on.

Take shift changes off the group chat

If your shift swaps still happen in a group chat, the missed post is only a matter of time. AVES lets a guard raise a shift change request that names the replacement and routes to a manager for approval, so no change goes live until the coverage is confirmed and the roster is updated for everyone.

Book a 30-minute demo and we will show you the actual shift change request and approval screens: Book a demo

Prefer to explore first? Start a free account: Start a free account

Follow AVES on Instagram: Instagram

A visitor log book is the running record of every person who enters your site who is not a member of staff. Each entry captures who the visitor is, who they came to see, when they arrived and when they left. Kept properly, the visitor log book is the first thing an auditor, an insurer or an investigator asks to see after an incident, and it is often the only proof of who was on site at a given moment.

Most sites still keep this record on a paper sheet at the front desk. It works until the moment it matters, and then the gaps show: unreadable handwriting, a sign-out column left blank, a page that has gone missing. This guide sets out exactly what a good visitor log book should record, the mistakes that make one worthless, and how a digital log closes those gaps.

Why a visitor log book matters

The visitor log book does three jobs at once, and each one carries real risk if the record is weak.

It is an evacuation roll call. In a fire or an emergency the log book tells the fire marshal how many non-staff are inside the building and who they are. A blank sign-out column means you cannot tell who has left and who is still at their desk, which is the difference between an accurate roll call and a guess.

It is a security control. A visitor who is logged, badged and tied to a named host is accountable. A visitor who walked past an unattended sheet is not. When something goes missing or an area is accessed that should not have been, the visitor log book is where the investigation starts.

It is a compliance and liability record. After an accident or a dispute, the question is always the same: who was on site, and can you prove it. A complete, timestamped log answers that question. An incomplete one leaves your organisation carrying the doubt.

What to record in a visitor log book

A useful entry answers who, who for, when and why. At a minimum every visitor log book entry should capture the following.

• Visitor name – full name, not initials.
• Company or affiliation – the organisation the visitor represents.
• Host – the member of staff the visitor is here to see, who is accountable for them on site.
• Purpose of visit – meeting, delivery, contractor work, interview.
• Date – the day of the visit.
• Time in – the arrival time, recorded at the point of entry.
• Time out – the departure time, recorded when the visitor leaves and hands back the pass.
• Pass or badge number – the physical or digital pass issued for the visit.
• Vehicle registration – where the visitor has parked on site, for evacuation and access control.
• Signature or acknowledgement – confirmation the visitor has read any site safety or confidentiality notice.

Higher-security sites add a photo of the visitor and a scan of a photo ID so the person at the desk matches the badge to the face. AVES issues each visitor pass with an approval step, a QR code and an id or profile photo, so the record is tied to a verified identity rather than a name written by hand.

How a digital visitor log book works

A digital visitor log book replaces the front-desk sheet with a structured record that cannot be left half-finished. The flow is straightforward.

A visitor arrives and is registered against a named host. Instead of a free-text line, the entry captures the required fields as data, so nothing is skipped. A pass is issued and, in AVES, that pass carries a QR code and the visitor’s profile photo, and it moves through an approval step before access is granted. When the visitor leaves, the pass is scanned or returned and the time out is recorded, which is the step paper logs lose most often.

Because every entry is a record rather than a row of handwriting, the log is searchable and legible. You can pull every visit by a given contractor, or every person on site on a given afternoon, in seconds rather than leafing through a book. For a fuller picture of how passes, approvals and access tie together, see the AVES visitor management system.

Common visitor log book mistakes

The same handful of failures turn a log book from evidence into a liability.

Blank sign-out times. The most common gap. Without a time out you cannot prove when a visitor left, and your evacuation count is wrong. A digital log that records the return of the pass fixes this.

An unattended sheet. A clipboard left on the counter lets anyone write anything, or nothing. Entry should be controlled by the person at the desk, not left to the honesty of the visitor.

No host named. If no member of staff is accountable for the visitor, no one is responsible for where they go. Every entry needs a named host.

Illegible handwriting. A name no one can read is a name you cannot check later. This is exactly the problem structured fields remove.

No identity check. A name with nothing behind it is easy to fake. A photo and an ID scan tie the entry to a real person.

Keeping old logs where they can be lost or read. A visitor log holds personal data. It should be retained securely for as long as it is needed and no longer, not stacked in a drawer where anyone can flip through it.

Visitor log book checklist

Use this to check your current visitor log book, whether it is paper or digital.

• Every entry has a full name, company and named host.
• Purpose of visit is recorded, not assumed.
• Time in and time out are both captured for every visit.
• A pass or badge number ties the person to a physical or digital pass.
• Higher-risk sites capture a photo and an ID check.
• The visitor has acknowledged any safety or confidentiality notice.
• Entry is controlled by a person, not an unattended sheet.
• Records are stored securely and retained only as long as needed.

Frequently asked questions

What is a visitor log book?

A visitor log book is a record of every non-staff person who enters a site, capturing their name, who they are visiting, and their arrival and departure times. It is used for evacuation roll calls, security accountability and compliance.

What should a visitor log book include?

At a minimum: visitor name, company, host, purpose of visit, date, time in, time out and pass number. Higher-security sites also capture a photo, an ID check and a signed acknowledgement of site rules.

Is a paper visitor log book still acceptable?

It can meet the basic requirement, but paper logs are prone to blank sign-out columns, illegible entries and lost pages. A digital visitor log book captures the same fields as structured data, records departures reliably and keeps the record searchable and secure.

How long should you keep a visitor log book?

Retain visitor records for as long as they are needed for security, compliance or insurance purposes, then dispose of them securely. Because the log holds personal data, it should not be kept indefinitely or left where it can be read by others.

What is the difference between a visitor log book and a visitor management system?

A log book is the record of entries. A visitor management system is the software that captures those entries, issues passes, ties each visit to a verified identity and a named host, and records departures. See how AVES keeps a full security guard logbook for the shift alongside visitor records.

Move your visitor log book off paper

If your front desk still runs on a paper sheet, the gaps are only a matter of time. AVES issues every visitor a pass with an approval step, a QR code and a profile photo, and records each visit as a structured, searchable entry.

Book a 30-minute demo and we will show you the actual visitor pass and approval screens: Book a demo.

Prefer to explore first? Start a free account.

Follow AVES on Instagram.

An asset handover form is a simple record of a company item passing from one person to another, capturing what the item is, who received it, when, in what condition and who witnessed it. Radios, keys, uniforms, tablets and access cards move between staff every shift, and when one goes missing the argument is always the same: who had it last. Without a signed record, that question has no answer. This guide covers what an asset handover form should record, why each field matters, and the common mistakes that leave teams exposed.

Why an asset handover form matters

A handover is a trust problem before it is an admin problem. When a supervisor issues a radio to a guard, they are trusting it will come back in the same condition. If it does not, and there is no record, the loss lands on whoever is easiest to blame rather than whoever actually held the item. A written, witnessed record protects the honest employee as much as it protects the company asset.

A good form also answers questions that surface weeks later. Was the item ever issued? Who accepted it, and did they agree it was working at the time? For teams handing out equipment across shifts and sites, these questions arrive often enough that memory and a group chat are not enough. A dated, accepted record settles a dispute in seconds instead of a meeting.

Finally, a form turns a scattered process into an auditable one. A manager can see at a glance what has been issued, what is still out, and what was returned damaged. That visibility is impossible when handovers happen verbally and the only proof is a photo someone may or may not have taken.

How an asset handover form works

The flow is short, and should stay short so people actually use it. An item is recorded at the moment it changes hands: what it is, who is issuing it, who is receiving it, its condition and the date. A witness is named. The receiver then formally accepts the handover, which converts a note into an agreement both sides have acknowledged. If the item is later returned, the return is recorded against the same entry so the item’s whole journey, issued to returned, sits in one place.

The point of recording each step is accountability. Every hand-off carries a name and a timestamp, so if anything goes wrong the record shows exactly where. In the AVES Acknowledgement module this is built in: a handover of an article is logged with a witness, and the receiver accepts or declines it, leaving a clear submitted, accepted or declined trail with the person, date and time attached. Nothing depends on someone writing it up later.

A note on signatures: the AVES record does not rely on a scanned signature image. Acceptance is captured as an in-system accept action tied to the named user, date and time, which is harder to forge than a signature on a page and easier to audit.

What to record in an asset handover form

Keep the fields tight. Too many and staff skip them; too few and the form cannot settle a dispute. At minimum, capture:

• Item description — what it is, make, model and serial or asset number.
• Condition at handover — working, scratched, screen cracked. Agreeing condition up front is what prevents an argument at return.
• Who is issuing it — the supervisor or store keeper releasing the asset, named.
• Who is receiving it — the employee taking responsibility, named.
• Date and time — recorded at the moment of handover, not backfilled later.
• Witness — a second name adds weight to high-value items and protects both parties.
• Acceptance — the receiver’s formal accept, so responsibility passes on the record rather than by assumption.
• Return details — who returned it, when and in what condition, closing the entry.

The AVES Acknowledgement module carries the core of this directly: the receipt and handover of an article, a named witness, and the receiver’s accept or decline response with the submitting person, date and time. Recording condition and a witness at the point of handover is what turns a note into proof.

Common mistakes to avoid

The first mistake is recording late. An item issued at the start of a shift and written up at the end has a gap no record can explain. Capture the handover at the moment it happens.

The second is skipping condition. If the form does not note that a tablet already had a cracked screen when issued, the company either eats a repair it did not cause or blames an employee unfairly. Record condition on the way out and on the way back.

The third is no acceptance step. A form filled in by the issuer alone proves the item left the store, not that the receiver agreed to take it. An explicit accept from the receiver is what makes the record binding on both sides.

The fourth is handing items back without recording the return. An open handover with no return detail looks, months later, exactly like a lost asset. Always close the loop with who returned it, when and in what state.

The fifth is keeping the form where only one person can see it. A paper pad at one gate cannot be searched, cannot be reviewed by a manager at another site, and is gone if it is lost. A shared, structured record fixes all three, and keeps the custody trail intact the same way a proper key control process does for keys.

Frequently asked questions

What should an asset handover form include?
At a minimum: an item description with a serial or asset number, its condition at handover, who issued it, who received it, the date and time, a witness, the receiver’s acceptance, and the return details when the item comes back.

Who should sign an asset handover form?
Both sides take part: the issuer records the handover and the receiver formally accepts it. A named witness adds weight for high-value items. In AVES the acceptance is an in-system accept tied to the user, date and time rather than a scanned signature.

What is the difference between an asset handover form and a gate pass?
A gate pass authorises an item to leave a site through the gate. An asset handover form records responsibility passing between two people, and is usually used when equipment is assigned to an employee, not when it exits the premises.

Is a paper asset handover form enough?
A paper form works for very low volumes but cannot be searched, reviewed remotely or backed up, and it offers no reliable timestamp. A structured digital record keeps the description, condition, witness and acceptance together and visible to managers across sites, which also supports fairer performance and development conversations when equipment responsibility is part of the role.

See the AVES handover record in action

If company assets keep going missing between shifts, book a 30-minute demo and we will show you the actual AVES Acknowledgement screen, how a handover is logged with a witness, and how the receiver accepts it into their care with a full submitted, accepted or declined trail.

Book a 30-minute demo →

Prefer to try it first? Start free with AVES →

Follow AVES on Instagram for more security operations guides.

A lost and found log is a simple record of every item found on site, who found it, where and when, and what happened to it afterwards. On a busy reception or guard post, phones, keys, wallets and passes turn up daily. Without a log they sit in a drawer, get handed back to the wrong person, or quietly disappear, and no one can prove what was ever received. This guide covers what a lost and found log should record, why each field matters, and the common mistakes that leave teams exposed.

Why a lost and found log matters

Found property is a trust problem before it is an admin problem. When a visitor hands a lost wallet to a guard, they are trusting that it will be kept safe and returned. If the item goes missing, the guard is the last person seen holding it, and a missing entry looks the same as theft. A written record protects the honest guard as much as it protects the owner.

A good log also answers questions that come up later. Was the item ever handed in? Who accepted it? When was it collected, and by whom? For sites that handle regular footfall, hotels, offices, retail, campuses, these questions arrive often enough that memory and loose notes are not enough. A dated, witnessed record settles disputes in seconds instead of arguments.

Finally, a log turns a scattered process into an auditable one. A supervisor can see at a glance what is still unclaimed, what has been returned, and what needs escalating. That visibility is impossible when found items live in a drawer and a few text messages.

How a lost and found log works day to day

The flow is short and should stay short so guards actually follow it. It sits alongside other reception accountability records a guard keeps. An item is found and logged at the point it is handed in, with a description, the location and the time. The person who found it and any witness are named. A supervisor then reviews the entry and either accepts it into safekeeping or declines it, which keeps a second set of eyes on anything valuable. When the owner comes to collect, the collection is recorded against the same entry so the item’s whole life, found to returned, sits in one place.

The point of recording each step is accountability. Every hand-off has a name and a timestamp attached, so if anything goes wrong the record shows exactly where. In the AVES Found module this is built in: a guard logs the item with its discovered location and date, the item names, any pictures of the discovered item and a witness, and the supervisor accepts or declines it, leaving a clear accept or decline trail. Nothing depends on a guard remembering to write it up later.

What to record in a lost and found log

Keep the fields on your lost and found log tight. Too many and guards skip them; too few and the log cannot settle a dispute. At minimum, capture:

• Item description — what it is, make, colour and any distinguishing marks. “Black wallet, worn corner” beats “wallet”.
• Where it was found — the specific location, not just “reception”. This helps match items to owners who retrace their steps.
• Date and time found — recorded when the item is handed in, not hours later.
• Who found or handed it in — the guard, staff member or visitor, named.
• Witness — a second name adds weight to high-value items and protects the finder.
• Photo of the item — a quick picture removes any argument about condition or which item was handed in.
• Review decision — the supervisor’s accept or decline, so responsibility passes formally into safekeeping.
• Collection details — who collected it and when, closing the entry.

The AVES Found module carries these fields directly: item discovered location and date, the names of the items, a picture of the discovered item, the witness, and the supervisor’s accept or decline trail. Recording a photo and a witness at the point of finding is what turns a note into proof.

Common lost and found log mistakes to avoid

The first mistake is logging late. An item handed in at 9am and written up at 2pm has a five-hour gap no record can explain. Log at the moment of hand-off.

The second is vague descriptions. “Phone” is useless when three phones are handed in the same day. Capture make, colour and a photo so items can be matched and collected without guesswork.

The third is no review step. If any guard can log and release items with no second check, there is nothing stopping an item leaving with the wrong person. A supervisor accept or decline puts a named decision on every valuable item.

The fourth is handing items back without recording collection. An open entry with no collection detail looks, months later, exactly like a lost item. Always close the loop by recording who collected it and when.

The fifth is keeping the log where only one person can see it. A drawer notebook cannot be searched, cannot be reviewed by a supervisor from another site, and is gone if it is lost. A shared, structured record, like a proper security guard logbook, fixes all three.

Frequently asked questions

What should a lost and found log include?

At a minimum: an item description, where and when it was found, who found or handed it in, a witness, a photo, the supervisor’s accept or decline decision, and the collection details when the owner takes it back.

Who should be responsible for the lost and found log?

The guard or reception staff member who receives the item logs it, and a supervisor reviews and accepts it into safekeeping. Splitting logging from review keeps a second set of eyes on valuables.

How long should found items be kept?

This depends on your site policy and any local requirements, so set a clear retention period and record the collection or disposal against each entry so nothing is released or discarded without a trace.

Is a paper lost and found log enough?

A paper log works for very low volumes but cannot be searched, reviewed remotely or backed up, and it offers no photo or timestamp proof. A structured digital log keeps the description, photo, witness and review trail together and visible to supervisors across sites.

See the AVES Found log in action

If found property is slipping through the cracks at your sites, book a 30-minute demo and we will show you the actual AVES Found screen, how a guard logs an item with a photo and witness, and how a supervisor accepts it into safekeeping with a full accept or decline trail.

Book a 30-minute demo →

See more from the team on Instagram. Prefer to try it first? Start free with AVES →

An employee training tracker is a single record of every training a worker has been assigned, requested, completed or still owes, with the dates and status kept against each person so nothing lapses unnoticed.

Most teams do not lose training records because people stop training. They lose them because the proof sits in five places at once: a signed attendance sheet in a drawer, a certificate photo on someone’s phone, a line in a spreadsheet that was last opened three months ago, and a memory that “I think Ravi did that course”. When an auditor, a client or an incident asks who was trained on what, and when, that scatter turns into a scramble.

An employee training tracker fixes the scatter. It is not a course library and it is not a payroll system. It is the running answer to one question a security operation is asked constantly: is this person cleared to do this task today. This guide covers what a good tracker records, why each field earns its place, and a checklist you can use to build or buy one.

Why a training tracker matters

Training is only useful if you can prove it. A guard who completed fire-safety training two years ago may be well past a required refresher, and without a tracked expiry date nobody notices until the certificate is asked for. The gap between “we trained them” and “we can show we trained them, on this date, and it is still current” is exactly where compliance findings, failed client audits and disputed incidents live.

An employee training tracker also protects the worker. When training is requested, accepted and recorded in one place, staff can see what they have been assigned and confirm they have done it, rather than being told after the fact that they missed something they were never clearly given. That accept-and-confirm trail matters as much for fairness as it does for the auditor.

For a multi-site security team, the case for an employee training tracker climbs. A supervisor covering several posts cannot hold every guard’s training status in their head. The tracker becomes the shared source of truth that a site lead, an operations manager and a client can all read the same way.

What an employee training tracker should record

The value of an employee training tracker is in its fields. Record too little and it cannot answer the who-when-still-valid question. Record fabricated detail it cannot back up and it becomes noise. Keep it to the fields that carry weight. At minimum, a training tracker should hold:

• The person — name and staff identifier, and the site or department they belong to, so records can be filtered by post.
• The training — the course or topic name, taken from a defined catalogue rather than free text, so the same course is not logged five different ways.
• Assignment and request — who the training was assigned to, and a record of the worker requesting or being enrolled, so there is a clear start point.
• Acceptance and completion — confirmation that the worker accepted the assigned training and that it was completed, with the date, rather than an unverifiable “done”.
• Status — a single readable state (assigned, requested, accepted, completed) so a supervisor can scan a list and see gaps at a glance.
• Records and evidence — the supporting document or certificate held against the entry, so the proof lives with the record and not in someone’s phone gallery.

If a course expires or needs periodic refreshers, an expiry or next-due marker turns the employee training tracker from a history into an early warning. That single field is the difference between finding a lapse in an audit and finding it a month before it happens.

How an employee training tracker works in practice

The mechanics of an employee training tracker are simpler than the spreadsheet version most teams outgrow. A training is defined once in a catalogue. It is then assigned to, or requested by, a worker. The worker accepts it, completes it, and the completion is recorded against their name with the date and any certificate attached. From that point the entry has a status anyone with access can read, and the record sits under that person permanently.

In the AVES Security app, the Training module follows exactly this flow: workers browse and request trainings, assignments are accepted, and records are kept, with an admin catalogue defining what can be assigned. For a broader view of how this fits together, see our guide to a training management system for security guards. The point is that request, acceptance and the resulting record are one connected trail rather than three disconnected artefacts.

Grounding the tracker in the same system your team already uses for shifts, patrols and reports also removes the second-system problem. It is the same principle behind a well-kept security guard logbook: the record is useful only when it sits alongside the daily work, not in a system nobody opens.

Employee training tracker checklist

Use this to build an employee training tracker from scratch or to judge a tool you are considering:

• Every entry ties to a named person and a staff identifier, filterable by site or department.
• Courses come from a defined catalogue, not free-typed text.
• The tracker records the full path: assigned or requested, accepted, completed, with dates.
• Each entry has a single readable status.
• Supporting certificates or documents are attached to the record itself.
• Expiring or recurring training carries a next-due or expiry marker.
• The record is permanent and readable by supervisors and managers, not owned by one person’s device.

If your current method fails more than one of these, it is a filing habit, not a tracker.

Common mistakes to avoid

The most common employee training tracker failure is the abandoned spreadsheet: accurate on the day it was made, silently wrong a month later because nobody updates it in real time. A tracker only works if the record is created as the training happens, not backfilled from memory.

The second employee training tracker mistake is logging completion with no evidence and no status. “Trained” as a single word proves nothing and cannot survive an audit. Capture the date, the confirmation and the certificate.

The third is treating training as a one-time event. Without an expiry or refresh marker, a completed course quietly becomes an expired one, and the tracker keeps showing green long after the training has lapsed.

The fourth is scattering the record across systems. If the certificate is in email, the attendance is on paper and the status is in a chat message, you do not have a tracker. You have the same scatter you started with, in more places.

Frequently asked questions

What is an employee training tracker?

An employee training tracker is a single, maintained record of every training each worker has been assigned, accepted, completed or still owes, with dates, status and supporting evidence held against each person so nothing lapses without being noticed.

What should a training tracker include?

At minimum: the person and their staff identifier, the course from a defined catalogue, the assignment and acceptance, the completion date, a readable status, and the attached certificate or record. Add an expiry or next-due marker for anything that needs refreshing.

Is a spreadsheet enough to track employee training?

It can start you off, but spreadsheets go stale because they rely on someone remembering to update them, they hold no attached evidence, and they do not signal upcoming expiries. Most teams outgrow them once training has to be provable rather than just noted.

How is a training tracker different from a training course library?

A course library is the catalogue of what can be taught, while an employee training tracker is the record of who did it. A tracker is the record of who was assigned it, who accepted and completed it, and when. You need both, but the tracker is what answers audit and compliance questions.

Why keep training records at all?

Because training that cannot be proven does not count when it matters, and an employee training tracker is what makes it provable. Kept records protect the organisation in audits and disputes, and protect the worker by showing clearly what they were assigned and confirmed.

See it on the real screen

Training only earns its keep when the request, acceptance and record live in one connected trail. Book a 30-minute demo and we will show you the actual AVES Training screen, using your own workflow, so you can see how assignments, acceptances and records stay in one place.

Book a 30-minute demo →

Prefer to explore first? Start a free AVES account →

Follow AVES Security on Instagram.

A policy acknowledgement form is a short record in which an employee confirms they have received, read and agreed to abide by a specific workplace policy. It captures the person, the policy, the date and their acceptance, so the organisation can later prove the policy was communicated and accepted.

Every site runs on policies: how to handle keys, who is allowed where, what to do with a lost visitor pass, how uniform and conduct are expected on duty. The policy acknowledgement form is the small piece of paperwork that turns “we told them” into something you can actually stand behind. This guide covers what the form is, what belongs on it, a simple example, the mistakes that make one worthless and how teams track sign-off once they outgrow paper.

Why a policy acknowledgement form matters

When something goes wrong, the first question is rarely whether a policy existed. It is whether the person involved knew about it. A policy pinned to a notice board or emailed once proves nothing about who read it. A signed acknowledgement does.

For security operations that means real exposure. If a guard mishandles a key, lets in the wrong contractor or ignores a conduct rule, an acknowledgement on file shows the standard was set and accepted before the incident, not invented afterwards. Without it, a dismissal or a client dispute turns into your word against theirs. The form is cheap; not having it is expensive.

What is a policy acknowledgement form?

A policy acknowledgement form is a written confirmation that an employee has received a named policy, understood what it requires and agreed to follow it. It is not the policy itself. It is the receipt that the policy was delivered and accepted, tied to a specific person and a specific date.

A complete policy acknowledgement form establishes four things:

1. Who acknowledged – the employee, identified by name and role.
2. What they acknowledged – the exact policy and its version, so there is no doubt which document.
3. When they acknowledged it – the date, which is what makes the record defensible.
4. That they accepted it – an explicit statement of agreement, not just receipt.

Miss any of the four and the record gets weaker. A signature with no date, or an acknowledgement that does not name the policy version, is easy to dispute.

What to include in a policy acknowledgement form

A good policy acknowledgement form is short. Length is not what makes it hold up; the fields do. At minimum, include:

• Employee name and role – who is signing.
• Policy name and version or date – precisely which document is being acknowledged.
• Acknowledgement statement – a clear line of acceptance (see the example below).
• Date of acknowledgement – when it was signed.
• Signature or digital confirmation – the act of acceptance itself.

Optional but useful: an employee ID or staff number, the department or site, and a line confirming the person had the chance to ask questions before signing. Keep it to one screen or one page. A form nobody finishes gets skipped.

Policy acknowledgement statement example

The heart of the form is the acknowledgement statement. A plain, unambiguous version reads:

I confirm that I have received and read the [Policy Name, version/date] policy. I understand its contents and agree to comply with it as a condition of my role. I understand that failure to follow this policy may result in disciplinary action.

That single paragraph does the work: it names the document, records that it was read, states agreement and sets the expectation clearly. Swap in the real policy name and version and the statement is ready to use.

How to track policy sign-off across a team

One acknowledgement is easy. The problem is the hundredth. Once you are distributing a policy to a whole guard force across multiple sites, the questions change: who still has not signed, which version did each person accept and can you produce every acknowledgement on demand when a client or auditor asks.

Paper and shared spreadsheets struggle here. Forms get signed and filed, but nobody can quickly say who is outstanding, a re-issued policy version leaves old sign-offs looking current, and pulling one person’s history means digging through a folder.

This is where distributing the policy through the system that already runs the workforce helps. In AVES, the Property Policy feature lets you distribute a policy notice that staff must accept, so acceptance is captured in the same platform that holds their duty records rather than in a separate pile of forms. Because the acceptance sits alongside the rest of an employee’s record, policy sign-off lives in the same place as their disciplinary action record or training record rather than in a drawer of loose forms.

Policies themselves usually live alongside your standard operating procedures; the acknowledgement is simply the step that proves each SOP or policy reached the person it was written for.

Common mistakes to avoid

1. No policy version on the form. If the acknowledgement does not name which version was accepted, a later revision quietly makes every old sign-off ambiguous. Always record the version or date.
2. Capturing receipt but not agreement. “I received this” is not “I agree to follow this.” Use an explicit acceptance statement.
3. No date. An undated acknowledgement cannot prove the policy was accepted before an incident. The date is the record.
4. Filing and forgetting. A signed form in a drawer helps nobody if you cannot find it or tell who is still outstanding. You need to know who has not signed, not just who has.
5. Re-issuing a policy without re-collecting sign-off. A changed policy needs fresh acknowledgement. Old signatures do not carry forward to a new version.

Frequently asked questions

What is a policy acknowledgement form?

A short record in which an employee confirms they have received, read and agreed to follow a specific policy, tied to their name and the date, so the organisation can later prove the policy was communicated and accepted.

What should a policy acknowledgement form include?

At minimum: the employee’s name and role, the exact policy name and version or date, a clear acknowledgement statement, the date of acknowledgement and a signature or digital confirmation.

What is a good policy acknowledgement statement?

A plain line such as: “I confirm that I have received and read the [policy] and agree to comply with it as a condition of my role, and understand that failure to follow it may result in disciplinary action.”

Is an acknowledgement form the same as the policy?

No. The policy is the document that sets the rule. The acknowledgement form is the separate receipt proving a named person read and accepted that policy on a given date.

How do you track policy sign-off for a whole team?

Distribute the policy through the system that holds your workforce records so acceptance is captured against each person, rather than collecting loose forms. Keeping acceptance alongside each employee’s record is more defensible than a drawer of signed sheets.

Distributing policies to a guard force and hoping everyone read them? See how AVES lets you distribute a policy notice that staff must accept, captured against each employee’s record instead of on loose forms. Book a 30-minute demo and we’ll walk you through the actual Property Policy screen – or start a free trial.

Follow AVES on Instagram for more security operations guides.