Configuration Management: The CMDB, Dependencies, and Configuration Baselines

Executive Summary

When a critical service goes down, the first question is always the same: what changed, and what does this depend on? When a change is proposed, the essential question is: what could this break? When a vulnerability is announced, the urgent question is: which of our systems are affected? Every one of these questions is a question about relationships and configuration — and answering them from memory, under pressure, is exactly how organizations make outages worse. Configuration management is the discipline that makes these questions answerable, by maintaining accurate information about the components that make up IT services, how each is configured, and — crucially — how they depend on one another.

Configuration management is often confused with asset management, but they answer different questions. An asset list tells you what you have and what it cost; configuration management tells you how it is set up and what depends on what. Its central artefact is the configuration management database (CMDB), which records the individual components — configuration items, or CIs — along with their attributes and the web of relationships between them. That web is the whole point: it turns a flat list of parts into a map of how the estate actually works, and it is what makes change management, incident resolution, problem management, security response, and recovery genuinely effective rather than guesswork. Alongside the relationship view sits a second dimension of configuration management — defining how systems should be configured (baselines) and detecting when reality drifts away from that standard.

This vendor-neutral guide covers configuration management in both senses. It explains configuration items and the CMDB, shows why dependency mapping delivers impact analysis and faster resolution, describes how to decide what to track and at what level of detail, covers configuration baselines and drift and the role of automation in enforcing desired state, and tackles the hardest part — keeping the CMDB accurate over time. Grounded in established service-management and security-configuration practice, the aim is a practical understanding of how to know not just what you have, but how it all fits together and whether it is configured the way it should be.

The Map of How Everything Connects

The foundational idea of configuration management is that the value lies not in the individual components but in the relationships between them. A CMDB captures both.

Configuration management — the map of how everything connects

Consider a business service such as online ordering. It depends on a web application, which depends on a database and an external payment API; the web app runs on a server host and traffic passes through a network and firewall. Each of those components is a configuration item (CI), and the arrows between them are its relationships. Configuration management records the CIs, their attributes — name, type, version, owner, status, location — and, most importantly, how they depend on each other, storing all of it in the CMDB. This is what distinguishes it from an asset register: the asset list tells you the server exists and what it cost, while the CMDB tells you that this server runs the web app that the online ordering service depends on. That web of relationships is what turns a list of parts into an understanding of the whole, and it is the difference between knowing you own a component and understanding what happens if it fails.

Why It Matters: Impact Analysis

The reason to invest in mapping relationships becomes clear the moment something needs to change or breaks. The payoff is impact analysis — the ability to see consequences before they happen and trace causes when they do.

Why it matters: answer “what breaks if this changes?”

A well-maintained CMDB enables several high-value capabilities. Change impact analysis lets you see, before a change, everything it could affect — which services depend on the component being changed — feeding directly into change management’s risk assessment. Faster incident resolution comes from tracing a downed service through its CIs to find the failed component quickly, moving from symptom to cause in minutes rather than hours. Root cause and problem management benefit from seeing what a failing CI has in common across multiple incidents, exposing a shared dependency. Service mapping links technical components to the business services that depend on them, connecting the technical to the business. Security and compliance are served by knowing what is affected by a vulnerability and being able to prove control over the estate, so patches and audits are scoped accurately. And recovery planning uses the dependency map to rebuild systems in the right order, restoring foundations first. Without the CMDB, every one of these becomes guesswork under pressure — which is why configuration management is what makes change, incident, and problem management genuinely effective.

Configuration Items: What to Track, and How Much

A configuration item is anything you need to manage in order to deliver a service, but the most common and consequential mistake in configuration management is trying to track absolutely everything. Deciding what to record, and at what level of detail, is critical.

Configuration items — what to track, and how much

Common CI types include hardware such as servers, network devices, and endpoints; software and applications; services, both business and technical; cloud resources and virtual machines; databases and middleware; and documentation and configurations. Each CI carries attributes — name, type, version, owner, status, location — and relationships to other CIs. The discipline lies in setting the right level of detail: track what you need for impact analysis and change, not every cable and setting, because a CMDB that is too granular becomes impossible to maintain and therefore inaccurate and useless. A maintainable CMDB is worth more than a theoretically complete one. And the most valuable relationships to capture are those that map CIs to business services — linking technical components to the services the business actually cares about, so that the question “which service does this affect?” always has an answer. Scope to purpose: the CMDB exists to support decisions, not to be an exhaustive encyclopedia of the estate.

Configuration Baselines and Drift

Configuration management has a second dimension beyond relationships: defining how systems should be configured and ensuring they stay that way. This is where configuration meets security and consistency.

Configuration baselines and drift — desired vs actual state

A baseline is the desired state — the approved, known-good configuration for a system, secure, standardized, and documented: “how it is supposed to be.” Drift is the actual state as it wanders over time through manual tweaks, ad hoc fixes, and undocumented changes: “how it actually is now.” The gap between them is a risk. The practice is to detect and remediate — continuously comparing actual configuration to the baseline, alerting on and correcting the difference. The most effective way to hold systems to their baseline is automation through infrastructure as code: define configuration as code, apply it consistently, and let tooling continuously re-assert the baseline, so that drift is corrected automatically rather than discovered during an outage or a failed audit. Drift matters for security in particular, because an unpatched or misconfigured system is itself drift from the secure baseline. Consistent configuration means fewer surprises, easier support, and stronger security — the payoff of managing not just what systems are, but how they are set up.

Keeping the CMDB Accurate

The hardest and most important challenge in configuration management is accuracy. An out-of-date CMDB is a trap: people trust it and act on wrong information, which is worse than having no CMDB at all. Several practices, applied together, keep it true.

The hard part: keeping the CMDB accurate

Automate discovery so tools scan the estate to find CIs and relationships automatically, because manual entry alone never stays current. Federate sources by pulling from asset tools, cloud platforms, and monitoring systems into one reconciled view, producing one truth from many systems. Tie updates to change so that every change updates the CMDB and configuration and change are managed together, ensuring the CMDB reflects reality by process. Scope it sensibly, tracking what supports impact analysis and change and resisting the urge to track everything, because a maintainable CMDB beats a complete one. Audit and verify by periodically reconciling the CMDB against discovered reality, catching and fixing drift in the data itself. And own it and govern it with clear ownership, standards for CI types, and conventions for naming and relationships, because data quality is a responsibility, not a hope. Measured by CMDB accuracy, the percentage of CIs from automated discovery, service-mapping coverage, drift detected and corrected, and the rate at which changes update the CMDB, configuration management becomes a trustworthy foundation rather than a well-intentioned liability.

Configuration Management Checklist

• Define configuration management as recording components, attributes, and relationships — not just an asset list.
• Identify configuration items (CIs) at a level of detail that supports impact analysis and change.
• Capture relationships between CIs, especially links to the business services they support.
• Use the CMDB for change impact analysis, incident resolution, and problem management.
• Establish configuration baselines — the approved, secure desired state — for key systems.
• Detect configuration drift and remediate it, ideally through automation and infrastructure as code.
• Automate discovery to find CIs and relationships rather than relying on manual entry.
• Federate data from asset, cloud, and monitoring sources into one reconciled view.
• Tie every change to a CMDB update so configuration and change are managed together.
• Scope the CMDB to what is useful; resist tracking everything.
• Audit the CMDB against discovered reality and correct data drift.
• Assign clear ownership and governance; measure CMDB accuracy and coverage.

Best Practices

Prioritize accuracy over completeness. An accurate CMDB covering the systems that matter is far more valuable than a comprehensive one that no one trusts. Scope deliberately and keep what you track correct.

Automate discovery and updates. Manual maintenance guarantees drift. Use discovery tools to populate and reconcile the CMDB, and tie updates to your change process so the data stays true by design.

Capture the relationships that matter. The value of a CMDB is in its dependencies, especially the links from technical components up to business services. Map those first; they answer the questions that count.

Manage baselines and drift. Define how systems should be configured, then detect and correct drift — ideally with infrastructure as code that continuously enforces the desired state. Consistent configuration is easier to support and more secure.

Integrate with change, incident, and problem. Configuration management delivers its value through the other practices. Use it for change impact analysis, incident tracing, and root-cause work, and it will earn its keep.

Own and govern the data. Assign accountability, set standards for CI types and naming, and audit regularly. A CMDB without governance decays into the untrustworthy trap it was meant to avoid.

Common Mistakes

Confusing the CMDB with an asset register. Treating configuration management as just an inventory misses its whole point — the relationships and configuration that enable impact analysis. The two are distinct and complementary.

Trying to track everything. Attempting to record every cable, setting, and object produces a CMDB too large and volatile to maintain, which quickly becomes inaccurate and abandoned. Scope to what supports decisions.

Letting the CMDB go stale. An out-of-date CMDB is worse than none because people act on wrong information. Without discovery, change integration, and audits, accuracy inevitably erodes.

Capturing CIs but not relationships. A list of components without their dependencies cannot answer “what breaks if this changes?” The relationships are the value; do not skip them.

Ignoring configuration drift. Focusing only on the relationship view while systems quietly drift from their baselines leaves security gaps and inconsistency. Manage desired state as well as dependencies.

Managing configuration separately from change. When changes do not update the CMDB, the data and reality diverge immediately. Configuration and change management must operate together.

Frequently Asked Questions

What is configuration management? It is the practice of maintaining accurate information about the components (configuration items) that make up IT services — their attributes and, crucially, their relationships and dependencies — usually in a configuration management database (CMDB). It also encompasses defining and maintaining how systems should be configured.

What is a CMDB? A configuration management database is the repository that records configuration items and the relationships between them. It is what allows an organization to answer questions like “what does this service depend on?” and “what would this change affect?”

What is a configuration item (CI)? A CI is anything that needs to be managed to deliver a service — a server, application, service, database, network device, cloud resource, and so on — along with its attributes and its relationships to other CIs.

How is configuration management different from asset management? Asset management is the financial and lifecycle view — what you own and what it costs. Configuration management is the technical and relationship view — how components are configured and how they depend on each other. They overlap but answer different questions.

What is configuration drift? Drift is the gap between how a system is supposed to be configured (its baseline) and how it actually is, caused by manual changes, ad hoc fixes, and undocumented tweaks over time. Detecting and correcting drift — ideally through automation — keeps systems consistent and secure.

How do we keep a CMDB accurate? Automate discovery, federate data from multiple sources, tie CMDB updates to your change process, scope the CMDB to what is useful, audit it regularly against reality, and assign clear ownership. Accuracy is the single most important property of a CMDB.

Conclusion

Configuration management is what allows an organization to understand not just what it has, but how it all fits together and whether it is set up the way it should be. By recording configuration items, their attributes, and above all their relationships in a CMDB, it turns a flat inventory into a map of the estate — and that map is what makes impact analysis, fast incident resolution, root-cause problem solving, accurate security response, and orderly recovery possible. The alternative, answering “what depends on this?” from memory during a crisis, is exactly the guesswork that configuration management exists to eliminate.

The discipline has two faces, and both matter: the relationship view that the CMDB provides, and the desired-state view of baselines and drift that keeps systems consistent and secure. Success in both comes down to the same principles — prioritize accuracy over completeness, automate discovery and enforcement, capture the relationships and baselines that carry real value, integrate tightly with change management, and govern the data as the asset it is. Get configuration management right and it quietly powers nearly every other operational practice; neglect it and those practices are left navigating in the dark. The goal is simple to state and demanding to achieve: an accurate, trusted picture of how the environment is built and how it is meant to run.

References

• ITIL 4 — Service Configuration Management practice (overview)
• ISO/IEC 20000-1 — Service management (configuration management)
• NIST SP 800-128 — Security-Focused Configuration Management of Information Systems
• NIST SP 800-53 — Configuration Management (CM) control family
• CIS Controls — Secure Configuration of Enterprise Assets
• ITIL 4 — Configuration items and the CMDB (overview)
• NIST SP 800-70 — National Checklist Program (configuration baselines)