Network Documentation: What to Record and How to Keep It Current
A switch fails in the branch office. Someone asks which ports carry the phone system, which VLAN the printers are on, and who the internet provider's support contact is. If the answers live in one engineer's head, or in a diagram from three years ago, a short outage becomes a long one.
Good network documentation fixes that. This guide covers what to record, how physical and logical diagrams differ, how to build your documentation from scratch with a network survey, and a simple routine that keeps it accurate.
What is network documentation?
Network documentation is the written and visual record of how your network is built: which devices exist, how they connect, how they're configured, and who to call when something breaks. It usually combines diagrams, an inventory of devices, an IP address plan, configuration records, and contact details for providers and owners.
Its job is practical. When something goes wrong, the person on call should be able to open one place and understand the network without guessing.
Why network documentation matters
Most teams only notice missing network documentation during an outage. But it pays off at three points.
Troubleshooting. A U.S. EPA cybersecurity guide for water utilities, built on CISA's Cross-Sector Cybersecurity Performance Goals, says a well-defined network topology helps administrators locate faults, troubleshoot issues, and allocate network resources. The same guide recommends including the network diagram in your incident response plan, because responders need it most when things are already broken.
Security. That guide also notes that network diagrams are an important reference for spotting potential security vulnerabilities. You can't protect a connection you don't know exists. Undocumented internet links, forgotten wireless bridges, and old vendor connections are exactly the paths you want on paper.
Speed under pressure. Google's Site Reliability Engineering book reports that writing best practices down ahead of time in a "playbook" produces roughly a 3x improvement in mean time to repair, compared with "winging it." Network documentation is the foundation those playbooks rely on.
What to include in your network documentation
You don't need every detail on day one. Start with these six building blocks and add depth over time.
Network diagrams (physical and logical)
Diagrams are the heart of network documentation, and you need two kinds. The EPA guide describes network diagrams as representing both physical and logical layouts, and each answers a different question.
- Physical network diagram: where things actually are. It shows sites, racks, devices, cabling, patch panels, and which port connects to which. Use it when someone has to walk up to a device.
- Logical network diagram: how traffic flows. It shows subnets, VLANs, routing, firewalls, and connections to cloud services and the internet. Use it when you're tracing a connectivity problem or reviewing security.
Keep a one-page overview of each for quick orientation, and link to detailed diagrams for individual sites or segments.
Device inventory
List every switch, router, firewall, access point, and server on the network. For each device, record its name, model, location, management address, owner, and support or warranty details. The UK National Cyber Security Centre recommends collecting asset information regularly so it stays up to date, and recording when each asset was last seen so you can tell how current a record is.
IP address plan
Document your IP address management: which ranges are assigned to which sites and VLANs, which addresses are static, where DHCP scopes live, and which DNS names point where. A clear IP plan prevents conflicts and makes new deployments much faster.
Configuration records and baselines
For each key device, keep a record of its approved configuration and the reason behind important settings. NIST defines a baseline configuration as a documented set of specifications for a system that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. In plain terms: write down the approved setup, and update the record whenever an approved change goes in. That gives you something to compare against when a device starts behaving oddly.
Connections, circuits, and providers
Record every connection that leaves your network: internet circuits, links between sites, VPNs, and cloud connections. Include the provider, circuit ID, bandwidth, and support contact. The EPA guide advises paying special attention to systems that connect directly to the public internet, and to any pathways between operational technology and business IT systems.
Access, owners, and contacts
Note who owns each part of the network, who can approve changes, and how to escalate. Record where administrative credentials are stored, but never paste passwords into your documentation. Point to your password manager instead.
How to create network documentation from scratch
If you're starting with little or nothing, work through these steps in order.
- Survey the network. The EPA guide recommends a network survey to confirm known connection pathways and uncover unknown ones. Include ordinary Ethernet links, but also less obvious paths such as serial, wireless, dial-up, and line-of-sight connections.
- Record what you find. For each asset, document what it is, what it connects to, and how it connects, for example hard-wired or wireless.
- Cross-check your sources. The NCSC advises using multiple data sources to find inconsistencies. Compare your survey against monitoring tools, switch tables, and DHCP logs. A device that shows up in network logs but not in your inventory is worth investigating.
- Draw the diagrams. Start with the logical overview, then the physical layout for each site. Keep each diagram focused so it stays readable.
- Write the supporting pages. Add the device inventory, IP plan, configuration baselines, and provider list, each linked from the overview.
- Bring in third parties. If vendors, integrators, or managed service providers run part of your network, the EPA guide suggests adding language to your agreements that requires them to help keep the documentation current.
A simple network documentation template
Consistent pages are easier to read and easier to maintain. Use this structure for each site or network segment:
- Overview: what this site or segment does, and a link to its diagrams.
- Owner and last review date: who keeps this page accurate, and when it was last checked.
- Diagrams: the physical and logical views for this site.
- Devices: name, model, location, management address, and support details.
- IP ranges and VLANs: subnets, gateways, DHCP scopes, and VLAN purposes.
- External connections: circuits, VPNs, cloud links, and provider contacts.
- Known issues and fixes: common problems and links to the matching troubleshooting steps or runbooks.
- Change history: what changed, when, and why.
Network documentation best practices that keep it current
Outdated network documentation is risky because people trust it. These habits keep it honest.
Update it as part of every change
Make documentation part of the change itself. A change request isn't finished until the diagram, IP plan, or baseline reflects it. New hardware isn't live until it's in the inventory.
Review on a schedule
Give every page a review date, and review critical pages, like internet-facing connections and core switching, more often. When a review date passes, the owner either confirms the page or fixes it.
Check reality against the records
Your documentation describes what should be there. Your monitoring and logs show what is there. Compare the two regularly, as the NCSC recommends, and treat any mismatch as a task, not trivia.
Keep versions and approvals
Being able to see what changed and roll back is as useful for diagrams and baselines as it is for code. For sensitive pages, add an approval step so changes are reviewed before they're published.
Store it where people will look
Network documentation spread across personal folders, chat threads, and old diagram files isn't really documentation. Keep it in one searchable home, linked from your wider IT documentation, and make sure the on-call team can reach it, including when part of the network is down.
How Sonat helps IT teams document their network
Sonat makes it simple to keep network documentation in one clear, searchable place without technical setup. Your team can write in Google Docs and publish with one click, embed diagrams and screenshots next to the text that explains them, and organize pages by site or segment. Every change is kept in an unlimited version archive, approval workflows review sensitive pages before they go live, and private manuals keep internal network details visible only to the right people.
See how Sonat supports IT documentation, or start on the free plan. No credit card is required.
Conclusion
Network documentation isn't a one-time diagram. It's a small, connected set of records: physical and logical diagrams, a device inventory, an IP plan, configuration baselines, external connections, and contacts, all kept current as part of everyday changes. Start with a survey of your most critical site, document what you find this week, and give the result an owner. Your next outage will be shorter for it.