Die NIS2-Richtlinie ist seit Oktober 2024 in deutsches Recht umgesetzt. Wer als Unternehmen in den Anwendungsbereich fällt – und das sind deutlich mehr als früher –, kommt an einer Frage nicht vorbei: Welche unserer IT-Systeme sind vorhanden, wer ist dafür verantwortlich, und wie kritisch sind sie?
Die Antwort auf diese Frage heißt: Applikationsliste. Oder genauer: ein strukturiertes, aktuelles Inventar eurer Anwendungslandschaft.
Dieser Artikel erklärt, was eine NIS2-konforme Applikationsliste enthalten muss, wie ihr sie systematisch aufbaut – und warum das größte Problem nicht das Erstellen, sondern das Aktuell-Halten ist.
Was NIS2 konkret fordert
Art. 21 der NIS2-Richtlinie verpflichtet betroffene Unternehmen zu einem umfassenden Risikomanagement für Netz- und Informationssysteme. Konkret bedeutet das unter anderem:
- Inventarisierung der eingesetzten Systeme und Anwendungen
- Identifikation kritischer Systeme und Bewertung ihrer Ausfallfolgen
- Dokumentation von Verantwortlichkeiten
- Erfassung von Lieferanten und Dienstleistern mit Zugang zu kritischen Systemen
Keine dieser Anforderungen kann erfüllt werden, wenn ihr nicht wisst, welche Systeme ihr überhaupt betreibt. Die Applikationsliste ist damit kein Nice-to-have – sie ist die Basis, auf der alle anderen NIS2-Maßnahmen aufbauen.
Die sechs Pflichtfelder einer NIS2-konformen Applikationsliste
Nicht jedes Feld, das theoretisch dokumentiert werden könnte, ist für NIS2 relevant. Konzentriert euch auf das, was Prüfer tatsächlich sehen wollen:
1. Systemname und eindeutige Kennung
Jede Applikation braucht einen klaren, eindeutigen Namen. Vermeidet intern gebräuchliche Kürzel ohne Erklärung – „SAP ERP (Produktivsystem DE)", nicht „SAPEP1".
2. Systemkategorie und Kritikalitätsbewertung
NIS2 unterscheidet zwischen kritischen und wichtigen Systemen. Für jede Applikation muss dokumentiert sein: Was passiert bei einem Ausfall? Ist die Applikation für Kernprozesse des Unternehmens notwendig?
3. Technischer Betreiber (interner Verantwortlicher)
Wer ist für den Betrieb, die Aktualisierung und die Verfügbarkeit der Applikation verantwortlich? Diese Person muss namentlich und erreichbar sein – nicht nur als Rollenbezeichnung.
4. Fachlicher Verantwortlicher (Business Owner)
Wer im Fachbereich ist für die inhaltliche Nutzung verantwortlich? Bei einem Ausfall dieser Applikation: wen alarmiert ihr zuerst?
5. Datenklassifikation
Verarbeitet die Applikation personenbezogene Daten (DSGVO-relevant)? Gesundheitsdaten? Finanzdaten? Betriebsgeheimnisse? Diese Klassifikation bestimmt, welche Schutzmaßnahmen greifen müssen.
6. Externe Dienstleister mit Systemzugang
NIS2 fordert ausdrücklich die Dokumentation von Lieferketten-Risiken. Wer hat Zugriff auf eure kritischen Systeme? Cloud-Anbieter, Wartungsdienstleister, Integratoren?
Von der Excel-Tabelle zur strukturierten Liste
Die meisten IT-Teams im Mittelstand haben diese Informationen irgendwo – verteilt über Excel-Tabellen, OneNote-Seiten, SharePoint-Dokumente und das Gedächtnis langjähriger Kollegen.
Der Aufbau einer NIS2-konformen Applikationsliste bedeutet nicht, von vorne zu beginnen. Es bedeutet, vorhandene Informationen zu strukturieren und an einem Ort zu konsolidieren.
Praktischer Einstieg:
- Exportiert eure bestehende Excel-Tabelle (oder erstellt eine Spaltenstruktur mit den sechs Feldern oben)
- Füllt die bekannten Felder für jede Applikation aus
- Markiert explizit, was noch unklar ist – Lücken sichtbar zu machen ist besser als sie zu verstecken
- Verteilt die offenen Fragen an die jeweiligen Verantwortlichen
Wenn ihr ein Tool nutzt, das diesen CSV-Import übernimmt, spart ihr die manuelle Dateneingabe. Das Ergebnis: eine erste Version eurer Applikationsliste in wenigen Stunden statt in Wochen.
Das eigentliche Problem: Aktualität
Die meisten Mittelstand-IT-Teams schaffen es, eine erste Version ihrer Applikationsliste zu erstellen. Das eigentliche Problem kommt danach: Systeme ändern sich. Verantwortlichkeiten wechseln. Externe Dienstleister kommen und gehen. Sechs Monate nach der Ersterfassung stimmt die Liste nicht mehr vollständig.
Eine NIS2-Anforderung ist aber keine einmalige Pflichtübung. Die Dokumentation muss laufend aktuell gehalten werden. Das bedeutet konkret:
- Regelmäßige Review-Zyklen pro Applikation (z. B. alle 12 Monate oder bei signifikanten Änderungen)
- Automatische Benachrichtigungen, wenn Einträge seit einer definierten Zeit nicht aktualisiert wurden
- Versionierung von Änderungen, damit bei einem Audit nachweisbar ist, wann welche Informationen gepflegt wurden
Ein manueller Kontrollprozess ist bei 30, 50 oder 100 Applikationen nicht praktikabel. Wer die Aktualität dauerhaft sichern will, braucht einen automatisierten Mechanismus – nicht noch eine Erinnerungs-E-Mail in einem geteilten Kalender.
Wer ist betroffen?
NIS2 weitet den Kreis der betroffenen Unternehmen gegenüber NIS1 erheblich aus. Grob betroffen sind Unternehmen ab 50 Mitarbeitern oder 10 Millionen Euro Jahresumsatz in relevanten Sektoren, darunter:
- Energie, Wasser, Abwasser, Verkehr, Gesundheit (KRITIS-Kernbereiche)
- Digitale Infrastruktur und Cloud-Dienste
- Lebensmittelproduktion und -verarbeitung ab bestimmten Größen
- Chemie, verarbeitendes Gewerbe (Manufacturing) und Zulieferer dieser Sektoren
Selbst wenn euer Unternehmen nicht direkt unter NIS2 fällt: Wer an KRITIS-Betreiber liefert oder mit ihnen vernetzt ist, wird zunehmend mit den gleichen Anforderungen konfrontiert – als Teil der Lieferkettendokumentation.
Fazit
Eine NIS2-konforme Applikationsliste ist keine überwältigende Aufgabe – sie erfordert sechs klare Felder pro System, einen strukturierten Aufbau, und einen Prozess, der Aktualität dauerhaft sichert.
Der häufigste Fehler: die Erstellung als einmaliges Projekt zu behandeln. Wer die Pflege als Teil des laufenden IT-Betriebs verankert, hat nicht nur NIS2 unter Kontrolle – sondern gewinnt nebenbei den Überblick, den jedes IT-Team jeden Tag braucht.
Mehr zur praktischen Umsetzung im Leitstand-Handbuch (öffnet in neuem Tab) oder im Vergleich NIS2 mit Leitstand.