SOP for Security Services Clients: Shifts, Incidents, Handover

When delivery happens alone, at night, off site, the written procedure is the entire supervision.

SOP for security services: the procedures a guarding operation runs on

A security services business is unusual among service providers in that almost all of its delivery happens away from the office, at odd hours, performed by people who are alone. There is no manager glancing over a shoulder, no shared screen, and often no reliable connectivity. Whatever the written procedure says is, in a very literal sense, the entire supervision.

That shifts the question from how to write a good procedure — which is a general craft, covered in the structure that makes any procedure runnable — to which specific procedures this vertical cannot operate without, and how each one gets prompted and recorded when the person doing it is standing in a car park at four in the morning.

Post orders are not the same thing as an SOP

The distinction matters enough to get right before anything else is written. Post orders are site-specific: what this location requires, which doors, which patrol route, who the contact is, what the client has asked for. They change when the client changes something. A procedure is company-wide: how a handover is performed, how an incident is graded, how an escalation is made. It changes when the business changes how it works.

Collapsing them produces the two failure modes you see most often. Site detail buried in a company procedure means the procedure has to be edited every time a client moves a gate. Company rules copied into every site’s post orders means a change to the escalation policy has to be made in as many places as you have sites, and it will not be.

The small set of procedures worth writing first

Seven procedures cover the overwhelming majority of what a guarding operation actually does. Writing those seven well is worth more than a library covering every situation, because these are the ones that run every day and the ones a client will ask about.

Check-in is the procedure everything else depends on

The check-in is what turns a schedule into a fact. Without it, nobody knows whether the site is covered until somebody notices it is not — usually the client.

Design it around the cut-off rather than around the check-in. The procedure that matters is what happens when the confirmation does not arrive: how long the system waits, who gets told, in what order, and how long they have before the next person is told. That escalation ladder should be written as times and roles, because at three in the morning nobody is going to improvise a good one.

The same discipline that governs a response commitment on an inbound message applies here, and for the same reason: a promise without a timer measuring it is a hope. A timer attached to the record is what converts “someone should have noticed” into something that either fired or did not.

Night contact needs its own decision

An operation that runs overnight will be messaging staff at hours when automated messages normally should not go out. Decide explicitly which of your sends are operational and person-triggered and which are automated marketing, and make sure the send window that governs automated messaging is not silently applied to a cover callout, or silently bypassed for a promotion.

Incident grading is what makes escalation possible

Escalation policies fail when they depend on the officer’s judgement about whether something is serious. Judgement varies by person, by tiredness and by how much they want to avoid waking a supervisor.

Replace it with a grade that comes from observable facts: was anyone hurt, was property damaged, was entry gained, is the situation ongoing, are emergency services involved. Each grade maps to a defined action — log only, notify the duty supervisor, call the client contact, call emergency services first and report after. The officer’s task becomes describing what they observed, which is a much more reliable thing to ask of someone at the scene.

Two practical constraints on the report itself. Keep it short enough to complete on a phone with one hand, because a form that takes ten minutes gets completed later from memory, which is worse than a brief one completed now. And separate what was observed from what was concluded, because the two get merged otherwise and the record stops being useful the moment anyone disputes it.

Handover is where information goes missing

Most operational failures in a guarding contract trace back to something one shift knew and the next did not: a door that has been left unlocked all week, a contractor expected in the morning, a camera that has been offline since Tuesday. Verbal handovers do not survive a shift change where the two people never overlap.

Make the handover an artefact rather than a conversation: a short written summary produced at the end of every shift and acknowledged by the incoming officer. The acknowledgement is the part people skip and the part that matters — without it you have a note nobody read.

Where the procedures live and how they get recorded

The document explains; the system prompts and records. For this vertical the mapping usually looks like this: the schedule holds shifts and assignments, timed prompts push the check-in and round reminders, forms capture incidents and handovers, and a durable log holds the record of what happened so it survives someone deleting a message thread.

That last part is worth building deliberately. An operation whose only history lives inside a messaging app cannot answer a question three months later, which is exactly what an append-only activity log is for. Log the event, the site, the person, the time and the outcome; keep the narrative detail in the incident record it belongs to.

Bringing a new site or a new officer into the system

Two onboarding paths, and both should be checklists rather than conversations.

• A new site. Post orders written and reviewed with the client, contacts and escalation ladder recorded, access arrangements confirmed, schedule built, first-week review booked. This is the same shape as any client onboarding checklist, with the site detail substituted for the marketing detail.
• A new officer. Licensing and eligibility verified according to whatever the local requirements are, company procedures walked through rather than emailed, site-specific post orders read at the site, first shift paired or supervised, and a check on the first solo shift.

Licensing rules for security work differ by country and often by state or region, and they change. Treat verification as a recorded step with a date and a review, not a one-off at hiring.

What goes wrong most often

• Procedures written for the office, not the field. If it cannot be completed on a phone, at night, standing up, it will not be completed.
• No cut-off on the check-in. The absence of a message is information, and nothing is watching for it.
• Grading left to judgement. The same event gets reported differently by different people, so escalation is inconsistent.
• Handover with no acknowledgement. Written, unread, and treated as done.
• Site detail inside company procedures. Every client change becomes a rewrite of the procedure.
• The record lives in a chat thread. It is not searchable, not durable, and not something you can show a client.

Frequently Asked Questions

What is the difference between post orders and an SOP?

Post orders are site-specific: what this location needs, which doors and routes, who the contact is, what the client has asked for. A procedure is company-wide: how a handover is done, how an incident is graded, how an escalation is made. Keeping them separate means a client moving a gate does not require editing a company procedure, and changing the escalation policy does not require editing every site’s post orders.

Which procedures should a security services business write first?

Seven cover most of what a guarding operation does daily: shift check-in, patrol or check rounds, incident reporting, escalation to the client, shift handover, no-show and cover, and equipment issue and return. Writing those well is worth more than a large library, because these are the ones that run every day and the ones a client will ask you about.

How should a missed shift check-in be handled?

Design the procedure around the cut-off rather than the check-in itself. Define how long the system waits before the absence counts as a problem, who is told first, how long they have to respond, and who is told next. Write it as times and roles, because nobody will improvise a good escalation ladder in the middle of the night. The absence of a message is information, so something has to be watching for it.

How do you make incident escalation consistent?

Take the judgement out of it. Grade incidents from observable facts such as whether anyone was hurt, whether property was damaged, whether entry was gained, whether the situation is ongoing and whether emergency services are involved. Map each grade to a defined action. The officer’s job becomes describing what they saw, which is a far more reliable thing to ask of someone at the scene than deciding how serious it is.

What should a shift handover contain?

A short written summary at the end of every shift, and an acknowledgement from the incoming officer. The acknowledgement is the part that gets skipped and the part that matters, because without it you have a note nobody read. Verbal handovers do not survive a shift change where the two people never overlap, which is where most operational surprises in a guarding contract come from.

Should incident reports be filled in on a phone?

Yes, and the form should be designed for it. A report that takes ten minutes gets completed later from memory, which is worse than a brief one completed at the time. Keep it short enough to finish one-handed, and separate what was observed from what was concluded, because those two get merged otherwise and the record loses its value the moment anyone disputes it.

Where should the operational record be kept?

Somewhere durable and searchable, not in a messaging thread. An operation whose history lives in a chat app cannot answer a question three months later, and cannot show a client anything. Keep an append-only log of the event, the site, the person, the time and the outcome, and leave the narrative detail in the incident record it belongs to.

We build your GoHighLevel account for you

CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.

• Setup (one-time)$850
• Ongoing (per month)$38.80

Get my free setup quote

No obligation quote · reply within 1 business day

This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.