Der BSI-Standard 300-1 schreibt kein Werkzeug vor; Geschäftsprozesse dürfen auch in einer Tabelle oder einem Wiki dokumentiert werden (Anhang 2). Eine Software lohnt sich erst, wenn sie die Methodik richtig abbildet und euch Arbeit abnimmt, die von Hand fehleranfällig ist: Katalogstände, Vererbung, Fristen, Freigaben. Diese Seite leitet Auswahlkriterien aus dem Standard ab und sagt bei jedem, wo BlueProceedings ISMS heute steht.
Links steht, was der BSI-Standard 300-1 verlangt, rechts, wie BlueProceedings ISMS damit umgeht.
Die Anforderungen stehen im Anwenderkatalog der Stand-der-Technik-Bibliothek im OSCAL-Format. Ändert sich die Bibliothek oder eine Blaupause, sind die Anforderungen zu validieren.
Kataloge werden mit Version, Herkunft und Prüfsumme eingelesen; ein Stand des Anwenderkatalogs liegt bei. Ein neuer Stand gilt erst nach einer bewussten Migration, vor der die Anwendung neue, geänderte und entfallene Anforderungen und Parameter zeigt.
Jedes Asset wird mindestens einer Zielobjektkategorie zugeordnet, die übergeordneten ebenfalls. Anforderungen, die mehrfach anfallen, zählen nur einmal.
Die Vererbung rechnet die Anwendung. Die Zuordnung eines Assets treffen und begründen Menschen, und jede Anforderung zeigt, aus welchem Katalog sie kommt und für welches Objekt sie gilt.
Blaupausen werden mit Version dokumentiert, das Paket um Compliance- und Risikoanforderungen ergänzt, Parameter konkretisiert.
Blaupausen sind versionierte OSCAL-Profile; ein Ausschluss braucht eine Begründung. Parameterwerte stehen mit ihrer Herkunft am Paket, offene Parameter bleiben sichtbar.
Bei MUSS keine Ausnahme und keine Risikoakzeptanz; dauerhaft nicht erfüllte SOLLTE-Anforderungen verlangen eine Risikobetrachtung.
Bei MUSS sperrt die Anwendung Ausnahme und Risikoakzeptanz. Vorübergehende Lücken verlangen Begründung und Frist, dauerhafte SOLLTE-Lücken werden zu Risikokandidaten.
Das Verfahren ist frei, die Mindestkriterien sind verbindlich: unter anderem Risikoregister mit Mindestangaben, Risikoeigentümer, befristete Akzeptanz, Autorisierung der Restrisiken.
Die Risikoakte verbindet Ursache, Schutzziele, Risikoeigentümer, Bewertung, Behandlung, Maßnahme und Restrisiko. Die Leitung setzt je Zelle der Risikomatrix eine Regel; Ausnahmen gelten höchstens ein Jahr.
Maßnahmen sind mit Anforderungen verknüpft, Nachweise eindeutig zugeordnet, eine Historie wird empfohlen. Die Wirksamkeit wird an messbaren Kriterien geprüft.
Eine Maßnahme lässt sich erst abschließen mit geprüften Wirksamkeitskriterien, gültigem Nachweis und erforderlicher Freigabe. Änderungen werden in einem hashverketteten Protokoll festgehalten, das sich nur um neue Einträge ergänzen lässt.
Die Verantwortung der Leitung ist nicht delegierbar; zwischen Umsetzung und Fortschrittsverfolgung sind Interessenkonflikte zu vermeiden.
Freigaben tragen Person, Rolle und Zeitpunkt. Im regulären Betrieb verlangt jede Freigabe eine zweite Person; der Kleinunternehmen-Modus lockert nur die personelle Trennung, nicht die fachlichen Bedingungen.
Leistungsbewertung, internes Auditprogramm, Managementbewertung und Validierung der Anforderungen.
Auditprogramm, Managementbewertung und Kennzahlen sind abgebildet; Erwartungen von Prüfenden lassen sich importieren und Nachweise als Prüfpaket exportieren. Berichte zeigen, wenn sich ihre Grundlage seit der Ausgabe geändert hat.
Auch an uns. Die Antworten zeigen schnell, ob ein Werkzeug Grundschutz++ abbildet oder IT-Grundschutz mit neuem Etikett.
Die Bibliothek bekommt neue Stände. Ein Werkzeug, das den Katalog still überschreibt, verliert die Grundlage bisheriger Bewertungen.
Viele Werkzeuge kommen aus dem IT-Grundschutz mit Bausteinen. Fragt, ob das Anforderungspaket je Informationsverbund aus Zielobjektkategorien, Blaupausen und Ergänzungen entsteht.
Berechnungen und Vorschläge sind hilfreich. Zuordnung, Bewertung und Freigabe gehören Menschen und müssen mit Person und Zeitpunkt nachvollziehbar bleiben.
Eigene Infrastruktur oder Cloud des Anbieters, Verschlüsselung, Export in einem offenen Format. Was passiert mit den Daten, wenn ihr das Werkzeug wechselt?
Sollen Fachbereiche ihre Prozesse und Systeme selbst pflegen, darf die Zahl der Konten kein Hindernis sein. Sonst landet doch wieder alles beim ISB.
Grundschutz++ ist neu, und kein Werkzeug ist lange erprobt. Lasst euch zeigen, was heute läuft, und trennt es von Ankündigungen.
Ab dem 11.11.2026 testen bis zu elf Personen aus der ISMS-Praxis die Anwendung. Die erste Version ist für Januar 2027 geplant.
Jeder Teilschritt von 2.1 bis 2.11 hat seinen Platz in der Anwendung; eine Übersicht zeigt den Stand je Teilschritt. Die Einzelheiten stehen auf der Seite Erhebung und Planung.
Docker-Container auf eurer Infrastruktur, verschlüsselte Datenbank, keine Hersteller-Cloud. Die Zahl der Nutzenden ist nicht begrenzt. Mehr zu Betrieb und Rollen auf der Seite ISMS-Software für BSI und NIS2.
Betrieb, Sicherung und Updates liegen bei euch. E-Mail-Benachrichtigungen kommen später. Die Leistungskennzahlen, die das BSI bis März 2027 ergänzen will, sind noch nicht abgebildet. Eine Konformitäts- oder Zertifizierungsaussage trifft die Anwendung nicht.
Ein Sicherheitskonzept hält einen Stand fest. Ändern sich danach seine Grundlagen, zeigt die Anwendung, welche Bereiche betroffen sind und wann sie geändert wurden.
Das Beispiel zeigt einen Informationsverbund mit Demodaten. Die Verantwortlichen prüfen, was neu bewertet und berichtet werden muss.
Nicht zwingend. Der BSI-Standard 300-1 lässt die Form der Dokumentation offen. Mit wachsender Zahl von Assets, Katalogständen und Freigaben wird die Pflege von Hand aber fehleranfällig, besonders die Vererbung über Zielobjektkategorien.
Grundschutz++ leitet Anforderungen über Geschäftsprozesse, Assets und Zielobjektkategorien aus einem OSCAL-Katalog ab, nicht über Bausteine. Eine passende Software bildet Anforderungspaket, Blaupausen, Parameter und Katalogstände ab.
Nein. Sie kann Anforderungen ableiten, Fristen überwachen und Zusammenhänge zeigen. Umsetzung, Bewertung, Wirksamkeitsprüfung und Leitungsentscheidungen bleiben Aufgaben der Institution.
Nein. Die Anwendung läuft als Docker-Container auf eurer eigenen Infrastruktur; es gibt keine Hersteller-Cloud, und BlueProceedings hat keinen Zugriff auf eure Daten.
Die Anwendung hält Arbeit und Entscheidungen nachvollziehbar zusammen. Umsetzung, fachliche Beurteilung und die Entscheidung einer prüfenden Stelle ersetzt sie nicht. BlueProceedings ISMS ist derzeit Pre-Alpha; die erste Version ist für Januar 2027 geplant.
Geschrieben von Xhoan Qazimi, BlueProceedings, zuletzt am 01.11.2026 mit den Quellen abgeglichen. Was zur Methodik gesagt ist, folgt den Veröffentlichungen des BSI; was zu BlueProceedings ISMS gesagt ist, beschreibt die Pre-Alpha.
Die Startseite zeigt anhand von Demodaten, wie die Pre-Alpha aussieht. Was fehlt oder anders sein sollte, hören wir gern.