CMDB Assessment

[Anish Reghu]

A clean CMDB assessment is not a report exercise. It’s a diagnostic + governance reset.

A technically accurate CMDB is not enough...
If it doesn’t influence operational decisions, it’s just inventory!

A strong CMDB assessment looks beyond data completeness.

Often heard - CMDB is inaccurate, so we don’t use it.? It's a maturity problem, not the tool.

Phase 1 — Define Scope & Intent (Before Touching Data)

• Clarify why the assessment is happening (audit issue? ITOM rollout? RFP? data trust problem?)

• Define scope (all CIs vs critical classes like Server, Application, Database)

• Identify stakeholders (Infra, App owners, Cloud, Security, Asset, Service Desk)

• Align on what “good CMDB” means for this organization

• Confirm current CMDB maturity stage (Ad hoc / Reactive / Managed / Optimized)

👉Without this, you’ll produce a technically correct but useless report.

Phase 2 — Data Health Analysis

Completeness

• % of mandatory fields populated (IP, Owner, Environment, Install status)

• Business Service relationships completeness

• Orphan CIs (no relationships)

• CIs without assignment group or owner

 

Correctness

• Duplicate CI analysis

• Naming standard compliance

• CI class misuse (Servers stored as Generic CIs)

• Lifecycle status inconsistencies

Integrity

• Relationship validity (Server → Application → Business Service)

• Broken dependency chains

• Invalid or stale relationships

 

Freshness

• Last discovered date

• Last updated timestamp

• Aging CIs (no update in 90/180 days)

• Decommissioned but still active CIs

Phase 3 — Process & Governance Review

• Is there a defined CMDB governance model?

• Who owns data per CI class?

• Is there a certification process?

• Are reconciliation rules properly defined?

• Are identification rules aligned with Discovery?

• Is there a CI onboarding workflow?

• How are deletions controlled?

• Is there a CI lifecycle policy?

Ask:

“Who is accountable for CI accuracy?”
If no one answers clearly — governance gap.

Phase 4 — Technical Configuration Review

• Review Identification & Reconciliation rules

• Review Data Source priorities

• Check Discovery schedules & coverage

• MID server placement and segmentation

• Event Management mapping to CIs

• Service Mapping coverage percentage

• ACLs for CI modification & deletion

• Scheduled jobs affecting CMDB

• Integration sources pushing CI data

Look for:

• Multiple sources overwriting each other

• Script-based CI updates bypassing IRE

• Manual CI creation without controls

Phase 5 — KPI & Metrics Review

• CI health score

• Duplicate rate %

• Relationship completeness %

• Orphan CI %

• Discovery coverage %

• Incident-to-CI linkage %

• Change success rate linked to CI

Then assess:
Is CMDB driving operational decisions — or just storing data?

Phase 6 — Risk Identification

Identify critical risks like:

• Mass deletion exposure

• Overlapping data sources

• No data certification cycle

• No lifecycle automation

• No impact mapping

• Shadow integrations modifying CIs

This is where you demonstrate architectural thinking.

Phase 7 — Maturity Scoring & Roadmap

Categorize findings:

Critical (Immediate Fix)

• Broken IRE

• Duplicate explosion

• No ownership

• Production risk

Medium-Term Improvements

• Relationship cleanup

• Governance formalization

• Lifecycle automation

Strategic Enhancements

• Service Mapping expansion

• Event correlation optimization

• CSDM alignment

Then provide:

• 30-day quick wins

• 90-day stabilization plan

• 6-month maturity roadmap

Deliverables You Should Produce

• Executive summary (business impact focused)

• Technical findings appendix

• CI health dashboard snapshot

• Governance gap report

• Prioritized remediation roadmap

Not just a spreadsheet dump!

And after performing the above steps, if you ask - If a P1 happens right now, can we confidently identify impacted business services within 5 minutes? The answer is a confident YES.

CMDB workshop should anchor around the following 4 pillars:

Process & Design (Are we structured?)

Focus on alignment and clarity.

• Is there a formally documented Configuration Management process?

• Is it consistently followed across regions/business units?

• Is the CMDB data model documented and aligned to CSDM?

• Are CI lifecycle stages (create, update, retire) clearly defined?

• Which processes depend on CMDB (Incident, Change, Asset, Vulnerability, Event)?

• Is there a defined audit and certification cycle?

If answers are vague → process immaturity.

---

Data & Automation (Is the data trustworthy?)

Focus on reliability and control.

• What CI classes are populated and why?

• What are the data sources per class?

• Are Identification & Reconciliation rules defined and reviewed?

• Are reconciliation priorities clear across multiple sources?

• How are duplicates detected and remediated?

• Are you monitoring CMDB Health & Data Foundations dashboards?

• How is manual data validated?

• Are relationships maintained and accurate?

• Is Discovery coverage sufficient?

If data comes from multiple uncontrolled sources → integrity risk.

---

Governance & Operations (Who owns it?)

Focus on accountability.

• Is there executive sponsorship?

• Who owns each CI class?

• Is there a governance committee?

• Are deletion/modification controls enforced?

• Are audits conducted periodically?

• Are KPIs tracked and reviewed?

• Are CMDB changes going through Change Management?

• Is there a continuous improvement roadmap?

If no clear data owner → governance failure.

---

Business Usage & Value (Does it matter?)

This is the most important section.

• Do Incident teams use CI relationships for impact analysis?

• Do Change teams use it for risk assessment?

• Does Problem Management leverage dependency data?

• Is Vulnerability Management integrated?

• What business decisions depend on CMDB?

• What measurable KPIs improved due to CMDB?

If CMDB is not influencing operational decisions → perceived failure.

Remember...

CMDB is not a project milestone.
It’s an operational capability.

All the best...

Regards,

Anish