What network documentation should a managed service maintain?
A managed service should maintain accurate, current documentation covering network topology, devices, configurations, IP addressing, security controls, dependencies, approved changes and recovery procedures. This record gives support teams the information needed to troubleshoot consistently, assess risk and manage future network changes safely.
Network documentation should be a controlled, working record of how the environment is built, operated and supported. It should allow an authorised engineer to understand the network, identify what may be affected by a fault or change, and follow the correct recovery process without relying on informal knowledge held by one person.
The documentation should describe both the technical environment and the business context around it. A device list is more useful when it records each device’s purpose, location, owner, support status and relationship with other systems. For example, an engineer may need to know whether a switch serves office users, production equipment, wireless access points or a site-to-site connection before taking action.
A managed service should normally maintain documentation in several connected layers:
- Asset records: details of routers, switches, firewalls, access points, servers, wireless controllers and other network equipment, including identifiers, locations, roles and relevant support information.
- Logical design records: descriptions of network segments, routing relationships, traffic paths, wireless networks, remote access arrangements and links between sites or cloud environments.
- Service dependency records: information showing which business applications, communications services, authentication systems and operational processes depend on particular network components.
- Configuration records: approved baseline settings, relevant software versions, licensing information and the location of securely held configuration backups.
- Operational procedures: instructions for routine administration, fault isolation, maintenance, escalation and recovery, written clearly enough for another suitably authorised engineer to follow.
Records should contain enough detail to support diagnosis without exposing sensitive information unnecessarily. Passwords, private keys and other secrets should not be copied into ordinary documents. Instead, the documentation should identify where authorised staff can retrieve them from a properly controlled credential system. Access to the documentation itself should also be restricted, because a detailed network record could assist an attacker if it were disclosed.
Each important record should have ownership and status information. This normally includes who is responsible for maintaining it, when it was last reviewed, what source was used to verify it and whether it is current, provisional or known to contain a gap. These details help distinguish a confirmed configuration from an assumption. They also make it easier to identify documentation that needs checking after staff changes, supplier changes, office moves or infrastructure work.
Change history is particularly important. A record should link a network alteration to its approval, implementation notes, testing evidence and any follow-up actions. Where a change is reversed, the documentation should show why, what was restored and whether further remediation is required. This creates a useful audit trail and prevents support teams from troubleshooting against an obsolete design.
Good documentation should also record exceptions rather than presenting an inaccurately tidy picture. Unsupported equipment, temporary connections, undocumented wireless devices, unusual firewall rules and inherited settings can all affect risk and troubleshooting. Marking these items clearly allows the managed service and the business to decide whether they should be removed, accepted, monitored or addressed through a planned improvement.
The format matters less than accuracy, accessibility and control. Diagrams are useful for showing relationships and traffic paths, while tables and written procedures are usually better for detailed attributes and repeatable tasks. Documents should be searchable, backed up, permission-controlled and linked so that an engineer can move from a diagram to the relevant device, service dependency or procedure without maintaining several contradictory versions.
Documentation should be checked as part of normal service management rather than left until a major incident. Useful review points include completed changes, new equipment, office relocations, connectivity alterations, security assessments, recovery exercises and the discovery of an undocumented dependency. Monitoring and configuration tools can help identify discrepancies, but automated discovery should be treated as evidence to verify, not as a substitute for an approved record.
The practical test is whether the documentation enables safe decisions. An engineer should be able to determine what a device does, what could be disrupted by changing it, which controls apply, how the change should be tested and how the previous state could be restored. If those answers depend on memory or scattered messages, the documentation is not yet serving its operational purpose.
Network documentation should record the reasoning behind significant design decisions, not only the resulting settings. For example, a segmented network may exist to separate production equipment from office users, or a firewall rule may support a specific application dependency. Recording that context helps a future engineer assess whether a proposed alteration would remove an intentional control or disrupt an essential service.
Decision records are particularly useful where the environment contains constraints, accepted risks or temporary arrangements. They should identify the decision, the options considered, the agreed approach, the relevant business owner and any condition that would trigger a review. This gives the managed service a clear basis for advising on later upgrades and prevents historical assumptions from being mistaken for current requirements.