Asset management

ISO/IEC 20000-1 Clause 8.2.5 requires you to manage all assets in scope of your service management system (SMS) across their full lifecycle, from identification and acquisition through use, maintenance, and disposal, so services remain deliverable and controlled ¹. Operationalize it by defining asset scope, building an authoritative inventory, assigning owners, and wiring asset events into change, incident, configuration, and supplier processes.

Key takeaways:

• Your asset inventory must be lifecycle-based, not a one-time list; every asset needs an owner and a status path from acquisition to disposal.
• “Within SMS scope” is the make-or-break boundary; document what’s in scope and why, and align it with your service catalog.
• Evidence matters: show consistent records of identification, approvals, maintenance, and disposal, plus traceability to service delivery.

“Asset management requirement” in ISO/IEC 20000-1 is straightforward to read and easy to fail in practice: you must prove you control assets that enable service delivery, across the entire lifecycle, within the boundaries of your SMS ¹. Auditors typically do not get stuck on whether you own a perfect CMDB; they get stuck on whether your asset records match reality, whether lifecycle events are governed, and whether service risks are controlled when assets change hands, age out, or get disposed.

This requirement applies to more than laptops. For ISO 20000 purposes, “assets” include anything you rely on to deliver services in scope: infrastructure, platforms, endpoint devices used to operate services, and often critical software components and subscriptions. The operational goal is consistent service delivery, which means you need reliable identification, controlled acquisition, known usage and assignment, planned maintenance, and verifiable disposal.

This page gives requirement-level implementation guidance you can put into action quickly: scope decisions, workflow steps, minimum records, and the exam questions that trigger nonconformities. It is written for a Compliance Officer, CCO, or GRC lead who must coordinate IT, service owners, procurement, and security without creating paperwork that no team will maintain.

Regulatory text

ISO/IEC 20000-1:2018 Clause 8.2.5 (Asset management) states: “The organization shall manage assets within the scope of the service management system throughout their lifecycle, including identification, acquisition, use, maintenance and disposal, to ensure services can be delivered effectively.” ¹

Operator interpretation (what you must do):

1. Define which assets are “within the scope of the SMS.” The scope must be explicit, consistent with your service catalog, and defensible during audit ¹.
2. Manage assets across a lifecycle. You need repeatable controls and records for identification, acquisition, use/assignment, maintenance, and disposal ¹.
3. Connect asset control to service delivery outcomes. If an asset fails, changes, or is disposed, you should be able to show how you prevented service disruption or unmanaged risk ¹.

Plain-English requirement: what “good” looks like

You have a single, authoritative way to answer:

• What assets do we rely on to deliver each in-scope service?
• Who owns each asset record and who approves lifecycle events?
• Where is it, what is it used for, and what’s its current status?
• What maintenance is required and what maintenance happened?
• How do we securely dispose, return, or decommission it? All of that must be true for assets you own and assets provided by third parties that are still required for service delivery within your SMS scope ¹.

Who it applies to (entity and operational context)

Applies to: Any organization or service provider operating an ISO/IEC 20000-1 service management system ¹.

Operational context where it shows up:

• IT service providers delivering managed services, hosting, service desk, or operations functions.
• Internal IT organizations running an SMS for enterprise services (identity, email, network, business apps).
• Hybrid environments with cloud subscriptions, managed devices, virtual infrastructure, and third-party-operated components.

Practical scoping note: Auditors typically anchor asset scope to services in your service catalog. If a service is in scope, the enabling assets are usually in scope too unless you document a clear boundary and rationale.

What you actually need to do (step-by-step)

Step 1: Set the asset scope boundary (and document it)

Create a short “Asset scope statement” aligned to your SMS scope:

• In-scope services (from the service catalog)
• Asset types covered (hardware, virtual, cloud services, network devices, endpoints used to deliver the service, key software/subscriptions)
• Exclusions and rationale (for example, employee personal devices if not used for service delivery, with justification)
• Interfaces to other systems (CMDB, endpoint management, procurement system)

Artifact: Asset Management Standard / Procedure + scope statement ¹.

Step 2: Define lifecycle states and required fields (minimum viable asset record)

Create a lifecycle model with consistent states:

• Identified → Requested → Approved → Acquired → In service → Under maintenance → Retired → Disposed/Decommissioned

Define required fields for each asset record (tailor by asset type):

• Unique asset ID; asset type; service association; owner; custodian/user; location/environment
• Acquisition source (purchase/lease/third party); date acquired; warranty/support info
• Configuration baseline reference where applicable
• Status + status change history
• Disposal method + evidence reference

Audit trap: If you cannot show who owns the record and who approves status changes, you are not “managing” the asset lifecycle in any meaningful sense ¹.

Step 3: Build and reconcile the inventory (authoritative source + feeds)

Decide what system is the system of record for asset inventory. Many organizations use:

• IT asset management tool for physical assets
• CMDB for configuration relationships
• Cloud inventory for subscriptions and resources

What matters is that you can demonstrate:

• Inventory completeness for in-scope services
• Reconciliation logic (how you detect missing/duplicate/ghost assets)
• Controlled updates (who can edit, and how edits are logged)

Practical approach: Start with a “critical services first” reconciliation. Pick a handful of in-scope services, list supporting assets, then verify the inventory matches operational reality.

Step 4: Control acquisition (request, approve, and record)

Establish an acquisition workflow:

• Requestor identifies service need and asset type
• Approval by service owner (and finance/procurement as needed)
• Security/IT review for certain asset classes (define triggers)
• Record creation at approval time or purchase time, not after deployment
• Receiving and tagging (physical assets) or account/subscription assignment (cloud)

Evidence: purchase requests, approvals, receiving records, asset tags or identifiers, onboarding checklist completion ¹.

Step 5: Control use (assignment, access, and permitted purposes)

For assets in use:

• Assign a custodian/user and permitted use context
• Tie access to identity lifecycle (joiner/mover/leaver) where relevant
• For shared operational assets, define who can administer and how changes are authorized
• For third-party-provided assets, document responsibility boundaries (who maintains, who patches, who disposes)

Exam hangup: “We have it in inventory” is not enough if you cannot show who is responsible for it today.

Step 6: Maintenance (planned + reactive) linked to service risk

Define what maintenance means by asset class:

• Preventive maintenance schedules where applicable
• Patch/upgrade responsibilities (internal team vs third party)
• Support contracts and renewals tracking
• Incident-to-asset linkage (so recurring failures drive maintenance decisions)

Evidence: maintenance tickets, work orders, patch records, renewal records, incident trends tied to asset IDs ¹.

Step 7: Disposal and decommissioning (secure, complete, provable)

Disposal must be an auditable event:

• Approval to retire (service owner confirms no service dependency remains)
• Data handling steps (wipe, destruction, key revocation, account closure)
• Update inventory status and remove from monitoring/backup where relevant
• Disposal evidence retained (certificate of destruction, return receipt, decommission record)

Risk implication: Uncontrolled disposal is a common root cause for orphaned access paths, untracked dependencies, and service outages triggered by “surprise” decommissions ¹.

Required evidence and artifacts to retain (audit-ready checklist)

Maintain these in a form you can produce quickly:

• Asset management policy/standard and procedure (scope + lifecycle) ¹
• Asset inventory export showing required fields, owners, and status
• Sampled lifecycle traceability (request → approval → acquisition → assignment → maintenance → retirement → disposal)
• Change records linked to asset changes for in-scope services (where your SMS requires change control)
• Maintenance records (tickets/work orders) linked to asset IDs
• Disposal/decommission evidence (certificates, return receipts, provider confirmations)
• Role definitions: asset owner, custodian, approver, asset manager

Common exam/audit questions and hangups

Expect these questions, and prepare packaged evidence:

1. “Show me the asset inventory for Service X.” Provide a service-to-asset mapping and the inventory extract.
2. “Pick one asset and walk me through its lifecycle.” Have a ready “audit sample pack” with linked records.
3. “Who can edit the asset register and how do you prevent unauthorized updates?” Show access controls and change logs.
4. “How do you know assets are disposed and not just missing?” Show the disposal workflow and evidence retention.
5. “What about cloud assets and subscriptions?” Show how you identify, assign owners, and decommission accounts/resources.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating asset management as a spreadsheet exercise. Fix: require lifecycle events to create/update records, and make owners accountable for accuracy.
• Mistake: No explicit SMS scope mapping. Fix: document which services are in scope and map supporting assets; keep the mapping current when services change ¹.
• Mistake: Disposal is informal. Fix: disposal must be a controlled step with approvals and evidence.
• Mistake: Third-party assets ignored. Fix: track third-party-provided assets that are required to deliver your services, and document responsibility boundaries.
• Mistake: Inventory exists but no reconciliation. Fix: define how you detect “unknown” assets and how quickly teams must investigate.

Tooling and operationalization (where Daydream fits)

If you struggle with collecting consistent evidence across procurement, ITSM tickets, CMDB, and third-party records, Daydream can act as the control hub that maps each lifecycle requirement to required artifacts and assigns owners to keep audit packs current. The goal is not more process; it is faster proof and fewer gaps during sampling.

Practical 30/60/90-day execution plan

Day 1–30: Establish control points and minimum inventory

• Confirm SMS scope and list in-scope services ¹.
• Draft the asset lifecycle states and required fields per asset class.
• Name asset owners for critical services and assign responsibilities.
• Stand up a minimum authoritative inventory (even if interim) for critical services.
• Implement a basic acquisition and disposal workflow with required approvals.

Day 31–60: Prove lifecycle traceability and tighten governance

• Run reconciliation for critical services; resolve unknowns and duplicates.
• Build “audit sample packs” for a small set of assets across types (endpoint, server/VM, network, cloud subscription).
• Connect maintenance records and incident records to asset IDs.
• Lock down edit permissions; implement logging and review for key fields.
• Document third-party asset responsibility boundaries in contracts or operating procedures where applicable.

Day 61–90: Expand coverage and make it routine

• Extend inventory and lifecycle controls to remaining in-scope services.
• Add monitoring checkpoints: periodic owner attestations, disposal evidence checks, renewal reviews.
• Align change management with asset lifecycle events (new, modify, retire).
• Run an internal audit-style sampling to test whether records match reality and whether evidence is retrievable quickly.
• Implement Daydream (or equivalent) to centralize evidence requests, owner tasks, and audit-ready exports.

Frequently Asked Questions

Do we need a CMDB to meet the ISO 20000 asset management requirement?

ISO/IEC 20000-1 requires lifecycle management and control of in-scope assets; it does not prescribe a CMDB tool ¹. A CMDB can help with relationships, but you can comply with another authoritative inventory if it is accurate and governed.

What counts as an “asset” under ISO 20000-1 Clause 8.2.5?

Any asset within your SMS scope that you rely on to deliver services, across identification through disposal ¹. In practice this includes infrastructure, endpoints used to operate services, and cloud subscriptions/resources tied to in-scope services.

How do we handle assets managed by a third party?

Include third-party-provided assets that are necessary for in-scope service delivery in your lifecycle controls and records, even if the third party performs maintenance or disposal steps ¹. Document who does what, how you get evidence, and how you verify completion.

What evidence is most persuasive in an audit?

Auditors respond well to end-to-end traceability: a request, approval, record creation, assignment, maintenance history, and disposal proof for sampled assets ¹. Keep a ready pack that links these records by asset ID.

How detailed does the inventory need to be?

Detailed enough to support lifecycle control and service delivery outcomes, with clear ownership, status, and service association for in-scope assets ¹. If you cannot confidently answer “who owns it” and “where it is in lifecycle,” the record is not sufficient.

What’s the fastest way to reduce risk without boiling the ocean?

Start with critical in-scope services and build accurate inventories and lifecycle workflows around them first, then expand ¹. Pair that with disciplined disposal controls because disposal gaps create persistent operational and security exposure.

Footnotes

1. ISO/IEC 20000-1:2018 Information technology — Service management