IT-Dokumentation aufbauen: Netzwerkpläne, Systembeschreibungen und CMDB

TL;DR

IT-Dokumentation ist kein Selbstzweck, sondern die Grundlage für Risikobewertung, Incident Response, Change Management und Compliance.
Starte mit drei Kernbausteinen: einem logischen Netzwerkplan, Systembeschreibungen für kritische Systeme und einem Asset-Inventar.
Perfekte Dokumentation, die nach drei Monaten veraltet ist, ist wertlos. Baue von Anfang an Prozesse ein, die die Aktualität sicherstellen.
Eine CMDB muss nicht in einem Enterprise-Tool leben. Für Unternehmen unter 200 Mitarbeitern reicht oft ein gut strukturiertes Asset-Inventar im ISMS-Tool.
Die goldene Regel: Dokumentiere so viel wie nötig und so wenig wie möglich. Der Detailgrad richtet sich nach dem Schutzbedarf.

Warum IT-Dokumentation die Basis von allem ist

Es gibt einen einfachen Test für den Zustand deiner IT-Dokumentation: Könnte ein neuer Mitarbeiter anhand der vorhandenen Unterlagen innerhalb einer Woche verstehen, wie deine IT-Landschaft aufgebaut ist, welche Systeme es gibt, wie sie zusammenhängen und welche Abhängigkeiten bestehen? Wenn die Antwort Nein ist, hast du ein Dokumentationsproblem. Und damit hast du auch ein Sicherheitsproblem.

IT-Dokumentation ist die Grundlage für fast alles, was ein ISMS braucht:

Risikobewertung: Du kannst keine Risiken für Systeme bewerten, die du nicht kennst. Und du kannst die Auswirkung eines Ausfalls nicht einschätzen, wenn du die Abhängigkeiten zwischen Systemen nicht verstehst.

Incident Response: Wenn der zentrale Switch ausfällt, musst du in Minuten wissen, welche Systeme betroffen sind. Wenn ein Server kompromittiert wird, musst du wissen, welche Daten darauf liegen und welche Netzwerkverbindungen er hat.

Change Management: Bevor du eine Änderung an einem System vornimmst, musst du die Abhängigkeiten kennen. Sonst ist jede Änderung ein Risiko.

Compliance: ISO 27001, NIS2, BSI-Grundschutz und praktisch jeder andere Standard fordern ein Asset-Inventar und die Dokumentation der IT-Infrastruktur.

Übergabe und Vertretung: Wenn dein Netzwerkadministrator krank wird und sein gesamtes Wissen nur in seinem Kopf existiert, hast du ein massives Betriebsrisiko.

Die gute Nachricht: Du musst keine enzyklopädische Dokumentation aufbauen. Du musst die richtigen Dinge in der richtigen Tiefe dokumentieren und dafür sorgen, dass die Dokumentation aktuell bleibt.

Baustein 1: Der Netzwerkplan

Warum der Netzwerkplan an erster Stelle steht

Der Netzwerkplan ist das Fundament jeder IT-Dokumentation. Er zeigt auf einen Blick, wie die IT-Landschaft strukturiert ist: welche Netzwerksegmente es gibt, wie sie verbunden sind, wo die Übergänge zum Internet und zu externen Netzen liegen und wo die Sicherheitskomponenten sitzen.

Ein aktueller Netzwerkplan beantwortet Fragen, die im Ernstfall überlebenswichtig sind: Wie schnell breitet sich ein Angriff aus? Welche Segmente sind betroffen, wenn ein Switch ausfällt? Wo sitzen die Firewalls, und was schützen sie? Gibt es Wege ins Netzwerk, die nicht über die zentrale Firewall laufen?

Logischer vs. physischer Netzwerkplan

Es gibt zwei Arten von Netzwerkplänen, und du brauchst mindestens einen davon:

Logischer Netzwerkplan: Zeigt die Netzwerksegmente (VLANs, Subnetze), ihre IP-Adressbereiche, die Routing-Beziehungen und die Platzierung von Sicherheitskomponenten (Firewalls, Proxies, IDS/IPS). Er abstrahiert von der physischen Verkabelung und konzentriert sich auf die logische Struktur. Das ist der Plan, den du für die Risikobewertung und für Sicherheitsanalysen brauchst.

Physischer Netzwerkplan: Zeigt die physische Verkabelung, die Standorte von Switches, Patchpanels und Servern, die Kabelwege und die physischen Verbindungen. Er ist wichtig für den operativen IT-Betrieb und die physische Sicherheit, aber für das ISMS weniger relevant als der logische Plan.

Empfehlung: Starte mit dem logischen Netzwerkplan. Er liefert den größten Nutzen für das ISMS und ist schneller zu erstellen.

Was in den logischen Netzwerkplan gehört

Ein brauchbarer logischer Netzwerkplan enthält:

Netzwerksegmente mit Namen und IP-Adressbereichen (z. B. "Produktivnetz 10.1.0.0/16", "DMZ 172.16.0.0/24", "Management-Netz 10.99.0.0/24")
Firewalls und Router mit ihren Schnittstellen zu den Segmenten
Internetanbindung (Provider, Bandbreite, redundant oder nicht)
VPN-Zugänge (Site-to-Site und Remote Access)
Cloud-Anbindungen (welche Cloud-Dienste, wie angebunden)
WLAN-Netze (mit Segmentierung und Authentifizierung)
Kritische Server und Dienste (zumindest die wichtigsten: DC, DNS, DHCP, E-Mail, ERP)
Standortverbindungen (WAN-Anbindungen zwischen Standorten)

Werkzeuge für Netzwerkpläne

Du brauchst kein teures Tool, um einen Netzwerkplan zu erstellen. Kostenlose oder günstige Optionen:

draw.io (diagrams.net): Kostenlos, webbasiert, speichert in Git oder SharePoint. Gute Netzwerk-Vorlagen.
Microsoft Visio: Wenn vorhanden, ein solides Werkzeug mit umfangreichen Netzwerk-Stencils.
Lucidchart: Webbasiert, kollaborativ, mit automatischem Import aus Netzwerk-Discovery-Tools.

Für Unternehmen ab ca. 100 Endgeräten lohnt sich zusätzlich ein Netzwerk-Discovery-Tool, das den Netzwerkplan automatisch oder halbautomatisch erstellt und aktualisiert.

Netzwerkplan aktuell halten

Ein Netzwerkplan, der ein Jahr alt ist, ist fast wertlos. Netzwerke ändern sich: Neue Server kommen hinzu, VLANs werden umstrukturiert, Standortanbindungen wechseln. Definiere einen Prozess, der die Aktualität sicherstellt:

Trigger-basierte Aktualisierung: Bei jeder Netzwerkänderung (neues Segment, neuer Standort, neue Firewall-Regel) wird der Plan angepasst. Verknüpfe die Aktualisierung mit dem Change-Management-Prozess.
Periodische Überprüfung: Mindestens einmal jährlich wird der Plan gegen die Realität geprüft. Idealerweise durch einen Abgleich mit einem Discovery-Tool.
Verantwortlichkeit: Eine Person (typischerweise der Netzwerkadministrator) ist verantwortlich für die Aktualität des Plans.

Baustein 2: Systembeschreibungen

Was eine Systembeschreibung ist

Eine Systembeschreibung dokumentiert ein IT-System so, dass jemand, der das System nicht kennt, die wesentlichen Aspekte versteht: Was macht das System? Wer nutzt es? Auf welcher Infrastruktur läuft es? Welche Abhängigkeiten hat es? Wie wird es gesichert?

Du brauchst keine Systembeschreibung für jedes einzelne System. Konzentriere dich auf die kritischen Systeme, also die Systeme, deren Ausfall den Geschäftsbetrieb erheblich beeinträchtigt oder die besonders schutzbedürftige Daten verarbeiten.

Struktur einer Systembeschreibung

Eine bewährte Struktur für Systembeschreibungen:

Allgemeine Informationen:

Systemname und Kurzbeschreibung
Zweck und Geschäftsprozesse, die das System unterstützt
Verantwortlicher (Systemeigner, technischer Betreiber)
Hersteller und Version
Lizenzinformationen

Architektur und Infrastruktur:

Servername(n), IP-Adressen, Standort
Betriebssystem und Middleware
Datenbank
Abhängigkeiten zu anderen Systemen (z. B. "benötigt Active Directory für Authentifizierung", "bezieht Daten aus ERP-System")
Netzwerksegment

Daten und Schutzbedarf:

Art der verarbeiteten Daten (personenbezogene Daten, Finanzdaten, Geschäftsgeheimnisse)
Schutzbedarf nach Vertraulichkeit, Integrität, Verfügbarkeit
Begründung des Schutzbedarfs

Sicherheitsmaßnahmen:

Authentifizierung und Autorisierung
Verschlüsselung (in Transit, at Rest)
Backup und Recovery (Intervall, Aufbewahrung, RTO/RPO)
Logging und Monitoring
Patch-Strategie

Betrieb:

Betriebszeiten und Erreichbarkeit
Kontakte für Störungen
Wartungsfenster
Kapazitäts- und Performanceinformationen

Detailgrad an Schutzbedarf anpassen

Nicht jedes System braucht eine umfangreiche Beschreibung. Der Detailgrad sollte sich am Schutzbedarf orientieren:

Hoher Schutzbedarf (z. B. ERP, HR-System, Kundendatenbank): Vollständige Systembeschreibung nach der obigen Struktur. Alle Abschnitte dokumentiert.

Normaler Schutzbedarf (z. B. Zeiterfassung, internes Wiki): Verkürzte Beschreibung. Allgemeine Informationen, Abhängigkeiten, Schutzbedarf und Backup reichen aus.

Niedriger Schutzbedarf (z. B. öffentliche Website ohne Kundendaten): Minimale Beschreibung im Asset-Inventar. Eine separate Systembeschreibung ist in der Regel nicht nötig.

Baustein 3: Das Asset-Inventar

Von der Liste zur Datenbank

Das Asset-Inventar ist die zentrale Datenbasis für alle IT-Assets. ISO 27001 fordert explizit ein Inventar der Assets, die mit Informationen und informationsverarbeitenden Einrichtungen in Verbindung stehen, und dass für jedes Asset ein Eigner benannt ist.

Ein Asset-Inventar kann verschiedene Formen annehmen:

Excel-Liste: Für den Anfang und für kleine Unternehmen (unter 50 IT-Assets) funktional. Stößt bei wachsenden Datenmengen und dem Bedarf nach Verknüpfungen an Grenzen.

ISMS-Tool: Die meisten ISMS-Tools bringen ein integriertes Asset-Inventar mit, das direkt mit Risikobewertung und Maßnahmen verknüpft ist. Für ISMS-Zwecke die praktischste Lösung.

CMDB-Tool: Für größere Unternehmen mit komplexer IT-Landschaft. Bietet automatische Erkennung, Abhängigkeitsdarstellung und Integration mit IT-Service-Management.

Was ins Asset-Inventar gehört

Nicht jede Maus und jede Tastatur muss inventarisiert werden. Konzentriere dich auf Assets, die für die Informationssicherheit relevant sind:

Hardware: Server (physisch und virtuell), Netzwerkkomponenten (Firewalls, Switches, Router), Speichersysteme, Endgeräte (Laptops, Workstations, Mobilgeräte), Drucker mit Netzwerkanbindung.

Software: Betriebssysteme, Geschäftsanwendungen (ERP, CRM, HR), Datenbanken, Middleware, Sicherheitssoftware (Antivirus, EDR, SIEM).

Cloud-Dienste: SaaS-Anwendungen (Office 365, Salesforce, Slack), IaaS/PaaS-Dienste (AWS, Azure, GCP), Cloud-Speicher.

Informationen: Kundendaten, Personaldaten, Finanzdaten, geistiges Eigentum, Vertragsdokumente. Diese werden oft über die Systeme erfasst, die sie verarbeiten.

Physische Assets: Serverräume, Netzwerkverteiler, Tresore, Archivräume. Relevant für physische Sicherheit.

Pflichtfelder für jedes Asset

Definiere Pflichtfelder, die für jedes Asset erfasst werden:

Bezeichnung: Eindeutiger Name
Kategorie: Hardware / Software / Cloud / Information / Physisch
Beschreibung: Kurze Beschreibung des Zwecks
Eigner: Die Person, die für das Asset verantwortlich ist (nicht der Administrator, sondern der Business Owner)
Standort: Physischer Standort oder Cloud-Region
Schutzbedarf: Vertraulichkeit / Integrität / Verfügbarkeit (jeweils normal / hoch / sehr hoch)
Klassifizierung: Öffentlich / Intern / Vertraulich / Streng vertraulich
Status: Aktiv / In Einführung / Außer Betrieb

Baustein 4: Die CMDB (für Fortgeschrittene)

Wann du eine echte CMDB brauchst

Eine Configuration Management Database (CMDB) geht über ein einfaches Asset-Inventar hinaus. Sie erfasst nicht nur Assets, sondern auch die Beziehungen zwischen ihnen: Abhängigkeiten, Dienst-Zuordnungen und Konfigurationsdetails. In ITIL-Sprache heißen die Einträge nicht "Assets", sondern "Configuration Items" (CIs).

Du brauchst eine CMDB, wenn du mehr als 200 IT-Assets hast, wenn die Abhängigkeiten zwischen Systemen komplex sind, wenn du einen ITIL-basierten IT-Betrieb fährst oder wenn du automatisierte Impact-Analysen bei Änderungen oder Störungen brauchst.

Für kleinere Unternehmen (unter 200 IT-Assets) reicht in der Regel ein gut strukturiertes Asset-Inventar im ISMS-Tool. Die Abhängigkeiten zwischen Systemen kannst du in den Systembeschreibungen oder als Freitextfeld im Asset-Inventar dokumentieren.

CMDB aufbauen: Der pragmatische Weg

Wenn du eine CMDB aufbaust, starte nicht mit dem Anspruch, alles zu erfassen. Beginne mit den kritischen Diensten und arbeite dich von oben nach unten:

Schritt 1: Geschäftskritische Dienste identifizieren. Was sind die 10 bis 15 wichtigsten IT-Dienste für dein Unternehmen? E-Mail, ERP, CRM, Dateiablage, Webshop, Produktionssteuerung?

Schritt 2: Für jeden Dienst die unterstützenden CIs erfassen. Welche Server, Datenbanken, Netzwerkkomponenten und Software-Instanzen stecken hinter dem Dienst? Welche Abhängigkeiten gibt es zu anderen Diensten?

Schritt 3: Automatische Discovery nutzen. Tools wie Lansweeper, GLPI oder Snipe-IT können Hardware und Software im Netzwerk automatisch erkennen und inventarisieren. Das liefert eine Grundlage, die du manuell um Beziehungen und Kontextinformationen ergänzt.

Schritt 4: Verantwortlichkeiten zuordnen. Jedes CI braucht einen Verantwortlichen. Bei Diensten ist das der Service Owner, bei Infrastrukturkomponenten der IT-Betrieb.

Schritt 5: Aktualität sicherstellen. Verknüpfe die CMDB mit dem Change-Management-Prozess: Jede Änderung an der Infrastruktur muss eine Aktualisierung der CMDB nach sich ziehen. Zusätzlich periodische Abgleiche mit der automatischen Discovery.

Der Prozess dahinter: Aktualität sicherstellen

Warum die meiste IT-Dokumentation veraltet ist

Die Erstellung von IT-Dokumentation ist aufwendig, aber machbar. Das eigentliche Problem ist die Pflege. Die meisten Unternehmen erstellen einmal eine gute Dokumentation und lassen sie dann veralten, weil es keinen Prozess gibt, der die Aktualisierung sicherstellt.

Die Gründe sind immer dieselben: Die Aktualisierung hat keine Priorität im Tagesgeschäft. Es gibt keine klare Verantwortlichkeit. Die Änderung wird durchgeführt, aber die Dokumentation wird "später" angepasst, und "später" wird nie.

Prozesse für die Aktualität

Verknüpfung mit Change Management: Die wichtigste Maßnahme. Jeder Change Request enthält ein Feld "Auswirkung auf Dokumentation". Der Change wird erst als abgeschlossen betrachtet, wenn die Dokumentation aktualisiert ist. Das klingt bürokratisch, ist aber der einzige Weg, die Aktualität systematisch zu sichern.

Periodische Reviews: Einmal im Jahr wird jede Systembeschreibung vom Systemeigner auf Aktualität geprüft. Der Netzwerkplan wird einmal im Jahr gegen die Realität abgeglichen (idealerweise mit einem Discovery-Tool). Das Asset-Inventar wird mindestens einmal jährlich auf veraltete Einträge geprüft.

Automatisierung: Wo möglich, automatisiere die Datenerfassung. Netzwerk-Discovery-Tools, Asset-Management-Software und Monitoring-Systeme können Daten liefern, die automatisch in die Dokumentation einfließen. Das reduziert den manuellen Aufwand und die Fehlerquote.

Verantwortlichkeit: Für jedes Dokumentationselement gibt es einen Verantwortlichen. Nicht die IT-Abteilung als Ganzes, sondern eine konkrete Person. Diese Person ist dafür verantwortlich, dass die Dokumentation aktuell und korrekt ist.

Der Zusammenhang mit dem ISMS

Dokumentation als Input für die Risikobewertung

Die IT-Dokumentation ist der zentrale Input für die Risikobewertung im ISMS. Ohne aktuelles Asset-Inventar kannst du keine vollständige Risikobewertung durchführen, weil du nicht weißt, welche Assets existieren. Ohne Netzwerkplan kannst du Netzwerkrisiken nicht bewerten, weil du die Angriffswege nicht siehst. Ohne Systembeschreibungen kannst du die Auswirkung eines Ausfalls nicht einschätzen, weil du die Abhängigkeiten nicht kennst.

Dokumentation als Nachweis im Audit

Ein Auditor wird nach dem Asset-Inventar fragen, nach dem Netzwerkplan und nach Systembeschreibungen für kritische Systeme. Er wird prüfen, ob die Dokumentation aktuell ist und ob die erfassten Informationen mit der Realität übereinstimmen. Eine gut gepflegte IT-Dokumentation hinterlässt einen positiven Eindruck und beschleunigt den Audit erheblich.

Dokumentation als Grundlage für Notfälle

Im Notfall ist Dokumentation überlebenswichtig. Wenn ein Systemadministrator nicht erreichbar ist und ein kritisches System ausfällt, braucht der Vertreter Informationen: Auf welchem Server läuft das System? Wie ist der Recovery-Prozess? Welche Abhängigkeiten gibt es? Wer ist der Ansprechpartner beim Hoster? Jede Minute, die in einem Notfall mit Suchen statt mit Handeln verbracht wird, kostet.

Praxisfahrplan: IT-Dokumentation in 8 Wochen aufbauen

Woche 1-2: Netzwerkplan erstellen. Logischen Netzwerkplan zeichnen, Segmente, Firewalls, Internetanbindung, VPN, Standortverbindungen erfassen. Ergebnis: Ein Diagramm, das die IT-Landschaft auf einer Seite zeigt.

Woche 3-4: Asset-Inventar aufbauen. Alle relevanten Assets erfassen: Hardware, Software, Cloud-Dienste. Pflichtfelder befüllen (Bezeichnung, Kategorie, Eigner, Schutzbedarf). In ISMS Lite lässt sich das Asset-Inventar direkt mit Risikobewertung und Maßnahmen verknüpfen, sodass die IT-Dokumentation von Anfang an ins ISMS integriert ist. Ergebnis: Ein vollständiges Asset-Inventar mit Eignerzuordnung.

Woche 5-6: Systembeschreibungen für kritische Systeme. Die 10 bis 15 kritischsten Systeme dokumentieren: Zweck, Architektur, Abhängigkeiten, Schutzbedarf, Sicherheitsmaßnahmen. Ergebnis: Systembeschreibungen, die als Grundlage für die Risikobewertung dienen.

Woche 7: Prozesse für die Aktualität definieren. Change-Management-Integration, periodische Reviews, Verantwortlichkeiten. Ergebnis: Ein dokumentierter Prozess, der die Aktualität langfristig sicherstellt.

Woche 8: Review und Freigabe. Netzwerkplan, Asset-Inventar und Systembeschreibungen im Team prüfen, Lücken schließen, Freigabe durch IT-Leitung.

Acht Wochen für eine grundlegende IT-Dokumentation klingt ambitioniert, ist aber realistisch, wenn eine Person etwa 50 Prozent ihrer Arbeitszeit dafür einsetzen kann und die Zuarbeit aus der IT-Abteilung gesichert ist. Das Ergebnis ist kein Meisterwerk der Dokumentationskunst, aber eine solide Grundlage, die du kontinuierlich verbessern kannst.

Weiterführende Artikel

IT-Dokumentation Netzwerkplan CMDB Asset-Management ISMS ISO 27001 IT-Betrieb