Die ISMS-Risikoanalyse nach ISO 27001 läuft in vier Schritten: Informationswerte erfassen, Bedrohungen und Schwachstellen zuordnen, Risiken nach Eintrittswahrscheinlichkeit und Schadensausmaß bewerten und über die Behandlung entscheiden – vermindern, vermeiden, übertragen oder akzeptieren. Das Verfahren muss definierte Kriterien haben und bei Wiederholung vergleichbare Ergebnisse liefern.
Die Risikoanalyse ist der Punkt, an dem viele ISMS-Projekte entweder Fahrt aufnehmen oder sich hoffnungslos verzetteln. Zu abstrakt angegangen, produziert sie Tabellen mit hunderten Zeilen, die niemand mehr pflegt. Zu oberflächlich behandelt, fehlt dem gesamten Managementsystem das Fundament – denn jede Maßnahme, jedes Dokument und jede Auditfrage führt letztlich auf sie zurück.
Dieser Artikel beschreibt ein praxistaugliches Verfahren in vier Schritten, wie es sich für kleine und mittlere Unternehmen bewährt hat: von der Erfassung der Informationswerte über die Bewertung bis zur Behandlungsentscheidung. Dazu ein konkretes Beispiel aus einem IT-Dienstleister und die Fehler, die in Audits am häufigsten auffallen.
Was die Norm verlangt – und was sie offenlässt
ISO 27001 schreibt in Kapitel 6.1.2 keinen bestimmten Rechenweg vor, sondern Eigenschaften des Verfahrens: Es braucht definierte Kriterien für Risikoakzeptanz und für die Durchführung, es muss bei Wiederholung vergleichbare und nachvollziehbare Ergebnisse liefern, Risiken müssen identifiziert, analysiert und bewertet werden, und jedes Risiko braucht einen benannten Risikoeigentümer. Wie granular Sie arbeiten, welche Skalen Sie verwenden, ob Sie mit Software oder Tabellenkalkulation arbeiten – all das ist Ihre Entscheidung.
Diese Freiheit ist eine Chance für kleine Unternehmen: Ein schlankes, konsequent gepflegtes Verfahren mit 30 Risiken schlägt im Audit jede importierte 800-Zeilen-Matrix. Als methodische Leitplanke dient ISO 27005, die Risikomanagement für Informationssicherheit ausführlich beschreibt – lesenswert, aber nicht verpflichtend.
Wichtig für das Verständnis: Die Risikoanalyse ist kein einmaliges Projektartefakt. Kapitel 8.2 verlangt ihre Wiederholung in geplanten Abständen – üblich ist jährlich – sowie bei wesentlichen Änderungen. Das Verfahren sollte also so dimensioniert sein, dass es sich mit vertretbarem Aufwand wiederholen lässt. Genau daran scheitern überkomplexe Ansätze regelmäßig.
Schritt 1: Informationswerte erfassen
Am Anfang steht die Frage: Was ist überhaupt schützenswert? Erfasst werden Informationswerte (Assets) – nicht nur Hardware, sondern alles, was Informationen trägt oder verarbeitet:
- Primäre Werte: die Informationen selbst – Kundendaten, Verträge, Kalkulationen, Quellcode, Zugangsdaten, Geschäftsgeheimnisse.
- Systeme und Anwendungen: ERP, E-Mail, Fileserver, Cloud-Dienste, Branchensoftware, Website.
- Infrastruktur: Netzwerk, Server, Endgeräte, Telefonanlage, Gebäudetechnik.
- Dienstleister: IT-Betreuer, Rechenzentren, SaaS-Anbieter, Steuerberater mit Datenzugriff.
- Menschen und Wissen: Schlüsselpersonen, deren Ausfall kritische Abläufe stoppt.
Der wichtigste Praxisrat: gruppieren statt atomisieren. Nicht jeder Laptop ist ein eigenes Asset – die Gruppe „mobile Endgeräte“ reicht, solange alle Geräte gleich behandelt werden. Für ein Unternehmen mit 10 bis 25 Mitarbeitenden sind 20 bis 40 Asset-Einträge ein gesundes Maß. Jeder Eintrag bekommt einen Verantwortlichen und eine grobe Einstufung, wie kritisch er für Vertraulichkeit, Integrität und Verfügbarkeit ist – das steuert später die Tiefe der Betrachtung.
Schritt 2: Bedrohungen und Schwachstellen zuordnen
Im zweiten Schritt wird je Asset gefragt: Was kann schiefgehen – und warum bei uns? Ein Risiko entsteht immer aus dem Zusammentreffen einer Bedrohung mit einer Schwachstelle. Die Bedrohung „Ransomware“ wird erst dadurch zum konkreten Risiko, dass Backups nie getestet wurden oder Makros ungefiltert ins Haus kommen.
Typische Bedrohungskategorien als Denkraster: Angriffe von außen (Phishing, Ransomware, Ausnutzung von Schwachstellen), menschliche Fehler (Fehlversand, Fehlkonfiguration, verlorene Geräte), Innentäter und ausscheidende Mitarbeitende, technisches Versagen (Hardwaredefekt, Softwarefehler), Ausfall von Dienstleistern und Cloud-Anbietern sowie physische Ereignisse (Feuer, Wasser, Einbruch, Stromausfall). Wer systematischer arbeiten will, findet in den Anhängen der ISO 27005 und in den Gefährdungskatalogen des BSI umfangreiche Listen – als Inspirationsquelle, nicht zum Komplettabschreiben.
Formulieren Sie Risiken als Szenario mit Ursache und Folge: „Verschlüsselung des Fileservers durch Ransomware nach Phishing-Mail führt zu mehrtägigem Betriebsstillstand“ ist bewertbar. „Hackerangriff“ ist es nicht. Diese Präzision zahlt sich doppelt aus – bei der Bewertung und später bei der Auswahl wirksamer Maßnahmen.
Schritt 3: Eintrittswahrscheinlichkeit und Schaden bewerten
Jedes Risikoszenario wird nun in zwei Dimensionen bewertet: Wie wahrscheinlich ist der Eintritt, und wie groß wäre der Schaden? Bewährt haben sich vierstufige Skalen, weil sie die bequeme Mitte verhindern. Beispiel für die Eintrittswahrscheinlichkeit: 1 = unwahrscheinlich (seltener als alle fünf Jahre), 2 = möglich (etwa alle zwei bis fünf Jahre), 3 = wahrscheinlich (etwa jährlich), 4 = sehr wahrscheinlich (mehrmals jährlich). Beim Schaden zählt nicht nur Geld: Betriebsunterbrechung, Vertragsstrafen, DSGVO-Meldepflichten, Reputationsverlust – definieren Sie je Stufe konkrete Anker, etwa 1 = unter 5.000 Euro Gesamtschaden, 4 = existenzbedrohend oder über 250.000 Euro.
Der Risikowert ergibt sich als Produkt beider Werte, dargestellt in einer Risikomatrix von 1 bis 16. Entscheidend ist die vorab definierte Akzeptanzschwelle – etwa: Werte ab 9 müssen behandelt werden, 6 bis 8 werden mit Begründung entschieden, unter 6 gilt als akzeptabel. Bewerten Sie im Team, nicht allein: Geschäftsleitung, IT und Fachbereich schätzen Schäden oft sehr unterschiedlich ein, und genau diese Diskussion macht die Analyse belastbar. Halten Sie zu jeder Bewertung eine Kurzbegründung fest – sie macht die Ergebnisse im nächsten Jahr vergleichbar, wie es die Norm verlangt.
Schritt 4: Risiken behandeln – vier Optionen
Für jedes Risiko oberhalb der Akzeptanzschwelle fällt eine bewusste Entscheidung. Die Norm kennt vier Behandlungsoptionen:
| Option | Bedeutung | Beispiel |
|---|---|---|
| Vermindern | Maßnahmen senken Wahrscheinlichkeit oder Schaden | Multi-Faktor-Authentifizierung gegen Kontoübernahme; getestete Backups gegen Datenverlust |
| Vermeiden | Die riskante Tätigkeit wird eingestellt oder nicht begonnen | Altsystem ohne Updates wird abgeschaltet statt weiterbetrieben |
| Übertragen | Ein Dritter trägt das Risiko ganz oder teilweise | Cyberversicherung; Auslagerung des Hostings an einen Profi mit Verfügbarkeitszusage |
| Akzeptieren | Das Restrisiko wird bewusst und dokumentiert getragen | Ausfall der Website für wenige Stunden wird hingenommen, da kein Vertriebskanal |
Aus den Entscheidungen entsteht der Risikobehandlungsplan: je Risiko die gewählte Option, konkrete Maßnahmen, Verantwortliche und Termine. Die gewählten Maßnahmen werden anschließend mit Anhang A abgeglichen und im Statement of Applicability dokumentiert. Wichtig: Auch „übertragen“ und „akzeptieren“ sind legitime Entscheidungen – die Risikoeigentümer müssen sie nur bewusst treffen und die Geschäftsleitung muss die Restrisiken formell akzeptieren.
Beispiel: Auszug aus der Risikoanalyse eines IT-Dienstleisters
So sieht das Verfahren angewendet aus – fünf Zeilen aus der Analyse eines Managed-Service-Providers mit 18 Mitarbeitenden (Skalen 1–4, Risikowert = Wahrscheinlichkeit × Schaden, Behandlungspflicht ab 9):
| Risikoszenario | W | S | Wert | Behandlung |
|---|---|---|---|---|
| Ransomware verschlüsselt zentrale Systeme nach Phishing-Mail | 3 | 4 | 12 | Vermindern: MFA, E-Mail-Filter, Offline-Backup mit Restore-Tests, Awareness-Training |
| Admin-Zugänge eines ausgeschiedenen Mitarbeiters bleiben aktiv | 3 | 3 | 9 | Vermindern: Offboarding-Checkliste, quartalsweiser Berechtigungsreview |
| Ausfall des Cloud-ERP-Anbieters über mehr als 24 Stunden | 2 | 3 | 6 | Übertragen/akzeptieren: SLA geprüft, Exportroutine eingerichtet, Restrisiko akzeptiert |
| Laptop mit Kundendaten geht auf Dienstreise verloren | 3 | 2 | 6 | Vermindern: Festplattenverschlüsselung, Fernlöschung per MDM |
| Brand im Büro zerstört lokale Server | 1 | 4 | 4 | Akzeptieren: Georedundantes Backup vorhanden, Restrisiko unter Schwelle |
Bemerkenswert am Beispiel: Nur zwei von fünf Risiken liegen über der Behandlungsschwelle, und die Maßnahmen sind konkret genug, um sie einem Verantwortlichen mit Termin zuzuweisen. Genau diese Verbindung – vom Szenario über die Bewertung zur nachverfolgbaren Maßnahme – wollen Auditoren sehen.
Die häufigsten Fehler – und wie Sie sie vermeiden
In Audits und Beratungsprojekten wiederholen sich bei der Risikoanalyse dieselben Muster:
- Zu viele Assets, zu feine Granularität: Wer jede Maus inventarisiert, pflegt bald gar nichts mehr. Gruppieren Sie und konzentrieren Sie sich auf das Kritische.
- Bedrohungskataloge blind kopiert: 400 importierte Standardrisiken ohne Unternehmensbezug sind wertlos – und im Audit sofort als Fremdkörper erkennbar.
- Nur IT-Risiken betrachtet: Ausscheidende Mitarbeitende, Dienstleisterausfall, Papierakten und Schlüsselpersonen fehlen in vielen Analysen komplett.
- Keine Risikoeigentümer: Risiken ohne verantwortliche Person werden nicht entschieden und nicht nachverfolgt – ein direkter Normverstoß gegen Kapitel 6.1.2.
- Bewertung im Alleingang: Schätzt nur die IT, fehlen Geschäftssicht und Schadensrealität; schätzt nur die Geschäftsführung, fehlt die technische Tiefe.
- Einmal durchgeführt, nie wiederholt: Die Analyse von vor drei Jahren kennt weder den neuen Cloud-Dienst noch das Homeoffice – im Überwachungsaudit ein Standardbefund.
- Restrisiken nie formell akzeptiert: Die Norm verlangt die dokumentierte Genehmigung der Restrisiken durch die Risikoeigentümer – ein Satz mit Unterschrift genügt, aber er muss existieren.
Der gemeinsame Nenner: Fast alle Fehler entstehen aus dem Versuch, die Analyse besonders vollständig statt besonders ehrlich zu machen. Ein schlankes Verfahren, das jährlich wirklich gelebt wird, ist jedem Umfangsrekord überlegen.
Häufige Fragen
Die Norm verlangt Wiederholungen in geplanten Abständen sowie bei wesentlichen Änderungen. Etabliert ist ein jährlicher Turnus, ergänzt um anlassbezogene Aktualisierungen – etwa bei neuen Cloud-Diensten, Umzügen, Zukäufen oder nach einem relevanten Sicherheitsvorfall. Entscheidend ist, dass Methode und Skalen gleich bleiben, damit die Ergebnisse über die Jahre vergleichbar sind.
Keine bestimmte. Die Norm fordert nur Eigenschaften: definierte Akzeptanz- und Bewertungskriterien, nachvollziehbare und wiederholbare Ergebnisse sowie benannte Risikoeigentümer. Ob Sie mit einer 4x4-Matrix, Szenariotechnik oder einem Tool arbeiten, ist frei wählbar. ISO 27005 liefert methodische Orientierung, ist aber nicht verpflichtend.
Für Unternehmen mit 10 bis 25 Mitarbeitenden sind 20 bis 50 dokumentierte Risikoszenarien ein realistischer Rahmen – genug für Substanz, wenig genug für jährliche Pflege. Deutlich dreistellige Zahlen deuten fast immer auf kopierte Kataloge hin. Auditoren bewerten die Qualität der Szenarien und deren Verbindung zu Maßnahmen, nicht die Menge.
Die Person mit der Befugnis und Verantwortung, über ein Risiko zu entscheiden – also Behandlung zu veranlassen oder das Restrisiko zu akzeptieren. Das ist bewusst nicht automatisch die IT: Für das Risiko „Ausfall des ERP“ ist eher die Geschäftsleitung Eigentümer, die IT setzt Maßnahmen um. Jedes Risiko braucht genau einen benannten Eigentümer.
Nein. Eine gut strukturierte Tabellenkalkulation mit Assets, Szenarien, Bewertungen, Eigentümern und Maßnahmen ist für kleine Organisationen vollkommen auditfähig. Software lohnt sich, wenn mehrere Standorte oder Normen zu koordinieren sind oder viele Personen gleichzeitig arbeiten. Wichtiger als das Werkzeug ist die Disziplin der jährlichen Pflege.
Im Sprachgebrauch der Norm ist die Risikobeurteilung der Oberbegriff mit drei Teilschritten: Identifikation (welche Risiken gibt es?), Analyse (wie wahrscheinlich, wie schwer?) und Bewertung (Vergleich mit den Akzeptanzkriterien: muss behandelt werden?). Umgangssprachlich steht „Risikoanalyse“ meist für den Gesamtprozess – im Audit sind die Begriffe selten streitentscheidend, die Schritte müssen aber erkennbar sein.
In 4–6 Wochen zum Zertifikat – zum Festpreis.
Kostenloses Erstgespräch: Wir sagen Ihnen ehrlich, ob eine nicht akkreditierte Zertifizierung für Ihren Fall reicht – oder eben nicht.
Erstgespräch vereinbaren
Thomas KowollInhaber und Leitung Zertifizierung bei KCERT. Auditiert Managementsysteme nach ISO 9001, 14001, 45001, 27001 und 50001. Mehr über KCERT