Drei Status statt vier
BSI-Standard 300-1 verlangt, dass der Umsetzungsstatus jeder Anforderung im Anforderungspaket vollständig überprüft wird. Der Status kann „erfüllt“ („ja“), „nicht erfüllt“ („nein“) oder „nicht anwendbar“ sein (Kap. 4.1.1). Für „nicht anwendbar“ nennt 300-1 genau zwei Gründe: „Eine Anforderung kann als ‚nicht anwendbar‘ gelten, wenn die Anforderung funktional nicht erfüllt werden kann oder die zugrunde liegende Komponente nicht im Informationsverbund existiert.“ (Kap. 4.1.1). Jede solche Einstufung braucht eine eigene Begründung.
Wer aus dem klassischen IT-Grundschutz kommt, kennt vier Werte: „entbehrlich“, „ja“, „teilweise“ und „nein“ (200-2, Kap. 8.4.2). „Teilweise“ gibt es im Grundschutz++ nicht mehr. Eine halb umgesetzte Anforderung ist nicht erfüllt. Der Katalog formuliert in seiner Erläuterung zu UMS.1.1 eine weitere Regel: „Eine Anforderung gilt nur dann als umgesetzt, wenn sie selbst sowie alle in Abhängigkeit stehenden Anforderungen umgesetzt sind.“
„Entbehrlich“ und „nicht anwendbar“ sind nicht dasselbe. Nach 200-2 durfte eine Anforderung auch dann entbehrlich sein, wenn sie durch Alternativmaßnahmen behandelt wurde. 300-1 nennt für „nicht anwendbar“ nur zwei Gründe: funktional nicht erfüllbar oder Komponente nicht vorhanden. Eine Alternativmaßnahme führt nach unserer Lesart deshalb zu „erfüllt“, wenn sie das Ergebnis der Anforderung nachweisbar erreicht, und sonst zu „nicht erfüllt“.
| Status 200-2 | Status 300-1 | Was beim Übertrag zu tun ist |
|---|---|---|
| ja | erfüllt | Nachweis der Maßnahme zuordnen (300-1, Kap. 4.3); abhängige Anforderungen mitprüfen |
| teilweise | nicht erfüllt | Fehlenden Teil als Maßnahme planen; nach Modalverb weiterbehandeln (bei SOLLTE temporär oder dauerhaft einordnen) |
| nein | nicht erfüllt | Nach Modalverb weiterbehandeln |
| entbehrlich (nicht relevant) | nicht anwendbar | Begründung neu formulieren: funktional nicht erfüllbar oder Komponente nicht vorhanden |
| entbehrlich (Alternativmaßnahme) | erfüllt oder nicht erfüllt | Prüfen, ob die Alternativmaßnahme das Ergebnis der Anforderung erreicht |
In welcher Reihenfolge Sie bewerten
Nach der Ermittlung des Umsetzungsstatus prüfen Sie zunächst die Anforderungen mit dem Sicherheitsniveau „normal-SdT“ und dokumentieren für jede den Status (300-1, Kap. 4.1.2). Anforderungen mit dem Niveau „erhöht“ enthalten nach 300-1 das Modalverb KANN und sind optional (Kap. 3.4.2); drei Ausnahmen im aktuellen Build stehen weiter unten. Sie werden vor allem für die Risikobetrachtung herangezogen, etwa wenn ein Geschäftsprozess hohen Schutzbedarf hat (Kap. 3.4.2).
Wie Sie den Status ermitteln, lässt der Standard offen. Er nennt Interviews und Dokumentenprüfungen ebenso wie automatisierte Konfigurationsprüfungen und technische Scans; wichtig ist ein strukturiertes Verfahren, das alle Anforderungen gleich bewertet (Kap. 4.1). Bevor Sie bewerten, müssen die Parameter konkretisiert sein. Eine Anforderung mit „regelmäßig“ lässt sich erst prüfen, wenn feststeht, was regelmäßig für Sie heißt (Kap. 3.5).
MUSS, SOLLTE, KANN: was bei Nichterfüllung folgt
Die Bedeutung der Modalverben definiert die Stand-der-Technik-Bibliothek in einer eigenen Vokabeldatei, die Folgen bei Nichterfüllung regelt 300-1 in Kapitel 4.1.2. Im Build vom 29.10.2026 haben 149 Anforderungen das Modalverb MUSS, 627 SOLLTE und 224 KANN.
| Modalverb | Bedeutung laut Katalog-Vokabular | Folge bei Nichterfüllung (300-1, Kap. 4.1.2) | Was Sie dokumentieren |
|---|---|---|---|
| MUSS | „eine Anforderung …, die unbedingt erfüllt werden muss (uneingeschränkte Anforderung)“ | Maßnahmen zur Erfüllung festlegen; Ersatz durch Risikobetrachtung, Ausnahme oder Akzeptanz schließt der Standard aus | Status, Maßnahme, Zuständigkeit, Frist |
| SOLLTE | „normalerweise erfüllt werden muss, es aber Gründe geben kann, dies doch nicht zu tun. Dies muss aber sorgfältig abgewogen und stichhaltig begründet werden.“ | Nichterfüllung als temporär oder dauerhaft einordnen. Dauerhaft: Risikobetrachtung, Restrisiken zur Freigabe an die Institutionsleitung | Einordnung, stichhaltige Begründung, bei dauerhaft Verweis auf das Risikoregister |
| KANN | „keine generelle Verpflichtung …, sondern es wird lediglich aufgezeigt, dass diese Handlung oder Maßnahme je nach Situation (d.h. nach Risikoanalyse) sinnvoll sein kann“ | Keine Pflichtfolge; die Umsetzung bleibt freiwillig | Entscheidung, ob die Anforderung aufgenommen wird; bei hohem Schutzbedarf Bezug zur Risikobetrachtung |
SOLLTE-Anforderungen: temporär oder dauerhaft nicht erfüllt
300-1 unterscheidet zwei Fälle (Kap. 4.1.2). Temporär heißt: Die Erfüllung ist geplant und zu einem absehbaren Termin vorgesehen; der Standard verlangt dafür eine stichhaltige Begründung. Dauerhaft heißt: „Eine dauerhafte Nichterfüllung liegt vor, wenn die Anforderung auf absehbare Zeit oder endgültig nicht erfüllt wird.“ (Kap. 4.1.2). In diesem Fall folgt eine Risikobetrachtung (Anhang 3, Mindestkriterium 34), die Restrisiken gibt die Institutionsleitung frei (Mindestkriterium 30), und die Gefährdungen, die der Katalog der Anforderung zuordnet, gehören in die Betrachtung (Mindestkriterium 17). Im Katalog stehen sie als G0-Kennung an der Anforderung.
Zur temporären Nichterfüllung ist der Standard nicht einheitlich; wir behandeln das als offene Auslegungsfrage. Kapitel 4.1.2 sagt, sie löse keine Risikobetrachtung aus. Nach Kapitel 4.1.1 muss die Institutionsleitung erfahren, welches Risiko bei eingeplanten, aber noch offenen Anforderungen bis zur Umsetzung besteht; die Institutionsleitung muss dieses Risiko tragen. Kapitel 2.11 spricht für eingeplante, noch nicht erfüllte SOLLTE-Anforderungen von einer Restrisikobetrachtung, deren Ergebnis die Institutionsleitung freigibt. Welche der Stellen vorgeht, sagt der Standard nicht; eine Klarstellung des BSI liegt in den ausgewerteten Quellen nicht vor.
Wir lösen das in der Praxis so: Für jede temporäre Nichterfüllung stehen Begründung, Maßnahme und Termin im Umsetzungsplan, und das offene Risiko wird in einem Satz beschrieben. Diese Liste legen wir der Institutionsleitung gesammelt zur Kenntnis und Freigabe vor. Eine vollständige Risikoanalyse nach Anhang 3 setzen wir erst bei einer dauerhaften Nichterfüllung an. Das ist unsere Lesart einer offenen Frage, keine Vorgabe des Standards; wie Ihr Auditteam sie bewertet, sollten Sie früh klären.
Dauerhafte Nichterfüllungen sollen selten bleiben. Sammeln sie sich, kann nach 300-1 der Stand der Technik insgesamt verfehlt sein, und eine Zertifizierung kann eine erhebliche Abweichung feststellen (Kap. 4.1.2). Wie die Risikobetrachtung für eine dauerhafte Nichterfüllung abläuft, zeigt die Seite Risikoanalyse; ob Ihr Verfahren die Anforderungen aus Anhang 3 abdeckt, prüfen Sie mit den Risiko-Mindestkriterien.
MUSS ohne Ausweg, KANN als Option
Für eine nicht erfüllte MUSS-Anforderung gibt es nur den Weg über Maßnahmen. Der Standard schließt Risikobetrachtung, Ausnahmegenehmigung und Risikoakzeptanz ausdrücklich aus (Kap. 4.1.2). In der Praxis gehören offene MUSS-Anforderungen deshalb an den Anfang des Umsetzungsplans. Die meisten MUSS-Anforderungen stammen aus der Methodik: 76 der 95 Methodik-Anforderungen sind mit MUSS formuliert, dazu die vier RISK-Anforderungen. Die 69 MUSS-Anforderungen des Kernels sind durchweg dieselbe Reihe von Rahmenanforderungen, die sich in jeder organisatorischen und technischen Praktik wiederholt: „Verfahren und Regelungen“, „Dokumentation“, „Zuweisung der Aufgaben“, „Bekanntgabe“ und „Regelmäßige Überprüfung“ (in SENS ohne die Überprüfung).
KANN-Anforderungen müssen nicht unbedingt berücksichtigt werden. Halten Sie trotzdem fest, ob Sie eine KANN-Anforderung aufnehmen. Bei hohem Schutzbedarf sind sie der naheliegende Vorrat an Maßnahmen für die Risikobehandlung (300-1, Kap. 3.4.2). Drei Anforderungen im Build 2026-10-29 haben das Niveau „erhöht“, aber SOLLTE statt KANN: BES.1.4, DET.4.12.1 und REA.2.5. Wir dokumentieren sie wie erhöhte Anforderungen und vermerken die Abweichung zum Standard, Einzelheiten auf der Seite Anwenderkatalog Grundschutz++.
Entscheidungsbaum für jede Anforderung
Der Baum fasst die Regeln aus 300-1 Kapitel 3.4 und 4.1 zusammen. Gehen Sie ihn je Anforderung und, wo nötig, je Asset durch.
- Gehört die Anforderung ins Anforderungspaket?
- Methodik-Anforderung: ja, sie gilt für jeden Informationsverbund (Kap. 3.4.1).
- Anforderung ohne Zielobjektkategorie: ja, verpflichtend aufzunehmen (Kap. 3.4.1).
- Anforderung mit Zielobjektkategorie: ja, wenn ein Asset dieser Kategorie oder einer untergeordneten Kategorie zugeordnet ist (Kap. 3.4.2). Sonst gehört sie nicht ins Paket und braucht keinen Status.
- Sicherheitsniveau „erhöht“: optional; Entscheidung festhalten, bei hohem Schutzbedarf in der Risikobetrachtung heranziehen.
- Ist die Anforderung anwendbar? Nicht anwendbar ist sie nur, wenn sie sich technisch oder organisatorisch gar nicht erfüllen lässt oder die Komponente im Informationsverbund nicht existiert. Dann Status „nicht anwendbar“ mit Begründung. Ende.
- Ist sie erfüllt? Erfüllt ist sie, wenn das Ergebnis der Anforderung mit dem konkretisierten Parameter erreicht ist und die abhängigen Anforderungen ebenfalls erfüllt sind. Dann Status „erfüllt“, Maßnahme und Nachweis zuordnen. Ende.
- Nicht erfüllt: welches Modalverb?
- MUSS: Maßnahme festlegen, in den Umsetzungsplan mit Zuständigkeit und Frist. Keine Risikoakzeptanz.
- SOLLTE, Erfüllung vorgesehen und absehbar: temporär. Begründung, Maßnahme, Frist; offenes Risiko der Institutionsleitung mitteilen.
- SOLLTE, auf absehbare Zeit oder endgültig nicht erfüllbar: dauerhaft. Risikobetrachtung nach Anhang 3 mit den zugeordneten elementaren Gefährdungen; Restrisiko zur Freigabe an die Institutionsleitung.
- KANN: optional; Entscheidung festhalten.
Sechs Musterfälle aus einer fiktiven Behörde
Die folgenden Fälle sind erfunden. Die Anforderungen und ihre Texte stammen aus dem Anwenderkatalog Grundschutz++, Build 2026-10-29. Die fiktive Behörde betreibt eine Fachanwendung für Antragsverfahren, hat keine Faxgeräte und verbietet Gruppenkonten.
| Fall (fiktiv) | Anforderung | Befund | Status und Einordnung | Dokumentation und Folge |
|---|---|---|---|---|
| 1. MUSS nicht erfüllt | BER.1.1.1 „Dokumentation“ (MUSS, normal-SdT): „Berechtigung MUSS die Verfahren und Regelungen dokumentieren.“ | Das Berechtigungsverfahren wird gelebt, ist aber nirgends schriftlich festgehalten | nicht erfüllt; MUSS | Maßnahme „Berechtigungskonzept schreiben und freigeben“ mit Zuständigkeit und Frist; keine Risikoakzeptanz möglich |
| 2. SOLLTE temporär | BER.5.9 „Mehr-Faktor-Authentisierung für weitreichende Berechtigungen“ (SOLLTE, normal-SdT) | MFA für Administrationskonten ist beauftragt, die Einführung ist in vier Monaten abgeschlossen | nicht erfüllt; SOLLTE temporär | Begründung, Maßnahme und Termin im Umsetzungsplan; offenes Risiko in der Sammelvorlage an die Institutionsleitung |
| 3. SOLLTE dauerhaft | KONF.14.1.1 „Obligatorische Verschlüsselung“ (SOLLTE, normal-SdT): „Konfiguration für Anwendungen SOLLTE unverschlüsselte und anfällige Verbindungen über Netze deaktivieren.“ | Die Fachanwendung tauscht Daten mit einem Altsystem eines Partners nur unverschlüsselt aus; eine Ablösung ist nicht absehbar | nicht erfüllt; SOLLTE dauerhaft | Risikobetrachtung mit den zugeordneten Gefährdungen G 0.43 und G 0.15; Behandlung, etwa ein abgeschotteter Übertragungsweg; Restrisiko zur Freigabe an die Institutionsleitung |
| 4. Nicht anwendbar | BER.3.17 „Gruppenkonten - MFA“ (SOLLTE, normal-SdT, ohne Zielobjektkategorie) | Gruppenkonten sind verboten und technisch nicht eingerichtet; ein Abgleich des Verzeichnisdienstes bestätigt das | nicht anwendbar | Begründung „Komponente nicht vorhanden“ mit Verweis auf den Abgleich; bei Einführung von Gruppenkonten neu bewerten |
| 5. Erhöht, optional | KONF.14.1.2 „Ende-zu-Ende-Verschlüsselung“ (KANN, erhöht) | Geschäftsprozess mit normalem Schutzbedarf | nicht im Paket | Entscheidung vermerken; bei hohem Schutzbedarf als mögliche Maßnahme in der Risikobetrachtung prüfen |
| 6. Früher „teilweise“ | DET.3.1 „Protokollierung sicherheitsrelevanter Ereignisse“ (SOLLTE, normal-SdT), Parameter von der Behörde auf 90 Tage festgelegt | Die Fachanwendung protokolliert, hält die Protokolle aber nur 30 Tage vor | nicht erfüllt; SOLLTE temporär, wenn die Speichererweiterung geplant ist | Kein „teilweise“: fehlende Aufbewahrungsdauer als Maßnahme planen, Termin festlegen |
Ein Grenzfall zum Status „nicht anwendbar“: KONF.12.13 „Sendebericht“ hängt an der Zielobjektkategorie Faxanwendungen. Hat die Behörde kein Fax, ordnet sie kein Asset dieser Kategorie zu, und die Anforderung kommt gar nicht ins Anforderungspaket. „Nicht anwendbar“ brauchen Sie vor allem bei Anforderungen ohne Zielobjektkategorie, die verpflichtend im Paket stehen.
Welche Angaben je Anforderung festgehalten werden
Der Standard verlangt keine bestimmte Form, aber eine Reihe von Angaben. Die Tabelle ordnet jede Angabe ihrer Fundstelle zu; wo „eigene Empfehlung“ steht, geht das Feld über den Standard hinaus. Mit diesen Feldern lässt sich jede Bewertung später nachvollziehen, auch wenn Personen wechseln.
| Feld | Inhalt | Fundstelle |
|---|---|---|
| Anforderung und Katalogstand | Kennung, Titel, Build-Datum des Katalogs | Kennung: Kap. 3.4; Build-Datum: eigene Empfehlung, damit die Validierung nach Kap. 5.5 nachvollziehbar bleibt |
| Bezug | Asset bzw. Zielobjektkategorie oder „ohne Zielobjektkategorie“ | Kap. 3.4.2 |
| Parameterwert | Konkretisierung, z. B. „regelmäßig = jährlich“ | Kap. 3.5 |
| Status | erfüllt, nicht erfüllt, nicht anwendbar | Kap. 4.1.1 |
| Begründung | Pflicht bei „nicht anwendbar“ und bei temporärer Nichterfüllung | Kap. 4.1.1 und 4.1.2 |
| Einordnung | bei SOLLTE: temporär oder dauerhaft | Kap. 4.1.2 |
| Maßnahmen | zugeordnete Maßnahme(n); adressiert eine Maßnahme mehrere Anforderungen, alle Zuordnungen | Kap. 4.3 |
| Datum und Person | Datum der Umsetzung oder Überprüfung, dokumentierende bzw. prüfende Person | Kap. 4.3 |
| Nachweis | eindeutig zugeordneter Nachweis; bei automatisierter Prüfung Tool, Zeitpunkt und Ergebnis | Kap. 4.3 |
| Zuständigkeit und Frist | für offene Maßnahmen | Kap. 4.4 |
| Risikobezug | bei dauerhafter Nichterfüllung die Kennung im Risikoregister und das Datum der Restrisikofreigabe | Kap. 4.1.2, Anhang 3 |
| Historie | frühere Feststellungen mit Zeitpunkt, verantwortlicher Person und eingesetztem Tool | Kap. 4.3 (empfohlen) |
Wer welche Nachweise wann liefert, planen Sie auf der Seite Nachweisplan.
Fehler, die Sie bei der Bewertung vermeiden sollten
- „Teilweise“ weiterführen. Aus dem Altbestand übernommene Teilerfüllungen müssen als „nicht erfüllt“ mit geplanter Maßnahme erscheinen.
- „Nicht anwendbar“ ohne Begründung. Der Standard verlangt sie für jede einzelne Anforderung.
- Alternativmaßnahme als „nicht anwendbar“. Erreicht die Alternative das Ergebnis, ist die Anforderung erfüllt; sonst nicht.
- Risikoakzeptanz für MUSS. Schließt der Standard aus.
- Dauerhafte Nichterfüllung ohne Risikobetrachtung. Mindestkriterium 34 macht sie zur Pflicht.
- Parameter nicht konkretisiert. Ohne festgelegten Wert lässt sich „erfüllt“ nicht belegen.
- Abhängigkeiten übersehen. Eine Anforderung gilt laut Katalogerläuterung zu UMS.1.1 erst als umgesetzt, wenn die abhängigen Anforderungen umgesetzt sind.
Wenn Sie einen Altbestand aus dem IT-Grundschutz-Check neu bewerten lassen wollen, übernimmt das Team von Blackfort Technology diese Arbeit; mehr dazu auf der Seite Beratung.
Rechtehinweis: Kurze Zitate aus BSI-Standard 300-1 „Methodik Grundschutz++“, Version 1.0 vom 20.10.2026, © Bundesamt für Sicherheit in der Informationstechnik 2026, Quelle: BSI-Seite zu Grundschutz++. Diese Zitate stehen nicht unter CC BY-SA 4.0; der Lizenzhinweis am Seitenende gilt nur für die Auszüge aus den Katalogdaten.