ISMS-Werkzeug für Grundschutz++ · Pre-Alpha

Mehr als eine Momentaufnahme.Ein ISMS, das mitläuft.

RiskScope hält Anforderungen, Risiken, Verantwortung und Nachweise aktuell, prüft sie laufend und verteilt die Arbeit auf Fachbereiche, IT und Leitung. So liegt das Sicherheitskonzept nicht im Ordner, während sich die Institution weiterentwickelt.

So sieht es aus Interesse melden

On-Premises per Docker, ohne Hersteller-Cloud
Erste Version für Januar 2027 geplant
Zwei Jahre kostenfrei für alle

9Bereiche, ein Datenstand

Risiken

Bereich 4 von 9

Bewertung mit Herkunft und Historie. Auswirkungen werden über Abhängigkeiten sichtbar.

Risikoregister
Ausbreitungsprüfung
Risikohistorie
Akzeptanz mit Wiedervorlage

Kontext: Wer und was wirkt auf die Institution: Grundlage für Geltungsbereich und Sicherheitsniveau.

Struktur: Was geschützt wird und wie es zusammenhängt.

Anforderungen: Der Grundschutz++-Katalog und weitere OSCAL-Kataloge, angepasst an die Institution und nachvollziehbar migriert.

Risiken: Bewertung mit Herkunft und Historie. Auswirkungen werden über Abhängigkeiten sichtbar.

Verantwortung: Wer entscheidet, wer vertritt, und welche Freigabe vier Augen braucht.

Überwachung: Ob Maßnahmen wirken, nicht nur ob sie erledigt sind.

Notfall: Notfallvorsorge (BCM): vorbereitet sein, bevor es ernst wird, und aus Vorfällen und Übungen lernen.

Berichte: Berichte merken, wenn sie nicht mehr stimmen, und sagen warum.

Schneller Start: Vom ersten Tag an arbeitsfähig, auch ohne Vorwissen zur neuen Methodik.

Schwierig wird, was nach der Freigabe kommt.

Tabellen, Vorlagen und One-Pager halten einen Stand fest. Wer länger mit ISMS arbeitet, kennt die vier Stellen, an denen dieser Stand verloren geht.

Aktualität: Dass ein Konzept nach Monaten veraltet ist, wissen die meisten. NIS2, DORA und CRA landen bei kleinen Teams, oft bei einer Person.
Veraltet-Warnung mit Ursache, Arbeit verteilt auf Fachbereiche
Verantwortung: Sie steht im Organigramm, doch im Alltag bleibt offen, wer entscheidet. Das Vier-Augen-Prinzip gilt oft nur, bis es eilig wird.
Rollen, RACI, Vertretungen, Vier-Augen-Freigaben im Prozess
Prüfung: Aus „erledigt“ wird schnell „wirksam“, ohne dass jemand geprüft hat.
Wirksamkeitsprüfung, Auditprogramm, Prüfpaket
Verbesserung: Abweichungen und Risiken werden notiert, doch ohne Übersicht bleibt unklar, was sie für Prozesse und Systeme bedeuten.
Auswirkungen über Abhängigkeiten, Risikohistorie

Veraltet statt falsch-grün.

Ändert sich nach der Freigabe eine Grundlage, markiert RiskScope das Sicherheitskonzept und die übrigen Berichte als veraltet. Je Ursache steht dort, wann sie sich zuletzt geändert hat, wie oft und wer in welcher Rolle. Neu erzeugen lässt sich der Bericht mit einem Klick.

Informationsverbund Kunden- und Marktpartnerportal: Hinweis „Das Sicherheitskonzept (Bericht) ist veraltet“, letzter Stand vom 30.09.2026. Je geänderter Bereich steht, wann zuletzt geändert wurde, wie oft und von wem in welcher Rolle, etwa Risiken durch die Institutionsleitung und das Schutzbedarfsprofil durch die Informationssicherheitsbeauftragte. — Fiktive Demo-Daten aus der Pre-Alpha

Eine Kette statt Dateiinseln.

In RiskScope weiß jede Angabe, woher sie kommt und was von ihr abhängt. Ändert sich ein Glied, wird sichtbar, was danach neu zu bewerten ist, statt dass ein alter Stand weiter grün aussieht.

Prozesse und InformationenWas die Institution tut und welche Informationen sie dafür braucht
Komponenten und DienstleisterWorauf das läuft, mit Abhängigkeiten und Schnittstellen
SchutzbedarfNormal oder hoch, je Schutzziel und mit Begründung
AnforderungenAus dem Grundschutz++-Katalog und weiteren Katalogen, je Objekt und mit Herkunft
RisikenBewertet, behandelt, akzeptiert mit Wiedervorlage
MaßnahmenMit Verantwortung, Frist und Meilensteinen
NachweiseGeprüft, versioniert und mit Ablaufdatum
WirksamkeitGegen Kriterien geprüft, nicht nur abgehakt
FreigabeMit vier Augen, Person, Rolle und Zeitpunkt

Und wieder von vorn. Neue Komponente, geänderter Schutzbedarf, abgelaufener Nachweis oder ein neuer Katalogstand: RiskScope markiert, was betroffen ist, und Berichte wie das Sicherheitskonzept sagen, seit wann und warum sie nicht mehr stimmen.

So sieht das in der Pre-Alpha aus.

Vier Funktionen aus neun Bereichen, so wie sie heute in RiskScope laufen, gezeigt mit fiktiven Demo-Daten. Auf LinkedIn stellt jeder Beitrag eine weitere vor, mit dem Problem, das sie löst.

Bereich Risiken

Bei einem Vorfall sehen, was mitbetroffen ist.

Ein Sicherheitsvorfall trifft eine Komponente. RiskScope schlägt über Abhängigkeiten und bestätigte Schnittstellen vor, was mitbetroffen sein könnte: links die Voraussetzungen, rechts die abhängigen Objekte. Erreichbar heißt nicht betroffen. Erst eine Bestätigung mit Aussage je Schutzziel macht ein Objekt zum Betroffenen.

Jedes Objekt mit Zustand in Wort und Randform
Verwerfen und „nicht entscheidbar“ mit Begründung
Bestätigte Objekte werden zu Risiken oder Teilrisiken

Ausbreitungsprüfung als zweiseitiger Graph: in der Mitte das Startobjekt PostgreSQL-Cluster, links seine Voraussetzungen, rechts die davon abhängigen Objekte, je Spalte eine Ebene. Drei Objekte sind bestätigt, zwei veraltet, eines verworfen, eines nicht entscheidbar, acht noch zu prüfen. Eine Legende erklärt die Randformen. — Fiktive Demo-Daten aus der Pre-Alpha

Bereich Notfall

Wiederanlauf und Wiederherstellung planen, bevor es ernst wird.

Ausgefallene Standorte oder Objekte wählen, verfügbares Personal angeben: RiskScope plant über die Abhängigkeiten, in welcher Reihenfolge Notbetrieb und Wiederherstellung anlaufen, und vergleicht fünf etablierte Verfahren von Greedy bis Branch-and-Bound. Als Maßstab dient der Verlust, wenn im Planungszeitraum nichts wieder anliefe. Das Ergebnis ist ein Planungsvorschlag, keine Entscheidung des Krisenstabs.

Gesamtverlust je Verfahren und Abstand zum besten Plan
Reihenfolge und Zeiten je Notfallprozess
Als Übung oder echter Krisenlauf speicherbar

Verfahrensvergleich eines Übungslaufs: bester Plan mit 1.027.530 Euro Gesamtverlust im Planungszeitraum, verglichen mit 3.531.600 Euro, wenn kein betroffener Prozess im Planungszeitraum wieder anliefe. Drei verschiedene Ergebnisse aus fünf Verfahren (Greedy, Branch-and-Bound, Priority Rule, Parallel SGS, MTPD-gewichtete Priority Rule) mit Abstand zum besten Plan. — Fiktive Demo-Daten aus der Pre-Alpha

Bereich Notfall

Notfallvorsorge auf demselben Bestand.

Business-Impact-Analyse, Notfallszenarien und Übungen beziehen sich auf dieselben Prozesse, Komponenten und Standorte wie das übrige ISMS. Ein Szenario hält fest, welche Objekte gestört oder verloren sind. Übungen haben Ziele, Kriterien und Sollzeiten, und was dabei auffällt, wird zur Folgearbeit.

Planspiel, Funktions-, Wiederherstellungs- und Kommunikationstest
Planung, Durchführung und Abschluss als getrennte Stände
Unveränderliche Zeitlinie und Folgearbeit nach der Übung

Planspiel zur Verschlüsselung der zentralen Plattformdienste: Beteiligte mit Rollen, Annahme, Sicherheits- und Abbruchbedingung, zwei Soll-Zeiten von je einer Stunde, ein Erfolgskriterium und das Szenario mit Container-Plattform und Identitätsdienst gestört sowie Datenbank-Cluster verloren. — Fiktive Demo-Daten aus der Pre-Alpha

Bereich Überwachung

Erledigt ist nicht wirksam.

Maßnahmen entstehen aus Risiken, Sicherheitsvorfällen, Audit-Feststellungen, Kennzahlen oder neuen Vorgaben. Abgeschlossen ist eine Maßnahme erst, wenn vorab festgelegte Kriterien geprüft sind und ein gültiger Nachweis vorliegt. Bis dahin bleibt der Abschluss gesperrt und sagt, was fehlt. Die Schließung gibt eine zweite Person frei. Im Kleinunternehmen-Modus entfällt nur die personelle Trennung, nicht die Prüfung.

Messbare Wirksamkeitskriterien, bevor geprüft wird
Nur akzeptierte, gültige Nachweise schließen ab
Aus „nicht bestanden“ entsteht die Feststellung automatisch

Prüfkreis einer Verbesserungsmaßnahme in vier Schritten: Feststellung aus dem Audit bestätigt, Maßnahme in Umsetzung und offen, Wirksamkeitsprüfung offen mit dem Hinweis „Kriterien festlegen“, Abschluss gesperrt, bis die Wirksamkeitskriterien festgelegt und gespeichert sind. — Fiktive Demo-Daten aus der Pre-Alpha

Gebaut für alle, die ein ISMS tragen.

Ein ISMS hängt selten an einer Person, auch wenn es sich oft so anfühlt. RiskScope gibt jeder Rolle die Antwort auf ihre eigene Frage, aus demselben Datenstand.

InformationssicherheitInformationssicherheitsbeauftragte und ihr Team: Wo steht unser ISMS, und was muss ich als Nächstes anstoßen?
Die Lage über alle Informationsverbünde: offene Nachweise, Fristen und Risiken, veraltete Berichte mit Ursache und Aufgaben, die bei den Verantwortlichen liegen
LeitungInstitutionsleitung, Geschäftsführung: Welche Entscheidung braucht jetzt meine Aufmerksamkeit?
Freigaben, Risikoakzeptanz mit Wiedervorlage und eine Managementbewertung mit vorbelegten Eingaben
FachbereicheProzess- und Objektverantwortliche: Was gilt für meinen Prozess, und was ist meine Aufgabe?
Eigene Aufgaben statt Rundmail, jede Anforderung mit Herkunft und Bezug zum eigenen Verfahren
NotfallmanagementNotfallbeauftragte, Krisenstab: Welche Prozesse müssen zuerst wieder laufen, und was brauchen sie dafür?
BIA mit Wiederanlaufzeiten, Notfallorganisation, Szenarien, Krisenläufe und Übungen auf denselben Abhängigkeiten wie das übrige ISMS
IT-BetriebBetrieb von Systemen, Netzen und Anwendungen: Welche Maßnahmen und Nachweise erwartet man von uns, und bis wann?
Zugewiesene Maßnahmen mit Frist, Nachweise mit Ablaufdatum und Komponenten mit ihren Abhängigkeiten. RiskScope selbst läuft per Docker auf eigener Infrastruktur.
Audit und RevisionInterne Revision, Prüfende: Woraus folgt diese Aussage?
Die Kette von der Anforderung bis zum Nachweis, Prüfmodus, Prüfpaket als Datei und ein Änderungsprotokoll

Grundschutz++ kommt. RiskScope wächst mit.

Die Entwicklung begann, als es von Grundschutz++ erst Umrisse gab. Die erste Version erscheint, wenn die Methodik zertifizierbar wird.

Anfang 2026Entwicklung beginntVon Grundschutz++ gibt es erst Umrisse.
Oktober 2026Pre-AlphaFeinschliff in Teilen öffentlich, Fortschritte regelmäßig auf LinkedIn.
27.10.2026BSI auf der it-saVorstellung von Grundschutz++ in Nürnberg.
11.11.2026TestphaseElf Freiwillige testen die Pre-Alpha und geben Rückmeldung.
01.01.2027ZertifizierbarGrundschutz++ wird laut BSI zertifizierbar.
Januar 2027Erste VersionGeplant: Download, Quelltext und Community-Einreichungen.

Gute Vorlagen entstehen in der Praxis. Teilen wir sie.

Blaupausen, Vorlagen für Informationsverbünde und Komponenten, Berichtsvorlagen und Erfahrungen: offen auf GitHub, vor der Aufnahme moderiert, importierbar als lokaler Entwurf.

Zur Community Diskussionen

Läuft bei dir. Deine Daten bleiben bei dir.

RiskScope wird als Container ausgeliefert und auf eigener Infrastruktur betrieben, ohne Hersteller-Cloud.

Verfügbar ab Januar 2027

Container, Installationsanleitung und Quelltext erscheinen mit der ersten Version. Bis dahin zeigen die Beiträge auf LinkedIn, was entsteht.

BlueProceedings/riskscopeContainer, Installation, Quelltext · ab Januar 2027 BlueProceedings/riskscope-communityVorlagen, Erfahrungen, Diskussionen · Diskussionen jetzt offen

Stand: Pre-Alpha, erste Version für Januar 2027 geplant
Betrieb: On-Premises per Docker, ohne Hersteller-Cloud
Daten: Verschlüsselte Datenbank auf eigener Infrastruktur, Export in offenen Formaten wie OSCAL
Kosten: Die ersten zwei Jahre kostenfrei für alle Organisationen, danach kostenpflichtig. Die Bedingungen werden vorher veröffentlicht.
Methodik: Grundschutz++-Katalog des BSI im OSCAL-Format, weitere OSCAL-Kataloge importierbar
Lizenz: Wird vor der ersten Version veröffentlicht

Vorher testen: 11 Plätze ab 11.11.2026

Ab dem 11.11.2026 bekommen elf Freiwillige die Pre-Alpha zum Testen auf eigener Infrastruktur. Wir suchen Menschen aus der ISMS-Praxis, die regelmäßig ausprobieren und offen sagen, was fehlt, hakt oder unklar ist. Aus den Meldungen wählen wir die Teilnehmenden aus. Getestet wird mit Übungsdaten, nicht mit dem echten ISMS.

Interessiert an der Testteilnahme

Häufige Fragen

Was hier nicht steht, beantworten wir gern per E-Mail an info@blueproceedings.de.

Macht mich RiskScope konform oder zertifizierungsbereit?

Nein. RiskScope unterstützt die Vorbereitung: Es hält Anforderungen, Nachweise, Prüfungen und Entscheidungen nachvollziehbar zusammen. Ob eine Institution die Anforderungen erfüllt, beurteilt die prüfende Stelle.

Wo liegen unsere Daten?

Auf eurer eigenen Infrastruktur. RiskScope läuft als Docker-Container On-Premises, die Datenbank ist verschlüsselt, und es gibt keine Hersteller-Cloud. Austausch mit Prüfenden oder der Community geschieht bewusst über Dateien, die ihr selbst exportiert und importiert.

Was kostet RiskScope?

Die ersten zwei Jahre nach der ersten Version ist RiskScope für alle Organisationen kostenfrei. Danach wird es kostenpflichtig. Die Bedingungen werden veröffentlicht, bevor die kostenfreie Zeit endet.

Wann kann ich RiskScope ausprobieren?

Die erste Version ist für Januar 2027 geplant, wenn Grundschutz++ laut BSI zertifizierbar wird. Den letzten Feinschliff machen wir in Teilen öffentlich: Die Beiträge auf LinkedIn zeigen laufend, was fertig wird, und Rückmeldungen fließen direkt ein. Ab dem 11.11.2026 testen elf Freiwillige die Pre-Alpha. Wer dabei sein möchte, meldet sich per E-Mail.

Wir arbeiten noch mit IT-Grundschutz. Passt RiskScope trotzdem?

RiskScope setzt die Methodik Grundschutz++ um und arbeitet mit dem Katalog, den das BSI im OSCAL-Format auf GitHub veröffentlicht. Weitere Kataloge im OSCAL-Format lassen sich zusätzlich importieren. Für den Umstieg gibt es Vorlagen, einen Einrichtungsassistenten, der aus dem tatsächlichen Datenbestand den nächsten Schritt ableitet, und einen Lern-Modus mit eigener Übungsumgebung.

Wir sind ein kleines Team. Ist das nicht zu groß für uns?

Gerade kleine Teams sollen die Arbeit verteilen können: Fachbereiche pflegen ihre Objekte, IT liefert Nachweise, die Leitung entscheidet. Wo es keine zweite Person gibt, lockert der Kleinunternehmen-Modus die personelle Trennung beim Vier-Augen-Prinzip, ohne die fachlichen Prüfungen abzuschalten.

Wie arbeiten wir mit Auditoren zusammen?

Ohne Gastkonten: Ihr importiert die Erwartungsliste der prüfenden Stelle, seht die Lücken und exportiert ein Prüfpaket mit Nachweisen und Prüfsummen. Ergebnisse eines externen Audits lassen sich wieder importieren.

Wer steht hinter RiskScope?

BlueProceedings, ein Einzelunternehmen in Bonn. RiskScope ist ein unabhängiges Projekt und wird nicht im Auftrag eines Arbeitgebers entwickelt.

Neu auf LinkedIn

Die Beitragsreihe startet in diesen Tagen auf der LinkedIn-Seite von BlueProceedings: eine Funktion und das Problem dahinter, regelmäßig bis zur ersten Version.

BlueProceedings auf LinkedIn folgen

Warum RiskScope entsteht

Grundschutz++ ist maschinenlesbar. Damit kann Software übernehmen, was von Hand kaum zu leisten ist: Angaben laufend pflegen, überwachen und nachvollziehen. Dafür entsteht RiskScope.

RiskScope entsteht seit Anfang 2026 bei BlueProceedings, einem Einzelunternehmen von Xhoan Qazimi in Bonn. Die Software baut auf Fachwissen aus der ISMS-Praxis und auf dem Grundschutz++-Katalog auf, den das BSI als offene Daten auf GitHub veröffentlicht.

RiskScope ist ein unabhängiges Projekt und macht keine Aussage über Zertifizierung oder Konformität. Es unterstützt die Vorbereitung. Es wird nicht im Auftrag eines Arbeitgebers entwickelt.

info@blueproceedings.de

Bereit sein, wenn Grundschutz++ zertifizierbar wird.

Folge der Entwicklung auf LinkedIn oder sag uns, was dir im ISMS heute am meisten Arbeit macht. Jede Rückmeldung aus der Praxis fließt in die erste Version ein.

Auf LinkedIn folgen Interesse melden