Stille Zuständigkeiten machen alte Systeme riskant

Alte Systeme fallen im IT-Betrieb oft erst dann auf, wenn sie plötzlich nicht mehr laufen, ein Zertifikat abläuft, ein Hersteller keine Updates mehr liefert oder nur noch eine Person weiß, wie ein Fehler behoben wird. Bis dahin wirken sie unspektakulär. Sie bekommen weniger Tickets als neue Anwendungen, werden selten verändert und stehen im Alltag scheinbar stabil im Hintergrund.

Genau diese Ruhe kann trügen. Ein System wird nicht sicherer, nur weil es lange funktioniert. Für ITSM und IT-Management entsteht ein Risiko, wenn alte Anwendungen, Server, Schnittstellen oder Geräte zwar weiter gebraucht werden, aber keine klare Zuständigkeit, keine sichtbare Restlaufzeit und keinen geübten Notfallweg mehr haben.

Der kritische Punkt ist nicht nur das Alter

Nicht jedes alte System ist automatisch ein Problem. Manche Anwendungen laufen bewusst langfristig, weil sie einen spezialisierten Prozess tragen oder aus guten Gründen nicht ständig verändert werden. Kritisch wird es, wenn die Organisation nicht mehr sauber erklären kann, wofür das System gebraucht wird, welche Daten es verarbeitet, wer es fachlich verantwortet und wer im Störungsfall entscheiden darf.

Das britische National Cyber Security Centre beschreibt veraltete Produkte als Systeme, die nicht mehr ausreichend unterstützt werden und deshalb besondere Schutzmaßnahmen brauchen. Für den Betrieb heißt das in Alltagssprache: Ein alter Server, ein altes Betriebssystem oder eine veraltete Anwendung darf nicht nur technisch betrachtet werden. Es braucht eine Entscheidung, ob das System ersetzt, isoliert, besonders überwacht oder bewusst weiterbetrieben wird.

Inventar ohne Verantwortung hilft nur halb

Viele Organisationen führen Listen über Hardware, Software oder Verträge. Diese Listen sind wichtig, reichen aber nicht aus. Ein Inventar beantwortet oft, was vorhanden ist. Der Betrieb braucht zusätzlich Antworten auf die Fragen, warum es noch vorhanden ist, wer es freigibt, welche Abhängigkeiten daran hängen und welcher Ausfallpfad geplant ist.

IT-Asset-Management wird damit zur Brücke zwischen Technik, Serviceverantwortung und Risiko. Atlassian beschreibt IT-Asset-Management als Steuerung von IT-Beständen über ihren Lebenszyklus. Für Generalisten im ITSM ist daran vor allem der Lebenszyklus entscheidend. Ein System hat nicht nur eine Anschaffung und eine Nutzung. Es hat auch eine Phase, in der es kritisch beobachtet, abgelöst oder bewusst mit Schutzmaßnahmen weitergeführt werden muss.

Stille Zuständigkeiten sind ein Warnsignal

Ein häufiges Muster im Betrieb lautet: Jemand kennt das System noch. Diese Aussage klingt beruhigend, ist aber kein Prozess. Wenn Wissen an einzelne Personen gebunden ist, fehlen Vertretung, Nachvollziehbarkeit und Priorisierung. Wird die Person krank, wechselt die Rolle oder verlässt das Unternehmen, wird aus einem bekannten Altsystem sehr schnell ein blinder Fleck.

Darum sollte jedes alte System mindestens eine kleine Betriebsakte bekommen. Darin steht, welcher Service betroffen ist, welcher Fachbereich es nutzt, welche technischen Abhängigkeiten bestehen, welche Risiken bekannt sind und welcher nächste Entscheidungstermin gilt. Diese Akte muss kein schweres Dokument sein. Sie muss aber auffindbar, aktuell und mit einem klaren Besitzer verbunden sein.

Restlaufzeit gehört in den Servicebetrieb

Ein Altsystem ohne Restlaufzeit wird leicht zum Dauerzustand. Dann verschiebt sich jede Ablösung in das nächste Budget, jede Sicherheitsmaßnahme in das nächste Projekt und jede Dokumentation auf später. Der Betrieb arbeitet weiter, aber niemand weiß, ob das System noch drei Monate, drei Jahre oder bis zum nächsten Notfall bleiben soll.

Eine sichtbare Restlaufzeit verändert die Diskussion. Sie zwingt nicht sofort zur Abschaltung, macht aber die Entscheidung sichtbar. Für ein System kann dann zum Beispiel festgelegt werden: Betrieb bis zum Quartalsende mit erhöhter Überwachung. Weiterbetrieb für ein Jahr mit Netzwerktrennung und monatlicher Prüfung. Oder Ablösung durch einen neuen Service mit geplanter Datenmigration. Wichtig ist nicht die perfekte Formel, sondern die Verbindlichkeit.

Sicherheitsregeln brauchen einen Betriebsübersetzer

CISA betont bei Secure by Design, dass Sicherheit nicht nachträglich als Zusatz behandelt werden sollte. Für alte Systeme ist dieser Gedanke besonders relevant. Dort lassen sich Sicherheitsfunktionen oft nicht einfach nachrüsten. Deshalb muss der Betrieb übersetzen, welche Ersatzmaßnahmen möglich sind. Dazu gehören eingeschränkte Zugriffe, Segmentierung, zusätzliche Protokollierung, klare Änderungsfenster und ein getesteter Wiederanlauf.

Auch das NIST Cybersecurity Framework denkt in Funktionen wie Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen. Auf alte Systeme übertragen heißt das: Erst sichtbar machen, dann schützen, dann überwachen, dann Reaktionswege üben. Wer nur auf technische Härtung schaut, übersieht häufig die organisatorische Lücke. Wer nur auf Dokumentation schaut, übersieht den echten Betriebszustand.

Eine einfache Prüfliste für den nächsten Review

• Welcher Service hängt an dem alten System, und wer nutzt ihn wirklich?
• Wer ist fachlicher Besitzer, technischer Besitzer und Entscheidungsstelle bei Risiko?
• Welche Herstellerunterstützung, Updates oder Ersatzteile fehlen bereits?
• Welche Daten, Schnittstellen und Berechtigungen sind betroffen?
• Welche Schutzmaßnahmen gelten bis zur Ablösung?
• Welche Restlaufzeit ist beschlossen, und wann wird sie erneut geprüft?
• Wie wird ein Ausfall erkannt, eskaliert und wiederhergestellt?

Diese Fragen machen alte Systeme nicht automatisch modern. Sie verhindern aber, dass der Betrieb nur aus Erinnerung, Gewohnheit und stiller Duldung besteht. Gerade für ITSM-Generalisten ist das entscheidend, weil sie zwischen Fachbereich, Technik, Sicherheit und Management vermitteln müssen.

Fazit

Alte Systeme gehören nicht aus Prinzip abgeschaltet. Sie gehören aber sichtbar geführt. Wer Zuständigkeit, Restlaufzeit, Schutzmaßnahmen und Notfallweg dokumentiert, kann bewusst entscheiden, ob ein System noch tragbar ist. Ohne diese Klarheit bleibt das größte Risiko oft nicht die alte Technik selbst, sondern die stille Annahme, dass sich schon jemand darum kümmert.

Quellen und Stand der Prüfung: NCSC Guidance zu veralteten Produkten, CISA Secure by Design, Atlassian Überblick zu IT-Asset-Management und NIST Cybersecurity Framework. Quellen per HTTP geprüft am 10.06.2026.

Bildquelle: Pexels / https://www.pexels.com/photo/1181675/