Zum Inhalt springen
Grundschutz++ Docs

Suche wird geladen …

DEEN
Phase nach der Veröffentlichung von BSI-Standard 300-1 (bis 12/2026).Zum Zeitplan

Methodik: So wendest du Grundschutz++ an

Das ist eine Lesehilfe, keine Auskunft und keine Rechtsberatung. Maßgeblich ist der BSI-Standard 300-1 selbst. Das Projekt ist unabhängig und nicht mit dem BSI verbunden. Kapitelangaben wie „(3.4)“ beziehen sich auf den Standard.

Quelle ist der BSI-Standard 300-1, © Bundesamt für Sicherheit in der Informationstechnik 2026. Zusammenfassungen sind sinngemäß und nennen das Kapitel, wörtliche Zitate stehen in Anführungszeichen. Das PDF wird hier nicht angeboten, sondern verlinkt. Es gelten die Nutzungsbedingungen des BSI.

Der Katalog sagt, was eine Institution umsetzen soll. Die Methodik sagt, wie man dorthin kommt: in welcher Reihenfolge, mit welchen Entscheidungen und wann man tiefer hinschauen muss. Das BSI hat sie als BSI-Standard 300-1 „Methodik Grundschutz++“ veröffentlicht, Pressemitteilung vom 26.10.2026. Das PDF trägt Version 1.0, die Änderungshistorie nennt als Datum den 20.10.2026.

Version 1.0 richtet sich laut Standard in erster Linie an Early Adopters, also erfahrene Institutionen, die früh einsteigen wollen. Ihre Erfahrungen sollen in die Weiterentwicklung einfließen (1). Ein nach Grundschutz++ aufgebautes ISMS soll ab 2027 zertifizierbar sein.

Die fünf Schritte

Abschnitt betitelt „Die fünf Schritte“

Die Methodik beschreibt einen PDCA-Zyklus (Plan, Do, Check, Act) mit fünf Prozessschritten. Jeder Schritt wird selbst iterativ durchlaufen (1). Die Abbildung 1 des Standards ordnet zu: Plan sind die Schritte 1 und 2, Do ist Schritt 3, Check ist Schritt 4 und Act ist Schritt 5.

PDCA1 · PLANErhebungund Planung2 · PLANAnforderungs-analyse3 · DORealisierung4 · CHECKÜberwachung5 · ACTKontinuierlicheVerbesserung
  1. 1PlanErhebung und Planung
  2. 2PlanAnforderungsanalyse
  3. 3DoRealisierung
  4. 4CheckÜberwachung
  5. 5ActKontinuierliche Verbesserung
  6. weiter bei Schritt 1
  • 1 Erhebung und Planung (Kapitel 2 des Standards, ISO/IEC 27001 Kapitel 4 und 5): GC Governance und Compliance
  • 2 Anforderungsanalyse (Kapitel 3, ISO/IEC 27001 Kapitel 6 und 10): STM Strukturmodellierung
  • 3 Realisierung (Kapitel 4): UMS Umsetzung, RISK Risikomanagement
  • 4 Überwachung (Kapitel 5): PERF Monitoring-Evaluation
  • 5 Kontinuierliche Verbesserung (Kapitel 6): VRB Verbesserung

Die ISO-Kapitel nennt der Standard nur für Schritt 1 und 2 ausdrücklich. Die Praktik hinter dem Doppelpunkt ist meine Zuordnung nach Thema und Titel, keine Angabe des BSI. Nur die Einteilung der Praktiken in drei Gruppen stammt vom Standard (Abbildung 2): Methodik (GC, STM, UMS, VRB, PERF, RISK), technisch (ARCH, BER, DET, REA, KONF, DEV) und organisatorisch (ASST, PERS, BES, DLS, TEST, GEB, SENS, NOT).

Schritt 1: Erhebung und Planung

Abschnitt betitelt „Schritt 1: Erhebung und Planung“

Die Institutionsleitung legt fest, was das ISMS abdeckt und was nicht (2). Das entscheidet sie selbst: Die Verantwortung für das ISMS liegt bei der Leitung und kann nicht delegiert werden (2.10). Der Standard nennt dafür diese Teilschritte, dahinter die Anforderungen im Katalog, die dazu passen:

Schutzbedarf: nur zwei Stufen

Abschnitt betitelt „Schutzbedarf: nur zwei Stufen“

Jeder Geschäftsprozess bekommt für Vertraulichkeit, Integrität und Verfügbarkeit einen Schutzbedarf. Es gibt zwei Kategorien (2.6):

  • normal: Die Auswirkungen sind begrenzt und überschaubar.
  • hoch: Die Auswirkungen können beträchtlich sein.

Eigene zusätzliche Kategorien sind erlaubt, müssen aber auf diese beiden abgebildet werden. Für ein zertifizierbares ISMS muss in der niedrigsten Kategorie immer der Stand der Technik eingehalten werden.

Wer zum ersten Mal ein ISMS aufbaut, soll laut Standard mit dem wichtigsten Geschäftsprozess der höchsten Kategorie beginnen und danach nach und nach alle weiteren untersuchen.

Der Schutzbedarf entscheidet, ob eine Risikobetrachtung nötig ist: Bei normalem Schutzbedarf muss man keine eigene durchführen, weil dem Katalog schon eine allgemeine Risikobetrachtung des BSI zugrunde liegt (2.11). Bei hohem Schutzbedarf ist eine erforderlich. Dazu unten mehr.

Schritt 2: Anforderungsanalyse

Abschnitt betitelt „Schritt 2: Anforderungsanalyse“

Hier entsteht aus dem Katalog ein individuelles Anforderungspaket für den Informationsverbund (3.4). Der Weg dorthin:

  1. Informationsverbund abgrenzen (3.1), STM.1.1 und STM.1.2. Der Anwendungsbereich legt den formalen Umfang des ISMS fest, der Informationsverbund bildet ihn inhaltlich-technisch ab.
  2. Assets erfassen (3.2), STM.2.1.2. Bei hohem Schutzbedarf müssen Zugehörigkeit und Abhängigkeiten der Assets zum Geschäftsprozess dokumentiert werden, bei normalem mindestens die Abhängigkeiten zwischen Anwendungen, IT-Systemen und Räumen. Die Abbildungen 3 und 4 zeigen die Ketten: bei hohem Schutzbedarf Geschäftsprozess, Anwendung, IT-System, Netz oder Netzkomponente, Raum. Bei normalem Schutzbedarf sind es Anwendung zu IT-System und IT-System zu Raum.
  3. Assets Zielobjektkategorien zuordnen (3.4.2), STM.2.1.3. Zielobjektkategorien sind standardisierte Klassen wie „Webserver“, „Cloud-Dienste“ oder „Serverräume“. Anhang 1 des Standards definiert 39 davon, das BSI stellt sie auch als CSV-Datei bereit. Sie stehen in einer Hierarchie aus sieben Wurzelknoten und vier Ebenen (Abbildung 6): Ein Asset bekommt auch die Kategorien über seiner eigenen (STM.2.1.4.1).
  4. Blaupausen prüfen (3.3). Eine Blaupause ist ein vorgefertigter Anforderungskatalog für ein bestimmtes Anwendungsszenario, mit vorgegebenen Parametern. Für manche Institutionen kann es verpflichtende Blaupausen geben.
  5. Anforderungen ergänzen (3.4.3), wenn ein Asset durch den Katalog nicht abgedeckt ist oder sich Pflichten aus Compliance oder Stakeholder-Analyse ergeben: STM.2.1.6 und STM.2.1.7.
  6. Parameter festlegen (3.5), STM.5.1. Parameter sind variable Stellen in einer Anforderung, etwa „regelmäßig“. Die Institution konkretisiert sie.

Das Paket besteht aus drei Arten von Anforderungen (3.4):

  • Methodik-Anforderungen gelten für jeden Informationsverbund und sind verpflichtend. Sie stehen in den Methodik-Praktiken (GC, STM, UMS, VRB, PERF, RISK) und bilden die ISO-27001-Kapitel 4 bis 10 ab. „Ein individuelles Vorgehen ist nicht vorgesehen“ (3.4.1). Im Katalog sind das 99 Anforderungen.
  • Anforderungen ohne Zielobjektkategorie aus den technischen und organisatorischen Praktiken sind ebenfalls verpflichtend (STM.2.1.5). Im Katalog sind das 265.
  • Anforderungen mit Zielobjektkategorie gelten, soweit man Assets dieser Kategorie hat (STM.2.1.4). Im Katalog tragen 636 Anforderungen die Kategorie als Feld target_object_categories. Zusammen mit den beiden anderen Gruppen ergibt das die 1.000 Anforderungen.

Eine Anforderung, die mehrere Assets derselben Kategorie betrifft, kommt nur einmal ins Paket (STM.2.1.4.2).

Was für eine Kategorie gilt, direkt und von den übergeordneten Kategorien geerbt, steht je Kategorie auf Anforderungen nach Zielobjektkategorie.

Die Zielobjektkategorien sind im Katalog je Anforderung hinterlegt (Feld target_object_categories, alle 39 Kategorien kommen vor und stimmen mit der CSV-Datei des BSI überein). Diese Seite zeigt sie an jeder Anforderung als „Gilt für“ an, und die Suche kann danach filtern.

MUSS, SOLLTE, KANN und die zwei Sicherheitsniveaus

Abschnitt betitelt „MUSS, SOLLTE, KANN und die zwei Sicherheitsniveaus“

Jede Anforderung trägt ein Modalverb und ein Sicherheitsniveau. Im Katalog (Stand 22.10.2026, 1.000 Anforderungen) ist die Verteilung so:

Modalverb Anzahl Niveau
MUSS 149 normal-SdT
SOLLTE 624 normal-SdT
SOLLTE 3 erhöht
KANN 224 erhöht

Der Standard sagt zu den Niveaus (3.4.2): Anforderungen mit dem Niveau erhöht enthalten das Modalverb KANN und sind optional. Man kann sie nutzen, um bei einem erhöhten Risiko weitere Maßnahmen zu finden.

Die drei SOLLTE-Anforderungen der Stufe erhöht sind BES.1.4, DET.4.12.1 und REA.2.5. Das passt nicht ganz zum Satz des Standards. Wer das Niveau als Filter nutzt, sollte sie im Blick haben.

Schritt 3: Realisierung

Abschnitt betitelt „Schritt 3: Realisierung“

Umsetzungsstatus ermitteln

Abschnitt betitelt „Umsetzungsstatus ermitteln“

Für jede Anforderung im Paket ist der Status zu prüfen (UMS.1.1). Der Standard kennt drei Werte (4.1.1): „erfüllt“, „nicht erfüllt“ und „nicht anwendbar“. Für „nicht anwendbar“ ist eine Begründung zu dokumentieren, etwa wenn die zugrunde liegende Komponente im Informationsverbund nicht existiert.

Der Katalog formuliert das knapper: Der Status sei grundsätzlich „umgesetzt“ („ja“) oder „nicht umgesetzt“ („nein“), und eine Anforderung gelte nur dann als umgesetzt, wenn auch alle abhängigen Anforderungen umgesetzt sind. Von „nicht anwendbar“ steht dort nichts. In der Praxis lohnt es sich, beide Texte zusammen zu lesen.

Zum Führen des Status gibt es hier eine Tabelle zum Ausfüllen: Export für Excel. Das ist ein Werkzeug dieser Seite und kein Bestandteil des Standards.

Was passiert bei Nichterfüllung

Abschnitt betitelt „Was passiert bei Nichterfüllung“

Ist eine Anforderung noch nicht erfüllt, aber schon in der Umsetzungsplanung, muss das noch nicht abgedeckte Risiko ermittelt und der Institutionsleitung mitgeteilt werden. Die Leitung muss es tragen (4.1.1). Alles Weitere hängt vom Modalverb ab (4.1.2):

  • KANN: optional, muss nicht berücksichtigt werden.
  • SOLLTE, vorübergehend nicht erfüllt: Die Erfüllung ist für später vorgesehen. Es genügt eine stichhaltige Begründung. Eine Risikobetrachtung wird dadurch nicht ausgelöst.
  • SOLLTE, dauerhaft nicht erfüllt: Gemeint ist „auf absehbare Zeit oder endgültig“. Dann ist eine Risikobetrachtung Pflicht. Das Restrisiko legt man der Leitung zur Freigabe vor.
  • MUSS: verpflichtend. Eine Risikobetrachtung kann die Erfüllung nicht ersetzen. Eine Ausnahmegenehmigung oder Risikoakzeptanz ist laut Standard nicht möglich.

Der Standard warnt: Häufen sich dauerhafte Nichterfüllungen von SOLLTE-Anforderungen, kann der Stand der Technik insgesamt als nicht erreicht gelten, bei einer Zertifizierung also eine erhebliche Abweichung festgestellt werden.

Im Katalog heißt UMS.5.1 „Autorisierung von Ausnahmen“. Gemeint sind dort Ausnahmegenehmigungen bei Zielkonflikten zwischen Verpflichtungen. Beide Aussagen gelten nebeneinander.

Umsetzung planen

Abschnitt betitelt „Umsetzung planen“

Aus dem Anforderungspaket entsteht ein Umsetzungsplan (UMS.2.1, UMS.2.2) (4.3). Für jede Maßnahme sind mindestens festzuhalten: die zugehörige Anforderung, das Datum der Umsetzung oder Überprüfung und die dokumentierende oder prüfende Person. Wird automatisiert geprüft, gehören Tool, Zeitpunkt und Ergebnis dazu.

Dazu kommen Zuständige und Fristen (UMS.3.1, UMS.4.1) (4.4) und die Fortschrittsverfolgung (UMS.6.1, UMS.6.2) (4.5). Der Standard empfiehlt, zuerst die Anforderungen der Elternknoten in der Zielobjektkategorie-Hierarchie umzusetzen, denn die haben meist konzeptionellen Charakter („Verfahren verankern“).

Welche Dokumenttypen der Katalog nennt, in denen die Ergebnisse festzuhalten sind, steht unter Dokumente im Katalog.

Wann eine Risikobetrachtung Pflicht ist

Abschnitt betitelt „Wann eine Risikobetrachtung Pflicht ist“

Der Katalog enthält bereits eine allgemeine Risikobetrachtung auf Basis einer angenommenen typischen Gefährdungslage. Die zugrunde liegenden Gefährdungen stehen als Metadaten an den Anforderungen. Im Katalog tragen 901 von 1.000 Anforderungen solche Angaben, insgesamt 47 verschiedene elementare Gefährdungen (Anhang 4). Bei normalem Schutzbedarf braucht man nur diese.

Eine explizite Risikobetrachtung ist laut Standard in diesen Fällen nötig (2.11):

  1. Ein Geschäftsprozess hat bei mindestens einem Schutzziel hohen Schutzbedarf (GC.7.2).
  2. Ein relevantes Asset wird durch die Zielobjektkategorien und deren Anforderungen nicht hinreichend abgedeckt.
  3. Eine anwendbare SOLLTE-Anforderung wird dauerhaft nicht erfüllt.

Der Katalog nennt in STM.4.1 als weiteren Anlass die Herabstufung des Sicherheitsniveaus von erhöht auf normal-SdT. Diesen Fall führt die Aufzählung im Standard nicht auf.

Für Restrisiken bei SOLLTE-Anforderungen, die in der Umsetzungsplanung stehen, aber noch nicht erfüllt sind, ist eine Restrisikobetrachtung nötig, und die Leitung muss das Risiko freigeben (UMS.1.2).

Das Verfahren ist frei, die Mindestkriterien nicht

Abschnitt betitelt „Das Verfahren ist frei, die Mindestkriterien nicht“

Wie man Risiken identifiziert, bewertet und behandelt, darf man selbst wählen, zum Beispiel nach ISO/IEC 27005 oder ISO 31000 (2.11). Verbindlich sind die 35 Mindestkriterien in Anhang 3, damit das Ergebnis vergleichbar und prüfbar bleibt, etwa in einer Zertifizierung. Einige davon:

  • ein einheitliches, dokumentiertes Verfahren für Identifikation, Bewertung und Behandlung (Kriterien 1 bis 4)
  • ein festgelegter Risikoappetit und Risikoakzeptanzkriterien (7, 8)
  • ein Risikoeigentümer für jedes Risiko, standardmäßig der Geschäftsprozesseigentümer (RISK.1.3) (5, 16)
  • ein Risikoregister mit festen Mindestangaben (15)
  • Autorisierung der Verfahren, Kriterien und Restrisiken durch die Institutionsleitung (RISK.1.5) (9, 30)
  • Überprüfung mindestens jährlich und bei wesentlichen Änderungen (35)

Schritt 4 und 5: Überwachen und verbessern

Abschnitt betitelt „Schritt 4 und 5: Überwachen und verbessern“

Der Standard fordert (5):

  • Leistungsbewertung des ISMS (5.1). Einheitliche Vorgaben dazu stehen laut Standard noch aus, die Institutionen sind bis dahin frei. Im Zeitplan nennt das BSI den 26.02.2027 für das Konzept zur Leistungsmessung.
  • ein internes Auditprogramm (5.2), das vor allem Verbesserungspotenziale aufzeigen soll
  • Managementbewertungen durch die Institutionsleitung (5.3)
  • Monitoring mit Verfahren für Sicherheitsvorfälle, Schwachstellen und neue Bedrohungen (5.4)
  • Validierung der Anforderungen, etwa bei Änderungen am Informationsverbund oder am Katalog (5.5)

Die kontinuierliche Verbesserung (6) schließt den Kreis: Nicht-Konformitäten analysieren, Verbesserungspotenziale bewerten, Korrektur- und Verbesserungsplan in den Umsetzungsplan aufnehmen, Wirksamkeit prüfen.

Was ich nicht geprüft habe

Abschnitt betitelt „Was ich nicht geprüft habe“
  • Was Blaupausen konkret sind, sagt der Standard nur allgemein. Das BSI-Repository enthält neben dem Anwenderkatalog Kataloge zu WLAN (48 Anforderungen) und Lieferkettensicherheit (146). Sie passen zur Beschreibung im Standard (zugeschnitten auf ein Anwendungsszenario), das BSI nennt sie dort aber nicht Blaupausen. Ob es Blaupausen im Sinne des Standards schon gibt, habe ich nicht geklärt.
  • Für Pflichten aus dem Gesetz ist diese Seite die falsche Quelle. Dazu siehe Für Geschäftsführung.

Quellen

Abschnitt betitelt „Quellen“