Hardware Asset Data Model

Why the Data Model Decides Everything Else

Every HAM problem eventually traces back to the data model. Reports do not run because the field they need does not exist. Audits fail because two people interpret "Active" differently. Integrations break because one system uses ISO country codes and the other uses free text. The platform you choose matters less than whether the field set, the controlled vocabularies, and the state transitions have been thought through before the first asset is loaded.

This guide is a reference for what to define and how to define it. It is not specific to any HAM product; the same field set works in a spreadsheet, a self-hosted tool, or an enterprise platform. The goal is to give you a starting model that survives growth and audits without needing to be rebuilt every two years.

Required Fields: The Minimum Viable Record

An asset record cannot be useful without these. Treat them as not-null at the database layer or as required fields in the form, depending on how strict your tooling lets you be.

Operational Fields: Earned Their Keep

Not strictly required to create the record, but most organizations regret leaving them out. Each one supports a real workflow you will eventually run.

Optional Fields: Add When You Have a Specific Reason

These are useful in some contexts and noise in others. Add them when a specific workflow demands them, not because the schema looks more impressive with more columns.

• Asset criticality (T1/T2/T3) — used in disaster recovery prioritization. Add it when you have a DR plan that uses it.
• Data classification — public / internal / confidential / regulated. Add it when sanitization decisions actually depend on it.
• Insured value — separate from acquisition cost when the insurance carrier requires it.
• Lease end date — for leased assets only. Don't add a permanently null column to track the small fraction that's leased; consider a separate lease module.
• Bundle ID — links a laptop, dock, and monitor procured together. Useful when you actually treat bundles as units; clutter otherwise.
• Custom tags — a single free-text "Notes" or "Tags" field absorbs the long tail. Resist adding ten purpose-specific text fields that 95% of records leave empty.

Naming Conventions That Don't Rot

Asset ID Format

Use simple sequential IDs with a short prefix: IT-10001, IT-10002. Leading zeros help with sorting, the prefix lets you reserve ranges for different classes if you ever need to, and there is nothing in the ID that organizational change can invalidate.

Avoid intelligent IDs that encode location, department, or asset type — NYC-FIN-LAP-0001 looks tidy on day one and becomes a problem the first time the asset moves to Boston, the user transfers to Marketing, or the device gets reclassified. Encode meaning in attribute fields, not in the primary key.

Location Structure

Locations are the field that most organizations get wrong by treating it as a single free-text field. The right structure for most organizations is a small hierarchy:

• Location Type: Office / Datacenter / Remote / Storage / In-Transit / Disposed.
• Site: Named office or datacenter (controlled list).
• Detail: Floor, room, rack, desk — the field that actually changes when an asset moves a few meters.

Free-text locations like "John's desk" and "the server room" guarantee data quality decay. Controlled lists at the site level and structured detail beneath are the difference between an audit that passes and one that doesn't.

Manufacturer and Model

Maintain a manufacturer master list with one canonical name per vendor (Dell, not Dell Inc. or DELL Computer Corp.). Model can be free text but should be normalized at receiving by whoever creates the record. Network discovery tools usually return useful manufacturer and model strings; treat them as suggestions, not authoritative.

User and Cost Center

Reference these from the corporate directory rather than typing them into the asset record. The asset stores a user ID and a cost center ID; the human-readable values come from the directory at display time. When the user's name or department changes, the asset record stays correct without any update.

Asset Classification Taxonomy

Classification is where most organizations either over-engineer (forty subcategories nobody uses) or under-engineer (everything is "IT Equipment"). The middle path is two levels:

• Class (the required field above) — laptop, desktop, server, network, mobile, peripheral, other. Five to seven values that almost never change.
• Sub-class (optional) — adds resolution where it matters: Network splits into switch, router, firewall, AP; Peripheral splits into monitor, dock, printer.

Each class drives different defaults: useful life, refresh cycle, expected fields, sanitization rules. Tying defaults to class is what lets the data model feel like it understands the asset rather than treating every device as a generic "thing".

The Status State Machine

Status is the single most-used field after Asset ID. Defining it as a free-text string is the most common mistake; defining it as a state machine with explicit allowed transitions is what makes lifecycle workflows reliable.

Recommended States

Transition Rules That Actually Help

• Deployed requires an Assigned User and an Assignment Date. The system should reject the transition if either is missing.
• Disposed requires a Disposal Date, Disposal Method, and (for regulated data) a sanitization certificate reference. No exceptions; the workflow itself is the compliance control.
• In Repair requires a ticket reference. Devices that go to repair without a ticket reliably become ghost assets.
• Lost/Stolen triggers a downstream notification to security and (if applicable) opens a breach assessment. The state change is the trigger.
• Backwards transitions are normal — In Repair → Deployed, Lost/Stolen → Deployed (recovered) — and should be supported with explicit reason codes.

Keeping these transitions enforced in the system means the audit methodology described in the audit methodology guide can rely on Status as a real signal. When Status is free text, the audit ends up being the only thing that can verify what state assets are actually in.

Identifiers and the Bridge to Other Systems

Three identifiers do the work of connecting HAM to everything else.

• Asset ID: the organization's identifier. Owned by HAM. Printed on tags. Used by humans.
• Serial Number: the manufacturer's identifier. The bridge to warranty lookups, manufacturer support, and the device itself when the tag is missing.
• Discovery Identifier: a system-specific ID — CMDB CI ID, MDM device ID, endpoint-protection agent ID. One per integrated downstream system, populated automatically when the device is discovered.

The HAM vs CMDB guide covers the integration patterns that use these identifiers. The principle here is to design them in from day one, not retrofit them later when the integration becomes urgent.

Common Mistakes

• Free-text where there should be a controlled list. Locations, manufacturers, and statuses corrupt within months when users can type anything. Fix it at schema time, not by sending out reminders later.
• One-size-fits-all required fields. Forcing every asset class to fill in fields only relevant to one of them produces empty fields, garbage values, or abandoned records. Make required fields class-aware.
• Encoding meaning in the Asset ID. The ID outlives the meaning every time. Keep the ID dumb.
• Mixing book and tax data in the same field. If finance needs different useful lives for book and tax, that's two fields, not one. The depreciation guide covers why.
• No timestamp + user on changes. Without an audit trail, you cannot answer "who changed this and when" — and external auditors will eventually ask.
• Skipping the Disposed terminal state. "Just delete the record when it's gone" loses the disposal evidence finance and compliance need for years. Disposed is a state, not a deletion.

Applying the Model

If you are starting fresh, build the schema with the required and operational fields above, controlled lists for the high-cardinality fields, and the status state machine enforced by the application or workflow layer. The Excel template guide shows how the same model translates to a spreadsheet for organizations under the threshold for dedicated software.

If you are remediating an existing schema, the highest-leverage moves in order: introduce controlled lists for Status / Manufacturer / Location, populate the missing required fields against existing records, add the audit-trail timestamps, and only then start enforcing transition rules. Trying to enforce a state machine on records that haven't been cleaned up first produces a flood of error messages and erodes the team's trust in the system.

Next Steps