Network Assessment: A Checklist and the Tools MSPs Use

A prospect hands over a one-page "network diagram" drawn in 2019, and the first scan turns up twice as many devices as it shows. Every MSP has seen that gap, and closing it before the contract is signed is the whole point of the exercise. This guide is a network assessment checklist you can run in a week, plus the tools that do each job, and how to turn the findings into a report the client will act on.

TL;DR

• A network assessment answers four questions: what is on the network, how exposed is it, how well does it perform, and what should change first. An audit checks against a standard; a penetration test tries to break in. Different jobs.
• Agree scope and rules of engagement in writing before the first scan. NIST SP 800-115 splits the work into planning, execution and post-execution, and that order holds for a 30-seat office as much as for an enterprise.
• Discovery is where assessments go wrong. Your RMM sees the devices with an agent; the DHCP server, the switches' MAC tables and a subnet scan see the rest.
• The report is the product. Findings need evidence, a severity, a fix, a cost and an owner, or they stay findings forever.
• Run one at every prospect, every onboarding, and at least once a year after that. The delta between two assessments is the story clients pay for.

What a Network Assessment Covers

A network assessment is a structured look at an existing network: the devices on it, how they're connected, how exposed they are, and how well traffic moves. The output is a report that says what was found, what it means, and what to do about it, in priority order.

It is not the same as a network audit or a penetration test, and clients mix the three up. An audit measures the network against a fixed standard or policy and produces pass/fail evidence for a regulator, an insurer or a board. A penetration test tries to exploit what it finds. An assessment sits in front of both: it builds the inventory and the risk picture that the other two need. If you're being asked for the audit version, the security audit procedures guide covers that framing.

The structure comes from NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment. It splits any assessment into three phases: planning, execution and post-execution. Planning gathers the assets in scope, the threats that matter and the rules for the work. Execution identifies and, where agreed, validates vulnerabilities. Post-execution analyzes root causes, writes mitigation recommendations and produces the final report. The guide was published in September 2008 and it still reads as the cleanest description of the job.

NIST also groups the techniques into three families. Review techniques are manual: documentation, logs, firewall rulesets, system configurations. Target identification and analysis techniques are the scans: network discovery, port and service identification, vulnerability scanning, wireless scanning. Target vulnerability validation techniques are the ones that prove a hole is exploitable: password cracking and penetration testing. A network assessment lives in the first two families. The third is a separate engagement with its own paperwork.

Scope and Rules Before You Plug Anything In

The planning phase is short and skipping it is expensive. Write down the objective in one sentence. "Find out what we'd be taking on" is a pre-sales objective. "Prove the guest Wi-Fi is isolated from finance" is a different assessment with a different tool list.

Then fix the scope: which sites, which subnets, which cloud tenants, and whether remote workers' home networks are in or out. Name the exclusions too. A production PLC that falls over when it gets an unexpected packet is a known category of thing, and the client knows where theirs are. Ask.

NIST SP 800-115 ships a rules of engagement template in its Appendix B, and it's worth using even when the client is a 20-person accounting firm. The rules cover who authorised the work, what techniques are allowed, when scans may run, who to call if something breaks, and how findings will be handled. Active scanning from an unknown laptop looks identical to an attacker's first hour, so the client's existing IT contact needs to know the date, the source IP and the scan windows in advance.

Access is the other planning item. You need read access to the firewall, the switches, the DHCP server, the identity provider and whatever monitoring exists. Read-only credentials created for the assessment and removed after it are the clean way to do this. If the client can't produce them, that's your first finding.

The pre-sales version of this deserves its own note, since the question of what to charge for it comes up in every MSP owner group. A free assessment is a sales cost that buys you the inventory before you price the contract, which is the only way to price it. A paid assessment is a deliverable the prospect keeps whether or not they sign. Both work. What doesn't work is a "free assessment" that is a ten-minute scan and a slide deck, because the prospect will get a real one from the next MSP and compare.

Step 1: Discover Everything on the Network

Discovery is the step that decides whether the rest of the assessment is worth anything. Every later check runs against the list you build here, so anything you miss now stays missed.

NIST separates passive discovery from active discovery. Passive discovery watches traffic with a sniffer and records which hosts talk, on which ports, to whom. It sends nothing and misses hosts that stay quiet during the capture window. Active discovery sends packets, ICMP pings and probes to common ports, and reads the replies to identify hosts, operating systems and open services. It's faster and more complete, and it's visible to any firewall or intrusion detection system on the way. Use both: a subnet scan for coverage, a capture on the core switch for the relationships between hosts.

The mistake to avoid is treating your RMM's device list as the inventory. The RMM sees devices that have its agent, which means the Windows and Mac endpoints the last provider managed. It doesn't see the printer with the default admin password, the four IP cameras on the same VLAN as finance, the NAS someone bought for a project in 2022, or the switch in the ceiling. Those come from three other sources: the DHCP server's lease table, the ARP and MAC address tables on the switches, and a port scan of every subnet the routing table knows about. Compare the four lists. The devices that appear in only one of them are the interesting ones.

Wireless needs its own pass. Wireless scanning, in NIST's terms, means walking the site with a scanner and recording every SSID, its security mode, and which access points belong to the client. A rogue AP plugged into a wall port for convenience is a common find, and so is a guest network that turns out to share a subnet with the office. The WPA2 explainer covers which security modes are fine and which should be a finding.

Draw what you found. A current topology with VLANs, uplinks, the internet edge and any site-to-site links is the diagram the report opens with, and the client has almost never seen one for their own network. Tools that build it automatically are covered in the network mapping software guide; a whiteboard photo works for a single site.

Step 2: Inventory and Lifecycle

Discovery gives you a list of addresses. Inventory turns it into a list of assets: make, model, role, owner, firmware or OS version, support status, and whether anyone is responsible for it. CIS Control 1 in the CIS Critical Security Controls v8.1 puts this first for a reason: the control's stated purpose is to actively manage, meaning inventory, track and correct, all enterprise assets, so you know what needs protecting and can spot what shouldn't be there.

The lifecycle columns matter more than they look. A firewall on firmware from three years ago, a switch past its end-of-support date, and a server whose OS stops getting security updates next year are three findings with three different costs and dates. Put the date next to each one. A client who won't fund a hardware refresh will often fund it when the report says "support ends 12 January 2027" next to a device that carries their file shares. The asset lifecycle guide has the refresh math.

Record the unknowns as unknowns. If nobody in the building can say what a device is, the finding is "unidentified device on the finance VLAN", not a guess. That line alone gets a response in the review meeting.

Step 3: Security Checks

The security half of the assessment is two views of the same network: from the outside looking in, and from the inside looking around.

Outside-in starts with what the internet can see. Every public IP the client owns gets a port scan and a check for exposed services: RDP, SMB, database ports, web admin panels, VPN endpoints on old firmware. CISA runs a free Cyber Hygiene vulnerability scanning service for US organizations that covers exactly this, internet-facing systems checked for weak configurations and known vulnerabilities, requested by emailing vulnerability@cisa.dhs.gov. It's a good baseline to put next to your own scan, and it costs the client nothing.

Inside-out is the vulnerability scan across the inventory you built in step 1. NIST describes vulnerability scanning as the technique that identifies outdated software versions, missing patches and misconfigurations by matching what it finds against a database of known vulnerabilities, and it notes the high false positive rate in the same breath. Read the results before you paste them into a report. A hundred "critical" findings that are one unpatched library reads as one finding. The vulnerability management guide covers how to rank what the scanner returns.

The reason this section carries weight with clients is in Verizon's 2025 Data Breach Investigations Report, published 23 April 2025: exploitation of vulnerabilities was the initial access vector in 20% of breaches, up 34% on the previous year, and ransomware was present in 88% of breaches at small and medium businesses. An assessment that finds the exposed VPN before the attacker does is the cheapest security spend the client will make that year.

The manual review items are where an experienced tech earns the fee. The firewall ruleset: any rule with "any" as the source and a port that shouldn't be public is a finding, and so is a rule with no comment that nobody can explain. Segmentation: can a guest Wi-Fi client reach the finance file server? Try it. Remote access: which accounts can reach the network from outside, and do all of them have MFA? Identity: how many accounts have domain admin, how many are shared, and how many belong to people who left? Logging: are the firewall, the domain controllers and the identity provider sending logs anywhere that keeps them for more than a week? The log management guide has the minimum set. Backups: is there one, has anyone restored from it, and can the backup server be reached from a workstation with a stolen password?

Every one of those is a yes-or-no question with evidence. That's the format the report needs.

Step 4: Performance and Capacity

Security findings get the client's attention. Performance findings are the ones they already feel, which is why they belong in the same report.

Start with utilization on the links that matter: the internet circuit, the uplinks between switches, and any site-to-site VPN. A week of interface counters from the firewall and the core switch will show whether the circuit is saturated at 9am or just slow because of a bad Wi-Fi channel plan. The bandwidth usage guide walks through reading those counters when the graph looks fine but users disagree.

Then measure the path quality that voice and video depend on: latency, jitter and packet loss. Microsoft publishes the thresholds it designs Teams around, and they're a fair benchmark for any real-time traffic. Microsoft also publishes a free Teams Network Assessment Tool (version 2.0, July 2026) that streams packets to Teams relays and reports loss, jitter and round-trip time from the client's own network, which is a quick way to get a number the client will recognise.

Wi-Fi gets a survey, not a guess. Channel overlap, access points on maximum power fighting each other, and coverage holes in the corner office all show up on a heat map and nowhere else. Note the client density per AP and whether the guest network shares airtime with the office network.

Finish with the edge. Is there a second internet circuit, and does failover work? When was the last time anyone tested it? A single circuit with no failover is a finding with a cost attached, and the infrastructure monitoring guide covers what to watch once the assessment turns into a contract.

Step 5: Documentation and the Report

Post-execution, in NIST's phasing, is analysis and reporting. In practice it's the part MSPs rush, and it's the only part the client reads.

The report has five sections, and the order matters. An executive summary of one page: what was assessed, the three findings that matter most, and what they cost to fix. The inventory and topology diagram. Findings, grouped by severity, each with evidence. A roadmap with costs and dates. Then the appendix of raw scan output that nobody reads but everyone wants to exist.

Each finding is a card with seven fields: what was found, the evidence (a screenshot, a scan line, a config excerpt), the risk in plain words, the fix, the cost, the owner and the target date. "Firewall firmware out of date" is a note. "Edge firewall on firmware 6.4.2 from March 2023, three published vulnerabilities in the interim, one with a public exploit; upgrade to the current release in the next maintenance window, two hours of labour, owner MSP, by 15 October" is a finding.

Severity needs a scale the client understands. Four levels are enough: fix now, fix this quarter, fix at the next refresh, and note for the record. Tie the top level to something concrete, such as anything exploitable from the internet, any account with no MFA that can reach the network from outside, and any backup that has never been restored.

Keep the working documents too. The inventory, the diagram and the credentials list become the client's documentation on day one of the contract, and the documentation tools guide covers where they should live.

The Network Assessment Checklist

This is the working list. Run it top to bottom, mark each line with the evidence you captured, and the report writes itself.

Tools MSPs Use

No single tool covers the checklist. The ones below are grouped by the job they do, and the pairing that shows up again and again in MSP threads is a paid discovery and monitoring platform for the client-facing view plus free scanners for the depth.

For discovery and mapping: Nmap for subnet scans, OS fingerprinting and port and service identification, which is the NIST technique list in one binary. Wireshark for the passive side, run from a mirror port on the core switch. Auvik, Domotz and the network modules inside RMM platforms for continuous discovery, topology maps and the device inventory after the assessment turns into a contract. Netdisco and Open-AudIT if the client prefers open source.

For vulnerability scanning: Greenbone's OpenVAS is the open-source scanner; Nessus and Qualys are the commercial ones with the larger plugin libraries. For a first-pass external view, CISA's Cyber Hygiene service is free for eligible US organizations. Kaseya's Network Detective and RapidFire Tools sit in a category of their own: assessment kits built for the MSP pre-sales use case, which package the scan, the findings and a branded report.

For performance: iperf3 between two hosts for raw throughput on a link; Microsoft's Teams Network Assessment Tool for real-time traffic quality against Microsoft's own thresholds; Ekahau or NetSpot for the Wi-Fi survey; the counters on the firewall and switches for utilization.

For inventory and documentation: Lansweeper for an agentless inventory that merges scan data with what the endpoints report; the client-documentation platforms for the hand-off. If the client's endpoints are already under an OpenFrame agent, a script run across them with the output collected gives you the per-device view in one pass.

Name the tools in the report, with the version and the date of the scan. The next assessment compares against this one, and the comparison only holds if the method held.

From Assessment to Contract

An MSP runs assessments at three moments, and the report reads differently at each.

Pre-sales, the assessment is how you price the contract. Device counts, the number of sites, the state of the edge and the age of the servers all move the monthly number, and a proposal written from the prospect's own diagram will be wrong. It's also the first thing the prospect sees you produce, and the questions to ask an MSP before signing include whether the provider assesses before quoting.

Onboarding, the assessment is the baseline. The onboarding checklist puts the network and security assessment in days three to seven, after credentials are in hand and before any changes are made. Everything you change after that is measured against it.

After that, run it annually and after any change big enough to move the diagram: a new site, a merger, a cloud migration. Cyber insurance applications ask the same questions every renewal, and an assessment from the last quarter is how you answer the insurance questionnaire without guessing. Put the top three findings from the last report and their status on the first slide of every quarterly review. The client sees progress, and you see the items that keep slipping.

The Short Version

Agree scope and rules in writing, then discover from four sources and reconcile them. Turn addresses into an inventory with dates. Check security from outside and inside, and write every finding with evidence, a fix, a cost and an owner. Measure the links the client feels. Deliver a report with a one-page summary and a priced roadmap, keep the working documents as day-one documentation, and run it again in a year. The delta is the value.

Next: the network mapping software guide for the discovery tooling, and the security audit procedures guide when a client needs the audit version against a standard.

FAQ

What is the difference between a network assessment and a network audit?

An assessment builds the picture: inventory, exposure, performance and a prioritised list of what to change. An audit measures the network against a defined standard or policy and produces pass/fail evidence for a regulator, insurer or board. Assessments usually come first, and audits reuse their inventory.

How long does a network assessment take?

For a single site with under a hundred devices, plan a day on site for discovery and the wireless survey, a week of passive counters for performance, and two days for the scan review and the report. Multi-site and heavily segmented networks scale roughly with the number of subnets, since each one needs its own discovery pass.

Should an MSP charge for a network assessment?

Both models work. A free assessment is a sales cost that gives you the inventory you need to price a contract accurately. A paid assessment is a deliverable the prospect keeps whether or not they sign. The one that fails is a free assessment that is a ten-minute scan and a template report, because the prospect will compare it with a thorough one from the next MSP.

What tools do you need for a network assessment?

A subnet scanner such as Nmap, a packet capture tool such as Wireshark, a vulnerability scanner such as OpenVAS or Nessus, a Wi-Fi survey tool, and the counters on the firewall and switches. Continuous discovery platforms such as Auvik, Domotz or an RMM's network module take over once the assessment becomes a contract. Kaseya's Network Detective and similar kits package the pre-sales version with a branded report.

What should a network assessment report include?

A one-page executive summary, the inventory and topology diagram, findings grouped by severity with evidence for each, a roadmap with costs and dates, and an appendix of raw scan output. Each finding carries what was found, the evidence, the risk, the fix, the cost, the owner and a target date.

How often should a network be assessed?

At every prospect, at onboarding, and at least once a year after that. Re-run it after any change that moves the diagram, such as a new site, an acquisition or a cloud migration, and before a cyber insurance renewal so the questionnaire is answered from evidence.