Discovery: Finding What Is Actually There

The machine count a client gives you is wrong, usually low. Establishing the real number before the contract starts is better than discovering it afterwards.

The recommendations in “Discovery: Finding What Is Actually There” become sustainable only when the recurring work has visible owners and enough capacity. A team assessing this time-management reference can use time and project records to see where operational effort accumulates, without treating activity data as a substitute for technical evidence or direct discussion with technicians.

For an independent operational benchmark, compare the local practice with NIST Cybersecurity Framework; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

Why the number is wrong

Machines bought by departments without telling anybody.

Laptops issued to people who have left and never returned.

Equipment in branch offices nobody counted.

Virtual machines spun up and forgotten.

And devices that are not computers: network gear, cameras, controllers, printers, anything with an address.

Where to look

Active directory or whatever identity system exists, which lists what has authenticated.

DHCP leases, which show what has been on the network recently.

Network scanning, with the client's written permission.

Switch port and wireless controller data, which shows what is physically connected.

Their asset register and their invoices, which rarely agree with each other or with reality.

The comparison

Put the sources side by side and look at what appears in one and not the others.

Machines in the directory but never on the network: probably gone, and still holding credentials.

On the network but not in the directory: unmanaged, and the interesting category.

This comparison is the entire exercise and it takes an afternoon.

What you will find

More machines than stated, by a meaningful margin.

Equipment nobody can account for.

Operating systems past support.

Servers running something critical that nobody documented.

And at least one thing the client is surprised by, which is a good moment for the scope conversation.

Turning it into the contract

The real count determines the price, if you bill per device.

The out-of-scope list comes from here.

And anything unsupportable — unsupported operating systems, equipment you will not touch — gets named before you are accountable for it.

Permission

Network scanning without written permission is not acceptable, however routine it feels.

Get it in the engagement, specifically.

This matters more with a prospect than with a client, and it is the kind of thing that ends a relationship before it starts.

Repeating it

Annually, and after any client acquisition or office move.

Estates drift, and the drift is invisible from the console because the console only shows what has an agent.

That blind spot is permanent and the only remedy is looking from outside it.

What to check

Does your onboarding include discovery, or do you deploy to a provided list?

How does your agent count compare with the client's stated count?

Do you have written permission to scan?

And when did you last look for machines without agents?

The point

The machine count a client gives you is wrong, usually low.

Establishing the real number before the contract is better than discovering it after.

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.