ISO 27001 Risikobewertung: Prozess, Methodik und Beispiele

Die Risikobewertung ist der Motor, der Ihr gesamtes Informationssicherheits-Managementsystem antreibt. Ohne sie ist Ihr ISMS eine Sammlung von Richtlinien und Kontrollen, die auf Instinkt statt auf Fakten basieren. ISO 27001 überlässt dies nicht der Interpretation — Klausel 6.1.2 schreibt einen formalen, wiederholbaren Risikobewertungsprozess vor, der Bedrohungen identifiziert, deren Schwere bewertet und einen Risikobehandlungsplan erstellt, der jedes wesentliche Risiko mit einer konkreten Maßnahme verknüpft.

Für SaaS-Unternehmen bestimmt die Risikobewertung, welche Annex A Kontrollen Sie implementieren, welche Sie ausschließen (dokumentiert in Ihrer Erklärung zur Anwendbarkeit) und wie Sie begrenzte Sicherheitsressourcen zuweisen. Eine Risikobewertung, die Ihre tatsächliche Bedrohungslandschaft widerspiegelt — Fehlkonfigurationen der Cloud-Infrastruktur, Supply-Chain-Angriffe über Open-Source-Abhängigkeiten, Fehler bei der Multi-Tenant-Datenisolierung — erzeugt ein ISMS, das Ihr Unternehmen tatsächlich schützt. Eine generische, aus einer Vorlage kopierte Bewertung erzeugt Auditfeststellungen und, schlimmer noch, nicht behobene Schwachstellen.

Dieser Leitfaden führt durch den gesamten ISO 27001 Risikobewertungsprozess: was der Standard verlangt, wie man eine Methodik wählt und anwendet, wie man Risiken bewertet und behandelt sowie die spezifischen Überlegungen, die für SaaS-Organisationen gelten.

Was verlangt ISO 27001 für die Risikobewertung?

ISO 27001 Klausel 6.1.2 legt sechs explizite Anforderungen an den Informationssicherheits-Risikobewertungsprozess fest. Das Verständnis jeder Anforderung ist essenziell, bevor Sie mit dem Aufbau Ihrer Methodik beginnen.

Anforderung 1: Risikobewertungskriterien festlegen und pflegen

Sie müssen die Kriterien definieren und dokumentieren, die Sie zur Bewertung von Risiken verwenden. Dies umfasst Ihre Risikoakzeptanzkriterien (welches Niveau an Restrisiko tolerierbar ist) und die Kriterien für die Durchführung der Risikobewertung selbst (wie Sie Eintrittswahrscheinlichkeit und Auswirkung messen). Diese Kriterien müssen vor Beginn der Bewertung festgelegt werden — nicht nachträglich angepasst, um bereits getroffene Entscheidungen zu rechtfertigen.

In der Praxis: Definieren Sie Ihre Risikobewertungsskalen, Ihre Risikoappetit-Schwellenwerte und die Regeln, wann ein Risiko behandelt werden muss und wann es akzeptiert werden kann. Dokumentieren Sie diese in Ihrer Risikomanagement-Richtlinie, damit sie über alle Bewertungen hinweg konsistent und prüfbar sind.

Anforderung 2: Wiederholbare und konsistente Ergebnisse sicherstellen

Der Risikobewertungsprozess muss konsistente, gültige und vergleichbare Ergebnisse liefern, wenn er wiederholt wird. Das bedeutet, dass Ihre Methodik nicht von der Beurteilung einer einzelnen Person ohne Struktur abhängen darf. Zwei verschiedene Teams, die dieselbe Bewertung mit demselben Umfang durchführen, sollten zu vernünftig ähnlichen Schlussfolgerungen gelangen.

In der Praxis: Verwenden Sie definierte Bewertungsskalen, dokumentierte Kriterien für jede Bewertungsstufe und strukturierte Workshops anstelle von Ad-hoc-Brainstorming. Eine 5x5-Wahrscheinlichkeits-Auswirkungs-Matrix mit schriftlichen Beschreibungen für jede Stufe liefert konsistentere Ergebnisse als „diskutieren und sich auf eine Bewertung einigen”.

Anforderung 3: Informationssicherheitsrisiken identifizieren

Sie müssen Risiken identifizieren, die mit dem Verlust von Vertraulichkeit, Integrität und Verfügbarkeit von Informationen innerhalb des ISMS-Geltungsbereichs verbunden sind. Dies erfordert eine systematische Identifikation — nicht nur das Auflisten der offensichtlichen Bedrohungen.

In der Praxis: Das bedeutet, die im Geltungsbereich befindlichen Informationswerte zu identifizieren, die Bedrohungen für diese Werte, die Schwachstellen, die Bedrohungen ausnutzen könnten, und die möglichen Folgen. Für SaaS-Unternehmen umfasst der Geltungsbereich typischerweise die Produktionsinfrastruktur, Kundendaten, interne Systeme, die den Dienst unterstützen, sowie die Menschen und Prozesse, die diese betreiben.

Anforderung 4: Die identifizierten Risiken analysieren

Jedes identifizierte Risiko muss analysiert werden, um seine Eintrittswahrscheinlichkeit und die potenzielle Auswirkung bei Eintreten zu bestimmen. Diese Analyse ergibt die Risikostufe, die Behandlungsentscheidungen antreibt.

In der Praxis: Wenden Sie Ihre Bewertungskriterien konsistent an. Bewerten Sie für jedes Risiko sowohl die Wahrscheinlichkeit, dass die Bedrohung die Schwachstelle ausnutzt, als auch die geschäftlichen Auswirkungen, wenn dies geschieht. Dokumentieren Sie die Begründung — nicht nur die Zahlen.

Anforderung 5: Die identifizierten Risiken bewerten

Sie müssen die Ergebnisse der Risikoanalyse mit Ihren Risikoakzeptanzkriterien vergleichen und Risiken für die Behandlung priorisieren. Die Bewertung bestimmt, welche Risiken Maßnahmen erfordern und in welcher Reihenfolge.

In der Praxis: Risiken über Ihrem Akzeptanzschwellenwert erfordern eine Behandlung. Risiken darunter können akzeptiert werden — aber die Akzeptanz muss eine dokumentierte Entscheidung sein, keine Standardeinstellung. Die Priorisierung stellt sicher, dass Sie die kritischsten Risiken zuerst angehen, was wichtig ist, wenn Ressourcen begrenzt sind (wie es bei wachsenden SaaS-Unternehmen immer der Fall ist).

Anforderung 6: Die Ergebnisse dokumentieren

Die Ergebnisse der Risikobewertung müssen als dokumentierte Information aufbewahrt werden. Dies ist nicht verhandelbar. Ihr Risikoregister, die Methodendokumentation, die Bewertungsbegründung und die Behandlungsentscheidungen sind alles prüfbare Artefakte.

In der Praxis: Führen Sie ein Risikoregister, das jedes identifizierte Risiko, seine Analyse, seine Bewertung und die Behandlungsentscheidung erfasst. Dieses Register ist ein lebendiges Dokument — es wird während des gesamten ISMS-Lebenszyklus überprüft und aktualisiert, nicht nur bei jährlichen Bewertungen.

Wahl Ihrer Risikobewertungsmethodik

ISO 27001 schreibt keine bestimmte Methodik vor. Der Standard verlangt, dass Ihr gewählter Ansatz die sechs oben genannten Anforderungen erfüllt, aber das spezifische Rahmenwerk liegt in Ihrer Entscheidung. Diese Flexibilität ist beabsichtigt — verschiedene Organisationen haben unterschiedliche Risikoprofile, Ressourcen und Reifegrade.

Qualitative Risikobewertung

Die qualitative Bewertung verwendet beschreibende Kategorien (Hoch, Mittel, Niedrig oder numerische Skalen wie 1-5) anstelle von präzisen Geldwerten. Sie ist der häufigste Ansatz für SaaS-Unternehmen, die erstmals eine ISO 27001-Zertifizierung anstreben.

Funktionsweise: Risiken werden auf zwei Dimensionen bewertet — Eintrittswahrscheinlichkeit und Auswirkung — unter Verwendung vordefinierter Skalen. Die Bewertungen werden multipliziert oder kombiniert, um eine Gesamtrisikobewertung zu erzeugen, die die Behandlungspriorität bestimmt.

Vorteile:

• Schneller zu implementieren und einfacher zu pflegen
• Erfordert keine versicherungsmathematischen Daten oder historische Verlustdaten
• Zugänglich für nicht-sicherheitstechnische Stakeholder, die an Risikoworkshops teilnehmen
• Ausreichend für die Zertifizierung — Auditoren akzeptieren qualitative Ansätze

Nachteile:

• Subjektiv — verschiedene Bewerter können dem gleichen Risiko unterschiedliche Bewertungen zuweisen
• Liefert keine Schätzungen in Geldwerten, die für ROI-Berechnungen von Sicherheitsinvestitionen nützlich sind
• Kann zu Häufungen führen (alles als „Mittel” bewertet), wenn Skalen nicht gut definiert sind

Am besten geeignet für: SaaS-Unternehmen mit weniger als 500 Mitarbeitern, Organisationen, die eine Erstzertifizierung anstreben, Teams ohne dedizierte Risikoanalysten.

Quantitative Risikobewertung

Die quantitative Bewertung weist sowohl der Eintrittswahrscheinlichkeit als auch der potenziellen Auswirkung monetäre Werte zu. Sie verwendet Formeln wie die Jährliche Verlusterwartung (Annual Loss Expectancy, ALE) = Einzelverlusterwartung (Single Loss Expectancy, SLE) x Jährliche Eintrittshäufigkeit (Annual Rate of Occurrence, ARO), um Risikoschätzungen in Geldwerten zu erzeugen.

Funktionsweise: Für jedes Risiko schätzen Sie die finanziellen Kosten bei Eintritt des Ereignisses (SLE) und wie oft es voraussichtlich pro Jahr eintritt (ARO). Das Produkt ist der erwartete jährliche Verlust, der direkt mit den Kosten der Minderung verglichen werden kann, um festzustellen, ob eine Kontrollinvestition gerechtfertigt ist.

Vorteile:

• Liefert Finanzzahlen, die bei der Geschäftsführung und Aufsichtsgremien Anklang finden
• Ermöglicht eine direkte Kosten-Nutzen-Analyse von Kontrollinvestitionen
• Reduziert die Subjektivität, wenn zuverlässige Daten verfügbar sind

Nachteile:

• Erfordert historische Daten und versicherungsmathematische Schätzungen, die vielen SaaS-Unternehmen fehlen
• Zeitaufwendig in der Entwicklung und Pflege
• Falsche Präzision — die Zahlen können eine Illusion von Genauigkeit erzeugen, wenn die zugrunde liegenden Annahmen grobe Schätzungen sind

Am besten geeignet für: Reife Organisationen mit dedizierten Risikomanagement-Funktionen, Unternehmen mit umfangreichen Vorfalldaten, Unternehmen, bei denen die Vorstandsberichterstattung eine finanzielle Risikoquantifizierung erfordert.

Hybrider Ansatz

Viele Organisationen verwenden die qualitative Bewertung als primäre Methodik und ergänzen sie mit quantitativer Analyse für die Risiken mit höchster Priorität oder für spezifische Investitionsentscheidungen. Dies ist ein pragmatischer Ansatz, der den Standard erfüllt und gleichzeitig finanziellen Kontext dort bietet, wo er am wichtigsten ist.

Beispiel: Ein SaaS-Unternehmen verwendet eine 5x5 qualitative Matrix für seine jährliche Risikobewertung, führt aber eine quantitative Analyse durch, wenn es evaluiert, ob eine Investition von 200.000 $ in eine neue WAF-Lösung im Vergleich zur Akzeptanz des Risikos von Application-Layer-Angriffen gerechtfertigt ist.

Asset-basierte vs. szenariobasierte Bewertung

Neben der Unterscheidung qualitativ/quantitativ müssen Sie sich auch für Ihren Identifikationsansatz entscheiden.

Asset-basierte Bewertung beginnt mit einer Inventarisierung der Informationswerte (Datenbanken, Server, Anwendungen, Datenspeicher) und identifiziert Bedrohungen und Schwachstellen für jeden Wert. Dies ist gründlich, kann aber für Organisationen mit umfangreichen Asset-Inventaren arbeitsintensiv sein.

Szenariobasierte Bewertung beginnt mit Bedrohungsszenarien (z. B. „Ransomware verschlüsselt Produktionsdatenbanken”, „Entwicklerlaptop mit gecachten Anmeldedaten gestohlen”) und verfolgt die Auswirkungen auf betroffene Assets. Dies ist oft effizienter für SaaS-Unternehmen, da es sich auf realistische Angriffspfade konzentriert anstatt jeden einzelnen Wert erschöpfend zu katalogisieren.

Der Standard erlaubt beides. Die meisten SaaS-Unternehmen profitieren von einem szenariobasierten Ansatz, der an einem übergeordneten Asset-Inventar verankert ist. Sie müssen wissen, welche Assets existieren, aber Ihre Risikoidentifikation ist um Bedrohungsszenarien herum organisiert und nicht um eine Auflistung Asset für Asset.

Asset-Identifikation und -Klassifizierung

Unabhängig von Ihrer Methodik müssen Sie wissen, was Sie schützen. ISO 27001 verlangt, dass Informationswerte innerhalb des ISMS-Geltungsbereichs identifiziert und klassifiziert werden.

Kategorien von Informationswerten

Datenbestände: Kundendaten (personenbezogene Daten, Geschäftsdaten, Nutzungsanalysen), Mitarbeiterdaten, Finanzdaten, geistiges Eigentum (Quellcode, Algorithmen, Trainingsdaten), Authentifizierungsdaten, Verschlüsselungsschlüssel, Konfigurationsdaten, Protokolle.

Technologische Werte: Produktionsserver, Datenbanken, Anwendungscode-Repositories, CI/CD-Pipelines, Überwachungssysteme, Backup-Speicher, Entwicklungs- und Staging-Umgebungen, intern genutzte SaaS-Tools (Identitätsanbieter, Projektmanagement, Kommunikationsplattformen).

Personelle Werte: Mitarbeiter mit Zugang zu sensiblen Systemen, Auftragnehmer, Supportpersonal von Drittanbietern. Menschen sind Werte, weil ihr Wissen, ihr Zugang und ihre Handlungen die Informationssicherheit direkt beeinflussen.

Prozesswerte: Verfahren zur Vorfallreaktion, Change-Management-Workflows, Backup-Prozesse, Onboarding-/Offboarding-Verfahren. Diese sind Werte, weil ihr Versagen oder ihre Abwesenheit Risiken erzeugt.

Asset-Eigentümerschaft

Jeder Wert muss einen bestimmten Eigentümer haben — eine Person, die für den Schutz des Wertes verantwortlich ist. Asset-Eigentümer sind dafür verantwortlich, sicherzustellen, dass Risiken für ihre Assets identifiziert, bewertet und behandelt werden. In SaaS-Unternehmen folgt die Asset-Eigentümerschaft typischerweise der Struktur der Engineering-Organisation: Das Team, das ein System baut und betreibt, besitzt die zugehörigen Werte.

Klassifizierung

Klassifizieren Sie Werte basierend auf der Sensibilität und Kritikalität der Informationen, die sie enthalten oder verarbeiten. Ein einfaches dreistufiges Schema funktioniert für die meisten SaaS-Unternehmen:

• Vertraulich — Kundendaten, Anmeldedaten, Verschlüsselungsschlüssel, Quellcode. Unbefugte Offenlegung würde erheblichen Schaden verursachen.
• Intern — Interne Geschäftsdokumente, nicht-sensible Mitarbeiterdaten, Projektpläne. Offenlegung würde moderate Auswirkungen haben.
• Öffentlich — Marketingmaterialien, veröffentlichte Dokumentation, öffentliche API-Spezifikationen. Keine Auswirkung bei Offenlegung.

Die Klassifizierung bestimmt das erforderliche Schutzniveau und beeinflusst die Risikobewertung — eine Bedrohung für einen vertraulichen Wert hat höhere Auswirkungen als dieselbe Bedrohung für einen öffentlichen Wert.

Bedrohungs- und Schwachstellenanalyse

Mit Ihren identifizierten Assets können Sie systematisch identifizieren, was schiefgehen könnte und warum.

Bedrohungsidentifikation

Bedrohungen sind potenzielle Ereignisse oder Handlungen, die Ihre Informationswerte schädigen könnten. Für SaaS-Unternehmen erstrecken sich Bedrohungen über mehrere Kategorien:

Cyberbedrohungen:

• Ransomware und Malware, die auf die Produktionsinfrastruktur abzielen
• Credential-Stuffing-Angriffe gegen die Kundenauthentifizierung
• Supply-Chain-Kompromittierung durch Drittanbieter-Bibliotheken oder Build-Tools
• DDoS-Angriffe, die die Dienstverfügbarkeit stören
• API-Missbrauch — Scraping, Injection, Umgehung von Rate Limits
• Zero-Day-Ausnutzung von Framework- oder Betriebssystem-Schwachstellen
• Phishing, das auf Mitarbeiter mit Zugang zu Produktionssystemen abzielt

Insider-Bedrohungen:

• Böswillige Datenexfiltration durch Mitarbeiter oder Auftragnehmer
• Fahrlässige Fehlkonfiguration von Cloud-Ressourcen (öffentliche S3-Buckets, offene Security Groups)
• Schatten-IT — Mitarbeiter nutzen nicht autorisierte Tools, die Unternehmens- oder Kundendaten verarbeiten
• Privilegienmissbrauch — Mitarbeiter greifen auf Daten zu, die über ihre Arbeitsanforderungen hinausgehen

Umwelt- und betriebliche Bedrohungen:

• Cloud-Anbieter-Ausfälle, die die Verfügbarkeit beeinträchtigen
• Ausfälle von Rechenzentren (auch in der Cloud treten regionale Ausfälle auf)
• Kapazitätserschöpfung bei Verkehrsspitzen
• Deployment-Fehler, die Bugs oder Sicherheitsregressionen einführen

Drittanbieter-Bedrohungen:

• Sicherheitsverletzungen bei SaaS-Anbietern, die Ihre Daten verarbeiten
• Einstellung von Anbieterleistungen, die eine Notfallmigration erzwingen
• Compliance-Verstöße durch Unterauftragnehmer, die Ihre regulatorischen Pflichten betreffen

Schwachstellenidentifikation

Schwachstellen sind Schwächen, die Bedrohungen ausnutzen können. Sie existieren in Technologie, Prozessen und Menschen:

Technische Schwachstellen:

• Ungepatchte Software und Betriebssysteme
• Unsichere Standardkonfigurationen
• Fehlende Verschlüsselung für ruhende oder übertragene Daten
• Unzureichende Protokollierung und Überwachung
• Schwache Authentifizierungsmechanismen (Einzelfaktor, geteilte Anmeldedaten)
• Unzureichende Netzwerksegmentierung zwischen Mandanten oder Umgebungen

Prozess-Schwachstellen:

• Kein formaler Change-Management-Prozess
• Fehlende Code-Review-Anforderungen für Produktionsbereitstellungen
• Fehlende oder ungetestete Backup-Wiederherstellungsverfahren
• Unzureichende Sicherheitsbewertungsprozesse für Anbieter
• Keine Playbooks zur Vorfallreaktion

Menschliche Schwachstellen:

• Unzureichendes Sicherheitsbewusstseinstraining
• Schlüsselpersonenabhängigkeiten (ein Ingenieur, der weiß, wie das System funktioniert)
• Unzureichende Hintergrundüberprüfungen für Mitarbeiter mit sensiblem Zugang
• Schlechte Passworthygiene trotz Richtlinienanforderungen

Zuordnung von Bedrohungen zu Schwachstellen

Risiko besteht an der Schnittstelle einer Bedrohung und einer Schwachstelle. Eine Bedrohung ohne eine entsprechende Schwachstelle ist theoretisch. Eine Schwachstelle ohne eine entsprechende Bedrohung ist eine Schwäche, aber kein aktives Risiko. Ihr Risikoregister sollte die spezifischen Bedrohungs-Schwachstellen-Kombinationen dokumentieren, die ein Risiko für Ihre Werte erzeugen.

Beispiel:

• Wert: Produktions-PostgreSQL-Datenbank mit Kundendaten
• Bedrohung: SQL-Injection-Angriff über öffentliche API
• Schwachstelle: Eingabevalidierung nicht konsistent über alle API-Endpunkte implementiert
• Risiko: Unbefugter Zugriff auf Kundendaten durch SQL-Injection, was zu einer Datenschutzverletzung, behördlichen Meldepflichten und Reputationsschaden führt

Eintrittswahrscheinlichkeits- und Auswirkungsbewertung

Hier wandelt sich Ihre Risikobewertung von einer Liste von Bedenken in ein priorisiertes Entscheidungsinstrument.

Definition Ihrer Wahrscheinlichkeitsskala

Verwenden Sie beschreibende Definitionen, die Ihr Team konsistent anwenden kann. Vage Bezeichnungen wie „Niedrig” und „Mittel” ohne Definitionen führen zu inkonsistenter Bewertung.

Bewertung	Bezeichnung	Definition
1	Selten	Könnte nur unter außergewöhnlichen Umständen eintreten. Keine bekannten Vorfälle in vergleichbaren Organisationen.
2	Unwahrscheinlich	Könnte eintreten, wird aber nicht erwartet. Einzelne Vorfälle in der Branche bekannt.
3	Möglich	Könnte irgendwann eintreten. Vorfälle treten periodisch in vergleichbaren Organisationen auf.
4	Wahrscheinlich	Wird voraussichtlich in den meisten Fällen eintreten. Regelmäßige Vorfälle in der Branche.
5	Fast sicher	Wird voraussichtlich häufig eintreten. Kontinuierliches oder nahezu kontinuierliches Auftreten in der Branche.

Definition Ihrer Auswirkungsskala

Die Auswirkung sollte mehrere für Ihr SaaS-Geschäft relevante Dimensionen berücksichtigen:

Bewertung	Bezeichnung	Finanziell	Betrieblich	Reputationsbezogen	Regulatorisch
1	Vernachlässigbar	< 10.000 $	Keine Dienstunterbrechung	Keine externe Wahrnehmung	Kein regulatorisches Interesse
2	Gering	10.000 - 50.000 $	Kurze Unterbrechung, < 1 Stunde	Begrenzte Kundenbeschwerden	Informelle regulatorische Anfrage
3	Moderat	50.000 - 250.000 $	Unterbrechung 1-8 Stunden	Branchenmedienberichterstattung	Formelle Untersuchung
4	Erheblich	250.000 - 1 Mio. $	Längerer Ausfall 8-48 Stunden	Mainstream-Medienberichterstattung	Durchsetzungsmaßnahmen, Bußgelder
5	Schwerwiegend	> 1 Mio. $	Längerer Ausfall > 48 Stunden	Anhaltende negative Berichterstattung	Hohe Bußgelder, obligatorische Abhilfemaßnahmen

Die Risikomatrix

Multiplizieren Sie Wahrscheinlichkeit mit Auswirkung, um einen Risikowert zu erhalten. Eine 5x5-Matrix erzeugt Werte von 1 bis 25:

	Vernachlässigbar (1)	Gering (2)	Moderat (3)	Erheblich (4)	Schwerwiegend (5)
Fast sicher (5)	5	10	15	20	25
Wahrscheinlich (4)	4	8	12	16	20
Möglich (3)	3	6	9	12	15
Unwahrscheinlich (2)	2	4	6	8	10
Selten (1)	1	2	3	4	5

Risikobewertungsbänder

Definieren Sie, was die Werte für Behandlungsentscheidungen bedeuten:

• Kritisch (20-25): Sofortiges Handeln erforderlich. Das Risiko muss vor der nächsten Managementbewertung behandelt werden.
• Hoch (12-19): Behandlungsplan innerhalb von 30 Tagen erforderlich. Der Risikoeigentümer muss dem Management Optionen vorlegen.
• Mittel (6-11): Behandlungsplan innerhalb von 90 Tagen erforderlich. Überwachung in regelmäßigen Risikoreviews.
• Niedrig (1-5): Akzeptanz oder Behandlung basierend auf Kosten-Nutzen-Analyse. Überprüfung bei der jährlichen Bewertung.

Risikoappetit und Akzeptanzkriterien

Risikoappetit ist die Menge und Art des Risikos, das Ihre Organisation bereit ist, bei der Verfolgung ihrer Ziele einzugehen. Er wird von der obersten Leitung definiert und in Ihrer Risikomanagement-Richtlinie dokumentiert.

Festlegung des Risikoappetits

Ihre Risikoappetit-Erklärung sollte spezifisch genug sein, um Behandlungsentscheidungen zu leiten. „Wir haben einen niedrigen Risikoappetit” ist zu vage. Stattdessen:

• „Wir akzeptieren kein Restrisiko, das als Kritisch oder Hoch bewertet wird, für Risiken, die die Vertraulichkeit von Kundendaten betreffen.”
• „Wir akzeptieren ein mittleres Restrisiko für betriebliche Verfügbarkeitsrisiken, wenn die Kosten weiterer Minderungsmaßnahmen das Dreifache der annualisierten Verlusterwartung übersteigen.”
• „Wir akzeptieren kein Risiko, das zu einer Nichteinhaltung der DSGVO oder anderer Datenschutzvorschriften führen würde, die für unseren Kundenstamm gelten.”

Formale Risikoakzeptanz

Wenn ein Risiko innerhalb Ihrer Akzeptanzkriterien liegt — oder wenn das Management eine bewusste Entscheidung trifft, ein Risiko über dem normalen Schwellenwert zu akzeptieren — muss diese Entscheidung dokumentiert werden:

• Risikobeschreibung und aktuelle Bewertung
• Begründung für die Akzeptanz (Kosten-Nutzen-Analyse, niedriges Restrisiko nach bestehenden Kontrollen, strategische Entscheidung)
• Genehmiger — eine namentlich genannte Person mit der Befugnis, das Risiko zu akzeptieren (typischerweise CISO, CTO oder Vorsitzender des Risikoausschusses)
• Überprüfungsdatum — wann die Akzeptanz neu bewertet wird
• Bedingungen — alle Bedingungen, die die Akzeptanz ungültig machen würden (z. B. „akzeptiert bis der Kundenstamm 1.000 Mandanten übersteigt”)

Auditoren werden überprüfen, ob Risikoakzeptanz-Entscheidungen von autorisierten Personen getroffen, mit Begründung dokumentiert und regelmäßig überprüft werden. Undokumentierte Risikoakzeptanz ist eine häufige Feststellung von Nichtkonformitäten.

Planung der Risikobehandlung

Sobald Risiken bewertet und mit Ihren Akzeptanzkriterien abgeglichen sind, erfordert jedes Risiko über dem Schwellenwert einen Behandlungsplan. ISO 27001 definiert vier Behandlungsoptionen.

Option 1: Mindern (Reduzieren)

Implementieren Sie Kontrollen, um entweder die Eintrittswahrscheinlichkeit oder die Auswirkung des Risikos zu reduzieren. Dies ist die häufigste Behandlung und schafft die direkte Verbindung zwischen Ihrer Risikobewertung und Ihren Annex A Kontrollen.

Beispiel: Risiko des unbefugten Zugriffs auf Produktionsdatenbanken (Wert: 16, Hoch).

• Kontrollen: Implementierung der Multi-Faktor-Authentifizierung für alle Produktionszugriffe (A.8.5), Durchsetzung rollenbasierter Zugriffskontrolle mit minimalen Rechten (A.5.15), Aktivierung der Datenbankaktivitätsprotokollierung mit Alarmierung (A.8.15), Durchführung vierteljährlicher Zugriffsüberprüfungen (A.5.18).
• Erwartetes Restrisiko: 6 (Mittel) — Wahrscheinlichkeit durch Zugriffskontrollen von Wahrscheinlich auf Unwahrscheinlich reduziert; Auswirkung unverändert.

Option 2: Übertragen (Teilen)

Verlagern Sie einen Teil des Risikos auf einen Dritten. Gängige Mechanismen umfassen Cyberversicherungen und vertragliche Vereinbarungen mit Anbietern.

Beispiel: Risiko finanzieller Verluste durch eine Datenschutzverletzung (Wert: 15, Hoch).

• Behandlung: Abschluss einer Cyberversicherung, die die Kosten der Reaktion auf Datenschutzverletzungen, regulatorische Bußgelder (soweit versicherbar) und Betriebsunterbrechungen abdeckt. Aushandlung von Verträgen mit Anbietern, die Haftungsbestimmungen für Verletzungen durch Fahrlässigkeit des Anbieters enthalten.
• Hinweis: Die Übertragung reduziert die finanzielle Exposition, eliminiert aber nicht das Risiko. Sie benötigen weiterhin erkennende und reagierende Kontrollen.

Option 3: Vermeiden (Beenden)

Eliminieren Sie das Risiko, indem Sie die Aktivität, den Prozess oder das System entfernen, das es erzeugt.

Beispiel: Risiko der Datenexposition durch eine Legacy-API, die Basis-Authentifizierung verwendet (Wert: 12, Hoch).

• Behandlung: Stilllegung der Legacy-API und Migration aller Nutzer auf die aktuelle API, die OAuth 2.0 und Rate Limiting unterstützt. Das Risiko wird eliminiert, da die verwundbare Komponente nicht mehr existiert.

Option 4: Akzeptieren (Behalten)

Erkennen Sie das Risiko an und entscheiden Sie sich, keine zusätzlichen Maßnahmen zu ergreifen. Gültig, wenn das Risiko innerhalb Ihres Risikoappetits liegt oder wenn die Kosten der Behandlung die potenzielle Auswirkung deutlich übersteigen.

Beispiel: Risiko einer kurzen Dienstunterbrechung durch Cloud-Anbieter-Wartungsfenster (Wert: 4, Niedrig).

• Behandlung: Akzeptieren. Die geplante Wartung des Cloud-Anbieters erfolgt in verkehrsarmen Zeitfenstern und verursacht typischerweise weniger als 5 Minuten eingeschränkte Leistung. Die Kosten für die Implementierung einer Multi-Region Active-Active-Architektur zur Eliminierung dieses Risikos stehen in keinem Verhältnis zur Auswirkung.

Das Risikobehandlungsplan-Dokument

Ihr Risikobehandlungsplan sollte für jedes behandelte Risiko dokumentieren:

• Risikoreferenz — Verknüpfung zum Risikoregister
• Gewählte Behandlungsoption — mindern, übertragen, vermeiden oder akzeptieren
• Spezifische Maßnahmen — was durchgeführt wird
• Annex A Kontrollreferenzen — welche Kontrollen die Behandlung implementieren (bei Minderung)
• Verantwortlicher — wer für die Umsetzung der Behandlung zuständig ist
• Zieldatum — wann die Behandlung vollständig umgesetzt sein wird
• Benötigte Ressourcen — Budget, Personal, Werkzeuge
• Erwartetes Restrisiko — das erwartete Risikoniveau nach der Behandlung

Dieses Dokument ist eine obligatorische Eingabe für Ihre Erklärung zur Anwendbarkeit, die jede Annex A Kontrolle den Risiken zuordnet, die sie adressiert.

Verknüpfung von Risiken mit Annex A Kontrollen

Die Verbindung zwischen Risikobewertung und Annex A Kontrollen verleiht Ihrem ISMS Kohärenz. Jede Kontrolle, die Sie implementieren, sollte auf ein oder mehrere identifizierte Risiken zurückzuführen sein. Jedes wesentliche Risiko sollte durch eine oder mehrere Kontrollen adressiert werden (oder formell akzeptiert sein).

So funktioniert die Zuordnung

1. Beginnen Sie mit dem Risikobehandlungsplan. Identifizieren Sie für jedes Risiko, das Sie mindern, die spezifischen Kontrollmaßnahmen, die Sie ergreifen werden.
2. Ordnen Sie Maßnahmen den Annex A Kontrollen zu. Jede Kontrollmaßnahme entspricht einer oder mehreren der 93 Annex A Kontrollen. Beispiel: „Implementierung der Multi-Faktor-Authentifizierung” wird A.8.5 (Sichere Authentifizierung) zugeordnet.
3. Dokumentieren Sie die Zuordnung in Ihrer Erklärung zur Anwendbarkeit. Das SoA zeigt jede Annex A Kontrolle, ob sie ein- oder ausgeschlossen ist, und die Risikobegründung für diese Entscheidung.
4. Schließen Sie Kontrollen ein, die nicht durch die Risikobewertung getrieben sind. Einige Annex A Kontrollen adressieren gesetzliche, regulatorische oder vertragliche Anforderungen anstelle spezifischer Risiken. Diese werden dennoch mit entsprechender Begründung in das SoA aufgenommen.

Häufige Zuordnungen für SaaS-Unternehmen

Risiko	Annex A Kontrollen
Unbefugter Zugriff auf Kundendaten	A.5.15 (Zugriffskontrolle), A.5.16 (Identitätsmanagement), A.8.5 (Sichere Authentifizierung), A.8.3 (Informationszugangsbeschränkung)
Supply-Chain-Angriff über Drittanbieter-Code	A.5.19-A.5.22 (Kontrollen für Lieferantenbeziehungen), A.8.25 (Sicherer Entwicklungslebenszyklus), A.8.28 (Sichere Programmierung)
Datenschutzverletzung durch fehlkonfigurierte Cloud-Ressourcen	A.8.9 (Konfigurationsmanagement), A.8.8 (Management technischer Schwachstellen), A.8.15 (Protokollierung)
Ransomware stört den Betrieb	A.8.7 (Schutz gegen Schadsoftware), A.8.13 (Informationssicherung), A.5.24 (Planung des Vorfallmanagements)
Weggang einer Schlüsselperson	A.5.2 (Rollen der Informationssicherheit), A.5.4 (Managementverantwortlichkeiten), A.6.5 (Verantwortlichkeiten nach Beendigung)
DSGVO-Nichteinhaltung	A.5.34 (Datenschutz und Schutz personenbezogener Daten), A.5.31 (Gesetzliche, regulatorische Anforderungen)

Pflege des Risikoregisters

Ihr Risikoregister ist kein einmaliges Ergebnis. Es ist ein lebendiges Dokument, das Ihre aktuelle Bedrohungslandschaft, Kontrollumgebung und den Geschäftskontext widerspiegelt.

Erforderliche Felder

Jeder Risikoeintrag sollte erfassen:

• Risiko-ID — Eindeutiger Identifikator (z. B. RISK-2026-001)
• Risikotitel — Kurze Bezeichnung zur Referenz
• Risikobeschreibung — Detaillierte Beschreibung der Bedrohung, Schwachstelle und potenziellen Auswirkung
• Betroffene(r) Wert(e) — Welche Informationswerte gefährdet sind
• Bedrohungsquelle — Externer Angreifer, Insider, Umwelt, Anbieter
• Schwachstelle — Die Schwäche, die die Bedrohung ausnutzt
• Inhärente Wahrscheinlichkeit — Bewertung vor Kontrollen
• Inhärente Auswirkung — Bewertung vor Kontrollen
• Inhärenter Risikowert — Wahrscheinlichkeit x Auswirkung
• Bestehende Kontrollen — Derzeit vorhandene Kontrollen
• Restwahrscheinlichkeit — Bewertung nach Kontrollen
• Restauswirkung — Bewertung nach Kontrollen
• Restrisikowert — Wahrscheinlichkeit x Auswirkung nach Kontrollen
• Behandlungsentscheidung — Mindern, übertragen, vermeiden, akzeptieren
• Referenz Behandlungsplan — Verweis auf den Behandlungsplan
• Risikoeigentümer — Namentlich genannte verantwortliche Person
• Überprüfungsdatum — Wann das Risiko zuletzt überprüft wurde
• Status — Offen, in Behandlung, akzeptiert, geschlossen

Überprüfungshäufigkeit

• Kontinuierlich — Aktualisierung des Registers bei bedeutenden Ereignissen (Sicherheitsvorfälle, neue Schwachstellen, Anbieterverletzungen, Architekturänderungen, Onboarding von Lieferanten)
• Vierteljährlich — Formelle Überprüfung der Top-Risiken, des Behandlungsfortschritts und aufkommender Bedrohungen
• Jährlich — Vollständige Neubewertung aller Risiken als Teil der ISMS-Managementbewertung
• Anlassbedingt — Neubewertung bei wesentlichen Änderungen (neuer Produktstart, M&A, Infrastrukturmigration, neue Vorschriften)

Verbindung zur Internen Revision

Ihr internes Auditprogramm sollte überprüfen, dass der Risikobewertungsprozess wie dokumentiert funktioniert. Auditoren prüfen:

• Wurde die Methodik konsistent angewandt?
• Wurden während des Zeitraums identifizierte neue Risiken im Register erfasst?
• Wurden Behandlungspläne termingerecht umgesetzt?
• Wurden Risikoakzeptanz-Entscheidungen ordnungsgemäß genehmigt?
• Spiegelt das Register die im Zeitraum eingetretenen Änderungen wider?

SaaS-spezifische Risikobeispiele

Diese Beispiele veranschaulichen, wie reale SaaS-Risiken in einem Risikoregister dokumentiert werden. Sie sind keine Vorlage zum Kopieren — Ihre Risiken müssen Ihre spezifische Architektur, Daten und Ihren Geschäftskontext widerspiegeln.

Beispiel 1: Fehler bei der Multi-Tenant-Datenisolierung

Risiko-ID: RISK-2026-012 Beschreibung: Ein Softwarefehler in der Mandantenisolierungsschicht ermöglicht es einem Kunden, auf die Daten eines anderen Kunden zuzugreifen. Dies könnte durch einen fehlenden Mandanten-ID-Filter in einer Datenbankabfrage, einen Cache-Fehler, der Daten eines anderen Mandanten liefert, oder eine Race Condition im Session-Management verursacht werden. Wert: Kundendaten, Produktionsanwendung Inhärente Wahrscheinlichkeit: 3 (Möglich) — Mandantenisolierung ist komplex; ähnliche Vorfälle sind bei großen SaaS-Anbietern aufgetreten Inhärente Auswirkung: 5 (Schwerwiegend) — Datenschutzverletzung, die mehrere Kunden betrifft, obligatorische Meldung, schwerer Reputationsschaden Inhärenter Risikowert: 15 (Hoch) Bestehende Kontrollen: Mandanten-ID-Durchsetzung auf ORM-Ebene, Integrationstests für Mandantenisolierung, Code-Review-Anforderungen für Datenzugriffscode Restwahrscheinlichkeit: 2 (Unwahrscheinlich) Restauswirkung: 5 (Schwerwiegend) — Auswirkung ändert sich nicht; nur die Wahrscheinlichkeit wird reduziert Restrisikowert: 10 (Mittel) Behandlung: Mindern — Implementierung von Row-Level Security auf Datenbankebene als sekundärer Isolierungsmechanismus, Hinzufügen automatisierter Mandantenisolierungstests zur CI/CD-Pipeline, Bereitstellung von Laufzeitüberwachung für mandantenübergreifende Datenzugriffsmuster Kontrollen: A.8.25 (Sicherer Entwicklungslebenszyklus), A.8.28 (Sichere Programmierung), A.8.29 (Sicherheitstests), A.8.16 (Überwachungsaktivitäten)

Beispiel 2: Kompromittierte CI/CD-Pipeline

Risiko-ID: RISK-2026-018 Beschreibung: Ein Angreifer erhält Zugang zur CI/CD-Pipeline (GitHub Actions, Jenkins oder ähnlich) und schleust bösartigen Code in ein Produktionsdeployment ein. Angriffsvektoren umfassen kompromittierte GitHub-Tokens, bösartige Pull Requests aus geforkten Repositories oder Supply-Chain-Angriffe durch kompromittierte GitHub Actions, die in Workflows verwendet werden. Wert: Quellcode, Produktionsinfrastruktur, Kundendaten Inhärente Wahrscheinlichkeit: 3 (Möglich) — Supply-Chain-Angriffe nehmen an Häufigkeit zu Inhärente Auswirkung: 5 (Schwerwiegend) — Angreifer erreicht Codeausführung in der Produktion mit Zugriff auf alle Kundendaten Inhärenter Risikowert: 15 (Hoch) Bestehende Kontrollen: Pflicht-Code-Review für alle PRs, Branch Protection auf dem Hauptbranch, Secret Scanning in CI Restwahrscheinlichkeit: 2 (Unwahrscheinlich) Restauswirkung: 5 (Schwerwiegend) Restrisikowert: 10 (Mittel) Behandlung: Mindern — Implementierung signierter Commits, Festpinnen aller GitHub Actions auf spezifische SHA-Hashes, Bereitstellung von SLSA Level 2 Build Provenance, Einschränkung des Zugriffs auf selbstgehostete Runner, Implementierung der Integritätsprüfung von Build-Artefakten Kontrollen: A.8.25 (Sicherer Entwicklungslebenszyklus), A.8.9 (Konfigurationsmanagement), A.5.19 (Informationssicherheit in Lieferantenbeziehungen), A.8.15 (Protokollierung)

Beispiel 3: Sicherheitsverletzung bei einem Drittanbieter-SaaS-Anbieter

Risiko-ID: RISK-2026-024 Beschreibung: Ein SaaS-Anbieter, der Unternehmens- oder Kundendaten verarbeitet oder speichert, erleidet eine Sicherheitsverletzung, die ihm anvertraute Daten offenlegt. Betroffene Anbieter könnten Identitätsanbieter, Analyseplattformen, Kundensupport-Tools oder Zahlungsdienstleister sein. Wert: Kundendaten, Mitarbeiterdaten, Geschäftsdaten Inhärente Wahrscheinlichkeit: 4 (Wahrscheinlich) — Anbieterverletzungen sind branchenweit häufig Inhärente Auswirkung: 4 (Erheblich) — je nach Anbieter könnten personenbezogene Kundendaten offengelegt werden, eine Verletzungsmeldung erforderlich sein und Reputationsschäden entstehen Inhärenter Risikowert: 16 (Hoch) Bestehende Kontrollen: Sicherheitsbewertung von Anbietern beim Onboarding, vertragliche Datenschutzklauseln, jährliche Anbieterüberprüfung Restwahrscheinlichkeit: 3 (Möglich) — die Sicherheitslage des Anbieters kann nicht vollständig kontrolliert werden Restauswirkung: 3 (Moderat) — Auswirkung durch Datenminimierung und Verschlüsselung reduziert Restrisikowert: 9 (Mittel) Behandlung: Mindern — Implementierung kontinuierlicher Anbieterüberwachung, Anforderung einer SOC 2 Type II- oder ISO 27001-Zertifizierung von kritischen Anbietern, Minimierung der mit Anbietern geteilten Daten auf das betrieblich Notwendige, Verschlüsselung sensibler Daten vor der Übermittlung an Anbieter, Pflege von Playbooks zur Anbieter-Vorfallreaktion Kontrollen: A.5.19-A.5.22 (Kontrollen für Lieferantenmanagement), A.5.31 (Gesetzliche Anforderungen), A.8.11 (Datenmaskierung)

Beispiel 4: Fehlkonfiguration der Cloud-Infrastruktur

Risiko-ID: RISK-2026-031 Beschreibung: Eine Fehlkonfiguration in der Cloud-Infrastruktur (AWS, GCP, Azure) macht Ressourcen über das öffentliche Internet zugänglich. Beispiele sind öffentlich zugängliche S3-Buckets, Security Groups, die uneingeschränkten eingehenden Zugriff erlauben, unverschlüsselte Datenbankinstanzen mit öffentlichen Endpunkten oder übermäßig freizügige IAM-Rollen. Wert: Produktionsinfrastruktur, Kundendaten, Anwendungsdaten Inhärente Wahrscheinlichkeit: 4 (Wahrscheinlich) — Fehlkonfigurationen sind die häufigste Ursache für Cloud-Sicherheitsvorfälle Inhärente Auswirkung: 4 (Erheblich) — könnte Kundendaten offenlegen, Angreifern laterale Bewegung ermöglichen oder Ressourcenmissbrauch erlauben Inhärenter Risikowert: 16 (Hoch) Bestehende Kontrollen: Infrastructure-as-Code mit PR-Review, AWS Config-Regeln für häufige Fehlkonfigurationen Restwahrscheinlichkeit: 2 (Unwahrscheinlich) — IaC und automatisierte Prüfungen reduzieren die Wahrscheinlichkeit erheblich Restauswirkung: 4 (Erheblich) — Auswirkung unverändert, wenn eine Fehlkonfiguration auftritt Restrisikowert: 8 (Mittel) Behandlung: Mindern — Implementierung eines Cloud Security Posture Management (CSPM) Tools, Durchsetzung von Infrastructure-as-Code für alle Cloud-Ressourcenänderungen (keine manuellen Konsolenänderungen), Bereitstellung von AWS SCPs zur Verhinderung der Erstellung öffentlicher Ressourcen, Durchführung vierteljährlicher Cloud-Konfigurationsaudits Kontrollen: A.8.9 (Konfigurationsmanagement), A.8.8 (Management technischer Schwachstellen), A.8.15 (Protokollierung), A.8.23 (Webfilterung)

Beispiel 5: Insider-Datenexfiltration

Risiko-ID: RISK-2026-037 Beschreibung: Ein Mitarbeiter oder Auftragnehmer mit privilegiertem Zugang zu Produktionssystemen exfiltriert absichtlich Kundendaten zum persönlichen Vorteil, Wettbewerbsvorteil oder aus böswilliger Absicht. Dies umfasst Datenbankexporte, API-Datenextraktion oder das Kopieren von Daten auf persönliche Speichermedien. Wert: Kundendaten, geistiges Eigentum Inhärente Wahrscheinlichkeit: 2 (Unwahrscheinlich) — Insider-Angriffe sind seltener als externe Angriffe, treten aber auf Inhärente Auswirkung: 5 (Schwerwiegend) — Datenschutzverletzung, behördliche Meldepflichten, Haftung, schwerer Reputationsschaden Inhärenter Risikowert: 10 (Mittel) Bestehende Kontrollen: Rollenbasierte Zugriffskontrolle, Hintergrundüberprüfungen für Mitarbeiter mit Produktionszugang, Geheimhaltungsvereinbarungen Restwahrscheinlichkeit: 1 (Selten) — Kontrollen reduzieren das Insider-Risiko, können es aber nicht eliminieren Restauswirkung: 5 (Schwerwiegend) Restrisikowert: 5 (Niedrig) Behandlung: Mindern — Implementierung der Datenbankaktivitätsüberwachung mit Alarmierung bei Massendatenexporten, Bereitstellung von DLP-Kontrollen auf Endpunkten und E-Mail, Durchsetzung von Just-in-Time-Zugriff für Produktionsdatenbanken, Durchführung vierteljährlicher Zugriffsüberprüfungen zur Sicherstellung minimaler Rechte, Protokollierung und Überwachung aller Produktionszugriffe Kontrollen: A.5.15 (Zugriffskontrolle), A.6.1 (Überprüfung), A.6.2 (Beschäftigungsbedingungen), A.8.15 (Protokollierung), A.8.16 (Überwachungsaktivitäten), A.8.12 (Verhinderung von Datenabfluss)

Integration der Risikobewertung in den ISMS-Lebenszyklus

Die Risikobewertung ist keine eigenständige Übung. Sie verbindet sich mit jeder anderen Komponente Ihres ISMS.

Verbindung zur Erklärung zur Anwendbarkeit

Ihr Risikobehandlungsplan ist die primäre Eingabe für die Erklärung zur Anwendbarkeit. Das SoA listet alle 93 Annex A Kontrollen auf und gibt an, ob jede ein- oder ausgeschlossen ist, mit Begründung. Für eingeschlossene Kontrollen verweist die Begründung auf die Risiken, die die Kontrolle adressiert. Für ausgeschlossene Kontrollen erklärt die Begründung, warum das Risiko nicht zutrifft.

Verbindung zu Richtlinien und Verfahren

Ihre ISMS-Richtlinien sollten die Risikobewertung als Grundlage für Kontrollanforderungen referenzieren. Beispiel: Ihre Zugriffskontrollrichtlinie gibt nicht einfach an „Multi-Faktor-Authentifizierung ist erforderlich” — sie gibt an, dass MFA erforderlich ist, weil die Risikobewertung unbefugten Zugriff als hohes Risiko für die Vertraulichkeit von Kundendaten identifiziert hat.

Verbindung zum Zertifizierungsprozess

Während Ihres ISO 27001 Zertifizierungsaudits wird der Auditor Ihre Risikobewertungsmethodik, das Risikoregister, den Behandlungsplan und die Verbindung zwischen Risiken und Kontrollen prüfen. Häufige Auditfeststellungen im Zusammenhang mit der Risikobewertung umfassen:

• Risikobewertungsmethodik nicht dokumentiert oder nicht befolgt
• Risikoregister nicht aktualisiert, um Änderungen während des Prüfungszeitraums widerzuspiegeln
• Behandlungspläne ohne Umsetzungsnachweise
• Annex A Kontrollen im SoA ohne entsprechende Risikobegründung
• Risikoakzeptanz-Entscheidungen ohne Managementgenehmigung
• Keine Nachweise für periodische Risikoüberprüfung

Verbindung zur DSGVO und zum Datenschutz

Wenn Ihr SaaS-Unternehmen personenbezogene Daten verarbeitet, die der DSGVO unterliegen, unterstützt Ihre ISO 27001 Risikobewertung — ersetzt aber nicht — Datenschutz-Folgenabschätzungen (DSFAs). Die beiden Prozesse ergänzen sich: Ihre ISMS-Risikobewertung deckt Informationssicherheitsrisiken breit ab, während DSFAs sich speziell auf die Risiken für die Rechte und Freiheiten betroffener Personen aus spezifischen Verarbeitungstätigkeiten konzentrieren.

Häufige Fehler bei der ISO 27001 Risikobewertung

Sie als einmalige Übung behandeln. Eine Risikobewertung, die einmal während der Zertifizierung durchgeführt und bis zum Überwachungsaudit vergessen wird, ist eine Compliance-Übung, keine Sicherheitspraxis. Ihre Bedrohungslandschaft ändert sich kontinuierlich. Neue Schwachstellen werden entdeckt, neue Anbieter eingebunden, die Infrastruktur entwickelt sich weiter und Angriffstechniken werden fortschrittlicher. Ihre Risikobewertung muss Schritt halten.

Generische Vorlagen ohne Anpassung verwenden. Ein Risikoregister, das „Brand im Rechenzentrum” für ein zu 100 % Cloud-natives SaaS-Unternehmen auflistet, spiegelt nicht die Realität wider. Ihre Risiken sollten spezifisch für Ihre Architektur, Ihren Technologie-Stack, Ihren Kundenstamm und Ihr Geschäftsmodell sein. Generische Vorlagen sind ein Ausgangspunkt für die Struktur, nicht für den Inhalt.

Die richtigen Personen nicht einbeziehen. Ingenieure wissen, wo die technischen Schulden liegen. Produktmanager wissen, welche Funktionen die sensibelsten Daten verarbeiten. Customer-Success-Teams wissen, welche Verfügbarkeitszusagen gemacht wurden. Sicherheitsteams allein können nicht alle relevanten Risiken identifizieren. Funktionsübergreifende Workshops erzeugen vollständigere Risikoregister.

Alles als Mittel bewerten. Wenn jedes Risiko in Ihrem Register zwischen 6 und 12 bewertet wird, differenzieren Ihre Bewertungskriterien nicht effektiv genug. Überprüfen Sie Ihre Wahrscheinlichkeits- und Auswirkungsdefinitionen, um sicherzustellen, dass sie eine sinnvolle Unterscheidung erzeugen. Ein gut kalibriertes Risikoregister sollte Risiken über den gesamten Bewertungsbereich verteilt haben.

Risikobewertung von Kontrollentscheidungen trennen. Wenn Ihr Risikoregister und Ihre Kontrollimplementierung in getrennten Dokumenten ohne Querverweise leben, werden Auditoren die Lücke sofort identifizieren. Jede Kontrolle sollte auf ein Risiko rückführbar sein. Jedes wesentliche Risiko sollte auf eine Kontrolle oder eine Akzeptanzentscheidung rückführbar sein.

Die Methodik nicht dokumentieren. „Wir haben Risiken gebrainstormt und aufgeschrieben” ist keine Methodik. Dokumentieren Sie Ihre Bewertungskriterien, Ihren Bewertungsprozess, Ihre Überprüfungshäufigkeit und die beteiligten Rollen. Das Methodendokument ist selbst ein prüfbares Artefakt.

Wie GRCTrail hilft

GRCTrail bietet SaaS-Unternehmen die Werkzeuge und Strukturen, um einen ISO 27001 Risikobewertungsprozess durchzuführen, der Auditoren zufriedenstellt und echte Sicherheitserkenntnisse liefert.

• Geführter Risikobewertungs-Workflow, der Ihr Team durch die Anforderungen der Klausel 6.1.2 führt — von der Methodendefinition bis zum Abschluss des Risikoregisters — und sicherstellt, dass jeder Schritt den Standard erfüllt, ohne einen externen Berater zur Interpretation der Klauseln zu benötigen
• Vorausgefüllte SaaS-Risikobibliothek mit Bedrohungsszenarien, die speziell auf Cloud-native SaaS-Unternehmen zugeschnitten sind und Multi-Tenant-Isolierung, CI/CD-Pipeline-Sicherheit, Cloud-Fehlkonfiguration, Supply-Chain-Risiken und Anbieterabhängigkeiten abdecken, sodass Sie mit relevanten Bedrohungen statt leeren Vorlagen beginnen
• Automatische Annex A Kontrollzuordnung, die identifizierte Risiken mit den 93 Annex A Kontrollen verknüpft und direkt in Ihre Erklärung zur Anwendbarkeit einfließt, wobei die Nachverfolgbarkeit von der Bedrohung über die Behandlung bis zur Kontrolle erhalten bleibt

Jetzt mit GRCTrail starten →

Verwandte Leitfäden

• Was ist ISO 27001? Ein Leitfaden für SaaS-Unternehmen
• ISO 27001 Anforderungen: Die Klauseln 4-10 verstehen
• ISO 27001 Annex A Kontrollen: Vollständiger Leitfaden zu allen 93 Kontrollen
• ISO 27001 Erklärung zur Anwendbarkeit: So erstellen Sie sie
• ISO 27001 Lieferantenmanagement-Leitfaden
• ISO 27001 Zertifizierungs-Checkliste
• SOC 2 Risikobewertungsleitfaden
• DSGVO DSFA-Leitfaden