ISO 27001 Risikomanagement: in 5 Schritten einfach erklärt
Viele Unternehmen machen aus dem Risikomanagement nach ISO 27001 entweder ein unnötig kompliziertes Monsterprojekt oder eine Excel-Übung ohne echten Nutzen. Beides bringt wenig.
Der pragmatische Weg liegt dazwischen: Sie brauchen ein nachvollziehbares Verfahren, mit dem Sie Informationssicherheitsrisiken systematisch identifizieren, sinnvoll bewerten und passende Maßnahmen festlegen. Nicht mehr.
In diesem Beitrag zeige ich Ihnen ein einfaches Vorgehen in 5 Schritten, mit dem kleine und mittlere Unternehmen das Thema sauber aufsetzen können.
Die kurze Antwort
Ein brauchbares Risikomanagement verbindet Geschäft, Informationen, Technik, Menschen und Dienstleister. Es beschreibt nicht bloß, was theoretisch schiefgehen könnte, sondern bewertet konkrete Auswirkungen, trifft nachvollziehbare Entscheidungen und verfolgt die Behandlung bis zur Wirksamkeit. Die Methode darf einfach sein. Beliebig darf sie nicht sein.
Was beim Risikomanagement nach ISO 27001 eigentlich gemeint ist
Im Kern geht es um diese vier Fragen:
- Welche Informationen möchten Sie schützen und wo werden diese verarbeitet?
- Welche Risiken gibt es dabei?
- Welche dieser Risiken sind wirklich relevant?
- Was tun Sie konkret gegen diese Risiken?
Genau an dieser Stelle verzetteln sich viele Unternehmen. Sie sammeln Bedrohungen, bauen riesige Listen und verlieren dabei den Überblick. Ein gutes Risikomanagement ist dagegen vor allem eines: klar, wiederholbar und im Alltag benutzbar.
Warum viele Unternehmen beim Risikomanagement festhängen
Das Problem ist meistens nicht, dass niemand das Wort „Risiko“ versteht. Das Problem ist, dass der Einstieg unklar ist.
Typische Fragen lauten:
- Müssen wir mit Assets anfangen oder mit Prozessen?
- Brauchen wir eine komplizierte Risikomatrix?
- Wie detailliert muss das Ganze sein?
- Was will der Auditor später wirklich sehen?
Die gute Nachricht: Sie brauchen kein akademisches Modell (uns werden in Audits immer wieder „Risikomanagement-Doktorarbeiten“ präsentiert). Sie brauchen ein Verfahren, das zu Ihrer Organisation passt und von den verantwortlichen Personen konsequent angewendet wird.
Schritt 1: Festlegen, für welchen Bereich Sie Risiken betrachten
Bevor Sie Risiken identifizieren, müssen Sie festlegen, worüber Sie überhaupt sprechen.
Fragen Sie sich zum Beispiel:
- Welche Standorte, Teams oder Prozesse gehören in den betrachteten Bereich?
- Welche Informationen sind dort relevant?
- Welche Systeme, Anwendungen, Geräte und Dienstleister spielen dabei eine Rolle?
Ohne diese Eingrenzung wird die Risikoanalyse beliebig. Dann reden Sie nicht über Ihre reale Organisation, sondern über ein theoretisches Sammelsurium möglicher Gefahren, das immer größer wird, je länger Sie drüber nachdenken.
Schritt 2: Relevante Werte und Abhängigkeiten identifizieren
Im nächsten Schritt erfassen Sie, was in diesem Bereich geschützt werden muss und wovon der Betrieb abhängt.
Dazu gehören typischerweise die folgenden Werte („Assets“):
- Informationen und Daten;
- Software und Cloud-Dienste;
- Hardware und Endgeräte;
- Netzwerke und technische Infrastruktur;
- Räume und physische Umgebung,
- Mitarbeiter und Zuständigkeiten;
- organisatorische Abläufe und Schnittstellen (bspw. zu Dienstleistern und Lieferanten).
Wichtig ist: Nicht jedes Asset muss bis ins letzte Detail dokumentiert werden. Und: Es reicht nicht, alles aufzuschreiben. Sie müssen vor allem verstehen, wovon Vertraulichkeit, Integrität und Verfügbarkeit Ihrer Informationen praktisch abhängen.
Schritt 3: Risiken identifizieren
Jetzt verbinden Sie Schwachstellen, mögliche Bedrohungen und die konkreten Auswirkungen auf Ihre Organisation.
Beispiele:
- Ein Cloud-Dienst ist für einen zentralen Kundenprozess unverzichtbar und es gibt kein belastbares Backup-Konzept (sehen wir immer wieder).
- Ein Administratorzugang ist zu weitreichend und nicht ausreichend abgesichert (bspw. kein 2FA und auch aus dem Internet heraus nutzbar).
- Ein wichtiges System wird nicht sauber überwacht, sodass Ausfälle oder Angriffe zu spät auffallen (es gibt schon 3 Terabyte Logfiles, aber niemand hat je reingeschaut).
- Ein Mitarbeiter kann auf sensible Informationen zugreifen, obwohl er sie für seine Aufgabe nicht benötigt (kein need-to-know-Prinzip).
- Ein Dienstleister ist kritisch, aber vertraglich und organisatorisch kaum abgesichert (fällt er weg, steht das Business).
- Der Systemadministrator hat Herrschaftswissen. Kündigt er oder wird vom Bus überfahren, geht bei Ihnen gar nichts mehr (Klassiker).
Wichtig ist dabei: Nicht nur technische Risiken zählen. Auch organisatorische Schwächen, unklare Verantwortlichkeiten oder schlecht geregelte Abläufe können echte Informationssicherheitsrisiken auslösen.
Schritt 4: Risiken bewerten und priorisieren
Jetzt trennen Sie Relevantes von Nebensächlichem.
Dafür brauchen Sie keine komplizierte Mathematik. In vielen Unternehmen reicht eine nachvollziehbare qualitative Bewertung völlig aus. Entscheidend ist, dass die Kriterien vorher klar sind.
Typische Bewertungsfragen sind:
- Wie wahrscheinlich ist das Risiko in unserer konkreten Umgebung?
- Wie schwer wären die Auswirkungen?
- Welche Informationen oder Prozesse wären betroffen?
- Gibt es bereits gewisse Schutzmaßnahmen?
- Wie schnell müssten wir reagieren, wenn das Risiko eintritt?
Das Ziel ist nicht Perfektion. Das Ziel ist Priorisierung. Wenn Ihre Bewertung dazu führt, dass die wirklich kritischen Risiken schnell sichtbar werden, erfüllt sie ihren Zweck.
Schritt 5: Risiken behandeln und Entscheidungen dokumentieren
Erst jetzt geht es um Maßnahmen.
Für jedes relevante Risiko brauchen Sie eine klare Entscheidung. Zum Beispiel:
- Risiko reduzieren, etwa durch technische oder organisatorische Maßnahmen;
- Risiko vermeiden, indem ein unsicherer Ablauf geändert oder beendet wird;
- Risiko übertragen, etwa teilweise über Verträge oder Versicherungen;
- Risiko bewusst akzeptieren, wenn es vertretbar ist oder die Abhilfe wirtschaftlich nicht darstellbar.
Wichtig ist hier, dass diese Entscheidungen nicht lose im Raum stehen. Sie sollten festhalten:
- welches Risiko betrachtet wurde;
- wie es bewertet wurde;
- welche Maßnahmen beschlossen wurden;
- wer verantwortlich ist;
- bis wann etwas umgesetzt werden soll;
- welche Restrisiken bestehen bleiben.
Spätestens hier wird aus einer theoretischen Risikoanalyse ein steuerbares Risikomanagement.
Was Auditoren beim Risikomanagement meist sehen wollen
Auditoren wollen in der Regel keinen Schönheitspreis für die kreativste Matrix vergeben. Sie wollen erkennen, dass Ihr Vorgehen nachvollziehbar ist.
Typischerweise sollte erkennbar sein:
- nach welcher Methode Sie Risiken identifizieren und bewerten (Beschreibung der Vorgehensweise);
- welche Kriterien für Eintrittswahrscheinlichkeit und Auswirkung gelten;
- wie Sie priorisieren;
- wie Maßnahmen abgeleitet werden;
- wie Entscheidungen dokumentiert werden;
- dass das Ganze tatsächlich gelebt wird.
Ein einfaches, konsequent genutztes Verfahren ist dabei fast immer besser als ein komplexes Modell, das intern niemand versteht oder anwenden kann.
Typische Fehler im ISO 27001-Risikomanagement
Es wird zu theoretisch
Dann entstehen lange Listen allgemeiner Gefahren, aber keine klaren Entscheidungen für die reale Umgebung.
Es wird zu detailliert
Dann verbringt das Unternehmen Wochen mit Tabellenpflege, ohne dass sich die Informationssicherheit praktisch verbessert.
Risiken und Maßnahmen werden nicht sauber getrennt
Viele schreiben sofort Maßnahmen auf, ohne das Risiko vorher klar beschrieben und bewertet zu haben. Oder die Maßnahme wird gleich mit ins Risiko geschrieben. Und später nie wiedergefunden.
Die Bewertungskriterien sind unklar
Wenn jeder „hoch“, „mittel“ oder „niedrig“ anders versteht, ist die Auswertung wertlos.
Es gibt keine echten Verantwortlichkeiten
Dann bleiben Maßnahmen offen und niemand fühlt sich zuständig.
Risiken stehen da ohne „Metadaten“
Wann wurde das Risiko aufgeschrieben? In welchem Zustand ist es jetzt? (Wurde es nur aufgeschrieben oder schon bewertet? Ist es sogar schon in Behandlung? Oder wurde es verworfen, weil irrelevant?) Wer hat es aufgeschrieben - an wen kann man Rückfragen dazu stellen? Wann soll es das nächste Mal angeschaut werden?
Risikobehandlungen sind nicht konkret genug
„Endgeräte-Strategie überdenken“ ist eine nebulöse Formulierung für „Lass das mal in die Zukunft vertagen“. Der Auditor wird hier sofort fragen: „Wer macht genau was bis wann?“
Risikokriterien müssen vor der Bewertung feststehen
Wenn jedes Risiko nach Tagesform bewertet wird, entsteht keine vergleichbare Liste. Legen Sie deshalb vorab fest, wie Auswirkungen und Eintrittsmöglichkeiten beurteilt werden, welche Risikostufen entstehen und ab wann eine Behandlung oder ausdrückliche Akzeptanz nötig ist.
Die Kriterien müssen zu Ihrem Unternehmen passen. Für einen SaaS-Anbieter kann ein mehrstündiger Ausfall eine andere Bedeutung haben als für ein internes Planungswerkzeug. Vertrauliche Kundendaten, Quellcode und öffentlich verfügbare Marketingunterlagen brauchen ebenfalls unterschiedliche Maßstäbe. Der Kontext der Organisation und die Interessen von Kunden, Behörden oder Eigentümern liefern dafür den Ausgangspunkt.
Wichtig ist außerdem die Trennung zwischen inhärentem und verbleibendem Risiko. Das inhärente Risiko beschreibt die Lage ohne die berücksichtigten Maßnahmen. Das Restrisiko bewertet, was nach vorhandenen oder geplanten Kontrollen übrig bleibt. Wer nur eine einzige Zahl pflegt, sollte wenigstens klar dokumentieren, welche Maßnahmen bei der Bewertung bereits vorausgesetzt wurden.
Assets sind mehr als Server und Laptops
Ein assetbasierter Ansatz funktioniert gut, wenn Assets nicht mit Hardware verwechselt werden. Prozesse, Informationen, Menschen, Anwendungen, Infrastruktur und Dienstleister können Werte beziehungsweise unterstützende Assets sein. Der Artikel über primäre und unterstützende Assets zeigt diese Trennung ausführlich.
Nehmen wir den Customer Service eines Premiumangebots. Der Prozess ist ein primäres Asset, wenn Kunden eine verbindliche Erreichbarkeit erwarten. Verbunden sind möglicherweise Ticketsystem, Identitätsdienst, Telefonie, Mitarbeiter, Wissensdatenbank, Internetzugang und ein externer Cloudanbieter. Fällt eines davon aus oder wird manipuliert, kann der Prozess sein Schutzziel verfehlen.
Zusätzlich müssen generelle Störungen betrachtet werden, die nicht bequem an einem einzelnen Asset hängen: regionaler Stromausfall, Unzugänglichkeit eines Standorts, politische Unruhe oder ein großflächiger Ausfall von Telekommunikation. Aus diesen Szenarien entstehen Kandidaten für Risikobehandlung und gegebenenfalls Business Continuity Management.
Risikobehandlung ist mehr als eine Maßnahmenliste
Für ein nicht akzeptables Risiko kommen mehrere Strategien infrage:
- Das Risiko mindern, etwa durch MFA, Redundanz oder einen Wiederanlaufplan.
- Das Risiko vermeiden, indem eine riskante Tätigkeit beendet oder verändert wird.
- Das Risiko teilen, beispielsweise über vertragliche Regelungen oder Versicherung.
- Das Risiko bewusst akzeptieren, wenn Aufwand und Nutzen das rechtfertigen.
Eine Behandlung braucht Verantwortlichen, Termin, Ressourcen und ein prüfbares Ergebnis. „Endgeräte-Strategie überdenken“ ist kein Ergebnis. „Bis 30. September werden alle mobilen Geräte in das MDM aufgenommen; verantwortlich ist die IT-Leitung; anschließend wird die Richtlinienkonformität ausgewertet“ ist wesentlich näher dran.
Akzeptanz ist ebenfalls eine Entscheidung. Sie sollte durch die Rolle erfolgen, die das Risiko tragen darf – nicht durch denjenigen, der gerade die Tabellenzeile bearbeitet. Hohe Risiken gehören sichtbar zur zuständigen Leitung.
Wann die Risikoanalyse aktualisiert werden muss
ISO 27001 erfindet keinen pauschalen jährlichen Pflichttermin für jedes Risiko. Die Organisation plant ihr Verfahren selbst und muss es bei relevanten Änderungen anwenden. Neue Systeme, Lieferanten, Standorte, Produkte, Schwachstellen oder Vorfälle sind typische Auslöser. Der Artikel über geplante Änderungen am ISMS beschreibt, wie solche Trigger aufgefangen werden.
Zusätzlich ist eine regelmäßige Gesamtschau sinnvoll. Dabei geht es nicht darum, jedes Jahr dieselben Zahlen abzuschreiben. Fragen Sie vielmehr:
- Haben sich Auswirkungen oder Abhängigkeiten verändert?
- Funktionieren die angenommenen Maßnahmen wirklich?
- Sind neue Bedrohungen oder Schwachstellen hinzugekommen?
- Ist eine frühere Akzeptanzentscheidung noch vertretbar?
- Gibt es ähnliche Risiken, die gemeinsam behandelt werden sollten?
Welche Angaben ein Risikoeintrag wirklich braucht
Ein Risikoregister muss keine Datenbankoper sein. Einige Felder machen die Einträge aber erst steuerbar: verständliches Szenario, betroffene Assets oder Prozesse, mögliche Auswirkungen, vorhandene Maßnahmen, Bewertung, verantwortliche Rolle, Behandlungsentscheidung, Termin und aktueller Status. Bei einer Maßnahme sollte außerdem erkennbar sein, welches Restrisiko nach ihrer Umsetzung erwartet wird.
Hilfreich sind Änderungsdatum und Entscheidungshistorie. Dann lässt sich nachvollziehen, warum ein Risiko früher akzeptiert und später doch behandelt wurde. Das schützt auch vor der üblichen Frage: „War das schon immer grün, oder hat jemand gestern die Farbe geändert?“
Suchen Sie auch nach ähnlichen Risiken
Wenn ein Risiko auffällt, lohnt sich der Blick nach links und rechts. Ein unkontrollierter administrativer Zugang bei einem Dienstleister kann bei weiteren Lieferanten ähnlich bestehen. Eine fehlende Wiederherstellungsprobe betrifft vielleicht nicht nur eine Anwendung, sondern mehrere Sicherungsverfahren. So lassen sich Ursachen und Maßnahmen gemeinsam bearbeiten.
Das bedeutet nicht, jedes Problem künstlich zu einem Konzernrisiko aufzublasen. Fragen Sie schlicht, ob derselbe Mechanismus an anderer Stelle wieder auftreten kann. Diese Suche verhindert, dass fünf fast identische Risiken nacheinander entdeckt und jeweils mit einer eigenen halben Maßnahme behandelt werden.
Interesse geweckt?
Wenn Ihr Risikoregister entweder zwanzig Seiten Theorie oder zwölf einsame Tabellenzeilen enthält, Sprechen Sie mit uns. Wir helfen dabei, eine Methode zu bauen, die Entscheidungen unterstützt und nicht nur beim Audit dekorativ auf dem Tisch liegt.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Risikoanalyse, Risikobewertung und Risikobehandlung?
Muss jede kleine Schwachstelle als eigenes Risiko aufgenommen werden?
Was ist wichtiger: Assets, Prozesse oder Informationen?
Wie oft muss die Risikoanalyse aktualisiert werden?
Was ist ein gutes Ergebnis einer Risikoanalyse?
Wer darf ein hohes Informationssicherheitsrisiko akzeptieren?
Dieser Artikel gehört zum Thema ISO 27001 Zertifizierung — erfahren Sie mehr über die Zertifizierung.