Nothing Borrowed, Nothing Lost: Keeping Account of Site Access in UK Service Work

A key handed over at a site induction rarely feels like an asset. It is a small courtesy, passed across a reception desk with a lanyard and a brief explanation of which door sticks. Months later, that same key can become the most awkward item in a client relationship. Access is the quietest asset a UK service team manages, and the one most likely to prompt a security conversation when it cannot be accounted for.

Access is a loan, not a gift

The useful shift is to stop calling these items equipment and start treating them as loans. A client site pass, a fob for the loading bay, a key safe combination and a door key all belong to the client's premises. The person carrying them is a custodian, not an owner. That distinction matters because loans have terms: who borrowed the item, when it was issued, what it permits, and when it must come back.

Most teams can answer the first question for the people sitting nearby. Fewer can answer it for someone who left three months ago, or for a subcontractor who covered a single weekend. The register exists to close that gap without turning access control into a bureaucratic exercise.

Why access records drift

Drift rarely happens through carelessness. It happens because access is issued in small moments: a new starter arrives, a shift changes, a client asks for cover at short notice. The key is handed over, the job proceeds, and the record is deferred. Three common failures follow.

First, a list of keys exists but not a list of holders. The register says there are four fobs for a building, but not who carries them. Second, names are recorded without dates or permissions, so nobody knows whether a fob still opens the plant room or only the main entrance. Third, the spreadsheet sits with one administrator who is on leave when the client asks for a summary.

None of these failures is dramatic. Together they create a position where the team cannot say, with confidence, what access it holds across a client estate.

Build around the return, not the issue

The register should be designed for the moment an item comes back, or should have come back. Issue details are easy to capture at the start. Return conditions are what make the record useful later.

A practical register carries the following fields for each item: a reference number, the type of access, the client and site, the holder's name and role, the date issued, who authorised the issue, the return trigger, the date returned, and any condition note. For alarm codes, do not write the code itself into a shared spreadsheet. Record that a code exists, who holds it, when it was last changed and where the current version is stored securely. The register is an index of custody, not a vault.

Where a client uses a digital access system, the register should still record the local custodian. The client's system shows permissions. The register shows the human relationship behind them.

Name the return triggers in advance

An item with no return trigger will stay in circulation until someone notices. Four triggers cover most situations in UK service work.

• The holder leaves the team or moves to a role that no longer requires the access.
• The contract ends, is not renewed, or moves to another supplier.
• The site closes, changes hands or undergoes a security review.
• A defined rotation period expires for codes or master keys.

Add a fifth for long absence. A holder on extended leave may still need access on return, but the team should know where the item is while they are away. Each trigger should have a named person responsible for collecting the item and updating the register. Without that name, the trigger is only a good intention.

The quarterly check that takes an hour

A register is only credible if it is tested. Once a quarter, take a sample of items or, for smaller estates, the whole register. Send each holder a short confirmation request: do you still hold this item, and does it still work for the purpose recorded? Check the leavers list against the register. Check any site changes notified by the client. Reconcile the result with the client's own access log where one is available.

Record exceptions in plain language: item not returned, holder unavailable, code changed without notification, fob reported lost. Do not aim for a perfect return. Aim for a register that shows what is known, what is outstanding and who is dealing with it. That is more useful to a client than a clean sheet that has not been checked.

What the client sees

Clients do not usually ask for an access register until something goes wrong. When they do ask, the team that can produce a dated summary within the hour is in a different conversation from the team that has to reconstruct events from memory. The summary need not be elaborate: items held, holders, last confirmation date and open exceptions. It demonstrates that access is being managed as a client asset.

Start with one site. Build the register, test it once, and extend it to the next client when the routine holds. The objective is not to eliminate every key from circulation. It is to ensure that every key has a name against it, a reason to be out, and a route back.