Building IT Documentation: Network Diagrams, System Descriptions, and CMDB

TL;DR

IT documentation is not an end in itself but the foundation for risk assessment, incident response, change management, and compliance.
Start with three core building blocks: a logical network diagram, system descriptions for critical systems, and an asset inventory.
Perfect documentation that is outdated after three months is worthless. Build in processes from the start that ensure currency.
A CMDB doesn't have to live in an enterprise tool. For companies with fewer than 200 employees, a well-structured asset inventory in the ISMS tool is often sufficient.
The golden rule: Document as much as necessary and as little as possible. The level of detail should align with the protection requirements.

Why IT documentation is the basis of everything

There's a simple test for the state of your IT documentation: Could a new employee, using the available documentation alone, understand within a week how your IT landscape is structured, what systems exist, how they interconnect, and what dependencies exist? If the answer is no, you have a documentation problem. And therefore also a security problem.

IT documentation is the foundation for almost everything an ISMS needs:

Risk assessment: You cannot assess risks for systems you don't know about. And you cannot estimate the impact of an outage if you don't understand the dependencies between systems.

Incident response: If the central switch fails, you need to know within minutes which systems are affected. If a server is compromised, you need to know what data it holds and what network connections it has.

Change management: Before making a change to a system, you must know the dependencies. Otherwise, every change is a risk.

Compliance: ISO 27001, NIS2, BSI IT-Grundschutz, and virtually every other standard require an asset inventory and documentation of the IT infrastructure.

Handover and backup coverage: If your network administrator falls ill and all their knowledge exists only in their head, you have a massive operational risk.

The good news: You don't need to build encyclopedic documentation. You need to document the right things at the right depth and ensure the documentation stays current.

Building block 1: The network diagram

Why the network diagram comes first

The network diagram is the foundation of all IT documentation. It shows at a glance how the IT landscape is structured: what network segments exist, how they're connected, where the transitions to the internet and external networks are, and where the security components sit.

An up-to-date network diagram answers questions that are critical in an emergency: How quickly does an attack spread? Which segments are affected if a switch fails? Where are the firewalls, and what do they protect? Are there paths into the network that don't go through the central firewall?

Logical vs. physical network diagram

There are two types of network diagrams, and you need at least one of them:

Logical network diagram: Shows the network segments (VLANs, subnets), their IP address ranges, the routing relationships, and the placement of security components (firewalls, proxies, IDS/IPS). It abstracts from the physical cabling and focuses on the logical structure. This is the diagram you need for risk assessment and security analysis.

Physical network diagram: Shows the physical cabling, the locations of switches, patch panels, and servers, the cable routes, and the physical connections. It's important for operational IT and physical security, but less relevant for the ISMS than the logical diagram.

Recommendation: Start with the logical network diagram. It delivers the greatest value for the ISMS and is faster to create.

What belongs in the logical network diagram

A useful logical network diagram contains:

Network segments with names and IP address ranges (e.g., "Production network 10.1.0.0/16," "DMZ 172.16.0.0/24," "Management network 10.99.0.0/24")
Firewalls and routers with their interfaces to the segments
Internet connection (provider, bandwidth, redundant or not)
VPN access (site-to-site and remote access)
Cloud connections (which cloud services, how connected)
Wi-Fi networks (with segmentation and authentication)
Critical servers and services (at minimum the most important: DC, DNS, DHCP, email, ERP)
Site connections (WAN links between locations)

Tools for network diagrams

You don't need an expensive tool to create a network diagram. Free or affordable options:

draw.io (diagrams.net): Free, web-based, saves to Git or SharePoint. Good network templates.
Microsoft Visio: If available, a solid tool with extensive network stencils.
Lucidchart: Web-based, collaborative, with automatic import from network discovery tools.

For companies with roughly 100 or more endpoints, a network discovery tool that creates and updates the network diagram automatically or semi-automatically is worth the investment.

Keeping the network diagram current

A network diagram that is a year old is nearly worthless. Networks change: new servers are added, VLANs are restructured, site connections change. Define a process that ensures currency:

Trigger-based updates: With every network change (new segment, new site, new firewall rule), the diagram is updated. Link the update to the change management process.
Periodic review: At least once a year, the diagram is verified against reality. Ideally through a comparison with a discovery tool.
Responsibility: One person (typically the network administrator) is responsible for keeping the diagram current.

Building block 2: System descriptions

What a system description is

A system description documents an IT system so that someone unfamiliar with it can understand the essential aspects: What does the system do? Who uses it? What infrastructure does it run on? What dependencies does it have? How is it secured?

You don't need a system description for every single system. Focus on the critical systems — those whose failure would significantly impair business operations or that process data requiring special protection.

Structure of a system description

A proven structure for system descriptions:

General information:

System name and brief description
Purpose and business processes the system supports
Responsible party (system owner, technical operator)
Vendor and version
License information

Architecture and infrastructure:

Server name(s), IP addresses, location
Operating system and middleware
Database
Dependencies on other systems (e.g., "requires Active Directory for authentication," "receives data from ERP system")
Network segment

Data and protection requirements:

Type of data processed (personal data, financial data, trade secrets)
Protection requirements for confidentiality, integrity, availability
Justification of protection requirements

Security measures:

Authentication and authorization
Encryption (in transit, at rest)
Backup and recovery (interval, retention, RTO/RPO)
Logging and monitoring
Patch strategy

Operations:

Operating hours and availability
Contacts for incidents
Maintenance windows
Capacity and performance information

Adjusting detail level to protection requirements

Not every system needs an extensive description. The level of detail should align with the protection requirements:

High protection requirements (e.g., ERP, HR system, customer database): Complete system description following the structure above. All sections documented.

Normal protection requirements (e.g., time tracking, internal wiki): Abbreviated description. General information, dependencies, protection requirements, and backup are sufficient.

Low protection requirements (e.g., public website without customer data): Minimal description in the asset inventory. A separate system description is generally not needed.

Building block 3: The asset inventory

From list to database

The asset inventory is the central database for all IT assets. ISO 27001 explicitly requires an inventory of assets associated with information and information processing facilities, and that an owner is designated for each asset.

An asset inventory can take various forms:

Excel spreadsheet: Functional for the beginning and for small companies (under 50 IT assets). Hits its limits with growing data volumes and the need for cross-references.

ISMS tool: Most ISMS tools include an integrated asset inventory that links directly to risk assessment and measures. The most practical solution for ISMS purposes.

CMDB tool: For larger companies with complex IT landscapes. Offers automatic discovery, dependency mapping, and integration with IT service management.

What belongs in the asset inventory

Not every mouse and keyboard needs to be inventoried. Focus on assets relevant to information security:

Hardware: Servers (physical and virtual), network components (firewalls, switches, routers), storage systems, endpoints (laptops, workstations, mobile devices), network-connected printers.

Software: Operating systems, business applications (ERP, CRM, HR), databases, middleware, security software (antivirus, EDR, SIEM).

Cloud services: SaaS applications (Office 365, Salesforce, Slack), IaaS/PaaS services (AWS, Azure, GCP), cloud storage.

Information: Customer data, personnel data, financial data, intellectual property, contract documents. These are often captured through the systems that process them.

Physical assets: Server rooms, network distribution rooms, safes, archive rooms. Relevant for physical security.

Mandatory fields for every asset

Define mandatory fields to be captured for every asset:

Name: Unique identifier
Category: Hardware / Software / Cloud / Information / Physical
Description: Brief description of the purpose
Owner: The person responsible for the asset (not the administrator but the business owner)
Location: Physical location or cloud region
Protection requirements: Confidentiality / Integrity / Availability (each: normal / high / very high)
Classification: Public / Internal / Confidential / Strictly confidential
Status: Active / Being introduced / Decommissioned

Building block 4: The CMDB (for advanced users)

When you need a real CMDB

A Configuration Management Database (CMDB) goes beyond a simple asset inventory. It captures not only assets but also the relationships between them: dependencies, service mappings, and configuration details. In ITIL terminology, the entries aren't called "assets" but "Configuration Items" (CIs).

You need a CMDB when you have more than 200 IT assets, when the dependencies between systems are complex, when you run an ITIL-based IT operation, or when you need automated impact analysis for changes or incidents.

For smaller companies (under 200 IT assets), a well-structured asset inventory in the ISMS tool is generally sufficient. You can document the dependencies between systems in the system descriptions or as a free-text field in the asset inventory.

Building a CMDB: The pragmatic approach

If you're building a CMDB, don't start with the ambition to capture everything. Begin with the critical services and work top-down:

Step 1: Identify business-critical services. What are the 10 to 15 most important IT services for your company? Email, ERP, CRM, file storage, web shop, production control?

Step 2: Capture the supporting CIs for each service. Which servers, databases, network components, and software instances support the service? What dependencies exist on other services?

Step 3: Use automatic discovery. Tools like Lansweeper, GLPI, or Snipe-IT can automatically detect and inventory hardware and software on the network. This provides a foundation that you manually supplement with relationships and context information.

Step 4: Assign responsibilities. Every CI needs a responsible party. For services, this is the service owner; for infrastructure components, IT operations.

Step 5: Ensure currency. Link the CMDB to the change management process: Every infrastructure change must trigger a CMDB update. Additionally, conduct periodic reconciliations with automatic discovery.

The process behind it: Ensuring currency

Why most IT documentation is outdated

Creating IT documentation is effort-intensive but achievable. The real problem is maintenance. Most companies create good documentation once and then let it go stale because there's no process to ensure updates.

The reasons are always the same: Updates have no priority in daily operations. There's no clear responsibility. The change is made, but the documentation is updated "later" — and "later" never comes.

Processes for currency

Link to change management: The most important measure. Every change request includes a field "Impact on documentation." The change is only considered complete when the documentation is updated. This sounds bureaucratic, but it's the only way to systematically ensure currency.

Periodic reviews: Once a year, every system description is reviewed for currency by the system owner. The network diagram is verified against reality once a year (ideally with a discovery tool). The asset inventory is checked at least annually for outdated entries.

Automation: Where possible, automate data collection. Network discovery tools, asset management software, and monitoring systems can provide data that automatically feeds into the documentation. This reduces manual effort and error rates.

Responsibility: For every documentation element, there is a responsible person. Not the IT department as a whole, but a specific individual. This person is responsible for ensuring the documentation is current and correct.

The connection to the ISMS

Documentation as input for risk assessment

IT documentation is the central input for risk assessment in the ISMS. Without a current asset inventory, you can't conduct a complete risk assessment because you don't know what assets exist. Without a network diagram, you can't assess network risks because you can't see the attack paths. Without system descriptions, you can't estimate the impact of an outage because you don't know the dependencies.

Documentation as evidence in audits

An auditor will ask for the asset inventory, the network diagram, and system descriptions for critical systems. They'll check whether the documentation is current and whether the captured information matches reality. Well-maintained IT documentation makes a positive impression and significantly speeds up the audit.

Documentation as the basis for emergencies

In an emergency, documentation is vital. If a system administrator is unreachable and a critical system fails, the backup person needs information: What server does the system run on? What is the recovery process? What dependencies exist? Who is the contact at the hosting provider? Every minute spent searching instead of acting during an emergency costs.

Practical roadmap: Building IT documentation in 8 weeks

Week 1-2: Create the network diagram. Draw the logical network diagram, capture segments, firewalls, internet connection, VPN, and site connections. Result: A diagram that shows the IT landscape on one page.

Week 3-4: Build the asset inventory. Capture all relevant assets: hardware, software, cloud services. Populate mandatory fields (name, category, owner, protection requirements). In ISMS Lite, the asset inventory can be directly linked to risk assessment and measures, so IT documentation is integrated into the ISMS from the start. Result: A complete asset inventory with owner assignments.

Week 5-6: System descriptions for critical systems. Document the 10 to 15 most critical systems: purpose, architecture, dependencies, protection requirements, security measures. Result: System descriptions that serve as the foundation for risk assessment.

Week 7: Define processes for currency. Change management integration, periodic reviews, responsibilities. Result: A documented process that ensures long-term currency.

Week 8: Review and approval. Review the network diagram, asset inventory, and system descriptions with the team, close gaps, obtain approval from IT management.

Eight weeks for foundational IT documentation sounds ambitious but is realistic if one person can dedicate about 50 percent of their working time and support from the IT department is secured. The result isn't a documentation masterpiece, but a solid foundation you can continuously improve.