Autor: Dr. Stefan Ransom, Partner & Prokurist bei TTS Trusted Technologies and Solutions GmbH
Warum getrennte Systeme im Ernstfall an Grenzen stoßen, und ein gemeinsames Weltbild Resilienz schafft
ISMS hier, BCMS dort: In vielen Organisationen sind beide Disziplinen unabhängig voneinander organisiert, mit eigenen Verantwortlichen, Analysen, Tools und Begriffen. Auf dem Organigramm wirkt das sauber. In der Praxis kostet es Zeit und im Ernstfall kann es die Handlungsfähigkeit kosten. Denn Cyberangriffe, Dienstleisterausfälle oder der Verlust eines Standorts halten sich nicht an die Grenzen von Managementsystemen.
Beide Disziplinen haben denselben Auftrag: Schäden verhindern oder begrenzen und die Organisation handlungsfähig halten, wenn Sicherheitsvorfälle oder andere Störungen eintreten. Dafür müssen beide wissen, welche Leistungen wirklich zählen und wovon sie abhängen. Unterschiedliche Perspektiven sind notwendig. Aber unterschiedliche Weltbilder sind gefährlich.
Zwei Analysen und zwei Blickwinkel – aber eine Organisation
Das ISMS startet typischerweise mit der Schutzbedarfsanalyse, das BCMS mit der Business Impact Analysis, kurz BIA. Beide rechnen mit möglichen Schäden. Aber sie beginnen bei unterschiedlichen Objekten und liefern Antworten auf unterschiedliche Fragen.
Die Schutzbedarfsanalyse: Informationen angemessen schützen
Informationssicherheit beginnt bei Informationswerten: etwa Kundendaten, Konstruktionszeichnungen, Produktionsparametern oder Zugangsdaten. Entscheidend ist der mögliche Schaden, wenn Vertraulichkeit, Integrität oder Verfügbarkeit verletzt werden. Bei der Verfügbarkeit zählt zusätzlich die Zeit: zwei Stunden können verkraftbar sein, ein ganzer Tag existenzbedrohend.
Dieser Schutzbedarf endet nicht bei der Information. Er wird auf alle unterstützenden Werte und Ressourcen übertragen, die Informationen verarbeiten, speichern oder übertragen. Korrekte Produktionsparameter erzeugen so Schutzbedarf für Produktionssteuerung, Server, Netze und Dienstleister. Dabei gilt häufig das Maximumprinzip: Der höchste relevante Schutzbedarf prägt die Einstufung. Anschließend werden Gefährdungen und Eintrittswahrscheinlichkeiten analysiert, Risiken ermittelt und Behandlungsmaßnahmen abgeleitet.
Die Kernfrage der Schutzbedarfsanalyse: Welche Informationen sind wie schutzbedürftig und welche Ressourcen müssen deshalb gegen Risiken abgesichert werden?
Die BIA: Was bis wann wieder funktionieren muss
Das BCM schaut aus der anderen Richtung auf die Organisation. Im Mittelpunkt stehen Geschäftsprozesse und die Tätigkeiten, ohne die Produkte oder Dienstleistungen nicht erbracht werden können. Die BIA macht sichtbar, wie die Folgen einer Unterbrechung mit der Zeit wachsen: Was muss zuerst wieder funktionieren? Und wann wird der Ausfall untragbar?
Genau hier reichen Informationswerte allein nicht aus. Alle Daten können verfügbar sein – und trotzdem steht die Tätigkeit: weil die freigabeberechtigte Person fehlt, der Rohstoff nicht rechtzeitig kommt, das Labor ausfällt oder eine vorgelagerte Tätigkeit kein Ergebnis liefert. Ein BCMS muss deshalb Tätigkeiten und ihre Abhängigkeiten ausdrücklich abbilden.
Der Unterschied ist entscheidend: Im ISMS bestimmt nach dem Maximumprinzip der höchste Schadenswert die Kritikalität des Prozesses und den Schutzbedarf seiner Ressourcen. Im BCM zählt zusätzlich die gesamte Abhängigkeitskette. Denn auch eine unscheinbare Tätigkeit kann bei Ausfall den ganzen Prozess stoppen.
Die BIA übersetzt Auswirkungen in zeitliche Leitplanken und klare Prioritäten. Dazu gehören die maximal tolerierbare Unterbrechungsdauer (MTPD; Maximum Tolerable Period of Disruption), die angestrebte Wiederanlaufzeit (RTO; Recovery Time Objective) und, sofern Daten wiederhergestellt werden müssen, der angestrebte Wiederherstellungspunkt (RPO; Recovery Point Objective). Er beschreibt die maximal akzeptable Datenverlustspanne. Darauf folgen die Bewertung von Ausfallszenarien, die Auswahl geeigneter BCM-Strategien sowie die Ableitung konkreter dafür notwendiger Umsetzungsmaßnahmen. Notfall-, Wiederherstellungs- und Geschäftsfortführungspläne machen die gewählten Strategien dann für den Notfall handhabbar.
Die Kernfrage der BIA: Welche Prozesse und Tätigkeiten müssen nach einer Unterbrechung bis wann und mit welchen Mindestressourcen wieder funktionieren?
Gemeinsamkeiten und Unterschiede im direkten Vergleich
| Aspekt | Informationssicherheit (ISMS) | Business Continuity (BCMS) |
|---|---|---|
| Primärer Blick | Informationswerte und ihre Schutzziele | Geschäftsprozesse, Tätigkeiten und zeitkritische Leistungen |
| Schadenslogik | Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit | Auswirkungen einer Unterbrechung im Zeitverlauf |
| Ableitung | Kritikalität der Geschäftsprozesse und Schutzbedarf unterstützender Ressourcen (häufig nach dem Maximumprinzip) | Kritikalität der Geschäftsprozesse, Abhängigkeiten sowie MTPD, RTO und RPO |
| Weitere Analyse | Gefährdungen, Eintrittswahrscheinlichkeiten und Risiken | Ausfallszenarien und BCM-Strategien |
| Ergebnis | Maßnahmen zur Risikobehandlung | Umsetzungsmaßnahmen für BCM-Strategien sowie Notfall-, Wiederherstellungs- und Geschäftsfortführungspläne |
Beide Analysen betrachten Schäden. Der entscheidende Unterschied ist, wo sie beginnen und welche Entscheidungen sie ermöglichen.
Normkonform – ohne eine zweite Realität zu bauen
Organisationen wollen normkonform arbeiten oder sind teilweise auch dazu verpflichtet. ISO/IEC 27001 fordert einen risikobasierten Umgang mit Informationen und den zu ihrer Verarbeitung benötigten unterstützenden Werten und Ressourcen. ISO 22301 verlangt für die BIA zusätzlich, priorisierte Tätigkeiten, ihre Abhängigkeiten und die erforderlichen Ressourcen zu bestimmen. Wer im BCM nur auf Informationswerte schaut, lässt einen entscheidenden Teil der betrieblichen Realität aus.
Die beiden Normen brauchen unterschiedliche fachliche Ergebnisse, aber keine getrennten Inventare für die Analyse. Vielmehr trägt eine konsistente Sicht auf die Organisation beide.
Das gemeinsame Fundament: ein Modell der Informationsverarbeitung
Das Modell der Informationsverarbeitung schafft diese gemeinsame Sicht. Es verbindet Geschäftsprozesse mit den benötigten Informationswerten und Tätigkeiten. Zugleich macht es sichtbar, wie Tätigkeiten voneinander und von unterstützenden Werten und Ressourcen abhängen: von IT-Systemen, Anlagen, Gebäuden, Personen und Dienstleistern.
Perfektion ist dabei der falsche Anspruch. Das Modell muss nicht das ganze Unternehmen bis ins letzte Detail abbilden, sondern gute Entscheidungen ermöglichen. Der Einstieg erfolgt bei wesentlichen Diensten und potenziell kritischen Prozessen: Welche Informationen, Tätigkeiten, Ressourcen, Abhängigkeiten und Zeitziele zählen? Vertieft wird nur dort, wo es Entscheidungen, Strategien oder Pläne besser macht. Die Devise lautet: grob starten und gezielt nachschärfen.
Abbildung 1: Gemeinsame Basis für ISMS und BCMS
Und nicht immer muss alles neu erhoben werden. Ein etabliertes QMS nach ISO 9001 kennt häufig bereits Prozesse, Tätigkeiten und Wechselwirkungen. Das BCM kann diese nutzen und sie um Zeitkritikalität, Kontinuitätsressourcen und störungsrelevante Abhängigkeiten ergänzen. Umgekehrt kann das gemeinsame Prozessmodell später ein QMS unterstützen. Die Arbeit zahlt also mehrfach ein.
Ein Modell lebt – oder es veraltet. Verantwortlichkeiten und Aktualisierungsanlässe müssen deshalb klar sein. Eine schlanke, gepflegte Landkarte ist dabei mehr wert als ein perfektes Modell, das nach 6 Monaten veraltet und dem niemand mehr vertraut.
Auf dieser gemeinsamen Landkarte entstehen konsistente fachliche Auswertungen: Das ISMS erkennt und behandelt Risiken an unterstützenden Werten und Ressourcen. Das BCMS analysiert Abhängigkeiten und legt Wiederanlaufziele und Fortführungsstrategien fest. Auch beim Management-Reporting greifen beide auf dieselben Prozesse, Kritikalitäten und Beziehungen zu. Aus zwei Blickwinkeln wird ein konsistentes Gesamtbild.
Gemeinsames Modell heißt nicht gleiche Aufgabe. ISMS und BCMS bleiben fachlich eigenständig. Aber sie gehen von demselben Weltbild aus und sprechen eine gemeinsame Sprache: über dieselben Prozesse, Informationen, Tätigkeiten sowie unterstützenden Werte und Ressourcen.
Warum es um weit mehr als Effizienz geht
Einmal fragen. Gemeinsam nutzen.
Fachbereiche kennen das Spiel: Erst fragt das ISMS nach Informationen und unterstützenden Werten, kurz darauf das BCMS nach Prozessen und Ressourcen. Andere Begriffe, andere Skalen, andere Tools. Das führt in der Praxis am Ende leider häufig zu zwei Versionen derselben Realität.
Eine gemeinsame Datenbasis beendet diese Doppelarbeit und verbessert die Qualität. Ändert sich ein Dienstleister, Standort oder System, muss die Änderung nur einmal nachgezogen werden. Und Widersprüche werden sichtbar: etwa, wenn ein zeitkritischer Prozess auf zentralen Ressourcen beruht, für die das ISMS nur einen niedrigen Verfügbarkeitsbedarf ausweist.
Maßnahmen einmal entwickeln – gemeinsam richtig auslegen
Einige Umsetzungsmaßnahmen, wie etwa Redundanz, Backups und offline verfügbare Notfalldokumentation sind für beide Disziplinen relevant. Werden sie getrennt geplant, entstehen schnell unterschiedliche Annahmen, Verantwortlichkeiten und Zielwerte. Dann gibt es zwei Konzepte, aber keine gemeinsame Lösung.
Backup
Aus IS-Sicht ist ein Backup die Antwort auf Risiken wie Ransomware, Fehlbedienung oder Defekte. Deshalb muss es gegen unbefugten Zugriff geschützt, unveränderbar, vom Produktivsystem getrennt und regelmäßig auf Wiederherstellbarkeit getestet sein.
Das BCM fragt weiter: Welche Daten braucht welcher Prozess zuerst? Wie viel Datenverlust ist akzeptabel? Welche Wiederanlaufzeit gilt? Und welche Systeme, Personen oder Dienstleister werden dafür benötigt? Denn nicht die Datenbank allein muss zurückkommen, sondern die gesamte Prozesskette, und das in der richtigen Reihenfolge.
Zwei Backup-Konzepte lösen dieses Problem nicht. Die Risikoanalyse begründet den Schutz. Die BIA liefert Zeitziele und geschäftliche Prioritäten. Die BCM-Strategie macht daraus eine belastbare Bereitstellung und Wiederherstellung im Störungsfall.
Redundanz
Die IS-Risikoanalyse zeigt den Single Point of Failure. Die BCM-Sicht zeigt, was die Redundanz wirklich leisten muss: welche Umschaltzeit, welche Kapazität und welche Unabhängigkeit. Zwei Systeme im selben Brandabschnitt oder zwei Dienstleister mit demselben Unterauftragnehmer sehen redundant aus, können aber im selben Szenario ausfallen.
Offline-Notfalldokumentation
Notfalldokumentation muss zwei Dinge gleichzeitig sein: geschützt und erreichbar. Das ISMS schützt Kontaktdaten, Zugangsinformationen und Anweisungen vor Offenlegung und Manipulation. Das BCMS sorgt dafür, dass sie auch ohne Netz, Identitätsmanagement oder Dokumentenplattform verfügbar bleiben. Die Lösung muss sicher, aktuell, offline erreichbar und praktisch getestet sein.
Gemeinsames Design: Das ISMS liefert Schutzanforderungen und Risikobegründung. Das BCMS ergänzt Zeitziele, Mindestleistung, Wiederanlaufreihenfolge und Szenariotauglichkeit. Eine Maßnahme – aber deutlich belastbarer ausgelegt.
Um 03:17 Uhr braucht niemand zwei Lagebilder
Ein mittelständischer Maschinenbauer, 03:17 Uhr: Die Produktionssteuerung reagiert nicht mehr. Mehrere Systeme zeigen Auffälligkeiten. In zwei Tagen muss ein wichtiger Kundenauftrag ausgeliefert werden.
Das Incident-Response-Team isoliert Systeme und trennt Netze. Aus Sicherheitssicht ist das richtig. Gleichzeitig steht die Produktion. Das BCM drängt auf Wiederanlauf. IT und BCM handeln – aber nicht zwingend auf Grundlage desselben Lagebilds.
Jetzt fehlen die Übersetzungen: Welche Prozesse hängen an der Produktionssteuerung? Welche Aufträge und Informationswerte sind betroffen? Was lässt sich manuell fortführen? Welche Abhängigkeit blockiert den Wiederanlauf? Und wie wächst der Schaden nach zwei, sechs oder vierundzwanzig Stunden?
Das gemeinsame Modell übersetzt den technischen Status in ein geschäftliches Lagebild. Aus „Produktionssteuerung nicht verfügbar“ werden betroffene Prozesse, Tätigkeiten, Abhängigkeiten, Zeitvorgaben, Backups und Dienstleister. Der Krisenstab sieht nicht nur den Ausfall. Er sieht seine Bedeutung und kann Handlungsoptionen bewerten.
Cyber-Resilienz entsteht nicht erst um 03:17 Uhr. Dann zeigt sich, ob die Disziplinen zuvor ein gemeinsames System geschaffen haben, das auch unter Druck trägt.
Von getrennten Managementsystemen zu gemeinsamer Resilienz
ISMS und BCMS bleiben eigenständige Disziplinen. Aber sie dürfen nicht an unterschiedlichen Realitäten derselben Organisation andocken.
Tätigkeiten, Abhängigkeiten und BCM-Ressourcen im gemeinsamen Modell sind deshalb kein zusätzlicher Ballast. Sie sind notwendig, um ISO/IEC 27001 und ISO 22301 konsistent umzusetzen und um die Lücke zwischen Schutzbedarf, Business Impact, Risikobehandlung und Wiederanlaufplanung zu schließen.
Im Ernstfall helfen keine Teams, die jeweils recht haben, aber aneinander vorbeiarbeiten. Resilienz entsteht, wenn ISMS und BCMS auf einem gemeinsamen Weltbild aufbauen, Maßnahmen abstimmen und unter Druck ein entscheidungsfähiges Lagebild schaffen.
Nebeneinander ist organisiert. Miteinander entsteht Resilienz.
Dieser Beitrag wurde mit Unterstützung von KI erstellt.
