# CMDB Data Model: [Organisation or service management system name]

> Data model for a configuration management database (CMDB): scope and level of detail, configuration item (CI) classes, mandatory attributes, relationship types, naming and ID rules, data sources and reconciliation, data owners, CI lifecycle statuses, and the audit and data quality checks that keep the records trustworthy. Structure aligned with ISO/IEC 20000-1:2018 with Amendment 1:2024 (the current edition as of October 2026), clause 8.2.6 configuration management, with links to clause 8.2.5 asset management and clause 8.5.1 change management. Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Model only what a process uses. Every class and attribute must answer a question that incident, problem, change, security or financial management asks. Unused data decays and makes the rest untrusted.
- Start with services and the CIs that support the top ten services, then widen. Discovery tools can fill attributes; they cannot decide which relationships matter.
- Each class has one data owner and one authoritative source per attribute. Two sources for the same attribute is the most common cause of a CMDB nobody believes.
- Related templates: Change Request (`ops/change-request`) and Change Enablement Policy (`ops/change-enablement-policy`), which require CIs on every change; Incident Management Procedure (`ops/incident-management-procedure`); Problem Record (`ops/problem-record`); End-of-Life Software Register (`ops/eol-software-register`), which reads lifecycle dates from this model; Service Catalog and SLA (`compliance/iso-20000-service-catalog`); Access Review (`ops/access-review`).
- Example organisation: Corvid Commerce, a fictional online retailer. IDs match the other ITSM templates in this library. Delete every *Example* row before use.
-->

## Document control

<!-- Guidance: The data model is a controlled document. Adding or removing a class or a mandatory attribute is a change: record it here and tell the data owners. -->

| Field | Value |
|---|---|
| Document ID | [STD-ITSM-CMDB] |
| Version | [1.0] |
| Status | [Draft / Approved / Retired] |
| Owner (configuration manager) | [@configuration-manager] |
| Approvers/reviewers | [@head-of-service-management], [@security-lead], [@asset-manager] |
| CMDB tool | [Tool name and instance] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved with 9 classes and 7 relationship types |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added end-of-support date as a mandatory attribute for software products |

## 1. Scope and level of detail

<!-- Guidance: State which services and environments are in scope and the lowest level of CI you record. Questions: do you record individual containers, or the deployment that runs them? Do you record laptops? Pitfall: recording everything discovery finds, so that the important CIs drown in short-lived ones. -->

| Item | Decision *(Example)* |
|---|---|
| Services in scope | Every service in the service catalogue |
| Environments | Production and disaster recovery; staging only for CIs shared with production |
| Lowest level recorded | Application deployment, host or managed cloud resource, database instance, network device; not individual containers or pods |
| End-user devices | Recorded in the asset register, linked to the CMDB only for shared store devices |
| Short-lived resources | Recorded by their template or deployment, not each instance |
| Retention | Retired CIs kept for [3] years for audit and incident history |

## 2. CI classes and mandatory attributes

<!-- Guidance: Keep classes few and stable. Every class shares the common attributes; class attributes are added only when a process needs them. Mark the authoritative source for each attribute. -->

### 2.1 Common attributes (every class)

| Attribute | Description | Authoritative source *(Example)* |
|---|---|---|
| CI ID | Unique, never reused, format `CI-<CLASS>-NNNN` | CMDB (generated) |
| Name | Human-readable name following the naming rule in section 4 | Owning team |
| Class | One of the classes in 2.2 | CMDB |
| Status | Lifecycle status from section 6 | Change records |
| Owner (technical) | Team responsible for the CI | Owning team |
| Data owner | Person accountable for this record's accuracy | Configuration manager assigns |
| Environment | Production, disaster recovery, staging | Discovery |
| Criticality | Tier 1 to tier 3, inherited from the highest-tier service it supports | Service catalogue |
| Last verified | Date discovery or a human last confirmed the record | Discovery or audit |

### 2.2 Classes

| Class code | Class | Examples | Class-specific mandatory attributes | Data owner role |
|---|---|---|---|---|
| SVC | Business or technical service | Online checkout (catalogue ID SVC-CHK, recorded as a CI with its own CI ID) | Service owner, SLA reference, tier | Service owner |
| APP | Application or deployment | checkout-api (CI-APP-0201) | Repository, version, runtime, deployment method | Product engineering lead |
| DB | Database instance | orders-db-primary (CI-DB-0012) | Engine and version, backup policy reference, data classification | Database lead |
| HST | Host or virtual machine | [name] | Operating system and version, patch group | Infrastructure lead |
| CLD | Managed cloud resource | [name] | Provider, account, region, resource type | Cloud platform lead |
| NET | Network device or component | [name] | Model, firmware version, management address | Network lead |
| SWP | Software product (licensed or open source) | Database engine 16 | Vendor, version, end-of-support date, licence | Asset manager |
| CRT | Certificate or secret reference | [name] | Expiry date, issuer, renewal method (never the secret itself) | Security lead |
| SUP | Supplier service | Payment authorisation | Supplier, contract reference, support contact | Supplier manager |

## 3. Relationships

<!-- Guidance: Relationships make the CMDB useful for impact analysis. Define direction and meaning for each type and use as few types as you can. Pitfall: a generic "related to" link that nobody can reason about. -->

| Relationship | From class | To class | Meaning | Used by |
|---|---|---|---|---|
| depends on | SVC, APP | APP, DB, CLD, SUP | Source fails or degrades if target fails | Incident and change impact analysis |
| runs on | APP, DB | HST, CLD | Source is hosted on the target | Capacity, patching |
| connects to | APP | APP, DB, SUP | Network or API connection | Security review, firewall rules |
| instance of | APP, DB, HST, NET | SWP | Source runs this software product version | End-of-life tracking, vulnerability response |
| secured by | APP, NET, CLD | CRT | Source uses this certificate | Certificate expiry alerts |
| provided by | SUP | SUP | Supplier service delivered by a sub-supplier | Supplier management |
| member of | APP, HST | SVC | CI belongs to the service boundary | Service reporting |

```mermaid
erDiagram
  SERVICE ||--o{ APPLICATION : "depends on"
  APPLICATION }o--o{ DATABASE : "depends on"
  APPLICATION }o--|| HOST : "runs on"
  DATABASE }o--|| HOST : "runs on"
  APPLICATION }o--|| SOFTWARE_PRODUCT : "instance of"
  DATABASE }o--|| SOFTWARE_PRODUCT : "instance of"
  APPLICATION }o--o{ CERTIFICATE : "secured by"
  SERVICE }o--o{ SUPPLIER_SERVICE : "depends on"
```

The diagram shows the main relationship types for the Corvid Commerce example; cloud resources and network devices follow the same pattern as hosts.

## 4. Naming and ID rules

<!-- Guidance: IDs are for machines and never change; names are for people and follow a rule. Write the rule so that two teams naming the same kind of CI produce the same pattern. -->

| Rule | Example *(Example)* |
|---|---|
| CI ID is generated, never edited and never reused | CI-DB-0012 |
| Name pattern: `<service>-<component>-<role>` in lower case with hyphens | orders-db-primary |
| Environment is an attribute, not part of the name, except where the tool requires it | Environment = Production |
| Software product name includes vendor product name and major version | Database engine 16 |
| Renamed CIs keep their ID; the old name is kept as an alias | Alias: orders-pg-main |

## 5. Data sources, reconciliation and ownership

<!-- Guidance: Name one authoritative source per attribute and a reconciliation rule for conflicts. Data owners confirm their records at a fixed cadence. -->

| Source | Feeds | Frequency *(Example)* | Conflict rule |
|---|---|---|---|
| Cloud provider inventory API | CLD, HST attributes, runs on | Hourly | Wins for technical attributes |
| Infrastructure as code state | CLD, APP deployment attributes | On every apply | Wins for intended configuration; drift raises a task |
| Deployment pipeline | APP version, member of | On every deployment | Wins for version |
| Network discovery | NET, connects to | Daily | Wins for presence; owner confirms new devices |
| Asset and licence register | SWP vendor, licence, end-of-support date | Weekly | Wins for commercial attributes |
| Human input through change records | Owner, data owner, criticality, depends on | On each change | Wins for ownership and business attributes |

Data owners confirm their CIs every [quarter]. A CI not verified for [90] days is flagged "Unverified" in impact analysis.

## 6. CI lifecycle statuses

<!-- Guidance: Statuses change only through change records or discovery, so that the CMDB and the change log tell the same story. -->

| Status | Meaning | Set by |
|---|---|---|
| Planned | Approved in a change, not yet built | Change record |
| In build | Being built or tested | Change record |
| Live | Supporting a service | Change record or deployment |
| Maintenance | Temporarily out of service for planned work | Change record |
| Retiring | Replacement in progress, no new dependencies allowed | Change record |
| Retired | Removed from service, record kept for history | Change record |

## 7. Audit and data quality

<!-- Guidance: Measure data quality and audit the CMDB on a schedule. Report results in the service review. Each failed check creates a correction task for the data owner. -->

| ID | Check | Measure | Target *(Example)* | Frequency |
|---|---|---|---|---|
| CMDB-Q01 | Completeness | Tier 1 CIs with every mandatory attribute filled / tier 1 CIs | 98% | Monthly |
| CMDB-Q02 | Accuracy | Sampled CIs matching the live environment / CIs sampled | 95% | Quarterly audit of [30] CIs |
| CMDB-Q03 | Freshness | CIs verified in the last 90 days / Live CIs | 95% | Monthly |
| CMDB-Q04 | Orphans | Live CIs with no relationship to a service | 0 for tier 1 | Monthly |
| CMDB-Q05 | Change linkage | Implemented changes with at least one CI / implemented changes | 100% | Monthly |
| CMDB-Q06 | Unauthorised CIs | CIs found by discovery with no change record | Each investigated | Weekly |

Audit procedure *(Example)*: the configuration manager selects a random sample stratified by class, a second person compares each record with the live system, and differences are logged as correction tasks with the data owner. Incident records that show wrong CMDB data (`ops/incident-management-procedure`, section 11) are added to the audit findings.

## 8. Standards mapping and references

<!-- Guidance: Clause numbers refer to ISO/IEC 20000-1:2018; check them against the edition you are certified to. -->

| Section of this model | ISO/IEC 20000-1:2018 clause | ISO/IEC 27001:2022 Annex A | Topic (short original label) |
|---|---|---|---|
| 1, 2, 3 Scope, classes, relationships | 8.2.6 Configuration management | 8.9 Configuration management | Define and record CIs and relationships |
| 2 Software products and licences | 8.2.5 Asset management | 5.9 Inventory of information and other associated assets | Asset records linked to CIs |
| 5, 6 Sources and statuses | 8.2.6, 8.5.1 Change management | 8.32 Change management | Control CI changes |
| 7 Audit | 8.2.6, 9.2 Internal audit | 5.36 Compliance with policies, rules and standards | Verify accuracy |

| Reference | Version or date checked | Use |
|---|---|---|
| ISO/IEC 20000-1:2018 with Amd 1:2024 | Current edition as of October 2026 | Clause numbers |
| ISO/IEC 27001:2022 with Amd 1:2024 | Current edition as of October 2026 | Annex A control numbers |

## Standard and licence note

Structure aligned with ISO/IEC 20000-1:2018 with Amendment 1:2024, clause 8.2.6 configuration management and the related clauses in section 8, and with ISO/IEC 27001:2022 Annex A controls 5.9, 8.9 and 8.32. Both are copyrighted standards: this template cites clause and control numbers with short original labels only; no text, table or definition is copied. Official text: ISO, purchase or licensed access: https://www.iso.org/standard/70636.html (ISO/IEC 20000-1) and https://www.iso.org/standard/82875.html (ISO/IEC 27001), also sold by national standards bodies. Classes, attributes, relationship types and targets are illustrative, not taken from any standard or tool vendor model. All text is original, written for this collection. Check the current edition of any standard you certify against. Template licence: MIT.