Configuration management is knowing what your systems are set to, deciding what they should be set to, and keeping the two the same. One name covers two jobs.
The first is a record of what you have and how the parts depend on each other, usually a configuration management database. The second is tooling that applies a desired state and reapplies it when someone changes it.
- One name, two jobs: a record of what you run, and enforcement of what it should be
- A CMDB answers what do we have. A tool answers is it still set that way
- Configuration drift is the problem both of them exist to fight
- Start with a written standard build, not with a product
- Software configuration management is a third, mostly unrelated meaning
On this page
- Two different things share the name configuration management
- The record: a CMDB and a change process
- The enforcement: a desired state, applied over and over
- What configuration management looks like in a 30 person company
- The configuration management process, in four steps
- Drift is the problem both sides are trying to solve
- Software configuration management is a different job
- Where people go wrong
- Comparison
- FAQ
Two meaningsTwo different things share the name configuration management
Ask two people what configuration management means and you get two answers. One describes a register of everything the business runs, and a process for changing it. The other describes a tool that pushes a file and a service setting to two hundred servers and puts them back when someone edits them.
Both are right. The service management tradition treats it as recordkeeping and control. The automation tradition treats it as code that enforces a desired state. They attack the same problem from opposite ends, and a company that buys one and declares the job done still has the other gap wide open.
So what is configuration management, stripped of the tooling? It is five activities that predate every product now claiming the name, and the configuration management process is built from them.
Identification. Decide which systems, components and data are under control, and give each one an identity that survives a rebuild or a rename.
Baselines. Agree the approved state of each item at a point in time. A baseline is the thing a later audit compares against, and without one there is nothing to drift from.
Change control. Every change to a baselined item goes through a decision rather than a whim, and the approved change becomes the new baseline.
Status accounting. Report the current state: what changed, when, and by whom. This is the data most teams never collect and most auditors ask for first.
Audit. Verify that the running systems match the record, instead of assuming they do.
The recordThe record: a CMDB and a change process
The service management side starts with a list. Every server, switch, firewall, laptop, application and license is a configuration item, and a configuration management database holds those items along with the relationships between them.
The relationships are the point. An asset list tells you a server exists. A CMDB tells you which application runs on it, which switch it depends on, and who calls when it reboots. Without that, every change is a guess about the blast radius.
A change process sits on top. Proposed changes are recorded, approved, applied, and then written back into the record. IT configuration management fails at that last step more than anywhere else, because updating the record is the part nobody is measured on.
The enforcementThe enforcement: a desired state, applied over and over
The automation side writes the target state down as data and makes a tool enforce it. Microsoft describes its Desired State Configuration as a declarative configuration platform, in which the state of a machine is described in a format that should be clear even to a reader who is not a subject matter expert.
That is the shape of every tool in this category. You declare what should be true: this package installed, this service running, this firewall rule present, this file with these contents. The tool compares, corrects, and can run again tomorrow with no further effect.
Agent or agentless. Some configuration management tools run a component on each machine that pulls its policy on a timer. Others connect over SSH or a remote management protocol and push. Pull scales quietly. Push is easier to reason about on a small estate.
Declarative, not a script. A script that installs software runs whether or not the software is already there. A declarative definition checks first, which is what makes repeated runs harmless instead of destructive.
The same definition across environments. A test system and a production system built from one definition behave the same way. When those environments drift apart, a change that passed testing fails in production and nobody can prove which difference did it.
Automation is what makes this affordable. Applying a baseline to forty systems by hand is a day of work and three mistakes. Applying it from a definition takes minutes and lands identically on every machine, which is the argument software development made first and the rest of infrastructure management inherited.
It overlaps with infrastructure as code. Infrastructure as code creates the servers, networks and storage. Configuration management decides what is true inside them. Plenty of teams use one tool for both and never draw the line, which is fine until an audit asks where a setting came from.
Small estatesWhat configuration management looks like in a 30 person company
A company with one file server, a firewall, thirty laptops and three cloud services does not need a CMDB product or an automation platform. It needs the two things those products exist to provide: a written standard, and a way to notice when reality stops matching it.
Write the standard build down. One page per device type: the image, the applications, the security settings, the local administrator policy, the backup agent. A build you cannot describe cannot be rebuilt, which is also the provisioning problem.
Keep the list somewhere shared. Device, owner, serial number, warranty date, operating system, role. At this size that spreadsheet is your configuration management database. The test is whether it is accurate, not whether it is a product.
Enforce with what you already own. Group Policy for domain joined Windows, Intune or an RMM tool for everything else. Both apply settings repeatedly rather than once, which is the enforcement half in miniature.
Deciding what to leave out matters as much as what goes in. No small team can manage every setting on every system. Pick the ones that cause outages or fail an audit: patching, encryption, administrator rights, the backup agent, firewall state.
Check for drift on a schedule. Once a month, compare the running estate with the standard: patch level, disk encryption, antivirus state, local administrators, open ports. The RMM console is usually where those answers already live, unread.
The processThe configuration management process, in four steps
Both sides of the discipline follow the same four steps, which is the clearest sign they are one process applied to different systems. The names come from classic configuration management practice and are worth knowing, because audit questions use them.
Identification. Decide what is under control and give each item an identity: the servers, network devices, applications and services that matter, each with an owner. Everything that is not identified is outside the process by definition, which is how shadow systems survive.
Control. No change to a controlled item happens outside the agreed route. In an automation tool the route is a change to the desired state file, reviewed and then applied. In a service management process it is a change request with an approval and a rollback plan. The point is the same: changes arrive one way.
Status accounting. Record the current state and the history of changes, so anyone can answer what this system looks like now and what changed last week. This is the part small organizations skip, and it is the part every incident and every audit needs.
Audit. Check periodically that reality matches the record, and correct whichever of the two is wrong. An automation tool does this on every run by reporting what it had to change. A manual process needs somebody to look.
A 30 person company runs all four informally: a list of systems with owners, changes made through one route, a note of what changed, and a look at the list twice a year. The steps do not require a platform. They require that somebody owns them.
DriftDrift is the problem both sides are trying to solve
Configuration drift is what happens between changes. Someone disables a service to test something. A vendor's installer switches a feature on. A rebuild skips a step. A setting is changed at three in the morning during an outage and never changed back.
None of those changes is recorded anywhere, and each one makes the estate slightly less like its documentation. The data that would have explained it, who changed what and when, was never captured. The first symptom is usually that two machines built the same way behave differently, and nobody can say which one is wrong.
NIST's SP 800-128, the Guide for Security-Focused Configuration Management of Information Systems, states the goal as managing and monitoring the configurations of information systems to achieve adequate security and minimize organizational risk while supporting the desired business functionality. Monitoring is the word that earns its place there.
A baseline nobody checks is a document. A baseline something compares against every week is a control. Patch management is the same idea narrowed to one attribute, and it is the easiest place to start, because the reporting already exists.
The third meaningSoftware configuration management is a different job
Software configuration management grew up inside development teams, where the data under control is source code rather than a server's settings: branches, build artifacts, release numbers, and which build is deployed where. The process has the same five steps, applied to software instead of systems.
If your team ships software, both matter, and the release is where they meet. Software configuration management says which version was built. The other kind says which machines are running it, and what else on those machines might explain the bug.
PitfallsWhere people go wrong
Buying a CMDB before writing the standard. An empty database with a workflow attached does not tell anyone what a laptop is supposed to look like. The one page standard does, and it costs an afternoon.
Letting the record rot. A configuration management database that is six months stale is worse than no database, because people trust it. Tie updates to the change process or expect decay.
Confusing asset management with configuration management. Asset management tracks ownership, cost and lifecycle. Configuration management tracks settings and dependencies. The same laptop sits in both, answering different questions.
Automating a build nobody agreed on. Encoding the current mess into a tool makes the mess faster and harder to argue with. Decide the target state first, in writing, with the people who have to support it.
Leaving network and cloud out. Firewall rules, switch configurations and identity settings are configuration items too, and they are the ones with no backup and no owner.
Treating the tool as the process. A tool reports drift. Somebody still has to decide whether the drift or the baseline is wrong, and that decision is the actual practice.
ComparisonThe record, the enforcement, and what a small company actually runs
| Criterion | The record | The enforcement | A 30 person company |
|---|---|---|---|
| Question it answers | What do we have, and what depends on it | Is this machine still set the way we decided | Both, at a smaller scale |
| Kept as | A database of configuration items | Code or policy describing a desired state | A shared list plus Group Policy or an RMM |
| Updated by | People, after the change | The tool, on every run | Mixed, which is the weak point |
| Fails when | Nobody writes the change back | The desired state was never agreed | Nobody reads the drift report |
| Effort to start | Weeks of inventory | Days per platform | An afternoon per device type |
| Catches drift | At audit, if then | Continuously | Monthly, if it is scheduled |
| Covers network and cloud | Yes, if you put them in | Only what the tool supports | By hand, and often skipped |
The first row is the honest split. A record answers questions about dependencies that no enforcement tool can, because the tool only knows the machines it manages. Enforcement answers questions about current state that no database can, because a database holds what somebody typed.
The bottom two rows are where small estates lose. Network gear, firewalls and cloud identity settings drift exactly like servers do, and they are usually outside whatever tool the company bought.
FAQFrequently asked questions
What is configuration management?
It is the practice of defining what your systems should be set to, recording what they are set to, and keeping the two aligned. In IT it covers both a register of systems and their dependencies, and the tooling that enforces settings on servers and end user devices.
What is a configuration management database?
A CMDB is a store of configuration items, which are the things you manage, along with the relationships between them. Its value is in the relationships: knowing that a server runs a specific application and depends on a specific switch changes how you plan a change.
What are configuration management tools?
Software that applies a declared state to machines and reapplies it on a schedule. They differ in whether an agent pulls the policy or a central server pushes it, which platforms they cover, and how much of the network and cloud they can reach.
What is software configuration management?
The version control discipline around source code and builds: branches, artifacts, release numbering, and knowing which build is deployed where. It shares the name and the vocabulary but is a separate job from managing machine settings.
What is the configuration management process?
Four activities in a loop. Identify what is under control, control changes to it, report the current state, and audit that the state matches the record. Everything else, including tool choice, is an implementation detail of those four.
Is configuration management the same as change management?
No. Change management is the approval and scheduling of a change. Configuration management is the record of what the change affects and the enforcement of the result. They are usually run together, and each one is weaker alone.
What is configuration drift?
The gap that opens between the documented state and the running state as people make untracked changes. It builds up quietly through emergency fixes, vendor installers and rebuilt machines, and it shows up as two supposedly identical systems behaving differently.
Does a 30 person company need configuration management?
It needs the outcome, not the product. A written standard build per device type, a shared inventory that is kept accurate, settings enforced through Group Policy or the RMM, and a monthly check that the estate still matches. That is the whole practice at that size.
Is infrastructure as code the same thing?
Not quite. Infrastructure as code provisions the servers, networks and storage. Configuration management defines what is true inside a machine once it exists. Modern tools blur the two, and many teams use a single tool for both.
What does IT configuration management include?
Servers, end user devices, network hardware, cloud tenants, applications and the settings on all of them. Anything whose configuration can change and whose change can cause an outage belongs in scope, which usually means more than the first draft of the list.
Where does security fit in?
NIST publishes SP 800-128, the Guide for Security-Focused Configuration Management of Information Systems, which frames the goal as managing and monitoring configurations to achieve adequate security and minimize risk while still supporting the business. Hardened baselines and drift monitoring are the practical output.
What is a configuration item?
Any system, component, document or piece of data you have decided to manage as a unit: a server, a switch, an application, a license, a build. If a change to it can break something else, it belongs in the record with its dependencies.
How does configuration management work across environments?
The same definition builds development, test and production, and the differences between them are parameters rather than manual steps. That is what makes a test result meaningful, because the environments differ only where you decided they should.
Where should we start?
With one device type. Write down what a standard laptop should look like, compare five real laptops against it, and fix the differences. The gap you find in that hour is the argument for everything that follows.
Keep readingRelated concepts
Read next · Operations What a CMDB Is, and the Question That Justifies One What goes in a configuration management database, and the relationships that make it worth keeping. Open this next10 min- Operations · 11 min Infrastructure as Code, and the File That Knows What Exists Where the line sits between building the servers and deciding what is true inside them.
- Operations · 10 min Provisioning How a standard build becomes a machine handed to a new starter, step by step.