Eine IT-Risikoanalyse zeigt, welche Gefahren der IT eines Unternehmens drohen, wie wahrscheinlich sie eintreten und welchen Schaden sie anrichten würden. Aus dem Ergebnis folgt, welche Risiken Sie zuerst angehen, welche Sie absichern oder übertragen und welche Sie bewusst tragen.
Klingt nach Theorie, ist aber das Werkzeug, mit dem sich Sicherheitsbudgets begründen lassen. Wer der Geschäftsleitung sagen kann, dass ein Ausfall der Warenwirtschaft mehrmals im Jahr droht und den Versand für Tage stoppt, bekommt eher Geld für Backups als jemand, der nur „mehr Sicherheit“ fordert. Dieser Beitrag erklärt die Methode nach BSI-Standard 200-3, zeigt ein durchgerechnetes Beispiel und liefert eine Vorlage für Ihr Risikoregister.
Was ist eine IT-Risikoanalyse?
Bei der IT-Risikoanalyse werden für Systeme, Anwendungen und Informationen die möglichen Gefährdungen ermittelt und bewertet. Jedes Risiko ergibt sich aus zwei Größen: der Häufigkeit, mit der ein Ereignis eintritt, und dem Schaden, den es verursacht. Aus der Kombination entsteht eine Risikostufe, die über die Behandlung entscheidet.
Wichtig ist der Unterschied zwischen Gefährdung und Risiko. Ransomware ist eine Gefährdung. Ein Risiko wird daraus erst im Zusammenhang: Ransomware auf einem Dateiserver ohne getrenntes Backup ist ein anderes Risiko als Ransomware auf einem Testrechner ohne Daten.
Wann eine IT-Risikoanalyse nötig ist
Grundsätzlich gehört eine Risikoanalyse zu jedem ernsthaften Sicherheitskonzept. Wer nach IT-Grundschutz arbeitet, muss sie nach Auffassung des BSI aber nicht für jedes System durchführen. Für die meisten Zielobjekte genügen die Standardanforderungen aus dem IT-Grundschutz-Kompendium. Eine zusätzliche Risikoanalyse ist nach BSI-Standard 200-3 erforderlich, wenn
- ein System oder eine Anwendung in Vertraulichkeit, Integrität oder Verfügbarkeit einen hohen oder sehr hohen Schutzbedarf hat,
- es für das Zielobjekt keinen passenden Baustein gibt oder
- das Objekt in einer für den IT-Grundschutz untypischen Umgebung betrieben wird.
Unabhängig davon verlangen mehrere Regelwerke eine Risikoanalyse. Für besonders wichtige und wichtige Einrichtungen schreibt § 30 Abs. 2 Nr. 1 BSIG „Konzepte in Bezug auf die Risikoanalyse“ vor. ISO/IEC 27001 verlangt eine Risikobeurteilung als Kern des Managementsystems, und die DSGVO fordert Schutzmaßnahmen, die dem Risiko angemessen sind.
Voraussetzung: Schutzbedarf und Bestandsaufnahme
Eine Risikoanalyse ohne Bestandsaufnahme bleibt Raten. Bevor Sie Risiken bewerten, sollten zwei Dinge feststehen:
- Welche Systeme, Anwendungen, Räume und Dienstleister gibt es? Ohne vollständige Liste fallen genau die Systeme durch, um die sich niemand kümmert.
- Wie schutzbedürftig sind sie? Die Schutzbedarfsfeststellung stuft jedes Objekt als normal, hoch oder sehr hoch ein. Sie bestimmt, wo sich eine vertiefte Analyse lohnt.
Beides ist Teil des IT-Sicherheitskonzepts, in das die Ergebnisse der Risikoanalyse am Ende wieder einfließen.
IT-Risikoanalyse nach BSI-Standard 200-3 in sechs Schritten
Der BSI-Standard 200-3 beschreibt ein schlankes Vorgehen, das auch ohne eigene Risikomanagement-Abteilung funktioniert. In der Praxis lässt es sich auf sechs Schritte verdichten.
1. Zielobjekte festlegen
Wählen Sie die Objekte aus, für die eine Analyse nötig ist, typischerweise alles mit hohem oder sehr hohem Schutzbedarf: die Warenwirtschaft, die Produktionssteuerung, die Lohnbuchhaltung, den Fernwartungszugang. Halten Sie den Kreis klein genug, dass die Analyse in überschaubarer Zeit fertig wird.
2. Gefährdungsübersicht erstellen
Das BSI liefert dafür einen Katalog von 47 elementaren Gefährdungen, von G 0.1 „Feuer“ über G 0.23 „Unbefugtes Eindringen in IT-Systeme“ bis G 0.39 „Schadprogramme“. Für jedes Zielobjekt prüfen Sie, welche davon relevant sind. Der Katalog ist bewusst allgemein gehalten, damit nichts Wesentliches übersehen wird.
3. Gefährdungsübersicht ergänzen
Ergänzen Sie, was der Katalog nicht abdeckt: branchentypische Gefahren, Abhängigkeiten von einem einzigen Dienstleister, bekannte Schwachstellen in eingesetzter Software, Erfahrungen aus früheren Vorfällen. Hier zahlt sich das Wissen der Fachbereiche aus.
4. Häufigkeit und Schaden einschätzen
Für jede relevante Gefährdung schätzen Sie ab, wie oft sie eintreten könnte und welcher Schaden dann entstünde. Das BSI schlägt jeweils vier Stufen vor:
| Häufigkeit | Bedeutung |
|---|---|
| selten | höchstens alle fünf Jahre |
| mittel | etwa alle fünf Jahre bis einmal im Jahr |
| häufig | etwa einmal im Jahr bis einmal im Monat |
| sehr häufig | mehrmals im Monat |
| Schadenshöhe | Bedeutung |
|---|---|
| vernachlässigbar | Auswirkungen sind gering und können außer Acht gelassen werden |
| begrenzt | Auswirkungen sind begrenzt und überschaubar |
| beträchtlich | Auswirkungen können erheblich sein |
| existenzbedrohend | Auswirkungen können ein existenzbedrohendes Ausmaß erreichen |
Die Stufen dürfen Sie an Ihr Unternehmen anpassen. Hilfreich ist, „beträchtlich“ mit einer konkreten Größe zu hinterlegen, etwa einem Umsatzausfall ab einer bestimmten Summe oder einem Stillstand ab einer bestimmten Dauer. Dann bewerten alle Beteiligten nach demselben Maßstab.
5. Risiken bewerten
Aus Häufigkeit und Schaden ergibt sich in einer Risikomatrix die Risikostufe. Das BSI unterscheidet vier Kategorien:
- gering: Die vorhandenen oder geplanten Maßnahmen bieten ausreichenden Schutz.
- mittel: Die Maßnahmen reichen möglicherweise nicht aus.
- hoch: Die Maßnahmen reichen nicht aus, das Risiko ist mit großer Wahrscheinlichkeit nicht tragbar.
- sehr hoch: Die Maßnahmen reichen nicht aus, das Risiko ist mit sehr großer Wahrscheinlichkeit nicht tragbar.
Bewerten Sie das Risiko unter Berücksichtigung der Schutzmaßnahmen, die bereits wirken. Ein Server mit getestetem Offline-Backup hat bei Ransomware ein deutlich geringeres Risiko als derselbe Server ohne.
6. Risiken behandeln
Für jedes Risiko oberhalb der festgelegten Grenze entscheiden Sie, wie es behandelt wird. Das BSI nennt vier Optionen:
| Option | Was passiert | Beispiel |
|---|---|---|
| A: Vermeiden | Prozess so umstellen, dass die Gefährdung nicht mehr wirkt | veraltetes System, das nicht mehr gebraucht wird, abschalten |
| B: Reduzieren | zusätzliche Sicherheitsmaßnahmen umsetzen | Multi-Faktor-Authentifizierung für den Fernzugang |
| C: Übertragen | Risiko auf Dritte verlagern | Cyberversicherung oder Auslagerung an einen Dienstleister |
| D: Akzeptieren | Risiko bewusst tragen | Schutzmaßnahme wäre unverhältnismäßig teuer |
Akzeptierte Risiken sollten schriftlich festgehalten und von der Geschäftsleitung abgezeichnet werden. Bei einer Prüfung ist das einer der ersten Punkte, nach denen gefragt wird.
Beispiel: Ransomware auf dem Dateiserver
Nehmen wir einen Maschinenbauer mit 120 Beschäftigten an, der seinen zentralen Dateiserver bewertet. Darauf liegen Konstruktionsdaten, Angebote und Teile der Auftragsabwicklung. Das Beispiel ist ausgedacht und vereinfacht, zeigt aber, wie sich ein Risiko durch Maßnahmen verändert.
| Schritt | Vorher | Nach Maßnahmen |
|---|---|---|
| Gefährdung | G 0.39 Schadprogramme (Ransomware) | unverändert |
| Bestehender Schutz | Virenschutz, Backup auf NAS im selben Netz | zusätzlich: Offline-Backup, getrennte Admin-Konten, MFA, Überwachung |
| Häufigkeit | häufig: Phishing-Versuche gehen wöchentlich ein, ein Treffer innerhalb eines Jahres ist realistisch | mittel |
| Schaden | existenzbedrohend: Backup würde mitverschlüsselt, Konstruktion und Auftragsabwicklung stünden still | begrenzt: Wiederherstellung aus Offline-Backup innerhalb eines Tages |
| Risiko | sehr hoch | gering bis mittel |
| Behandlung | B: Reduzieren | D: Restrisiko akzeptieren, jährlich prüfen |
Der entscheidende Hebel war hier nicht der Virenschutz, sondern das vom Netz getrennte Backup. Es senkt den Schaden von „existenzbedrohend“ auf „begrenzt“. Genau solche Erkenntnisse macht eine Risikoanalyse sichtbar.
Vorlage: So ist ein Risikoregister aufgebaut
Die Ergebnisse gehören in ein Risikoregister. Eine Tabelle genügt für den Anfang, wichtig ist, dass jedes Risiko eine verantwortliche Person und einen Termin hat. Diese Spalten haben sich bewährt:
| Spalte | Inhalt |
|---|---|
| Nr. | laufende Nummer, damit Maßnahmen und Berichte darauf verweisen können |
| Zielobjekt | System, Anwendung oder Prozess |
| Gefährdung | mit Kennung aus dem BSI-Katalog, wenn vorhanden |
| Bestehende Maßnahmen | was heute schon schützt |
| Häufigkeit und Schaden | jeweils mit kurzer Begründung |
| Risikostufe | gering, mittel, hoch oder sehr hoch |
| Behandlung | Vermeiden, Reduzieren, Übertragen oder Akzeptieren |
| Maßnahme, Verantwortliche, Termin | was bis wann von wem umgesetzt wird |
| Restrisiko und Freigabe | Risikostufe nach Umsetzung, Datum und Name der Freigabe |
Ab einer gewissen Größe wird die Tabelle unübersichtlich. Dann hilft eine GRC-Software, die Risiken, Maßnahmen und Nachweise an einem Ort verwaltet und an Fristen erinnert.
Qualitativ oder quantitativ bewerten?
Die Methode nach BSI-Standard 200-3 ist qualitativ: Sie arbeitet mit Stufen statt mit Euro-Beträgen. Das hat einen praktischen Grund. Für die meisten Cyberrisiken gibt es keine verlässlichen Zahlen, aus denen sich eine Eintrittswahrscheinlichkeit von 3,7 Prozent berechnen ließe. Scheinbar genaue Werte täuschen dann eine Präzision vor, die es nicht gibt.
Quantitative Ansätze, die Schäden in Geld ausdrücken, lohnen sich vor allem dort, wo Zahlen vorliegen, etwa beim Umsatzverlust pro Stunde Stillstand. Viele Unternehmen kombinieren beides: qualitative Stufen für die Bewertung, Euro-Beträge als Hilfe bei der Einordnung der Schadenshöhe.
BSI-Standard 200-3 oder ISO 27005?
Wer ein ISMS nach ISO/IEC 27001 betreibt, findet in der Norm ISO/IEC 27005 einen Leitfaden zum Risikomanagement. Sie lässt mehr Freiheit bei der Methode und legt weniger fest. Der BSI-Standard 200-3 ist enger an den IT-Grundschutz gekoppelt und bringt mit dem Gefährdungskatalog eine fertige Grundlage mit. Für mittelständische Unternehmen ohne eigene Risikomanagement-Abteilung ist das oft der leichtere Einstieg. Ein Zertifikat nach ISO 27001 auf Basis von IT-Grundschutz ist möglich, die Methoden schließen sich also nicht aus.
Wann die Analyse wiederholt werden muss
Eine Risikoanalyse ist eine Momentaufnahme. Prüfen Sie sie mindestens einmal im Jahr und zusätzlich, wenn sich die Lage ändert:
- neue Systeme, Cloud-Dienste oder Standorte
- Wechsel wichtiger Dienstleister
- ein Sicherheitsvorfall, auch ein glimpflich verlaufener
- neue gesetzliche Pflichten oder Kundenanforderungen
- neu bekannt gewordene Angriffsmuster in Ihrer Branche
Typische Fehler bei der IT-Risikoanalyse
- Alles ist „hoch“: Wenn jedes Risiko dieselbe Stufe bekommt, lässt sich nichts priorisieren. Eine Bewertung braucht den Mut zur Abstufung.
- Bewertung ohne Begründung: Ein Jahr später weiß niemand mehr, warum ein Risiko als „mittel“ eingestuft wurde. Ein Satz Begründung pro Bewertung genügt.
- Nur Technik betrachtet: Fehlbedienung, Ausfall eines Schlüsselmitarbeiters oder ein insolventer Dienstleister sind ebenso Gefährdungen.
- Keine Verantwortlichen: Maßnahmen ohne Namen und Termin bleiben liegen.
- Analyse ohne Folgen: Eine Risikoanalyse, die im Ordner verschwindet, hat nur Arbeit gekostet. Sie muss in den Maßnahmenplan und das Budget einfließen.
Wenn Ihnen für die Risikoanalyse Zeit oder Methodik fehlt, übernimmt unsere IT-Sicherheitsberatung die Moderation und Bewertung gemeinsam mit Ihrem Team.
Fazit: Erst bewerten, dann investieren
Die IT-Risikoanalyse beantwortet die Frage, wo jeder Euro für IT-Sicherheit am meisten bewirkt. Mit dem BSI-Standard 200-3, einem Gefährdungskatalog und einer einfachen Matrix lässt sie sich auch im Mittelstand mit vertretbarem Aufwand umsetzen. Entscheidend sind eine ehrliche Bestandsaufnahme, begründete Bewertungen und ein Risikoregister, das gepflegt wird.
Sie möchten wissen, wo Ihre größten Risiken liegen? Unser IT Security Audit zum Festpreis liefert Schwachstellen, Reifegrad und einen priorisierten Maßnahmenplan als Grundlage für Ihre Risikoanalyse. Für die laufende Steuerung von Risiken und Nachweisen unterstützen wir Sie mit GRC-Lösungen.
