ISMS ohne Cloud-Abhängigkeit: Warum Offline-Fähigkeit kein Relikt ist

Das Problem, über das niemand spricht

Cloud-Software ist heute der Standard. Für die meisten Anwendungsfälle funktioniert das gut. Aber es gibt eine Kategorie von Software, bei der "funktioniert meistens" nicht reicht: Systeme, die in Notfällen und unter Stress verfügbar sein müssen. Dein ISMS gehört dazu.

Ein ISMS ist kein Projektmanagement-Tool, das ein paar Stunden Downtime verkraftet. Es enthält deine Incident-Response-Pläne, deine Notfallkontakte, deine Risikobewertungen, deine Dokumentation. Es ist das System, das du öffnest, wenn etwas schiefgeht. Und wenn es genau dann nicht erreichbar ist, weil der Internetanschluss ausgefallen ist, der Cloud-Anbieter eine Störung hat oder du das Internet bewusst getrennt hast, stehst du mit leeren Händen da.

Das ist kein theoretisches Risiko. Es ist ein Verfügbarkeitsproblem, und Verfügbarkeit ist eine der drei Säulen der Informationssicherheit.

Szenario 1: Audit vor Ort ohne stabiles Netz

Externe Audits finden nicht in perfekt ausgestatteten Konferenzräumen statt. Sie finden dort statt, wo die Prozesse laufen: im Serverraum, in der Produktionshalle, im Büro des ISB, der vielleicht im Außenstandort sitzt. Und nicht überall gibt es stabiles WLAN oder einen Mobilfunkempfang, der für eine Cloud-Anwendung ausreicht.

Ein typisches Audit-Szenario: Der externe Auditor möchte die Risikobewertung zu den OT-Systemen einsehen. Du öffnest dein Cloud-ISMS, und die Seite lädt. Und lädt. Das WLAN in der Produktionshalle ist auf IoT-Sensoren ausgelegt, nicht auf Browser-Applikationen mit hunderten von Datensätzen. Nach 30 Sekunden gibt der Browser auf. Du entschuldigst dich, gehst zurück ins Büro, exportierst ein PDF, gehst zurück in die Halle.

Das ist nicht der Untergang. Aber es kostet Zeit, es wirkt unprofessionell, und es zeigt dem Auditor etwas, das er sich notiert: Die Verfügbarkeit des ISMS ist abhängig von einer externen Internetverbindung. Und wenn er dann fragt, ob diese Abhängigkeit in der Risikobewertung steht, wird es unangenehm.

Mit einem Self-Hosted-System, das im lokalen Netzwerk läuft, öffnest du den Browser und die Daten sind da. Auch im Serverraum, auch in der Außenstelle, auch in der Produktionshalle, solange das interne Netz funktioniert.

Szenario 2: Der Incident, bei dem das Internet ausfällt

Freitagabend, 18 Uhr. Die IT-Abteilung bemerkt ungewöhnlichen Netzwerkverkehr. Ein Ransomware-Angriff wird vermutet. Die erste Maßnahme: Netzwerksegmente isolieren, externe Verbindungen kappen. Der Sicherheitsexperte trennt den Internetzugang, um eine weitere Ausbreitung zu verhindern.

Und jetzt brauchst du dein ISMS. Du brauchst den Incident-Response-Plan. Du brauchst die Eskalationskontakte. Du brauchst die Dokumentation zu den betroffenen Systemen, um einzuschätzen, welche Daten gefährdet sind. Du brauchst die Schutzbedarfsfeststellung, um die Meldepflichten einzuschätzen. Musst du innerhalb von 24 Stunden ans BSI melden?

Wenn dein ISMS in der Cloud liegt, kommst du an nichts davon heran. Du hast gerade das Internet gekappt, genau die Leitung, über die du auf dein ISMS zugreifst. Die Dokumentation, die du für den Notfall erstellt hast, ist im Notfall nicht verfügbar.

"Dann drucken wir die wichtigsten Dokumente aus", sagen manche. Ja, das kannst du machen. Aber dann hast du ein ISMS-System, das Geld kostet, und einen Aktenordner, der die eigentliche Arbeit macht. Das ist keine Lösung, das ist ein Workaround, der zeigt, dass die eigentliche Lösung ein Verfügbarkeitsproblem hat.

Ein Self-Hosted-System im lokalen Netzwerk ist vom Internet unabhängig. Du kannst den Internetzugang kappen und trotzdem auf dein ISMS zugreifen, weil es auf deiner eigenen Infrastruktur läuft.

Szenario 3: Produktionsumgebungen ohne Internet

In vielen Fertigungsunternehmen ist die Produktionsumgebung bewusst vom Internet getrennt. Die OT-Sicherheit verlangt eine strikte Trennung zwischen IT- und OT-Netzwerken. Das Purdue-Modell definiert Netzwerkzonen, in denen Systeme der unteren Ebenen keinen direkten Internetzugang haben und auch keinen haben sollen.

Wenn du in diesen Umgebungen Risikobewertungen durchführst, Assets erfasst oder Maßnahmen dokumentierst, brauchst du ein System, das im internen Netz erreichbar ist. Ein Cloud-ISMS erfordert, dass du die Daten entweder vorher exportierst und später manuell einpflegst, oder dass du ein separates Gerät mit Internetzugang mitbringst, was in einer abgeschotteten Umgebung ein Sicherheitsproblem ist.

Für Unternehmen in der Fertigungsindustrie, die unter NIS2 für Maschinenbauer fallen, ist das kein Randthema. Sie müssen ein ISMS betreiben, das auch die OT-Umgebung abdeckt. Und sie müssen auf dieses ISMS zugreifen können, wo die OT-Umgebung ist.

Air-Gapped Environments: Wenn Offline die Vorgabe ist

Es gibt Umgebungen, in denen Offline-Fähigkeit keine Option ist, sondern eine Vorgabe. Air-Gapped-Systeme sind physisch vom Internet getrennt, ohne Kabel, ohne WLAN, ohne Mobilfunk. Sie kommen vor bei:

• KRITIS-Betreibern: Energieversorger, Wasserversorger, Krankenhäuser mit kritischen Steuerungssystemen
• Verteidigungsindustrie: Zulieferer mit Geheimhaltungsanforderungen, die Daten nicht außerhalb kontrollierter Umgebungen verarbeiten dürfen
• Forschungseinrichtungen: Labore mit sensiblen Forschungsdaten oder Patenten
• OT-Umgebungen: Produktionssteuerungen, SCADA-Systeme, Leittechnik

In all diesen Umgebungen ist ein Cloud-ISMS von vorneherein ausgeschlossen. Die Daten dürfen das interne Netzwerk nicht verlassen, und ein Browser, der Verbindung zu einem externen Server aufbaut, ist nicht zulässig.

Self-Hosted-Systeme laufen konstruktionsbedingt in dieser Umgebung. Sie brauchen keine externe Verbindung, keine Lizenzserver-Erreichbarkeit, keine Telemetrie. ISMS Lite läuft auf einem lokalen Server, benötigt für den Betrieb keinerlei Internetverbindung und validiert die Lizenz offline. In Air-Gapped-Umgebungen wird das System über einen USB-Datenträger installiert und aktualisiert, mit den entsprechenden Sicherheitsfreigaben für den Datenträgertransport.

SaaS-Abhängigkeit als Single Point of Failure

Lass uns das Problem systematisch betrachten. Ein Single Point of Failure (SPOF) ist eine Komponente, deren Ausfall das gesamte System lahmlegt. Bei einem Cloud-ISMS gibt es gleich mehrere potenzielle SPOFs:

Jede dieser Abhängigkeiten kann unabhängig voneinander zum Ausfall führen. Die Gesamtverfügbarkeit ist das Produkt der Einzelverfügbarkeiten. Wenn jede Komponente 99,9 % Verfügbarkeit hat, ergibt sich bei fünf Komponenten eine Gesamtverfügbarkeit von 99,5 %, das sind über 40 Stunden Ausfall pro Jahr.

Bei einem Self-Hosted-System reduzieren sich die Abhängigkeiten auf: der Server läuft und das interne Netz funktioniert. Zwei Komponenten statt fünf, beide unter deiner Kontrolle, beide mit lokaler Redundanz absicherbar.

"Aber unser Internet ist stabil"

Ja, meistens. Und dein ISMS brauchst du meistens auch nicht dringend. Das Problem ist das "meistens". Du brauchst dein ISMS genau dann dringend, wenn Dinge schiefgehen. Und wenn Dinge schiefgehen, ist die Internetverbindung häufig Teil des Problems.

Ein DDoS-Angriff legt deine Internetverbindung lahm. Ein kompromittierter Router wird vom Provider abgeschaltet. Ein Baggerunfall durchtrennt das Glasfaserkabel. Der Cloud-Anbieter hat einen globalen Ausfall. Die Szenarien sind vielfältig, und sie treten selten isoliert auf. Ein Sicherheitsvorfall korreliert häufig mit Netzwerkproblemen, weil Angreifer genau diese Infrastruktur angreifen oder weil die Reaktion auf den Vorfall Netzwerkmaßnahmen erfordert.

Ein ISMS, das genau dann nicht verfügbar ist, wenn es gebraucht wird, hat ein fundamentales Designproblem. Und dieses Problem lässt sich nicht durch SLAs des Cloud-Anbieters lösen, weil das SLA nur die Verfügbarkeit des Cloud-Dienstes abdeckt, nicht die Verfügbarkeit deiner Internetverbindung.

Offline-Fähigkeit und NIS2

Die NIS2-Richtlinie fordert von betroffenen Unternehmen unter anderem die Aufrechterhaltung des Betriebs (Business Continuity) und ein funktionierendes Incident Management. Beides setzt voraus, dass die relevanten Systeme und Dokumentationen auch im Krisenfall verfügbar sind.

Wenn dein ISMS der zentrale Ort ist, an dem Incident-Response-Pläne, Notfallhandbücher und Meldeprozesse dokumentiert sind, und dieses System bei einem Internetausfall nicht erreichbar ist, hast du ein Compliance-Problem. Nicht weil NIS2 Self-Hosted vorschreibt (das tut es nicht), sondern weil NIS2 Verfügbarkeit deiner Sicherheitsprozesse fordert. Und die ist bei einem Cloud-ISMS an die Internetverfügbarkeit gekoppelt.

Du kannst dieses Risiko behandeln: durch redundante Internetanbindung, durch lokale Kopien kritischer Dokumente, durch ein separates Offline-Notfallhandbuch. Aber jede dieser Maßnahmen ist ein Workaround für ein Problem, das ein Self-Hosted-System von Haus aus nicht hat.

Szenario 4: Außenstandorte mit instabilem Internet

Nicht jeder Standort hat Glasfaser. Ein Bauunternehmen mit Baustellen in ländlichen Gebieten, ein Maschinenbauer mit einer Fertigungshalle im Gewerbegebiet am Ortsrand, ein Logistikunternehmen mit Lagerstandorten an der Autobahn. In Deutschland gibt es genug Orte, an denen die Internetverbindung weder schnell noch stabil ist.

Wenn der ISB an einem solchen Standort eine Begehung durchführt, Assets erfasst oder eine Risikobewertung bespricht, braucht er Zugriff auf das ISMS. Bei einer Cloud-Lösung bedeutet das: mobiler Hotspot aufbauen, auf ausreichend Empfang hoffen, und beten, dass die Webanwendung mit 2 Mbit/s noch benutzbar ist. Bei einem Self-Hosted-System im Firmennetz reicht ein VPN zum Hauptstandort, oder, wenn der Standort ein eigenes lokales Netz hat, eine lokale Instanz.

Besonders relevant wird das für Unternehmen, die unter NIS2 mehrere Standorte in den Geltungsbereich ihres ISMS aufnehmen müssen. Ein ISMS, das an drei von fünf Standorten nur eingeschränkt funktioniert, ist kein vollständiges ISMS.

Die Risikobewertung, die fehlt

Hier liegt das eigentliche Problem: Die meisten Unternehmen haben die Abhängigkeit ihres ISMS von der Internetverbindung nie als Risiko bewertet. Sie haben Risiken für ihre Server bewertet, für ihre Anwendungen, für ihre Datenbanken. Aber das ISMS selbst, das Tool, in dem all diese Risiken dokumentiert sind, steht nicht auf der Liste.

Das ist ein blinder Fleck. Wenn du dein ISMS als Cloud-Dienst betreibst, sollte "Ausfall des ISMS-Cloud-Dienstes" als eigenes Risiko in deiner Risikobewertung erscheinen, mit Eintrittswahrscheinlichkeit, Schadenshöhe und definierten Maßnahmen.

Und wenn du diese Bewertung ehrlich durchführst, kommst du zu einem unbequemen Ergebnis: Die Eintrittswahrscheinlichkeit ist nicht niedrig (Internetausfälle passieren), die Schadenshöhe ist hoch (kein Zugriff auf Notfalldokumentation im Krisenfall), und die wirksamste Maßnahme ist, die Abhängigkeit zu eliminieren, also Self-Hosted zu betreiben.

Was "verfügbar" im ISMS-Kontext wirklich heißt

Verfügbarkeit ist einer der drei Pfeiler der Informationssicherheit, neben Vertraulichkeit und Integrität. Die CIA-Triade steht in jeder ISO-27001-Schulung auf Folie zwei. Aber wenn es um das ISMS-Tool selbst geht, wird Verfügbarkeit oft nur als "Anbieter hat 99,9% Uptime" interpretiert.

Das greift zu kurz. Verfügbarkeit im ISMS-Kontext bedeutet:

• Zugriff, wenn du ihn brauchst: Nicht nur wenn alles normal läuft, sondern besonders wenn es das nicht tut
• Zugriff, wo du ihn brauchst: Am Standort, in der Produktionshalle, beim Kunden, nicht nur am Schreibtisch mit WLAN
• Zugriff für alle, die ihn brauchen: Der ISB, der Risikoeigner, der Auditor, das Krisenteam. Gleichzeitig, nicht nacheinander über ein geteiltes Login
• Zugriff in akzeptabler Geschwindigkeit: Eine Risikomatrix, die 15 Sekunden zum Laden braucht, ist bei einem Audit keine Hilfe

Ein Self-Hosted-System im lokalen Netzwerk erfüllt alle vier Kriterien, unabhängig von der Internetverbindung. Ein Cloud-System erfüllt sie nur, solange das Internet funktioniert.

Häufige Fehler beim Thema Offline-Fähigkeit

1. "Wir drucken die wichtigsten Dokumente aus"

Ein gedrucktes Notfallhandbuch ist besser als keines. Aber es ist kein Ersatz für ein funktionierendes ISMS. Gedruckte Dokumente sind statisch. Sie veralten sofort nach dem Druck. Sie enthalten keine Verknüpfungen zwischen Risiken, Assets und Maßnahmen. Sie sind nicht durchsuchbar. Und sie werden erfahrungsgemäß nie aktualisiert. Wenn du ein gedrucktes Notfallhandbuch neben einem digitalen ISMS brauchst, ist das ein Zeichen dafür, dass die Verfügbarkeit deines digitalen ISMS nicht ausreicht.

2. "Unser Cloud-Anbieter hat ein SLA von 99,9%"

99,9% klingt gut. Das sind weniger als 9 Stunden Ausfall pro Jahr. Aber das SLA deckt nur die Verfügbarkeit des Cloud-Dienstes ab. Wenn dein Internetanschluss ausfällt, dein DNS-Provider eine Störung hat oder dein Identity Provider offline ist, greift das SLA nicht. Die End-to-End-Verfügbarkeit ist das Produkt aller Komponenten auf dem Weg.

3. "Wir haben eine zweite Internetleitung"

Redundante Internetanbindung ist eine gute Maßnahme. Aber sie schützt nicht vor allen Szenarien: bewusste Netzwerktrennung bei einem Incident, Air-Gapped-Anforderungen, Cloud-Anbieter-Ausfall. Und sie erzeugt laufende Kosten für ein Problem, das Self-Hosting von Haus aus löst.

4. "Das ist noch nie passiert"

Sicherheitsvorfälle sind per Definition Ereignisse, die vorher noch nie passiert sind, zumindest nicht in deinem Unternehmen. Die Tatsache, dass dein Cloud-ISMS noch nie ausgefallen ist, ist kein Beleg dafür, dass es nicht ausfallen wird. Risikomanagement basiert auf Wahrscheinlichkeiten und Auswirkungen, nicht auf der Abwesenheit bisheriger Vorfälle.

Wann Offline-Fähigkeit ein Muss ist

Nicht jedes Unternehmen braucht ein ISMS, das offline läuft. Aber diese Konstellationen machen es zur harten Anforderung:

• KRITIS-Betreiber mit Anforderungen an die Verfügbarkeit kritischer Prozesse
• Unternehmen mit OT-Umgebungen, in denen das ISMS auch die Produktion abdecken muss
• Organisationen mit Geheimhaltungsanforderungen (Verteidigung, Regierung, Forschung)
• Unternehmen mit Standorten ohne stabiles Internet (ländliche Gebiete, Auslandsstandorte, Baustellen)
• Unternehmen mit strikten Datensouveränitätsanforderungen, die keine Daten bei externen Anbietern speichern dürfen
• Jedes Unternehmen, das sein ISMS als Teil der Notfallvorsorge betrachtet, weil Notfälle keine stabile Internetverbindung garantieren

Und wenn du ehrlich bist: Jedes Unternehmen, das sein ISMS ernst nimmt, sollte sich die Frage stellen, was passiert, wenn das Internet ausfällt. Nicht weil die Cloud grundsätzlich schlecht ist, sondern weil Verfügbarkeit ein Kernziel der Informationssicherheit ist und die eigene Sicherheitsdokumentation davon nicht ausgenommen sein sollte.

Praktischer Vergleich: Verfügbarkeit Cloud vs. Self-Hosted

Ein Wort zur Wartung

Self-Hosted bedeutet Eigenverantwortung. Du bist für Updates, Backups und Server-Wartung zuständig. Das ist ein valider Einwand, und er muss in die Entscheidung einfließen. Aber die Wartung eines lokalen Servers ist kein Hexenwerk. Ein monatliches Update, tägliche automatisierte Backups und ein Restore-Test pro Quartal reichen aus. Der Aufwand liegt bei ein bis zwei Stunden pro Monat, was deutlich weniger ist, als die meisten befürchten.

Und dieser Aufwand steht in keinem Verhältnis zu den Kosten eines ISMS-Ausfalls im falschen Moment.

Fazit

Offline-Fähigkeit ist kein Relikt aus der Vor-Cloud-Ära. Sie ist eine Verfügbarkeitsanforderung, die sich aus der Natur eines ISMS ergibt. Ein System, das deine Notfallpläne enthält, muss im Notfall verfügbar sein. Ein System, das deine Risikobewertungen enthält, muss beim Audit verfügbar sein. Ein System, das deine OT-Dokumentation enthält, muss in der OT-Umgebung verfügbar sein. Self-Hosted ist nicht die einzige Antwort auf diese Anforderung, aber es ist die einfachste.

Weiterführende Artikel

• Self-Hosted vs. Cloud: Datensouveränität bei Compliance-Software
• OT-Sicherheit im Mittelstand: Warum die Produktionssteuerung ins ISMS gehört
• Disaster Recovery Plan erstellen: Vom Notfall zurück zum Normalbetrieb
• Incident Response Plan erstellen: Vorlage und Praxisbeispiel
• Backup-Strategie und Restore-Tests: Weil Backups allein nicht reichen