Nobody plans to lose a laptop. They just never write down who took it, and three job changes later it's gone.
An IT asset register records every piece of company hardware, who currently holds it, and every assignment it has had. Small businesses usually start one in a spreadsheet, keep it accurate for four months, and then discover during an exit that the record has not been touched since. The fix is not a bigger spreadsheet — it is tying assignment and return to events that already happen, namely onboarding and offboarding.
The costs are rarely dramatic and always add up:
None of these are catastrophic individually. Collectively, for a 40-person business, they are easily worth several lakh a year in replaced equipment and lost warranty cover.
Resist the urge to be comprehensive. A register with 25 fields is a register nobody updates:
Everything else — MAC address, OS version, installed software — belongs in a device management tool if you need it, not in the register that HR and ops maintain by hand.
Most registers record only who holds the asset now, which is exactly the information that fails you when it matters. Consider a laptop passed from Anita to Ravi to Priya over two years. Priya reports a cracked hinge. Without history you know only that Priya has it. With history you know Ravi returned it noted as damaged, which changes the conversation entirely.
The same applies to security incidents ("who had this device in March?"), to depreciation and to warranty claims. Keep assigned-to, assigned-on, returned-on and condition at each transition — one row per assignment, never overwritten.
Overwriting the assignment field is the asset-register equivalent of overwriting an attendance record: fast, easy, and it destroys the only evidence you have.
Registers rot when maintaining them is a separate task. Attach them to events that already happen:
At onboarding, alongside creating the employee record and login: assign the laptop and peripherals, record condition and accessories, and have the employee acknowledge receipt. Add it to the onboarding checklist rather than treating it as IT's private business.
At offboarding, before the final settlement is released: collect the assets, record the return with condition, and mark them available or under repair. This is the control that matters most — tying asset return to full and final settlement means it actually happens, because there is a natural checkpoint where both parties need something from each other.
Between those, handle transfers as a return followed by an assignment, so the history stays clean rather than jumping from one holder to the next with no record of the intervening state.
An unaudited register drifts within a year regardless of how good the process is. Once or twice a year:
The first audit is always uncomfortable and always worth doing. Subsequent ones take a fraction of the time, because the process fixes itself once people know a sighting is coming.
| Core fields | Asset ID, type, make/model/serial, purchase date and cost, warranty end, status, assigned to, assignment date, condition |
|---|---|
| Most valuable single field | Warranty or AMC end date — it typically pays for the whole exercise |
| Keep as history | One row per assignment: assigned to, assigned on, returned on, condition |
| Assignment trigger | Employee onboarding |
| Return trigger | Offboarding, before full and final settlement is released |
| Transfers | Record as a return followed by a new assignment, never as an overwrite |
| Audit cadence | Once or twice a year, by physical sighting or photo with asset tag |
An asset ID matching a physical tag, the asset type, make, model and serial number, purchase date and cost, warranty or AMC end date, current status, the employee it is assigned to, the assignment date and condition notes. Nine fields is enough — registers fail from being too detailed to maintain, not from being too simple.
Because the current holder alone cannot settle a dispute. If a device has passed through three people, damage reported by the third can only be assessed against the condition recorded when the second returned it. Assignment history is also what answers security questions such as who held a particular device on a particular date.
Tie asset return to the offboarding process, specifically as a checkpoint before the full and final settlement is released. That creates a natural moment where both parties need something from each other, which is far more reliable than reminders. It only works if the register records who holds what in the first place.
Once or twice a year. Export the register, physically sight each asset — a photo of the device with its asset tag is sufficient for remote staff — and reconcile matches, mismatches and missing items. Record the audit date against each asset so the next audit knows what has been verified and when.
Yes, at both handover and return. Without a recorded condition, every damage conversation becomes one person's recollection against another's, which is unresolvable and damages trust regardless of who is right. A short note and, ideally, a photo takes a minute and settles the question permanently.
Whether personal use is permitted, what happens in cases of accidental damage or loss, whether devices may be taken home or travelled with, when assets must be returned during a notice period, and how personal devices used for work are handled. Each of these must be written before an incident, not decided during one.
Merik includes a hardware asset register with assignment to employees, return, and a full assignment history — so the chain of custody survives people changing roles or leaving. Because assets sit in the same workspace as the employee records, assigning a laptop is part of setting someone up rather than a separate spreadsheet somebody remembers to open.
Offboarding runs through the same system, so asset return is visible at the point where an employee is being removed or given a last working day. Software subscriptions and seats are tracked alongside hardware, which is where the other half of your equipment spend usually hides. See the asset and software modules, the feature list, or how it works.