A small-business network can look simple until the internet fails, a router must be replaced or the one person who knows the setup is unavailable. At that point, an unlabeled switch, an unknown internet account or a missing configuration backup can turn a short outage into hours of guesswork.
Good network documentation is not a beautiful diagram created once and forgotten. It is a maintained operating record that tells an authorized technician what exists, how important systems connect, who owns each dependency and where to find the next piece of evidence.
The template below is designed for a small office, shop, nonprofit or distributed team. It covers routers, firewalls, switches, wireless networks, internet circuits, cloud-connected services and configuration backups without requiring enterprise software. It deliberately excludes passwords, private keys and recovery codes; those belong in an approved secrets manager, not in a shared runbook.
| Key takeaways • Keep a device inventory, address register, physical diagram, logical diagram, provider register, dependency map and change log. • Record where credentials and backups are stored, but never place the secrets themselves in the network document. • Mark every record with an owner, last-verified date and evidence source. • Update documentation as part of the change process, not as a separate task people hope to remember. • Use the 10-point trust score in this guide to identify weak documentation; it is an operational measure, not a compliance certification. |
|---|
What network documentation should accomplish
The document should help an authorized person answer five questions quickly:
- What network equipment and services exist?
- How are locations, devices and critical applications connected?
- Which addresses, wireless networks, virtual networks and firewall paths are intentional?
- Who can approve or support a change?
- Where are tested configuration backups, contracts and recovery instructions stored?
These questions align with established security guidance. CIS Control 12 calls for active management of network infrastructure, including architecture and configurations. CIS Control 4 addresses secure configuration processes. CISA treats asset visibility as a building block for operational awareness, while its ransomware guidance advises organizations to maintain secure IT asset documentation and offline copies.
Documentation does not itself secure a network. It makes missing devices, unsupported configurations and unclear ownership easier to see and correct.
The seven-part minimum viable network record
A useful small-business runbook can begin with seven connected sections. A spreadsheet works for registers; a diagramming tool works for topology; a document or wiki can link them together.
| Section | Minimum contents | Primary use |
|---|---|---|
| Site overview | Site name, address, operating hours, equipment room, local contact | Orient a technician before arrival |
| Device inventory | Asset ID, type, make/model, serial number, location, role, support status | Find, replace and maintain equipment |
| Address and network register | Management IP, subnet, VLAN, DHCP range, DNS and gateway | Troubleshoot addressing and segmentation |
| Physical and logical diagrams | Cables and ports; then subnets, VLANs, VPNs and trust boundaries | See how traffic can and should flow |
| Service and dependency map | Internet, DNS, identity, voice, payment, cameras, cloud apps | Understand business impact and recovery order |
| Provider and contract register | ISP, circuit ID, account reference, support channel, renewal date | Escalate outages without searching old emails |
| Backup and change record | Configuration-backup location, restore test, change, approver, rollback | Recover and explain the current state |
Start with what is known and label uncertainty. “Switch in rear cabinet—model not verified” is more useful than silently omitting it. Add an owner and a due date to resolve every unknown.
Copyable network documentation template
Use one row per device, circuit, wireless network or dependency. Stable identifiers are better than informal names such as “the black router.”
Device inventory fields
| Field | Example | Rule |
|---|---|---|
| Asset ID | NET-HQ-FW-01 | Unique and never reused |
| Device type | Firewall | Use a controlled list |
| Make and model | Vendor / model | Copy from label or console |
| Serial number | Manufacturer serial | Restrict access if policy requires |
| Physical location | HQ cabinet A, shelf 2 | Specific enough to find |
| Business role | Internet edge and site VPN | Describe purpose, not only type |
| Management address | 10.20.0.1 | Keep passwords elsewhere |
| Firmware/version | Version and build | Record the evidence date |
| Support status | Supported to 2028-06 | Link to lifecycle evidence |
| Configuration backup | Vault path / backup job ID | Record location and last restore test |
| Owner | IT operations | One accountable function |
| Last verified | Oct 2, 2026 | Use a real date, not “current” |
Network and wireless fields
| Field | Example | Why it matters |
|---|---|---|
| Network name | Staff Wi-Fi | Human-readable reference |
| VLAN / subnet | VLAN 20 / 10.20.20.0/24 | Links logical design to addressing |
| Purpose | Managed staff devices | Clarifies intended membership |
| DHCP range | 10.20.20.50–200 | Reduces address conflicts |
| Gateway / DNS | Documented service addresses | Supports fault isolation |
| Authentication | Enterprise identity provider | Describe method, not secret |
| Isolation rule | No access to guest or IoT networks | Records intended boundary |
| Owner / approver | IT lead | Gives changes a decision path |
| Last tested | Date and test result | Distinguishes design from reality |
Provider and dependency fields
Record the provider, service, circuit or tenant identifier, support number or portal, service hours, renewal date, escalation owner and a link to the contract. For a critical application, add upstream dependencies such as internet, DNS, identity, VPN and power.
Do not copy account passwords, API keys, wireless passphrases or backup codes into these tables. Use a reference such as “Credential vault: Network / HQ ISP / Admin” and restrict the runbook itself to people who need it.
Build physical and logical diagrams separately
A physical diagram shows equipment and connections: internet handoff, firewall, switch, access points, ports, cabinets and inter-site links. It helps when a cable, device or power source fails.
A logical diagram shows how traffic is organized: subnets, VLANs, wireless networks, VPNs, cloud connections, routing and trust boundaries. It helps when a user can reach one service but not another, or when a security review asks whether guest devices are isolated.
Trying to place every cable, address, firewall rule and cloud dependency on one page creates a diagram no one can read. Keep each view focused and link objects with the same asset IDs and network names used in the registers.
For each connection, identify direction only when it matters, such as a site-to-cloud VPN or a restricted management path. Do not document a firewall rule as “needed.” Record the business reason, owner, source, destination, service, approval and expected review date.
Run a 90-minute discovery session
The first version does not require a week-long audit. Use a time-boxed session with the person who supports the network and one business owner.
Minutes 0–15: define the boundary
List sites, remote-worker connections and cloud networks in scope. Decide what is explicitly out of scope. Name the runbook owner and the secure storage location.
Minutes 15–35: collect evidence
Gather invoices, support portals, device consoles, equipment labels, DHCP records and configuration-backup jobs. Evidence is more reliable than memory. Do not change configurations during discovery unless a separate approved change exists.
Minutes 35–55: inventory and map
Create the device list and a rough physical diagram. Then add subnets, wireless networks, VPNs and critical cloud links to a separate logical view. Mark anything inferred rather than verified.
Minutes 55–70: map dependencies
Choose three essential business services and trace what each needs. A cloud point-of-sale service may depend on power, the internet circuit, firewall, DNS, wireless and the vendor platform. Record the recovery order and escalation contact.
Minutes 70–85: verify recovery evidence
Locate configuration backups and confirm their dates. A backup file that has never been restored is evidence of a backup process, not evidence of recoverability. Schedule a controlled restore test if the device or platform supports one.
Minutes 85–90: assign gaps
Give every unknown an owner and due date. Publish version 0.1 rather than waiting for perfection.
Calculate a documentation trust score
Score five dimensions from 0 to 2. Add them for a maximum of 10.
| Dimension | 0 points | 1 point | 2 points |
|---|---|---|---|
| Coverage | Critical devices or services missing | Core items listed, some gaps | Devices, networks and dependencies in scope |
| Currency | No verified dates | Mixed or older verification | All critical records verified within policy |
| Evidence | Memory or assumptions | Some labels and console checks | Key fields linked to reliable evidence |
| Recovery | Backup location unknown | Backups located, restore not tested | Backup and recent restore evidence recorded |
| Ownership | No accountable owner | General team named | Named role for record and each critical service |
Formula: documentation trust score = coverage + currency + evidence + recovery + ownership.
A score of 7 might come from coverage 2, currency 1, evidence 2, recovery 1 and ownership 1. That tells the team where to improve: verify stale records, test a configuration restore and assign explicit owners.
The score is not a security rating and does not prove compliance. It is a lightweight way to prioritize documentation work and track whether the runbook is becoming more reliable.
Protect sensitive network information
Network documentation can help an attacker understand infrastructure. Treat it as sensitive operational information even when it contains no passwords.
- Limit access to authorized staff and providers.
- Require multi-factor authentication for the document repository.
- Keep credentials, private keys and recovery codes in an approved secrets manager.
- Log or review access where the platform permits.
- Maintain a protected offline or exported copy of essential contacts and recovery paths.
- Remove access promptly when an employee or provider leaves.
- Avoid exposing management addresses or diagrams in public tickets and screenshots.
The offline copy should be deliberately limited. It may include circuit IDs, support numbers, equipment locations and recovery sequence while referring authorized staff to the secure vault for secrets.
Keep documentation current after every change
The common failure is not creating the document; it is allowing the network and the document to drift apart. Add documentation to the definition of done for every network change.
A change is complete only when the device record, affected diagram, configuration backup and change log are updated. The change log should include date, requester, approver, reason, affected assets, implementation result, rollback result if used and the person who verified the documentation.
Also define review triggers:
- after a router, firewall, switch or access point is added or replaced;
- after an ISP, subnet, VLAN, VPN or wireless setting changes;
- after a new critical cloud service is introduced;
- after an outage reveals an undocumented dependency;
- after a provider or internal owner changes; and
- at a fixed quarterly review for critical records.
Use a short completeness measure: critical records verified on time divided by total critical records, multiplied by 100. Report the count with the percentage so a small inventory does not create false precision.
A 30-day rollout plan
Week 1: establish the system of record
Choose the approved repository, restrict access and create the seven sections. Import any trustworthy existing inventory rather than starting with assumptions.
Week 2: inventory and diagram
Verify device labels and console records, build the physical and logical views and mark every unknown. Do not scan networks without authorization and an understood operational impact.
Week 3: map dependencies and recovery
Trace the three most important business services, locate configuration backups and schedule safe restore tests. Add provider and escalation details.
Week 4: integrate maintenance
Add documentation fields to the change template, calculate the first trust score and set a quarterly review. Assign an alternate owner so the runbook does not depend on one person.
Frequently asked questions
What should be included in small-business network documentation?
At minimum, include a site overview, device inventory, IP and network register, physical and logical diagrams, critical-service dependencies, provider details, configuration-backup references and a change log.
Should the document contain passwords?
No. Record the approved vault location and access owner, not the password, private key, recovery code or Wi-Fi passphrase itself.
How often should a network diagram be updated?
Update it whenever a material network change is completed and review critical diagrams on a fixed schedule, such as quarterly. The right interval depends on change frequency and business risk.
Do I need network-documentation software?
Not necessarily. A controlled spreadsheet, diagram and document can support a small environment if ownership, access control and update rules are clear. Specialized software becomes more valuable as the number of sites, devices and changes grows.
Is a network inventory the same as an IT asset inventory?
They overlap, but they are not identical. An IT asset inventory may include laptops, software and cloud accounts. Network documentation adds topology, addressing, traffic boundaries, circuits, configurations and service dependencies.
Final checklist
Key-takeaway box
A small, verified runbook beats a large, stale diagram. Start with the seven minimum sections, label unknowns, protect the record and make documentation a required output of every network change.
