You have two hours, a network you have never seen, and somebody who wants to know what they have. Here is a process that produces something useful in that time and does not quietly invent the parts you could not verify.
Before you plug anything in
Establish in writing that you are authorised to scan. An email saying “yes, please go ahead” is enough, and it is the difference between routine professional work and a criminal offence in most jurisdictions. Do it even when it feels absurd, especially with a new client.
Then ask three questions that save an hour each:
- Are there multiple networks or VLANs? A scan of one subnet documents one subnet.
- Is there anything that must not be touched — a machine control, a medical device, a till system?
- Who do I call if something goes wrong while I am here?
Start with the physical layer
Photograph the rack, the patch panel and every switch before you touch anything. Photographs cost seconds and answer questions you do not yet know you have, including “was that cable already unplugged when I arrived?”
Write down what you can read off the equipment: manufacturer, model, serial, and how many ports are actually populated. This is the part a network scan cannot give you, which is exactly why it is worth doing while you are standing there.
Then scan, twice
Run one scan when you arrive. Run another before you leave. Comparing them tells you which devices are transient — laptops, phones, a contractor’s tablet — and which are genuinely part of the infrastructure. A single scan cannot distinguish those, and a document that lists somebody’s phone as network infrastructure is a document that gets ignored.
Scan the whole subnet, not just the range you think is in use. Static addresses outside the DHCP pool are where the interesting things live: the cameras, the controllers, the thing somebody configured in 2019 and never mentioned.
Record uncertainty as uncertainty
This is the discipline that separates a useful document from a liability. Some devices will not identify themselves, and no tool can change that. When that happens, write down what you actually know — this address answers, it has these ports open, it has this MAC prefix — and mark the identification as unresolved.
A list of six unresolved addresses is a genuine deliverable — it is a work list. A list of six confidently wrong identifications is worse than nothing.
Map what you can to switch ports
If there is a managed switch and you can get a read-only SNMP credential, map devices to ports. It converts “there is a camera somewhere” into “the camera is on port 14 of the switch in the back cupboard”, which is the difference between a document and a map.
Watch for ports carrying many hardware addresses. Those are uplinks to other switches, and treating one as a device’s port is the classic error here. ScanWRX labels them rather than guessing.
What to hand over
- A one-page summary: how many devices, what kinds, what needs attention.
- The full inventory, with confidence marked on each identification.
- The unresolved list, framed as work rather than as failure.
- Photographs of the physical layer.
- What you did not cover, and why — other VLANs, the guest network, whatever.
That last one matters more than it looks. A document that does not say what it excludes gets read as complete, and the first person to discover otherwise will assume you missed it rather than scoped it out.
Coming back
Keep the scan. On your next visit, a comparison against it answers “what changed since last time” in seconds, and “nothing has changed since March” is a sentence clients pay for. It is only worth anything if the tool that produced it would genuinely have noticed if something had.