ServiceNow Hardware Asset Management Governance Model

Asset Lifecycle and Ownership Governance

Hardware assets (servers, desktops, networking equipment) progress through a lifecycle: Procurement (ordered), Deployment (installed), In Use (supporting services), Maintenance (repairs), and Decommissioning (removed from service). Governance defines the business rules for each phase and who is accountable.

Define ownership at each phase. Finance owns procurement (budget approval, vendor selection). IT Operations owns deployment and maintenance (installation, patching, repair). Business units own in-use assets (assign users, allocate to cost centers). When an asset moves between phases, ownership transfers and the asset record is updated.

Document asset location and custody: Who currently has the asset? Where is it located? This chain-of-custody tracking is essential for compliance and for locating assets during audits. For expensive or sensitive assets (cryptographic hardware, security appliances), implement stricter custody tracking.

Procurement Control and Budget Governance

Define a procurement workflow: Request → Approval → Purchase Order → Receipt → Asset Record. Finance must approve large capital purchases before procurement proceeds. Define approval thresholds: small purchases are auto-approved; large purchases require executive approval. This prevents unauthorized spending.

Track procurement status in ServiceNow: When was the purchase order created? When was the order received? When was it deployed? Tracking provides visibility into procurement pipeline and identifies delays. Use this data for capacity planning: if you ordered servers and they are just being received, you can plan for deployment.

Asset Depreciation and Financial Tracking

Hardware assets depreciate over time. Finance needs to track asset cost, depreciation method (straight-line, accelerated), and book value for financial reporting. ServiceNow can be a source of truth for asset data (cost, acquisition date, location, status). Finance systems pull this data for depreciation calculations.

Define governance for depreciation: What is the useful life of different asset types (servers, desktops, and networking equipment each have expected useful lifespans)? When an asset reaches end-of-life, it is decommissioned and removed from the balance sheet. Track fully depreciated assets separately; they may still be in use but have no book value.

Maintenance and Support Tracking

Track hardware maintenance contracts: warranty expiration, support level (standard, priority, premium), and vendor contact information. When a hardware issue occurs (server failure, network device malfunction), support tickets should reference the maintenance contract to determine response times and escalation procedures.

Define preventive maintenance: Which asset types require regular maintenance (HVAC units, tape backup systems)? When is maintenance due? Set up alerts to notify operations team when maintenance is overdue. Link maintenance to incident data: if an asset has recurring incidents, investigate whether maintenance is inadequate or whether the asset should be replaced.

Compliance and Asset Auditing

For regulated organizations, assets must be tracked for compliance. Compliance audits verify that assets are properly maintained, support is current, and assets are not obsolete. Prepare audit reports: list of active assets by type, maintenance status, warranty expiration, and owner.

Physical asset audits: Periodically walk around and verify that assets in CMDB actually exist. For high-value or sensitive assets, conduct audits at regular intervals. Low-value assets can be audited less frequently but should still be verified regularly.

Track asset disposal: When assets are decommissioned, document how they were disposed. For sensitive equipment (servers containing data), implement secure disposal (wipe drives, physically destroy). Document disposal procedures for audit trail.

Integration With Financial Systems and Reporting

ServiceNow Hardware Asset Management should integrate with financial systems. Asset cost and depreciation data flows from ServiceNow to finance for accounting. Regular reconciliation: Does the list of active assets in ServiceNow match the asset list in the financial system? Discrepancies indicate data quality issues.

Generate compliance reports: Asset aging (which assets are older than their expected useful life), maintenance status (which assets have current support contracts), and depreciation (how much book value remains). These reports inform strategic decisions about asset refresh cycles.

Common Governance Challenges

Challenge 1: Asset tracking gaps. Not all assets are registered in ServiceNow. Users bring personal devices to work, shadow IT orders equipment without going through approved channels. Implement periodic asset inventory and reconciliation to catch unregistered assets.

Challenge 2: Obsolete assets not being retired. Assets that are broken or obsolete remain in CMDB indefinitely. Implement a decommissioning process: when an asset reaches end-of-life or is replaced, decommissioning is mandatory. Set reminders for assets nearing end-of-life date.

Challenge 3: Support contracts not aligned with asset lifecycle. A support contract expires but the asset is still in use. Implement alerts for contract expirations and automated renewal workflows to prevent support gaps.

Decide who may change a hardware record before deciding how it is changed

Governance for hardware assets is mostly a question of decision rights. Who can write off a laptop that is still listed as in use? Who can reassign a server that supports a live service? Who can accept a supplier’s invoice total when it differs from the purchase order? Until those questions have named answers, every change becomes a negotiation, and the register drifts toward whichever team pushes hardest. A governance model is the set of answers, written down, with an escalation route for the cases the answers do not cover. The people-side version of those answers is in the roles and RACI guide, which is not repeated here.

The model does not need a committee for every decision. Most routine changes should be settled by the team that holds the record. The governance effort should go into the small number of decisions where two functions have a legitimate claim, usually finance and operations and sometimes security. The purpose of the forum is to settle those disputes once and record the outcome, not to approve each device.

A decision rights table for the decisions that cause disputes

The table below lists the decisions that most often produce disagreement in a hardware estate. For each one it names who decides, whose input is needed first, and the condition that moves the decision up a level. Fill in the people and the conditions for your own organization. The structure is the part that carries over.

Setting up the governance forum without making it a bottleneck

A forum that meets to approve routine items is often bypassed over time. The setup below keeps the forum for disputes and policy, with routine decisions settled in the operational queue.

1. Name the chair and the standing members from finance, operations and security. Keep the list short enough that each member can attend every session without delegating. Where members belong to assignment groups, the assignment groups governance guide covers how to keep that ownership clear.
2. Agree the decision rights table and publish it where the register’s users can find it, so that people can see who to ask before they ask.
3. Define the escalation criteria in terms a service desk agent can apply on a call, not in terms only a lawyer can read.
4. Record each forum decision in the register as a policy note linked to the affected asset class, so that later readers can see the reason.
5. Review the decision rights table when the operating model changes, such as a move to a different hosting arrangement or a change in how equipment is leased.

Where governance stops and paperwork starts

Governance adds the most value where the cost of being wrong is high: data-bearing equipment, equipment under lease or legal hold, and assets that carry a large book value. For low-value consumables and shared accessories, a lighter rule is usually enough, such as a periodic sample check that the holding team can explain. Applying the full model to everything is a common way to make it unpopular, and an unpopular model is one that people route around.

Evidence that the model is working

The forum’s own minutes are not evidence of control. The more useful measures are whether disputes reach the forum with a clear question attached, whether decisions are applied to the register within the same working cycle, and whether any change to a record can be traced to a named decision. If the agenda is dominated by questions the decision rights table already answers, the table needs clearer wording, not more meetings.

Who should own the policy on lease returns?

Finance usually owns the commercial terms and operations usually owns the physical return. The governance model should say so explicitly, because the return date is when cost, custody and data risk all change at once.

Can a governance forum overrule a service owner?

It can set the rule that applies across the estate, but a decision about one specific service should stay with the service owner unless the risk is enterprise-wide. Keeping that line clear stops the forum from becoming a second service desk.

What is the minimum record needed to support a governance decision?

The asset identifier, its current custodian, the decision taken, the name of the person who took it, and the date. A decision without those fields cannot be checked later, which is often why an audit query returns to the same unresolved item.

How does this differ from change governance?

Change governance controls changes to services and configuration. Hardware governance controls the status, custody and financial state of physical assets. The two meet when a device is changed in a live service, and the handoff between them should be written down. The change review decision note is a related read for that handoff.

When a forum is meeting but its outcomes never reach the register, the break is often in the recording step. The policy evidence planning note covers how obligations are connected to evidence.

Hardware asset lifecycle in ServiceNow: state values, fields and table names

In many ServiceNow implementations a hardware asset’s lifecycle is tracked on the alm_hardware table through its install status and substatus. Install status says where the asset is in its life, such as in stock, installed or retired, and the substatus refines it. Each transition needs one named owner.

The names below are common out-of-box values. Check them on your own instance and release, because labels and defaults change between releases. Some releases and the Hardware Asset Management application use separate state and substate fields for the lifecycle, so confirm which pair your instance reports on.

Example (hypothetical): a laptop is received against an order and recorded as In stock with the substatus Available. When it is handed to an employee, the state changes to Installed and the assigned user is filled in. At the end of its use it returns to stock, is wiped, and is later retired. The governance forum decides one rule for this path: an asset cannot move to Retired while a user is still assigned, and the team enforces that with a data policy or business rule it writes itself.

Which field shows where a hardware asset is in its life?

Commonly the install status field, refined by the substatus, giving a state such as In stock with the substatus Available. Report on the pair rather than on either alone, and keep the list of allowed combinations short enough that every team reads them the same way.

How do you stop retired assets from lingering in use?

Block retirement while a user is assigned, then run a regular report for assets that are retired but still referenced by a user, a task or a linked configuration item. Each hit is either a status error or a device that was never collected, and both need an owner.

Who should be allowed to edit the state directly?

Restrict direct edits to the people who run the stockroom and the register, and let everyone else change state through a request or task. The asset role is the usual out-of-box role for asset managers, but confirm role names on your own release before writing access rules.

Related reading: the hardware asset management guides, the plain-language guide to hardware asset management and the explanation of CMDB classes.