ServiceNow CMDB Requirements Workshop Questions

This page is a set of questions for a CMDB requirements workshop, covering which configuration items to track, where their data comes from, how accurate it must be, and what reports it has to support. The answers decide how much the CMDB can be trusted by the teams who depend on it.

What the CMDB Tells You and How It Must Change

The CMDB is the single source of truth for infrastructure and application configuration. Every other module in ServiceNow—incident management, change management, asset management, event management—depends on the CMDB to answer questions like: what server is this database running on? Who owns this application? What dependencies does this service have? The decisions made in CMDB requirements workshops determine what configurations you track, how complete and accurate that data is, and whether downstream teams actually trust the CMDB or work around it.

Unlike transactional modules (incident, request), the CMDB is more about governance than workflow. The workshop questions focus on data structure, data sources, automation, and accuracy thresholds. The goal is to build a CMDB that is comprehensive enough to be useful but not so comprehensive that you cannot keep it accurate.

Scope: Which Configuration Items to Track

The first critical set of questions focuses on scope: what types of CIs will you track? Will you track servers, databases, and applications? Will you track network devices, storage arrays, and UPS devices? Will you track virtual machine templates, Docker images, and Kubernetes clusters? Will you track business services, teams, and dependencies between applications? The broader your scope, the more complex the CMDB model and the higher the cost of data collection and maintenance.

A common approach is to start with a minimal model: physical servers, databases, major applications, and the relationships between them. This gives you enough data to manage incidents and changes without drowning in configuration detail. Some organisations track every virtual machine instance, every container, and every configuration file change. This level of detail is useful for troubleshooting but creates a data maintenance burden that quickly becomes unsustainable if you are not automating data collection.

Another scope question concerns business context: will the CMDB track business services and their dependencies on infrastructure, or only technical configurations? A business-aware CMDB helps executives understand risk and impact. When a server goes down, executives can see which customer-facing services are affected. A technical-only CMDB tracks infrastructure but does not answer business questions. The choice depends on whether you need to communicate infrastructure risk to business leaders and whether you have the discipline to maintain business service definitions.

The warning sign is scope creep. Teams often start by tracking servers and databases, then add applications, network devices, and change information, until the CMDB has ten thousand CI types and no one can remember the purpose of each one. If your scope grows during implementation, revisit it explicitly. Aim for a 80/20 point: track the a small subset of CIs that answer the majority of operational questions. Leave the rest for phase two.

Data Sources and Discovery Strategy

The next set of questions addresses how the CMDB will be populated: manual entry, discovery tools, or a combination? Manual entry is reliable but labour-intensive. Discovery tools (like ServiceNow’s own Discovery tool, or third-party tools like Tanium or Splunk) can automatically inventory infrastructure. The trade-off is complexity: discovery tools require configuration, tuning, and ongoing maintenance, but they scale far beyond manual processes.

Key questions include: will you use ServiceNow Discovery, or will you integrate with other discovery tools? How often will discovery run? Daily, weekly, or only on demand? What happens when discovery finds a configuration that does not match the CMDB? Do you automatically update the CMDB, flag it for review, or ignore it? The discovery strategy determines how current the CMDB is and how much manual reconciliation is required.

Another source of CMDB data is integrations with external systems: asset management tools, infrastructure automation platforms (Terraform, Ansible), cloud provider APIs (AWS, Azure). These integrations can feed CIs and relationships directly into the CMDB, keeping it in sync with your actual infrastructure. The cost is integration complexity. Each system requires configuration, error handling, and monitoring to ensure data flows correctly.

A common warning sign is discovering that your manual CMDB is outdated. If the CMDB has not been touched in six months and you have no automated data collection, it is almost certainly wrong. When was that server decommissioned? Was that database upgraded? Outdated CIs cause false incident impact assessments and incorrect change management decisions. If you cannot commit to keeping the CMDB current through discovery or integration, focus on a smaller, more manageable scope that you can maintain accurately.

Accuracy, Relationships, and Dependency Mapping

A CMDB with many CI types but loose relationship data is often less useful than a CMDB with fewer CI types but tight, well-verified relationships. Questions about accuracy focus on: what is the tolerance for incorrect or missing CIs? How many relationships must you map and keep current? What level of dependency detail do you need?

For example, tracking that server A runs database B is useful. Tracking that database B has 47 tables, each with 12 columns, indexed seven times, is detail that is rarely needed and expensive to maintain. Dependency mapping decisions should be driven by specific use cases. If change management must understand what breaks when a service changes, you need service dependency maps. If incident management just needs to know what team to call, you may only need ownership relationships.

A critical question is who owns accuracy. Is there a CMDB data steward role? Does each team own their configurations and update them when things change? Or is the CMDB maintained once per year as a project? Teams that designate a steward and embed CMDB maintenance into operational processes keep their CMDB reasonably accurate. CMDBs maintained only periodically quickly become unreliable.

The warning sign is attempting to map all dependencies at once. A complete dependency map often requires weeks of documentation, discovery, and analysis. Start with critical service dependencies. Map the rest iteratively as new incidents reveal gaps. Similarly, do not try to achieve complete accuracy. Most organisations accept high accuracy for their CMDB. Higher accuracy requires disproportionate effort and often provides diminishing returns.

Change Management Integration and Automated Workflows

Questions about CMDB-integrated change management focus on whether the CMDB should drive change workflows and notifications. Will the CMDB automatically calculate change risk based on the number of dependent services? Will the CMDB notify affected teams when a CI they depend on is about to change? Will the CMDB feed configuration data into approval workflows?

These integrations are powerful but add complexity. A CMDB-aware change process can reduce missed impact assessments and coordinate changes across dependent services. However, this requires the CMDB to be accurate enough to trust. If the CMDB frequently has wrong relationships or missing CIs, automated workflows will make decisions on bad data. Before automating CMDB-driven workflows, confirm that your CMDB accuracy is acceptable for that use case.

Another integration question: will the CMDB track configuration changes at the file level or only at the service level? Some organisations use the CMDB to store configuration files and version their changes. Others track only high-level configurations and store files in separate repositories. File-level tracking gives you a complete audit trail but requires careful integration with your deployment automation and source control systems.

The warning sign is automating CMDB workflows before the CMDB is accurate. A common failure pattern is enabling automatic impact assessment in change management, which then starts rejecting valid changes because the CMDB shows incorrect dependencies. When this happens, teams bypass the CMDB and change management loses credibility. Get the CMDB stable and trusted before automating critical workflows.

Reporting and Compliance

The final set of questions addresses what reports and queries the CMDB must support. Will you report on infrastructure inventory and cost? Will you report on configuration compliance and deviations? Will you track configuration change history for audit trails? The answers determine which attributes and relationships you must track and how carefully you must maintain history.

For compliance-heavy organisations, the CMDB often becomes a compliance evidence source. Auditors ask: can you show me all servers running unpatched operating systems? Can you show me all databases that lack redundancy? These questions require the CMDB to track security patches, backup status, and high-availability configurations. The CMDB that just tracks server names and IPs will not answer compliance questions.

A practical decision is whether you will track configuration history or just current state. Current-state tracking is simpler. History tracking allows you to answer questions like: when was this server added? What changed on this database over the last month? History tracking is valuable for troubleshooting and compliance but requires more storage and query complexity.

The warning sign is adding reporting requirements late in implementation. If executives later ask for a report on infrastructure underutilisation, but the CMDB only tracked server names and application ownership, you cannot answer it. Clarify reporting requirements upfront, even if you do not implement all reports immediately.