Die 35 Mindestkriterien für die Risikobetrachtung im Grundschutz++, einzeln erklärt

KERNTHESE Grundschutz++ sagt es ausdrücklich: Organisationen dürfen ihre Risikobetrachtung mit einem Verfahren eigener Wahl durchführen. Der Preis dieser Freiheit ist Anhang 3 des BSI-Standards 300-1, eine Liste von 35 verbindlichen Mindestkriterien, die jedes Verfahren vergleichbar und prüfbar machen. Zusammen gelesen sagen die Kriterien dreierlei. Die Leitung entscheidet über den Rahmen und trägt, was übrig bleibt. Jedes Risiko hat einen Eigentümer. Und jeder Schritt hinterlässt einen Nachweis, den jemand anderes prüfen kann.

Der BSI-Standard 300-1, die Methodik des Grundschutz++, wurde am 26. Oktober 2026 veröffentlicht.¹ Für Geschäftsprozesse mit normalem Schutzbedarf hat das BSI eine allgemeine Risikobetrachtung bereits in seinen Anforderungskatalog eingebaut. Eine eigene explizite Risikobetrachtung wird nötig, wenn ein Geschäftsprozess bei mindestens einem Schutzziel hohen Schutzbedarf hat, wenn ein relevantes Asset durch die Zielobjektkategorien nicht hinreichend abgedeckt ist oder wenn eine anwendbare SOLLTE-Anforderung dauerhaft nicht erfüllt wird.² Eine nur vorübergehend nicht erfüllte SOLLTE-Anforderung mit geplanter Erfüllung löst keine vollständige explizite Risikobetrachtung aus; ihr Restrisiko ist aber dennoch zu betrachten und durch die Institutionsleitung freizugeben.² In jedem dieser Fälle muss das gewählte Verfahren die 35 Kriterien aus Anhang 3 erfüllen. Der Standard nennt ISO/IEC 27005 und ISO 31000 als mögliche Grundlagen und hält fest, dass die Kriterien dafür sorgen, dass das gewählte Verfahren etwa im Rahmen einer Zertifizierung vergleichbar und überprüfbar ist.²

Dieser Beitrag geht alle 35 Kriterien durch. Zu jedem sagt er in einfachen Worten, was verlangt ist, und gibt ein konkretes Beispiel. Die Kriterien selbst stammen aus dem Standard; die Erläuterungen und alle Beispiele sind meine eigene Veranschaulichung, kein BSI-Text.

Das durchgehende Beispiel

Damit die Beispiele konkret bleiben, folgen sie alle einer fiktiven Organisation. Die Stadt Musterstadt betreibt ein Bürgerportal, über das Einwohnerinnen und Einwohner Anträge online stellen: Wohnsitzanmeldung, Bewohnerparkausweis, Kitaplatz. Die Anträge enthalten Namen, Anschriften, Einkommensangaben und Kopien von Ausweisdokumenten. Die Stadt hat den Prozess bei Vertraulichkeit und Integrität mit hoch bewertet, daher greift Kriterium 32, und eine Risikobetrachtung ist erforderlich.

Der Prozess läuft über einen Ressourcenpfad, der immer wieder auftaucht: die Webanwendung des Portals, ein Fachverfahren für die Sachbearbeitung, ein Datenbankserver, der Serverraum im Rathaus und ein externer Hosting-Dienstleister für die öffentliche Oberfläche.

Der Standard weist darauf hin, dass die Nummerierung nur der Referenz dient und keinen Ablauf beschreibt und dass einzelne Kriterien phasenübergreifend wirken.² Die Reihenfolge unten folgt den Phasen, in die der Standard sie gliedert.

Phase 1: Initiierung und Vorbereitung (Kriterien 1–10)

Bevor ein einziges Risiko notiert wird, muss der Rahmen stehen. Diese zehn Kriterien entscheiden, ob zwei Personen, die dasselbe Risiko bewerten, zu einem vergleichbaren Ergebnis kommen.

Kriterium 1 — Ein einheitliches Verfahren für Risikoidentifikation und Risikobewertung

Einfach gesagt: Die Organisation legt ein Verfahren fest, mit dem Risiken gefunden und bewertet werden, und nutzt es überall, nicht eine Methode in der IT und eine andere im Gebäudemanagement.

Beispiel: Musterstadt führt für alle Fachbereiche ein szenariobasiertes Verfahren angelehnt an ISO/IEC 27005 ein. Die IT hatte bisher eine eigene Tabelle mit einer Skala von 1 bis 10; sie wird abgelöst, damit das Bürgerportal und die Lohnabrechnung gleich bewertet werden.

Was ein Auditor sehen will: Das Verfahrensdokument und Register aus zwei verschiedenen Fachbereichen, die dieselben Skalen verwenden.

Kriterium 2 — Ein einheitliches Verfahren für die Risikobehandlung

Einfach gesagt: Sind Risiken bewertet, gibt es einen festen Weg, wie über sie entschieden wird.

Beispiel: Jedes Risiko oberhalb der Akzeptanzschwelle durchläuft dieselben drei Schritte: Behandlungsoption wählen, Maßnahmen festlegen, Ergebnis dem Risikoeigentümer vorlegen. Kein Fachbereich kann ein Risiko außerhalb dieses Wegs einfach für „in Ordnung“ erklären.

Was ein Auditor sehen will: Den Behandlungsweg im Verfahren und eine Stichprobe behandelter Risiken, die ihn durchlaufen haben.

Kriterium 3 — Das Verfahren für Identifikation und Bewertung ist dokumentiert

Einfach gesagt: Das Verfahren aus Kriterium 1 liegt schriftlich vor, damit es geprüft und wiederholt werden kann.

Beispiel: Ein sechsseitiges Dokument „Verfahren Risikobetrachtung“ beschreibt die Skalen, das Workshop-Format, die Beteiligten und den Ablageort der Ergebnisse. Ein Auditor kann es lesen und dann prüfen, ob das Register ihm folgt.

Was ein Auditor sehen will: Die aktuelle, freigegebene Fassung des Verfahrens für Identifikation und Bewertung mit Versionshistorie.

Kriterium 4 — Das Behandlungsverfahren ist dokumentiert

Einfach gesagt: Dasselbe gilt für den Behandlungsweg aus Kriterium 2.

Beispiel: Das Verfahrensdokument enthält ein Kapitel zur Behandlung: welche Optionen es gibt, wer entscheidet, welche Vorlage für den Behandlungsplan genutzt wird und wie Entscheidungen zur Leitung gelangen.

Was ein Auditor sehen will: Das Kapitel oder Dokument zur Behandlung einschließlich der Vorlage für den Behandlungsplan.

Kriterium 5 — Rollen, Zuständigkeiten und Befugnisse, insbesondere der Risikoeigentümer

Einfach gesagt: Es ist festgelegt, wer im Risikomanagement was tut und wer was entscheiden darf. Die Rolle des Risikoeigentümers wird eigens genannt.

Beispiel: Musterstadt legt vier Rollen fest. Der ISB moderiert und dokumentiert. Die Geschäftsprozesseigentümer sind Risikoeigentümer. Die IT-Leitung bewertet die technische Umsetzbarkeit. Der Bürgermeister autorisiert den Rahmen und die Restrisiken.

Was ein Auditor sehen will: Eine Rollenbeschreibung oder RACI, die den Risikoeigentümer nennt und festhält, was jede Rolle entscheiden darf.

Kriterium 6 — Kriterien für Risikoidentifikation und Risikobewertung

Einfach gesagt: Für beide Schritte stehen die Kriterien vorab fest: welche Szenarien überhaupt ins Register aufgenommen werden (Identifikation) und wie Eintrittshäufigkeit und Schadensauswirkung gemessen und zusammengeführt werden (Bewertung).

Beispiel: Musterstadt legt vier Häufigkeitsklassen für einen Zeitraum von drei Jahren fest (selten, möglich, wahrscheinlich, häufig) und vier Auswirkungsklassen (gering, spürbar, beträchtlich, die Handlungsfähigkeit der Stadt gefährdend), jeweils mit Beschreibungen, etwa für „beträchtlich“: „Daten von mehr als 1.000 Einwohnern offengelegt“. Für die Identifikation legt das Verfahren von Musterstadt fest, dass jedes Szenario, das einen Prozess im Anwendungsbereich betrifft, erfasst wird, wenn es plausibel mindestens eine „spürbare“ Auswirkung erreichen kann; vorhandene Maßnahmen werden dabei mit ihrem Stand festgehalten.

Was ein Auditor sehen will: Die Kriterien für die Aufnahme von Risiken ins Register, die Skalen für Häufigkeit und Auswirkung mit ihren Definitionen und die Regel, die beide zusammenführt.

Kriterium 7 — Risikoappetit

Einfach gesagt: Die Organisation legt fest, wie viel Risiko sie zur Erreichung ihrer Ziele einzugehen bereit ist.

Beispiel: „Für Prozesse mit hohem Schutzbedarf geht Musterstadt im Regelfall keine hohen Informationssicherheitsrisiken ein; einziger Ausweg ist eine begründete, festgehaltene Ausnahme der Leitung nach Kriterium 27. Mittlere Risiken werden vorübergehend toleriert, wenn ein Behandlungsplan mit Termin vorliegt.“

Was ein Auditor sehen will: Eine schriftliche, von der Leitung freigegebene Aussage zum Risikoappetit.

Kriterium 8 — Risikoakzeptanzkriterien, abgeleitet aus dem Appetit

Einfach gesagt: Der Appetit wird in konkrete Regeln übersetzt, welches Risikoniveau akzeptabel ist. Der Standard verlangt nur, dass diese Kriterien den Appetit berücksichtigen; auch festzulegen, von wem und wie lange akzeptiert werden darf, ist gute Praxis.

Beispiel: Geringe Risiken kann der Risikoeigentümer zur Akzeptanz vorschlagen; wie alle Restrisiken werden sie anschließend gemeinsam mit den übrigen durch den Bürgermeister autorisiert (Kriterium 30). Mittlere Risiken darf der Bürgermeister höchstens zwölf Monate mit Behandlungsplan akzeptieren. Hohe und sehr hohe Risiken dürfen bei Prozessen mit hohem Schutzbedarf nicht akzeptiert werden; sie müssen behandelt werden, es sei denn, die Leitung autorisiert eine begründete Ausnahme (Kriterium 27).

Was ein Auditor sehen will: Akzeptanzkriterien, die sich auf den Appetit beziehen und festlegen, welches Niveau akzeptabel ist, idealerweise auch von wem und wie lange.

Kriterium 9 — Die Leitung autorisiert Verfahren, Rollen, Kriterien und Appetit

Einfach gesagt: Der gesamte Rahmen aus den Kriterien 1 bis 8 wird von der Institutionsleitung freigegeben, nicht vom Sicherheitsteam allein.

Beispiel: Der Bürgermeister genehmigt Verfahrensdokument, Rollenmodell, Skalen, Akzeptanzkriterien und Risikoappetit in einer protokollierten Entscheidung. Ohne diese Unterschrift ist der Rahmen nur ein Vorschlag.

Was ein Auditor sehen will: Eine datierte Leitungsentscheidung, etwa ein Protokoll oder ein unterschriebener Vermerk, die Verfahren, Rollen, Kriterien und Appetit freigibt.

Kriterium 10 — Die methodische Grundlage der Identifikation

Einfach gesagt: Die Organisation legt fest, wie sie Risiken findet: über Bedrohungen und Schwachstellen, über Risikoszenarien oder über einen anderen dokumentierten Ansatz.

Beispiel: Musterstadt arbeitet mit Szenarien. Für jeden Prozess fragt der Workshop: „Was könnte diesem Prozess passieren, durch wen oder was, und mit welcher Folge?“ Die 47 elementaren Gefährdungen des Grundschutz++ dienen als Checkliste, damit keine Kategorie vergessen wird.

Was ein Auditor sehen will: Die dokumentierte Wahl der Methode, etwa szenariobasiert oder über Bedrohungen und Schwachstellen, und die verwendete Checkliste.

Phase 2: Risikoidentifikation (Kriterien 11–17)

Diese sieben Kriterien entscheiden, was betrachtet wird, was zu jedem Risiko festgehalten wird und wem es gehört.

Kriterium 11 — Die Untersuchungsobjekte sind dokumentiert

Einfach gesagt: Für jede Risikobetrachtung wird festgehalten, was betrachtet wurde.

Beispiel: Die Betrachtung vom Oktober 2026 umfasst „Geschäftsprozess Bürgerportal (GP-04), mit dem externen Hosting-Dienstleister als gesondert betrachtetem kritischen Asset“. Der Prozess Speiseplan der Kantine gehört ausdrücklich nicht dazu.

Was ein Auditor sehen will: Die Abgrenzung jeder Betrachtung: welche Prozesse und Assets untersucht wurden und welche nicht.

Kriterium 12 — Vorhandene und geplante Maßnahmen werden berücksichtigt

Einfach gesagt: Bei Identifikation und Bewertung gehören umgesetzte und bereits geplante Maßnahmen samt ihrem Umsetzungsstatus mit ins Bild. Das gilt für beide Schritte.

Beispiel: Das Risiko „Übernahme eines Portal-Administratorkontos“ wird in dem Wissen bewertet, dass starke Passwörter und eine Kontosperre umgesetzt sind, während die Mehr-Faktor-Authentisierung für März 2027 geplant, aber noch nicht in Betrieb ist. Beides wird mit Status festgehalten; die geplante Maßnahme ist notiert, zählt in der Bewertung aber noch nicht als Schutz.

Was ein Auditor sehen will: Registereinträge, die vorhandene und geplante Maßnahmen mit ihrem Status zum Zeitpunkt der Bewertung zeigen.

Kriterium 13 — Risiken auf Prozessebene und, wo nötig, bei kritischen Assets

Einfach gesagt: Risiken sollten für den Geschäftsprozess als Ganzes identifiziert werden und zusätzlich für einzelne Assets nur dort, wo die Prozessbetrachtung deren Lage nicht erfasst.

Beispiel: Die meisten Risiken des Bürgerportals werden auf Prozessebene beschrieben, etwa „Anträge werden vor der Entscheidung manipuliert“. Der externe Hosting-Dienstleister wird gesondert als kritisches Asset betrachtet, weil sein Vertrag und sein Standort Fragen aufwerfen, die die Prozessbetrachtung nicht beantwortet.

Was ein Auditor sehen will: Risiken auf Prozessebene und eine Begründung überall dort, wo ein einzelnes Asset gesondert betrachtet wurde.

Kriterium 14 — Jedem Risiko werden die betroffenen Schutzziele zugeordnet

Einfach gesagt: Jedes Risiko nennt mindestens, ob es Vertraulichkeit, Integrität oder Verfügbarkeit betrifft.

Beispiel: „Antragsdaten über einen falsch konfigurierten Speicher offengelegt“ betrifft Vertraulichkeit. „Anträge durch Angreifer verändert“ betrifft Integrität. „Portal zur Antragsfrist nicht erreichbar“ betrifft Verfügbarkeit.

Was ein Auditor sehen will: Ein Feld für Schutzziele in jedem Registereintrag, mindestens mit Vertraulichkeit, Integrität und Verfügbarkeit.

Kriterium 15 — Mindestangaben im Risikoregister

Einfach gesagt: Jedes Risiko im Register hat mindestens eine eindeutige Kennung, das Untersuchungsobjekt, eine Beschreibung, die betroffenen Schutzziele, das Risikoniveau und den Risikoeigentümer. Bei zu behandelnden Risiken kommen Priorität, Behandlungsoption und ein Verweis auf die zugeordneten Maßnahmen hinzu.

Beispiel: R-007, „Übernahme eines Portal-Administratorkontos durch Phishing; Antragsdaten werden gelesen oder verändert“, Objekt GP-04 administrativer Zugang, Schutzziele Vertraulichkeit und Integrität, Niveau hoch (wahrscheinlich × beträchtlich), Eigentümer Leitung Bürgerbüro; als zu behandelndes Risiko zusätzlich Priorität 1, Option Reduktion, Maßnahmen M-031 bis M-033 (Abbildung 4).

Was ein Auditor sehen will: Ein Register, in dem jeder Eintrag alle sechs Mindestangaben hat und zu behandelnde Risiken zusätzlich Priorität, Option und Maßnahmen.

Kriterium 16 — Jedes Risiko hat einen Risikoeigentümer

Einfach gesagt: Jedes Risiko wird einem Risikoeigentümer zugeordnet. Ist nichts anderes festgelegt, ist das der Geschäftsprozesseigentümer.

Beispiel: Alle Risiken des Bürgerportals gehören der Leitung des Bürgerbüros, der der Prozess gehört. Ein Risiko, das Bürgerportal und Lohnabrechnung zugleich betrifft, erhält einen federführenden Risikoeigentümer aus dem Kreis der beiden Prozessverantwortlichen.²

Was ein Auditor sehen will: Einen benannten Eigentümer für jedes Risiko und, wenn ein Risiko mehrere Prozesse betrifft, einen aus den betroffenen Geschäftsprozesseigentümern gewählten federführenden Eigentümer.

Kriterium 17 — Elementare Gefährdungen bei dauerhaft nicht erfüllten SOLLTE-Anforderungen

Einfach gesagt: Wird eine SOLLTE-Anforderung auf absehbare Zeit nicht erfüllt, sind die ihr im Katalog zugeordneten elementaren Gefährdungen in der Risikobetrachtung zu berücksichtigen.

Beispiel: Angenommen, eine anwendbare SOLLTE-Anforderung zur Mehr-Faktor-Authentisierung für administrative Zugänge lässt sich nicht erfüllen, weil das Fachverfahren sie nicht unterstützt und eine Ablösung nicht vor 2029 absehbar ist. In dieser Veranschaulichung trägt die Anforderung die Kennungen G 0.23 (Unbefugtes Eindringen in IT-Systeme) und G 0.36 (Identitätsdiebstahl). Beide Gefährdungen werden dann für das Bürgerportal ausdrücklich betrachtet, und Ersatzmaßnahmen werden an ihnen gemessen.

Was ein Auditor sehen will: Für jede dauerhaft nicht erfüllte SOLLTE-Anforderung die ihr zugeordneten elementaren Gefährdungen und wie sie bewertet wurden.

Phase 3: Risikobewertung (Kriterien 18–22)

Diese fünf Kriterien machen aus einem identifizierten Risiko ein Niveau, das sich mit den Akzeptanzkriterien vergleichen lässt.

Kriterium 18 — Eintrittshäufigkeit nach festgelegten Kriterien und für einen festgelegten Zeitraum

Einfach gesagt: Wie oft ein Ereignis erwartet wird, wird anhand der festgelegten Klassen und für einen festgelegten Zeitraum eingeschätzt, nicht aus dem Bauch heraus.

Beispiel: „Phishing nach Zugangsdaten von Portal-Administratoren“ wird für drei Jahre als „wahrscheinlich“ eingestuft. Die Stadt hat im letzten Jahr zwei solche Versuche registriert; solange nur Passwörter und eine Kontosperre schützen, geht sie vorsichtig geschätzt davon aus, dass in drei Jahren mindestens ein Versuch zu einer erfolgreichen Kontoübernahme führen kann.

Was ein Auditor sehen will: Häufigkeitseinschätzungen mit den festgelegten Klassen und dem festgelegten Zeitraum, samt Quelle der Einschätzung.

Kriterium 19 — Schadensauswirkung nach festgelegten Kriterien, mit Begründung

Einfach gesagt: Die Schadenshöhe wird mit den festgelegten Klassen eingeschätzt, und die Einschätzung wird begründet.

Beispiel: „Beträchtlich, weil das Portal Daten von rund 18.000 Einwohnern einschließlich Ausweisdokumenten speichert und eine Offenlegung Meldepflichten und nachhaltigen Vertrauensverlust auslösen würde.“

Was ein Auditor sehen will: Auswirkungseinschätzungen mit den festgelegten Klassen, jeweils mit kurzer schriftlicher Begründung.

Kriterium 20 — Das Risikoniveau verbindet Häufigkeit und Auswirkung

Einfach gesagt: Das Risikoniveau ergibt sich aus beiden Werten zusammen nach der festgelegten Regel.

Beispiel: In der Matrix von Musterstadt ergeben „wahrscheinlich“ und „beträchtlich“ das Niveau „hoch“.

Was ein Auditor sehen will: Risikoniveaus, die sich mit der dokumentierten Regel aus Häufigkeit und Auswirkung nachvollziehen lassen.

Kriterium 21 — Zu behandelnde Risiken werden priorisiert

Einfach gesagt: Die Organisation legt fest, in welcher Reihenfolge Risiken behandelt werden.

Beispiel: Risiken werden zuerst nach Niveau behandelt, bei gleichem Niveau nach der Zahl der betroffenen Einwohner. Das Risiko der Administratorübernahme hat Priorität 1.

Was ein Auditor sehen will: Eine dokumentierte Priorisierungsregel und die daraus folgende Reihenfolge der zu behandelnden Risiken.

Kriterium 22 — Jedes Risiko wird mit den Akzeptanzkriterien abgeglichen

Einfach gesagt: Jedes bewertete Risiko wird mit den Akzeptanzkriterien abgeglichen.

Beispiel: Das Risiko der Administratorübernahme ist „hoch“ bei einem Prozess mit hohem Schutzbedarf und damit nach Kriterium 8 nicht akzeptabel. Das Risiko „FAQ-Seite des Portals einige Stunden nicht erreichbar“ ist „gering“ und akzeptabel.

Was ein Auditor sehen will: Für jedes bewertete Risiko ein festgehaltenes Ergebnis des Abgleichs mit den Akzeptanzkriterien.

Phase 4: Risikobehandlung (Kriterien 23–31)

Diese neun Kriterien regeln, was mit einem Risiko nach der Bewertung geschieht und wer das Verbleibende autorisiert.

Kriterium 23 — Eine Behandlungsoption für jedes zu behandelnde Risiko

Einfach gesagt: Jedes zu behandelnde Risiko erhält eine von vier Optionen: Reduktion, Vermeidung, Transfer oder Akzeptanz.

Beispiel: Das Risiko der Administratorübernahme wird reduziert. Das Risiko, dass Einwohner Anträge als unverschlüsselten E-Mail-Anhang schicken, wird vermieden, indem der E-Mail-Kanal abgeschaltet wird. Ein Teil der finanziellen Folgen einer Datenpanne wird über eine Cyberversicherung transferiert. Das geringe Risiko, dass die FAQ-Seite des Portals einige Stunden nicht erreichbar ist, wird akzeptiert.

Was ein Auditor sehen will: Eine festgehaltene Behandlungsoption für jedes zu behandelnde Risiko.

Kriterium 24 — Reduktionsmaßnahmen folgen aus der Bewertung

Einfach gesagt: Maßnahmen werden nachvollziehbar auf Grundlage dessen gewählt, was die Bewertung ergeben hat.

Beispiel: Weil die Bewertung Phishing gegen Administratoren als Ursache benannt hat, zielen die Maßnahmen genau dorthin: ein Hardware-Sicherheitsschlüssel für die drei Administratoren, administrativer Zugang nur aus dem internen Netz und Alarmierung bei fehlgeschlagenen Anmeldungen. Eine allgemeine Sensibilisierungskampagne kann ergänzen; dass sie allein ausreicht, müsste die erneute Bewertung zeigen.

Was ein Auditor sehen will: Maßnahmen, deren Auswahl sich auf die in der Bewertung benannte Ursache oder das Szenario zurückführen lässt.

Kriterium 25 — Die Zuordnung von Risiken und Maßnahmen ist dokumentiert

Einfach gesagt: Es ist erkennbar, welche Maßnahmen zu welchem Risiko gehören, und umgekehrt.

Beispiel: Risiko R-007 verweist im Umsetzungsplan auf die Maßnahmen M-031, M-032 und M-033, und jede dieser Maßnahmen verweist auf R-007 zurück.

Was ein Auditor sehen will: Eine nachvollziehbare Zuordnung von Risiken und Maßnahmen, etwa über Verweise in Register und Umsetzungsplan.

Kriterium 26 — Bewertung und Behandlung werden wiederholt, wenn das Risiko noch zu hoch ist

Einfach gesagt: Erfüllt ein Risiko nach der Behandlung die Akzeptanzkriterien noch nicht, wird es erneut bewertet und behandelt.

Beispiel: Sobald M-032 und M-033 im November 2026 wirken, lassen sich erbeutete Zugangsdaten nicht mehr von außerhalb des städtischen Netzes nutzen, und Missbrauchsversuche lösen einen Alarm aus. Musterstadt senkt die Häufigkeit desselben Szenarios deshalb um eine Klasse: R-007 wird als „möglich“ und „beträchtlich“ neu bewertet, das ergibt „mittel“. Mittel ist höchstens zwölf Monate mit Plan akzeptabel, und der Plan ist M-031, die Sicherheitsschlüssel, fällig am 31. März 2027. Die Schleife endet also hier. Wäre das Ergebnis weiter „hoch“ gewesen, wäre eine weitere Runde nötig gewesen.

Was ein Auditor sehen will: Nachweise der erneuten Bewertung für Risiken, die nach einer ersten Runde die Akzeptanzkriterien nicht erfüllten.

Kriterium 27 — Die Leitung autorisiert nicht weiter behandelte Risiken

Einfach gesagt: Erfüllt ein Risiko die Akzeptanzkriterien nicht und soll es dennoch nicht weiter behandelt werden, muss die Institutionsleitung dies als Ausnahme autorisieren. Eine solche Ausnahme ersetzt nicht die Erfüllung einer anwendbaren MUSS-Anforderung.²

Beispiel: Das Fachverfahren lässt sich nicht weiter härten, seine Ablösung ist nicht vor 2029 absehbar. Das verbleibende „hohe“ Risiko wird dem Bürgermeister mit Begründung vorgelegt; er unterschreibt eine Ausnahmegenehmigung. Ohne diese Unterschrift müsste das Risiko weiter behandelt werden.

Was ein Auditor sehen will: Eine nachweisbar von der Leitung autorisierte Ausnahme, etwa ein protokollierter Beschluss oder ein unterschriebener Vermerk, für jedes Risiko über den Akzeptanzkriterien, das nicht weiter behandelt wird.

Kriterium 28 — Temporäre Risikoakzeptanz braucht eine Befristung

Einfach gesagt: Wird ein Risiko nur für eine Zeit akzeptiert, wird der Zeitraum festgelegt.

Beispiel: Das „mittlere“ Restrisiko von R-007 wird bis zum 31. März 2027 akzeptiert, dem Termin, zu dem die Sicherheitsschlüssel (M-031) als Mehr-Faktor-Authentisierung in Betrieb gehen sollen. An diesem Tag endet die Akzeptanz, und das Risiko wird neu bewertet.

Was ein Auditor sehen will: Eine Befristung für jedes temporär akzeptierte Risiko und den Nachweis, dass abgelaufene Akzeptanzen neu bewertet wurden.

Kriterium 29 — Akzeptierte Risiken sind dokumentiert

Einfach gesagt: Jedes akzeptierte Risiko wird dokumentiert. Mehr sagt der Standard nicht; prüfbar wird der Nachweis, wenn festgehalten ist, was von wem und wann akzeptiert wurde.

Beispiel: Das Register zeigt für R-007: „mittel, temporär akzeptiert bis 31.03.2027; Risikoeigentümer: Leitung Bürgerbüro; autorisiert durch den Bürgermeister am 12.11.2026“.

Was ein Auditor sehen will: Eine Liste akzeptierter Risiken, aus der hervorgeht, was von wem und wann akzeptiert wurde.

Kriterium 30 — Die Leitung autorisiert die Restrisiken

Einfach gesagt: Die nach der Behandlung verbleibenden Risiken werden der Institutionsleitung vorgelegt und von ihr autorisiert.

Beispiel: Die Restrisikoübersicht des Bürgerportals, eine Seite mit allen verbleibenden Risiken und ihrem Niveau, ist Teil des Managementberichts und wird vom Bürgermeister unterzeichnet.

Was ein Auditor sehen will: Eine nachweisbare Autorisierung der Restrisiken durch die Leitung, etwa ein protokollierter Beschluss oder der unterschriebene Managementbericht.

Kriterium 31 — Die Risikoeigentümer autorisieren die Umsetzungsplanung

Einfach gesagt: Der Plan für die in der Behandlung beschlossenen Maßnahmen wird von den Risikoeigentümern freigegeben. Die weitere Planung und Steuerung der Maßnahmen erfolgt dann in der Umsetzung.²

Beispiel: Die Leitung des Bürgerbüros gibt den Plan mit den drei Maßnahmen zu R-007, ihren Verantwortlichen und Fristen frei. Die IT setzt den Plan dann um und berichtet den Fortschritt.

Was ein Auditor sehen will: Die Freigabe der Umsetzungsplanung für die beschlossenen Maßnahmen durch den Risikoeigentümer.

Phasenübergreifende Anforderungen (Kriterien 32–35)

Die letzten vier Kriterien gehören zu keiner einzelnen Phase. Drei sagen, wann eine Risikobetrachtung überhaupt stattfinden muss, eines, wie oft sie überprüft wird.

Kriterium 32 — Risikobetrachtung bei hohem Schutzbedarf

Einfach gesagt: Jeder Geschäftsprozess mit hohem Schutzbedarf bei mindestens einem Schutzziel erhält eine Risikobetrachtung.

Beispiel: Das Bürgerportal ist bei Vertraulichkeit und Integrität hoch und wird deshalb betrachtet. Der Speiseplan der Kantine ist bei allen drei Schutzzielen normal und durch die allgemeine Risikobetrachtung des Katalogs abgedeckt.

Was ein Auditor sehen will: Eine Risikobetrachtung für jeden Prozess, der bei mindestens einem Schutzziel hoch bewertet ist.

Kriterium 33 — Nicht hinreichend abgedeckte Assets

Einfach gesagt: Ist ein relevantes Asset durch die bestehenden Zielobjektkategorien und ihre Anforderungen nicht hinreichend abgedeckt, wird für dieses Asset eine Risikobetrachtung durchgeführt.

Beispiel: Die Gebäudeleittechnik der Stadt, die Heizung und Zutrittstüren im Rathaus steuert, lässt sich einer Zielobjektkategorie zuordnen, doch die dieser Kategorie zugeordneten Anforderungen decken ihr konkretes Einsatzszenario nicht hinreichend ab. Die verbleibenden Risiken werden deshalb in einer eigenen Risikobetrachtung untersucht, und das Anforderungspaket wird ergänzt.

Was ein Auditor sehen will: Eine Liste der Assets, die durch Zielobjektkategorien nicht hinreichend abgedeckt sind, jeweils mit eigener Risikobetrachtung.

Kriterium 34 — Dauerhafte Nichterfüllung einer SOLLTE-Anforderung

Einfach gesagt: Jede dauerhaft nicht erfüllte SOLLTE-Anforderung löst eine Risikobetrachtung aus.

Beispiel: Die fehlende Mehr-Faktor-Authentisierung im Fachverfahren aus Kriterium 17 ist eine dauerhafte Nichterfüllung. Sie löst eine Risikobetrachtung aus, und Kriterium 17 sagt, welche Gefährdungen diese abdecken muss.

Was ein Auditor sehen will: Eine Liste der dauerhaft nicht erfüllten SOLLTE-Anforderungen, jeweils mit verknüpfter Risikobetrachtung.

Kriterium 35 — Überprüfung mindestens jährlich und bei wesentlichen Änderungen

Einfach gesagt: Die Risikobetrachtung wird mindestens einmal im Jahr überprüft, außerdem bei geplanten oder eingetretenen wesentlichen Änderungen.

Beispiel: Musterstadt überprüft ihre Risikobetrachtung jeden Oktober. Zusätzlich überprüft sie sie vor dem geplanten Umzug des Portals zu einem neuen Hosting-Dienstleister im Frühjahr 2027 und unmittelbar nach einem schwerwiegenden Sicherheitsvorfall, der die Risikolage verändert.

Was ein Auditor sehen will: Überprüfungstermine mindestens einmal im Jahr und Überprüfungen, die mit geplanten oder eingetretenen wesentlichen Änderungen verknüpft sind.

Worauf Auditoren zuerst schauen dürften

Die 35 Kriterien sind nicht gleich schwer. Nach meiner Erfahrung als Lead Auditor erfüllen Organisationen, die bereits einen Risikoprozess nach ISO/IEC 27001 betreiben, die meisten ohne Änderungen. Vier sind die Stellen, an denen ich Lücken erwarte.

Die erste ist ein schriftlicher Risikoappetit (Kriterien 7 und 8). Viele Organisationen haben Skalen und eine Matrix, aber keine Aussage, wie viel Risiko die Leitung zu tragen bereit ist, und keine Regel, die diese Aussage in Akzeptanzkriterien übersetzt.

Die zweite ist die Befristung temporärer Akzeptanz (Kriterium 28). Risiken werden oft „vorerst“ akzeptiert, was in der Praxis unbefristet heißt.

Die dritte ist der Bezug zu den elementaren Gefährdungen bei dauerhaft nicht erfüllten SOLLTE-Anforderungen (Kriterium 17). Gefährdungsbezogene Kreuzreferenzen zu nicht erfüllten Anforderungen gab es bereits im IT-Grundschutz; neu ist, dass Anhang 3 diese Verknüpfung als ausdrückliches Mindestkriterium verankert. In einem ISO-orientierten Verfahren lohnt die Prüfung, ob sie bereits enthalten ist.

Die vierte ist der Unterschied zwischen den beiden Autorisierungen am Ende (Kriterien 30 und 31). Die Leitung autorisiert, was übrig bleibt; der Risikoeigentümer autorisiert den Plan. Das sind zwei Entscheidungen über zwei verschiedene Dinge, und beide müssen nachvollziehbar sein. In vielen Registern ist nur eine davon festgehalten, oder keine.

Lessons Learned

Die folgenden Lehren sind meine eigene Lesart, keine Aussagen des BSI.

Erstens: Nutzen Sie die 35 Kriterien als Checkliste für Ihr bestehendes Verfahren, nicht als neues Verfahren. Wer bereits nach ISO/IEC 27005 oder ISO 31000 arbeitet, ordnet jedem Kriterium die Stelle zu, an der das eigene Verfahren es schon erfüllt, und schließt nur die Lücken.

Zweitens: Halten Sie schriftlich fest, was die Leitung entscheidet. Die Kriterien 9, 27 und 30 verlangen eine Autorisierung durch die Institutionsleitung. Ein Risikoprozess, den das Sicherheitsteam gut führt, der aber nie freigegeben wird, erfüllt sie nicht.

Drittens: Halten Sie das Register schlank, aber vollständig. Kriterium 15 verlangt nicht viele Felder, aber alle sechs für jedes Risiko und drei weitere für jedes zu behandelnde.

Viertens: Tragen Sie die Überprüfung in den Kalender ein. Kriterium 35 ist am leichtesten zu erfüllen und am leichtesten zu vergessen.

Glossar

Begriff	Bedeutung
Risikoappetit	Das Maß an Risiko, das eine Organisation zur Erreichung ihrer Ziele einzugehen bereit ist
Risikoakzeptanzkriterien	Aus dem Appetit abgeleitete Regeln, welches Risikoniveau akzeptabel ist
Risikoeigentümer	Die für ein Risiko verantwortliche Person, Rolle oder Organisationseinheit; im Grundschutz++ standardmäßig der Geschäftsprozesseigentümer
Risikoregister	Verzeichnis aller identifizierten Risiken mit den Mindestangaben aus Kriterium 15
Behandlungsoption	Reduktion, Vermeidung, Transfer oder Akzeptanz eines Risikos
Restrisiko	Das nach der Behandlung verbleibende Risiko
Ausnahmegenehmigung	Autorisierung eines Risikos durch die Leitung, das die Akzeptanzkriterien nicht erfüllt und nicht weiter behandelt wird
Elementare Gefährdungen	Die 47 Gefährdungen G 0.1 bis G 0.47, aus denen das BSI die Anforderungen des Grundschutz++ ableitet; eine G-0-Kennung benennt eine Gefährdung, keine fehlende Maßnahme und kein Risikoniveau
SOLLTE-Anforderung	Eine Anforderung, die erfüllt werden sollte; ihre dauerhafte Nichterfüllung löst eine Risikobetrachtung aus

Rechtlicher Hinweis: Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung dar. Er beschreibt Anhang 3 des BSI-Standards 300-1 in Version 1.0. Die Stadt Musterstadt und alle Beispiele sind fiktive Veranschaulichungen, keine Inhalte des BSI. Stand: Oktober 2026.

1. BSI, Pressemitteilung „Methodik zum Grundschutz++ als BSI-Standard 300-1 veröffentlicht“, 26.10.2026, https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/2026/BSI-Standard_300-1_261026.html (abgerufen am 28.10.2026). ↩

2. BSI, „BSI-Standard 300-1 – Methodik Grundschutz++“, Version 1.0, 20.10.2026: Kapitel 2.11 (Initiierung der Risikobetrachtung, Auslöser, freie Wahl des Verfahrens unter Einhaltung von Anhang 3, Restrisiko), Kapitel 4.2 (Risikoidentifikation, -bewertung und -behandlung, federführender Risikoeigentümer bei mehreren Geschäftsprozessen) und Anhang 3 (Mindestkriterien 1 bis 35 mit Hinweisen zu Nummerierung und Überschneidungen), https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_300-1.pdf?__blob=publicationFile&v=3 (abgerufen am 28.10.2026). ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷