Multi-site vehicle logging: a rollout plan for UK security companies

Pilot one operating model, not one identical gate

A security company can use one digital vehicle register across several client locations without pretending every gate works the same way. The useful objective is consistency in the record: who recorded the movement, at which site and gate, when it happened, which registration was confirmed and how an exception was approved. The local procedure around that record can still reflect the client's access rules, vehicle routes and escalation contacts.

This distinction should shape the pilot. Do not begin by copying the first site's instructions to every contract. Begin with a common minimum workflow, then document the site-specific decisions that sit around it. Priority Service's published features organise sites, gates and staff and record vehicle movements against the site, gate and guard. They do not replace the client's local transport plan, risk assessment or authority structure.

Choose a pilot site that will expose problems

The easiest gate is not necessarily the best pilot. Choose a live but manageable location that handles more than one normal arrival type, such as staff vehicles, contractors and deliveries. Include at least two guards and a supervisor so the test covers a handover and an approval decision. Avoid starting simultaneously at every client site; that multiplies unresolved questions before the operating model is stable.

Write down what success means before the first shift. Suitable operational tests include completing an expected entry and exit, correcting a deliberately misread registration, referring an unknown vehicle, finding a movement later and producing a limited report. Add a device or connectivity interruption exercise, but confirm the application's actual behaviour with the supplier rather than assuming an offline capability.

Agree responsibilities with the client before configuration

HSE guidance for shared workplaces says employers need to co-operate and co-ordinate their measures and tell each other about relevant risks. HSE workplace transport guidance also says the site operator should provide contractors with appropriate information about the workplace, routes, vehicles, hazards and other people on site. In practice, the security provider needs a named client decision-maker before it configures the gate workflow.

Create a short responsibility table covering who defines the access rule, who approves an unknown vehicle, who changes permits, who investigates a missing OUT record, who authorises a report and who owns the device. Resolve the awkward cases as well as the normal ones: no client contact answering, a substitute delivery vehicle, an instruction that conflicts with the written procedure and a vehicle leaving through another gate.

The HSE sources cited apply in Great Britain. A deployment in Northern Ireland should be checked against HSENI guidance and the client's local arrangements. The operational principle remains the same: the software record must sit inside an agreed division of responsibilities.

Separate the standard workflow from the site profile

Keep the common guard workflow short: sign in with the assigned account, choose the correct gate, capture or enter the registration, check the result, review the relevant permit or approval status and record IN or OUT. Priority Service advertises photo-based number plate reading with manual correction, vehicle permits, supervisor approvals and time-stamped movements. These are the parts that can be demonstrated consistently.

Build a separate one-page profile for each site. It should identify the gate names, permitted categories, local approval contacts, safe stopping point, route restrictions, expected handover method and what the guard does if the application or device is unavailable. This profile is an operating document agreed with the client; it is not generated automatically by the features currently advertised.

Use the same terms across training, the site profile and the application. If one contract calls a person a supervisor while another gives that person no approval authority, guards will learn the wrong lesson. Names can differ, but the decision rights must be explicit.

Consult guards before the procedure is final

HSE guidance says consultation should cover changes that may substantially affect health and safety, including new procedures, equipment, ways of working and the consequences of new technology. It also recommends involving employees in risk assessment because they understand the work, shortcuts and practical problems.

Run the draft workflow with the guards who will use it at night, in poor weather and during busy arrivals. Ask where they can safely take a photograph, whether the screen terms match the language used at the gate, how they know which site or gate is selected and what happens during a queue. Consultation is not a vote on whether records should be accurate; it is a way to find flaws before those flaws become normal practice.

Record the changes arising from the pilot. If guards repeatedly bypass a step, test whether the instruction is unclear, the configuration is wrong or the site's process is unrealistic. Merely telling them to be more careful is not a rollout plan.

Train decisions, not only button presses

A five-minute demonstration can teach where to tap, but it does not establish competence in the complete gate procedure. Training should cover a normal arrival, a departure, a plate-reading correction, an existing permit, a vehicle requiring referral, a shift handover and the local fallback process.

Use fictional vehicles during training and ask the guard to explain the decision aloud. The key checks are whether they verify the registration before saving, understand that a recorded plate is not automatic permission to enter, use the correct approval route and record the departure consistently. Managers should also practise finding a record and exporting only what is required.

Give the client supervisor the same scenario pack. If the guard and supervisor interpret an unknown vehicle differently, the pilot has found a governance problem rather than a software defect.

Configure accounts and devices as an ongoing control

NCSC guidance for software as a service says customers retain responsibility for configuration specific to their use. It recommends managing onboarding and offboarding, authenticating users robustly, protecting administration, assigning appropriate permissions, using trusted devices and planning incident response. An unlimited-user price should never be interpreted as unlimited access.

Create individual accounts for active staff and assign only the responsibilities they need. Decide who can administer sites and gates, who can approve vehicles and who can review or export records. Remove or suspend access promptly when a guard leaves a contract or changes role. Include agency and relief staff in the process; short assignments are not a reason to share one generic login.

Use supported, updated Android devices with screen locks and a clear loss-reporting route. Decide whether the client or the security provider owns the handset, mobile connection and replacement stock. During the demo, ask to see the roles that matter to your operation rather than viewing every screen through a single administrator account.

Settle the data relationship in the contract

A multi-site rollout can involve the client, security company and software provider in processing vehicle registrations, photographs and visit information. The ICO says a controller must choose processors offering sufficient security guarantees, and a written controller-processor contract must cover documented instructions, confidentiality, security, sub-processors, individual rights, assistance, end-of-contract treatment and audits.

Do not copy job titles into the data agreement and assume the roles are solved. Identify who decides why the vehicle records are collected, who sets retention and disclosure rules, and who acts on whose instructions. Align the software arrangement with the security contract, particularly where one security company serves several unrelated clients.

Before expansion, confirm how data is returned or deleted when a site contract ends and how rights requests or incidents are routed. The detailed retention choices belong in the site's privacy and records process; today's rollout decision is to make sure ownership and assistance are contractually clear.

Use a two-stage acceptance review

At the end of the first operating week, review exceptions with guards and the client contact. Look for wrong gate selections, uncorrected registrations, missing departures, repeated referrals and exports that contain more information than the recipient needed. Numbers alone need context: a high referral count might indicate cautious guards, an incomplete permit list or an unclear access rule.

Then run a formal acceptance exercise using the scenarios agreed before launch. A sensible go-live decision requires the workflow to work across shifts, administrators to retrieve the required records, account changes to be understood and the fallback procedure to be usable. Keep unresolved critical issues visible instead of declaring success because normal entries were easy.

Agree what will be reviewed after 30 days: access lists, site contacts, permit maintenance, training gaps, report use and device problems. NCSC guidance stresses maintaining security over time; configuration is not finished on launch day.

Expand site by site with controlled differences

Once the operating model passes, create the next site's profile and repeat the local checks. Reuse the common training scenarios, account process and acceptance criteria, but validate the client's routes, categories, contacts and reporting needs. This is faster than inventing each rollout from scratch and safer than assuming every gate is interchangeable.

Priority Service's published multi-site capabilities include organising sites, gates and staff, reviewing shift and vehicle activity, supervisor approvals and CSV reports for authorised administrators. Use Explore the app features below to compare those capabilities with your rollout plan. Do not infer automatic barrier control, fixed-camera integration, people roll-call or other functions the site explicitly does not advertise.

Use Request a demo to bring one real site profile and one difficult exception. Ask to see the guard's capture and correction, the supervisor's decision and the administrator's later review. A useful demonstration should expose where your client procedure ends and the application begins.

A practical pre-rollout checklist

Before adding the next site, confirm six things: a named client owner; agreed gate and approval rules; trained guards and supervisor; individual accounts with appropriate access; managed devices and a tested fallback; and contractual clarity for vehicle data. Also confirm the acceptance scenarios and review date.

If any one of these is missing, expansion increases operational inconsistency rather than reducing it. The best multi-site system is not the one configured fastest. It is the one whose common record can survive different gates, relief staff, client exceptions and later scrutiny without people having to guess what happened.

Sources below were checked on 8 October 2026. HSE and ICO pages should be revisited when the client's legal or operational context changes, and the NCSC recommends checking that a SaaS service remains consistent with the security claims relied upon because services evolve.

Vehicle logging for your operation

Explore the workflow, plans and demo options for your team.

• Security companies

Explore gatehouse management software