CMDB Remediation: Where to Start When Everything Is Broken

The most common mistake in CMDB remediation is trying to fix everything at once. The second most common mistake is fixing the data before fixing the governance.

Both errors lead to the same outcome: a remediation project that improves the CMDB for six months and then reverts to its previous state, having consumed significant budget and goodwill in the process.

Here is the approach that actually works.

Start with governance, not data

Before touching a single CI record, answer three questions:

Who owns the CMDB? Not "which team is responsible for it," but who is the named individual with authority to make decisions about the data model, CI lifecycle rules, and quality standards? If the answer is ambiguous, remediation will be undermined at every step.

What are the quality success criteria? "Better" is not a success criterion. What CI classes need to be accurate? What accuracy level is acceptable? What does the ongoing measurement look like? Without defined criteria, remediation is a project with no completion condition.

How will ongoing quality be maintained? If the answer is "we'll sort that out after the remediation," you are planning to repeat this engagement in two years. The maintenance model needs to be designed as part of the remediation, not deferred.

Identify the five CI classes that actually matter

Every organisation has a CMDB with dozens of CI classes. Most of them are not business-critical. The remediation effort should be concentrated on the classes that downstream services depend on.

In most mid-market organisations, the business-critical CI classes are:

• Business applications (the services the business actually uses)
• Infrastructure that supports those applications (servers, databases, network)
• The relationships between them (the CMDB relationships that make impact analysis work)

Everything else, such as physical locations, printers, and mobile devices, can be remediated in a second phase if it matters enough to prioritise.

Discovery versus manual reconciliation

Discovery tools are good at finding things. They are not good at deciding what to do with what they find when it conflicts with existing records. Manual reconciliation, meaning a human reviewing discovery findings against existing CI data, is the step that organisations most frequently skip, and the one that determines whether the remediation actually results in accurate data.

The architecture of the reconciliation process matters as much as the data quality rules. Who reviews reconciliation exceptions? On what cadence? What happens to discovery-found devices that have no matching CI? These decisions need to be made before discovery runs, not after.

Quick wins that restore confidence

Remediation projects lose momentum when early progress is not visible. Identify two or three quick wins that can be demonstrated in the first four weeks:

• A specific CI class that is small enough to remediate completely and important enough to matter
• A quality metric that is currently red and can be moved to amber with targeted effort
• A downstream use case, such as incident routing or change impact analysis, that visibly improves when the underlying data is corrected

Demonstrating real improvement early maintains the organisational will to continue.

The governance model that makes it stick

The remediation project ends. The CMDB governance model does not. What you need by the end of the engagement is:

CI lifecycle rules: documented criteria for creation, modification, and decommission of each critical CI class, with named owners for each rule.

Quality thresholds and alerts: automated monitoring that flags when quality drops below defined thresholds, going to a named person who has the authority to act on it.

A reconciliation cadence: scheduled review of discovery output against CMDB records, with clear exception handling.

A change control process for the data model: changes to CI class structure, relationship types, and quality rules require the same governance as changes to anything else in the platform.

If you are at the beginning of a CMDB remediation and want an independent assessment of your current state and a recommended approach, we can help.