Hardware Asset Register: What Lean IT Teams Should Track

A hardware asset register should track six things for every device: identity (an asset tag, type, and serial number), ownership (who holds it and which department), status (in use, spare, repair, retired, or lost), purchase context (when it was bought and a reference to the order), basic specification (brand, model, and the specs that matter for support), and notes for the exceptions. Get those right and a pile of laptops becomes a record you can answer questions from.

This guide is the hardware companion to what an IT assets register is. It assumes you already know why you want one; here we get specific about the fields, why each earns its place, and what to leave out so the register stays accurate by hand.

What to Track in a Hardware Asset Register

The short version, before the detail: track enough to identify a device, know who has it, know what state it is in, and trace where it came from — and nothing you cannot keep current by hand. Everything below maps to fields CertPilot's Assets Register holds today, so the list is grounded in a real register rather than an ideal one.

| Field group | Example fields | Why it matters | Review use | |---|---|---|---| | Identity | Asset tag, asset type, brand, model, serial number | Distinguishes one device from another and ties it to support and warranty | Find a specific device; confirm it is the one in the record | | Ownership & custody | Assigned person, department | Answers "whose is this?" and "who is responsible?" | Offboarding checks; chase unassigned items | | Specification | Processor, RAM, storage, GPU | Decides whether a device is fit for a role or due for refresh | Refresh planning; reassignment decisions | | Purchase context | Purchase date, invoice or order reference | Makes the record traceable to a real purchase | Age and refresh cycle; finance queries | | Status / lifecycle | Active, spare, repair, retired, lost | Captures where the device is in its life | Spot retired/lost items; reconcile the fleet | | Notes | Maintenance notes, general notes, confidentiality label | Holds the exceptions a fixed schema misses | Context during reviews and handovers |

Why Hardware Evidence Gets Messy

Hardware records decay faster than almost any other IT list, for ordinary reasons. Devices are bought in batches and handed out informally. People swap laptops without telling anyone. Spares live in a drawer that only one person knows about. A device comes back from a leaver and goes straight to the next joiner with no record in between.

None of this is negligence — it is what happens when the record lives in memory and email. The fix is a single owned list where updating one row is easy enough to actually happen. The fields below are chosen to be worth that small effort and no more.

Identification Fields to Track

Identity is what makes a record point at exactly one device:

• Asset tag — your own reference for the item, ideally on a physical label. This is the field you search by, and it should be unique within your organization.
• Asset type — laptop, desktop, monitor, phone, tablet, printer, network device, peripheral, server, or other. Typing matters because it drives most of your filtering ("show me all the laptops").
• Brand and model — for support, compatibility, and refresh decisions.
• Serial number — the manufacturer's identifier, distinct from your asset tag. The serial is what a vendor asks for; the asset tag is what your team uses day to day. Tracking both is the difference between a record that is convenient internally and one that is useful when you call support.

A common early mistake is treating the serial number as the asset tag. They serve different jobs — keep both fields.

Ownership and Custody Fields to Track

Ownership is the field that makes the register answer the question it exists for:

• Assigned person — who holds the device. In CertPilot this links to your People & Accounts register, so custody and the wider record of who works here stay connected; a manual name works for anyone not in that register.
• Department — useful for filtering and for routing questions when the individual owner is unclear.

The gap that costs teams the most is the unassigned device — one with no holder recorded. It is worth a deliberate habit: any device without an owner is either a spare (mark it so) or a missing record (fix it). Tying custody to people is also what makes offboarding a checklist rather than a hunt — the practical link explored in how to prove IT is under control without more spreadsheets.

Purchase, Warranty, and Lifecycle Fields to Track

These fields make a record traceable and help you plan ahead:

• Purchase date — when the device entered service, which drives age and refresh planning.
• Invoice or order reference — a pointer back to the actual purchase, so a finance or audit query has somewhere to land.
• Warranty and end-of-support — CertPilot's hardware register does not have a dedicated warranty field today, so record warranty expiry or end-of-support in the notes or maintenance notes field. Keeping it as a deliberate note is honest and still useful; just don't expect a built-in warranty alert.

Lifecycle proper is captured by the status field, covered next. Together, purchase context and status let you answer "how old is this and where is it in its life?" without a separate accounting tool — and without claiming to be one.

Status Fields to Track

Status is the single most valuable field for evidence, because it captures the states people forget to write down. CertPilot's hardware status options are:

• Active — in use by its assigned owner.
• Spare — held in reserve, not currently assigned.
• Repair — out for or awaiting repair.
• Retired — withdrawn from service (record disposal details in notes).
• Lost — unaccounted for, with a note on when and what follow-up happened.

The non-active states are the ones a reviewer, an insurer, or a leaver's manager actually asks about. A register full of "active" rows looks tidy but proves little; one that honestly shows three retired, one in repair, and one lost is what demonstrates the fleet is being managed. The guide to lost, retired, and unassigned asset evidence goes deeper on each.

What Not to Track

Discipline about exclusions keeps the register maintainable:

• No live telemetry. CPU load, last-seen times, and patch status belong to monitoring tools, not a manual register. A hand-kept field that claims to hold them will be stale and misleading.
• No secrets. No passwords, no full licence or product keys. Those belong in a password manager or vault.
• No data you cannot refresh. If a field will never be updated after import, it is noise. Drop it.
• No surveillance fields. Location history, usage hours, and activity have no place here — that is not what this register is for and not what CertPilot does.

The test for any candidate field: will someone actually keep this current, and does it help answer a real question? If not, leave it out.

How Hardware Asset Tracking Supports Evidence Reports

A maintained hardware register is the internal-register input to IT governance evidence: it records what public-signal checks cannot see. In CertPilot today, hardware data reaches a report as summary counts in the Governance Evidence Pack — how many devices, how many assigned, how many retired or lost — alongside your other registers. There is no dedicated Assets PDF; the detailed surface is the live register and a CSV export for a point-in-time snapshot. The checks + registers → evidence reports model explains how the pieces fit, the evidence reports module describes how each report is assembled, and the sample reports gallery shows the finished artifacts.

How CertPilot Fits — With Strict Boundaries

CertPilot's Assets Register holds the hardware fields above as a customer-maintained, manual-first record with CSV import and export. The boundaries are deliberate and worth stating plainly:

• It does not discover devices automatically, scan your network, or read device telemetry.
• It is not MDM and installs no endpoint agent.
• It does not monitor endpoints, scan for vulnerabilities, or patch devices.
• It cannot remote wipe, lock, or control a device.
• It is not a CMDB replacement and not an accounting or depreciation system.
• It is not a certification or an audit guarantee — it supports internal governance routines and evidence preparation.

Every field is something you enter or import. That keeps the register honest: it reflects what your team knows, dated and owned. For the full picture of where CertPilot's lines are drawn, see what CertPilot is — and what it is not.

A Practical First Version for a Lean IT Team

A workable hardware register on day one does not need every field populated:

1. Import what you have. Export your current device spreadsheet to CSV and import it — even if owners and serials are patchy.
2. Get every device an owner or a status. Each row should either name a holder or be marked spare, repair, retired, or lost. No silent unassigned rows.
3. Add serials where they matter most. Start with laptops and anything you might need vendor support for.
4. Record the exceptions in notes. Warranty dates, "screen cracked," "on loan to contractor" — the notes field is where real life goes.
5. Schedule fifteen minutes a month. Update the rows that changed. That recurring upkeep is what makes the register evidence rather than a snapshot of one good afternoon.

In Short

• Track six field groups: identity, ownership/custody, specification, purchase context, status, and notes.
• Keep asset tag and serial number as separate fields — they serve different jobs.
• Status (active, spare, repair, retired, lost) is the highest-value field; the non-active states are what evidence is made of.
• Record warranty in notes — CertPilot's hardware register has no dedicated warranty field today.
• Leave out telemetry, secrets, and anything you cannot keep current; CertPilot's register is manual-first and discovers nothing on its own.

Frequently Asked Questions

What is the minimum I should track per device?

An asset tag, the type of device, an owner (or a status if unowned), and a serial number for anything you might need support for. That is enough to identify the device, know who has it, and contact a vendor. Everything else — specs, purchase date, notes — adds value but is not required to start.

What is the difference between an asset tag and a serial number?

The asset tag is your own internal reference, usually on a physical label, and is what your team searches by. The serial number is the manufacturer's identifier, used for warranty and vendor support. They are different fields with different jobs — track both rather than collapsing them into one.

How do I handle spares and loaners?

Mark a spare with the spare status and no assigned person. For a loaner, assign it to the person currently holding it and note the arrangement in the notes field. The goal is that no device sits in an undefined "unassigned" limbo — every row has either an owner or a deliberate status.

Can CertPilot read the specs off my machines?

No. CertPilot does not scan devices, install an agent, or collect telemetry. Specifications like processor, RAM, and storage are entered or CSV-imported by your team. The register holds what you put in — which is also what keeps it under your control.

Does the hardware register track warranty expiry?

Not as a dedicated field today. Record warranty or end-of-support dates in the notes or maintenance-notes field. They are still useful context during reviews and handovers; just don't expect an automatic warranty reminder from the register.