Their IT person had been with the company for three years. He knew everything: the network topology, the firewall rules, the VPN configuration, the server passwords, the ISP account credentials, which patch panel port went where.

None of it was written down. It was all in his head.

When he left โ€” on good terms, for a better opportunity โ€” he took all of it with him. Not deliberately, because it had never been formalized to begin with. There was nothing to hand over.

The new IT provider spent six weeks rebuilding the picture of what was actually running in the environment. Some of it they could discover by scanning the network. Some required password resets, escalations to ISP and vendor support lines, and a few frantic searches through filing cabinets for hardware warranties that might have account numbers attached. The bill was $4,800.

During the firewall audit, they found rules that had been in place for three years that referenced devices no longer on the network. Nobody had been reviewing them.

What network documentation actually means

Network documentation is the written record of how your IT environment is built and how it works. It's not a one-time project โ€” it's a set of living documents that stay current as your environment changes.

At minimum, it includes:

Network diagram

A diagram showing: internet connection โ†’ firewall/router โ†’ switches โ†’ network segments (VLANs). Every device with a fixed IP address should appear, labelled with hostname, IP, and function. This doesn't need to be elaborate โ€” a clear Visio or draw.io diagram updated when things change is sufficient.

Device inventory

A spreadsheet (or IT documentation platform like IT Glue or Hudu) with every network-connected device: hostname, IP address, MAC address, location, device type, model, serial number, purchase date, warranty expiry, and assigned user if applicable.

Credential register

Credentials for network infrastructure should be stored in a company-owned password manager โ€” not in the personal password manager of whoever set it up. Router admin, firewall admin, switch admin, server admin, domain admin, ISP account, and domain registrar login should all be documented and accessible to at least two authorized people.

Configuration backups

Firewall and switch configurations should be exported and stored (encrypted) in a known location. If the firewall fails and needs to be replaced, you should be able to restore the configuration rather than rebuild from memory.

Runbooks for common tasks

A runbook is a short document describing how to do a specific task: how to add a new user, how to set up a new workstation, how to restore from backup, how to escalate a major incident. These don't need to be exhaustive โ€” a checklist format is fine.

Who owns it

This is the more important question. Documentation that exists only in a person's private files is nearly as bad as documentation that doesn't exist.

Network documentation should be owned by the business, stored in a system the business controls, and accessible to the authorized IT providers who need it โ€” not in a personal Dropbox or a notebook in a desk drawer.

If you use an MSP, they should maintain documentation in a platform they provide access to. You should be able to request a full export of your documentation at any time. If they can't provide that, it's a problem worth addressing before you need it.