What is a CMDB, and how do you keep it live?

What is a CMDB?

A CMDB (configuration management database) is a record of the configuration items (CIs) that make up your services, such as applications, databases, servers, cloud resources, network devices and the third-party services you depend on, with their key attributes and the relationships between them. Its purpose is to answer, at any moment, what a service runs on, who owns each part and what depends on what. That is what separates it from an asset inventory, which tracks what you own and what it costs, and from a monitoring tool, which tracks whether components are healthy right now.

ITIL 4 calls the discipline service configuration management. Its stated purpose is to make accurate and reliable information about services, and the CIs that support them, available when and where it is needed, including how CIs are configured and related. ITIL 4 treats IT asset management (the lifecycle and cost of assets) and monitoring and event management (changes of state) as separate practices, which shows where a CMDB sits between them.

NIST SP 800-128, the US guide to security-focused configuration management, defines a configuration item as an aggregation of system components designated for configuration management and treated as a single entity.

What goes into a CMDB?

A CMDB holds three kinds of information. NIST SP 800-128 leaves granularity to the organisation (a workstation and its peripherals can be one component or several) and expects every component to sit with a single accountable owner.

• Configuration items: the things you manage as units. Typical CI classes are business services, applications, databases, virtual machines and containers, cloud resources such as load balancers and storage buckets, network devices, identity tenants and third-party services.
• Attributes: the facts about each CI that people act on, such as owner, support group, environment, version, region, criticality and the service it supports. Keep the list short, because every attribute you add is one more thing that can go stale.
• Relationships: how CIs connect, such as runs on, depends on, connects to, is owned by and is supplied by. Relationships turn a list into a map, and they are what you need most during an incident.

What is a CMDB used for?

A CMDB earns its keep when someone has to make a decision quickly and needs to know how things connect. The common uses are:

• Incident impact (blast radius): when a database or a cloud region degrades, the relationships tell you which services, customers and teams are affected, so you can prioritise and communicate early.
• Change risk: before a change, you can see what the target CI supports and who depends on it, which is the basis for a sensible approval and test plan.
• Root cause: the CMDB plus the change record narrows the question to what changed on this CI, or on something it depends on, shortly before the failure.
• Service ownership: every CI has an owner and a support group, so alerts and tickets reach someone who can act.
• Audits and regulation: auditors and supervisors ask for an inventory of systems, what supports which service and a history of changes. A current CMDB answers from records, not a spreadsheet assembled the week before.

Why do most CMDBs drift?

Drift is the gap between what the CMDB says and what is actually running. Almost every CMDB drifts, and the causes are structural rather than a lack of discipline.

• Manual upkeep: if people must update records after doing the real work, the update loses to the next urgent task, and records go slowly wrong.
• Discovery that sees one slice: a network scanner sees devices, an endpoint agent sees installed software, a cloud integration sees one provider. Each is accurate within its slice, and none of them sees the whole service.
• No source of authority per field: when the cloud API, the monitoring tool and a ticket disagree about a server's owner or environment, something has to decide which one wins. Without stated rules, the last import overwrites the rest, and good data is replaced by stale data.
• Changes outside the change process: emergency fixes, console changes, auto-scaling and infrastructure-as-code applied straight to production all alter configuration without touching a change ticket. Containers and serverless functions can come and go within minutes, faster than any nightly process can follow.
• Nothing gets retired: decommissioned servers and deleted cloud resources stay in the CMDB because no process removes them, so the map shows dependencies that no longer exist.

What does CMDB drift cost during an incident?

The cost shows up at the worst moment. Responders working from a stale map page the owner of a system that changed hands months ago, miss a downstream service that was never recorded, or spend the opening of the incident working out what the failing component connects to. Customer updates go out with the wrong scope.

Root cause takes longer for the same reason. If the change that triggered the failure was made outside the change process, it is not linked to the CI, and the team has to reconstruct it from cloud audit logs and chat history.

There is a slower cost too. Once engineers catch the CMDB being wrong during an incident, they stop using it, and an unused CMDB decays faster still.

How do you keep a CMDB live?

Stop treating the CMDB as something people write, and treat it as something your own tools keep current, with people reviewing the exceptions. NIST SP 800-128 calls the checking part configuration monitoring: confirming that the components found in a system are consistent with the component inventory. A live CMDB rests on six ideas.

• Automated discovery from authoritative sources: read CIs and attributes from the systems that already know them. Cloud provider APIs know what resources exist and how they are configured. Identity providers know accounts, groups and who has left. Monitoring tools know what is running and what talks to what. Ticketing and on-call tools know services, owners and support groups.
• Reconciliation with a source of authority per field: decide, for each attribute, which source wins. The cloud API might own region and instance type, the ticketing tool might own service owner. When two sources disagree and no rule settles it, flag the conflict for a person instead of overwriting.
• Relationship and dependency mapping: combine declared relationships (from infrastructure-as-code and service catalogues) with observed ones (from traces, flow logs and monitoring topology), and record which kind each is. A declared dependency that is never observed deserves a question.
• Changes and incidents linked to CIs: every change ticket, pull request, deployment and incident should point at the CIs it touched. That link is what lets the CMDB answer what changed before something broke.
• Provenance: store where each fact came from and when it was last confirmed. A simple scheme marks each fact as live-verified (confirmed by a source within its refresh window), declared (entered by a person or a file) or stale (not confirmed when it should have been).
• Drift reviewed as a queue: route each discrepancy (a new resource with no owner, a CI no source can see, a conflicting attribute) to a named owner as a small task. A short queue reviewed weekly keeps the map trustworthy; a yearly clean-up only makes it right for a week.

A step-by-step plan to make your CMDB live

Start narrow, prove that the data stays current, then widen the scope.

• 1. Start from services, not devices. List the business services that matter most and work down to the CIs that support them.
• 2. Name the authoritative source for each CI class and each important attribute, and write the precedence rules down.
• 3. Connect those sources read-only, with frequent polling for cloud inventory and event-driven updates for changes and incidents.
• 4. Define how records match across sources (cloud resource IDs, hostnames, tags) so that one server does not appear as three CIs.
• 5. Map relationships, starting with what is declared and adding what is observed.
• 6. Link every change and incident to the CIs it touched, including code changes and emergency changes.
• 7. Record provenance for each fact, and set a staleness threshold per source so that a connector that has gone quiet is noticed.
• 8. Run drift as a weekly queue with named owners, and retire CIs that no source has seen within an agreed period.
• 9. Measure the queue rather than running an annual accuracy audit: open discrepancies, their age and the share of services with a confirmed owner show whether the CMDB is staying live.

What do NIS2 and DORA say about asset inventories?

Neither law uses the word CMDB, but both expect you to know your assets, how they are configured and how they depend on each other.

NIS2 (Directive (EU) 2022/2555) lists ten minimum cybersecurity risk-management measures in Article 21(2). Point (i) is human resources security, access control policies and asset management, and several other measures, such as incident handling (point (b)), business continuity (point (c)) and supply chain security (point (d)), are hard to evidence without an accurate inventory. Our guide to the Article 21 measures covers all ten.

For cloud computing service providers, data centre service providers, managed service providers, managed security service providers and other digital providers, Commission Implementing Regulation (EU) 2024/2690 spells out what asset management means. Point 12.4 of its Annex requires a "complete, accurate, up-to-date and consistent" inventory that lists operations and services and the network and information systems supporting them, with changes to entries recorded in a traceable manner. Points 6.3 and 6.4 add configuration management and change management, including assessing a change's potential impact before it is made. For other entities, the national law that transposes NIS2 sets the detail.

DORA (Regulation (EU) 2022/2554), which has applied to EU financial entities since 17 January 2025, is more explicit still. Article 8(1) requires financial entities to identify, classify and document their ICT supported business functions, the information and ICT assets supporting them, and their dependencies, reviewing the classification at least yearly. Article 8(4) requires them to map the configuration of those assets and the links and interdependencies between them, and Article 8(6) requires the inventories to be updated periodically and every time a major change occurs. Article 8(5) covers processes that depend on ICT third-party service providers, which connects to the register of information required by Article 28(3).

A CMDB does not make an organisation compliant with either law. It provides the inventory, dependency and change evidence that much of the work relies on.

How should a mid-market team or MSP choose a CMDB approach?

There are four broad approaches. Most organisations combine two, so the useful question is which one holds the picture people trust during an incident.

• Enterprise ITSM suites with a built-in CMDB: mature data models, change and incident workflow in the same platform, and long track records with auditors. They usually need an integrator or an internal platform team to configure discovery and maintain data quality, which suits organisations that already run the suite for service management.
• Discovery and inventory tools: good at finding devices, installed software and licences. They tend to see one slice, and relationships to business services and owners usually have to be maintained separately.
• Observability tools: strong on runtime dependencies for whatever they instrument. They map their own telemetry, so ownership, supplier relationships and systems without an agent fall outside the picture.
• A reconciled live map: reads from several of the tools above, reconciles them into one model with per-field rules and provenance, and keeps itself current. Its quality depends on connector coverage, and it can sit alongside an existing ITSM CMDB rather than replace it.

What should you ask before choosing a CMDB?

• Which sources does it read, and how often does each one refresh?
• When two sources disagree about a field, what decides, and can you see the rule?
• Can it show, for any fact, where it came from and when it was last confirmed?
• Are changes and incidents linked to the CIs they touched?
• For MSPs: is each client's data isolated, and how is that enforced?

How Alexus AI helps

Alexus AI is a Dublin-built operational intelligence platform built around a CMDB that keeps itself current. It connects read-only to your cloud, monitoring, ticketing and code tools (status on the connectors page) and reconciles them into one live service and dependency map. Every item shows where it came from and when it was last confirmed: live-verified, declared or stale. When sources disagree, a stated rule per field decides, and if Alexus is still unsure it asks a person instead of overwriting.

On top of the map, the platform shows blast radius, links incidents to what they affect with a proposed cause a human confirms, and records what changed, what it touched and who approved it. You can ask about a named system in Slack or Microsoft Teams. For MSPs, each client is isolated in the database and priced per managed client. Alexus reads ServiceNow as one source rather than replacing it; the comparison page sets out where other approaches are stronger. Alexus is early-stage, working with design partners, and does not make anyone compliant.

This guide is general guidance, not legal advice.

Frequently asked questions

What is the difference between a CMDB and an asset inventory?

An asset inventory records what you own: hardware, software and licences, with cost, contract and lifecycle data. A CMDB records how the things that deliver your services are configured and how they depend on each other. ITIL 4 treats these as separate practices, IT asset management and service configuration management. Many CIs are also assets, but a CMDB adds relationships, owners and change history, which is what you need during an incident or a change review.

What is a configuration item (CI)?

A configuration item is anything you manage as a unit because it helps deliver a service: an application, a database, a server, a cloud resource, a network device or a third-party service. NIST SP 800-128 defines it as an aggregation of system components designated for configuration management and treated as a single entity. Each CI has attributes, such as owner and environment, and relationships to other CIs, such as runs on or depends on.

Does NIS2 require a CMDB?

Not by name. Article 21(2)(i) of NIS2 includes asset management among the ten minimum measures, and Implementing Regulation (EU) 2024/2690 requires cloud providers, data centre providers, MSPs, MSSPs and other digital providers to keep a complete, accurate, up-to-date and consistent asset inventory, with changes recorded traceably. A CMDB that stays current is a practical way to meet that expectation, but how you evidence it is for you to decide under your national rules.

Does DORA require a CMDB?

DORA does not mention a CMDB, but Article 8 of Regulation (EU) 2022/2554 requires financial entities to identify and classify their ICT assets, map their configuration and the links and interdependencies between them, and update those inventories periodically and every time a major change occurs. That is the core job of a CMDB. One that stays current is a natural basis for Article 8 evidence and for the register of information on ICT third-party arrangements.

How often should a CMDB be updated?

Continuously, from the source systems, rather than on a calendar. Cloud resources can change within minutes, so a monthly or yearly update leaves the map wrong for most of its life. A practical target is for each source to refresh automatically, with changes and incidents arriving as events, and for people to review the drift queue weekly. DORA sets a floor for financial entities: update inventories periodically and every time a major change occurs.

What is a good alternative to an enterprise CMDB for a mid-market company?

If you already run an enterprise ITSM suite for service management, its CMDB is usually worth keeping, fed by better discovery. If you do not, or your CMDB has fallen out of date, a reconciled live map that reads from your cloud, monitoring and ticketing tools can give you a current CMDB without an integrator programme. Alexus AI takes that approach, and it can read an existing ServiceNow CMDB as one of its sources.

Sources

• NIST SP 800-128: Guide for Security-Focused Configuration Management of Information Systems
• NIST CSRC Glossary: configuration item
• ITSM.tools: the ITIL 4 management practices and their purpose statements
• Directive (EU) 2022/2555 (NIS2), Article 21, EUR-Lex
• Commission Implementing Regulation (EU) 2024/2690, Annex points 6.3, 6.4 and 12.4, EUR-Lex
• Regulation (EU) 2022/2554 (DORA), Articles 8 and 28, EUR-Lex