Asset Tagging

Back to Data Center Management · Rack Elevation Diagrams · Cable and Port Documentation · CMDB · Service Offerings

Asset tagging means every server, switch, and PDU labeled and tracked with make, model, and serial number. It is the least glamorous item in data centre management and the one everything else rests on: a rack elevation, a cable record, and a CMDB entry all have to point at something, and the asset tag is that something.

It is also the item most often done once and never maintained. A room full of correctly labelled hardware with a two-year-old spreadsheet behind it is not an inventory — it is a collection of stickers. The work that matters is not the first pass. It is what happens at every change afterwards.

1. The Tag Is an Identifier, Not a Label

The point of an asset tag is to provide a stable key that belongs to you and survives the asset's whole life. That is a different job from the identifiers already present on the hardware, and conflating them is the usual first mistake.

Record the vendor serial as well — warranty and support lookups need it, and it is the only way to prove which physical unit you hold. But do not make it the key. When a motherboard is replaced under warranty the serial can change while the asset does not, and anything keyed on the serial then quietly points at a machine that no longer exists.

2. What to Record Against the Tag

• Identity — asset tag, make, model, vendor serial or service tag.
• Location — site, room, rack, and the rack units occupied. This is the field that feeds rack elevations, and the one most likely to be stale.
• Lifecycle — purchase date, warranty expiry, expected end of life, current status. Status matters more than people expect; see section 5.
• Ownership — which team is accountable for it, and who signs off on taking it out of service.
• Role — what it currently does, kept deliberately brief. Deep role modelling belongs in the CMDB, not the asset register.
• Physical facts — rack units, depth, weight, power draw, power connector type. Dull until the day you are planning an install and need all four at once.

Resist adding fields that nobody reads. Every attribute is a maintenance obligation, and an inventory with twelve accurate fields is worth more than one with forty, nine of which are wrong.

3. Putting the Label on the Hardware

• Front and rear, both. You read the front when you are looking for a machine and the rear when you are working on its cabling. A front-only label means crawling behind the rack with a torch at the exact moment you are least inclined to.
• Make it machine-readable. A barcode or QR code alongside the human-readable text turns an audit from a typing exercise into a walk with a scanner. This is what makes reconciliation (section 4) cheap enough to actually happen.
• Use labels that survive the environment. Polyester or vinyl with a permanent adhesive. Paper labels in a warm aisle curl and fall off within a year, and the ones that fall off are the ones nobody notices.
• Mind where it goes. Not over vents, not on a removable bezel, not on the rails, not on a drive caddy that will be swapped. The label belongs on the chassis itself.
• Tag the unglamorous things too. PDUs, patch panels, console servers, transceivers in long-lived links. These are precisely the items missing from most registers, and precisely the ones nobody can identify at 3am.

4. The Part That Fails: Keeping It True

Labelling a room takes a few days. Keeping the register true takes a process, and this is where the exercise usually collapses. Two things make the difference.

• The record is updated as part of the work, not after it. If moving a server requires a change ticket, updating its location is a step in that ticket, not a follow-up task. Anything deferred to "later" is deferred permanently.
• Reconcile physically, on a schedule. Walk the room with a scanner and compare what is there against what the register claims. Annually at minimum; quarterly where hardware moves often.

The number worth tracking is the discrepancy rate — what fraction of assets were found somewhere other than where the register said, or not found at all. A rate that is flat or falling means the process works. A rising one means the register is drifting and decisions are being made on it anyway.

5. Decommissioning Is Part of the Record

When hardware leaves, the natural instinct is to delete the row. Do not. Change the status and keep the history, because the questions that come later are about assets you no longer have: what happened to the machine that held that data, when did it leave, who took it, and was the disk destroyed.

• A status that distinguishes in service, spare, failed, awaiting disposal, and disposed.
• The disposal date and the organisation that took it.
• The data destruction record — certificate, serial of the destroyed drive, method — linked to the asset tag.

This is the chain that ISO 27001 and SOC 2 work asks about, and it cannot be reconstructed after the fact. ISO/IEC 27001:2022 expects an inventory of assets and documented return and secure-disposal handling; the asset register is where that evidence lives. The SOC 2 Evidence Helper covers how such listings are usually requested.

6. What It Feeds

• Rack elevations — the location field, rendered.
• Cable and port records — both ends of every connection are asset tags.
• The CMDB — physical identity, which the logical and service layers hang off.
• Maintenance and warranty work — what is still covered, and by whom.
• Disaster recovery planning — you cannot plan to replace what you have not written down.

How We Approach It

1. Walk the room and record what is actually there, which is routinely not what the existing list says. The gap between the two is the first useful finding.
2. Agree a tag scheme — short, non-sequential-by-location, and scannable. Tags that encode the rack become wrong the first time something moves.
3. Label front and rear in durable material, including the PDUs and patch panels that are usually skipped.
4. Choose where the register lives, and make it one place rather than three that disagree.
5. Wire the update into the change process, so the record is maintained by the work rather than alongside it.
6. Set the reconciliation schedule and establish the baseline discrepancy rate.

What You Get

• Every device labelled front and rear, machine-readable, including the items usually missed.
• A register with identity, location, lifecycle, ownership and physical facts — and no fields nobody maintains.
• The update step written into your change process, so accuracy is a by-product of the work.
• A reconciliation procedure, a schedule, and the first measured discrepancy rate to track against.
• A decommissioning record that holds up when someone asks about a machine you no longer own.

Asset tagging is worth doing properly because everything downstream inherits its accuracy. A rack diagram, a cable record and a CMDB built on a register that is sixty per cent right are all sixty per cent right, and none of them tell you which sixty.