Aspekte in der Bewertung und Behandlung von Risiken und Chancen, die oft vernachlässigt werden (gemäß ISO 27001)

Risikomanagement für Informationssicherheit – mehr als eine Risikomatrix

Risiken erkennen, bewerten, behandeln und wirksam steuern nach ISO/IEC 27001:2022 und ISO/IEC 27005:2019

Risikomanagement ist eine der zentralen Säulen eines Informationssicherheits-Managementsystems (ISMS).

Trotzdem wird Risikomanagement in der Praxis häufig auf eine Risikomatrix reduziert:

Eintrittswahrscheinlichkeit × Auswirkung = Risikowert

Damit ist zwar ein Teil der Aufgabe erledigt – aber noch lange kein funktionierendes Risikomanagement etabliert.

Ein wirksames Informationssicherheits-Risikomanagement beginnt wesentlich früher und endet wesentlich später:

Kontext verstehen → Risiken identifizieren → Risiken analysieren → Risiken bewerten → Maßnahmen auswählen → Maßnahmen umsetzen → Restrisiko bewerten und akzeptieren → Wirksamkeit überwachen → Risiken regelmäßig überprüfen

Genau hier setzen ISO/IEC 27001:2022 und ISO/IEC 27005:2019 an.

Dieser Artikel betrachtet das Thema bewusst aus einer praktischen Perspektive. Er zeigt, was die ISO/IEC 27001 fordert, welche Rolle ISO/IEC 27005 spielt und wo sich Risikobetrachtungen im täglichen Betrieb eines ISMS wiederfinden.

1. Zunächst die Grundlagen: Was fordert ISO/IEC 27001?

Die zentralen Anforderungen an das Risikomanagement finden sich insbesondere in den Kapiteln 6.1.1, 6.1.2, 6.1.3, 8.2 und 8.3.

Dabei sollte man unterscheiden zwischen:

• Risiken und Chancen des ISMS,
• Informationssicherheitsrisiken,
• Risikobewertung,
• Risikobehandlung,
• Restrisiken,
• Überwachung und Wirksamkeitsbewertung.

Kapitel 6.1.1 – Maßnahmen zum Umgang mit Risiken und Chancen

Die Organisation muss die Risiken und Chancen bestimmen, die sich aus ihrem Kontext und den Anforderungen interessierter Parteien ergeben und die für das ISMS relevant sind.

Dabei geht es beispielsweise um:

• externe und interne Themen,
• gesetzliche und regulatorische Anforderungen,
• Anforderungen von Kunden,
• technologische Entwicklungen,
• Veränderungen des Geschäftsmodells,
• Lieferanten und Dienstleister,
• neue Bedrohungen,
• organisatorische Veränderungen

Hier kann beispielsweise eine PESTEL-Analyse eine sinnvolle Methode sein:

 Political – politische Faktoren
Economic – wirtschaftliche Faktoren
Social – gesellschaftliche Faktoren
Technological – technologische Faktoren
Environmental – Umweltfaktoren
Legal – rechtliche Faktoren

PESTEL ist dabei keine von ISO/IEC 27001 vorgeschriebene Methode. Sie kann aber helfen, externe Einflussfaktoren systematisch zu erfassen.

Seit dem Amendment 1:2024 ist außerdem ausdrücklich zu berücksichtigen, ob der Klimawandel ein relevantes Thema für die Organisation ist und ob interessierte Parteien Anforderungen bezüglich des Klimawandels haben.

Wichtig ist außerdem:

Maßnahmen allein zu implementieren reicht nicht. Ihre geplante Integration und ihre Wirksamkeit müssen berücksichtigt werden.

Eine interessante praktische Frage lautet deshalb:

Woher wissen wir eigentlich, dass eine Risikomaßnahme tatsächlich funktioniert?

2. Kapitel 6.1.2 – Informationssicherheits-Risikobewertung

Die Organisation muss einen Prozess für die Informationssicherheits-Risikobewertung festlegen.

Dieser Prozess sollte insbesondere sicherstellen, dass:

• Kriterien für die Risikobewertung definiert sind,
• Kriterien für die Risikoakzeptanz definiert sind,
• vergleichbare und wiederholbare Ergebnisse entstehen,
• Informationssicherheitsrisiken innerhalb des ISMS-Scope identifiziert werden,
• Risiken hinsichtlich ihrer Auswirkungen und ihrer Wahrscheinlichkeit analysiert werden,
• Risikoniveaus bestimmt werden,
• Risiken mit den festgelegten Kriterien verglichen werden,
• Risiken priorisiert werden.

Dabei stehen insbesondere die Auswirkungen auf die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen im Mittelpunkt. (V. I. V. oder Confidentiality, Integrity, Availability: C.I.A.)

Je nach Organisation können darüber hinaus beispielsweise betrachtet werden:

• Datenschutz,
• gesetzliche Anforderungen,
• finanzielle Auswirkungen,
• Vertragsverletzungen,
• Kundenbeeinträchtigungen,
• Produktionsausfälle,
• Lieferfähigkeit,
• Reputation,
• Business Continuity,
• Auswirkungen auf Produkte und Dienstleistungen.

Die Ergebnisse der Risikobewertung müssen als dokumentierte Information nachvollziehbar sein.

Eine bestimmte „Risikoakte“ schreibt die Norm nicht vor. Ein Risikoregister bzw. eine Risikoakte ist jedoch in der Praxis ein sehr sinnvolles Steuerungsinstrument.

3. Risikobewertung ist mehr als eine Risikomatrix

Ein häufiger Fehler besteht darin, Risikoanalyse und Risikobewertung gleichzusetzen.

Praktisch lässt sich der Prozess beispielsweise so darstellen:

Risikoidentifikation

Was kann passieren?

Risikoanalyse

Wie wahrscheinlich ist es und welche Auswirkungen hätte es?

Risikoevaluation

Ist das Risiko im Vergleich zu unseren Kriterien akzeptabel?

Risikobehandlung

Was tun wir dagegen?

Restrisiko

Was bleibt nach den Maßnahmen übrig?

Risikoakzeptanz

Wer akzeptiert das verbleibende Risiko?

Monitoring & Review

Hat sich das Risiko verändert und sind die Maßnahmen weiterhin wirksam?

Das entspricht wesentlich besser dem Gedanken eines kontinuierlichen Risikomanagements, wie er auch in ISO/IEC 27005 beschrieben wird.

4. ISO/IEC 27005: Der Blick auf den vollständigen Risikomanagement-Prozess

ISO/IEC 27005 ergänzt ISO/IEC 27001 insbesondere um eine systematische Betrachtung des Informationssicherheits-Risikomanagements.

Der Fokus liegt nicht nur auf der Frage:

„Wie hoch ist das Risiko?“

Sondern auf dem gesamten Lebenszyklus.

Dazu gehören insbesondere:

• Kontext herstellen,
• Risikoidentifikation,
• Risikoanalyse,
• Risikoevaluation,
• Risikobehandlung,
• Risikoakzeptanz,
• Kommunikation und Konsultation,
• Monitoring und Review.

Damit wird deutlich:

Ein Risikoregister ist kein Archiv. Es ist ein Steuerungsinstrument.

5. Wie entsteht eigentlich ein Informationssicherheitsrisiko?

Eine gute Risikobewertung beginnt mit einer guten Beschreibung des Risikos.

Zu häufig findet man in Risikoregistern Einträge wie:

„Ransomware – hoch“

oder:

„Cyberangriff – mittel“

oder:

„Datenverlust – hoch“

Das ist für eine belastbare Risikobehandlung zu wenig.

Denn:

Ransomware ist eine Bedrohung.

Datenverlust ist eine mögliche Konsequenz.

Dazwischen liegt das eigentliche Risikoszenario.

Eine präzisere Betrachtung könnte beispielsweise so aussehen:

Bedrohung

Ransomware-Angriff

Ursache

Phishing / kompromittiertes Benutzerkonto

Schwachstelle

Unzureichende Absicherung und Segmentierung

Risikoereignis

Angreifer kann Schadsoftware in das Unternehmensnetzwerk einbringen und verbreiten

Konsequenz

Verschlüsselung kritischer Systeme und Unterbrechung wesentlicher Geschäftsprozesse

Jetzt lässt sich sinnvoll bewerten:

• Wie wahrscheinlich ist das?
• Welche Systeme sind betroffen?
• Welche Informationen sind betroffen?
• Welche Auswirkungen entstehen?
• Welche Controls existieren bereits?
• Welche Maßnahmen fehlen?
• Welches Restrisiko bleibt?

6. Eine gute Risikobeschreibung betrachtet mehrere Ebenen

Eine detaillierte Betrachtung ermöglicht eine zielgerichtete Analyse.

Folgende Aspekte sollten mindestens betrachtet werden:

1. Asset / Information

Was soll geschützt werden?

Beispielsweise:

• Kundendaten,
• Quellcode,
• Produktionsdaten,
• Geschäftsgeheimnisse,
• Identitäten,
• IT-Systeme.

2. Bedrohung

Was kann passieren?

Beispielsweise:

• Phishing,
• Ransomware,
• Insider,
• technische Schwachstelle,
• Fehlkonfiguration,
• Lieferantenausfall.

3. Ursachen

Warum kann es passieren?

Beispielsweise:

• fehlende Schulung,
• unzureichende Prozesse,
• technische Schwachstellen,
• fehlende Trennung von Netzwerken,
• unzureichende Zugriffskontrollen.

4. Schwachstellen

• Was kann ausgenutzt werden?

5. Risikoereignis

• Was passiert konkret?

6. Konsequenzen

• Welche Auswirkungen entstehen?

7. Bestehende Maßnahmen

• Was wurde bereits dagegen implementiert?

8. Restrisiko

• Wie hoch ist das Risiko nach Berücksichtigung der bestehenden Maßnahmen?

9. Zusätzlicher Handlungsbedarf

• Welche weitere Risikobehandlung ist erforderlich?

10. Verantwortung und Akzeptanz

• Wer ist Risk Owner und wer akzeptiert gegebenenfalls das Restrisiko?

7. Inhärentes Risiko und Restrisiko

Ein besonders hilfreiches Konzept ist die Unterscheidung zwischen dem Risiko vor und nach Berücksichtigung vorhandener Maßnahmen.

Beispiel:

Inhärentes Risiko

Ransomware

Eintrittswahrscheinlichkeit: hoch
Auswirkung: hoch
Risiko: hoch

Vorhandene Controls:

• MFA
• EDR
• Patch Management
• Netzwerksegmentierung
• Backups
• Restore-Tests
• Awareness Training

Nach Berücksichtigung dieser Maßnahmen:

Restrisiko

Eintrittswahrscheinlichkeit: mittel
Auswirkung: hoch
Restrisiko: mittel

Jetzt stellt sich die entscheidende Managementfrage:

Ist dieses Restrisiko innerhalb der festgelegten Risikoakzeptanzgrenze?

Wenn ja, kann das Restrisiko durch den zuständigen Risikoeigner akzeptiert werden.

Wenn nein, sind weitere Maßnahmen erforderlich.

8. Risikobehandlung nach 6.1.3

Die Risikobehandlung besteht nicht einfach darin, eine Maßnahme in eine Liste einzutragen.

Die Organisation muss geeignete Behandlungsmaßnahmen bestimmen und deren Umsetzung planen.

Typische Optionen sind:

Risiko vermeiden

Die risikobehaftete Aktivität wird beendet oder gar nicht erst durchgeführt.

Risiko reduzieren

Eintrittswahrscheinlichkeit oder Auswirkungen werden reduziert.

Risiko teilen bzw. übertragen

Beispielsweise durch Versicherungen oder vertragliche Vereinbarungen.

Risiko akzeptieren

Das Risiko wird bewusst übernommen, wenn es innerhalb der definierten Akzeptanzkriterien liegt.

Wichtig:

„Wir haben ein Control implementiert“ bedeutet nicht automatisch „Risiko ist behandelt“.

Entscheidend ist die Frage:

Hat die Maßnahme das Risiko tatsächlich ausreichend reduziert?

9. Die Wirksamkeit von Maßnahmen

Dieser Punkt wird in der Praxis häufig unterschätzt.

Eine Maßnahme sollte nicht nur einen Status bekommen:

„implementiert“

sondern auch eine Aussage darüber ermöglichen:

„wirksam“

Beispielsweise:

Maßnahme

Backup-System eingeführt.

Das allein sagt noch wenig aus.

Interessanter sind Fragen wie:

• Werden die Backups tatsächlich durchgeführt?
• Sind sie gegen Manipulation geschützt?
• Sind kritische Systeme enthalten?
• Sind Wiederherstellungszeiten definiert?
• Wurde ein Restore-Test durchgeführt?
• War der Restore erfolgreich?
• Wird die Wirksamkeit regelmäßig überprüft?

Damit wird aus:

„Control vorhanden“

ein:

„Control funktioniert nachweislich.“

10. Die Rolle der Statement of Applicability

Die Statement of Applicability (SoA) ist ein wichtiger Bestandteil des Risikobehandlungsprozesses.

Die Organisation muss die notwendigen Controls bestimmen und diese mit den Controls des Annex A abgleichen.

Dabei ist Annex A nicht einfach eine Checkliste, die vollständig „abgehakt“ werden muss.

Der entscheidende Prozess ist vielmehr:

• Risiken + Kontext + Anforderungen + Geschäftsanforderungen
• notwendige Maßnahmen
• Abgleich mit Annex A
• SoA

Damit soll unter anderem sichergestellt werden, dass relevante Controls nicht übersehen werden.

Die SoA dokumentiert insbesondere:

• welche Controls erforderlich sind,
• warum sie erforderlich sind,
• ob sie implementiert sind,
• und – soweit ein Control nicht erforderlich ist – warum es nicht angewendet wird.

11. Ist die gesamte ISO/IEC 27001 risikobasiert?

Ja – aber mit einer wichtigen Einschränkung.

ISO/IEC 27001 ist wesentlich risikobasiert. Aber nicht jede einzelne Anforderung stellt eine eigenständige Risikobewertung dar.

Es gibt direkte und indirekte Bezüge.

Direkte Anforderungen

Besonders relevant sind:

• 6.1.1 – Risiken und Chancen
• 6.1.2 – Informationssicherheits-Risikobewertung
• 6.1.3 – Informationssicherheits-Risikobehandlung
• 8.2 – Durchführung der Informationssicherheits-Risikobewertung
• 8.3 – Durchführung der Informationssicherheits-Risikobehandlung

Indirekte bzw. risikoorientierte Bezüge

Andere Anforderungen schaffen Rahmenbedingungen für risikobasierte Entscheidungen, beispielsweise:

• 4.1 – Kontext der Organisation
• 4.2 – interessierte Parteien
• 5.1 – Führung und Verpflichtung
• 5.2 – Informationssicherheitspolitik
• 9.1 – Überwachung, Messung, Analyse und Bewertung
• 9.3 – Managementbewertung
• 10.1 – Nichtkonformität und Korrekturmaßnahmen

Dabei sollte man nicht behaupten, dass jedes dieser Kapitel eine eigene Risikobewertung fordert.

Vielmehr tragen sie dazu bei, dass das ISMS Risiken systematisch berücksichtigt, Entscheidungen nachvollziehbar getroffen und deren Wirksamkeit bewertet werden.

12. Risikomanagement findet nicht nur im Risikoregister statt

Hier liegt meiner Meinung nach einer der interessantesten Aspekte eines funktionierenden ISMS.

Risikomanagement findet nicht nur einmal jährlich im Rahmen einer zentralen Risikobewertung statt.

Risiken entstehen auch im täglichen Betrieb.

Lieferanten

Bei neuen Lieferanten oder Änderungen bestehender Lieferantenbeziehungen müssen beispielsweise betrachtet werden:

• Abhängigkeiten,
• Zugriff auf Informationen,
• Subdienstleister,
• Cloud-Nutzung,
• Standort,
• Vertragsanforderungen,
• Verfügbarkeit,
• Datenschutz,
• Informationssicherheit.

Besonders relevant sind hier beispielsweise:

A.5.19 – Information Security in Supplier Relationships

A.5.20 – Addressing Information Security within Supplier Agreements

A.5.21 – Managing Information Security in the ICT Supply Chain

A.5.23 – Information Security for Use of Cloud Services

13. Risikomanagement im Change Management

Ein klassisches Beispiel ist ein IT-Change.

Ein Change sollte nicht nur die Frage beantworten:

„Was soll technisch geändert werden?“

Sondern auch:

• Welche Systeme sind betroffen?
• Welche Informationen sind betroffen?
• Welche Sicherheitsanforderungen ändern sich?
• Welche neuen Schwachstellen können entstehen?
• Welche Abhängigkeiten existieren?
• Wie wird getestet?
• Wie kann zurückgerollt werden?
• Welche Auswirkungen hätte ein Fehler?

Eine sinnvolle Kette lautet:

• Change
• Risikoanalyse
• Sicherheitsanforderungen
• Test
• Freigabe
• Implementierung
• Monitoring
• Fallback / Rollback
• Review

Hier zeigt sich besonders deutlich, dass Risikomanagement Bestandteil des operativen Managements sein sollte.

14. Risikomanagement in der Softwareentwicklung

Auch Softwareentwicklung bietet zahlreiche Beispiele.

Risiken können entstehen durch:

• unsichere Anforderungen,
• fehlende Security Requirements,
• Schwachstellen,
• unsicheren Code,
• Open-Source-Komponenten,
• fehlende Tests,
• unzureichende Zugriffskontrollen,
• unsichere Schnittstellen,
• Fehlkonfigurationen,
• fehlende Protokollierung.

Relevante Annex-A-Controls sind beispielsweise:

• A.8.8 – Management of Technical Vulnerabilities
• A.8.25 – Secure Development Life Cycle
• A.8.26 – Application Security Requirements
• A.8.28 – Secure Coding
• A.8.29 – Security Testing in Development and Acceptance

Auch hier gilt:

Security by Design bedeutet letztlich, Risiken frühzeitig in Anforderungen, Architektur, Entwicklung und Tests zu berücksichtigen.

15. Risikomanagement bei Standorten und physischer Sicherheit

Informationssicherheit ist nicht nur IT-Sicherheit.

Ein Unternehmen kann beispielsweise Risiken durch folgende Faktoren haben:

• Hochwasser,
• Feuer,
• Stromausfall,
• Einbruch,
• unbefugten Zutritt,
• Ausfall eines Rechenzentrums,
• Standortkonzentration,
• Abhängigkeit von einer einzigen Infrastruktur.

Gerade bei mehreren Standorten sollte deshalb die Frage gestellt werden:

Welche standortbezogenen Risiken beeinflussen die Informationssicherheit?

Dabei können beispielsweise folgende Faktoren betrachtet werden:

• geografische Lage,
• Infrastruktur,
• Stromversorgung,
• Internetanbindung,
• Naturgefahren,
• politische bzw. regulatorische Faktoren,
• Lieferantenabhängigkeiten.

Auch hier kann PESTEL als strukturierendes Werkzeug sinnvoll sein – allerdings als Methode der Organisation, nicht als normative Forderung der ISO/IEC 27001.

16. Risikomanagement bei Business Continuity

Informationssicherheitsrisiken und Business Continuity sind eng miteinander verbunden.

Ein Ausfall eines IT-Systems kann beispielsweise nicht nur ein IT-Problem sein.

Die eigentliche Frage lautet:

Welche Geschäftsprozesse können dadurch nicht mehr durchgeführt werden?

Damit kommen unter anderem folgende Themen ins Spiel:

• kritische Geschäftsprozesse,
• Wiederanlaufzeiten,
• Wiederherstellungspunkte,
• Abhängigkeiten,
• Ersatzverfahren,
• Backup,
• Recovery,
• Krisenmanagement.

A.5.30 – ICT Readiness for Business Continuity ist dabei ein wichtiges Control.

Eine Business Impact Analysis (BIA) ist dabei nicht einfach mit einer Risikoanalyse gleichzusetzen. Sie liefert vielmehr wichtige Informationen darüber, welche Auswirkungen ein Ausfall auf das Geschäft hätte und welche Kontinuitätsanforderungen daraus entstehen.

17. Annex A und Risiko – nicht jedes Control verlangt eine eigene Risikobewertung

Der Annex A enthält zahlreiche Controls, bei denen Risiken eine wichtige Rolle spielen.

Man sollte aber zwischen drei Situationen unterscheiden.

Kategorie 1 – explizit risikoorientierte Controls

Beispielsweise:

• A.5.19 Supplier Relationships
• A.5.23 Cloud Services
• A.8.8 Technical Vulnerabilities
• A.8.32 Change Management

Kategorie 2 – Controls, deren Ausgestaltung von Risiken bzw. Schutzbedarf beeinflusst wird

Beispielsweise:

• A.5.3 Segregation of Duties
• A.5.12 Classification of Information
• A.6.1 Screening
• A.7.1 Physical Security Perimeters
• A.8.2 Privileged Access Rights
• A.8.16 Monitoring Activities

Kategorie 3 – Controls, deren konkrete Anwendung stark vom Kontext abhängt

Beispielsweise:

• A.5.32 Protection of Intellectual Property
• A.8.11 Data Masking
• A.8.26 Application Security Requirements
• A.8.28 Secure Coding

Daraus folgt:

Nicht jedes Control benötigt eine separate Risikobewertung. Aber die Auswahl, Ausgestaltung und Priorisierung von Controls sollte im Gesamtkontext des ISMS nachvollziehbar sein.

18. Risiko verändert sich

Ein Risiko ist keine statische Eigenschaft.

Ein Beispiel:

2025

Cloud Provider
Risiko: mittel

Dann ändern sich beispielsweise:

• Bedrohungslage,
• technische Architektur,
• Subdienstleister,
• Vertragsbedingungen,
• gesetzliche Anforderungen,
• Geschäftsprozesse,
• Abhängigkeiten.

Das Risiko kann dadurch 2026 plötzlich hoch sein.

Deshalb braucht ein funktionierendes Risikomanagement:

• regelmäßige Bewertungen,
• Reviews,
• Monitoring,
• Anlassbewertungen.

Anlassbezogene Neubewertungen können beispielsweise erforderlich werden bei:

• wesentlichen Changes,
• neuen Systemen,
• neuen Lieferanten,
• neuen Bedrohungen,
• Sicherheitsvorfällen,
• neuen regulatorischen Anforderungen,
• organisatorischen Änderungen,
• neuen Standorten,
• wesentlichen Technologieänderungen.

19. Die oft unterschätzte Frage: Was hat sich seit der letzten Bewertung verändert?

Eine sehr praktische Auditfrage lautet:

„Was hat sich seit der letzten Risikobewertung verändert?“

Wenn die Antwort lautet:

„Nichts.“

sollte man nachfragen.

Denn möglicherweise haben sich verändert:

• Bedrohungen,
• Schwachstellen,
• Lieferanten,
• Mitarbeiter,
• Technologien,
• Systeme,
• Geschäftsprozesse,
• regulatorische Anforderungen,
• geopolitische Rahmenbedingungen.

Risikomanagement sollte deshalb nicht nur dokumentieren:

„Risiko = mittel“

sondern auch:

„Warum ist das Risiko heute mittel und was hat sich seit der letzten Bewertung verändert?“

20. Die Qualität der Risikobeschreibung entscheidet über die Qualität der Maßnahmen

Ein häufiges Problem in Risikoregister lautet:

„Risiko: Datenverlust“

Maßnahme:

„Backup verbessern.“

Das ist zu unspezifisch.

Eine bessere Beschreibung könnte lauten:

„Durch einen kompromittierten privilegierten Account kann ein Angreifer auf produktive Daten zugreifen und diese verändern oder löschen. Aufgrund unzureichend geschützter Backup-Zugänge besteht zusätzlich das Risiko, dass Wiederherstellungsdaten manipuliert werden. Im Falle eines erfolgreichen Angriffs können Verfügbarkeit und Integrität kritischer Geschäftsdaten beeinträchtigt werden.“

Jetzt lassen sich gezielt Maßnahmen ableiten:

• MFA,
• Privileged Access Management,
• getrennte Backup-Accounts,
• Immutable Backup,
• Netzwerksegmentierung,
• Monitoring,
• Restore-Tests.

Die Qualität der Maßnahme hängt also wesentlich von der Qualität der Risikoanalyse ab.

21. Eine praktische Checkliste für ein gutes Risikoszenario

Für die Praxis kann folgende Checkliste verwendet werden:

• Risikoidentifikation
• Was wollen wir schützen?
• Bedrohung
• Was kann passieren?
• Ursache
• Warum kann es passieren?
• Schwachstelle
• Was kann ausgenutzt werden?
• Risikoereignis
• Was passiert konkret?
• Konsequenz
• Welche Auswirkungen entstehen?
• Bestehende Controls
• Was haben wir bereits dagegen?
• Risikobewertung
• Wie wahrscheinlich ist das Ereignis und wie groß ist die Auswirkung?
• Restrisiko
• Wie hoch ist das Risiko nach Berücksichtigung der bestehenden Maßnahmen?
• Risikobehandlung
• Was müssen wir zusätzlich tun?
• Verantwortlichkeit
• Wer ist Risk Owner?
• Risikoakzeptanz
• Wer akzeptiert das Restrisiko?
• Wirksamkeit
• Woran erkennen wir, dass die Maßnahme funktioniert?
• Monitoring
• Wann und unter welchen Bedingungen wird das Risiko erneut bewertet?

22. Das Risikoregister sollte deshalb mehr sein als eine Excel-Tabelle

Eine praktische Risikoakte könnte beispielsweise folgende Informationen enthalten:

   Element

 Beispiel

    Risiko-ID:  R-023

   Asset / Prozess: Kundendatenbank

   Bedrohung:  Phishing

   Ursache:  Social Engineering

   Schwachstelle: fehlende MFA

   Risikoereignis: kompromittierter Account

   Konsequenz: Verlust der Vertraulichkeit

   CIA: C

   Inhärentes Risiko: Hoch

   Bestehende Controls: MFA, EDR, Awareness

   Restrisiko: Mittel

   Behandlung: weitere Absicherung

   Maßnahme: MFA für alle externen Zugriffe

   Risk Owner: CISO

   Termin: 30.06.

   Akzeptanzgrenze: Mittel

   Status: Offen

   Wirksamkeitsnachweis: MFA-Abdeckung > 99 %

   Review: quartalsweise

  Damit wird aus einem Risikoregister ein echtes Managementinstrument.

23. Die Verbindung zu Managementbewertung und kontinuierlicher Verbesserung

Risikomanagement endet nicht beim Risk Owner.

Die Ergebnisse müssen wieder in das Managementsystem zurückfließen.

Das Management sollte beispielsweise wissen:

• Welche Risiken sind aktuell kritisch?
• Welche Risiken haben sich verändert?
• Welche Maßnahmen sind überfällig?
• Welche Restrisiken wurden akzeptiert?
• Wo gibt es wiederkehrende Probleme?
• Welche neuen Risiken sind entstanden?
• Welche Maßnahmen sind nicht wirksam?
• Wo müssen Ressourcen angepasst werden?

Damit entsteht der Kreislauf:

• Risiko
• Entscheidung
• Maßnahme
• Wirksamkeitsprüfung
• Managementbewertung
• Verbesserung
• neue Risikobewertung

Das ist der eigentliche Mehrwert eines ISMS.

24. Fazit: Risikomanagement ist keine einmalige Übung

Ein gutes Informationssicherheits-Risikomanagement besteht nicht darin, einmal pro Jahr eine Risikomatrix zu aktualisieren.

Es bedeutet:

Risiken verstehen, bevor sie zum Problem werden.

Dazu gehört:

• den Kontext der Organisation zu verstehen,
• relevante Bedrohungen und Schwachstellen zu erkennen,
• Risiken konkret zu beschreiben,
• Ursachen und Konsequenzen zu analysieren,
• bestehende Controls zu berücksichtigen,
• Risiken nachvollziehbar zu bewerten,
• geeignete Maßnahmen auszuwählen,
• Restrisiken bewusst zu akzeptieren,
• die Wirksamkeit der Maßnahmen zu überprüfen,
• und Risiken bei Veränderungen erneut zu betrachten.

ISO/IEC 27001 liefert dafür den verbindlichen Rahmen.

ISO/IEC 27005 unterstützt dabei, den Risikomanagement-Prozess methodisch zu strukturieren.

Die eigentliche Herausforderung liegt jedoch in der praktischen Umsetzung.

Denn Informationssicherheitsrisiken entstehen nicht nur im Risikoregister.

Sie entstehen bei:

neuen Lieferanten, Cloud-Diensten, Changes, Projekten, Softwareentwicklung, Schwachstellen, neuen Standorten, neuen Technologien, organisatorischen Veränderungen und neuen regulatorischen Anforderungen.

Deshalb sollte die entscheidende Frage nicht nur lauten:

„Wie hoch ist unser Risiko?“

Sondern:

„Verstehen wir, warum dieses Risiko besteht, was wir dagegen tun, ob unsere Maßnahmen tatsächlich wirken und welches Restrisiko wir bewusst akzeptieren?“

Das ist der Unterschied zwischen einer Risikomatrix und einem wirksamen Risikomanagement.

Kurzform für die Praxis

• Was schützen wir?
• Was kann passieren?
• Warum kann es passieren?
• Welche Konsequenzen entstehen?
• Was haben wir bereits dagegen?
• Wie hoch ist das Restrisiko?
• Was müssen wir zusätzlich tun?
• Wer trägt die Verantwortung?
• Wer akzeptiert das Restrisiko?
• Wie überprüfen wir die Wirksamkeit?
• Was hat sich verändert?

Genau hier beginnt praktisches Informationssicherheits-Risikomanagement.

Viel Erfolg, Ihr Konstantin Ziouras

P.S. Im Portfolio:

Zwei-Tägige Kurse zur Behandlung von Risiko Management im Integrierten Management System, oder in der Informationssicherheit!