Grundschutz++ und BSI-Standard 300-1: Methodik, Anwenderkatalog und der Weg zur Zertifizierung

Drei Bestandteile, ein Regelwerk

Das BSI stellt den Grundschutz++ für die Einführung eines Informationssicherheitsmanagementsystems bereit. Die Methodik beschreibt der BSI-Standard 300-1; nach Darstellung des BSI lässt sie Anwenderinnen und Anwendern Gestaltungsspielraum, etwa für die Größe der Institution und die Komplexität des Informationsverbunds. Der Anwenderkatalog ergänzt die Methodik: Das BSI hat ihre normativen Aspekte in Anforderungen überführt, sodass der Katalog alle Grundschutz++-Anforderungen umfasst – die der Methodik ebenso wie die technischen und organisatorischen. Bereitgestellt wird er in der Stand-der-Technik-Bibliothek, der technischen Plattform, auf der das BSI Anforderungen und Maßnahmen zentral und maschinenlesbar veröffentlicht. Weil die Anforderungen maschinenlesbar vorliegen, wird ihre Prüfung automatisierbar; künftig sollen laut BSI digitale Werkzeuge die Umsetzung unterstützen.

Was GS++ ablöst – und was vorerst bleibt

Laut BSI löst die Stand-der-Technik-Bibliothek das IT-Grundschutz-Kompendium ab. Als Weiterentwicklung des IT-Grundschutz beschreibt der Anwenderkatalog nur noch Anforderungen, die nicht auf spezifische IT-Lösungen abzielen; der Kernel-Katalog, aus dem die 901 technischen und organisatorischen Anforderungen stammen, enthält nach seiner Beschreibung ausschließlich technologie- und herstellerneutrale Sicherheitsanforderungen. Produktbezogene Bausteine, wie sie das Kompendium Edition 2023 etwa für „Windows Server 2012“ oder „Clients unter macOS“ führte, haben im Anwenderkatalog deshalb kein produktspezifisches Gegenstück; für solche Systeme gelten die lösungsneutralen Anforderungen der passenden Zielobjektkategorien. Statt 111 Bausteinen in zehn Schichten gliedert sich der Katalog in 20 Praktiken; welche Anforderungen für ein Asset gelten, bestimmen Zielobjektkategorien. Anforderungszahlen von Kompendium und Katalog sind daher aus unserer Sicht nur eingeschränkt vergleichbar, und auch das BSI versteht seine Zuordnung des Kompendiums zu GS++ nicht als 1:1-Abbildung, sondern als Orientierungshilfe; sie ist mit Stand 21.07.2026 als Entwurf gekennzeichnet. Vorerst bleibt der IT-Grundschutz zertifizierbar: Laut Meilensteinplan endet die Zertifizierbarkeit am 30.11.2031, fünf Jahre nach Veröffentlichung des GS++. Anträge für eine Zertifizierung nach ISO 27001 auf Basis von GS++ sollen ab dem 01.01.2027 möglich sein, die Early-Adopter-Phase ist vom ersten Quartal 2027 bis zum 31.12.2027 vorgesehen. Den Meilensteinplan passt das BSI nach eigener Angabe stetig an.

Verbindlichkeit: Bundesverwaltung und NIS-2-Einrichtungen

Für die Einrichtungen der Bundesverwaltung schreibt das BSI-Gesetz, neu gefasst durch das NIS-2-Umsetzungsgesetz vom 2. Dezember 2025, Mindestanforderungen vor, die sich aus den BSI-Standards, dem Grundschutzkompendium – im Gesetz zusammen „IT-Grundschutz“ – und den Mindeststandards des Bundes ergeben. Die Erfüllung ist dem BSI spätestens fünf Jahre nach Inkrafttreten des Gesetzes nachzuweisen, laut BSI also 2030; wer die Mindestanforderungen umsetzt, erfüllt damit zugleich die gesetzlichen Risikomanagementvorgaben, soweit kein EU-Durchführungsrechtsakt darüber hinausgeht. Dasselbe Gesetz beauftragt das BSI, den IT-Grundschutz bis zum 1. Januar 2026 zu modernisieren, und der Anwenderkatalog verweist in seinen Metadaten auf genau diese Vorgaben für die Bundesverwaltung. Ab wann GS++ als maßgebliche Fassung im Sinne dieser Pflicht gilt, legt keine der für diese Seite ausgewerteten Primärquellen ausdrücklich fest. Für besonders wichtige und wichtige Einrichtungen nennt das BSI-Gesetz den IT-Grundschutz nicht: Ihre Maßnahmen sollen den Stand der Technik einhalten und die einschlägigen europäischen und internationalen Normen berücksichtigen. Aus unserer Sicht ist GS++ für sie ein möglicher, kein vorgeschriebener Weg.

Aufbau: sechs Kapitel, vier Anhänge

Zielgruppe, Entstehung, angekündigte Ergänzungen

Version 1.0 trägt in der Änderungshistorie das Datum 20.10.2026 und den Vermerk „Initiale Veröffentlichung der ersten anwendbaren Version“; als Autor nennt sie „S 13“, laut Organisationsplan des BSI das Referat „IT-Grundschutz und Mindeststandards“. Laut Meilensteinplan wurde der Standard am 27.10.2026 auf der it-sa in Nürnberg vorgestellt und der Community zur Anwendung bereitgestellt. Zielgruppe sind in erster Linie Early Adopters, also erfahrene Institutionen, die GS++ früh einführen und deren Erfahrungen in die Weiterentwicklung einfließen. Entwickelt wurde die Methodik gemeinsam mit der Grundschutz-Community und in ausgewählten Pilotierungsinstitutionen erprobt; die Pilotierungsphase lief vom 1. April bis 31. August 2026. Der „Leitfaden zur Methodik Grundschutz++“ aus dieser Phase ist noch abrufbar, maßgeblich ist der Standard. Mehreres kündigt das BSI erst an: Schulungskonzepte für GS++-Praktiker und GS++-Berater zum 30.11.2026, ein Anwendungsbeispiel anhand der fiktiven Beispielbehörde „BDIT“ im Dezember 2026, das Konzept zur Leistungsmessung zum 26.02.2027 und Leistungskennzahlen für jede Anforderung der Methodik-Praktiken zum 31.03.2027.

Fünf Prozessschritte, vier PDCA-Phasen

Der Standard beschreibt, verbindlich wird er über den Katalog: Die normativen Inhalte der Methodik hat das BSI in Anforderungen überführt und in Methodik-Praktiken strukturiert. Diese 99 Anforderungen gelten für alle Institutionen und sind auf jeden Informationsverbund anzuwenden; „ein individuelles Vorgehen ist nicht vorgesehen“. Wie streng eine einzelne Pflicht ist, entscheidet das Modalverb im Anwenderkatalog: 80 der 99 Methodik-Anforderungen sind MUSS, 19 SOLLTE, keine ist KANN. Standardtext und Katalog setzen die Akzente dabei nicht immer gleich. An mehreren Stellen formuliert der Standard eine Empfehlung, wo der Katalog MUSS verlangt; beim Restrisiko offener SOLLTE-Anforderungen ist es umgekehrt. VamiSec-Empfehlung: Planen Sie entlang der Katalog-Anforderungen und nutzen Sie den Standardtext als Erläuterung.

Kontext, Compliance und Anwendungsbereich

Die Kontextanalyse erfasst Faktoren, die von außen auf die Institution wirken – geopolitische, rechtliche und regulatorische wie NIS-2 oder DORA, technologische wie den Einsatz von KI, wirtschaftliche wie Abhängigkeiten von Lieferketten, gesellschaftliche sowie ökologische und physische, etwa die Lage an einem Fluss –, und Faktoren von innen: Strategien und Ziele, Struktur, etablierte Prozesse, die IT-Landschaft ohne Detailinventar, die Institutionskultur und Einstellung zur Sicherheit sowie Ressourcenmangel. Das Compliance-Management bringt Rechtskataster, Gesetze und Anforderungskataloge, interne Regelwerke sowie gesetzliche und vertragliche Verpflichtungen ein; was sich daraus ergibt, wird beim Anforderungspaket berücksichtigt. Den Anwendungsbereich legt die Institutionsleitung fest: Geschäftsprozesse, und zwar vollständig, die relevanten Institutionseinheiten, Standorte, Anwendungen und IT-Systeme, dazu die Abgrenzung zu externen Partnern und Dienstleistern und gegebenenfalls ausgeschlossene Bereiche. Interessierte Parteien wie Kunden, Dienstleister, Aufsichtsbehörden, Mitarbeitende oder Personalvertretungen werden mit ihren Erwartungen erfasst; mit der Leitung wird festgelegt, welche verbindlichen Verpflichtungen als Anforderungen ins ISMS eingehen.

Geschäftsprozesse: so einfach wie möglich, so genau wie nötig

Die Geschäftsprozesse im Anwendungsbereich müssen identifiziert und dokumentiert werden; gemeint sind auch Verwaltungs- und Fachverfahren. Sie sind die Grundlage für Schutzbedarfsfeststellung, Asset-Erfassung und Risikobetrachtung. Für die Dokumentation genügt es laut Standard, dass der Zweck des Prozesses im Hinblick auf die Institutionsziele erkennbar ist. Quellen sind Prozesslandkarten und bestehende Managementsysteme wie BCMS oder DSMS, bei Behörden die gesetzlichen Aufträge. Fehlen solche Übersichten, hilft die vereinfachte Geschäftsprozessanalyse aus dem Anhang des Standards, die bewusst als Mindestanforderung angelegt ist: Weder ein umfassendes Prozessmanagement noch eine ausführliche Prozessdokumentation wird verlangt.

1. 1
   Abläufe prüfen

   Ein Geschäftsprozess wird regelmäßig oder anlassbezogen wiederholt, ist für Auftrag oder Leistung der Institution wesentlich, führt zu einem nachvollziehbaren Ergebnis und besteht aus mehreren sachlich zusammenhängenden Tätigkeiten. Einzelne Arbeitsschritte sind keine Geschäftsprozesse; eine zu feine Aufgliederung sollte vermieden werden.

2. 2
   Vorhandene Quellen nutzen

   Organigramme und Geschäftsverteilungspläne, gesetzliche oder satzungsmäßige Aufgaben, das Verzeichnis von Verarbeitungstätigkeiten, Anwendungs- und Systemübersichten aus der CMDB, Prozessverzeichnisse, ISMS-Tools sowie Vertrags- und Dienstleisterübersichten. Besonders hilfreich kann das Gespräch mit den zuständigen Personen sein.

3. 3
   Fünf Angaben dokumentieren

   Kennung, Name, fachlich verantwortliche Person, Rolle oder Organisationseinheit, Kurzbeschreibung und wesentliche Anwendungen. Die Kurzbeschreibung muss Zweck, wesentliches Ergebnis und Beitrag zu den Institutionszielen erkennen lassen; die Form – Tabelle, Prozessverzeichnis, Wiki oder ISMS-Werkzeug – ist frei wählbar.

Leitlinie, Sicherheitsorganisation und Freigabe

Die Informationssicherheitsleitlinie ist das zentrale Dokument des ISMS: Sie beschreibt konkrete und messbare Ziele, etwa nach SMART, und die Strategie, legt Verpflichtung und Verantwortung der Institutionsleitung fest, wird von ihr freigegeben und muss allen Mitarbeitenden kommuniziert werden. Eine Informationssicherheitsorganisation mit festgelegten Rollen und Zuständigkeiten ist „zwingend erforderlich“. Interessenkonflikte, etwa zwischen IT-Leitung und ISB oder zwischen Datenschutzbeauftragtem und ISB, sind zu vermeiden, und der ISB oder eine andere Rolle der Sicherheitsorganisation muss in sicherheitsrelevante Projekte eingebunden werden. Verfahren für die interne und externe Kommunikation und für die Lenkung mindestens aller ISMS-relevanten Dokumente müssen verankert werden. Die Verantwortung für das ISMS liegt bei der Institutionsleitung und „kann nicht delegiert werden“; sie erhält Entscheidungsvorlagen zu Anwendungsbereich, Schutzbedarf, Reihenfolge der Geschäftsprozesse, Ressourcen und Leitlinie. Zum Abschluss initiiert die Institution die Risikobetrachtung: Risikoappetit und Akzeptanzkriterien auf strategischer, Verfahren und Kriterien auf methodischer, Rollen einschließlich Risikoeigentümer auf organisatorischer Ebene – den Rahmen autorisiert die Leitung.

Bei der Schutzbedarfsfeststellung wird für jeden erfassten Geschäftsprozess entschieden, welchen Schutzbedarf er bezüglich der Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit hat. Heranzuziehen sind die im Prozess verarbeiteten Informationen, maßgeblich sind die Schäden, die mit einer Beeinträchtigung verbunden sein können. Der Schutzbedarf ist für jeden Prozess einzeln zu ermitteln und zu dokumentieren, die Institutionsleitung gibt ihn frei. Der Anwenderkatalog macht Verfahren und Einstufung zu MUSS-Anforderungen und bezieht sie auf „Geschäftsprozesse oder Informationen“; eingestuft wird unter Berücksichtigung der Geschäftsziele und in Absprache mit der Institutionsleitung. Laut Hinweistext ist ein Prozess als hoch einzustufen, wenn existenzbedrohende finanzielle oder Reputationsschäden oder folgenschwere Auswirkungen auf Geschäftsziele oder bestehende Verpflichtungen drohen, ebenso wenn er als besonders vertraulich eingestufte Informationen verarbeitet.

Fünf Schadensszenarien als Hilfe für „hoch“

• Verstoß gegen Gesetze, Vorschriften oder Verträge mit existenzbedrohender Konsequenz für die Institution
• Beeinträchtigung des informationellen Selbstbestimmungsrechts, die zu einem erheblichen Reputationsschaden führt
• Beeinträchtigung der persönlichen Unversehrtheit
• Negative Innen- oder Außenwirkung, die die Reputation der Institution nachhaltig schädigt
• Finanzielle Auswirkungen in existenzbedrohendem Ausmaß

Weitere eigene Kategorien darf die Institution optional definieren, muss sie aber auf die beiden GS++-Kategorien abbilden; für ein zertifizierbares ISMS muss in der niedrigsten Kategorie stets der Stand der Technik eingehalten werden. Bei der erstmaligen Implementierung empfiehlt der Standard, mit dem wichtigsten Geschäftsprozess der höchsten Schutzbedarfskategorie zu beginnen – gibt es mehrere, wählt die Institutionsleitung – und danach sukzessive alle Prozesse des Anwendungsbereichs zu untersuchen. Den veröffentlichten Stand der Technik bezieht das BSI auf typische Verarbeitungssituationen. Bei atypischen Situationen oder erhöhtem Schutzbedarf, genannt werden staatlich eingestufte Daten und besondere Kategorien personenbezogener Daten nach der DSGVO, können weitere Schutzmaßnahmen erforderlich sein.

Vom Schutzbedarf zum Sicherheitsniveau

Jede Anforderung trägt eines von zwei Sicherheitsniveaus: normal-SdT, die Standard-Sicherheitsstufe, oder erhöht. Welche Anforderungen ausgewählt werden, richtet sich nach dem Schutzbedarf des betrachteten Geschäftsprozesses. Anforderungen des Niveaus erhöht beinhalten laut Standard das Modalverb KANN und sind optional zu erfüllen; sie lassen sich in der Risikobetrachtung heranziehen, um weitere Maßnahmen zu identifizieren, etwa bei erhöhtem Risiko. Im Katalog vom 22.10.2026 trifft das auf 224 der 227 erhöhten Anforderungen zu, drei tragen SOLLTE. Als SOLLTE-Anforderung sieht der Anwenderkatalog vor, die initiale Einstufung der Sicherheitsniveaus zu überprüfen, wenn der Kontext der Institution abweicht – laut Hinweistext besonders bei hohem Schutzbedarf; geändert werden kann sie auch für einzelne Assets. Eine Herabstufung von erhöht auf normal-SdT nennt der Hinweistext des Katalogs ausdrücklich als Anlass für eine Risikobetrachtung.

Anwendungsbereich und Informationsverbund

Der Anwendungsbereich legt den formalen und organisatorischen Umfang des ISMS fest, der Informationsverbund ist seine inhaltlich-technische Abbildung. Ein Anwendungsbereich kann einen oder mehrere Informationsverbünde enthalten; ein Informationsverbund kann den ganzen Anwendungsbereich umfassen oder einzelne Bereiche, die nach Organisationsstruktur, gemeinsamen Geschäftsprozessen oder Anwendungen gegliedert sind. Assets sind alle materiellen und immateriellen Werte, die für die betrachteten Geschäftsprozesse benötigt werden, etwa Anwendungen, IT-Systeme oder Räume. Eine klare Abgrenzung stellt sicher, dass alle relevanten Informationen, Assets und Abhängigkeiten erfasst werden; die erfassten Assets sind Voraussetzung für das Anforderungspaket. Der Anwenderkatalog fasst das in zwei MUSS-Anforderungen: den nachvollziehbar abgegrenzten Informationsverbund auf Basis des Geltungsbereichs festlegen und seine Schnittstellen zu externen Prozessen festlegen.

Relevante Assets können insbesondere Geschäftsprozesse, Informationen, Systeme und Anwendungen, Netz- und Kommunikationskomponenten, infrastrukturelle und physische sowie personelle und organisatorische Assets sein. Für die Dokumentation kann die Institution auf vorhandene Asset-Register und digital erfasste Systemdaten zurückgreifen; die Schnittstellen zu externen Prozessen und Systemen oder anderen Informationsverbünden sind organisatorisch, technisch und infrastrukturell eindeutig zu dokumentieren. Die Reihenfolge der Erfassung folgt der Priorisierung aus der Schutzbedarfsfeststellung, Assets mit ähnlichen Eigenschaften und ähnlichem Einsatzzweck dürfen gruppiert werden. Der Anwenderkatalog verlangt als MUSS, alle relevanten Assets der betrachteten Geschäftsprozesse festzulegen; im ersten PDCA-Durchgang genügen laut Hinweistext die Assets des wichtigsten Geschäftsprozesses. Je Asset sieht er eine eindeutige Bezeichnung, eine Kurzbeschreibung mit Zweck, die Zuordnung zu Geschäftsprozessen und eine verantwortliche Rolle oder einen Asset-Owner vor.

Abhängigkeiten: Tiefe nach Schutzbedarf

Für die Abbildung lassen sich laut Standard vorhandene Quellen wie CMDBs, Asset-Register, Betriebshandbücher, Netzpläne oder Service-Maps nutzen, um Doppelarbeit zu vermeiden. Entscheidend ist, dass die wesentlichen Abhängigkeiten nachvollziehbar dokumentiert sind, denn die Risikobetrachtung bei hohem Schutzbedarf setzt auf Ebene des Geschäftsprozesses an und folgt dem Ressourcenpfad. Für Prozesse mit normalem Schutzbedarf verlangt der Standard mindestens zwei Beziehungsarten. Anschließend werden die Assets den Zielobjektkategorien zugeordnet.

Praktiken: thematische Ordnung in drei Kategorien

Praktiken dienen laut Standard dem besseren Verständnis: Sie fassen die Anforderungen thematisch zusammen und sind in die Kategorien Methodik, Organisatorisch und Technisch unterteilt. Die sechs Methodik-Praktiken bilden mit 99 Anforderungen den Managementrahmen und tragen keine Zielobjektkategorie. Die acht organisatorischen und sechs technischen Praktiken enthalten 901 Anforderungen; jede von ihnen beginnt mit der Untergruppe „Grundlagen“ und gliedert sich danach thematisch – zusammen in 103 Untergruppen, der gesamte Katalog hat 140. Die Definitionen des BSI zu jeder Praktik klären die Abgrenzungen, etwa dass Monitoring-Evaluation der Check-Phase des PDCA-Zyklus entspricht, dass Verbesserung den Zyklus abschließt und zugleich einen neuen einleitet und dass Detektion den Umgang mit erkannten Ereignissen der Sicherheitsvorfallsbehandlung überlässt.

Beim Lesen hilft ein Muster: In den 14 technischen und organisatorischen Praktiken gibt es nur 69 MUSS-Anforderungen, und alle stehen in der Untergruppe „Grundlagen“. Sie bilden in jeder Praktik denselben Prozessrahmen – Verfahren und Regelungen verankern, dokumentieren, die damit verbundenen Aufgaben zuweisen, die Zuständigen informieren und die Regelungen regelmäßig und anlassbezogen überprüfen; in der Sensibilisierung steht an der Stelle der Überprüfung eine SOLLTE-Anforderung zur Erfolgsmessung. Die übrigen 832 Anforderungen dieser Praktiken sind SOLLTE oder KANN, und KANN-Anforderungen gehören ausnahmslos zum Sicherheitsniveau erhöht. Aus unserer Sicht ist SOLLTE damit der eigentliche Maßstab von GS++: Eine Abweichung ist sorgfältig abzuwägen und stichhaltig zu begründen, und eine dauerhafte Nichterfüllung löst eine Risikobetrachtung aus.

Zielobjektkategorien: Elternknoten und Kindknoten

Die hierarchisch höheren Knoten heißen Elternknoten, die ihnen untergeordneten Kindknoten. Anforderungen auf der obersten Stufe eines Strangs haben meist konzeptionellen Charakter, etwa „Verfahren verankern“; jede Kategorie ist im Anhang des Standards definiert, die meisten zusätzlich mit Beispielen, und jedes identifizierte Asset lässt sich mindestens einer Kategorie zuordnen. Entscheidend ist die Vererbung: Einem Asset sind auch alle übergeordneten Kategorien zuzuordnen, und erst die direkte und die übergeordneten Kategorien zusammen ergeben seine Anforderungen. Ein SaaS-Dienst, als Cloud-Dienst geführt, erbt so die Anforderungen von Outsourcing, Dienstleistungen und Einkäufe – 9 direkte plus 29, 31 und 39, zusammen 108. Der Anwenderkatalog macht Zuordnung, Vererbung und Konsolidierung zu MUSS-Anforderungen: Die Zuordnung erfolgt funktionsorientiert, also danach, wie das Asset im Geschäftsprozess wirkt, mehrfach wirkende Anforderungen werden nur einmal geführt, und schwer zuordenbare Assets werden in der Risikobetrachtung analysiert.

Drei Anforderungsarten

Den Weg zum Paket zeigt der Standard als Kette: Geschäftsprozess mit Schutzbedarf normal oder hoch, Assets, Zielobjektkategorien, Anforderungen, Anforderungspaket – und bei hohem Schutzbedarf die Risikobetrachtung. Für jedes Asset ergeben sich organisatorische, technische, personelle und infrastrukturelle Vorgaben; Anforderungen, die über mehrere Assets derselben Kategorie gelten, stehen nur einmal im Paket. Bei den Anforderungen ohne Zielobjektkategorie unterscheiden sich die Texte: Der Standard verlangt, sie verpflichtend aufzunehmen, der Hinweistext des Katalogs sieht je Anforderung eine Relevanzentscheidung und die begründete Streichung nicht relevanter Anforderungen vor. VamiSec-Empfehlung: dem Standard folgen, alle aufnehmen und Anforderungen, deren Komponente im Informationsverbund nicht existiert, in der Realisierung mit dokumentierter Begründung als „nicht anwendbar“ führen – so bleibt das Vorgehen nach beiden Texten nachvollziehbar.

Blaupausen: vorgesehen, aber noch nicht veröffentlicht

Eine Blaupause ist laut Standard ein vorgefertigter Katalog von Anforderungen, der anders als der Anwenderkatalog auf bestimmte Anwendungsszenarien zugeschnitten ist, eine Vorauswahl trifft und die Parameter vorgibt. Blaupausen können Gruppen von Assets oder einzelnen Assets zugeordnet und kombiniert werden; Auswahl einschließlich Version, Zuordnung und Anpassung sind nachvollziehbar zu dokumentieren, Lücken durch weitere Blaupausen oder Anforderungen zu schließen, und bei Änderungen des Informationsverbunds oder der verfügbaren Blaupausen ist die Auswahl zu überprüfen. Für bestimmte Institutionen kann es verpflichtende Blaupausen geben; welche das sind, nennt der Standard nicht. Mit Stand 29.10.2026 ist in der Stand-der-Technik-Bibliothek kein Artefakt als Blaupause bezeichnet. Veröffentlicht sind unter anderem das Profil „Stand der Technik WLAN“ mit 48 ausgewählten Anforderungen und drei festgelegten Parametern wie „WPA3“ sowie ein Profil zur Lieferkettensicherheit mit 146 Anforderungen ohne festgelegte Parameter; ob sie als Blaupausen gelten, sagt das BSI nicht. Ein Blaupausenkonzept hat das BSI einer Community-Arbeitsgruppe als Alpha-Version zur Kommentierung vorgelegt, öffentlich abrufbar ist es nicht.

Eigene Anforderungen und Gestaltungsentscheidungen

Kann ein Asset mit den bestehenden Anforderungen nicht hinreichend abgebildet werden oder ergeben sich Verpflichtungen aus Compliance-Management oder Stakeholder-Analyse, formuliert der Standard als Empfehlung, ergänzende Anforderungen zu entwickeln; der Anwenderkatalog macht beides zur MUSS-Anforderung. Für Assets ohne passende Anforderungen sieht der Hinweistext vor, die betroffenen Assets zu dokumentieren, zu begründen, warum die GS++-Anforderungen nicht ausreichen, gegebenenfalls neue Anforderungen bezogen auf die Schutzziele zu formulieren, sie fest ins Paket zu übernehmen und dem BSI zuzustellen. Das „vom GS++ vorgesehene Format“ für eigene Anforderungen präzisiert der Standard nicht; aus unserer Sicht bietet sich die Satzschablone an, nach der alle Katalog-Anforderungen aufgebaut sind: Praktik, gegebenenfalls Zielobjektkategorie, Modalverb, Ergebnis, optional eine Ergebnisspezifikation und ein Handlungswort – etwa „Informationen und Assets für IT-Systeme SOLLTE den Wartungsbedarf für Systemkomponenten und die zum Betrieb erforderliche Infrastruktur dokumentieren“. Der Katalog verwendet 27 Handlungswörter, am häufigsten verankern, dokumentieren und aktivieren, und nennt bei 961 Anforderungen eine empfohlene Dokumentationsart.

Gestaltungsentscheidungen trifft die Institution über Parameter: variable Elemente wie „regelmäßig“, die Auditoren und Anwendern Spielräume aufzeigen und sich für die automatisierte Prüfung nutzen lassen. Konkretisiert werden sie bei oder nach der Erstellung des Pakets; der Anwenderkatalog verlangt als MUSS, konkrete Werte zuzuweisen, laut Hinweistext etwa „täglich“, „wöchentlich“ oder „monatlich“ statt „regelmäßig“ oder die Personen und Rollen, denen jede technische und organisatorische Praktik in ihren Grundlagen die Aufgaben zuweist. Der Katalog enthält 223 Parameter in 210 Anforderungen. Das Profil des Anwenderkatalogs legt davon nur zwei fest: den Standard für das ISMS, „BSI Grundschutz++“, und den für ein BCMS, „BSI-Standard 200-4“; alle übrigen Werte bestimmt die Institution, sofern keine Blaupause sie vorgibt.

Umsetzungsstatus: drei Werte, vollständig geprüft

Für jede Anforderung des Anforderungspakets muss der aktuelle Umsetzungsstatus vollständig überprüft werden. Der Standard kennt drei Werte: „erfüllt“, „nicht erfüllt“ und „nicht anwendbar“. Der dritte Wert ist an Bedingungen geknüpft: Als „nicht anwendbar“ kann eine Anforderung gelten, wenn sie funktional nicht erfüllt werden kann oder die zugrunde liegende Komponente im Informationsverbund nicht existiert; die Begründung ist zu dokumentieren. Die Ermittlung sollte einem strukturierten Verfahren folgen, das von Interviews und Dokumentenprüfungen bis zu automatisierten Konfigurationsprüfungen und technischen Scans reichen kann; zuerst sind die Anforderungen mit dem Sicherheitsniveau normal-SdT zu prüfen. Im Anwenderkatalog ist die Statusprüfung eine MUSS-Anforderung, vollständig und regelmäßig, wobei die Institution das Intervall als Parameter festlegt. Der Hinweistext dort kennt nur „umgesetzt“ und „nicht umgesetzt“ und ergänzt eine Regel, die der Standard nicht nennt: Eine Anforderung gilt erst dann als umgesetzt, wenn auch alle mit ihr in Abhängigkeit stehenden Anforderungen umgesetzt sind.

Umsetzungsplan: jede Maßnahme an ihre Anforderung gebunden

Aus dem Anforderungspaket entsteht ein strukturierter Umsetzungsplan. Er legt für jede Anforderung konkrete Maßnahmen fest und priorisiert sie; als Kriterien nennt der Standard beispielhaft den Aufwand der zugrundeliegenden Anforderung, Synergien zwischen Maßnahmen, die Höhe der Risiken, die strategische Bedeutung und Quick-Wins mit hoher Wirksamkeit. Grundsätzlich empfiehlt er, die Anforderungen der Elternknoten zuerst umzusetzen. Für jede Anforderung muss eindeutig erkennbar sein, welche Maßnahmen ihr zugeordnet sind; adressiert eine Maßnahme mehrere Anforderungen, sind alle Zuordnungen auszuweisen, ebenso Abhängigkeiten. Je Maßnahme sind mindestens die zugehörige Anforderung, das Datum der Umsetzung oder Überprüfung und die dokumentierende beziehungsweise prüfende Person festzuhalten. Zuständigkeiten und realistische Fristen sollten in geeigneter Form dokumentiert werden, etwa in einem Projektmanagement- oder Ticketsystem; das Vorgehen gibt die Institutionsleitung frei, weil sie die Ressourcen bereitstellen muss. Der Fortschritt muss kontinuierlich nachgehalten werden, und ein möglicher Interessenkonflikt zwischen Umsetzung und Fortschrittsverfolgung ist durch eine angemessene Rollenverteilung zu verhindern.

Nachweise, automatisierte Prüfung und Historie

Nachweise, die zur Beurteilung herangezogen werden, sind eindeutig der jeweiligen Maßnahme zuzuordnen, damit sich die Umsetzung nachvollziehen lässt. Bei automatisierten Prüfungen gehören das eingesetzte Tool, der Prüfzeitpunkt und das Ergebnis in die Dokumentation; erzeugt das Tool einen Prüfbericht, wird er der Maßnahme und der Anforderung zugeordnet. Ändern sich Zuordnung, Umsetzungsstand oder Prüfergebnis, ist die Dokumentation zu aktualisieren, und für die Nachvollziehbarkeit empfiehlt der Standard eine Historie mit mindestens Zeitpunkt, verantwortlicher Person und eingesetztem Tool. Welche Inhalte ein Umsetzungsplan typischerweise trägt, zählt der Hinweistext zur Freigabe der Umsetzungsplanung auf: von Anforderungsbeschreibung, Zielobjekt, verantwortlicher Stelle, Fristen und Prioritäten über Risiken mit Begründung, Ressourcen und Abhängigkeiten bis zu Freigabedatum und Unterschrift des Risikoeigentümers. Für maschinenlesbare Prüfergebnisse ist in der Stand-der-Technik-Bibliothek ein eigener Assessment Layer vorgesehen; dort sind bisher noch keine Artefakte veröffentlicht.

Wann eine eigene Risikobetrachtung nötig ist

Dem Anwenderkatalog liegt eine allgemeine Risikobetrachtung des BSI zugrunde, die von einer angenommenen typischen Gefährdungslage ausgeht; deshalb müssen Anwenderinnen und Anwender bei normalem Schutzbedarf keine eigene Risikobetrachtung durchführen. Eine explizite Risikobetrachtung ist erforderlich, wenn ein Geschäftsprozess bei mindestens einem Schutzziel hohen Schutzbedarf hat, wenn ein für den Informationsverbund relevantes Asset durch die Zielobjektkategorien und ihre Anforderungen nicht hinreichend abgedeckt wird oder wenn eine anwendbare SOLLTE-Anforderung auf absehbare Zeit oder endgültig nicht erfüllt wird. Im Anwenderkatalog sind diese Auslöser als MUSS-Anforderungen gefasst: eine dedizierte Risikobetrachtung für Geschäftsprozesse oder Informationen mit hohem Schutzbedarf und eine Risikobetrachtung immer dann, wenn die Methodik sie verlangt. Der Hinweistext dazu nennt zusätzlich die Herabstufung des Sicherheitsniveaus von erhöht auf normal-SdT, einen Anlass, den der Standard selbst nicht aufführt. Das Verfahren für Identifikation, Bewertung und Behandlung wählt die Institution selbst, etwa auf Basis von ISO/IEC 27005, ISO 31000 oder BSI-Standard 200-3, solange die Mindestkriterien für die Risikobetrachtung eingehalten werden. Sie sollen die Methode unter anderem im Rahmen einer Zertifizierung vergleichbar und überprüfbar machen.

Rollen und Freigaben: wer was autorisiert

Elementare Gefährdungen: Bindeglied zwischen BSI-Herleitung und eigener Analyse

Die 47 elementaren Gefährdungen G 0.1 bis G 0.47, von Feuer bis zu schädlichen Seiteneffekten IT-gestützter Angriffe, beschreiben grundlegende Ereignisse, Umstände oder Handlungen auf abstrakter Ebene. Sie sind produkt- und technikneutral, mit internationalen Standards kompatibel, den Grundwerten Vertraulichkeit, Integrität und Verfügbarkeit zugeordnet und zielen auf realistische Gefahren; eine fehlende oder unzureichend umgesetzte Sicherheitsmaßnahme ist grundsätzlich keine elementare Gefährdung. In GS++ haben sie zwei Funktionen: Sie sind eine Grundlage, auf der das BSI die Anforderungen des Katalogs hergeleitet hat, und sie dienen Anwendern als Ausgangspunkt eigener Risikobetrachtungen. Die Verbindung ist im Katalog sichtbar. Die 901 Kernel-Anforderungen tragen G0-Kennungen, alle 47 Gefährdungen kommen vor, die Anforderungen der Methodik-Praktiken haben keine. Bei dauerhaft nicht erfüllten SOLLTE-Anforderungen sind die zugeordneten Gefährdungen zu berücksichtigen; praktisch beginnt die Analyse einer solchen Lücke also bei den G0-Kennungen der betroffenen Anforderung.

Leistungsbewertung: verpflichtend, aber noch ohne einheitliche Vorgaben

Zur Überprüfung der Wirksamkeit des ISMS und seiner Ziele ist eine Leistungsbewertung erforderlich. Weil die Entwicklung einheitlicher Vorgaben dafür im GS++ noch aussteht, sind die Institutionen in der Ausgestaltung frei; die Ergebnisse sollten der Institutionsleitung nachvollziehbar vorgelegt werden. Frei heißt nicht optional: Der Anwenderkatalog verlangt als MUSS-Anforderungen Verfahren und Regelungen zur Messung und Bewertung der Leistung des ISMS, die regelmäßige Überprüfung und Fortschreibung des Umsetzungsplans sowie eine regelmäßige Prüfung, ob die Anforderungen noch aktuell sind. Die methodische Lücke will das BSI laut Meilensteinplan 2027 schließen: Zum 26.02.2027 soll das Konzept zur Leistungsmessung in die Methodik integriert sein und angewendet werden können, zum 31.03.2027 soll jede Anforderung der Methodik-Praktiken Leistungskennzahlen haben.

Audit, Managementbewertung und Monitoring

Das interne Audit dient laut Standard der Selbstkontrolle: Sein Fokus liegt nicht auf dem Aufzeigen von Nichtkonformitäten, sondern von Verbesserungspotenzialen. Bei der Planung sind zuerst die Auditprogrammziele festzulegen; sie sollten unter anderem die Anforderungen an die Informationssicherheit, die Leistungsfähigkeit von Detektion und Sicherheitsvorfallbehandlung, die identifizierten Risiken, die Prozesse, den Reifegrad des ISMS und frühere Auditergebnisse berücksichtigen. Die Risiken des Auditprogramms selbst müssen ermittelt und bewertet werden, einschließlich Maßnahmen zur Vertraulichkeit im Audit. Umfang und Regelmäßigkeit sollten sich nach der Zahl der Informationssysteme, Standorte und betroffenen Personen, der Komplexität des ISMS und der Bedeutung der Risiken richten; Audits können vor Ort, remote oder kombiniert stattfinden, und die Auswahl des Auditteams sollte Objektivität und Unparteilichkeit sichern. In der Managementbewertung prüft die Institutionsleitung auf Grundlage des Managementberichts, ob das ISMS geeignet, angemessen und wirksam ist, mit Blick auf Auditergebnisse, Leistungsbewertung, Sicherheitsvorfälle, den Status der Risikobehandlung, Änderungen in Institution oder Bedrohungslage und den Status früherer Entscheidungen. Für das Monitoring müssen drei Verfahren verankert sein; hinzu kommt die regelmäßige Validierung der Anforderungen:

• Erkennung von Sicherheitsvorfällen mit frühzeitiger Identifikation und Meldung, je nach Größe und Komplexität der Institution von manuellen Abläufen bis zu automatisierten Erkennungssystemen.
• Umgang mit Schwachstellen: systematisch identifizieren, bewerten, behandeln und nachverfolgen, mit Rückfluss in die Risikobetrachtung.
• Erfassung neu auftretender Bedrohungen und Reaktion darauf, ebenfalls mit Rückfluss in die Risikobetrachtung.
• Validierung der Anforderungen bei Änderungen im Informationsverbund, in der Stand-der-Technik-Bibliothek, in genutzten Blaupausen oder in der Methodik GS++, abgestimmt mit den zuständigen Organisationseinheiten und gegebenenfalls mit Anpassung des Anforderungspakets.

Verbesserung: vom Befund zum Korrektur- und Verbesserungsplan

Werden Anforderungen nicht im vorgesehenen Maß erfüllt, liegt eine Abweichung vor. Nicht-Konformitäten werden systematisch erfasst und auf ihre Ursachen untersucht, nicht nur auf die unmittelbaren, sondern auch auf die zugrundeliegenden. Dazu gehören die Einschätzung, wie wahrscheinlich und folgenreich ein Wiederauftreten wäre, der Blick auf ähnliche Fälle in anderen Bereichen und die Frage, ob eine systemische Schwäche des ISMS vorliegt. Verbesserungspotenziale ergeben sich unter anderem aus der Bedrohungslage, der Effektivität des Umsetzungsplans, Auditergebnissen, Sicherheitsvorfällen und Vorschlägen der Mitarbeitenden; bewertet werden sollten sie nach Risikoreduktion, Ressourcenaufwand, strategischer Bedeutung, Synergien und Nachhaltigkeit. Die Korrektur- und Verbesserungsvorschläge müssen in einen Korrektur- und Verbesserungsplan eingebettet werden, der nach Ressourcen, Quick-Wins und größtem Verbesserungspotenzial priorisiert und in den Umsetzungsplan aufgenommen wird. Die Evaluation prüft anschließend mit messbaren Kriterien, Tests oder Audits, ob die Maßnahmen wirken. Erkannte Schwachstellen und geänderte Bedrohungslagen lösen einen neuen Zyklus der Risikobetrachtung aus, und der Kreis zum Umsetzungsplan der Realisierung schließt sich.

Modalverben, Sicherheitsniveaus und Zielobjektbezug

Aufwandsstufen: was das BSI an Arbeit erwartet

Was sich seit April 2026 verändert hat

Die Verschiebungen betreffen vor allem die Methodik-Praktiken: Dort sind Untergruppen entfallen oder zusammengeführt worden, zehn der zwölf entfallenen Anforderungen stammen aus der Methodik, und fünf Methodik-Anforderungen wurden von SOLLTE auf MUSS angehoben. Insgesamt wechselten elf Anforderungen das Modalverb; neben diesen fünf stiegen vier von KANN auf SOLLTE, je eine sank von SOLLTE auf KANN und von MUSS auf SOLLTE. Neu hinzugekommen sind überwiegend Anforderungen der Praktik Berechtigung. Für die Praxis wichtiger als jede Einzelzahl ist die Erkenntnis dahinter: IDs sind positionsabhängig und können sich zwischen Katalogständen ändern, stabil ist die UUID. Ein reiner Vergleich der IDs würde deutlich mehr neue und entfallene Anforderungen ausweisen, als es tatsächlich gibt. Wer Umsetzungsstatus, Mappings oder Erklärungen zur Anwendbarkeit auf Anforderungs-IDs aufbaut, sollte jeden neuen Katalogstand deshalb über die UUIDs abgleichen; aus unserer Sicht ist das eine Grundfunktion jedes GS++-Werkzeugs. Weitere Kennzahlen im Überblick:

• Größte Praktiken: KONF mit 157, BES mit 109, BER mit 92, SENS mit 87, DET mit 82 und GEB mit 75 Anforderungen; die sechs Methodik-Praktiken umfassen zusammen 99 Anforderungen, davon 80 MUSS und 19 SOLLTE.
• Häufigste Dokumentationsarten: Konfigurationshistorie mit 183, IT-Betriebskonzept mit 116, Beschaffungskriterien mit 70, Detektions-Konzept mit 61, Arbeitsanweisung und Schulungsplan mit je 60 Nennungen.
• Häufigstes Parameter-Label ist „regelmäßig“ mit 68 Vorkommen; das Profil des Anwenderkatalogs setzt nur zwei der 223 Parameter fest, alle übrigen konkretisiert die Institution.
• Häufigste elementare Gefährdungen: G 0.18 mit 385, G 0.23 mit 142, G 0.30 mit 130, G 0.36 mit 110, G 0.19 mit 98 und G 0.39 mit 95 Zuordnungen.
• Durch die Vererbung entlang der Zielobjektkategorien wächst der Umfang je Asset: Einem Asset der Kategorie Cloud-Dienste sind direkt 9 Anforderungen zugeordnet, mit den übergeordneten Kategorien Outsourcing, Dienstleistungen und Einkäufe sind es 108.
• Satzschablone: 27 verschiedene Handlungswörter, am häufigsten „verankern“ mit 137, „dokumentieren“ mit 100 und „aktivieren“ mit 78 Anforderungen.

Die Stand-der-Technik-Bibliothek

Die Stand-der-Technik-Bibliothek ist laut BSI die technische Plattform, auf der alle Anforderungen und Maßnahmen zentral bereitgestellt werden; sie löst das IT-Grundschutz-Kompendium ab, und der Anwenderkatalog Grundschutz++ ist ein Teil davon. Das Repository BSI-Bund/Stand-der-Technik-Bibliothek ist laut BSI seit 29.09.2025 öffentlich und steht unter der Lizenz CC BY-SA 4.0. Seit der Umstellung auf eine Layer-Struktur am 27.07.2026 veröffentlicht das BSI Aktualisierungen als automatisierte „rolling publication“ in wechselnden Abständen, bis zum Redaktionsstand 29.10.2026 zuletzt am 23.10.2026. Als Format dient OSCAL, die Open Security Controls Assessment Language des US-amerikanischen NIST; das BSI begründet die Wahl damit, keine eigene nationale Lösung entwickeln zu müssen und die Kompatibilität mit internationalen Sicherheitsstandards zu erhöhen. Formal beschreibt die BSI-Seite „Stand der Technik“ die Bibliothek weiterhin als in der Pilotphase befindlich.

Was in jeder Anforderung steckt

• ID und UUID: Laut dem BSI-Handbuch für Autoren der Stand-der-Technik-Bibliothek ist die ID positionsabhängig und kann sich bei Umstrukturierungen ändern, die UUID bleibt an die Bedeutung der Anforderung gebunden. Zwischen April und Oktober 2026 erhielten 157 Anforderungen eine neue ID.
• Satzschablone aus Praktik, gegebenenfalls Zielobjektkategorie, Modalverb, Ergebnis und Handlungswort. Nach demselben Autorenhandbuch müssen Vorschriften so formuliert sein, dass eine unabhängige dritte Partei mit Ja oder Nein prüfen kann, ob sie erfüllt sind.
• Metadaten: Sicherheitsniveau, Aufwandsstufe und, soweit vergeben, Zielobjektkategorien, Dokumentationsart und Schlagwörter; Kernel-Anforderungen zusätzlich mit Relevanzwerten 0 bis 2 für Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität sowie mit den G0-Kennungen der elementaren Gefährdungen.
• Parameter als Lückentext für Gestaltungsentscheidungen, etwa „regelmäßig“. Profile können Werte festlegen oder enger fassen; das Profil des Anwenderkatalogs setzt nur zwei, darunter „BSI Grundschutz++“ als Standard für das ISMS.
• Verknüpfungen zu verwandten und vorausgesetzten Anforderungen sowie Hinweistexte, die eine Anforderung erläutern und Umsetzungsbeispiele geben.

Mappings: Brücken zu ISO/IEC 27001 und zum IT-Grundschutz-Kompendium

Zum Lesen empfiehlt die README des BSI-Repositorys den Stand-der-Technik-Viewer, eine Browseranwendung aus der Community-Organisation bsi-community. Er stellt Kataloge, Komponentendefinitionen und Mappings clientseitig dar, filtert nach Merkmalen wie Sicherheitsniveau, Aufwand, Zielobjektkategorie, Modalverb oder Gefährdung und ergänzt bei Auswahl einer Zielobjektkategorie automatisch die übergeordneten Kategorien. Nach Angabe des BSI arbeiten zahlreiche Hersteller von IT-Grundschutz-Tools an der Integration der OSCAL-Daten. Die Grenzen sollten klar sein: OSCAL-Kataloge automatisieren laut BSI keine Implementierung und ersetzen nicht die fachliche Prüfung vor Ort, der Assessment Layer ist noch leer, und ein als Blaupause bezeichnetes Artefakt ist bisher nicht veröffentlicht. Die Profile für Lieferkettensicherheit mit 146 und für WLAN mit 48 Anforderungen sind Auswahlen aus dem Kernel; als Blaupausen bezeichnet das BSI sie nicht.

Systemzertifizierung: was feststeht und was offen ist

Fest steht: Ab 01.01.2027 können Anträge für eine Zertifizierung nach ISO 27001 auf Basis von GS++ gestellt werden. In seiner Meldung zur Veröffentlichung des Standards beschreibt das BSI ein nach Grundschutz++ implementiertes ISMS als ab 2027 zertifizierbar und zur ISO/IEC 27001 kompatibel. Offen ist das Prüfverfahren: Ein Auditierungsschema für GS++ ist nicht veröffentlicht. Laut BSI-Programm zur it-sa war für den 28.10.2026 ein Vortrag der Zertifizierungsstelle des BSI unter dem Titel „Ausblick auf die Zertifizierung nach Grundschutz++“ angekündigt, der aktuelle Überlegungen zum Auditierungsschema einschließlich der Herausforderungen bei Prüfgegenständen und Prüfkriterien vorstellen sollte. Die geltenden Unterlagen für die Zertifizierung nach ISO 27001 auf der Basis von IT-Grundschutz, also Prüfgrundlage 4.8, Zertifizierungsschema 2.2 und Auditierungsschema 2.5 vom 01.02.2026, beziehen sich auf ISO/IEC 27001:2022, BSI-Standard 200-2 und das IT-Grundschutz-Kompendium Edition 2023. Hinweise auf die künftige Prüfpraxis enthält der Standard selbst: Häufen sich dauerhafte Nichterfüllungen von SOLLTE-Anforderungen, könnte im Rahmen einer Zertifizierung eine erhebliche Abweichung festgestellt werden, und die Mindestkriterien sollen die Risikomethode unter anderem für eine Zertifizierung vergleichbar und überprüfbar machen.

Ausbildung und Personenzertifizierung: GS++-Praktiker, GS++-Berater, GS++-Auditteamleiter

Auch die Qualifizierung von Personen stellt das BSI um. Zum 30.11.2026 sollen Schulungskonzepte für die Ausbildung zum GS++-Praktiker und zum GS++-Berater erscheinen. Ab 01.01.2027 können Anträge auf Zertifizierung zum GS++-Berater und zum GS++-Auditteamleiter gestellt werden; im ersten Quartal 2027 startet für bereits zertifizierte IT-Grundschutz-Berater und Auditteamleiter eine gesonderte Fortbildung zur Zertifizierung als GS++-Berater beziehungsweise GS++-Auditteamleiter. Inhalte, Umfang und Zugangsvoraussetzungen nennt der Meilensteinplan nicht. Für Ausschreibungen und Angebote ergibt sich daraus aus unserer Sicht eine einfache Prüfregel: Vor dem 01.01.2027 kann niemand als GS++-Berater oder GS++-Auditteamleiter zertifiziert sein; vorhandene BSI-Qualifikationen beziehen sich auf den IT-Grundschutz.

Wer was beachten muss

Stand 29.10.2026. Der Meilensteinplan wird vom BSI fortgeschrieben; maßgeblich sind die jeweils veröffentlichten Zertifizierungsgrundlagen. VamiSec ist keine Zertifizierungsstelle, und die GS++-Personenzertifizierung beginnt erst 2027.

Pfad A: vom IT-Grundschutz

Pfad B: von ISO/IEC 27001

90-Tage-Startplan

1. 1
   Tage 1–15 · BSI 300-1 Kap. 2.3 und 2.10 · GC.1.2, GC.6.1, GC.8.1Mandat, Anwendungsbereich und Ziel klären

   Die Institutionsleitung bestätigt das Vorhaben, legt den Anwendungsbereich fest, gibt Ressourcen frei und entscheidet, ob 2027 eine Zertifizierung nach ISO 27001 auf Basis von GS++ angestrebt wird. Ein Kernteam aus ISB, Prozessverantwortlichen und IT wird benannt.

2. 2
   Tage 16–30 · Kap. 2.5 und 2.6 · GC.7.1.1, GC.7.1.2Geschäftsprozesse und Schutzbedarf

   Geschäftsprozesse im Anwendungsbereich dokumentieren, und wo keine Prozesslandkarte existiert, die vereinfachte Geschäftsprozessanalyse aus Anhang 2 nutzen. Den wichtigsten Prozess der höchsten Schutzbedarfskategorie auswählen und den Schutzbedarf normal oder hoch je Schutzziel von der Leitung freigeben lassen.

3. 3
   Tage 31–50 · Kap. 3 · STM.2.1.2 bis STM.2.1.5, STM.5.1Assets, Zielobjektkategorien und Anforderungspaket

   Für den ersten Durchgang genügen laut Hinweistext des Katalogs die Assets des wichtigsten Geschäftsprozesses. Assets den Zielobjektkategorien samt übergeordneter Kategorien zuordnen, Methodik-Anforderungen und Anforderungen ohne Zielobjektkategorie aufnehmen, Dubletten bereinigen und Parameterwerte festlegen.

4. 4
   Tage 51–70 · Kap. 4.1 · UMS.1.1Umsetzungsstatus erheben

   Mit den Anforderungen normal-SdT beginnen und je Anforderung erfüllt, nicht erfüllt oder nicht anwendbar mit Begründung dokumentieren. Vorhandene Ergebnisse aus dem IT-Grundschutz-Check oder der Erklärung zur Anwendbarkeit dienen als Startwert, nicht als Ergebnis.

5. 5
   Tage 71–85 · Kap. 2.11 und 4.2 · Anhang 3Risikobetrachtung aufsetzen

   Risikoappetit, Akzeptanzkriterien, Verfahren und Rollen von der Institutionsleitung autorisieren lassen; Risikobetrachtungen für Prozesse mit hohem Schutzbedarf, nicht hinreichend abgedeckte Assets und dauerhaft nicht erfüllte SOLLTE-Anforderungen starten.

6. 6
   Tage 86–90 · Kap. 4.3 bis 4.5 und 5.3 · UMS.2.1, RISK.1.10, PERF.4.1Umsetzungsplan und erster Managementbericht

   Maßnahmen priorisieren, Elternknoten zuerst, Zuständige und Fristen festlegen, die Umsetzungsplanung durch die Risikoeigentümer autorisieren lassen und der Leitung im Managementbericht Stand, Restrisiken und den nächsten Geschäftsprozess vorlegen.

Offene Punkte: was das BSI noch nachliefert