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.
Document control
| 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
| 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
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
| 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 |
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
| 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
| 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
| 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
| 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
| 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.