Gate System Access Roles | Priority Service

Start with decisions, not job titles

A vehicle gate system may describe its users as guards, supervisors and administrators, but those labels are only useful when each one maps to defined decisions. A guard needs to process the vehicle in front of them. A supervisor may need to decide an exception. An administrator may need to configure sites, gates and staff or review records. If everybody receives the highest role because it is convenient, the organisation loses meaningful separation and increases the effect of mistakes or a compromised account.

The National Cyber Security Centre's cloud guidance recommends granular access control following the principle of least privilege, with standard and administrative accounts. In plain operational terms, give each person the access needed for their work and no more. The buyer should therefore write a role matrix before configuring the system, rather than accepting a collection of broad accounts and trying to impose control later.

Begin with actions: capture a vehicle, correct a registration, record IN or OUT, view a permit, refer an unknown vehicle, approve or decline that referral, manage staff, manage sites and gates, review history and export reports. For each action, record who normally performs it, who can authorise an exception, which sites they may access and who reviews their activity. Then compare that matrix with the product's demonstrated permissions.

Give guards the access needed for the live gate

The guard role should support the immediate gate task without exposing organisation-wide administration. On Priority Service's published workflow, the guard signs in, captures a vehicle and number plate, checks or corrects the registration, reviews permit information and records IN or OUT. A vehicle requiring approval can be referred to a supervisor. Those are operational activities performed at the point of entry or exit.

The important control is that the record remains attributable to an individual account. NCSC guidance for small organisations says each person should have their own work account and that multiple users should not share one. Shared accounts make it harder to connect actions to a particular person and can expose more data if the credential is compromised. A gate phone can be shared equipment; the account used on it should still identify the guard on duty.

Avoid giving guards administrator access merely to solve a roster, password or site-assignment problem. That shortcut can allow routine users to change configuration or see records beyond their duties. Instead, define an escalation route and make sure authorised support is available during the hours the gate operates. If a guard covers another location, assign only the necessary site or gate access for the required period where the product and customer process allow it.

Make supervisor approval a real decision

A supervisor role is useful when it separates the guard who presents an exception from the person authorised to decide it. Examples include an unknown vehicle, a permit mismatch or an arrival outside the expected window. The supervisor should receive enough reliable context to decide under the site's policy, but approval should not become a reflex response to a queue at the gate.

Define the limits of supervisor authority. Can any supervisor approve for every site, or only for assigned locations? Can they change a permit, or only decide the current referral? Can they view historical records, and for what operational purpose? Can they override a refusal required by the client? These are procurement and configuration questions. Priority Service advertises supervisor approvals and distinct staff roles, but its public pages do not publish a complete permission table. Buyers should verify the exact boundaries during the demonstration and reflect them in their own written procedure.

Supervisors should use their own accounts too. Do not keep a generic 'duty supervisor' password on a desk or in a messaging group. If the person on call changes, the rota and account assignment should change rather than the credential being handed over. The decision record is most useful when the organisation can establish who made it, at which site and in response to which vehicle event.

Protect administrator access as a higher-risk capability

Administrators may be able to manage staff, sites and gates and review or export organisation records. That makes the role materially more powerful than the guard workflow. The NCSC warns that compromised administrator accounts can expose more data and cause more damage than standard accounts. Its guidance recommends protecting powerful accounts and, for wider identity management, using privileged accounts only when necessary rather than for routine activity.

Keep the number of administrators small enough to justify individually. Record who approved each appointment, what scope the person needs and when it should be reviewed. Where a person performs both operations and administration, use the product and organisational controls available to keep those activities distinct. Do not browse, read email or perform unrelated work using a powerful administrative identity if a normal account is appropriate.

The ICO's access-control guidance expects organisations to assess and assign privileged access, restrict systems processing personal information according to least privilege, and use formal provisioning procedures for staff, temporary workers and contractors. Vehicle photographs, registrations and visit records can include personal information depending on context, so access should be based on a defined purpose rather than curiosity or seniority. The customer's data controller remains responsible for deciding what access is appropriate to its risks and uses.

Run a joiner, mover and leaver process

Role design fails if accounts are not maintained. A joiner should receive an individual account only after their identity, employment or assignment and required sites have been confirmed. A mover who becomes a supervisor, transfers to another client site or returns to guard duties needs their permissions changed, not simply added to. A leaver's access should be removed promptly at the end of the authorised assignment.

Create one owner for the account lifecycle. For a security company, decide whether the contract manager, control room or central administrator requests and approves changes. For an in-house team, that may sit with security management and HR. Require enough notice for planned changes, but keep an emergency process for suspension after dismissal, lost credentials or a suspected compromise. The process should also cover agency guards, temporary cover and administrators supplied by a contractor.

Review access on a schedule and after significant changes. Ask whether every active user still works for the organisation, still needs the assigned role and still needs every site listed. The ICO's data protection by design guidance specifically points to processes for granting or revoking access when staff change roles or leave. A quarterly review may suit one operation while a more dynamic contractor workforce may need checks more often; set the interval according to risk rather than copying a generic calendar.

Secure the account as well as the permission

Correct permissions do not help if credentials are weak, shared or left signed in on an unattended phone. The NCSC advises securing important online accounts with strong, unique authentication and two-step verification where supported. It also advises using devices that are kept updated and protected. Buyers should ask which authentication protections the product supports and configure the strongest practical option available; do not assume an unadvertised feature exists.

At the gate, define how a shift change handles the device. The outgoing guard should finish or hand over open operational work, then sign out or follow the approved account-switching process. The incoming guard signs in using their own identity. Screen locks, device ownership, app updates, lost-device reporting and charging arrangements belong in the local operating procedure. A handwritten password attached to the device defeats the accountability the role model is meant to provide.

Plan account recovery before it is urgent. Decide who can reset a guard's access, how the requester's identity is checked and how a compromised administrator account is escalated. NCSC cloud guidance highlights the customer's continuing responsibility to configure and use a service securely. A supplier can provide roles and authentication mechanisms, but the customer still controls whom it appoints, how promptly access changes and whether unsafe sharing is tolerated.

Test the role model during the buying process

A useful demonstration should use at least three separate test identities. Ask the guard to record a normal arrival, correct a deliberately misread registration and refer an unknown vehicle. Ask the supervisor to make the referral decision. Ask the administrator to locate the visit, show the available filters and export route, then manage a test user's assignment. At each stage, try an action that role should not perform and confirm how the system responds.

Also test scope. A security company may operate several client locations, while an in-house team may have multiple gates at one site. Confirm which records each role can see across sites and gates, how temporary cover is assigned, what happens when a supervisor is unavailable and what evidence remains after an account is removed. Do not judge the design only by whether an authorised task succeeds; verify that unnecessary access is absent.

Priority Service's current feature summary is at https://priorityservice.co.uk/#features. The simulated entry and exit workflow at https://priorityservice.co.uk/demo shows an individual guard account, vehicle capture, permit review and the resulting management record. Use the enquiry at https://priorityservice.co.uk/#demo to request a live role-based walkthrough against your proposed guard, supervisor and administrator matrix.