Produktstand · geprüft am 28.10.2026

Schritt 1: Erhebung und Planung, verteilt statt gebündelt.

Der BSI-Standard 300-1 beschreibt Schritt 1 in elf Teilschritten, vom Kontext der Institution bis zum Risikorahmen (Kapitel 2.1 bis 2.11). Fachlich ist das schlüssig. Im Alltag läuft aber fast alles über zwei Personen: Der ISB bereitet vor, die Leitung gibt frei. BlueProceedings ISMS verteilt die Arbeit, ohne die Verantwortung zu verwässern.

Arbeitsweise: welches Problem die Funktion löst und wie der Ablauf zusammenhängt
Produktstand: was heute in der Pre-Alpha vorhanden ist und wo ihre Grenzen liegen

Elf Teilschritte, ein Ort.

So bildet die Pre-Alpha jeden Teilschritt aus Kapitel 2 ab.

2.1 Kontext der Institution: Interne und externe Einflussfaktoren mit Quelle, Annahmen und Review, verknüpft mit den Entscheidungen, die auf ihnen beruhen.
2.2 Compliance-Management: Gesetze, Verträge, Satzungen und eigene Pflichten in einem Register, jede mit ihrem eigenen Katalog, ihrer Kritikalität und ihrer Quelle.
2.3 Anwendungsbereich: Jedes erfasste Objekt gehört dazu. Ein Ausschluss braucht eine Begründung.
2.4 Interessierte Parteien: Stakeholder mit ihren Erwartungen und einer Gewichtung, die in die Priorisierung einfließt.
2.5 Geschäftsprozesse: Prozesse mit Abhängigkeiten, RTO, RPO und Wiederanlauf. Widersprüche stehen direkt an der Verbindung.
2.6 Schutzbedarf: Normal oder hoch je Schutzziel, begründet mit Schadensszenarien und Kriterien für Erhöhung und Absenkung.
2.7 Leitlinie: Versioniert, von der Leitung freigegeben und mit Nachweis, wann sie kommuniziert wurde.
2.8 Rollen und Zuständigkeiten: RACI-Matrix für die Institution und je Informationsverbund, dazu Vertretungsplan und Funktionstrennung.
2.9 Dokumentation und Kommunikation: ISMS-Dokumente mit Version, Klassifikation, Freigabe und Review in einem Register.
2.10 Freigabe der Vorgehensweise: Freigaben mit Person, Rolle und Zeitpunkt, dort, wo die Entscheidung getroffen wurde.
2.11 Risikobetrachtung: Risikomatrix mit Risikoappetit und einer Regel je Zelle: automatisch akzeptieren, einzeln entscheiden oder ablehnen.

Aus der Pre-Alpha

Nacheinander oder parallel.

Klassisch holt der ISB jeden Fachbereich in einen Termin, trägt die Ergebnisse zusammen und geht mit den Risiken zur Leitung. Jede Rückfrage braucht einen neuen Termin.

In BlueProceedings ISMS erfassen die Fachbereiche ihre Prozesse und Objekte gleichzeitig selbst. Der ISB bündelt und meldet direkt zurück, die Leitung prüft im Rahmen ihrer Regeln. Die Darstellung ist schematisch und keine Messung: Die Fachbereiche arbeiten etwas mehr, ISB und Leitung deutlich weniger.

Schematischer Vergleich: Fachbereiche erfassen nacheinander mit gemeinsamen Terminen oder parallel in BlueProceedings ISMS. ISB und Leitung prüfen und geben Rückmeldung. Keine Zeitmessung. — Fiktive Demo-Daten aus der Pre-Alpha

Aus der Pre-Alpha

Verteilen, ohne zu verwässern.

Wer einen Prozess oder ein System verantwortet, macht die Angaben dazu selbst. Der ISB steuert, die Leitung gibt frei. Die RACI-Matrix hält fest, wer etwas ausführt (R), wer es verantwortet und freigibt (A, genau eine Rolle), wer vorher gefragt wird (C) und wer das Ergebnis erfährt (I).

Neben der Matrix für die Institution kann jeder Informationsverbund eine eigene haben, im Beispiel mit zwei konsultierten und mehreren informierten Rollen. Wer bei Abwesenheit einspringt, regelt getrennt davon der Vertretungsplan. Die Zahl der Nutzenden ist nicht begrenzt: Jede Fachabteilung kann mitarbeiten.

Institutionsweite RACI-Matrix mit Spalten R, A, C und I für ISMS-Leitlinie, Geltungsbereich, Register sowie Risikomanagement und Ausnahmen. Accountable ist jeweils die Institutionsleitung, Responsible meist die Informationssicherheitsbeauftragte, beim Register die Fachverantwortlichen; konsultiert werden Fachverantwortliche, Asset-Owner oder Risikoeigentümer, informiert wird der Auditor. — Fiktive Demo-Daten aus der Pre-Alpha

Lokale RACI-Matrix eines Informationsverbunds für Schutzbedarf, Risikomanagement und Umsetzung. Responsible sind Fach- oder Technisch-Verantwortliche, Accountable die Institutionsleitung oder die Fachverantwortlichen. Konsultiert werden zwei Rollen, die Informationssicherheitsbeauftragte und die Compliance-Beauftragte oder der IT-Betrieb; informiert werden mehrere Rollen wie Auditor, IT-Betrieb und Notfallbeauftragte. — Fiktive Demo-Daten aus der Pre-Alpha

Aus der Pre-Alpha

Wenn sich ein Faktor ändert.

Interne und externe Einflussfaktoren, etwa ein neues Gesetz oder eine Änderung in der Lieferkette, lassen sich mit Entscheidungen verknüpfen. Quelle, Annahmen, Unsicherheit und nächster Review stehen beim Faktor.

Wird eine inhaltlich geänderte Fassung freigegeben, zeigt seine Seite, welche Freigaben, Risikobewertungen, Schutzbedarfe, Dokumente und Maßnahmen neu zu prüfen sind, jeweils mit Namen und Link. Der Faktor ändert keine Bewertung selbst; die Verantwortlichen entscheiden.

Externer Einflussfaktor NIS2-Umsetzung mit Quelle, Annahmen, Unsicherheit und nächstem Review. Darunter die Auswirkung einer Ablösung und offene Prüfhinweise mit Namen der betroffenen Entscheidungen: ein Risiko, ein ISMS-Dokument, mehrere Schutzbedarfsfeststellungen und eine Maßnahme, je mit Link zur Entscheidung. — Fiktive Demo-Daten aus der Pre-Alpha

Aus der Pre-Alpha

Pflichten an einem Ort.

Gesetze, Verträge und Satzungen sind der Ursprung vieler Anforderungen. Im Compliance-Register steht jede Pflicht mit ihrem eigenen Katalog, ihrer Kritikalität und ihrer Quelle. Eigene Pflichten lassen sich direkt in der Oberfläche anlegen.

Im Beispiel gehören DSGVO, TLS-Mindeststandard, NIS2 und ISO/IEC 27001 Annex A je zu einem anderen Katalog. Neu eingelesene Kataloge stehen auf „Noch nicht bewertet“, bis jemand den Erfüllungsstand erhebt.

Compliance-Register mit vier Verpflichtungen, je mit eigenem Katalog: DSGVO mit dem Datenschutz-Anforderungskatalog, BSI-Mindeststandard zur Nutzung von TLS, NIS2-Umsetzungsgesetz mit dem Anwenderkatalog Grundschutz++ (372 von 998 erfüllt) und ISO/IEC 27001:2022 Annex A nur mit Kennungen und Titeln. Je Zeile Erfüllungsstand, Kritikalität mit Kennzeichen „Risikorelevant“ und Quelle. — Fiktive Demo-Daten aus der Pre-Alpha

Aus der Pre-Alpha

Alles gehört dazu, außer es ist begründet.

Jedes erfasste Objekt liegt standardmäßig im Geltungsbereich. Wer etwas herausnimmt, begründet es, und der Zeitpunkt bleibt sichtbar. Das beugt Schatten-IT vor, weil kein System aus Versehen herausfällt.

Für den Überblick lässt sich die Liste nach Objektart filtern und durchsuchen. Im Beispiel sind zwei Komponenten begründet ausgeschlossen.

Geltungsbereich mit Filter nach Objektart und Suchfeld. 48 referenzierbare Objekte sind im Geltungsbereich, darunter PostgreSQL-Cluster, Docker-Plattform, Kunden- und Vertragsdaten und das Kunden- und Marktpartnerportal. Zwei Komponenten sind ausgeschlossen, die Schulungsdatenbank mit synthetischen Daten und die Kantinenkasse des Pächters, jeweils mit Begründung und Zeitpunkt. — Fiktive Demo-Daten aus der Pre-Alpha

Aus der Pre-Alpha

Wer was erwartet.

Stakeholder werden mit ihren Erwartungen erfasst. Jeder kann einen ganzen Katalog, eine einzelne Anforderung, eine Maßnahme oder eine Kennzahl von 1 bis 5 gewichten.

Aus den Gewichtungen aller Stakeholder entsteht eine Rangfolge der Anforderungen und Maßnahmen. Sie hilft, die Reihenfolge der Umsetzung zu begründen.

Gewichtungen eines Stakeholders mit Werten von 1 bis 5 für einen ganzen Katalog, einzelne Anforderungen, Maßnahmen und eine Kennzahl. — Fiktive Demo-Daten aus der Pre-Alpha

Rangfolge der Anforderungen und Maßnahmen nach dem Durchschnitt der Gewichtungen aller Stakeholder. — Fiktive Demo-Daten aus der Pre-Alpha

Aus der Pre-Alpha

Wer wen braucht.

Geschäftsprozesse werden mit Abhängigkeiten, Schutzbedarf, Wiederanlaufzeit (RTO) und tolerierbarem Datenverlust (RPO) erfasst. Passen die Zeitvorgaben nicht zusammen, steht der Konflikt am Pfeil.

Im Beispiel soll die Netzleitstelle nach zwei Stunden wieder laufen, braucht aber die Smart-Meter-Erfassung mit einer RTO von vier Stunden. Das fällt beim Erfassen auf, nicht erst in der Notfallübung.

Prozessabhängigkeiten mit Schutzbedarf, RTO und RPO. Ein Hinweis zeigt den RTO-Konflikt zwischen Netzleitstelle mit zwei Stunden und benötigter Smart-Meter-Erfassung mit vier Stunden. — Fiktive Demo-Daten aus der Pre-Alpha

Aus der Pre-Alpha

Normal oder hoch, mit Begründung.

Grundschutz++ kennt zwei Schutzbedarfskategorien. Schadensszenarien legen fest, wann ein Schaden normal oder hoch ist; Kriterien begründen, wann vom vererbten Vorschlag nach oben oder unten abgewichen wird.

Neben Vertraulichkeit, Integrität und Verfügbarkeit lassen sich eigene Schutzziele führen, im Beispiel Authentizität (AUTH) und Nachvollziehbarkeit (TRACE). Schon ein hohes Schutzziel löst die eigene Risikobetrachtung aus (BSI-Standard 300-1, Anhang 3, Kriterium 32).

Vorlagen für Schadensszenarien mit Bezug, betroffenen Schutzzielen und der Grenze zwischen normal und hoch, etwa Abfluss von Verbrauchs- und Vertragsdaten, fehlende Nachweise für Aufsicht und Eichrecht mit dem eigenen Schutzziel TRACE, manipulierte Schalthandlung mit AUTH und I sowie Ausfall der Leitstelle. — Fiktive Demo-Daten aus der Pre-Alpha

Eskalations- und Deeskalationskriterien für Schutzbedarfsfeststellungen, etwa Gefahr für Leib und Leben, gesetzliche Meldefrist, Kumulation vieler Betroffener zur Erhöhung und veröffentlichte Daten oder erprobtes Ersatzverfahren zur Absenkung. — Fiktive Demo-Daten aus der Pre-Alpha

Aus der Pre-Alpha

Leitlinie und Dokumente.

Die Leitlinie hat Versionen, eine Freigabe durch die Leitung und einen nächsten Review. Je freigegebener Fassung wird bestätigt, wann sie an alle Mitarbeitenden kommuniziert wurde.

Alle ISMS-Dokumente stehen in einem Register mit Version, Status, Klassifikation, Review und Aufbewahrung.

Freigegebene Leitliniengruppe mit nächstem Review und Kommunikationsstand: Leitlinie v2 freigegeben am 28.10.2026 und kommuniziert, Leitlinie v1 freigegeben am 12.7.2026 und kommuniziert. — Fiktive Demo-Daten aus der Pre-Alpha

Register der ISMS-Dokumente mit Art, Version, Status wie veröffentlicht, freigegeben, Entwurf oder in Prüfung, Klassifikation, nächstem Review und Aufbewahrungsfrist. — Fiktive Demo-Daten aus der Pre-Alpha

Aus der Pre-Alpha

Die Leitung setzt die Regel.

Nach Anhang 3, Kriterium 30 autorisiert die Leitung jedes Restrisiko, und Risiken kommen mindestens jährlich und bei wesentlichen Änderungen wieder auf den Tisch. In BlueProceedings ISMS legt sie stattdessen für jede Zelle der Risikomatrix fest, ob ein Restrisiko vorab akzeptiert, einzeln entschieden oder abgelehnt wird.

Grüne Zellen mit dicker Linie sind vorab akzeptiert, rot gestrichelte abgelehnt; dort braucht jedes Risiko Maßnahmen. Die runde Zahl zeigt, wie viele Risiken nach Maßnahmen in der Zelle liegen. Die Freigabe der Matrix als Autorisierung zu werten, ist unsere Auslegung. Wer jedes Restrisiko einzeln freigeben will, stellt das mit einem Schalter ein.

Risikomatrix mit fünf Stufen für Wahrscheinlichkeit und Auswirkung. Jede Zelle trägt Stufe und Regel: grüne Zellen werden automatisch akzeptiert, eine dicke Linie markiert die Grenze, die meisten Zellen werden manuell entschieden, zwei kritische Zellen sind gestrichelt rot umrandet und werden abgelehnt. Runde Zahlen zeigen, wie viele Risiken nach Maßnahmen in einer Zelle liegen. — Fiktive Demo-Daten aus der Pre-Alpha

Aus der Pre-Alpha

Ausnahmen bleiben möglich, aber befristet.

Liegt ein Risiko in einer gesperrten Zelle, beantragt der Risikoeigentümer eine Ausnahme mit Begründung, Chancen und kompensierenden Maßnahmen. Die Leitung entscheidet mit Frist und Auflagen.

Die Befristung folgt Anhang 3, Kriterium 28; in der Anwendung beträgt sie höchstens ein Jahr. Bei einer nicht erfüllten MUSS-Anforderung ist keine Ausnahme möglich.

Genehmigte Ausnahme für ein Risiko in einer Zelle ohne Akzeptanz: Leitrechner der Fernwärme-Erzeugung bis zur Migration, mit Befristung, Begründung, Chancen, Bedürfnissen, geprüften und kompensierenden Maßnahmen, Entscheidung der Institutionsleitung und drei Auflagen. — Fiktive Demo-Daten aus der Pre-Alpha

Die Verantwortung bleibt bei der Leitung.

Die Anwendung verteilt Erfassung und Vorbereitung, sie trifft keine Entscheidung. Anwendungsbereich, Schutzbedarf, Leitlinie, Risikorahmen und Restrisiken gibt weiterhin die Leitung frei (BSI-Standard 300-1, Kapitel 2.10 und Anhang 3). Alle Bilder zeigen fiktive Demodaten aus der Pre-Alpha.

Das ist noch nicht alles.

Weitere Funktionen sind bereits umgesetzt. Wir bereiten ihre Vorstellung noch vor – schau später wieder vorbei.

Weiterlesen

BSI‑Standard 300‑1: die Methodik hinter Grundschutz++BSI-Standard 300-1 erklärt: Zweck, fünf Prozessschritte, Anwenderkatalog, OSCAL und praktische Bedeutung für die Einführung von Grundschutz++.Grundschutz++ umsetzen: vom Geltungsbereich zum laufenden ISMSGrundschutz++ umsetzen: vom Geltungsbereich über Anforderungsanalyse und Maßnahmen bis Überwachung und Verbesserung – entlang BSI-Standard 300-1.Risiken und Maßnahmen zusammenhaltenISMS-Risikomanagement mit nachvollziehbaren Entscheidungen: Risiken, Maßnahmen, Restrisiko, Akzeptanz und Wiedervorlage in BlueProceedings ISMS.

Quellen

BSI-Standard 300-1 „Methodik Grundschutz++“Fachliche Grundlage der beschriebenen Grundschutz++-Arbeitsabläufe
BSI: Grundschutz++Überblick, Veröffentlichungsstand und Meilensteine

Geschrieben von Xhoan Qazimi, BlueProceedings, zuletzt am 28.10.2026 mit den Quellen abgeglichen. Die Funktionsbeschreibung gibt den Stand der Pre-Alpha wieder; methodische Aussagen sind als solche benannt und belegt.

Verteilt erfassen. Zentral steuern. Einmal freigeben.

Schritt 2, die Anforderungsanalyse, folgt als nächster Beitrag. Die Testphase beginnt am 11.11.2026.

So sieht es aus Interesse melden