ISO 20000-1 Configuration Management (Clause 9.1)

ISO 20000 SMS Configuration Management CMDB IT Service Management ITSM

Overview

Build a configuration management process and CMDB design that satisfies ISO/IEC 20000-1:2011 Clause 9.1. This skill guides you through identifying configuration item types, defining attributes and naming conventions, designing the CMDB relationship model, establishing the CI lifecycle, and setting up baseline and verification procedures.

The CMDB is the backbone of IT service management – it is the single source of truth that incident, problem, change, and release management all depend on. An auditor will want to see that you have defined what constitutes a CI, how CIs are identified and tracked, how relationships between CIs are mapped, and that you verify the CMDB against reality on a regular schedule. This skill structures the CMDB design so it is comprehensive without being unwieldy.

For a step-by-step walkthrough, see the ISO 20000 SMS workspace tutorial .

What It Covers

CI types – hardware, software, documentation, services, licenses, SLAs
CI attributes – mandatory and type-specific fields per CI category
Naming convention – consistent identification scheme with type prefix and versioning
CMDB structure – relationship types (runs on, depends on, used by, installed on, part of)
CI lifecycle – registration, active use, under change, retired with authorization rules
Baseline and verification – audit schedule, scope, reconciliation procedures

Example Conversation

You: We need to design our CMDB for ISO 20000 certification. We’re an MSP managing infrastructure for several clients. We use ServiceNow but haven’t structured the CMDB properly yet.
Agent: I’ll help you design the CMDB for Clause 9.1. Let me start by defining the CI types relevant to your managed services. Based on a typical MSP, I’d suggest:
CI Type Description Examples
Hardware Physical infrastructure Servers, network switches, firewalls, storage arrays
Software Applications and platforms Operating systems, middleware, business applications
Virtual Infrastructure Virtualization and cloud VMs, containers, cloud instances
Network Network components VLANs, load balancers, DNS entries
Documentation Controlled documents SLAs, process documents, runbooks
Service Logical services Managed Infrastructure, Cloud Hosting
Does this cover your landscape, or are there CI types I should add?
You: Add licenses as a CI type – we track Microsoft and VMware licensing for our clients. Also add SLAs since each client has different service level agreements.
Agent: Good additions. Now let’s define attributes for each CI type. Every CI needs mandatory attributes:
ci_id – unique identifier following the naming convention
name – human-readable name
owner – person or team responsible
status – current lifecycle state
version – current version
For hardware, I’d add: model, serial_number, location, warranty_expiry, rack_position. For licenses: license_type, quantity, expiry_date, vendor, assigned_to. Does that work?
You: Yes. For the naming convention, we want something that includes the client code.
Agent: Here’s a proposed naming convention:
Pattern: {CLIENT}-{TYPE_PREFIX}-{SEQUENTIAL_ID}-v{VERSION}
Examples:
NGF-HW-0001-v1 – Northgate Financial, Hardware, first item
RTC-SW-0015-v3 – RetailCo, Software, version 3
MDT-VM-0042-v1 – MedTech, Virtual Machine
Type prefixes: HW (hardware), SW (software), VM (virtual), NW (network), DOC (documentation), SVC (service), LIC (license), SLA (SLA).
You: Perfect. Now what about relationships?
Agent: CMDB relationships are critical for impact analysis. I’d define these relationship types:
runs_on – Application runs on server
depends_on – Service depends on component
used_by – CI is used by a service or team
installed_on – Software installed on hardware/VM
part_of – Component is part of a larger assembly
For verification, I recommend quarterly CMDB audits comparing records against automated discovery scans, with reconciliation of discrepancies within 10 business days. Shall I set that up?
You: Yes, quarterly audits. And we want a configuration baseline captured before every major release.
Agent: I’ll run the cmdb_design_validator now…
Result: All checks passed. 8 CI types defined with attributes. Naming convention documented with client prefix pattern. 5 relationship types specified. Verification process established with quarterly audit frequency and pre-release baseline capture.

CI Type	Description	Examples
Hardware	Physical infrastructure	Servers, network switches, firewalls, storage arrays
Software	Applications and platforms	Operating systems, middleware, business applications
Virtual Infrastructure	Virtualization and cloud	VMs, containers, cloud instances
Network	Network components	VLANs, load balancers, DNS entries
Documentation	Controlled documents	SLAs, process documents, runbooks
Service	Logical services	Managed Infrastructure, Cloud Hosting

Sample Output Excerpt

The skill produces a structured JSON CMDB design file and a markdown process document. Here is a representative excerpt from the JSON.

{
  "ci_types": [
    {
      "type": "hardware",
      "description": "Physical infrastructure components",
      "attributes": ["ci_id", "name", "owner", "status", "version", "model", "serial_number", "location", "warranty_expiry", "rack_position"]
    },
    {
      "type": "software",
      "description": "Applications, operating systems, and middleware",
      "attributes": ["ci_id", "name", "owner", "status", "version", "vendor", "license_type", "install_date"]
    },
    {
      "type": "virtual_infrastructure",
      "description": "VMs, containers, and cloud instances",
      "attributes": ["ci_id", "name", "owner", "status", "version", "host", "cpu", "memory", "cloud_region"]
    },
    {
      "type": "license",
      "description": "Software and service licenses",
      "attributes": ["ci_id", "name", "owner", "status", "vendor", "license_type", "quantity", "expiry_date"]
    }
  ],
  "naming_convention": {
    "pattern": "{CLIENT}-{TYPE_PREFIX}-{SEQUENTIAL_ID}-v{VERSION}",
    "prefixes": {
      "hardware": "HW", "software": "SW", "virtual_infrastructure": "VM",
      "network": "NW", "documentation": "DOC", "service": "SVC",
      "license": "LIC", "sla": "SLA"
    },
    "examples": ["NGF-HW-0001-v1", "RTC-SW-0015-v3", "MDT-VM-0042-v1"]
  },
  "relationship_types": ["runs_on", "depends_on", "used_by", "installed_on", "part_of"],
  "verification_process": {
    "audit_frequency": "quarterly",
    "scope": "All active CIs",
    "reconciliation_procedure": "Compare CMDB records against discovery scan results, resolve discrepancies within 10 business days",
    "baseline_trigger": "Before every major release"
  }
}

Extension Tools

`cmdb_design_validator`

Validates cmdb-design.json for ISO 20000-1 Clause 9.1 completeness. Run after generating the CMDB design.

Check	What It Does
CI types defined	Confirms at least one CI type is documented with attributes
CI attributes per type	Verifies each CI type has a defined set of attributes
Naming convention	Checks that a naming pattern is present with examples
Relationship types	Validates that relationship types are specified
Verification process	Confirms audit frequency, scope, and reconciliation procedure are documented

Getting Started

Activate the ISO 20000-1 Configuration Management skill and have your service catalog ready – the agent uses it to understand which infrastructure and applications support your services. If you have an existing asset inventory or discovery tool output, share that as a starting point for CI type definition.

The completed CMDB design is referenced by change management (every change must link to affected CIs), release management (deployment updates the CMDB), and incident management (impact analysis uses CI relationships).