What should be in a facilities asset register

Ask most facilities teams whether they have an asset register and the answer is almost always yes. Ask what's actually in it and the answer gets vaguer — a spreadsheet started by someone who's since left, half-updated, with some buildings covered in detail and others barely represented at all. An asset register that's just a list of names and locations is a start, but it's missing most of what makes a register genuinely useful.

Location and access, not just an asset name

"Boiler 2" tells an engineer almost nothing on a busy morning. A working register records exactly where an asset is — building, floor, room, or plant area — and anything relevant to reaching it: whether it needs a key, sits behind a locked riser, or requires isolating something else first. This sounds like a small detail until someone's standing in front of the wrong door at 7am with a contractor waiting.

Criticality, tied to consequence of failure

Not every asset matters equally, and a register that treats them as equally important is quietly making a bad prioritisation decision by default. We've written separately about rating asset criticality in more depth, but the short version is: record what actually happens if this fails, not just what it is, because that's what should drive how urgently it gets attention when something does go wrong.

Service history, not just the next due date

A register that only shows the next scheduled date is missing the context that makes that date meaningful. Has this asset been reliable, or has it had three call-outs in the last six months? Service history turns a register from a static list into something that actually informs decisions — including, eventually, whether an asset is worth repairing again or should be flagged for replacement.

• –Manufacturer, model and serial number, so the right parts and the right manual can be found without guesswork
• –Installation date and expected service life, as a rough guide to when replacement conversations should start
• –Which building and area the asset sits in, matched to how a multi-site team actually organises its work
• –Any statutory inspection obligation attached to the asset — lifting equipment and pressure systems being the obvious examples
• –Warranty status, where it's still relevant, so a call-out doesn't get billed when it shouldn't be

Keeping it current is the actual hard part

Building a register once is a project. Keeping it accurate as assets are added, removed, moved between buildings, or quietly replaced by a contractor without anyone updating the record is the ongoing discipline that most teams struggle with. A register that was accurate on the day it was built and hasn't been touched since is, within a year or two, actively misleading — confidently wrong is worse than visibly incomplete, because nobody thinks to double-check it.

The teams that keep a register genuinely current tend to be the ones where updating it is a normal part of closing out a job, not a separate task someone has to remember to do later — which is really the same discipline that makes a PPM schedule stick in the first place.

Why registers rot rather than break

An asset register is almost never wrong on the day it is built. It degrades through ordinary events that nobody thinks to record: a unit replaced under warranty with a different model, a plant room renumbered during a refurbishment, an asset decommissioned and left in place, a contractor fitting a replacement and taking the old serial plate with them. Each is individually trivial and none generates a prompt to update anything.

Two years on, the practical symptom is an engineer standing in a plant room unable to match what is in front of them to any row in the register. At that point the register is not a record of the estate; it is a record of the estate as it was when somebody last walked it. Building the walk into a routine — a proportion of assets physically verified each quarter — is duller than a data-cleanse project and considerably more effective.

Common mistakes

• –Recording an asset name without the location detail needed to find it
• –No process to update the register when an asset is replaced or decommissioned
• –Leaving decommissioned assets in place and in the register, so tasks keep generating against them
• –Holding serial and model numbers only in the original commissioning pack
• –Never physically verifying the register against the building
• –Treating the register as a one-off project rather than something with continuous upkeep