Kurz gesagt: Die Risikoanalyse ist der Kern jedes ISMS nach ISO/IEC 27001:2022. Die Norm verlangt in Abschnitt 6.1.2 eine Risikobeurteilung mit festen Kriterien und benannten Risikoeigentümern, in Abschnitt 6.1.3 eine Risikobehandlung mit Anwendbarkeitserklärung und in Abschnitt 8.2 die Wiederholung in geplanten Abständen. Welche Methode Sie nutzen, lässt die Norm offen. Dieser Beitrag zeigt, wie Sie eine ISO 27001 Risikoanalyse im Mittelstand in sieben Schritten durchführen, welche Fehler häufig sind und was Auditoren sehen wollen.

Was ISO 27001 bei der Risikobewertung verlangt

Ein ISMS (Informationssicherheits-Managementsystem) steuert Informationsrisiken über feste Rollen, Regeln und Abläufe. Wer ein ISMS aufbauen will, beginnt nach dem Geltungsbereich mit der Risikoanalyse, denn sie entscheidet, welche Maßnahmen Sie umsetzen und warum. ISO/IEC 27001:2022 regelt das in drei Abschnitten:

  • 6.1.2 Risikobeurteilung. Sie legen Kriterien für die Risikoakzeptanz und für die Durchführung fest. Wiederholte Beurteilungen müssen zu konsistenten, gültigen und vergleichbaren Ergebnissen führen. Sie identifizieren Risiken für Vertraulichkeit, Integrität und Verfügbarkeit von Informationen im Geltungsbereich und benennen je Risiko einen Risikoeigentümer. Dann analysieren Sie mögliche Folgen und realistische Eintrittswahrscheinlichkeit, bestimmen das Risikoniveau und bewerten das Ergebnis gegen Ihre Kriterien.
  • 6.1.3 Risikobehandlung. Sie wählen Behandlungsoptionen, bestimmen die nötigen Maßnahmen, gleichen sie mit Anhang A ab und erstellen Anwendbarkeitserklärung und Risikobehandlungsplan. Die Risikoeigentümer geben den Plan frei und akzeptieren die verbleibenden Restrisiken.
  • 8.2 und 8.3 Betrieb. Die Beurteilung läuft in geplanten Abständen und bei erheblichen Änderungen erneut, der Behandlungsplan wird umgesetzt. Die Ergebnisse beider Schritte bewahren Sie als dokumentierte Information auf.

Für die Ausgestaltung gibt es einen eigenen Leitfaden: ISO/IEC 27005:2022 beschreibt das Management von Informationssicherheitsrisiken passend zu ISO 27001. Er ist nicht zertifizierbar, liefert aber Begriffe und Vorgehen, auf die sich Berater und Auditoren beziehen. Wer nach BSI IT-Grundschutz arbeitet, nutzt dafür den BSI-Standard 200-3.

Zwei Ansätze aus ISO/IEC 27005

ISO/IEC 27005:2022 nennt zwei Wege, Risiken zu identifizieren. Beide sind zulässig und lassen sich kombinieren.

  • Ereignisbasierter Ansatz. Sie gehen von Szenarien aus, etwa „Ransomware verschlüsselt das ERP-System“ oder „ein Dienstleister verliert Kundendaten“. Das geht schnell, passt zur Sprache der Geschäftsleitung und eignet sich für den Einstieg.
  • Assetbasierter Ansatz. Sie gehen von Ihren Werten aus, also Informationen, Systemen, Prozessen und Dienstleistern, und fragen je Wert nach Bedrohungen und Schwachstellen. Eine Bedrohung ist eine mögliche Ursache für einen Schaden, eine Schwachstelle eine Lücke, die eine Bedrohung ausnutzen kann. Der Ansatz ist gründlicher, kostet aber mehr Zeit.

Im Mittelstand ist ein Mittelweg oft praktikabel: Szenarien für die wichtigsten Geschäftsprozesse, gestützt auf ein schlankes Verzeichnis der Werte, damit nichts Wesentliches fehlt.

Die Risikoanalyse in sieben Schritten

  1. Geltungsbereich übernehmen. Die Analyse deckt genau den Geltungsbereich (Scope) des ISMS ab, also die Standorte, Abteilungen und Systeme, die Sie nach Abschnitt 4.3 festgelegt haben. Was außerhalb liegt, aber hineinwirkt, etwa ein externer Rechenzentrumsbetreiber, gehört als Schnittstelle dazu.
  2. Kriterien festlegen. Definieren Sie Skalen für Auswirkung und Wahrscheinlichkeit, jeweils mit wenigen Stufen und einer Beschreibung pro Stufe, zum Beispiel nach Ausfalldauer, finanziellem Schaden oder Folgen für Kunden. Legen Sie fest, ab welchem Risikoniveau gehandelt werden muss und wer welches Risiko akzeptieren darf. Die Geschäftsleitung gibt diese Kriterien frei.
  3. Werte und Prozesse erfassen. Erfassen Sie kritische Geschäftsprozesse, die Informationen dahinter, die tragenden Systeme und die beteiligten Dienstleister. Arbeiten Sie auf der Ebene, auf der Sie entscheiden: Systemgruppen statt einzelner Rechner.
  4. Risiken identifizieren und Eigentümer benennen. In kurzen Workshops mit den Fachbereichen sammeln Sie Szenarien. Jedes Risiko erhält einen Risikoeigentümer, also eine Person mit der Befugnis, über Behandlung und Budget zu entscheiden. Das ist meist eine Bereichsleitung, nicht automatisch die IT.
  5. Analysieren und bewerten. Schätzen Sie Auswirkung und Wahrscheinlichkeit unter Berücksichtigung der Maßnahmen, die schon wirken. Das Ergebnis vergleichen Sie mit Ihren Akzeptanzkriterien und bringen die Risiken in eine Reihenfolge.
  6. Behandlung festlegen. ISO/IEC 27005 nennt vier Optionen: das Risiko durch Maßnahmen verändern, es bewusst beibehalten, es vermeiden, indem Sie eine Tätigkeit aufgeben, oder es teilen, etwa über eine Versicherung oder einen Dienstleister. Die gewählten Maßnahmen gleichen Sie mit Anhang A ab.
  7. Anwendbarkeitserklärung und Behandlungsplan erstellen. Der Plan nennt je Maßnahme Verantwortliche, Termin und Mittel. Die Risikoeigentümer geben ihn frei und akzeptieren die Restrisiken schriftlich.

Die Anwendbarkeitserklärung

Die Anwendbarkeitserklärung (englisch Statement of Applicability, kurz SoA) ist das Pflichtdokument, das Risikoanalyse und Maßnahmen verbindet. Nach Abschnitt 6.1.3 d) enthält sie die notwendigen Maßnahmen, die Begründung für ihre Aufnahme, den Stand der Umsetzung und die Begründung für jeden Ausschluss einer Maßnahme aus Anhang A. Anhang A umfasst 93 Maßnahmen in vier Themen: organisatorisch, personenbezogen, physisch und technologisch.

Anhang A dient dem Abgleich, nicht dem Abhaken. Nach 6.1.3 c) prüfen Sie mit seiner Hilfe, dass keine notwendige Maßnahme übersehen wurde. Eigene Maßnahmen aus anderen Quellen sind ausdrücklich zulässig. Ein Ausschluss braucht eine nachvollziehbare Begründung, etwa „keine eigene Softwareentwicklung im Geltungsbereich“ für A.8.25 zum sicheren Entwicklungslebenszyklus.

Typische Fehler und was Auditoren sehen wollen

  • Zu feingranular. Jedes Notebook als eigener Wert, jede Bedrohung als eigene Zeile. Das Register wächst auf Hunderte Einträge, niemand pflegt es, und die wichtigen Risiken gehen unter.
  • Ohne Risikoeigentümer. Alle Risiken liegen bei der IT-Leitung oder bei niemandem. Dann fehlt die Freigabe nach 6.1.3 f), und Restrisiken akzeptiert jemand ohne Befugnis.
  • Tabelle ohne Behandlung. Risiken sind bewertet, aber hohe Risiken haben weder Maßnahme noch dokumentierte Akzeptanz, und der Plan hat keine Termine.
  • Einmal und nie wieder. Die Beurteilung entsteht kurz vor dem Audit und wird danach nicht mehr angefasst. Abschnitt 8.2 verlangt Wiederholung in geplanten Abständen und bei erheblichen Änderungen.
  • Kriterien ohne Definition. „Hoch“ ohne Beschreibung führt bei zwei Personen zu zwei Ergebnissen. Das widerspricht der Forderung nach vergleichbaren Ergebnissen.

Im Zertifizierungsaudit prüfen die Auditoren in Stufe 1 die Unterlagen: Methode, Kriterien, Risikoregister, Anwendbarkeitserklärung und Behandlungsplan. In Stufe 2 zählt die gelebte Praxis. Auditoren verfolgen dann zum Beispiel ein Risiko vom Register bis zur umgesetzten Maßnahme, sprechen mit Risikoeigentümern, sehen sich Freigaben und Akzeptanzen an und fragen, wie ein neuer Dienstleister oder ein Vorfall in die Bewertung eingeflossen ist.

Wie GermanAI Defense unterstützt

Wir haben die Risikoanalyse für unser eigenes ISMS durchlaufen und sind seit Mai 2026 nach ISO/IEC 27001:2022 zertifiziert (Zertifikat-Nr. 26052601). Mit Ihrem Team legen wir Kriterien fest, moderieren die Workshops mit den Fachbereichen und erstellen Risikoregister, Anwendbarkeitserklärung und Behandlungsplan so, dass sie im Betrieb gepflegt werden können. Technische Maßnahmen wie Penetrationstests und SOC-Überwachung rund um die Uhr, Service- und Reaktionszeiten laut Vertrag, übernehmen wir auf Wunsch mit.

→ Vom Ist-Stand bis zum Audit: ISO 27001 Beratung

→ Was ein ISO-Zertifikat für NIS 2 bringt: ISO 27001 und NIS 2 im Vergleich

→ Schwachstellen technisch prüfen: Penetrationstest

Quellen

Stand: 28.10.2026. Dieser Beitrag ist eine fachliche Einordnung und ersetzt keine Beratung im Einzelfall.