Network Documentation: A UK Business Guide to Building a Network Map That Actually Gets Used in 2026

Network documentation is the thing every UK business agrees it should have and almost none of them actually has in a usable state. There is usually something: a Visio file from a 2021 project, a spreadsheet of IP addresses that was accurate when it was made, a folder on a share drive called Network with eleven documents and no indication which is current. What there is not, in most organisations, is a description of the network that a competent engineer who has never seen it could use to understand it at two in the morning.

The gap matters for a specific and measurable reason: undocumented networks are diagnosed by exploration. When something breaks, the first phase of the incident is not fixing anything — it is establishing what exists, what connects to what, and which of the four things called core-switch is the one in the rack. That phase is pure cost, it is entirely avoidable, and it is paid every single time. This guide covers what a network map should genuinely contain across its several layers, how to keep IP address management and diagrams synchronised with a network that changes weekly, where to store documentation so it is reachable when the network is down, and how to build a process that survives the departure of the person who created it — which is the only test of documentation that ultimately matters.

Why most networks exist only in somebody’s head

Networks are not undocumented through negligence. They are undocumented because of how they get built, and understanding that is the first step to fixing it durably rather than producing one more file that is accurate for a fortnight.

A network is built incrementally by people who are, at the moment of building, the only people who need to understand it. The engineer configuring a VLAN for the new finance system knows exactly why it exists, what it connects to, and which firewall rule permits the traffic. Writing that down has no value to them that day. It has enormous value to somebody else in three years, but that person is not in the room, and the work of documenting competes against a queue of things that are visibly urgent. Multiply that by six years and four engineers and the result is a network whose rationale is distributed across people who have mostly left.

The second force is decay. Documentation is a snapshot of a system that keeps moving. A diagram is accurate the day it is drawn and slightly wrong a week later, and because being slightly wrong is not immediately punished, it drifts. Eventually it is wrong enough that people stop trusting it, at which point they stop consulting it, at which point nobody notices when it becomes wrong enough to be actively dangerous — describing a topology that has not existed for two years and sending a troubleshooter in the wrong direction.

The third force is that the cost lands on a different person from the one who could have prevented it. The engineer who did not document is rarely the one paged during the outage. This is an incentive problem rather than a competence problem, and incentive problems are not solved by asking people to try harder. They are solved by changing when documentation happens — making it part of the change rather than a separate activity to be done later, because later never arrives.

The practical implication is that the goal is not a document. It is a process whose output happens to be documentation, owned by someone, gated into the change workflow, and split so that machines maintain the parts machines are good at and humans maintain the part only humans can supply.

What is actually missing

The chart below shows how often each documentation component is absent, out of date beyond usefulness, or unfindable, across UK organisations of 20 to 400 staff at the point we first review their estate. An item counts as present only if it is current and someone who did not write it could locate it.

The ordering of that list is the useful part. The logical diagram — the thing people mean when they say network documentation — is the component most likely to exist, because it is the one that gets produced during projects and shown to management. The components that are genuinely missing are the unglamorous ones: which physical port something is plugged into, what breaks if a given device fails, and above all why any of it is the way it is.

That top row deserves emphasis because it is the one that cannot be recovered by any tool. Automated discovery will find every device, every link and every subnet. It will never tell you that the odd static route exists because a supplier integration needed it in 2022, that the apparently redundant firewall rule is load-bearing for a payment terminal, or that a VLAN which looks abandoned is used quarterly by an auditor. That knowledge exists only in people, and it leaves when they do. Ninety per cent of organisations are carrying a network whose rationale is undocumented, which means every future change carries a risk of breaking something for reasons nobody can anticipate.

The circuit and contract row at fifty-two per cent is worth noting for a different reason: it is the row that costs money rather than time. Organisations that cannot readily say which provider supplies which circuit, on what account, at what contract end date, routinely auto-renew services they no longer need and miss the window to renegotiate ones they do.

Network documentation in UK businesses — the numbers

The figures below reflect what we typically find across UK organisations of 20 to 400 staff. They describe networks that work and are competently run, rather than neglected ones — documentation gaps are largely independent of how well the network itself performs.

The first figure is the one that makes the business case. If well over a third of incident duration is discovery rather than repair, then documentation is not an administrative nicety — it is the largest single lever on mean time to resolution available without buying anything. It also compounds: the discovery phase is when wrong assumptions get made, and a change applied to the wrong device during an outage turns a one-hour incident into a three-hour one.

The second figure is the risk everyone recognises and nobody prices. A network understood by exactly one person is a network with a single point of failure that no amount of hardware redundancy addresses. That person will at some point resign, be on annual leave during an incident, or be unavailable for the obvious human reasons. Organisations tend to discover the true value of documentation in the four weeks after a notice period ends.

The last figure is the one that turns a merely unhelpful situation into an actively painful one. Documentation stored on a file server, an intranet or a wiki that depends on the network being up is documentation that is unavailable precisely when it is needed. Nineteen per cent having an out-of-band copy means four organisations in five would be locked out of their own network map during a significant outage.

Where documentation efforts fall down

The grid below groups the recurring failure patterns we see, including in organisations that have made a genuine attempt. The badges reflect how much each issue undermines the usefulness of the result rather than how much effort it would take to correct.

The monolithic diagram deserves a specific mention because it is the well-intentioned failure. Somebody sets out to draw the whole network on one page, and the result is either unreadably dense or so simplified that it answers no real question. It also becomes impossible to maintain, because every change touches the one artefact everyone depends on, so nobody wants to edit it. Two or three diagrams at different altitudes — a one-page service and site view, a per-site logical view, and a physical rack and patching view — are individually maintainable and collectively more useful.

The credentials row is worth being blunt about. Passwords, community strings and pre-shared keys do not belong in a document that needs to be widely readable during an incident. They belong in a password manager with its own access control and audit trail, referenced from the documentation by name rather than value. Mixing them forces a choice between documentation that is useful and documentation that is safe, and organisations that face that choice usually resolve it by restricting access so tightly that the documentation stops being consulted.

The final card’s last-but-one row — documentation held only by an outgoing provider — is the one that surfaces at the worst possible moment. If a managed service provider holds the only current record of your network, then the relationship has a switching cost that has nothing to do with service quality. Documentation of your own estate is yours, and the right to receive it in a usable, portable form belongs in the contract rather than in a goodwill conversation during a transition.

What a network map should actually contain

Documentation is not one artefact. It is a small set of layers, each answering a different question, and the common failure is producing one of them and considering the job done.

The logical layer

Subnets and their purpose, VLANs, gateways, routing between them, WAN links and their providers, trust boundaries and where policy is enforced. This is the layer that answers “how does traffic get from here to there, and what is allowed to”. Annotate links with speed and with whether they are primary or failover, because a diagram that shows two lines without saying which one carries traffic normally is ambiguous in exactly the situation where clarity matters.

The physical layer

Racks and their contents with unit positions, switch stack membership, patch panel to port mapping, cable runs and labelling, power feeds and UPS coverage. This is the layer most often missing and the one an engineer standing in a comms room at midnight needs most. It is also the layer that automated discovery cannot fully produce, because a switch knows what is connected to a port electrically but not that the port serves the third desk from the window in the meeting room.

Address management

The allocation scheme first, then the allocations. Recording that 10.20.0.0/16 is the estate range, issued as a /22 per site, subnetted by function within each site, is more valuable than a list of individual subnets, because the scheme tells a future engineer where the next allocation should come from. Then the specifics: subnet purpose, DHCP scope ranges, static ranges, reservations, and which addresses are excluded and why. A single spreadsheet holds this adequately up to a couple of sites; beyond that the conflicts and stale entries start to accumulate faster than they get cleaned. The addressing plan itself interacts heavily with topology, which we cover in our guide to multi-site network design.

Asset and lifecycle detail

Device name, model, serial number, location, firmware version, support contract reference, warranty expiry and vendor end-of-support date. The last two turn documentation into a planning tool rather than a reference: an inventory that surfaces which devices lose vendor support within eighteen months is the input to a refresh budget. This layer also does double duty as the asset inventory that Cyber Essentials and ISO 27001 both expect, and as the scope input for security testing — something we touch on in our guide to what happens during a penetration test.

Dependencies and external parties

What breaks if each significant device or service fails, and who to call. Circuit identifiers, provider names, account numbers, support telephone numbers, contract end dates, and the escalation path. This is the layer that gets used during incidents by people who are not engineers, and it should be legible to them.

Configuration and change history

Versioned copies of device configurations, taken automatically, plus a log of what changed, when, by whom and why. The configuration backups are a recovery asset in their own right. The change log is what lets somebody reconstruct how the network reached its current state, which is the closest available substitute for the rationale that was never written down at the time.

Documentation as a project against documentation as a process

Almost every organisation has at some point run a documentation project: a few weeks of concentrated effort, often triggered by an incident, a provider change or an audit. The output is usually good. The problem is what happens next, and it is the difference between the two approaches below.

The row that does the work is the relationship to change. If a network change can be marked complete while the documentation still describes the previous state, then documentation will always lag, and the lag will grow at whatever rate the network changes. Making the documentation update part of what closing a change means — not a separate ticket, not a follow-up task, but a condition of the original change being finished — is the mechanism. It costs a few minutes per change and it is the only approach that holds over years.

The trust row explains why the project approach fails even when the initial output is excellent. Documentation is consulted in proportion to how much it is believed, and belief is destroyed by a single bad experience — one engineer following a diagram to a device that is not there. Once people stop consulting it, the feedback loop that would have caught errors disappears, and it degrades silently from that point. Accuracy and usage are not independent variables.

None of which means an initial project is wrong. If there is nothing to start from, a concentrated effort to establish a baseline is exactly right — the error is treating that baseline as the deliverable rather than as the starting point for a process. Budget the project, then budget the far smaller ongoing cost of keeping it true, and assign the second one to a person by name.

Building the documentation set from nothing

The sequence below assumes an organisation of 20 to 400 staff starting with scattered files and no current baseline. It front-loads automated discovery, because that produces the widest coverage for the least effort, and defers the human-knowledge capture to the point where there is a structure to attach it to.

Week five is the phase to protect if the schedule slips. Everything else can be reconstructed later at a cost in effort; the rationale cannot be reconstructed at all once the people holding it have gone. If a key engineer is leaving, invert the order and do week five first, accepting a messier process, because that window closes on a fixed date and nothing else in the sequence does.

Seven weeks is realistic for a single-site organisation with a few dozen network devices and somebody able to give it meaningful time. Multi-site estates extend the reconciliation and diagram phases roughly in proportion to site count, though the addressing and process phases do not grow much. Organisations that try to compress this below about a month generally skip the physical layer, which is the layer they will most regret missing.

Tooling categories and indicative UK cost

The table below describes categories rather than endorsing products, because the right choice depends far more on what an organisation will actually maintain than on feature comparison. Figures are indicative annual costs for a 20 to 400 seat UK business in 2026, excluding VAT, and open-source options in several categories reduce licence cost to zero while increasing the internal effort required.

The fourth row is the one that changes the economics of the whole exercise, and it is worth understanding why. Automated discovery does not replace documentation, but it removes the hardest part of maintaining it: knowing when something has changed. A tool that reports a new device, a changed link or a subnet nobody declared converts documentation drift from invisible to visible, which means the quarterly audit becomes a short reconciliation rather than a rebuild. Most organisations of this size already own something capable of this within their monitoring platform and have not configured it for the purpose. The wider case for monitoring sits in our guide to proactive network monitoring.

A word on the temptation to spend nothing. A wiki page and a diagram in a free tool, actively maintained, beats an expensive documentation platform nobody updates — by a wide margin. The failure mode in this area is buying tooling as a substitute for process, and it is common because tooling is procurable and process is not. If the choice is between a licence and assigning somebody the ownership, assign the ownership.

Equally, do not let cost-consciousness produce a spreadsheet estate. Several spreadsheets, each partially accurate, held in different places by different people, is the state most organisations are already in, and the reason it fails is not the file format — it is the absence of a single authoritative location. One spreadsheet in one known place with a change history is entirely viable for a small single-site network.

Keeping it synchronised with a network that changes

This is the part that determines whether any of the preceding work has lasting value. There are four mechanisms, and they are complementary rather than alternatives.

Split the work between machines and people

Machines are good at recording what exists and terrible at recording why. People are the reverse. Let discovery tooling own the inventory of devices, links, subnets and versions, updated continuously, and let humans own the rationale, the dependency mapping and the physical detail that no protocol exposes. Attempting to maintain the inventory by hand is what makes documentation feel like an endless chore, and it is the part that can be largely automated away.

Gate documentation into the definition of done

A network change is not complete until the documentation reflects it. Not a follow-up ticket — a condition of closure, checked by whoever approves the change. In practice this is a single line added to a change template asking which documentation was updated, and it works because it moves the cost to the person making the change, at the moment they have the context, which is when it is cheapest to record.

Audit against reality on a cadence

Quarterly, compare the documented state against discovery output and investigate every discrepancy. Each one is either a change that was not documented or documentation that is wrong, and both are worth knowing. An annual deeper review should additionally check the things discovery cannot see: whether the patch panel mapping still matches, whether contract end dates have moved, whether the rationale notes still make sense.

Record change, not just state

A change log costs almost nothing and does something documentation of current state cannot: it lets somebody reconstruct how the network arrived where it is. When an incident traces back to a configuration that nobody can explain, the change log is frequently the only route to understanding it, and it partially compensates for rationale that was never captured at the time. Automated configuration backups with version history provide much of this for free.

The number that justifies the effort

If one measurement had to make the case to a board, it would be the share of major incident duration spent working out what exists rather than repairing anything. It is the cost of missing documentation expressed in the currency the business already cares about, and unlike most documentation arguments it is measurable from existing incident records.

Thirty-eight per cent of incident time spent on discovery is a figure that translates directly. An organisation with four significant network incidents a year averaging three hours each is spending something over four and a half hours annually on repeatedly rediscovering its own network — and that undercounts, because the discovery phase is when wrong assumptions are formed, and a change applied to the wrong device extends the incident rather than merely delaying the fix.

The figure is worth calculating from your own records rather than borrowing. Take the last three or four significant incidents, read the ticket timeline, and mark where the team was establishing facts against where they were applying a fix. Most organisations find the proportion higher than they expected, and having the number from their own history is far more persuasive internally than any benchmark.

It is also the fairest test of documentation quality. Documentation that reduces the discovery phase is working, regardless of how it looks or which tool holds it. Documentation that does not reduce it is not working, however handsome the diagram, and the discovery share is the measure that distinguishes the two.

Benchmarks — documentation practice against what we find

The figures below reflect how often each practice is present across UK organisations of 20 to 400 staff at first review. Readings are generous throughout: a practice counts as present if it exists in any form, regardless of quality.

Eighty-one per cent against sixteen per cent is the shape of the whole problem. Nearly everyone has produced documentation at some point; a sixth have the one mechanism that keeps it true. Everything between those numbers is documentation slowly ceasing to describe the network it was written about, and the organisation not finding out until an incident.

The two cheapest rows are again among the lowest. Gating documentation into change closure is a line on a change template. Placing an out-of-band copy somewhere reachable during an outage is a deliberate act performed once and refreshed on a cadence. Neither requires budget or tooling, and together they address the two failures — silent drift and unavailability at the moment of need — that make otherwise good documentation worthless.

Naming conventions and why they are documentation

A naming convention is the cheapest documentation an organisation can own, because it embeds information in the thing itself rather than in a separate file that can drift away from it. A device called LON-CORE-SW01 tells an engineer its site, its role and its number before they have opened anything. A device called switch2 tells them nothing, and worse, tells them nothing while appearing to be informative.

The scheme matters far less than having one and applying it consistently. Site code, role, then a sequence number covers most estates; add a floor or rack identifier where buildings are large enough to need it. Extend the same logic to the things around the devices: subnet descriptions, VLAN names, firewall rule descriptions, patch panel labels, wireless network names and DHCP scope names. The value compounds, because an engineer who learns the convention once can then navigate parts of the estate they have never seen.

Two practical notes. First, rename opportunistically rather than as a project — renaming a live device is a small change with a non-zero chance of breaking a monitoring reference or a firewall rule, so do it when the device is already being worked on and check what references it first. Second, write the convention down and put it at the front of the documentation, because a convention nobody has recorded will be guessed at differently by the next three people to add a device.

Firewall rule descriptions deserve a specific mention as the highest-value place to apply this discipline. A rule described as allow 443 inbound records what the rule does, which the rule already says. A rule described with the system it serves, the requester and the date is the rationale layer captured at the only moment it is cheap to capture — and it is what prevents the rule being deleted during a future tidy-up by somebody who cannot tell whether it matters. This is closely tied to how policy is structured across the estate, which we cover in our guide to network segmentation for UK SMEs.

The uses that are not incidents

Incident response is the argument that gets documentation funded, but it is not the only return, and the others are worth knowing because they arrive on somebody else’s timetable.

Certification and audit

An accurate asset inventory is a control requirement rather than a nicety. Cyber Essentials expects an organisation to know what is in scope, including its firewall and boundary configuration; ISO 27001 expects asset management to be documented and maintained. Organisations pursuing either generally find that the network documentation work is the longest part of the exercise, and that having done it already converts a multi-week scramble into an afternoon of collation. The same inventory is the input to scoping security testing, and a supplier who has to discover your estate before testing it is spending your budget on discovery.

Procurement, renewals and refresh planning

Recording firmware versions, support contract references and vendor end-of-support dates turns documentation from a reference into a planning instrument. It surfaces which devices fall out of vendor support within the next budget cycle, which is the input to a refresh plan rather than an emergency purchase after a failure. It also surfaces circuit contract end dates, which is the difference between renegotiating a leased line and discovering it auto-renewed for three years.

Due diligence and insurance

Acquirers, investors and insurers increasingly ask questions that documentation answers directly: what is the estate, how is it segmented, what is out of support, who has administrative access. These requests arrive with deadlines set by a transaction rather than by you. Organisations that can answer from existing records look well run; organisations that cannot spend the diligence period producing documentation under time pressure, which is both expensive and a poor impression to create.

Provider transitions

Changing managed service provider is substantially cheaper and lower risk when the incoming provider can be handed a current network map instead of reverse-engineering the estate at your expense. It also removes a soft dependency: a provider who holds the only accurate record of your network has leverage unrelated to the quality of their service, and the cost of that is invisible until you want to leave. The cost comparison between models is something we look at in our guide to in-house versus managed IT support.

Documentation maturity — where most UK estates sit

Combining the assessment areas gives an indication of how well an organisation would cope with an incident, an audit or the departure of its most knowledgeable engineer. The gauge reflects a first review of a UK business of 20 to 400 staff with a functioning network and no documentation process.

A score in the mid-thirties has a familiar composition. Something exists, usually a diagram and a spreadsheet, and it was good when it was made. Coverage scores moderately on the logical layer and badly on the physical layer and dependencies. Currency scores poorly because nothing connects documentation to change. Rationale scores close to zero, because capturing why is not a habit anyone has been asked to form. Availability during an outage scores poorly, mostly because nobody has considered the question.

What distinguishes this benchmark from most is how much of the gap closes through decisions rather than work. Naming an owner is a decision. Choosing a single authoritative location is a decision. Adding a line to the change template is a decision. Configuring discovery in monitoring tooling you already own is an afternoon. The genuinely effortful items are the physical layer reconciliation and the rationale capture, and the second of those has a deadline nobody controls.

The usual caveat applies with force. A six-person business with a single switch, one firewall and a broadband circuit does not need any of this machinery, and a photograph of the comms cupboard plus a note of the provider account number is proportionate documentation. The score becomes meaningful roughly at the point where more than one person maintains the network, or where the network is complex enough that nobody holds all of it. Below that threshold, the honest answer is that documentation effort should be minimal and mostly about not losing the account details.

Common network documentation mistakes

The errors below recur across organisations that have genuinely tried. Most are structural rather than careless, which is why they persist through several attempts.

• Documenting what exists and never why. Automated tooling will map every device and link. It will never tell you why an odd static route exists or which apparently redundant rule is load-bearing. That knowledge lives in people and leaves with them.
• Drawing one diagram to cover everything. The result is either unreadable or so simplified it answers nothing, and because every change touches it, nobody maintains it. Three diagrams at different altitudes are individually maintainable and collectively more useful.
• Treating it as a project rather than a process. A concentrated few weeks produces a good baseline that degrades from the day it is finished. Without a gate into change closure, the lag grows at whatever rate the network changes.
• Leaving it unowned. Documentation that is everybody’s responsibility is nobody’s. A named owner is the cheapest intervention available and among the least common.
• Skipping the physical layer. Which port, which patch panel, which rack unit, which power feed. It is the layer discovery cannot fully produce and the layer an engineer in a comms room at midnight needs most.
• Putting credentials in the documentation. It forces a choice between useful and safe, and organisations resolve it by restricting access until the documentation stops being consulted. Reference secrets by name from a password manager.
• Storing it only where the network can reach. A network map on the file server is unavailable during exactly the incident it was written for. Four organisations in five have no out-of-band copy.
• Letting a provider hold the only current copy. Your estate documentation is yours, and the right to receive it in a portable, usable form belongs in the contract rather than in a goodwill conversation during a transition.

What this looks like in practice

A 165-person architectural practice across two UK offices had a network built and maintained over nine years by a single internal network engineer. It worked well. Monitoring was in place, backups ran, the estate was tidy, and he could answer any question about it from memory in seconds, which everybody regarded as a strength rather than a risk.

He resigned in the March, with a month of notice. The practice asked him to produce documentation before leaving, and he did: a logical diagram, a spreadsheet of subnets and devices, and a handover document of about fourteen pages. Everybody agreed it was a thorough job, and by most standards it was.

The first significant incident came in the July. A core switch in the smaller office failed, and the replacement was straightforward, but bringing the office back required knowing which patch panel ports carried which services. The handover document described the logical topology accurately and contained no physical port mapping at all, because port mapping had lived entirely in the departed engineer’s head and neither he nor anyone else had thought to ask for it. Restoring the office took eleven hours, of which the incoming provider estimated six were spent tracing cables.

Two further gaps surfaced over the following months. A firewall rule that appeared redundant was removed during a tidy-up and broke a nightly data transfer to a structural engineering consultancy; nobody had known the rule existed for that purpose. And a leased line at the main office auto-renewed for three years at the previous rate because the contract end date was recorded nowhere and the renewal notice went to a mailbox belonging to the person who had left.

The rebuild took about seven weeks. Discovery tooling already present in the monitoring platform was configured to maintain the device and link inventory automatically, which took an afternoon and immediately found two unmanaged switches nobody had mentioned. The comms rooms were walked and every port mapped and labelled. Configuration backups were automated with version history. Circuit and contract detail was gathered from invoices. Documentation moved to one platform with a named owner, and a line was added to the change template asking which documentation had been updated.

The rationale layer was the part that could not be recovered. The practice contacted the former engineer, who answered what he could recall from memory several months on, and a number of configuration decisions remain annotated in the documentation as unexplained — which is itself useful, because it flags them as things to investigate rather than remove.

We thought the risk was that he would leave without writing anything down. He wrote plenty down. The risk was that we did not know which questions to ask him, and the things we most needed were the things so obvious to him that it never occurred to him they were knowledge. The port mapping was not in his document because, to him, it was just where things were plugged in.

Two points generalise. The first is that a handover document written by a departing engineer will cover what that engineer considers documentation, which systematically omits whatever has become intuitive to them. Handover is far more effective when the receiving side supplies the question list. The second is that the contract end date was the cheapest thing on the list to record and produced the largest single financial loss, which is a useful corrective to the assumption that documentation value is concentrated in the technical layers.

The 12-point network documentation checklist

Items one to three are decisions to take before producing content. Items four to nine are the content itself. Items ten to twelve are what keeps it true after the initial effort.

1. Name one owner accountable for currency. A person, not a team. This is the cheapest intervention available and only about a quarter of organisations have it.
2. Choose one authoritative location. Decided before anything is written, otherwise you produce another copy. Version history matters more than the platform.
3. Configure automated discovery for devices, links and subnets. Most organisations already own something capable of this in their monitoring platform. It converts drift from invisible to visible.
4. Draw three diagrams, not one. A one-page service and site view, a per-site logical view with subnets and policy points, and a physical rack and patching view. Each dated, versioned and attributed.
5. Record the addressing scheme before the allocations. The scheme tells a future engineer where the next subnet comes from. Then scopes, static ranges, reservations and exclusions.
6. Map the physical layer. Rack positions, stack membership, patch panel to port mapping, labelling, power feeds and UPS coverage. The layer discovery cannot produce and incidents most need.
7. Capture the rationale while the people are still there. Walk the anomalies with whoever built it and record why each exists, or record explicitly that nobody knows. This phase has a deadline you do not control.
8. Record dependencies, circuits and contracts. What breaks if each device fails, plus provider names, circuit identifiers, account numbers, support numbers, escalation paths and contract end dates.
9. Automate versioned configuration backups. A recovery asset in its own right and the closest available substitute for a rationale nobody wrote down.
10. Gate documentation into the definition of done. A network change is not closed until the documentation reflects it. One line on the change template, checked by the approver.
11. Audit against discovered reality quarterly. Investigate every discrepancy: each is either an undocumented change or wrong documentation, and both are worth knowing.
12. Keep an out-of-band copy and run the new-engineer test. Reachable when the primary network is down, physically secure, credential-free; and annually ask someone who did not build it to answer a specific question from the documentation alone.

At a glance — network documentation summary

How Cloudswitched approaches network documentation

Cloudswitched provides network administration for UK organisations, and documentation is part of running a network rather than a separate deliverable. In practice that means configuring automated discovery and versioned configuration backup so the inventory maintains itself, walking comms rooms to map the physical layer that no tool can see, recording the addressing scheme alongside the allocations, capturing rationale from whoever built the estate while they are still available, holding circuit and contract detail where it can be found before a renewal date passes, and gating documentation updates into how changes are closed. Where a client moves to or from us, the documentation is theirs in a portable form — which is how it should work regardless of who holds the contract.

Frequently Asked Questions

What should network documentation actually include?

Six layers, each answering a different question. The logical layer: subnets and their purpose, VLANs, routing, WAN links, trust boundaries and where policy is enforced. The physical layer: racks and unit positions, stack membership, patch panel to port mapping, labelling, power and UPS coverage. Address management: the allocation scheme first, then scopes, static ranges, reservations and exclusions. Asset and lifecycle detail: model, serial, firmware, support contract, warranty and vendor end-of-support dates. Dependencies and external parties: what breaks if each device fails, plus circuit identifiers, providers, account numbers and contract end dates. And configuration and change history, ideally automated and versioned.

Why does network documentation always go out of date?

Because it is treated as a project rather than as an output of how changes are made. A concentrated effort produces a good baseline that starts degrading the day it finishes, and because being slightly wrong is not immediately punished, it drifts until people stop trusting it. Once they stop consulting it, the feedback loop that would have caught errors disappears and it decays silently. The fix is to make updating documentation a condition of a change being closed rather than a follow-up task, which moves the cost to the person who has the context at the moment it is cheapest to record.

What is the most important part of network documentation?

The rationale — why things are configured the way they are. It is missing in roughly 89 per cent of the estates we review and it is the only layer that cannot be recovered by any tool. Automated discovery will find every device, link and subnet, but it will never tell you that an odd static route exists for a supplier integration, that an apparently redundant firewall rule is load-bearing for a payment terminal, or that a VLAN which looks abandoned is used quarterly by an auditor. That knowledge exists only in people and leaves when they do, which gives the rationale capture a deadline set by somebody’s notice period rather than by your project plan.

How many network diagrams should we have?

Three, at different altitudes. A one-page service and site view legible to non-specialists, a per-site logical view showing subnets, links, speeds and policy enforcement points, and a physical view covering racks and patching. The common mistake is attempting one diagram covering everything, which ends up either unreadably dense or so simplified it answers no real question — and becomes unmaintainable because every change touches the single artefact everyone depends on. Annotate each with date, author and version, and mark which links carry traffic normally rather than just showing two lines.

Do we need a dedicated IPAM tool or will a spreadsheet do?

A single spreadsheet in one known location with a change history is genuinely adequate up to roughly two sites or fifty subnets. Beyond that, conflicts and stale entries accumulate faster than they get cleaned, and a dedicated tool earns its place. The more important point is that the failure mode is rarely the file format — it is having several partially accurate spreadsheets in different places held by different people, with no authoritative version. Record the allocation scheme as well as the allocations, because the scheme tells a future engineer where the next subnet should come from.

Can we just use automated discovery instead of writing documentation?

No, but you should definitely use it for the part it does well. Discovery tooling is excellent at maintaining an inventory of devices, links, subnets and firmware versions, updated continuously, and it removes the hardest part of maintaining documentation by hand: knowing when something has changed. What it cannot produce is the rationale, the service dependency view, or the physical detail such as which port serves which desk. Split the work: let machines own what exists and people own why, and use quarterly reconciliation between the two to surface undocumented changes.

Where should network documentation be stored?

In one authoritative location with version history, and additionally in a copy that is reachable when the primary network is down. The second part is the one almost everybody misses — only about 19 per cent of organisations we review can reach their documentation during a significant outage, because it lives on a file server, intranet or wiki that depends on the network being up. Keep the out-of-band copy physically secure and free of credentials, and refresh it on a cadence so it does not become a stale trap of its own.

Should credentials go in the network documentation?

No. Passwords, community strings and pre-shared keys belong in a password manager with its own access control and audit trail, referenced from the documentation by name rather than by value. Mixing them forces a choice between documentation that is useful and documentation that is safe, and organisations facing that choice usually restrict access so tightly that the documentation stops being consulted at all. Separating them lets the topology and dependency information be readable by everyone who needs it during an incident.

Is network documentation a security risk?

It is a map of your estate, so it has value to an attacker who obtains it, and that is worth taking seriously. It is also regularly used as an argument for not documenting at all, which is a much worse trade. The balance that works: keep credentials out entirely, apply access control proportionate to sensitivity, and keep the emergency out-of-band copy somewhere physically secure rather than on an unencrypted laptop or an open cloud share. A well-protected map being stolen is a possibility; an undocumented network being mishandled during an incident is close to a certainty.

How long does it take to document a network from scratch?

About seven weeks for a single-site organisation of 20 to 400 staff with a few dozen network devices and somebody able to give it real time: a week on structure and automated discovery, two weeks reconciling and enriching the inventory, a week on addressing, a week on diagrams, a week capturing rationale, a week on dependencies and configuration backup, and a final week gating it into change and testing it. Multi-site estates extend the reconciliation and diagram phases roughly in proportion to site count. Compressing below about a month usually means skipping the physical layer, which is the omission organisations most regret.

Our provider holds our network documentation. Is that a problem?

It is, if it is the only current copy. Documentation of your own estate is yours, and where a provider holds the sole record the relationship carries a switching cost unrelated to service quality — and a transition becomes a negotiation rather than a handover. Put the right to receive current documentation in a portable, usable format into the contract, and ask for it periodically rather than only when leaving. Reputable providers have no objection to this; a reluctance to supply it is itself informative.

How do we know if our documentation is any good?

Two tests. First, the new-engineer test: ask someone who did not build the network to answer a specific question — which switch port the reception phone is on, why a particular subnet exists, which circuit the guest wireless egresses through — from the documentation alone, and time them. More than five minutes, or an outcome where they ask a colleague, means you have files rather than documentation. Second, the incident test: measure what share of your last few significant incidents was spent establishing facts rather than fixing. Documentation that reduces that share is working, whatever it looks like.

Related reading

More guidance on designing, running and documenting UK business networks:

• Multi-site network design: connecting branch offices to the cloud
• Office move IT checklist for hybrid teams
• Bandwidth planning for a growing UK business
• What happens during a penetration test
• In-house versus managed IT support: a UK cost comparison