Eine Karte der IT-Systemlandschaft erklärt, welche Anwendungen einen Geschäftsprozess unterstützen, welche Daten zwischen ihnen fließen und wer eine Abhängigkeit bestätigen kann. Sie hilft bei konkreten Fragen: Warum bleibt eine Bestellung liegen? Wo gibt es noch einen Export an den alten Dienstleister? Welche Systeme sind betroffen, wenn ein zentraler Anmeldedienst ausfällt?
Der Nutzen entsteht aus überprüften Beziehungen, nicht aus einer möglichst großen Grafik. Dieser Leitfaden führt von der Bestandsaufnahme über unterschiedliche Sichten zu einer ausgefüllten System- und Schnittstellenkarte. Als methodische Orientierung dient unter anderem der Kartierungsleitfaden der französischen Sicherheitsbehörde ANSSI. Er bietet eine schrittweise Vorgehensweise, ist aber keine allgemeine deutsche Rechtsvorschrift.
Was gehört in eine IT-Systemkarte?
Die Karte verbindet Geschäftsleistungen, Anwendungen, technische Komponenten und externe Beteiligte. Das zugrunde liegende Inventar enthält eindeutige Kennungen und prüfbare Eigenschaften. Die sichtbare Grafik zeigt jeweils nur die Beziehungen, die für eine bestimmte Entscheidung gebraucht werden. Ein einzelnes Schaubild muss daher nicht sämtliche Informationen enthalten.
| Sicht | Inhalt | Typische Arbeitsfrage |
|---|---|---|
| Geschäftssicht | Leistungen, Prozesse und verantwortliche Bereiche | Welche Aufgabe kann bei einem Ausfall nicht erledigt werden? |
| Anwendungssicht | Anwendungen, Datenbestände und Schnittstellen | Woher erhält die Buchhaltung ihre Rechnungsdaten? |
| Technische Sicht | Server, Datenbanken, Laufzeitumgebungen und Netzbeziehungen | Welche Komponenten müssen gemeinsam gewartet werden? |
| Betriebs- und Administrationssicht | Betreiber, Zugänge, Identitätsdienste und Wartungswege | Wer kann das System tatsächlich verwalten? |
Definieren Sie die verwendeten Begriffe. Eine Anwendung ist nicht automatisch gleichbedeutend mit einem Server; ein externer Cloud-Dienst kann aus mehreren Komponenten bestehen. Wenn ein Fachbereich „Kundenportal“ sagt, sollte er dieselbe Systemkennung meinen wie der IT-Betrieb. Ein gepflegtes Namensverzeichnis verhindert doppelte Einträge und scheinbar getrennte Systeme, die tatsächlich dasselbe meinen.
1. Mit einer konkreten Frage und einem begrenzten Umfang beginnen
Legen Sie fest, welche Entscheidung die erste Kartierung ermöglichen soll. Für eine neue Auftragsabwicklung kann der Weg von der Anfrage bis zur Rechnungsstellung genügen. Für einen Wiederanlaufplan müssen zusätzlich Anmeldung, Netz, Sicherung und externe Betriebsabhängigkeiten sichtbar werden. Schreiben Sie die Grenze ausdrücklich auf.
Benennen Sie Personen aus Fachbereich, Betrieb, Sicherheit und Datenschutz, die Informationen beitragen können. Eine Person koordiniert das Inventar, muss aber nicht jede technische Angabe selbst bestätigen. Die organisatorischen Zuständigkeiten sollten zur Informationssicherheitsrichtlinie passen.
Ein geeigneter Startvermerk lautet: „Die erste Version beschreibt die Verarbeitung einer Kundenbestellung vom Portal bis zur Rechnung. Enthalten sind Produktivsysteme, aktive Schnittstellen, Anmeldung und Hosting. Entwicklungsumgebungen werden zunächst nur aufgenommen, soweit sie Produktivdaten erhalten.“ Damit ist erkennbar, was noch fehlt und welche Aussage die Karte bereits ermöglichen kann.
2. Bestandsquellen zusammenführen und Unsicherheit markieren
Nutzen Sie vorhandene Inventare, Verträge, Betriebsdokumentation und Gespräche mit Fachbereichen. Ein Netzwerkscan kann technische Geräte zeigen, erfasst aber nicht zwangsläufig einen eigenständig beschafften SaaS-Dienst oder einen manuellen Tabellenexport. Eine Einkaufsliste zeigt wiederum nicht, ob eine alte Anwendung noch aktiv ist.
Erfassen Sie für jeden Eintrag mindestens Kennung, Funktion, fachlichen Eigentümer, technischen Betreiber, Betriebsstatus und Quelle der Information. Ergänzen Sie die Datenkategorien, den Hosting-Kontext und wichtige Schnittstellen. Geheimnisse, private Schlüssel oder produktive Zugangsdaten gehören nicht in dieses Inventar.
Kennzeichnen Sie Angaben als bestätigt, plausibel oder offen. „Hosting-Region laut Vertrag“ und „tatsächlich geprüfter Supportzugriff“ sind unterschiedliche Aussagen. Eine offene Information darf sichtbar bleiben, wenn eine verantwortliche Person und ein Klärungstermin zugeordnet sind. Unsicherheit zu verstecken macht die Karte scheinbar vollständig, aber für Entscheidungen unzuverlässig.
Verwenden Sie eine feste Kennung auch dann weiter, wenn der Anzeigename einer Anwendung wechselt. Dadurch bleiben Schnittstellen und ältere Nachweise nachvollziehbar. Bei tatsächlich abgelösten Systemen dokumentieren Sie den Status, statt deren Existenz aus der Geschichte zu entfernen.
3. Schnittstellen als eigene Objekte beschreiben
Eine Pfeilverbindung mit dem Wort „Daten“ reicht selten aus. Notieren Sie für jeden Fluss Quelle, Ziel, Richtung, Zweck, Auslöser, übertragene Datenkategorien, technische Verantwortlichkeit und Verhalten bei Fehlern. Unterscheiden Sie einen regelmäßigen automatischen Export von einer gelegentlichen manuellen Weitergabe.
Die Richtung ist wichtig: Ein Portal kann Bestellungen an ein Warenwirtschaftssystem senden und getrennt davon Lieferstatus zurückerhalten. Das sind unterschiedliche Flüsse mit möglicherweise anderen Berechtigungen und Fehlerfolgen. Eine doppelseitige Linie kann diese Unterschiede verdecken.
Erfassen Sie auch Zwischenstationen. Eine Datei kann zunächst in einem gemeinsamen Ablagebereich liegen, bevor ein Dienstleister sie abholt. Dieser Speicherort hat eigene Zugriffs- und Löschfragen. Für die Prüfung unnötiger Felder lässt sich die Karte mit der Datenminimierung auf Feldebene verbinden.
4. Ausgefülltes Beispiel: Bestellung bis Rechnung
Das folgende Beispiel ist fiktiv. Ein Handelsunternehmen nimmt Bestellungen im Kundenportal an, bearbeitet sie in einer Warenwirtschaft und erstellt Rechnungen in einer separaten Finanzanwendung. Die Bezeichnungen beschreiben Funktionen, keine behaupteten Eigenschaften realer Produkte.
| System | Aufgabe und Daten | Zuständigkeit | Wichtige Abhängigkeit |
|---|---|---|---|
| APP-01 Kundenportal | Bestellannahme; Kontakt- und Lieferdaten, Artikel, Bestellnummer | Vertrieb fachlich, Plattformteam technisch | Hosting und Schnittstelle FL-01 |
| APP-02 Warenwirtschaft | Prüfung, Vorbereitung und Status der Bestellung | Auftragsservice fachlich, Anwendungsteam technisch | Zentrale Mitarbeiteranmeldung und FL-01 |
| APP-03 Finanzanwendung | Rechnung und Zahlungszuordnung | Finanzabteilung fachlich, Finanz-IT technisch | Rechnungsdatenfluss FL-02 |
| ID-01 Identitätsdienst | Anmeldung der Beschäftigten | IT-Betrieb | Erreichbarkeit und registrierte Anmeldefaktoren |
Die vereinfachte Anwendungssicht lautet: Kundenportal → Warenwirtschaft → Finanzanwendung. Der Identitätsdienst verbindet sich zusätzlich mit den internen Anwendungen. Er ist kein Teil der fachlichen Bestellkette, kann aber deren Bearbeitung dennoch unterbrechen.
Der ausgefüllte Flusseintrag FL-01 lautet: „Quelle APP-01, Ziel APP-02; Auslöser bestätigte Bestellung; übertragen werden Bestellnummer, Artikelpositionen, erforderliche Kontakt- und Lieferangaben. Bei Nichterreichbarkeit des Zielsystems bleibt die Bestellung im Portal im Status Warteschlange. Die Wiederholung nutzt dieselbe eindeutige Bestellkennung, damit die Verarbeitung auf doppelte Übernahme geprüft werden kann. Verantwortlich für die technische Fehleranalyse ist das Anwendungsteam; der Auftragsservice bewertet verzögerte Aufträge.“
FL-02 wird separat beschrieben: „Quelle APP-02, Ziel APP-03; Auslöser freigegebene Rechnungsstellung; übertragen werden die erforderlichen Rechnungsdaten. Ein Fehler blockiert im Beispiel die Rechnungserstellung, nicht die bereits erfolgte Annahme der Bestellung. Die Finanzabteilung erhält eine nachvollziehbare Liste offener Übertragungen.“ Diese Trennung verhindert, dass eine allgemeine Meldung „Schnittstelle gestört“ unterschiedliche betriebliche Folgen verdeckt.
5. Einen Vorgang mit Fachbereich und Betrieb durchgehen
Validieren Sie die Karte anhand eines konkreten, dafür geeigneten Vorgangs. Lassen Sie den Fachbereich erklären, was er im System sieht, und den Betrieb zeigen, welche Übertragung dazu gehört. Prüfen Sie, ob die beschriebenen Datenkategorien tatsächlich stimmen. Nutzen Sie für Demonstrationen nach Möglichkeit Testdaten und begrenzen Sie erforderliche Einsicht in echte personenbezogene Daten.
Im Beispiel wird eine Testbestellung angenommen und ihre eindeutige Kennung durch beide Schnittstellen verfolgt. Das Team kontrolliert, ob die Rechnung zu genau diesem Vorgang gehört und ob ein wiederholter Übertragungsversuch keine zweite Bestellung erzeugt. Ein geplanter Fehlerfall wird in einer geeigneten Umgebung geprüft, ohne den laufenden Betrieb ungeplant zu unterbrechen.
Das Logkonzept hilft, die richtigen Ereignisquellen zu bestimmen. Die Karte muss nicht vollständige Protokolle enthalten; sie sollte erklären, wo berechtigte Personen die für eine Untersuchung nötigen Informationen finden. Prüfen Sie auch den Ausfall der Protokollierung selbst, damit ein fehlender Eintrag nicht vorschnell als Beweis für einen nie erfolgten Vorgang gilt.
6. Systemkarte und Verarbeitungsverzeichnis verknüpfen
Eine Systemkarte organisiert technische Komponenten. Das Verzeichnis von Verarbeitungstätigkeiten beschreibt dagegen Verarbeitungen mit ihren Zwecken und den gesetzlichen Angaben. Die DSGVO, insbesondere Artikel 30 und 32, ist der rechtliche Bezugspunkt für Dokumentation und angemessene Sicherheit; eine Grafik allein erfüllt diese Pflichten nicht.
Bei Finanzunternehmen muss vor der Zuordnung regulatorischer Nachweise die Abgrenzung von DORA und NIS2 geklärt sein; eine gemeinsame Systemliste legt den gesetzlichen Anwendungsbereich nicht fest.
Ordnen Sie deshalb einer Verarbeitung mehrere Systemkennungen zu, wenn sie tatsächlich mehrere Anwendungen nutzt. Umgekehrt kann eine Anwendung mehrere Zwecke unterstützen. Eine Kundenverwaltung kann der Vertragsabwicklung und einer gesonderten Werbenutzung dienen. Nur eine Zeile mit dem Produktnamen verdeckt diese Unterschiede.
Prüfen Sie bei externen Beteiligten außerdem die Abgrenzung zwischen Verantwortlichem und Auftragsverarbeiter. Ein technischer Pfeil entscheidet die rechtliche Rolle nicht. Die tatsächliche Tätigkeit, vertragliche Organisation und Entscheidungsbefugnis sind gesondert zu bewerten. Bei möglichen Drittlandzugriffen ist auch der konkrete Empfänger- und Zugriffskontext zu klären.
7. Erkenntnisse in begrenzte Maßnahmen übersetzen
Eine zweite fiktive Feststellung könnte sein, dass ein alter Export noch an eine abgelöste Dienstleisterumgebung sendet. Entfernen Sie nicht einfach die Linie aus der Grafik. Zuerst bestätigt der Fachbereich, ob der Fluss noch gebraucht wird. Danach prüft der Betrieb die tatsächliche Verbindung, die übertragenen Daten und die Folgen einer Abschaltung.
Wenn die Stilllegung freigegeben wird, umfasst der Auftrag Verbindung, Berechtigung, verbleibende Daten und Nachkontrolle. Dokumentieren Sie anschließend den tatsächlichen Zustand. Eine geplante Abschaltung darf nicht als bereits wirksame Schutzmaßnahme erscheinen.
Bei Ausfallrisiken führt die Karte zur Frage, welche Systeme in welcher Reihenfolge zurückkehren müssen. Der Wiederherstellungsplan für Backups muss solche Abhängigkeiten berücksichtigen. Eine wiederhergestellte Datenbank hilft nicht vollständig, wenn die Anwendung oder der benötigte Anmeldedienst weiterhin fehlt.
8. Pflege und Zugriff festlegen
Verknüpfen Sie Änderungen mit bestehenden Abläufen: neue Anwendung, neue Schnittstelle, Wechsel des Betreibers, zusätzliche Datenkategorie, geänderte Anmeldung oder Stilllegung. Der jeweilige Änderungsauftrag sollte die Kartenpflege auslösen und eine verantwortliche Person nennen. Ergänzende regelmäßige Durchsichten helfen, nicht gemeldete Veränderungen zu finden; das Intervall ist anhand des eigenen Betriebs zu wählen.
Wählen Sie das Werkzeug anhand eines kleinen Arbeitsszenarios: System anlegen, Fluss beschreiben, Eigentümer ändern, veraltete Angabe markieren und eine verständliche Ansicht exportieren. Eine Tabelle mit gepflegten Kennungen kann für einen kleinen Umfang ausreichen. Bei komplexen Beziehungen ist ein geeigneteres Modell hilfreich, sofern das Team es tatsächlich warten kann.
Begrenzen Sie den Zugriff auf technische Detailansichten. Für eine Leitungsvorlage sind interne Adressen und Administrationswege meist nicht erforderlich. Unterschiedliche Sichten erlauben verständliche Zusammenarbeit, ohne jedem Empfänger eine vollständige Sicherheitsarchitektur offenzulegen.
Häufige Fragen
Ist die Systemkarte dasselbe wie das Verarbeitungsverzeichnis? Nein. Die Karte beschreibt Komponenten und Beziehungen, das Verzeichnis die personenbezogenen Verarbeitungen. Beide lassen sich über eindeutige Kennungen verbinden.
Muss zunächst jedes Gerät bekannt sein? Nicht für jede erste Anwendungssicht. Der definierte Umfang muss aber die benötigte Aussage tragen. Fehlende Abhängigkeiten und ausgeschlossene Bereiche sind sichtbar zu dokumentieren.
Wann ist eine Karte einsatzbereit? Wenn die wesentlichen Beteiligten den dargestellten Ablauf bestätigen können, offene Punkte zugeordnet sind und ein Pflegeprozess besteht. Eine schöne Grafik ohne überprüfte Flüsse erfüllt diesen Zweck noch nicht.