Skip to main content

Asset Management

Asset management is the discipline of tracking, controlling, and optimising IT resources from acquisition through disposal. An asset in this context is any item of value that supports IT service delivery: physical hardware, software licences, cloud subscriptions, and the data stored within systems. Effective asset management provides visibility into what the organisation owns, where it is located, who is responsible for it, and what it costs to operate.

IT asset
Any component with financial value that contributes to IT service delivery, including hardware, software, cloud resources, and data repositories.
Asset register
The authoritative record of all IT assets, their attributes, locations, owners, and status throughout the lifecycle.
Asset lifecycle
The complete sequence of stages an asset passes through: planning, acquisition, deployment, operation, and retirement.
Reconciliation
The process of comparing discovered assets against the asset register to identify discrepancies such as missing records, ghost assets, or incorrect attributes.
Total cost of ownership
The complete cost of an asset over its useful life, including acquisition, deployment, operation, support, and disposal costs.

Asset classification

Assets divide into categories based on their nature, how they are acquired, and how they depreciate. The classification determines tracking requirements, financial treatment, and lifecycle management approaches.

Hardware assets are physical items: servers, network equipment, workstations, laptops, mobile devices, printers, and peripherals. Hardware assets have serial numbers, physical locations, and depreciate over time according to accounting standards. A laptop purchased for £1,200 might depreciate over three years at £400 annually, reaching zero book value while remaining operationally useful. Hardware requires physical inventory verification and has tangible disposal requirements including data sanitisation and environmental compliance.

Software assets encompass licences, subscriptions, and entitlements that grant rights to use software products. Software assets lack physical form but carry significant financial and compliance obligations. A perpetual licence for design software purchased for £2,500 remains on the register indefinitely, while a subscription licence for productivity software at £150 per user annually requires renewal tracking. Software assets connect to deployment records showing where licences are installed and whether usage complies with entitlement terms.

Cloud assets represent contracted capacity and services from cloud providers. Unlike traditional software where the organisation holds a licence, cloud assets represent ongoing service relationships with consumption-based or subscription pricing. A virtual machine instance running continuously at £0.15 per hour costs £1,314 annually. Cloud assets require different tracking mechanisms because they exist only as configurations and billing line items rather than discrete installable products.

Data assets are repositories of organisational information with value that extends beyond the systems storing them. A beneficiary database, financial records archive, or programme monitoring dataset constitutes an asset requiring lifecycle management independent of the hardware and software that hosts it. Data assets have retention requirements, compliance obligations, and ownership distinct from technical infrastructure.

+------------------------------------------------------------------+
| ASSET CLASSIFICATION |
+------------------------------------------------------------------+
| |
| +------------------------+ +------------------------+ |
| | HARDWARE | | SOFTWARE | |
| | | | | |
| | - Servers | | - Perpetual licences | |
| | - Network equipment | | - Subscription | |
| | - Workstations | | - Volume agreements | |
| | - Mobile devices | | - Open source | |
| | - Peripherals | | - Custom developed | |
| | | | | |
| | Attributes: | | Attributes: | |
| | - Serial number | | - Licence key | |
| | - Physical location | | - Entitlement count | |
| | - Warranty status | | - Renewal date | |
| +------------------------+ +------------------------+ |
| |
| +------------------------+ +------------------------+ |
| | CLOUD | | DATA | |
| | | | | |
| | - IaaS instances | | - Databases | |
| | - PaaS services | | - File repositories | |
| | - SaaS subscriptions | | - Archives | |
| | - Storage accounts | | - Backups | |
| | - Reserved capacity | | - Analytical datasets | |
| | | | | |
| | Attributes: | | Attributes: | |
| | - Resource identifier | | - Classification | |
| | - Billing account | | - Retention period | |
| | - Consumption metrics | | - Data controller | |
| +------------------------+ +------------------------+ |
| |
+------------------------------------------------------------------+

Figure 1: Asset classification hierarchy showing four primary categories with distinguishing attributes

The classification hierarchy extends to subcategories reflecting organisational needs. Hardware subdivides into compute (servers, workstations), network (switches, routers, access points), storage (SAN, NAS, backup appliances), and end-user devices (laptops, tablets, phones). Software subdivides by licence model (perpetual, subscription, consumption), deployment method (installed, hosted, cloud-delivered), and commercial status (commercial, open source, internally developed). These subdivisions enable meaningful reporting and policy application.

Asset lifecycle stages

Every asset progresses through predictable stages, each with distinct activities and controls. Understanding the lifecycle reveals where asset management adds value and where gaps create risk.

+---------------------------------------------------------------------+
| ASSET LIFECYCLE |
+---------------------------------------------------------------------+
| |
| +----------+ +----------+ +----------+ |
| | | | | | | |
| | PLAN +---->+ ACQUIRE +---->+ DEPLOY | |
| | | | | | | |
| +----------+ +----------+ +----+-----+ |
| | |
| Requirements Procurement v |
| Budgeting Receiving +-----+------+ |
| Approval Registration | | |
| | OPERATE | |
| | | |
| +----------+ +----------+ +-----+------+ |
| | | | | | |
| | RETIRE |<----+ MAINTAIN |<---------+ |
| | | | | |
| +----------+ +----------+ Monitoring |
| Support |
| Disposal Repair Updates |
| Transfer Upgrade |
| Donation Refresh |
| |
+---------------------------------------------------------------------+

Figure 2: Asset lifecycle stages showing progression from planning through retirement

The planning stage occurs before acquisition and determines what assets the organisation needs, when, and at what cost. Planning connects asset decisions to service requirements and budget availability. A request for 15 new laptops originates from a programme expansion requiring additional field staff. Planning validates the requirement, specifies the configuration, estimates total cost (hardware, deployment, support, eventual disposal), and secures budget approval. Planning decisions recorded in the asset register create audit trails showing why assets were acquired.

The acquisition stage encompasses procurement, receiving, and initial registration. Procurement follows organisational purchasing procedures, potentially involving competitive quotes for items above threshold values. Receiving verifies that delivered items match purchase orders and meet specifications. Initial registration creates the asset record with foundational attributes: asset tag number, serial number, model, purchase date, cost, supplier, warranty terms, and assigned owner. For a server costing £8,500, acquisition captures the purchase order number, delivery date, data centre location designation, warranty expiration (three years forward), and the IT manager as accountable owner.

The deployment stage transforms an acquired asset into an operational one. Hardware deployment involves physical installation, configuration, network connection, and security hardening. Software deployment involves installation, activation, and verification of licensing compliance. Cloud deployment involves provisioning resources, configuring access, and establishing monitoring. Deployment updates the asset record with operational details: IP addresses, installed software, assigned user, deployment date, and initial configuration baseline. A laptop moving from acquisition to deployment gains records of the operating system image applied, security software installed, encryption status, assigned user, and help desk ticket number authorising the deployment.

The operation stage spans the asset’s productive life where it delivers value. Operation involves ongoing monitoring, support, updates, and maintenance. Asset records accumulate operational history: support tickets raised, patches applied, component replacements, performance issues, and utilisation patterns. A server in operation for three years accumulates records of 47 patches applied, two memory upgrades, one disk replacement under warranty, and average CPU utilisation of 35%. This operational history informs decisions about extending service, planning replacement, or identifying systemic issues across similar assets.

The retirement stage removes assets from service through disposal, transfer, donation, or destruction. Retirement triggers specific procedures depending on asset type and classification. Hardware retirement requires data sanitisation, physical disposition, and environmental compliance. Software retirement requires licence termination or transfer and removal from systems. Retirement closes the asset record with final status, disposition method, date, and any certificate of destruction for media containing sensitive data.

Asset register design

The asset register serves as the single source of truth for IT asset information. Register design determines what data is captured, how it is structured, and how it integrates with other systems.

Core attributes apply to all assets regardless of type:

The asset identifier is a unique code assigned at registration. Organisations use various schemes: sequential numbers (A00001), prefixed codes by type (HW-00001, SW-00001), or location-embedded codes (UK-LON-HW-00001). The identifier appears on physical asset tags for hardware and in licence management records for software. Consistent identifier schemes enable accurate tracking across systems and locations.

The asset name provides human-readable identification describing what the asset is. Names follow consistent conventions: “Dell PowerEdge R750 Server” rather than “Server” or “Dell box in rack 3”. Meaningful names reduce confusion when staff discuss assets across organisational boundaries.

Classification places the asset within the categorisation hierarchy. A laptop classifies as Hardware > End User Device > Laptop. Classification enables policy application (all laptops require encryption), reporting (total value of network equipment), and lifecycle management (servers have five-year refresh cycles, laptops have three-year).

Status indicates current lifecycle position. Common status values include: Planned, Ordered, Received, In Deployment, In Service, Under Maintenance, In Storage, Pending Disposal, Disposed. Status transitions trigger workflows and update reporting. An asset moving from “In Service” to “Under Maintenance” might trigger a service request and exclude the asset from availability calculations.

Owner identifies the person or role accountable for the asset. Ownership does not mean physical possession or daily use; it means accountability for decisions about the asset throughout its lifecycle. The IT Manager owns the core network switch regardless of which engineer physically maintains it. The Finance Director owns the finance system server regardless of which team operates it. Clear ownership prevents assets becoming orphaned when staff depart.

Custodian identifies who physically possesses or directly manages the asset. For a laptop, the assigned user is custodian while IT remains owner. For a server, the systems administrator team is custodian while the service owner remains accountable owner. Distinguishing ownership from custody clarifies responsibilities: custodians protect assets in their care, owners make decisions about lifecycle and expenditure.

Location records where the asset physically resides or, for cloud assets, the logical location within the provider’s infrastructure. Location schemes reflect organisational structure: Country > Office > Building > Floor > Room for physical assets, or Provider > Region > Subscription > Resource Group for cloud assets. Accurate location enables physical audits, supports incident response (which assets are affected by a power outage in Building B), and meets compliance requirements for data residency.

Financial attributes capture cost and accounting information: purchase price, depreciation method, annual depreciation amount, current book value, cost centre charged, and funding source. An asset purchased for £3,000 using straight-line depreciation over three years shows annual depreciation of £1,000 and book value declining from £3,000 to £2,000 to £1,000 to zero over the period. Connecting assets to cost centres enables accurate cost allocation and budget tracking.

+-------------------------------------------------------------------+
| ASSET REGISTER INFORMATION MODEL |
+-------------------------------------------------------------------+
| |
| +------------------+ +------------------+ |
| | ASSET RECORD | | OWNERSHIP | |
| +------------------+ +------------------+ |
| | Asset ID (PK) +---------+ Owner | |
| | Name | | Custodian | |
| | Classification | | Cost Centre | |
| | Status | | Funding Source | |
| | Description | +------------------+ |
| +--------+---------+ |
| | |
| | |
| +--------v---------+ +------------------+ |
| | FINANCIAL | | LOCATION | |
| +------------------+ +------------------+ |
| | Purchase Price | | Country | |
| | Purchase Date | | Site | |
| | Depreciation | | Building | |
| | Book Value | | Room/Rack | |
| | Warranty End | | Cloud Region | |
| +------------------+ +------------------+ |
| |
| +------------------+ +------------------+ |
| | LIFECYCLE | | RELATIONSHIPS | |
| +------------------+ +------------------+ |
| | Acquisition Date | | Parent Asset | |
| | Deployment Date | | Child Assets | |
| | Retirement Date | | Related Services | |
| | Disposal Method | | Contracts | |
| | History Log | | Suppliers | |
| +------------------+ +------------------+ |
| |
+-------------------------------------------------------------------+

Figure 3: Asset register information model showing core attribute groups and relationships

Extended attributes vary by asset type. Hardware assets require serial numbers, MAC addresses, warranty status, and physical specifications. Software assets require licence keys, entitlement quantities, licence type, and installation records. Cloud assets require subscription identifiers, resource names, consumption metrics, and billing account references. The register schema accommodates type-specific attributes while maintaining consistent core structure.

Relationships connect assets to each other and to external entities. A server asset relates to the rack it occupies (parent), the disk drives installed within it (children), the services it hosts, the support contract covering it, and the supplier who provided it. Relationship modelling enables impact analysis: if server HW-00147 fails, which services are affected? Which assets depend on network switch HW-00089?

Ownership and accountability

Asset accountability requires clear definition of who makes decisions, who maintains records, and who ensures compliance. Without explicit ownership, assets drift into unmanaged states where no one authorises expenditure, monitors compliance, or plans replacement.

+------------------------------------------------------------------------+
| OWNERSHIP AND ACCOUNTABILITY |
+------------------------------------------------------------------------+
| |
| +------------------------+ |
| | ASSET OWNER | |
| +------------------------+ |
| | - Accountable for | |
| | asset decisions | |
| | - Approves lifecycle | |
| | transitions | |
| | - Budget holder | |
| +----------+-------------+ |
| | |
| | Delegates operational responsibility |
| v |
| +----------+-------------+ +------------------------+ |
| | CUSTODIAN | | ASSET MANAGER | |
| +------------------------+ +------------------------+ |
| | - Physical possession | | - Register maintenance | |
| | or direct control | | - Process compliance | |
| | - Day-to-day care | | - Reporting | |
| | - Usage compliance | | - Discovery/audit | |
| +------------------------+ +------------------------+ |
| |
| +------------------------+ +------------------------+ |
| | FINANCE | | PROCUREMENT | |
| +------------------------+ +------------------------+ |
| | - Depreciation | | - Acquisition | |
| | - Cost allocation | | - Supplier management | |
| | - Audit compliance | | - Contract terms | |
| +------------------------+ +------------------------+ |
| |
+------------------------------------------------------------------------+

Figure 4: Ownership and accountability structure showing role relationships

The asset owner is the person accountable for an asset throughout its lifecycle. Ownership typically aligns with budget responsibility or service accountability. The IT Director owns infrastructure assets supporting core IT services. Programme Directors own assets dedicated to specific programmes. Department Heads own assets used exclusively by their teams. Ownership assignment follows organisational structure: assets serving the whole organisation have central IT ownership; assets serving specific functions have distributed ownership with IT providing custodianship.

Asset owners hold specific responsibilities: approving acquisition and retirement decisions, authorising expenditure on maintenance or upgrades, ensuring compliance with policies affecting their assets, and participating in periodic reviews. When an asset approaches end of life, the owner decides whether to extend service, replace with equivalent, upgrade to enhanced capability, or retire without replacement.

The custodian maintains physical control or operational management. For end-user devices, the assigned user is custodian responsible for physical security, acceptable use, and reporting loss or damage. For infrastructure assets, the technical team managing the systems serves as custodian responsible for operational care, security updates, and monitoring. Custodians follow policies set by owners and escalate decisions beyond their authority.

The asset manager role maintains the asset management function itself: the register, processes, discovery tools, and reporting. In small organisations, asset management responsibilities distribute across IT staff with no dedicated role. In larger organisations, a dedicated asset manager or asset management team coordinates the discipline. The asset manager does not own assets; they own the system for managing them.

Finance maintains financial records, calculates depreciation, and ensures asset values reconcile with accounting systems. The asset register and financial ledger must agree on what assets exist and their values. Finance provides valuation guidance, depreciation schedules, and audit support.

Procurement manages supplier relationships, negotiates contracts, and executes purchases. Procurement creates the commercial relationship; asset management tracks what results from that relationship throughout the asset’s life.

Financial tracking

Asset management intersects financial management through acquisition costs, depreciation, and total cost of ownership analysis. Understanding these financial dimensions enables informed decisions and supports organisational reporting requirements.

Acquisition cost captures what the organisation paid to obtain and ready an asset for use. For a server, acquisition cost includes the hardware purchase price (£8,500), shipping (£45), installation labour (£400), and initial configuration (£300), totalling £9,245. The full acquisition cost, not just purchase price, enters the asset register and serves as the depreciation base.

Depreciation allocates acquisition cost over the asset’s useful life, recognising that assets lose value as they age and approach obsolescence. The straight-line method divides acquisition cost by useful life in years. A £9,000 server with three-year useful life depreciates at £3,000 annually. After year one, book value is £6,000; after year two, £3,000; after year three, zero. Zero book value does not mean the asset has no operational value; many assets remain useful beyond their depreciation period.

Depreciation schedules vary by asset type. Hardware assets commonly use three to five-year periods depending on refresh strategy and asset category. Servers might depreciate over five years while laptops depreciate over three years, reflecting different technological obsolescence rates. Software licences depreciate over their licence term or useful life if perpetual. Cloud assets present depreciation challenges since they involve ongoing operational expenditure rather than capital investment; many organisations treat cloud as operational cost rather than depreciating asset.

Total cost of ownership extends beyond acquisition to include all costs throughout the lifecycle. For a laptop with £1,200 acquisition cost over a three-year life:

Cost elementYear 1Year 2Year 3Total
Acquisition£1,200£0£0£1,200
Deployment£150£0£0£150
Support allocation£200£200£200£600
Software licences£180£180£180£540
Accessories£80£30£30£140
Disposal£0£0£25£25
Annual total£1,810£410£435£2,655

The £1,200 laptop actually costs £2,655 over three years, or £885 annually. TCO analysis reveals that lower acquisition cost does not guarantee lower total cost. A £900 laptop requiring more support and replacement peripherals might exceed TCO of a £1,200 laptop with better reliability.

Asset registers supporting financial tracking must reconcile with accounting systems. Discrepancies emerge when assets are acquired without proper registration, disposed without proper recording, or moved between cost centres without updates. Quarterly reconciliation between the asset register and fixed asset ledger identifies discrepancies for investigation. A £15,000 variance between systems indicates either assets exist without register records, register records exist without corresponding accounting entries, or valuation calculations differ between systems.

Asset discovery and reconciliation

The asset register’s value depends on accuracy. Discovery identifies assets that exist; reconciliation compares discovered assets against register records to find gaps.

Discovery uses automated tools to identify assets connected to networks or deployed in cloud environments. Network discovery scans IP ranges and identifies responding devices by MAC address, hostname, and detected services. Agent-based discovery deploys software to devices that reports hardware specifications, installed software, and configuration details. Cloud discovery uses provider APIs to enumerate resources in subscriptions and accounts.

Discovery tools operate continuously or on scheduled intervals. Continuous discovery detects new devices within minutes of network connection. Scheduled discovery runs nightly or weekly scans to build comprehensive inventories. The choice depends on how dynamically the environment changes and how quickly visibility is required.

Discovery limitations affect coverage. Network discovery misses devices that are powered off, disconnected, or on isolated network segments. Agent-based discovery misses devices without agents installed, which often includes the devices most needing management oversight. Cloud discovery depends on proper credential configuration for each provider and subscription. Field locations with intermittent connectivity challenge discovery systems designed for always-connected environments.

Reconciliation compares discovery results against the asset register. The comparison identifies:

  • Discovered, not registered: Assets found by discovery that lack register records. These might be legitimate assets acquired without following process, shadow IT deployed by staff, or devices connected by visitors. Each requires investigation and either registration or removal.

  • Registered, not discovered: Register records without corresponding discovered assets. These might be assets powered off, in storage, disposed without recording, lost, stolen, or stolen. Investigation determines actual status and updates records accordingly.

  • Attribute mismatches: Assets found by both discovery and register but with conflicting attributes. Location might differ (register says London, discovery finds Manchester), configuration might differ (register says 16GB RAM, discovery finds 8GB), or status might differ (register says In Service, asset appears offline for 90 days).

Reconciliation frequency depends on environment volatility and compliance requirements. Monthly reconciliation suits stable environments. Weekly reconciliation suits dynamic environments with frequent changes. Compliance requirements might mandate specific reconciliation intervals and documentation of results.

A reconciliation cycle for an organisation with 500 hardware assets might proceed as follows: discovery identifies 487 devices on the network; the register contains 512 hardware records marked “In Service”; comparison reveals 15 discovered devices without register records and 40 register records without discovered matches. Investigation determines that 8 of the unregistered devices are contractor equipment requiring no action, 7 are staff-procured devices requiring registration and policy review. Of the 40 missing assets, 25 are laptops assigned to travelling staff currently offline, 10 are in storage awaiting deployment, and 5 cannot be located and require escalation.

Compliance and audit

Asset management supports compliance with external requirements including financial audit, donor reporting, and regulatory obligations.

Financial audit requires demonstration that asset register records accurately reflect organisational holdings. Auditors verify existence (do registered assets physically exist?), completeness (are all assets registered?), valuation (are recorded values accurate?), and ownership (does the organisation control these assets?). Physical verification involves sampling: auditors select assets from the register and verify physical existence, then select physical assets and verify register records. Discrepancy rates indicate asset management maturity. Rates below 2% indicate strong controls; rates above 5% indicate control weaknesses requiring remediation.

Donor requirements in grant-funded organisations impose specific asset tracking obligations. Major institutional donors require tracking of assets purchased with grant funds, potentially including serial numbers, locations, purchase documentation, and planned disposition at project end. USAID requires grantees to maintain property records with specified attributes and disposition approval for assets over threshold values. EU funding requires demonstration that assets were used for intended purposes throughout specified periods. The asset register must segment assets by funding source to support donor reporting and end-of-project handover.

Regulatory requirements affect asset management in specific contexts. Data protection regulations require knowing what systems process personal data and where that data resides. An asset inventory that identifies systems handling personal data supports data protection compliance. Healthcare organisations face asset tracking requirements for medical devices. Financial services organisations face requirements for trading systems and data repositories. Understanding which regulations apply and how they affect asset tracking shapes register design and retention.

Audit trails record changes to asset records over time. Every status change, location update, ownership transfer, and attribute modification creates a timestamped record of who made the change and what changed. Audit trails enable reconstruction of asset history and demonstrate control over asset records. When an auditor asks why an asset shows a £500 value when it was purchased for £3,000, the trail shows depreciation entries over three years.

Donor asset tracking

Grant-funded organisations face specific asset management requirements that extend beyond standard practice. Donor-funded assets carry obligations throughout their lifecycle and require dedicated tracking.

Assets purchased with grant funds must be identifiable as such from acquisition onward. The asset register must record funding source, grant identifier, and any specific donor requirements. A laptop purchased under a UN grant carries that association through its entire lifecycle, affecting what happens when the project ends or if the asset is no longer needed for project purposes.

Threshold requirements determine which assets require formal tracking and approval. USAID defines equipment as non-expendable tangible personal property with useful life over one year and acquisition cost over $5,000; items below threshold require less formal tracking. EU thresholds vary by programme. Organisations receiving multiple grants must track different thresholds and requirements by funding source.

Disposition requirements restrict what happens to donor-funded assets at project end or when assets are no longer needed. Options depend on asset value, donor requirements, and organisational need. Assets might transfer to the donor, transfer to partner organisations, transfer to host governments, be sold with proceeds returned to the donor, or remain with the organisation for continued use. Each outcome requires approval and documentation. An organisation cannot simply dispose of a £15,000 vehicle purchased with grant funds; donor approval and documentation of disposition protects against audit findings.

Segregation may be required for certain donors. Some government donors require that their funded assets are not commingled with other funding sources in ways that prevent clear identification. This might require separate inventory lists, separate storage, or clear marking. Asset management systems must support filtering and reporting by funding source to demonstrate compliance.

The asset register serves as evidence for grant close-out audits. When a three-year project ends, the organisation must account for all assets purchased with project funds: what was acquired, what remains, and what happened to each item. Incomplete records create audit findings, questioned costs, and potential requirement to return funds. Investing in accurate asset tracking throughout the project prevents close-out complications.

Implementation considerations

Asset management implementation varies dramatically based on organisational size, complexity, and resources. Attempting enterprise practices in a resource-constrained organisation wastes effort and creates abandoned processes. Starting too simply in a complex organisation creates control gaps and compliance failures.

For organisations with limited IT capacity

Organisations with minimal or single-person IT functions need asset management that provides essential visibility without consuming available capacity. The goal is knowing what exists and maintaining enough records to support basic operations and compliance.

The minimum viable asset management approach uses a spreadsheet-based register tracking hardware assets with core attributes: asset tag, description, serial number, assigned user, location, purchase date, cost, and status. A single spreadsheet with 200-300 rows serves most small organisations. Updates happen when assets change: new acquisitions add rows, assignments update the user field, disposals mark status as retired. Monthly review catches gaps before they accumulate.

Physical asset tags enable verification. Self-adhesive asset labels with sequential numbers cost under £0.15 each. Applying tags at acquisition creates the connection between physical asset and register record. Without tags, verification requires matching serial numbers, which takes longer and fails for assets without accessible serial numbers.

Software tracking can begin with a simple list of applications in use and their licence status. Detailed software asset management with entitlement tracking and compliance calculations exceeds what minimal IT functions can maintain. Knowing that the organisation uses a particular productivity suite under a nonprofit programme licence suffices until growth creates need for detailed tracking.

Discovery tools exist at low or no cost. Open source tools like OCS Inventory or Snipe-IT provide basic discovery and register functionality. Cloud providers offer native resource inventory features. Even simple network scanning with nmap provides visibility into connected devices. Automated discovery reduces manual effort and catches assets that bypass registration.

For organisations with established IT functions

Organisations with dedicated IT teams can implement structured asset management with defined processes, integrated tooling, and regular governance.

A dedicated asset management tool replaces spreadsheets when asset counts exceed what spreadsheets handle reliably (typically 300-500 assets) or when multiple people need concurrent access and audit trails. Commercial ITSM platforms include asset management modules. Purpose-built tools like Snipe-IT (open source), Lansweeper, or ServiceNow Asset Management provide specialised capability. Tool selection depends on integration requirements, budget, and feature needs.

Integration with other systems multiplies value. Asset management integrated with service desk enables linking incidents to affected assets, identifying patterns across similar assets, and automating asset lookup during support calls. Integration with procurement automates registration of purchased items. Integration with identity management tracks which users have which assets assigned. Integration with financial systems automates depreciation calculations and reconciliation.

Discovery automation runs continuously, maintaining current inventory without manual effort. Agent deployment to managed devices provides detailed software inventory and configuration data. Network scanning identifies unmanaged devices. Cloud integration enumerates resources across providers. Reconciliation reports highlight discrepancies for investigation rather than requiring manual comparison.

Governance includes defined processes for lifecycle transitions, periodic reviews with asset owners, and metrics tracking asset management effectiveness. An asset governance board or regular review meeting examines acquisition trends, reconciliation results, disposal backlogs, and compliance status. Metrics might include reconciliation discrepancy rate, percentage of assets with current owner assignment, and average time from acquisition to registration.

For federated organisations

Organisations with multiple autonomous locations or entities face asset management challenges around consistency, consolidation, and appropriate autonomy.

A federated model allows local asset management within global standards. Each country office or entity maintains its own asset register and processes while adhering to common data standards, classification schemes, and reporting requirements. Central IT provides the standards framework, template registers, and consolidated reporting; local IT operates within that framework with autonomy over daily management.

Data standards enable consolidation. If each location uses different classification schemes, asset identifiers, or attribute definitions, consolidated reporting becomes impossible. Defining common standards while allowing local extensions balances consistency with flexibility. The core schema is mandatory; local extensions accommodate specific needs.

Consolidated visibility enables central functions like global reporting, insurance coverage assessment, and strategic planning. This requires either a single consolidated database that all locations update, or regular data extracts from local systems into a central data warehouse. Real-time consolidation suits organisations with reliable connectivity; periodic batch consolidation suits organisations with intermittent connectivity between locations.

Local ownership with central oversight recognises that people closest to assets manage them best while ensuring overall compliance. Local asset managers handle daily operations. Central asset management validates compliance with standards, supports local capability building, and coordinates organisation-wide initiatives like technology refresh programmes.

Technology options

Asset management tools range from simple spreadsheets through enterprise platforms. Selection depends on asset counts, integration requirements, budget, and operational complexity.

Open source solutions

Snipe-IT provides full-featured asset management including hardware, software licences, consumables, and accessories. The web-based interface supports multiple users with role-based access. Features include check-in/check-out for assignable assets, maintenance scheduling, depreciation calculation, custom fields, and API for integration. Self-hosted deployment requires PHP and MySQL/MariaDB. Snipe-IT suits organisations with web hosting capability wanting full-featured asset management without licence costs.

OCS Inventory combines asset discovery with inventory management. Agents deploy to devices and report hardware and software inventory to a central server. The web console displays inventory data and supports grouping, reporting, and integration with deployment tools. OCS Inventory excels at automated inventory collection but provides less lifecycle management capability than Snipe-IT. Self-hosted deployment requires Linux, Apache, MySQL, and Perl.

GLPI provides asset management within a broader ITSM platform including service desk, change management, and knowledge base. Asset management features include inventory, financial tracking, contracts, and supplier management. GLPI integrates with OCS Inventory or FusionInventory for automated discovery. Organisations wanting integrated ITSM and asset management find GLPI provides both without separate systems.

Commercial solutions

Freshservice delivers cloud-based ITSM with integrated asset management. Discovery agents and network scanning automate inventory. Software licence management includes compliance tracking and optimisation recommendations. Cloud delivery eliminates infrastructure requirements but creates data residency considerations for organisations with geographic restrictions. Nonprofit pricing is available.

Lansweeper specialises in IT asset discovery and inventory. Agentless scanning discovers Windows, Linux, and network devices. Software recognition identifies installed applications. Cloud or self-hosted deployment options provide flexibility. Lansweeper excels at discovery and inventory but provides less lifecycle management than full asset management platforms.

ServiceNow Asset Management provides enterprise-grade capability within the ServiceNow platform. Features include hardware and software asset management, discovery integration, contract and licence management, and extensive automation capabilities. ServiceNow suits large organisations with complex requirements and budget for enterprise platforms. Integration with ServiceNow ITSM creates seamless asset-to-incident linking.

CapabilitySnipe-ITGLPIFreshserviceServiceNow
Hardware trackingYesYesYesYes
Software licencesYesYesYesYes
Automated discoveryVia integrationVia integrationBuilt-inBuilt-in
DepreciationYesYesYesYes
Self-hosted optionYesYesNoNo
ITSM integrationAPIBuilt-inBuilt-inBuilt-in
Nonprofit pricingN/A (free)N/A (free)YesLimited

See also