# ISO 20000-1 Configuration Management (Clause 9.1) > Establish configuration management and the CMDB for ISO/IEC 20000-1:2011 Clause 9.1. Define CI types, attributes, naming conventions, CMDB structure, CI lifecycle, and verification procedures. Tags: ISO 20000, SMS, Configuration Management, CMDB, IT Service Management, ITSM ## Example Prompts - Define configuration item types and attributes for our IT services - Design a CMDB structure with CI relationships and naming conventions - Establish a configuration baseline and verification audit schedule URL: https://rakenne.app/skills/iso20000-configuration-management/index.md Try this skill: https://rakenne.app/a/?skill=iso20000-configuration-management ## 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**](/learn/tutorials/iso20000-sms-workspace-guide/). ### 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. ## 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. --- ```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). --- Back to [Skill Library](https://rakenne.app/skills/index.md)