Praxisorientierte Einordnung zu Informationssicherheitsrisiken bewerten: Methode, Kriterien und Akzeptanz: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für ISMS Beratung aufbauen.
Informationssicherheitsrisiken werden häufig mit farbigen Matrizen bewertet, doch die entscheidende Arbeit findet vor der Farbe statt. Eine belastbare Bewertung muss erklären, welches Geschäftsziel gefährdet ist, durch welches Ereignis ein Schaden entstehen kann, welche Kontrollen bereits wirken und wer das verbleibende Risiko tragen darf. Ohne diese Logik werden Zahlen schnell zu Scheingenauigkeit. Dieser Fachbeitrag zeigt eine Methode, die ISO/IEC 27005, BSI-Standard 200-3 und NIST SP 800-30 praktisch zusammenführt und für Managemententscheidungen nutzbar macht.
Risiko ist ein mögliches Geschäftsergebnis, keine technische Schwachstelle
Eine ungepatchte Software, ein öffentlich erreichbarer Dienst oder ein fehlendes Vier-Augen-Prinzip sind zunächst Schwachstellen beziehungsweise Kontrolllücken. Ein Risiko entsteht daraus erst im Zusammenhang mit Bedrohung, betroffenen Informationswerten und möglichen Auswirkungen. Die Formulierung „Risiko: Ransomware“ ist deshalb zu kurz. Sie beschreibt weder den Eintrittspfad noch die geschäftliche Konsequenz und lässt offen, welche Behandlung sinnvoll wäre.
Ein entscheidungsfähiges Szenario könnte lauten: Ein Angreifer nutzt kompromittierte Fernwartungszugänge, verschlüsselt Systeme der Produktionsplanung und verhindert dadurch für mehrere Tage die termingerechte Belieferung wesentlicher Kunden. Diese Aussage verbindet Ursache, Ereignis, Ziel und Wirkung. Sie kann mit bestehenden Kontrollen, Wiederanlaufzeiten, Vertragsfolgen und Risikoeigentümern angereichert werden. Erst dann lohnt sich eine Einstufung.
Normative Leitplanken richtig nutzen
ISO/IEC 27005 beschreibt den gesamten Kreislauf des Informationssicherheits-Risikomanagements: Risiken werden identifiziert, analysiert, bewertet, behandelt, kommuniziert, überwacht und überprüft. Das BSI strukturiert die Risikoanalyse in Gefährdungsübersicht, Risikoeinstufung, Behandlung und Konsolidierung des Sicherheitskonzepts. NIST SP 800-30 trennt Vorbereitung, Durchführung und laufende Pflege einer Bewertung. Die Modelle verwenden unterschiedliche Begriffe, verfolgen aber denselben Kern: Bewertungen benötigen Kontext, definierte Kriterien, belastbare Informationen und eine Verbindung zu Entscheidungen.
Keines dieser Modelle verlangt eine universelle Formel. Organisationen dürfen qualitative, quantitative oder gemischte Ansätze verwenden, solange sie zur Entscheidung passen und konsistent angewendet werden. Die Methode sollte so einfach sein, dass Risikoeigentümer sie verstehen, und so differenziert, dass sehr verschiedene Auswirkungen nicht in derselben Sammelkategorie verschwinden.
Schritt 1: Zweck und Entscheidung der Bewertung festlegen
Bevor Szenarien gesammelt werden, muss klar sein, wozu die Bewertung dient. Ein unternehmensweites Risikoprofil benötigt eine andere Granularität als die Freigabe einer Cloud-Anwendung oder die Bewertung eines neuen Produktionsstandorts. Definieren Sie Entscheidungsadressaten, Zeithorizont, Geltungsbereich, erforderliche Genauigkeit und verfügbares Wissen. Eine Methode, die bei knappen Daten absolute Eurobeträge erzwingt, produziert keine höhere Qualität.
Halten Sie außerdem fest, welche Entscheidungen aus den Ergebnissen folgen können: Kontrollinvestition, Vermeidung, Transfer, zeitlich befristete Akzeptanz oder vertiefende Analyse. Fehlt ein Handlungskanal, wächst nur ein Risikoregister. Gute Assessments enden mit einem klaren Eigentümer und einer Entscheidung, nicht mit einem Score.
Schritt 2: Bewertungsobjekt und Systemgrenzen bestimmen
Beschreiben Sie, welche Geschäftsleistung, Information, Anwendung, Infrastruktur oder Lieferkette betrachtet wird. Dokumentieren Sie Abhängigkeiten, Schnittstellen und Annahmen. Bei einem SaaS-Dienst gehören Identitätsanbieter, Datenexport, Unterauftragnehmer und interne Anschlussprozesse zum relevanten Kontext. Bei OT-Systemen können physische Sicherheit, Fernwartung und Safety-Folgen entscheidend sein.
Eine zu enge Grenze unterschätzt Kaskadeneffekte; eine zu breite Grenze führt zu unscharfen Szenarien. Beginnen Sie bei der geschäftlichen Leistung und verfolgen Sie die wichtigsten technischen und organisatorischen Abhängigkeiten. Das verhindert, dass das Team einzelne Server bewertet, obwohl der Schaden aus dem Ausfall einer Ende-zu-Ende-Leistung entsteht.
Schritt 3: Informationsquellen und Unsicherheit erfassen
Nutzen Sie mehrere Datenquellen: Interviews, Asset- und Prozessdaten, Vorfälle, Schwachstellenbefunde, Architekturunterlagen, Bedrohungsinformationen, Tests, Lieferanteninformationen und Wiederanlaufübungen. Notieren Sie, wie aktuell und verlässlich jede Quelle ist. Eine Annahme über die Wiederherstellungsdauer hat eine andere Qualität, wenn sie aus einem erfolgreichen Restore-Test statt aus einer Planungsangabe stammt.
Unsicherheit sollte nicht versteckt werden. Verwenden Sie etwa eine zusätzliche Kennzeichnung für hohe, mittlere oder geringe Evidenzqualität. Ein scheinbar mittleres Risiko mit sehr unsicherer Datengrundlage kann eine kurzfristige Analyse oder einen Test rechtfertigen. Dadurch wird Informationsgewinn selbst zu einer legitimen Behandlung.
Schritt 4: Bedrohungsquellen und auslösende Ereignisse unterscheiden
Bedrohungsquellen können kriminelle Gruppen, Insider, Lieferantenfehler, Naturereignisse oder technische Ausfälle sein. Ein Bedrohungsereignis beschreibt, was diese Quelle auslöst: Zugangsdaten missbrauchen, Daten verändern, Stromversorgung unterbrechen oder eine fehlerhafte Konfiguration ausrollen. Die Trennung hilft, unterschiedliche Eintrittspfade und Kontrollen sichtbar zu machen.
Vermeiden Sie endlose Kataloge. Wählen Sie Szenarien, die aufgrund von Exponierung, Geschäftsmodell und beobachteten Veränderungen plausibel sind. Ergänzen Sie generische Gefährdungen um spezifische Ereignisse aus der eigenen Architektur. Ein Hersteller mit Fernwartungszugängen benötigt andere Szenarien als eine Plattform mit öffentlich zugänglichen APIs.
Schritt 5: Schwachstellen und prädisponierende Bedingungen benennen
Schwachstellen sind nicht nur Softwarefehler. Unklare Verantwortungen, fehlende Segmentierung, überbreite Berechtigungen, ungetestete Notfallpläne und Konzentration auf einen Dienstleister können den Eintritt oder die Auswirkung eines Ereignisses begünstigen. Dokumentieren Sie Bedingungen so konkret, dass eine Behandlung daran ansetzen kann.
Trennen Sie beobachtete Tatsachen von Vermutungen. „MFA fehlt für 14 privilegierte Konten“ ist belegbar. „Berechtigungen sind vermutlich zu weit“ verlangt zunächst eine Stichprobe. Diese Disziplin verbessert sowohl die Bewertung als auch die spätere Wirksamkeitskontrolle.
Schritt 6: Auswirkungen mehrdimensional bewerten
Eine einzige Schadenskategorie wird komplexen Folgen selten gerecht. Definieren Sie Kriterien für finanzielle Verluste, Betriebsunterbrechung, rechtliche Konsequenzen, Sicherheit von Menschen, Kundenwirkung, Reputation und strategische Nachteile. Beschreiben Sie jede Stufe mit konkreten Schwellen oder Beispielen aus dem eigenen Geschäft. „Hoch“ sollte für Produktion und Vertrieb dasselbe Grundverständnis besitzen.
Berücksichtigen Sie zeitliche Entwicklung. Ein vierstündiger Ausfall kann unkritisch beginnen und nach zwei Tagen existenzielle Lieferfolgen auslösen. Ebenso können viele kleine Datenschutzverletzungen kumulativ relevant sein. Legen Sie fest, ob der höchste Einzelwert, eine gewichtete Kombination oder ein plausibles Gesamtszenario die Auswirkungsstufe bestimmt.
Schritt 7: Eintrittswahrscheinlichkeit ohne Scheingenauigkeit schätzen
Wahrscheinlichkeit ergibt sich aus Bedrohungsaktivität, Exponierung, Attraktivität des Ziels, Wirksamkeit vorhandener Kontrollen und beobachteter Häufigkeit. Kategorien sollten durch Intervalle oder qualitative Anker beschrieben werden. „Selten“ kann beispielsweise bedeuten, dass ein Ereignis unter den gegebenen Bedingungen nur in Ausnahmefällen zu erwarten ist; die genaue Definition muss zur Branche und zum Zeithorizont passen.
Historische Abwesenheit ist kein Beweis für geringe Wahrscheinlichkeit. Neue Technologien und aktive Angreifer verändern die Lage schneller als interne Statistiken. Nutzen Sie deshalb Szenarioargumente und dokumentieren Sie die wichtigsten Treiber. Bei geringer Datenbasis ist eine Bandbreite oft ehrlicher als ein einzelner Prozentwert.
Schritt 8: Bestehende Kontrollen getrennt beurteilen
Bewerten Sie zunächst das inhärente Risiko ohne berücksichtigte Kontrollen und anschließend das Restrisiko unter realen Betriebsbedingungen. Listen Sie nur Kontrollen auf, deren Umsetzung und Wirkung belegbar ist. Eine Richtlinie reduziert kein Risiko, wenn sie nicht angewendet wird; ein Backup reduziert die Auswirkung erst nach nachgewiesenem Restore.
Kontrollwirksamkeit sollte Design und operative Leistung unterscheiden. Ein geeignetes Verfahren kann unzureichend ausgeführt werden, während eine konsequent ausgeführte Kontrolle konzeptionell am Szenario vorbeigeht. Für kritische Risiken sind Stichproben, Tests und technische Evidenz stärker als bloße Selbstauskünfte.
Schritt 9: Risikoklasse nachvollziehbar ableiten
Eine Matrix kombiniert Eintritt und Auswirkung zu einer Risikoklasse. Halten Sie die Logik einfach und überprüfen Sie, ob Randfälle zu sinnvollen Prioritäten führen. Eine symmetrische Fünf-mal-fünf-Matrix ist nicht automatisch geeignet: Sehr seltene, aber katastrophale Safety-Folgen dürfen nicht durch eine mittlere Farbe verharmlost werden. Definieren Sie deshalb Ausschlusskriterien und besondere Eskalationsregeln.
Dokumentieren Sie neben der Klasse die Begründung. Zwei gleichfarbige Risiken können völlig unterschiedliche Behandlungsoptionen und Dringlichkeiten besitzen. Der Score unterstützt die Sortierung, ersetzt aber keine Entscheidung.
Schritt 10: Kriterien für Akzeptanz festlegen
Risikotoleranz beschreibt, welche Exposition die Organisation in Verfolgung ihrer Ziele grundsätzlich tragen will. Akzeptanzkriterien übersetzen diese Haltung in Schwellen, Genehmigungsrechte und Bedingungen. Definieren Sie, welche Klassen auf welcher Ebene akzeptiert werden dürfen, welche Folgen niemals akzeptabel sind und wann eine unabhängige Prüfung erforderlich ist.
Akzeptanzen sollten befristet und an Annahmen gebunden sein. Wird ein Lieferant kritischer, ändert sich die Bedrohungslage oder scheitert ein Restore-Test, muss die Entscheidung erneut auf den Tisch. Eine dauerhaft grüne Tabellenzeile ohne Wiedervorlage ist kein gesteuertes Restrisiko.
Vier Behandlungsoptionen sauber unterscheiden
Risiken können vermieden, reduziert, übertragen beziehungsweise geteilt oder akzeptiert werden. Vermeidung beendet die risikobegründende Tätigkeit, etwa durch Verzicht auf eine unsichere Funktion. Reduktion verändert Wahrscheinlichkeit oder Auswirkung durch Kontrollen. Transfer kann finanzielle Folgen verteilen, beseitigt aber selten Verantwortung oder operative Schäden. Akzeptanz ist eine bewusste Managemententscheidung, keine Bezeichnung für vergessene Maßnahmen.
Ein Behandlungsplan braucht Zielrisiko, Eigentümer, Termin, Ressourcen und Erfolgskriterien. Prüfen Sie nach Umsetzung, ob die angenommene Wirkung eingetreten ist. Wenn Segmentierung zwar eingeführt, aber durch zahlreiche Ausnahmen durchlässig bleibt, muss das Restrisiko neu bewertet werden.
Praxisbeispiel: Kompromittierter Cloud-Administrator
Ein Unternehmen betreibt seine Kundenplattform in einer Public Cloud. Das Szenario lautet: Durch Phishing werden privilegierte Zugangsdaten kompromittiert; ein Angreifer verändert Sicherheitsgruppen, exfiltriert Kundendaten und löscht produktive Ressourcen. Hohe Auswirkungen ergeben sich aus Betriebsunterbrechung, Vertragsfolgen und Datenschutz. Die Eintrittseinschätzung berücksichtigt Exponierung, Phishing-Aktivität, Zahl privilegierter Konten und Schutz der Administrationswege.
Vorhandene Kontrollen sind Mehrfaktor-Authentisierung, getrennte Administrationskonten, unveränderbare Backups, Logging und ein Freigabeprozess für kritische Änderungen. Die Bewertung zeigt jedoch, dass Sitzungsdiebstahl nicht ausreichend erkannt und Notfallzugänge nicht getestet werden. Die Behandlung kombiniert phishingresistente Authentisierung, just-in-time Berechtigungen, Alarmierung kritischer Änderungen und eine Wiederherstellungsübung. Der Risikoeigentümer akzeptiert das verbleibende Risiko erst nach Evidenz aus Tests.
Praxisbeispiel: Manipulation einer Produktionsrezeptur
Bei einem Lebensmittelhersteller könnte ein kompromittierter Fernwartungszugang Parameter einer Produktionslinie verändern. Die Folge betrifft nicht nur Verfügbarkeit, sondern potenziell Produktqualität und Verbrauchersicherheit. Eine rein finanzielle Matrix würde das Szenario unzureichend abbilden. Deshalb erhält die Kategorie „Sicherheit und Gesundheit“ eine eigene, nicht durch geringe Wahrscheinlichkeit relativierbare Eskalationsregel.
Behandlungsmaßnahmen umfassen kontrollierte Fernwartungsfenster, starke Authentisierung, Segmentierung, Protokollierung von Parameteränderungen und unabhängige Plausibilitätsprüfungen. Zusätzlich werden Rückruf- und Produktionsstoppszenarien geübt. Das Beispiel zeigt, warum Risikomethoden an Geschäftsmodell und Schadenstypen angepasst werden müssen.
Risiken aggregieren, ohne sie zu verwischen
Managementberichte benötigen Verdichtung. Gruppieren Sie Szenarien nach Geschäftsleistung, Risikotreiber oder Kontrollthema, erhalten Sie aber die Verbindung zu den Einzelszenarien. Zehn Risiken, die auf unzureichendes Identitätsmanagement zurückgehen, können gemeinsam eine strategische Initiative begründen. Ihre individuellen Auswirkungen und Eigentümer bleiben trotzdem sichtbar.
Achten Sie auf Korrelationen und Konzentration. Der Ausfall eines Identitätsproviders kann viele Anwendungen gleichzeitig treffen; mehrere Lieferanten können vom selben Cloud- oder Netzbetreiber abhängen. Eine einfache Summe unabhängiger Einzelrisiken unterschätzt solche Kaskaden.
Qualitätssicherung der Bewertung
Nutzen Sie Moderation, Peer Review und Kalibrierungsbeispiele. Teams sollten ausgewählte Szenarien gemeinsam bewerten und Unterschiede in der Interpretation besprechen. Prüfen Sie, ob dieselben Kriterien in IT, OT, Produktentwicklung und Fachbereichen konsistent angewendet werden. Ein Methodeneigentümer pflegt Definitionen und dokumentiert Änderungen, darf aber nicht alle Geschäftsentscheidungen selbst treffen.
Führen Sie Stichproben von der Risikoaussage bis zum Nachweis und zurück. Ist der betroffene Prozess im Scope? Sind Kontrollen belegt? Hat der Eigentümer die Behandlung freigegeben? Wurde die Wirkung überprüft? Diese Rückverfolgbarkeit ist wichtiger als ein komplexes Werkzeug.
Wann Risiken neu bewertet werden müssen
Ein jährlicher Zyklus ist nur die Mindeststruktur. Trigger sind schwere Vorfälle, neue Schwachstellen mit realer Exponierung, Architekturänderungen, neue Lieferanten, Akquisitionen, regulatorische Veränderungen und fehlgeschlagene Kontrolltests. Definieren Sie für jedes Risiko eine Überwachungsfrequenz und Ereignisse, die eine außerplanmäßige Prüfung auslösen.
Beobachten Sie außerdem Annahmen. Wenn die Bewertung von einer Wiederherstellung in acht Stunden ausgeht, muss ein Test mit deutlich längerer Dauer automatisch zur Neubewertung führen. So bleibt das Register ein Steuerungsinstrument statt ein historisches Archiv.
Typische Fehler in Risikoworkshops
Dominante Stimmen, unklare Begriffe und Zeitdruck erzeugen Gruppenurteile ohne Begründung. Schicken Sie Kontext und Kriterien vorab, trennen Sie Szenariobeschreibung von Bewertung und protokollieren Sie abweichende Einschätzungen. Vermeiden Sie, dass Diskussionen sofort in Lieblingslösungen springen; zunächst muss klar sein, welches Risiko tatsächlich behandelt wird.
Ein weiterer Fehler ist die Vermischung von aktuellem und gewünschtem Kontrollzustand. Bewerten Sie nur, was heute wirksam belegt ist. Geplante Maßnahmen gehören in den Behandlungsplan und bestimmen das Zielrisiko, nicht das aktuelle Restrisiko.
Werkzeuge und Automatisierung angemessen einsetzen
GRC-Software kann Beziehungen, Fristen, Freigaben und Berichte unterstützen. Sie kann jedoch keine guten Szenarien erzeugen oder geschäftliche Auswirkungen entscheiden. Beginnen Sie mit Datenmodell und Prozess, bevor Sie ein Werkzeug konfigurieren. Pflichtfelder sollten Begründung und Evidenz fördern, nicht nur Zahlen erzwingen.
Automatisieren Sie aktuelle Informationen wie Asset-Eigentümer, Schwachstellenstatus oder Kontrolltests, wenn Datenqualität und Verantwortlichkeiten geklärt sind. Die menschliche Bewertung bleibt für Kontext, Kaskaden und Risikoakzeptanz erforderlich. Ein dynamisches Dashboard ohne belastbare Grundannahmen beschleunigt nur schlechte Entscheidungen.
Vom Risikoregister zum Managementdialog
Berichten Sie nicht jede Zeile. Zeigen Sie wesentliche Szenarien, Veränderungen, überfällige Behandlungen, Konzentrationen und Entscheidungen, die das Management treffen muss. Erläutern Sie Bandbreiten und Unsicherheiten. Ein guter Bericht verbindet Risiko mit Geschäftsziel, Verantwortlichem und Handlungsalternative.
Professionelle ISMS-Beratung unterstützt insbesondere bei der Kalibrierung von Kriterien, der Moderation kritischer Szenarien und der Verzahnung mit bestehenden Enterprise-Risk-Prozessen. Ziel ist keine externe Dauerbewertung, sondern eine Methode, die Eigentümer selbstständig und konsistent anwenden können.
Fazit: Eine gute Bewertung macht Entscheidungen nachvollziehbar
Informationssicherheitsrisiken lassen sich nicht durch eine universelle Formel objektivieren. Belastbarkeit entsteht durch klare Szenarien, passende Wirkungskriterien, belegte Kontrollen, sichtbare Unsicherheit und definierte Akzeptanzrechte. Wer Bewertung und Behandlung als fortlaufenden Dialog zwischen Fachbereichen, Technik und Leitung gestaltet, erhält ein Risikoregister, das Investitionen priorisiert und Veränderungen steuert.
