A network assessment is the technical half of discovery. The discovery call tells you why a prospect is looking for a new provider and what's driving the decision. The network assessment tells you what's actually running in their environment — the hardware, the topology, the security gaps, the licensing you'll inherit. Without both, a proposal is either persuasive but wrong on scope, or accurate but generic. This is the template for the technical side: what to document, how to structure the findings, and how those findings become a scope of work instead of a pile of screenshots.
Why a Template Matters More Than a Tool
Most network assessment advice focuses on which scanning tool to run — and tooling matters, since manual discovery misses devices and misreads configurations. But the tool only produces raw data. What turns raw data into something a client (or your own estimator) can use is a consistent template: the same categories, in the same order, every time, so nothing gets missed on a rushed Friday-afternoon site visit and nothing has to be re-explained to whoever writes the proposal.
A template also protects you contractually. If a scope dispute comes up three months into an engagement — "we thought you were monitoring the warehouse switch too" — a signed, dated assessment that explicitly lists what was and wasn't documented is the evidence that settles it.
The template below is built around five categories that map to how a managed services proposal is actually structured: infrastructure defines what you're pricing per device or per user, topology defines what you're supporting and where the single points of failure sit, security and backup define your risk exposure as the incoming provider, and compliance defines the language your proposal needs to use for this specific client's industry. Treat it as a checklist to run through on every assessment, not a form to fill in once and forget — environments change, and an assessment from eighteen months ago is a starting point for the next one, not a substitute for it.
The Five Categories to Document
1. Infrastructure & Hardware Inventory
This is the foundation everything else builds on — you can't price per-device or per-endpoint pricing without an accurate count, and you can't scope patching or lifecycle replacement without knowing what's end-of-life.
- Workstation and laptop count, by make/model/age, OS version
- Server inventory: physical vs. virtual, role (domain controller, file server, application server, hypervisor host), OS and patch level
- Network hardware: firewalls, switches, wireless access points, make/model/firmware version
- Printers, scanners, and other shared peripherals
- Line-of-business applications and the hardware/OS dependencies they require
- Warranty status and manufacturer support end-of-life dates for critical hardware
2. Network Topology & Connectivity
This category documents how everything connects — the map you'd need to actually support the environment, not just a device list.
- Physical topology: how locations, closets, and racks connect
- ISP provider(s), circuit type, and contracted bandwidth per location
- Redundancy: is there a secondary ISP or failover path, or is a single circuit a single point of failure?
- VLAN structure and segmentation (or lack of it)
- VPN configuration for remote sites and remote workers
- IP addressing scheme — static assignments, DHCP scope size and utilization
3. Security Posture
The category that determines both your risk exposure as the incoming provider and the compliance language your proposal needs.
- Endpoint protection: what's deployed, is it centrally managed, is it current
- Patch management: is there a defined cadence, or is patching ad hoc
- Firewall rules: any obviously outdated or overly permissive rules
- Multi-factor authentication: where is it enforced, where is it missing (email, VPN, admin accounts are the three that matter most)
- Password policy and privileged account hygiene — shared admin logins are a common finding
- Email security: SPF/DKIM/DMARC configuration, phishing filtering in place
- Prior incidents: has the client disclosed any breach, ransomware event, or significant phishing loss
4. Backup & Disaster Recovery
Clients frequently assume backups exist and work. Confirming or disproving that assumption during the assessment — not after an incident — is one of the highest-value things you document.
- What's backed up: servers, workstations, cloud data (Microsoft 365/Google Workspace are commonly missed)
- Backup frequency and retention period
- Backup location: on-site only, off-site/cloud, or both (3-2-1 is the standard reference point: three copies, two media types, one off-site)
- Last successful test restore — and whether one has ever actually been performed
- Recovery Time Objective and Recovery Point Objective the client expects, versus what the current setup can actually deliver
5. Compliance & Licensing
This category is where a generic assessment becomes an MSP-specific one — it's the input for the compliance section of the proposal.
- Applicable regulatory frameworks: HIPAA, PCI DSS, SOC 2, CMMC, state-specific requirements
- Cyber liability insurance: is there a policy, and does the current environment actually meet its stated requirements
- Software licensing: are OS, Office/productivity, and line-of-business application licenses current and properly counted (under-licensing is a common and expensive finding)
- Data retention and privacy obligations tied to the client's industry
Running the Assessment
Before the visit: confirm with the client who can grant access to network equipment, whether you're assessing one site or multiple, and whether remote sites/employees are in scope. Send a short pre-assessment questionnaire covering employee count, location count, and known pain points — it saves time on-site and gives you a starting point to verify against.
During the visit: combine automated discovery (a network scanning tool to enumerate devices, IPs, and open ports) with manual verification — physically checking rack labeling, confirming what's actually plugged into what, and asking the on-site contact about anything the scan can't explain. Automated tools are good at finding devices; they're not good at telling you why a workstation nobody remembers is still connected.
After the visit: the raw findings need to become a report before they're useful to anyone. That means organizing by the five categories above, flagging findings by severity (a missing off-site backup is not the same urgency as an outdated printer driver), and writing a short executive summary that states the two or three findings that matter most — in plain language, not a device list.
Tools That Support the Template
The template itself is tool-agnostic — it defines what to capture, not how. In practice, most MSPs combine three kinds of tooling: an automated network scanner (built into most RMM platforms, or a standalone option like Advanced IP Scanner or nmap) to enumerate devices and open ports; a documentation platform (IT Glue, Hudu, or a structured spreadsheet at minimum) to store the findings against the template categories so the next technician doesn't start from zero; and a backup-verification step that's manual by necessity, since a backup job showing "success" in a dashboard is not the same thing as a confirmed, restorable file. None of this requires expensive tooling for a first assessment — a scanner, a spreadsheet built around the five categories, and a checklist for physically confirming what the scan can't see will get a usable assessment done.
Common Mistakes That Turn Into Scope Disputes
Treating the assessment as a sales formality. When the assessment is rushed to get to the pricing conversation, the categories most likely to get skipped are backup verification and licensing — both of which are expensive to discover mid-contract instead of during discovery.
Not documenting what was explicitly out of scope. If a satellite office or a personally-owned device wasn't assessed, write that down in the report itself. An assessment that's silent on a location reads, later, like an assessment that missed it — not one that excluded it on purpose.
Skipping the test restore. A backup schedule that's "green" in a dashboard says nothing about whether a file can actually be recovered. Confirming at least one successful test restore — or explicitly noting that none has occurred — is the single highest-value line item in the backup category, and the one most often skipped under time pressure.
Letting the report become a device list. A twelve-page inventory with no severity ranking and no executive summary is unusable to anyone who isn't already technical. The report needs both: the full detail for whoever scopes the engagement, and a two-paragraph summary for whoever signs the contract.
From Assessment to Proposal
The assessment and the proposal are not separate documents that happen to reference each other — the assessment's findings are the raw material for the proposal's scope of service, and its risk findings are the raw material for the executive summary. A missing off-site backup found in category 4 becomes a specific line item and a specific risk statement, not a vague "we'll improve your backups" bullet point. See the MSP proposal template and IT project proposal template guides for how the sections map.
The gap most MSPs hit here isn't running the assessment — it's the hours between finishing the visit and having a proposal a client can review. Notes from a network assessment, like notes from a discovery call, are usable input for ScopeMSP: paste in what you found — device counts, security gaps, backup status, compliance flags — and get a structured, scoped proposal with the right pricing model and compliance language already applied, instead of starting a blank document at 9pm.