Legacy-Systeme als Governance-Risiko unter NIS-2, ISO/IEC 27001:2022 und BSI-Grundschutz++

Mit der zunehmenden Verzahnung von IT- und OT-Landschaften verschiebt sich der Maßstab, nach dem technische Systeme bewertet werden, grundlegend. In heutigen Prüf-, Aufsichts- und Haftungsregimen ist nicht mehr ausschlaggebend, wann ein System entstanden ist oder warum es so betrieben wird. Entscheidend ist allein, ob sein Betrieb beherrscht, überblickt und verantwortet werden kann.

Genau an diesem Punkt wird die Aussage „Das war historisch so“ zum Problem. In Audits fungiert sie nicht als Erklärung, sondern als Eingeständnis fehlender Steuerung. Sie signalisiert, dass Risiken nicht aktiv entschieden, sondern aus der Vergangenheit übernommen wurden – ohne klare Zuständigkeit, ohne überprüfbare Kontrolle, ohne belastbare Abwägung. Unter den heute maßgeblichen Regimen – insbesondere NIS-2, ISO/IEC 27001:2022 und BSI-Grundschutz++ – ist diese Form der unbewussten Risikoübernahme nicht mehr anschlussfähig. Historie rechtfertigt keinen Betrieb. Steuerungsfähigkeit legitimiert ihn.

Dieser Beitrag richtet sich an CISOs, ISBs und Entscheidungsträger auf Leitungs- und Aufsichtsebene. Er analysiert keine Einzeltechnologien und keine spezifischen Protokolle, sondern eine ganze Systemklasse: historisch gewachsene Systeme, deren Funktionsweise sich dem modernen Anspruch an Auditierbarkeit, Verantwortungszuordnung und Governance strukturell entzieht. Systeme, die nicht per se „unsicher“ sind, deren Betrieb aber unter heutigen Regimen nur noch dann vertretbar ist, wenn er bewusst entschieden, klar begrenzt und dauerhaft verantwortet wird.

Architektonische Ausgangslage historischer Systeme

Die sicherheitstechnische Schwäche historischer Systeme liegt nicht primär in einzelnen fehlenden Schutzmechanismen, sondern in ihrer impliziten Architekturlogik. Viele dieser Systeme wurden in Umgebungen entworfen, in denen Kontrolle nicht explizit modelliert, sondern vorausgesetzt wurde. Vertrauen war kein zu verwaltender Zustand, sondern eine Grundeigenschaft des Netzes. Betrieb bedeutete Funktion, nicht Governance.

In dieser Logik existiert Identität nicht als eigenständiges, dauerhaft überprüfbares Konstrukt, sondern als situative Eigenschaft der Verbindung. Wer Zugriff erhält, ist der Akteur. Sitzung, Berechtigung und Handlung fallen in einem technischen Moment zusammen. Sicherheitsrelevante Aktionen entstehen nicht als bewusst autorisierte Vorgänge, sondern als unmittelbare Folge der Erreichbarkeit eines Systems. Kontrolle ist kein vorgelagerter Entscheidungsprozess, sondern folgt bestenfalls nachträglich als Beobachtung.

Diese Struktur erzeugt ein fundamentales Spannungsfeld zu heutigen Governance-Modellen. Moderne Regime verlangen nicht nur, dass Handlungen nachvollzogen werden können, sondern dass sie vor ihrer Ausführung eindeutig zugeordnet, bewusst erlaubt und organisatorisch verantwortet sind. Verantwortung ist dabei kein abstrakter Begriff, sondern eine konkrete Zuordnung von Entscheidungs- und Haftungslinien. Genau diese Zuordnung unterlaufen viele historische Architekturen systematisch.

Der entscheidende Punkt ist dabei: Diese Systeme sind nicht „unsicher“ im klassischen Sinne. Sie funktionieren oft stabil, vorhersehbar und technisch zuverlässig. Ihre Inkompatibilität liegt auf einer anderen Ebene. Sie lassen sich nicht ohne Weiteres in Modelle integrieren, die auf expliziter Autorisierung, rollenbasierter Trennung, revisionssicherer Nachvollziehbarkeit und kontrollierter Eskalation beruhen. Versuche, diese Eigenschaften nachträglich aufzusetzen, führen häufig dazu, dass entweder die Funktionalität eingeschränkt oder die Governance nur simuliert wird.

Damit wird deutlich, warum klassische Härtungsmaßnahmen an dieser Stelle an ihre Grenzen stoßen. Das Problem ist nicht, dass einzelne Kontrollen fehlen, sondern dass die Architektur selbst keine Trennlinien kennt, an denen Governance sinnvoll ansetzen könnte. Wo Identität, Zugriff und Ausführung technisch ununterscheidbar sind, bleibt Kontrolle zwangsläufig fragmentarisch. Aus Sicht moderner Prüf- und Aufsichtsregime ist dies kein Implementierungsdefizit, sondern eine strukturelle Design-Inkompatibilität.

Diese Inkompatibilität ist der Ausgangspunkt für alle weiteren Fragen zur Auditierbarkeit, Risikobewertung und Verantwortlichkeit. Sie erklärt, warum sich viele Organisationen in Audits argumentativ im Kreis drehen – und warum der Rückgriff auf Historie so oft als letzte, aber nicht mehr tragfähige Begründung herangezogen wird.

Auditierbarkeit versus Rekonstruktion

An diesem Punkt verschiebt sich die Diskussion in Audits häufig unmerklich – und genau hier entsteht der eigentliche Konflikt. Wenn Organisationen auf die eingeschränkte Steuerungsfähigkeit historischer Systeme angesprochen werden, reagieren sie oft mit dem Verweis auf vorhandene Logfiles, Ticketsysteme, Change-Protokolle oder Betriebsdokumentationen. Formal entsteht so der Eindruck von Nachvollziehbarkeit. In der Sache liegt jedoch ein grundlegender Kategorienfehler vor.

Auditierbarkeit bedeutet nicht, dass sich ein Geschehen im Nachhinein plausibel erzählen lässt. Auditierbarkeit setzt voraus, dass sicherheitsrelevante Handlungen kausal, zeitnah und eindeutig einem verantwortlichen Akteur zugeordnet werden können – und zwar auf Basis technischer Tatsachen, nicht interpretativer Annahmen. Sie ist eine Eigenschaft des Systems im Betrieb, nicht der Dokumentation im Rückblick.

Rekonstruktion hingegen ist ein forensischer Notbehelf. Sie versucht, aus fragmentierten Spuren, Kontextwissen und organisatorischen Annahmen ein Bild dessen zu erzeugen, was vermutlich geschehen ist. Diese Rekonstruktion kann im Incident-Response wertvoll sein, ersetzt jedoch keine belastbare Steuerungs- und Kontrollfähigkeit. Wo Identität, Zugriff und Ausführung technisch nicht sauber getrennt sind, bleibt jede Rekonstruktion zwangsläufig mehrdeutig.

Genau dieses Muster zeigt sich bei vielen historisch gewachsenen Systemen. Sie erzeugen Ereignisspuren ohne verlässliche Identitätsbindung, ohne konsistenten Sitzungskontext und ohne klare Trennung zwischen legitimer Handlung und Missbrauch. Verantwortung entsteht nicht aus dem System selbst, sondern wird organisatorisch nachträglich zugewiesen. Für moderne Governance-Regime ist das unzureichend.

Unter ISO/IEC 27001:2022 ist ein Risiko nur dann bewertbar, wenn es messbar, steuerbar und in seinem Wirkmechanismus verstanden ist. Fehlt diese Grundlage, ist auch eine formale Risikoakzeptanz inhaltlich angreifbar, weil sie sich nicht auf überprüfbare Tatsachen stützt. Unter NIS-2 verschärft sich dieser Befund weiter: Ein Risiko, das weder technisch kontrollierbar noch organisatorisch eindeutig verantwortbar ist, kann nicht als „angemessen behandelt“ gelten – unabhängig davon, wie lange es bereits existiert.

Damit wird deutlich, warum sich viele Auditgespräche an genau diesem Punkt zuspitzen. Die Vorlage von Dokumentation ersetzt keine fehlende Auditierbarkeit. Sie verschiebt das Problem lediglich zeitlich nach hinten – und im Ernstfall die Beweislast nach oben. Wo Systeme nur Rekonstruktion erlauben, aber keine echte Zuordnung, entsteht ein Governance-Vakuum, das in modernen Aufsichts- und Haftungsregimen nicht mehr durch Verweise auf Historie geschlossen werden kann.

Patch-Realität und Governance-Schuld

Ein zentraler Irrtum in der Bewertung historisch gewachsener Systeme liegt in der Annahme, sie ließen sich durch klassische Wartungs-, Update- und Patch-Zyklen hinreichend kontrollieren. Diese Logik stammt aus modernen IT-Produktlandschaften, greift aber bei Legacy-Systemen strukturell zu kurz. Viele dieser Komponenten existieren faktisch außerhalb zeitgemäßer Software-Lifecycle-Modelle. Quellcode wird über Jahre oder Jahrzehnte nicht mehr verändert, systematische Reviews finden nicht statt, und sicherheitsrelevante Korrektionen erfolgen – wenn überhaupt – ausschließlich reaktiv, oft erst nach externer Offenlegung oder regulatorischem Druck.

Damit fehlt eine grundlegende Voraussetzung moderner Governance: die Annahme kontinuierlicher Pflege und technischer Steuerbarkeit. Historische Systeme sind nicht „schlecht gepflegt“, sondern nicht mehr pflegbar im Sinne heutiger Sicherheitsmodelle. Wartbarkeit wird zur Fiktion, Patchfähigkeit zur theoretischen Möglichkeit ohne operative Verlässlichkeit.

In Embedded-, Industrie- und OT-Umgebungen verschärft sich diese Situation erheblich. Firmware-Stände sind häufig zertifiziert, statisch eingebettet oder an regulatorische Freigaben gebunden. Änderungen ziehen neue Zertifizierungen, Stillstände oder Haftungsfragen nach sich und sind betrieblich oft nicht durchsetzbar. In der Praxis bedeutet dies: Selbst bekannte Schwachstellen bleiben über Jahre bestehen, weil ein Update zwar technisch denkbar, organisatorisch oder regulatorisch jedoch nicht realisierbar ist.

Patchbarkeit wird unter diesen Bedingungen zu einem Zufallsereignis, nicht zu einem belastbaren Sicherheitsmechanismus. Sie hängt weniger von Risikoabwägung als von externen Faktoren ab – Herstellerverhalten, Ersatzteilverfügbarkeit, Wartungsfenstern oder Aufsichtsentscheidungen. Für Governance-Regime, die auf planbarer Risikobehandlung beruhen, ist das hochproblematisch.

Aus dieser Diskrepanz entsteht eine Governance-Schuld. Sie unterscheidet sich fundamental von klassischer technischer Schuld. Governance-Schuld akkumuliert unauffällig im Betrieb und offenbart sich erst im Prüf- oder Incident-Fall – dann jedoch unmittelbar auf Geschäftsführung und Leitungsebene. Denn in modernen Regimen zählt nicht, ob ein System theoretisch patchbar wäre, sondern ob sein Risiko aktiv beherrscht, begrenzt und verantwortet wird.

Wo Patchfähigkeit nicht verlässlich gegeben ist, kann sie nicht länger als Sicherheitsargument dienen. An ihre Stelle tritt die Frage nach bewusster Management-Entscheidung: Ist der Weiterbetrieb dieses Systems bekannt, begründet, begrenzt und explizit verantwortet – oder lediglich historisch fortgeschrieben? An diesem Punkt kippt die Diskussion von Technik zu Governance.

Reale Verbreitung und Expositionsdynamik

Belastbare Markt- und Feldanalysen zeigen konsistent, dass historisch gewachsene Management-, Steuerungs- und Betriebsschnittstellen weiterhin in erheblichem Umfang produktiv eingesetzt werden. Internetweite Beobachtungen über mehrere Jahre hinweg weisen dauerhaft eine hohe sechsstellige Anzahl exponierter Legacy-Dienste aus – etwa ~800.000+ offene Telnet-Server und ähnliche Management-Schnittstellen über alle Branchen hinweg. Diese Zahlen schwanken je nach Messmethode und Scanzeitpunkt, bewegen sich aber stabil in derselben Größenordnung. Das ist kein statistisches Artefakt, sondern Ausdruck einer strukturellen Realität.

Für OT- und ICS-Umgebungen verdichtet sich dieses Bild erheblich:

Besonders betroffen sind langlebige Komponenten mit Lebenszyklen von 15 bis 30 Jahren, bei denen Management- und Wartungsschnittstellen nie für moderne Audit- oder Governance-Modelle ausgelegt wurden.

Wichtig: Einordnung der Datenbasis. Es existiert keine vollständige, zentrale Inventarisierung historischer Systeme über Branchen hinweg. Die vorliegenden Zahlen ergeben sich aus der Korrelation unabhängiger Quellen: Marktstudien, Herstellerangaben, Betreibererhebungen, Incident-Analysen und internetweite Messungen. Diese erlauben keine exakte Vollerhebung, liefern jedoch ein belastbares Bild der Größenordnung, der Persistenz und vor allem der Trendrichtung.

Denn entscheidend ist nicht allein die absolute Zahl, sondern die Dynamik. Die Verbreitung historischer Systeme ist kein statischer Altbestand, der langsam verschwindet. Im Gegenteil: IT/OT-Konvergenz, zunehmende Remote-Wartung, ausgelagerter Betrieb, Fernzugriffe von Dienstleistern sowie struktureller Fachkräftemangel führen dazu, dass genau diese Systeme funktional aufgewertet werden. Schnittstellen, die ursprünglich für lokale Bedienung oder isolierte Wartung gedacht waren, rücken an sicherheitskritische Übergänge zwischen Zonen, Organisationen und Verantwortlichkeiten.

Was früher physisch getrennt war, wird logisch angebunden. Was früher implizit vertraut wurde, wird Teil verteilter Betriebsmodelle. Dadurch wächst nicht nur die klassische Angriffsfläche, sondern vor allem das Governance-Risiko: Systeme mit begrenzter Auditierbarkeit, eingeschränkter Steuerungsfähigkeit und diffuser Verantwortungszuordnung werden zu tragenden Elementen moderner Betriebsprozesse. An diesem Punkt kippt das Problem endgültig von einer historischen Altlast zu einem aktuellen Aufsichts- und Haftungsthema.

Die relevante Frage für Prüf- und Aufsichtsregime lautet daher nicht, ob solche Systeme existieren – das ist empirisch belegt –, sondern wie bewusst, transparent und verantwortet ihr Weiterbetrieb erfolgt. In dieser Verschiebung liegt der eigentliche Konflikt moderner Audits: Nicht die Existenz historischer Technik ist erklärungsbedürftig, sondern ihre unbehandelte Integration in hochregulierte Betriebsrealitäten.

Regimeübergreifende Bewertung (Stand 2026)

Vor diesem Hintergrund verdichten sich die Anforderungen der maßgeblichen Regime zu einer gemeinsamen Leitfrage: Ist der Betrieb eines Systems tatsächlich steuerbar, überprüfbar und verantwortet – oder lediglich historisch fortgeschrieben? Die Unterschiede zwischen NIS-2, ISO/IEC 27001:2022 und BSI-Grundschutz++ liegen im Detail, nicht jedoch im Grundverständnis von Governance.

NIS-2

Die NIS-2-Richtlinie (EU) 2022/2555 verankert Cybersicherheit explizit als Führungsaufgabe (Art. 20). Sie fordert angemessene, dem Stand der Technik entsprechende Risikomanagementmaßnahmen und weist die Verantwortung unmittelbar der Leitungsebene zu. In diesem Rahmen ist „historisch gewachsen“ weder eine Maßnahme noch eine zulässige Begründung. Systeme, deren Betrieb nicht aktiv gesteuert, überwacht und im Zweifel kurzfristig begrenzt oder beendet werden kann, stellen unter NIS-2 kein technisches Detailproblem dar, sondern ein potenzielles Management-Versagen.

Im Schadens- oder Aufsichtsfall entsteht daraus ein strukturelles Risiko der faktischen Beweislastumkehr: Die Organisation muss darlegen, wie trotz bekannter struktureller Defizite eine angemessene Kontrolle gewährleistet war – ein Nachweis, der ohne explizite Governance-Entscheidung regelmäßig nicht gelingt.

ISO/IEC 27001:2022

Die ISO/IEC 27001:2022 verschärft diesen Anspruch auf einer anderen Ebene. Der Fokus liegt nicht mehr primär auf der Existenz einzelner Kontrollen, sondern auf Context of the Organization, Leadership und der bewussten Behandlung von Risiken. Ein Risiko gilt nur dann als akzeptiert oder behandelt, wenn seine Ursachen, Auswirkungen und Steuerungsmechanismen nachvollziehbar sind.

Systeme, deren innere Wirkweise, Identitätslogik oder Kontrollpfade nicht transparent sind, entziehen sich dieser Bewertungslogik – und damit auch einer regulatorisch tragfähigen Behandlung. Das Risikomanagement selbst wird angreifbar: Eine formale Zertifizierung kann fehlende Steuerungsfähigkeit nicht kompensieren, sondern verschärft im Zweifel die Erwartungshaltung von Auditoren und Aufsicht.

BSI IT-Grundschutz (Fortentwicklung ab 2026)

Der BSI IT-Grundschutz durchlebt eine grundlegende Fortentwicklung ab 2026, mit einer Übergang zu einem digitalen, JSON-basierten Regelwerk (sukzessive Einführung ab Q1 2026). Diese Modernisierung zieht sich konsequent durch und konzentriert sich auf den Nachweis realer Steuerungs- und Kontrollfähigkeit statt schematischer Bausteinerfüllung – besonders bei hohem oder sehr hohem Schutzbedarf. Systeme werden nicht mehr allein danach beurteilt, ob Maßnahmen theoretisch zugeordnet werden können, sondern ob deren Sicherheitsanforderungen technisch und organisatorisch überhaupt umsetzbar sind.

Historische Systeme, die grundlegende Governance-Eigenschaften strukturell nicht unterstützen, gelten grundschutzseitig nicht als „unvollständig abgesichert“, sondern als ungeeignet – sofern ihr Weiterbetrieb nicht explizit, begründet und begrenzt entschieden wurde.

Gemeinsamer Nenner

Regimeübergreifend ergibt sich ein konsistentes Bild: Keines der aktuellen Regelwerke verlangt die sofortige Eliminierung historischer Systeme. Alle verlangen jedoch, dass deren Existenz bewusst gemanagt, ihre Defizite offen benannt und ihre Risiken auf Leitungsebene verantwortet werden. Wo dies nicht geschieht, wird Technik zum Auslöser eines Governance-Problems – mit unmittelbaren Konsequenzen für Aufsicht, Haftung und Vertrauen.

Ausblick: Der Cyber Resilience Act (CRA) und die Digitale Operationale Widerstandsfähigkeitsverordnung (DORA) für Finanzinstitute schärfen diese Anforderungen ab 2026/2027 weiter. Auch hier gilt: Legacy-Systeme sind nicht automatisch ausgeschlossen, aber ihre Governance muss explizit dokumentiert und nachweisbar sein.

Technische Zwangslagen sind keine Legitimation

In vielen Organisationen lassen sich historisch gewachsene Systeme kurzfristig nicht ersetzen. Wirtschaftliche Zwänge, regulatorische Abhängigkeiten, lange Beschaffungszyklen oder die Bindung an zertifizierte Komponenten stehen einer schnellen Ablösung entgegen. Diese Situation ist real und in IT- wie OT-Umgebungen eher die Regel als die Ausnahme. Aus Governance-Sicht ändert sie jedoch nichts an der Bewertung des Risikos. Eine technische Zwangslage erklärt einen Zustand – sie legitimiert ihn nicht.

Genau an diesem Punkt verschiebt sich die Verantwortung aus dem technischen Raum in den Governance-Raum. Sobald bekannt ist, dass ein System grundlegende Anforderungen an Steuerbarkeit, Auditierbarkeit oder Verantwortungszuordnung nicht erfüllt, wird sein Weiterbetrieb zu einer bewussten Management-Entscheidung. Ab diesem Moment handelt es sich nicht mehr um ein implizites Technikrisiko, sondern um ein explizites Organisationsrisiko, das auf Leitungsebene verantwortet werden muss.

Der entscheidende Unterschied liegt darin, ob ein System stillschweigend geduldet oder formal als Ausnahme behandelt wird. Implizite Duldung erzeugt in Audits den Eindruck fehlender Kontrolle. Eine explizite Ausnahme hingegen macht den Zustand sichtbar, begrenzt ihn zeitlich und sachlich und ordnet ihn einer verantwortlichen Instanz zu. Governance-fähig ist in solchen Konstellationen nicht das System selbst, sondern die Entscheidung über seinen Betrieb.

Diese Entscheidung muss nachvollziehbar dokumentiert sein, einen klaren Zweck benennen und mit definierten Randbedingungen versehen werden. Dazu gehören insbesondere die Abgrenzung des Einsatzbereichs, zusätzliche Überwachungs- und Kompensationsmaßnahmen sowie eine regelmäßige Neubewertung. Entscheidend ist dabei weniger die Perfektion der Maßnahmen als die Eindeutigkeit der Verantwortlichkeit. Nur so lässt sich gegenüber Aufsicht und Auditoren darlegen, dass der Zustand nicht verdrängt, sondern aktiv gesteuert wird.

Technische Unersetzbarkeit ist damit kein Freibrief, sondern ein Prüfstein für Governance-Reife. Organisationen, die diesen Unterschied klar ziehen, können auch mit schwierigen Altlasten bestehen. Organisationen, die ihn verwischen, laufen Gefahr, dass aus einer technischen Einschränkung ein strukturelles Haftungs- und Vertrauensproblem wird.

Operative Sichtbarkeit als Mindestanforderung

Dort, wo technische Auditierbarkeit strukturell nicht herstellbar ist, wird operative Sichtbarkeit zur nicht verhandelbaren Mindestanforderung. Wenn ein System keine belastbare Identitäts-, Sitzungs- oder Handlungszuordnung liefern kann, muss diese Lücke auf der Betriebsebene bewusst und sichtbar adressiert werden. Jede Nutzung eines nicht governance-fähigen Systems ist dann kein Routinevorgang, sondern ein sicherheitsrelevantes Ereignis mit Prüf- und Relevanzcharakter.

Operative Sichtbarkeit bedeutet in diesem Kontext nicht bloß Logging im technischen Sinne. Entscheidend ist die Kontextualisierung der Nutzung: Wer greift wann, von wo, über welchen Pfad und zu welchem Zweck auf ein solches System zu? Welche organisatorische Rolle legitimiert diesen Zugriff, und unter welchen Rahmenbedingungen findet er statt? Diese Informationen ersetzen nicht die fehlende technische Auditierbarkeit, machen aber die Nutzung steuerbar, überprüfbar und verantwortbar.

Wichtig ist dabei die klare Trennung zwischen Kompensation und Illusion. Operative Sichtbarkeit ist keine Reparatur des Systems, sondern eine bewusst gewählte Ausgleichsmaßnahme für einen bekannten strukturellen Mangel. Sie muss deshalb explizit als solche benannt werden. Der Versuch, fehlende Steuerungsfähigkeit durch formale Dokumentation oder nachträgliche Protokollsammlungen zu kaschieren, verschärft das Risiko statt es zu mindern. Auditoren und Aufsichtsbehörden unterscheiden sehr genau zwischen echter Kontrolle und nachgelagerter Rechtfertigung.

Unter NIS-2 und BSI-Grundschutz++ ist nicht ausschlaggebend, dass Aktivitäten irgendwo dokumentiert sind, sondern dass Organisationen nachweisen können, dass sie den Betrieb nicht-governance-fähiger Systeme aktiv führen. Steuerungsfähigkeit zeigt sich darin, dass Nutzung begrenzt, beobachtet, hinterfragt und bei Bedarf unterbunden werden kann. Wo diese Fähigkeit fehlt oder nur behauptet wird, entsteht ein Governance-Defizit, das sich im Prüfungsfall unmittelbar gegen die Leitungsebene richtet.

Operative Sichtbarkeit ist damit kein optionales Zusatzinstrument, sondern die unterste Linie der Verteidigung in Umgebungen mit strukturellen Altlasten. Sie macht aus einem diffusen technischen Risiko einen benennbaren, adressierbaren und verantworteten Zustand – und genau das ist es, was moderne Aufsichts- und Prüfregime erwarten.

Fazit & Angebot

Historisch gewachsene, nicht vollständig governance-fähige Systeme sind kein Randphänomen, sondern ein zentrales Risiko moderner IT- und OT-Landschaften. Die eigentliche Gefahr liegt dabei nicht in einzelnen technischen Schwachstellen, sondern in der Kombination aus fehlender Steuerungsfähigkeit, eingeschränkter Auditierbarkeit und impliziter Verantwortungsdiffusion. Genau diese Kombination macht solche Systeme unter heutigen Regimen angreifbar – nicht technisch, sondern regulatorisch und haftungsrechtlich.

Dieser Beitrag adressiert bewusst die strukturelle Ebene des Problems. Dort setzen Aufsichtsbehörden, Auditoren und Geschäftsleitungen im Jahr 2026 an. Entscheidend ist nicht, ob ein System historisch erklärbar ist, sondern ob sein Betrieb heute bewusst geführt, begrenzt und verantwortet wird. Governance ersetzt Historie.

Die Übertragung dieser Governance-Logik in eine tragfähige Position für Aufsichts-, NIS-2- oder Zertifizierungsgespräche ist jedoch niemals generisch. Sie hängt vom konkreten Schutzbedarf, vom anwendbaren Regime, von der Organisationsstruktur und vor allem von der realen Systemlandschaft ab. Genau deshalb lassen sich solche Situationen nicht mit Standarddokumenten, vorgefertigten Policies oder schematischen Risikoakzeptanzen beherrschen.

Wenn Sie vor einer Prüfung stehen und den Umgang mit historisch gewachsenen, nicht vollständig auditierbaren Systemen belastbar vertreten müssen, unterstütze ich Sie gern dabei, gemeinsam ein maßgeschneidertes Audit-Positionspapier zu erarbeiten und Sie im Audit aktiv zu begleiten. Ziel ist keine kosmetische Compliance, sondern eine Argumentationslinie, die die tatsächliche Unternehmensrealität abbildet, regulatorisch trägt und auch unter kritischer Nachfrage Bestand hat.

Sprechen Sie mich an, wenn Sie diesen Schritt bewusst, vorbereitet und auf Augenhöhe mit Aufsicht und Auditoren gehen wollen.

Methodologischer Hinweis: Die empirischen Angaben in diesem Artikel basieren auf der Korrelation unabhängiger, veröffentlichter Quellen. Die Verbreitung exponierter Legacy-Dienste stützt sich auf Shadowserver-Messungen, Shodan-Scans und Bitsight-Reports (Unforgivable Exposure 2025/2026). Die OT/ICS-Exposition ist dokumentiert im Claroty State of Critical Infrastructure Report (2025), in Team82 Vulnerability Research und in Fortinet Threat Landscape Reports. Die Dynamik-Trends zu IT/OT-Konvergenz und Fachkräftemangel sind belegt durch Rockwell Automation, ENISA 2025 und IBM X-Force Threat Intelligence. Zur Patch-Kompatibilität in OT liegen Branchenstudien zu Zertifizierungsabhängigkeiten in Embedded und ICS-Umgebungen vor. Die Regime-Details stammen aus offiziellen Quellen: NIS-2 (OJEU 2022/2555), ISO/IEC 27001:2022 Standard und die BSI-Fortentwicklung (bsi.bund.de).

Der Text verzichtet bewusst auf vollständige Quellenangaben zugunsten von Lesbarkeit, kann diese aber auf Anfrage detailliert belegen. Die Einschätzung zur Datenbasis – dass keine Vollerhebung vorliegt, sondern eine Korrelation mehrerer Quellen – spiegelt wissenschaftliche Sorgfalt wider.