When a company implements an automated infrastructure discovery tool, there's a tempting assumption that the asset management problem is now solved: discovery will find everything on the network by itself, populate the CMDB by itself, and the issue of stale data will simply disappear. In practice, it works differently.

Auto-discovery is excellent at detecting what's already connected to the infrastructure. But it knows nothing about what happened to an asset before that point — who ordered it, on what grounds it was purchased, who is responsible for it, or whether it should even be in production at all. Without a clear onboarding process, a discovery tool turns into something that merely highlights the problem rather than solving it — the company simply finds out faster that "orphaned" servers and forgotten test environments have accumulated in its infrastructure.

That's why, when implementing auto-discovery, we never start by configuring scans — we start with a procedure: who initiates the addition of a configuration item (CI), who purchases it, who accepts and configures it, and who is responsible for making sure the CMDB record appears on time and with the correct attributes. Below we share a procedure we developed as part of one such project — it has been tested on a real-world implementation and is ready to use as a template.

Why a Formal Process Is Needed When You Already Have a Discovery Tool

A common mistake is treating the CMDB and a discovery tool as interchangeable. In reality, they address different problems.

The CMDB is a database of assets with attributes, relationships, and areas of ownership, used in operational and management processes: incident management, change planning, auditing, budgeting, security control. For this data to be trustworthy, every record must go through a controlled process — from the initial request all the way to confirmation that the asset is actually working as declared.

An auto-discovery tool — in our case, Device42 — covers a different part of the task: it finds assets in the infrastructure and provides factual data about them — configuration, network connections, and dependencies between services. Discovery delivers its full value precisely when there's something to reconcile its data against — that is, when the CMDB already contains a preliminary record created through a regulated process. At that point, discovery shifts from being a source of chaos into a validation tool: "we expected to see exactly this in the infrastructure, and discovery confirms that it's there."

Download the template — the procedure itself. We're sharing it as a working template that can be adapted to the structure of any given company.

Where Device42 Fits into This Process

The procedure described above is an organizational framework: who is responsible for an asset, and at what point. But without a tool that actually sees the infrastructure, this framework has no grounding in reality — the data in the CMDB remains whatever was entered manually, unverified.

Device42 covers exactly this gap — step 5.5, "Deployment." Once a CI is physically connected to the infrastructure, Device42 detects it automatically: collecting its attributes, network connections, and dependencies on other services. This discovered state is then matched against the record that was already created in the CMDB at an earlier stage of the process (step 5.4, "Acceptance and Warehousing"

It's precisely this matching that creates the value of combining "process + discovery":

• If the discovered asset matches the expected record, this confirms the process worked correctly, and the CMDB can be marked as "in production."
• If discovery finds an asset for which no expected record was created, this is a signal that the process was broken or bypassed somewhere — and it's worth investigating, not silently adding to the database.
• If a CMDB record exists but discovery doesn't find the asset, this is a reason to check whether the asset has been decommissioned, whether its status has changed, or whether it has been physically lost.

Without a defined process, discovery just accumulates raw data that gradually drifts away from actual areas of responsibility. Without discovery, the process remains a declaration with no one and nothing to verify it against. In practice, only the combination works: a formalized onboarding process plus a tool that can automatically and regularly confirm that the infrastructure matches what's on record.

If you're implementing auto-discovery and want to build this kind of controlled process around it, get in touch — we'll discuss what it would look like in your infrastructure.

‍