Gate system outages: a fallback and recovery plan for UK sites

The real question is how the gate recovers

A lost connection is not just an IT problem when vehicles are arriving at a manned gate. The guard may be unable to retrieve a permit, request approval or establish whether the last movement was saved. A paper sheet can preserve observations, but it cannot automatically restore those missing decisions. The operational question is therefore: how will the site continue safely, retain trustworthy records and return to its normal process without inventing a history?

This guide proposes a practical fallback procedure for UK security providers and organisations managing their own premises. It is not a claim that Priority Service works offline. Its published features describe Android capture, checked registrations, permits, supervisor approvals and administrator reporting; they do not advertise offline saving or automatic synchronisation. Treat those capabilities as unconfirmed unless demonstrated and agreed for your deployment.

The primary guidance linked below was checked on 16 October 2026. The gate-specific steps are operational recommendations to adapt through your site's risk assessment, client instructions and data responsibilities.

Define the failure and the point of transfer

Separate four situations in your procedure: one phone fails; connectivity fails; the application cannot be reached; or only a supporting vehicle-data lookup is unavailable. They do not necessarily require the same response. A missing lookup result is not proof that the vehicle is unsuitable, and it does not establish whether the movement-recording service is also unavailable. Check the actual failure rather than treating every error as a complete outage.

Give guards a short activation rule. For example, after an unsuccessful save, they stop repeated submissions, note the registration and observed time, notify the supervisor and use the authorised fallback while an administrator checks the record. The precise trigger should be tested locally; it is not a universal retry count or service promise.

Name who can activate the fallback and who can restore normal operation, with deputies. NCSC guidance recommends identifying critical information, documenting responsibilities and planning incident trigger points. Keep the contact route accessible when the affected app or usual communication channel is unavailable.

Prepare a fallback pack that does not depend on the failed system

Prepare a controlled pack at each gate rather than asking guards to improvise a spreadsheet. Include the current procedure, an escalation contact list, a numbered temporary movement sheet, the approved traffic and waiting instructions, and access to any authorised spare device. Check chargers and the spare's account assignment during routine supervision, not only after a failure.

For a movement sheet, consider a sequence reference, date, observed time, IN or OUT, registration, site and gate, recorder, decision reference and reconciliation status. Only include fields needed for your stated purpose. ICO data-minimisation guidance requires information to be sufficient and relevant without collecting more than necessary. A network outage is not a reason to copy driving licences or photograph identity documents by default.

Make version ownership explicit. A printed instruction with an obsolete supervisor number is not a working contingency. Hampshire County Council's business-continuity guidance emphasises resources, responsibilities, testing and review. Apply that to the actual pack: who checks it, when, and after which operational changes?

Preserve admission authority when the screen is unavailable

A familiar registration, yesterday's permit or a driver's statement that someone approved entry should not silently replace the site's current authorisation rule. Agree which arrivals can be handled under an existing written contingency and which require a fresh decision from an authorised person. If that person cannot be reached, follow the site's safe waiting, refusal or rescheduling procedure rather than letting queue pressure decide.

Where verbal approval is permitted, record the decision-maker, time, scope and temporary reference through the approved process. Read back the relevant registration and destination. Do not label a vehicle as electronically approved when the normal electronic check was unavailable; preserve the distinction between what staff observed and what someone authorised.

For a guarding contractor, agree this authority with the client before an outage. The contract manager should know which decisions remain with the premises operator. Temporary recordkeeping is a continuity measure, not an expansion of a guard's authority.

Keep the fallback inside the traffic plan

Slower recording can create an unsafe queue before the technical problem is understood. Set out where vehicles may wait, who tells the receiving team about delays, and when arrivals should be paused or rescheduled. Use the site's assessed traffic arrangements; do not create an improvised waiting area on a pedestrian route or send drivers into an unassessed reversing movement.

HSE's delivery guidance stresses cooperation between suppliers, carriers and recipients, clear responsibilities and agreed safety arrangements. The practical implication during an outage is to communicate changed arrival arrangements to the people sending and receiving vehicles, not just the guard at the entrance.

If safe arrangements cannot be maintained, escalate the operational restriction. Recording fewer fields or moving to paper does not make an unsafe manoeuvre acceptable. An outage procedure should also leave emergency routes and the site's emergency response arrangements intact; it must not turn a routine recording problem into an obstruction.

Reconcile uncertain saves before adding missing records

The highest-risk recovery mistake is assuming that an error message means nothing was saved. A request may have reached the service before the phone lost its response. The opposite mistake is assuming that a visible form or remembered tap proves the record exists. Mark these movements as uncertain until an authorised person checks the saved history.

Agree a recovery sequence: establish the last confirmed normal record; identify the fallback period at each gate; compare temporary sheets with available digital records; investigate possible duplicates and unmatched IN or OUT events; then sign off exceptions. Match more than the registration alone. The same vehicle can make several visits, so direction, gate, observed time and visit context matter.

Keep the observed movement time separate from the later transcription time. Before live use, establish how the system can represent delayed records without mislabelling their time or recorder. Priority Service's published pages do not promise bulk import, retrospective timestamp editing or an automatic merge facility. If those are needed, ask for a demonstration; do not manufacture ordinary live events to make a report appear complete.

Where the software cannot represent a temporary event faithfully, retain the approved fallback record and a controlled reconciliation note under the organisation's policy. Leave unresolved departures explicitly uncertain rather than guessing an OUT time. Recovery succeeds when the record is understandable, not when every row looks tidy.

Distinguish an operational outage from a security incident

A flat battery and a missing signed-in phone require different escalation. For loss, suspected account misuse or unusual record changes, involve the responsible manager and IT or security contact promptly. Do not ask guards to investigate by sharing credentials, installing unapproved tools or sending screenshots to personal accounts. The NCSC recommends connecting incident response with continuity and recovery plans, and defining who can authorise consequential actions.

An unavailable service is not automatically a reportable personal data breach. However, the ICO explains that breaches can affect confidentiality, integrity or availability. The responsible organisation should assess what happened and the risk to people, record any personal data breach and its response, and determine notification duties.

For a notifiable UK GDPR breach, notify the ICO without undue delay and within 72 hours of awareness; do not wait for a complete investigation. High-risk breaches also require informing affected individuals without undue delay. A processor must notify its controller without undue delay. Escalate early enough for that assessment rather than deciding at the gate that a technical fault has no privacy implications.

Rehearse an outage that crosses gates and shifts

Use a fictional drill: at 10:02 a guard attempts to record a van IN, but the confirmation does not arrive. At 10:05 fallback recording starts. The van leaves through another gate at 10:18. Normal access returns at 10:30, just before relief arrives. Do not assume whether the first save succeeded; make the team establish it during the exercise.

Check whether the second gate knew fallback was active, whether both movements have usable references, who authorised admission and who owns reconciliation after the shift change. Ask an administrator to explain the visit from the available records. A drill fails if the explanation depends on the outgoing guard remembering what happened.

Set observable acceptance criteria: staff can find the pack and deputy contacts; no approval is invented; uncertain saves are checked; duplicate candidates are resolved or assigned; and the recovery owner signs off outstanding discrepancies. Council guidance recommends testing and maintaining continuity plans. NCSC guidance likewise recommends practising incident response. Repeat the exercise after material changes to gates, staffing or the application.

Make the demonstration test the limits as well as the normal visit

Priority Service's published feature summary at https://priorityservice.co.uk/#features covers vehicle photographs, registration checking and manual entry, time-stamped IN and OUT records linked to sites, gates and guards, supervisor approvals and CSV reporting for authorised administrators. Manual registration entry should not be confused with offline operation, and a CSV export is not a promise of a full restorable system backup.

Bring your outage scenario to a demonstration: what happens if the connection disappears before a save, how is success confirmed, what can administrators check, and how should temporary records be retained? Ask which behaviour has actually been tested on your proposed Android devices and site connectivity.

Request a walkthrough at https://priorityservice.co.uk/#demo and discuss preparation through https://priorityservice.co.uk/setup-and-training. Agree the normal workflow and the fallback boundary before live use. A credible buying decision includes what the product does not promise, who owns recovery and how the site will prove that its record remains reliable.

Vehicle logging for your operation

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

Explore gatehouse management software