In einem Satz. Der BSI-Standard 200-3 liefert eine vereinfachte Risikoanalyse-Methodik, die bei Anwendung des IT-Grundschutzes eine vertiefte Betrachtung für hohen oder sehr hohen Schutzbedarf, nicht hinreichend modellierte Zielobjekte und besondere Einsatzumgebungen beschreibt — vier Schritte: Gefährdungsübersicht, Risikoeinstufung, Risikobehandlung, Konsolidierung.
200-3 ist die Brücke zwischen pauschaler Grundschutz-Modellierung und individueller Risikobewertung. Die DSGVO schreibt diese BSI-Methode nicht allgemein vor. Sie verlangt nach Artikel 32 eine dem konkreten Verarbeitungsrisiko angemessene Sicherheit; eine nachvollziehbar angewandte Methode kann die Auswahl und Überprüfung von Maßnahmen stützen. Für den Methodik-Überblick siehe BSI-Grundschutz-Methodik und DSGVO Artikel 32. Standardtext und Gefährdungskatalog stellt das BSI zu den BSI-Standards kostenfrei bereit; die datenschutzrechtliche Zielnorm ist Art. 32 DSGVO.
Wichtige Punkte
- BSI 200-3 ist vereinfachte Risikoanalyse, ergänzt 200-2 — keine vollständige ISO/IEC 27005.
- Prüfanlässe innerhalb des IT-Grundschutzes: hoher Schutzbedarf, Modellierungslücke oder besondere Einsatzumgebung.
- Die zum verwendeten Kompendium gehörenden elementaren Gefährdungen sind Ausgangspunkt; projektspezifische Gefährdungen kommen hinzu.
- Risikomatrix mit Eintrittswahrscheinlichkeit x Schadenshöhe.
- Vier Behandlungsoptionen: Vermeidung, Reduktion, Transfer, Akzeptanz.
Wann ist 200-3 Pflicht?
Drei Auslöser nach BSI-Methodik:
- Schutzbedarf “hoch” oder “sehr hoch” bei einem Zielobjekt
- Kein passender Baustein im IT-Grundschutz-Kompendium
- Einsatzbereich ist atypisch (z.B. besondere Bedrohungslage)
Beispiel: Für ein klinisches Informationssystem kann die Einrichtung nach einer begründeten Schutzbedarfsfeststellung hohen oder sehr hohen Bedarf bei Vertraulichkeit und Verfügbarkeit feststellen. Dann vertieft sie die Analyse im gewählten IT-Grundschutz-Vorgehen; die Einstufung folgt dem möglichen Schaden, nicht allein der Datenart.
Der Auslöser “hoher Schutzbedarf” ist in der Praxis der häufigste — und er hängt eng mit dem Datenschutz zusammen. Immer dann, wenn eine Verarbeitung besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO betrifft (Gesundheits-, Biometrie- oder Gewerkschaftsdaten), kann die Schutzbedarfsfeststellung einen hohen Bedarf ergeben. Eine gesonderte Prüfung kann auch eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO ergeben; weder die Datenkategorie allein noch die 200-3-Einstufung entscheidet darüber. Beide Analysen bewerten Risiken aus unterschiedlichen Blickwinkeln: 200-3 aus Sicht der Informationssicherheit, die DSFA aus Sicht der Rechte und Freiheiten der Betroffenen. Wer sie parallel und aufeinander abgestimmt führt, spart Doppelarbeit und erhält eine widerspruchsfreie Risikodokumentation.
Erstellung der Gefährdungsübersicht
Auswahl relevanter Gefährdungen aus dem Katalog der elementaren Gefährdungen der verwendeten Kompendium-Edition. Nummern und Bezeichnungen sind gegen diese Edition zu prüfen. Beispiele aus dem bisherigen Katalog:
- G 0.14 Ausspähen von Informationen (Spionage)
- G 0.18 Fehlplanung oder fehlende Anpassung
- G 0.23 Unbefugtes Eindringen in IT-Systeme
- G 0.36 Identitätsdiebstahl
- G 0.40 Verhinderung von Diensten (DoS)
Pro Zielobjekt werden alle einschlägigen Gefährdungen erfasst, ggf. ergänzt durch organisationsspezifische.
Risikoeinstufung
Bewertung jeder Gefährdung in zwei Dimensionen:
Der BSI-Standard 200-3 im Original beschreibt qualitative Stufen für Eintrittshäufigkeit und potenzielle Schadenshöhe. Die Organisation muss die Grenzen ihrer Kategorien mit den Fachbereichen so definieren, dass zwei Bearbeiter einen vergleichbaren Fall ähnlich bewerten. Pauschale Eurogrenzen wären dafür ungeeignet: Ein Tag Ausfall kann je nach Dienstleistung geringe Kosten oder eine Gefährdung von Menschen bedeuten. Schätzen Sie unmittelbare Folgen, Folgeschäden, Wiederherstellungszeit und bereits wirksame Schutzmaßnahmen getrennt. Halten Sie Unsicherheit fest, anstatt eine Scheingenauigkeit aus Multiplikation zweier Zahlen zu erzeugen.
Die Risikokategorie entsteht aus der Kombination beider Dimensionen. Legen Sie eine organisationsweit verwendete Matrix, die Kriterien für Handlungsbedarf und die entscheidende Rolle vor der Einzelfallbewertung fest. Ein Risiko, das für eine kleine Testumgebung tragbar ist, kann für ein produktives System mit kritischen Abhängigkeiten untragbar sein. Die Matrix ist eine Entscheidungshilfe; begründen Sie Abweichungen und beziehen Sie die Fachverantwortlichen ein. Für die vorgelagerte Schutzbedarfsfeststellung erläutert BSI 200-2 die Modellierung.
Risikobehandlung
Vier Optionen pro Risiko:
- Vermeidung — Aktivität einstellen, Komponente entfernen
- Reduktion — zusätzliche Maßnahmen (Verschlüsselung, MFA, Monitoring)
- Transfer — Cyberversicherung, Outsourcing an zertifizierten Dienstleister
- Akzeptanz — bewusste Restrisikoübernahme mit Begründung und Genehmigung Leitung
Ob ein Restrisiko akzeptiert werden darf, richtet sich nach den zuvor festgelegten Kriterien, rechtlichen Pflichten und der zuständigen Entscheidungsebene; eine dokumentierte Akzeptanz ersetzt erforderliche Schutzmaßnahmen nicht. Für Verfügbarkeitsrisiken greift ergänzend das Notfallmanagement nach BSI 200-4.
In der Praxis dominiert die Risikoreduktion — sie ist die typische Antwort auf hoch bewertete Risiken. Der Transfer über eine Cyberversicherung wird oft missverstanden: Eine Versicherung deckt finanzielle Folgen, aber sie beseitigt weder das Risiko noch die datenschutzrechtliche Verantwortung des Verantwortlichen. Deckungsumfang und Ausschlüsse müssen anhand der konkreten Police geprüft werden. Die Akzeptanz schließlich ist an strenge Bedingungen geknüpft: Sie verlangt eine explizite, dokumentierte Entscheidung der Leitungsebene, nicht des IT-Betriebs. Ein akzeptiertes Restrisiko, das nie formal freigegeben wurde, ist im Audit wertlos und erschwert im Schadensfall die Rechenschaft. Deshalb gehört jede Akzeptanzentscheidung ins Risikoregister — mit Datum, Begründung und Unterschrift der verantwortlichen Führungskraft.
Konsolidierung im Sicherheitskonzept
Ergänzende Maßnahmen werden in das bestehende Sicherheitskonzept aus 200-2 integriert. Restrisiken werden dokumentiert und von der Leitung formal akzeptiert. Output: aktualisiertes Sicherheitskonzept inklusive Risikoregister.
Eine Risikoanalyse vorbereiten, die ein Team wirklich verwenden kann
Beginnen Sie mit einem eindeutig bezeichneten Zielobjekt und dem aktuellen Informationsverbund. Ein Name wie „Cloud“ ist zu breit: Welche Anwendung, welche Mandanten, welcher Betreiber, welche Schnittstellen und welcher Standort sind gemeint? Halten Sie Datenflüsse und technische Abhängigkeiten fest. Wenn mehrere nahezu gleiche Server zusammen bewertet werden, dokumentieren Sie die Gruppierungsregel und prüfen Sie die Ausnahmen. Ein abweichend exponiertes Administrationssystem gehört möglicherweise in eine eigene Analyse. Übernehmen Sie anschließend den begründeten Schutzbedarf aus der Strukturanalyse. Die verantwortliche Fachabteilung sollte Folgen eines Ausfalls oder einer Manipulation beschreiben; die IT kann die Geschäftsfolgen allein selten belastbar beurteilen.
Bestimmen Sie vor Workshops, wer Informationen liefert und wer Entscheidungen trifft. Sicherheitsverantwortliche koordinieren die Methode, technische Betreiber beschreiben die Architektur, Prozessverantwortliche bewerten Auswirkungen, Datenschutzverantwortliche ergänzen Risiken für betroffene Personen. Die Leitung legt Akzeptanzkriterien und Eskalationsgrenzen fest. Wenn ein Dienstleister beteiligt ist, brauchen Sie Informationen zu dessen Maßnahmen und Zuständigkeiten; eine bloße Zertifikatskopie erklärt nicht, wie Ihr konkreter Dienst abgesichert wird. Für die praktische Zuordnung von Pflichten und Nachweisen hilft auch der Leitfaden zu technischen und organisatorischen Maßnahmen.
Von der Gefährdung zur überprüfbaren Maßnahme
Eine Gefährdungsliste ist noch kein Risikoregister. Formulieren Sie für jeden relevanten Fall ein Szenario: Ein kompromittiertes Administratorkonto erlaubt Zugriff auf die Kundendatenbank; ein Ausfall der Identitätsplattform verhindert die Anmeldung am klinischen System; ein fehlerhafter Wiederherstellungsprozess verlängert den Stillstand. Nennen Sie Ursache, betroffene Zielobjekte, mögliche Folgen und bestehende Schutzvorkehrungen. Der BSI-Katalog hilft beim systematischen Suchen, aber neue Architekturmerkmale und Lieferketten erfordern eigene Szenarien. Bei einem Cloud-Dienst müssen beispielsweise Mandantentrennung, privilegierte Zugriffe und Ausstiegsmöglichkeiten konkret geprüft werden.
Bewerten Sie zuerst das Risiko unter den tatsächlich vorhandenen Maßnahmen. Eine geplante Verschlüsselung ist noch keine wirksame Kontrolle. Trennen Sie Eintrittseinschätzung und mögliche Schadenshöhe; notieren Sie die Belege, etwa Störungsdaten, Restore-Übungen oder bekannte Schwachstellen. Halten Sie fest, wo nur eine Annahme vorliegt. Ein technischer Scan kann eine Schwachstelle belegen, aber nicht allein den Schaden für den Geschäftsprozess bestimmen. Eine DSFA kann zusätzliche Informationen zu Nachteilen für Personen liefern, ersetzt jedoch weder die Schutzbedarfsfeststellung noch die Sicherheitsrisikoanalyse.
Die Behandlung sollte mit dem Szenario verknüpft sein. „MFA einführen“ ist zu ungenau, wenn nur Standardnutzer erfasst werden, während privilegierte Konten ausgenommen bleiben. Besser ist eine Maßnahme mit betroffenen Systemen, Verantwortlichem, Termin und Wirksamkeitsnachweis. Legen Sie fest, wie ihre Wirkung überprüft wird: Konfigurationstest, Zugriffsrezertifizierung, Wiederherstellungstest oder unabhängige Prüfung. Bei einem Ausfallrisiko braucht der technische Wiederanlauf ein mit dem Geschäftsprozess abgestimmtes Ziel. Der BSI-200-4-Leitfaden vertieft diesen Teil.
Wie die Wirkung einer ausgewählten Maßnahme mit Beobachtung statt nur mit einer Maßnahmenliste geprüft wird, zeigt der Prüfplan für Sicherheitskontrollen.
Restrisiko und Änderungsanlass dokumentieren
Nach Umsetzung der Maßnahme bewerten Sie das verbleibende Risiko erneut. Verwechseln Sie einen niedriger gesetzten Matrixwert nicht mit einer nachgewiesenen Reduktion: Der Nachweis gehört an dieselbe Entscheidung. Ist eine Maßnahme offen, bleibt das Risiko bis zu ihrem Wirksamkeitsnachweis grundsätzlich im vorherigen Zustand. Eine zeitlich befristete Ausnahme sollte den Grund, kompensierende Kontrollen, die zuständige Genehmigung und das Ablaufdatum enthalten. Bei einer rechtlich gebotenen Mindestanforderung ist „Akzeptanz“ keine Alternative zur Erfüllung.
Die Analyse gehört in einen nachvollziehbaren Änderungsprozess. Neue Datenarten, zusätzliche Schnittstellen, ein Anbieterwechsel, Sicherheitsvorfälle oder ein veränderter Bedrohungskontext können die frühere Bewertung entwerten. Prüfen Sie dann gezielt betroffene Szenarien, statt jeden Eintrag mechanisch neu zu schreiben. Dokumentieren Sie Versionsstand, Anlass und geänderte Entscheidung. So lässt sich im Audit erklären, warum eine Maßnahme gewählt, getestet oder später verworfen wurde. Die Verbindung zum ISMS nach BSI 200-1 sorgt dafür, dass Zuständigkeit und Review nicht beim einmaligen Projekt enden.
Beispiel: Zugriff auf eine kommunale Fachanwendung
Eine Verwaltung betreibt eine Fachanwendung mit personenbezogenen Anträgen. Die Schutzbedarfsfeststellung ergibt hohe Vertraulichkeit; die Fachabteilung begründet dies mit möglichen Nachteilen für Bürger bei Offenlegung. Das Team stellt fest, dass ein externer Supportkanal mit privilegierten Rechten erreichbar ist. Das Szenario lautet nicht „Hackerangriff“, sondern „Missbrauch eines Supportkontos führt zur Einsicht in unbeteiligte Anträge“. Bestehende Kontrollen sind ein VPN und Protokollierung, aber keine zeitliche Freigabe des Zugangs. Das Team bewertet Häufigkeit und Schaden nach seiner zuvor festgelegten Matrix und vermerkt, welche Annahmen noch überprüft werden müssen.
Als Behandlung wird der Zugriff auf einzelne Supportfälle begrenzt, mit starker Authentisierung versehen und nach jeder Sitzung geprüft. Der Betreiber liefert Konfigurationsnachweise; die Fachabteilung testet, ob der Support weiterhin seinen Zweck erfüllt. Erst danach wird das Restrisiko neu bewertet. Parallel prüft die Datenschutzstelle, ob die Verarbeitung eine Datenschutz-Folgenabschätzung braucht. Der gemeinsame technische Sachverhalt kann beide Prüfungen speisen, ihre jeweiligen rechtlichen Fragen bleiben getrennt. Diese konkrete Spur aus Ausgangslage, Entscheidung und Test ist nützlicher als eine pauschale Aussage, das System sei „grundschutzkonform“.
Verhältnis zu anderen Risikomethoden
BSI 200-3 baut auf der Strukturanalyse, Schutzbedarfsfeststellung und Modellierung des IT-Grundschutzes auf. Eine Organisation mit einem anderen ISMS kann eine andere geeignete Risikomethode wählen. Ein pauschaler Gegensatz zwischen „nur qualitativ“ und „auch quantitativ“ wäre falsch: BSI 200-3 erläutert in Abschnitt 5.1 sowohl qualitative als auch quantitative Betrachtungen und empfiehlt wegen fehlender belastbarer Daten häufig qualitative Kategorien. Entscheidend sind passende Kriterien, nachvollziehbare Entscheidungen und die Wirksamkeit der Maßnahmen. Bei einer ISO-27001-Zertifizierung auf Basis von IT-Grundschutz gelten zusätzlich die Anforderungen des jeweiligen BSI-Zertifizierungsschemas.
Beispiel: Risikoanalyse Webshop
Illustratives Zielobjekt: Webshop-Anwendung. Ob sein Schutzbedarf hoch ist, muss die konkrete Organisation begründen; die folgenden Kategorien und Zuordnungen sind nur ein Beispiel einer von ihr festzulegenden Matrix.
- G 0.23 Unbefugtes Eindringen → mittel x beträchtlich = hoch → WAF, Pentest, Monitoring
- G 0.40 DoS → häufig x begrenzt = hoch → CDN, Rate-Limiting
- G 0.14 Ausspähen → selten x existenzbedrohend = hoch → Verschlüsselung, Zugriffslogs
Das Beispiel zeigt die eigentliche Stärke der Methodik: Sie zwingt zu expliziten, begründeten Entscheidungen statt zu pauschalem “wir tun schon genug”. Für jedes hoch bewertete Risiko wird eine konkrete Behandlung dokumentiert, samt Verantwortlichem und Umsetzungstermin. Ob PCI DSS für einen Webshop relevant ist, hängt von seinem konkreten Umgang mit Kartendaten und den Vertragsregeln des Zahlungsökosystems ab. Ob der Zahlungsdienstleister Auftragsverarbeiter oder eigenständig Verantwortlicher ist, ist gesondert nach seinen tatsächlichen Zwecken und Weisungsbindungen zu prüfen. Die Risikoanalyse wird damit zum Bindeglied zwischen technischer Absicherung, vertraglicher Steuerung und datenschutzrechtlicher Rechenschaft — genau das erwartet eine Aufsichtsbehörde, wenn sie nach der Angemessenheit der Maßnahmen fragt.
200-3 und DSGVO Artikel 32
Artikel 32 verlangt risikobasierte TOMs. Eine dokumentierte 200-3-Analyse kann einen Teil der Entscheidungsgrundlage dafür liefern — inkl. Begründung, warum welche Maßnahmen “angemessen” sind. Sie kann bei Datenpannen-Meldungen und Aufsichtskontrollen eine relevante Entscheidungsgrundlage liefern; entscheidend bleibt, ob die Maßnahmen tatsächlich angemessen und wirksam waren.
Der juristische Kern von Art. 32 ist die Formulierung “unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos”. Diese Faktoren verlangen eine dokumentierte Risikoabwägung; BSI 200-3 kann deren informationssicherheitsbezogenen Teil strukturieren. Wenn eine Aufsichtsbehörde nach einer Datenpanne fragt, warum eine bestimmte Maßnahme fehlte oder eine andere gewählt wurde, ist die dokumentierte Risikobewertung die Antwort. Ohne sie steht der Verantwortliche mit einer bloßen Behauptung da; mit ihr kann er belegen, dass die Auswahl der Maßnahmen das Ergebnis einer nachvollziehbaren, an Wahrscheinlichkeit und Schadenshöhe orientierten Abwägung war. Eine Dokumentation allein beweist jedoch weder Wirksamkeit noch Rechtskonformität.
Häufige Fehler
- Risikobewertung “aus dem Bauch” ohne Datengrundlage
- Akzeptanz hoher Risiken ohne formale Geschäftsführungsfreigabe
- Vergessene Aktualisierung bei Systemänderungen
- Kein Risikoregister → keine Nachvollziehbarkeit im Audit
Welche Unterlagen sollte das Risikoregister enthalten?
Ein Werkzeug kann die Zusammenarbeit erleichtern, entscheidet aber keine Risikokategorie. Halten Sie je Eintrag Zielobjekt und Geltungsbereich, Szenario, Quelle der Gefährdung, vorhandene Maßnahmen, Erstbewertung, Behandlung, Verantwortliche, Frist und Wirksamkeitsprüfung fest. Ergänzen Sie die erneute Bewertung und die begründete Entscheidung über das Restrisiko. Verweisen Sie auf die Version der Schutzbedarfsfeststellung und die zugehörigen Anforderungen im Sicherheitskonzept. So können andere Prüfer die Kette rekonstruieren, ohne aus verstreuten Tabellen zu raten.
Bei personenbezogenen Daten lohnt sich eine kontrollierte Verbindung zu Art. 32 DSGVO, zur passenden DSFA-Vorlage und zu den jeweiligen Verarbeitungsvorgängen. Das ist eine Dokumentationshilfe, keine automatische Bestätigung von Konformität. Rechte und Zugriffe im Register sollten der Sensibilität der darin beschriebenen Schwachstellen entsprechen. Eine exportierbare Historie erleichtert außerdem spätere Überprüfungen nach einem Vorfall oder Architekturwechsel.
Prüffragen vor der Freigabe
Kann ein anderer Bearbeiter erkennen, warum genau dieses Zielobjekt einbezogen wurde? Ist die Auswahl der Gefährdungen nachvollziehbar und deckt sie auch Besonderheiten der eingesetzten Technologie ab? Sind die Annahmen zu Wahrscheinlichkeit und Auswirkung mit Fach- und Technikverantwortlichen abgestimmt? Sind bereits umgesetzte Kontrollen von erst geplanten Maßnahmen getrennt? Hat jede Behandlung einen Eigentümer, einen Termin und einen konkreten Wirksamkeitstest? Diese Fragen sind der einfachste Qualitätstest für eine Analyse, die später noch verwendbar sein soll.
Prüfen Sie auch die Schnittstellen. Eine technische Sicherheitsbewertung beantwortet nicht, ob eine Verarbeitung eine tragfähige Rechtsgrundlage besitzt; eine DSFA bewertet Risiken für Menschen, die in einer klassischen Betriebsrisikomatrix zu kurz kommen können. Bei einem ausgelagerten Dienst sollte die Analyse den Vertrag, die tatsächliche Systemarchitektur und den Wiederanlauf abgleichen. Bei der Vorbereitung einer Datenschutzprüfung lässt sich dann zeigen, welche Entscheidung auf welchem Sachverhalt beruhte. Wenn eine wesentliche Information fehlt, markieren Sie die Bewertung als vorläufig und beauftragen die Klärung. Ein leerer Evidenzverweis darf nicht als abgeschlossene Freigabe erscheinen.
Fazit
BSI 200-3 macht die zusätzlichen Risiken eines anspruchsvollen Informationsverbunds bearbeitbar. Wer sie konsequent dokumentiert, hat im Auditgespräch und bei Aufsichtsanfragen das stärkste Argument: “Wir haben das Risiko analysiert, bewertet, behandelt — hier ist die Doku.”
Der Aufwand ist überschaubar, wenn die Analyse fokussiert bleibt: Nicht jedes Zielobjekt braucht eine vertiefte 200-3-Betrachtung; prüfen Sie aber auch Modellierungslücken und besondere Einsatzszenarien. Für diese lohnt sich die Tiefe umso mehr, weil genau dort das Bußgeld- und Schadenspotenzial konzentriert ist. Führen Sie das Risikoregister als lebendes Dokument, verknüpfen Sie es mit den TOMs nach Art. 32 und der DSFA nach Art. 35, und aktualisieren Sie es bei jeder wesentlichen Änderung. So wird aus einer einmaligen Pflichtübung ein dauerhaftes Steuerungsinstrument, das Sicherheit und Datenschutz messbar und verteidigungsfähig macht.
FAQ
Ist BSI 200-3 verpflichtend für jede Risikoanalyse?
Nein. Die Methode betrifft die vertiefte Analyse im IT-Grundschutz, etwa bei hohem Schutzbedarf, Modellierungslücken oder besonderer Einsatzumgebung. Alternativ ISO 27005 oder eigene Methodik.
Wie oft muss 200-3 aktualisiert werden?
Prüfen Sie die Analyse regelmäßig in Ihrem ISMS-Zyklus und anlassbezogen bei wesentlichen Änderungen, neuen Gefährdungen oder Vorfällen. Ein pauschaler Jahresrhythmus ersetzt keine solche Anlassprüfung.
Kann ich Restrisiken einfach akzeptieren?
Nur wenn die festgelegte Risikostrategie und alle bindenden Pflichten dies zulassen. Benennen Sie den Entscheidungsträger, begründen Sie die Abwägung und terminieren Sie eine erneute Prüfung.
Reicht 200-3 für eine ISO-27001-Zertifizierung?
200-3 ist ein Baustein der Methode. Eine Zertifizierung verlangt den definierten Geltungsbereich, die übrigen Anforderungen und eine unabhängige Prüfung; die Risikoanalyse allein reicht nicht.