Do Your Change Management Tools Alert You to Unplanned Changes?
| CMDB change management is the practice of keeping configuration item records accurate by reconciling what change management processes approve against what IT discovery tools actually observe in the environment. When these two pictures diverge — because of last-minute workarounds, unauthorized modifications, or incomplete implementations — the CMDB becomes unreliable, and every downstream ITSM process built on it carries that risk. Automated IT discovery gives organizations an independent, continuous view of the environment that surfaces unplanned changes before they compound into incidents. |
Most IT organizations invest heavily in change management processes — review boards, approval workflows, change advisory boards (CABs). Yet incidents caused by changes that bypassed or deviated from those processes remain one of the leading sources of unplanned downtime. The gap is not in the process. It is in the verification layer: nothing in a standard change management system confirms that what was approved was actually implemented as intended.
This blog covers how CMDB change management works, where the gaps form, how IT discovery closes them, and what your team should do when discovery surfaces a discrepancy. You will learn: how unplanned changes enter a CMDB environment, what the as-observed vs. as-expected framework means, how to detect configuration drift automatically, and what a complete change verification workflow looks like.
What Is CMDB Change Management?
A configuration management database (CMDB) is a centralized repository that records every configuration item (CI) in an IT environment — servers, applications, network devices, cloud resources — and the relationships between them. Change management is the ITSM process that governs how modifications to those CIs are requested, reviewed, approved, and implemented.
When the two work together, every approved change should produce a corresponding update to the CMDB. The CMDB reflects the current, authorized state of the environment. The change management process provides the governance layer that determines what state is authorized.
In practice, the two rarely stay in sync without an automated verification mechanism. According to ITIL guidance on unauthorized changes, any modification to a CI that was not submitted, reviewed, and approved through the formal change request process is classified as an unauthorized change — and unauthorized changes are among the most common causes of CMDB degradation and service-impacting incidents.
| ‘What is an unplanned change in ITIL?’ An unplanned change in IT change management is any modification to a configuration item (CI) that was not submitted, reviewed, and approved through the formal change request process. These include last-minute workarounds, shadow IT deployments, and partial implementations where the approved change was not executed as documented. Unplanned changes are the leading cause of CMDB data drift and a primary contributor to incident-causing blind spots in IT operations. |
Why Good Change Management Is Not Enough to Keep Your CMDB Accurate
Change management processes, no matter how mature, share a structural limitation: they record intent, not outcome. A change request documents what was approved. It cannot confirm what was actually deployed.
This creates three categories of CMDB accuracy risk that change management alone cannot address:
1. Undocumented Workarounds
When a scheduled change encounters an obstacle — a dependency failure, a configuration conflict, a time constraint — engineers often implement temporary fixes to keep the work moving. These workarounds are rarely submitted as change requests. They are invisible to the CMDB until discovery scans the environment and surfaces them.
2. Incomplete Implementations
A change request may be approved for a full software rollout across 40 servers. Only 37 are updated before the maintenance window closes. The change is marked complete. The CMDB is updated to reflect the approved scope. Three servers now carry an unauthorized configuration — one that the CMDB does not show and that creates a silent vulnerability or compliance gap.
3. Shadow IT and Unauthorized Modifications
Infrastructure teams, application owners, and cloud teams often make configuration changes outside the formal change request process — adding a firewall rule, spinning up a cloud instance, adjusting a service dependency. Each of these creates a discrepancy between the approved environment documented in the CMDB and the actual environment running in production.
The EMA Research report on CMDB maturity and ServiceOps found that organizations with automated, multi-source discovery practices achieve measurably better change success rates and faster incident resolution — precisely because discovery closes the gap that change management cannot cover on its own.
The As-Observed vs. As-Expected Framework
The most reliable way to understand CMDB accuracy gaps is to treat your IT environment as two separate pictures that must be continuously reconciled: the as-observed picture from discovery tools, and the as-expected picture from your CMDB and change management systems.
| ‘How does IT discovery validate CMDB accuracy?’ IT discovery validates CMDB accuracy by comparing the as-observed state of the environment against the as-expected state recorded in the CMDB. Discrepancies — new undocumented assets, unauthorized modifications, removed components still listed as active — represent either unplanned changes or deviations from approved change requests. Without this validation layer, CMDB data degrades silently and every impact analysis built on it carries compounding risk. |
When the two pictures match, your CMDB is accurate. When they diverge, you have evidence of one of the following:
- Something has changed that was not previously known to your change management process
- Something new has entered the environment without a corresponding change request
- Something is missing that was documented as present — either removed or non-functional
- A CI has moved to a new location or been reconfigured in a way not reflected in the CMDB
- A CI is being used in a new way that changes its relationship dependencies
- A CI still exists in the CMDB even though it was reportedly decommissioned
Each of these represents either an unplanned change or a planned change implemented differently than approved — and each warrants investigation. Without discovery running the as-observed comparison, these discrepancies accumulate silently, compounding the risk of every impact analysis your team runs from CMDB data.
What Is Configuration Drift — and Why It Matters
| ‘What is configuration drift?’ Configuration drift occurs when an IT asset’s actual state diverges from its approved baseline in the CMDB — typically due to unplanned changes or undocumented workarounds. Drift is invisible to change management systems, which record approvals, not outcomes. Automated discovery tools that flag configuration drift as it occurs give IT teams the reconciliation layer needed to maintain CMDB accuracy and reduce failed change rates. |
Configuration drift is the accumulated effect of small, unrecorded deviations. A software version that was not updated uniformly. A firewall rule applied on some nodes but not others. A cloud resource tagged differently from its CMDB record. Individually, each deviation is minor. Collectively, they produce a CMDB that is unreliable at exactly the moment it is most needed — during incident response, change impact analysis, or a compliance audit.
Sustaining CMDB accuracy over time requires automating the rules that flag configuration drift as soon as discovery surfaces it. Virima’s IT discovery continuously scans the environment and alerts the team to unplanned changes, closing the gap between what is approved and what is actually running in production.
How IT Discovery Detects Unplanned Changes: A 5-Step Process
IT discovery acts as an independent audit of your change management process. Here is how the detection workflow operates:
- Scheduled or continuous discovery scans the environment — Virima’s discovery tools poll network devices, query software inventories, and map service dependencies on a configurable cadence. For high-risk environments, continuous scanning detects changes within minutes.
- Discovery builds an as-observed snapshot — each scan produces a current-state record of every CI: software version, location, active services, relationship dependencies, and configuration attributes.
- The as-observed snapshot is compared against the CMDB baseline — every CI in the snapshot is reconciled against its current record in the CMDB. Attributes that differ from the approved baseline are flagged.
- Discrepancies are classified by change type — new CIs not in the CMDB, modified CIs that deviate from their baseline, missing CIs still recorded as active, and relationship changes that affect service maps.
- Flagged discrepancies are routed to investigation workflows — each flagged item is linked to the relevant CMDB record and, where applicable, to the change request that should have covered it. Teams can then determine whether the discrepancy represents an unauthorized change, an implementation error, or a legitimate undocumented change that requires a retrospective change record.
| ‘How do I detect unauthorized changes in my IT environment?’ Unauthorized IT changes are detected by running continuous discovery scans and comparing the observed environment against CMDB baselines. Any configuration item whose version, location, or dependency relationships differ from the approved record represents a potential unauthorized change. Virima’s automated discovery surfaces these discrepancies and routes them to investigation workflows — closing the gap between what change management approves and what actually runs in production. |
Multiple Discovery Sources Give You a More Complete Picture
Discovery is not a single-lens process. Different discovery tools illuminate different facets of the IT environment:
| Discovery Type | What It Finds | CMDB Action if Discrepancy Found |
| Network device polling | Unauthorized device additions, IP reassignments, topology changes | Open change investigation; update CI relationship map |
| Software inventory scans | Version mismatches, unauthorized installs, missing patches | Flag for unauthorized change review; create retrospective CR if needed |
| Cloud infrastructure discovery | Shadow IT cloud resources, untagged assets, misconfigured services | Create new CI record; initiate change request or decommission workflow |
| Service dependency mapping | Relationship changes between applications, databases, and infrastructure CIs | Update CMDB service map; assess impact on dependent change requests |
| Container & Kubernetes discovery | Ephemeral workloads, unregistered containers, namespace changes | Reconcile with CMDB; update application-level CI groupings |
| Storage arrays (e.g. Pure Storage FlashArray) | Capacity changes, new LUN assignments, undocumented RAID configurations | Update storage CIs; escalate if unplanned allocation detected |
The real value comes from combining these perspectives into a single reconciliation view — one that shows not just individual CI discrepancies but the dependency relationships that make each discrepancy matter.
| See how Virima’s IT discovery validates your CMDB automatically Virima’s agentless discovery compares as-observed vs. as-expected continuously — surfacing unauthorized changes, configuration drift, and incomplete implementations before they cause incidents. Request a demo today! |
Closing the Loop: What to Do When Discovery Finds an Unplanned Change
Detection is only the first step. A complete CMDB change management workflow requires a defined response process for each discrepancy type:
Step 1: Classify the Discrepancy
Determine whether the discrepancy represents an unauthorized change (no corresponding change request), an implementation deviation (change request exists but was not executed as approved), or an orphaned record (CI decommissioned in practice but still active in the CMDB).
Step 2: Assess the Impact
Use the CMDB service map to identify which services, applications, and dependent CIs are affected by the discrepancy. This is where ViVID — Virima’s visual dependency mapping capability — provides immediate impact context without requiring a manual CMDB query.
Step 3: Resolve and Update
Depending on classification: open a retrospective change request for legitimate undocumented changes, escalate to the security or compliance team for unauthorized modifications, or trigger a remediation workflow to correct the as-deployed state. Update the CMDB record once the resolution is confirmed — closing the as-observed vs. as-expected gap.
| ‘Why does CMDB change management fail without discovery?’ CMDB change management without discovery can only record approved intent, not deployed reality. Last-minute workarounds, fixes applied outside the change advisory board, and incomplete rollbacks leave no trace in the change management system. IT discovery provides an independent environmental scan that reconciles approved plans against what is actually running — making it the only reliable mechanism for detecting and closing CMDB accuracy gaps over time. |
CMDB Change Management in a ServiceNow Environment
For organizations using ServiceNow CMDB, Virima’s discovery integrates directly to feed accurate CI data into change management workflows. The Virima-ServiceNow integration overlays ViVID service maps onto change requests, giving change advisory boards visual impact context at the point of approval — not after an incident.
ServiceNow’s unauthorized change detection capability flags CI modifications that occur without an associated approved change request. However, as noted in ServiceNow’s community documentation, this capability works most effectively when paired with continuous, multi-source discovery — exactly the gap Virima is built to close.
Frequently Asked Questions: CMDB Change Management
| Question | Answer |
| What is an unplanned change in CMDB context? | An unplanned change is any CI modification that bypassed the formal change request process — including last-minute workarounds, shadow IT deployments, and partial implementations that deviated from the approved scope. |
| How does IT discovery detect unauthorized changes? | Discovery scans the live environment, compares the as-observed state against the CMDB baseline, and flags any CI whose version, location, or relationships differ from the approved record. |
| What is the difference between planned and unplanned changes? | Planned changes go through the formal CAB review and approval workflow. Unplanned changes occur outside that process — either unauthorized, or undocumented deviations from an approved change request. |
| Can CMDB discovery catch changes that bypassed change management? | Yes. Discovery compares the live environment against approved CMDB baselines independently of the change management system. Any deviation is flagged regardless of whether a change request exists. |
| What causes CMDB data to become inaccurate over time? | CMDB drift accumulates from undocumented workarounds, incomplete rollouts, shadow IT activity, and decommissioned CIs that are never removed from the CMDB. Continuous discovery is the primary mechanism for preventing and detecting this drift. |
| How does Virima support CMDB change management? | Virima’s agentless discovery continuously scans the environment, compares as-observed vs. as-expected states, flags configuration drift, and integrates with ServiceNow to surface impact context at the point of change approval. |
Automate the Verification Layer Your Change Management Is Missing
Change management controls what is approved. IT discovery verifies what was actually deployed. Together, they form a closed loop that keeps your CMDB accurate — not just in the weeks after a cleanup project, but continuously, across every sprint and every maintenance window.
Without discovery running the as-observed comparison, unplanned changes accumulate silently. Configuration drift makes your CMDB unreliable at the exact moments — incident response, change impact analysis, compliance audits — when accuracy matters most.
The as-observed vs. as-expected framework is not a complex capability to implement. It requires a discovery tool that scans continuously, a CMDB that surfaces discrepancies clearly, and a defined response workflow for what to do when they are found. Virima delivers all three. Read the related guide: How Does a CMDB Help in Change Management? for implementation details on setting up automated change detection in your environment.Still relying on change management alone to keep your CMDB accurate? Virima’s automated discovery closes the gap. Request a Demo.
