Der BSI-Standard 300-1 beschreibt Prozessschritt 1 in elf Teilschritten, vom Kontext der Institution bis zum Rahmen für die Risikobetrachtung (Kapitel 2.1 bis 2.11). Auf dieser Seite steht je Teilschritt, was der Standard verlangt und wie BlueProceedings ISMS es umsetzt, danach, was die Anwendung darüber hinaus kann. Der Grundgedanke: Fachlich ist Schritt 1 schlüssig, im Alltag läuft aber fast alles über zwei Personen. Die Anwendung verteilt die Arbeit, ohne die Verantwortung der Leitung zu verwässern, und hält fest, warum etwas entschieden wurde.
Ein geänderter Vertrag kann eine Compliance-Verpflichtung betreffen; eine Erwartung des Auftraggebers kann zusätzliche Anforderungen begründen. Die Kontextspur hält diese Verbindungen zur Entscheidung fest. Die Leitungsmappe zeigt die Freigaben im Zusammenhang.
Was daraus zuerst bearbeitet wird, soll erklärbar bleiben: Einflussfaktoren, Stakeholder und Compliance-Verpflichtungen können die Priorität von Anforderungen und Maßnahmen begründen. Die Anwendung zeigt die Beiträge; die Verantwortlichen entscheiden über die Reihenfolge. Den weiteren Weg zeigen Risikomanagement und Nachweismanagement.
Die Bilder zu den Teilschritten folgen weiter unten in derselben Reihenfolge. Die ersten vier Teilschritte klären vor der ersten Maßnahme: Was wirkt auf uns? Was müssen wir einhalten? Wofür gilt das ISMS? Wer erwartet was?
Die Faktoren erfassen, die von außen (unter anderem Geopolitik, Recht und Regulierung, Technologie, Wirtschaft, Gesellschaft, Umwelt) und von innen (unter anderem Strategie, Struktur, Prozesse, IT, Kultur, Ressourcen) auf die Institution wirken, und knapp festhalten, welche das ISMS prägen.
Einflussfaktoren mit Quelle, Annahmen, Unsicherheit und Termin zur Überprüfung, eingeordnet in die zwölf Gruppen des Standards oder in eigene Gruppen. Die Kontextlandkarte zeigt, zu welcher Gruppe noch nichts erfasst ist; eingeordnet wird nichts automatisch. Entscheidungen und Maßnahmen nennen ihre Faktoren. Ändert sich ein Faktor, erscheinen Prüfhinweise bei allem, was auf ihm beruht.
Rechtskataster, Gesetze, Anforderungskataloge und interne Regelwerke analysieren, zuständige Compliance-Stellen anhören, gesetzliche und vertragliche Verpflichtungen dokumentieren. Die daraus folgenden Anforderungen gehören ins Anforderungspaket.
Ein Compliance-Register mit eigenem Katalog, Kritikalität und Quelle je Compliance-Verpflichtung, dazu die Dokumentation nach Kapitel 2.2 (Anhörung, interne Regelwerke, Rechtskataster). Die Geltungsmatrix zeigt je Verpflichtung und Objekt, ob sie dort gilt, warum, und wie viele Anforderungen umgesetzt sind. Erfüllt zählt nur mit gültigem, akzeptiertem Nachweis. „Was fehlt noch?“ nennt Objekte ohne Verpflichtung, Verpflichtungen ohne Objekt und Dienstleister ohne gültigen Nachweis.
Die Institutionsleitung legt aus Kontext und Verpflichtungen fest, welche Geschäftsprozesse, Institutionseinheiten, Standorte, Anwendungen und IT-Systeme dazugehören und welche externen Partner und Dienstleister berücksichtigt werden. Ausgeschlossenes kann benannt werden.
Wir drehen es um: Alles Erfasste gehört dazu, ein Ausschluss braucht eine Begründung. Der Überblick zeigt die Objekte im Anwendungsbereich nach Objektart, nennt die ausgeschlossenen Objekte und zeigt die Schnittstellen zu Objekten außerhalb. Eine Entscheidungsvorlage fasst für die Leitung Ausschlüsse, Dienstleister-Abhängigkeiten und offene Befunde zusammen. In der Oberfläche heißt der Anwendungsbereich „Geltungsbereich“.
Interne und externe Stakeholder identifizieren, ihre Erwartungen dokumentieren, Relevanz und Priorität festlegen und mit der Institutionsleitung klären, was verbindlich ins ISMS aufgenommen wird.
Stakeholder in Gruppen auf einer Landkarte; jede Erwartung mit der Entscheidung, ob sie übernommen wird, und ihrer Begründung. Der Erwartungs-Trichter zeigt, was erfasst, entschieden, übernommen und mit Maßnahmen hinterlegt ist. Freigegebene Gewichte von 1 bis 5 auf Kataloge, Anforderungen, Maßnahmen, Kennzahlen oder Compliance-Verpflichtungen fließen in einen Vorschlag für die Reihenfolge ein.
Die Geschäftsprozesse im Anwendungsbereich identifizieren und dokumentieren, etwa über Prozesslandkarten oder die vereinfachte Analyse aus Anhang 2. Es reicht, wenn der Zweck im Hinblick auf die Institutionsziele erkennbar ist.
Prozessregister und Prozesslandkarte mit Haupt- und Teilprozessen, wahlweise mit Kennung, Zweck und Ergebnis, Beitrag zu den Zielen, Quelle und wesentlichen Anwendungen. Abhängigkeiten zwischen Prozessen tragen Wiederanlaufzeit (RTO) und tolerierbaren Datenverlust (RPO); Widersprüche stehen am Pfeil.
Je Geschäftsprozess den Schutzbedarf für Vertraulichkeit, Integrität und Verfügbarkeit feststellen: normal oder hoch, orientiert an Schadensszenarien. Bei hohem Schutzbedarf ist eine Risikobetrachtung erforderlich.
Eine Matrix mit Prozessen und Schutzzielen zeigt den Schutzbedarf in Symbol und Wort, Abweichungen vom vererbten Vorschlag und ob die nötige Risikobetrachtung fehlt, abgelaufen oder vorhanden ist. Neue Installationen starten mit den fünf Schadensszenarien des Standards. Begründet wird wahlweise gesamt oder je Schutzziel; eigene Schutzziele sind möglich.
Eine Leitlinie mit Verpflichtung der Leitung, konkreten und messbaren Zielen, Strategie und Sicherheitsorganisation. Die Leitung gibt sie frei, allen Mitarbeitenden wird sie kommuniziert.
Die Leitlinie hat Fassungen mit Freigabe, Termin zur Überprüfung und bestätigter Kommunikation. Das Dokument entsteht als PDF aus dem freigegebenen Stand, mit einer Momentaufnahme der Kennzahlen zu den Zielen. Die Ziele lassen sich mit Kennzahlen aus dem KPI-Register verbinden.
Rollen und Zuständigkeiten mit Qualifikationen festlegen, Interessenskonflikte vermeiden (IT-Leitung und ISB, DSB und ISB) und Schnittstellen festlegen.
RACI-Matrix für die Institution und je Informationsverbund, Vertretungsplan und eine Konfliktmatrix, in der die Paare des Standards voreingestellt sind. Die Rollenkarte zeigt je Rolle Besetzung, Vertretung, RACI und Funktionstrennung; Rollen mit offener Absicherung stehen oben.
Ein Verfahren für die interne und externe Kommunikation, auch bei sicherheitsrelevanten Projekten, und eine Dokumentenlenkung, die Nachvollziehbarkeit, Aktualität und Vollständigkeit über den Lebenszyklus sichert.
Ein Dokumentregister mit Version, Status, Klassifikation, Überprüfung und Aufbewahrung. Wer laut RACI-Matrix zu konsultieren (C) oder zu informieren (I) ist, sieht die betreffenden Vorgänge unter „Beratung und Information“; wird ohne Beratung freigegeben, bleibt das festgehalten. Berichte haben ein Erzeugungsintervall und aufbewahrte Stände.
Die Verantwortung liegt bei der Institutionsleitung und kann nicht delegiert werden. Ihr werden Entscheidungsvorlagen vorgelegt, unter anderem zu Anwendungsbereich, Schutzbedarf, Reihenfolge der Geschäftsprozesse, Ressourcen und Leitlinie.
Jede Freigabe hat eine Fassung, eine freigebende Rolle, ein Datum und einen Termin zur Überprüfung; Begründung und Einflussfaktoren lassen sich an der Freigabe festhalten. Die Leitungsmappe zeigt alle Freigaben an einem Ort, dazu neuere Fassungen, die noch warten, und Restrisiken, über die die Leitung entscheiden soll.
Den Rahmen auf drei Ebenen schaffen: strategisch (Risikoappetit, Akzeptanzkriterien), methodisch (Verfahren, Kriterien) und organisatorisch (Rollen, Risikoeigentümer). Die Institutionsleitung autorisiert ihn (Anhang 3, Kriterium 9).
Ein Überblick zeigt die drei Ebenen mit ihrem Stand; was sich nicht laden lässt, heißt „unbekannt“ und zählt nie als Lücke. In der Risikomatrix legt die Leitung je Zelle fest, ob ein Restrisiko vorab akzeptiert, einzeln entschieden oder abgelehnt wird. Befristete Ausnahmen bleiben möglich.
Der Standard sagt, was festzuhalten ist. Im Alltag kommen Fragen dazu, die eine Liste nicht beantwortet. Dafür hat die Pre-Alpha eigene Ansichten; sie zeigen an und bewerten nicht.
Eine Karte zeigt je Teilschritt 2.1 bis 2.11 den Stand und genau eine nachprüfbare Tatsache, etwa „neuere Fassung wartet auf Freigabe“, mit Sprung an die Stelle. Es gibt bewusst keine Gesamtzahl.
Die Kontextspur zeigt zu einem Prozess, welche Stakeholder, Compliance-Verpflichtungen und Einflussfaktoren zu welchen Entscheidungen geführt haben, als Graph oder als Liste. Fehlt ein Objektbezug, steht dort „Ohne Objektbezug“, statt einen zu erfinden.
Ein Faktor kann an eine Kennzahl gebunden sein, etwa die Zahl überfälliger Maßnahmen. Nennt eine Entscheidung den Faktor, bleibt der damalige Wert festgehalten und steht neben dem heutigen. Ob neu entschieden wird, entscheiden die Zuständigen.
Anstehende Überprüfungen und auslaufende Gültigkeiten von Faktoren, Stakeholdern und Compliance-Verpflichtungen an einer Stelle, nach Zeitraum geordnet und mit Kennzeichnung überfälliger Termine.
Für Maßnahmen schlägt die Anwendung eine Priorität von P1 bis P5 vor. Es gibt keine Gesamtpunktzahl: Die höchste Einzelklasse bestimmt den Vorschlag, und die Erklärung nennt den Grund, etwa eine überschrittene Frist, die Gewichtung eines Stakeholders oder eine Compliance-Verpflichtung. Eine manuell gesetzte Priorität bleibt sichtbar.
An jeder Maßnahme stehen Anlass, Bezüge und Einflussfaktoren an einer Stelle. So bleibt erkennbar, ob ihr Grund noch besteht.
Ein Nachweis kann mehrere Compliance-Verpflichtungen stützen. Wird er ungültig oder läuft er ab, fällt er bei allen weg, und die Lücke wird sichtbar.
Ein ausgeschlossener Dienstleister, der eine Komponente im Anwendungsbereich betreibt, und Dienstleister ohne jeden Bezug werden gemeldet. Mehr dazu auf der Seite Dienstleister und Lieferkette.
Die Karte „Stand der Vorbereitung“ zeigt jeden Teilschritt mit Zustand und einer nachprüfbaren Tatsache. Von dort geht es zur passenden Stelle in der Anwendung. Eine Gesamtpunktzahl gibt es nicht.
Im Beispiel warten neue Fassungen auf Freigabe, andere Grundlagen wurden seit der Freigabe geändert. Die Prozesse sind erfasst; beim Rahmen für die Risikobetrachtung gibt es noch offene Punkte. Die Aufnahme zeigt fiktive Demodaten vom 01.11.2026.
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.
Interne und externe Einflussfaktoren, etwa ein neues Gesetz oder eine Änderung in der Lieferkette, lassen sich mit Entscheidungen verknüpfen. Quelle, Annahmen, Unsicherheit und der Termin der nächsten Überprüfung 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.
Gesetze, Verträge und Satzungen sind der Ursprung vieler Anforderungen. Im Compliance-Register steht jede Compliance-Verpflichtung mit ihrem eigenen Katalog, ihrer Kritikalität und ihrer Quelle. Eigene Compliance-Verpflichtungen 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.
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.
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.
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.
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).
Die Leitlinie hat Fassungen, eine Freigabe durch die Leitung und einen Termin zur nächsten Überprüfung. Je freigegebener Fassung wird bestätigt, wann sie an alle Mitarbeitenden kommuniziert wurde. Das Dokument selbst entsteht als PDF aus dem freigegebenen Stand.
Alle ISMS-Dokumente stehen in einem Register mit Version, Status, Klassifikation, Überprüfung und Aufbewahrung. Das ist die Dokumentenlenkung, die Kapitel 2.9 verlangt.
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.
Die Leitungsmappe führt die Freigabestände je Thema zusammen: Fassung, Datum, freigebende Rolle, Gültigkeit und nächste Überprüfung. Neue Fassungen bleiben neben dem bisher freigegebenen Stand erkennbar. Entschieden wird in den verlinkten Bereichen.
Im Beispiel sind die Risikomatrix und die Einstellung zur Leitungsfreigabe der Restrisiken freigegeben. Die Leitlinie hat eine neuere Fassung im Entwurf, beim Geltungsbereich wird auf eine inhaltliche Änderung hingewiesen. Die Aufnahme zeigt fiktive Demodaten vom 01.11.2026.
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.
Der Überblick zum Rahmen für die Risikobetrachtung zeigt die drei Ebenen getrennt: Risikoappetit und Akzeptanzkriterien, Verfahren und Bewertungskriterien sowie die Zuordnung zu Risikoeigentümern. Zustände stehen mit Symbol und Wort bei den einzelnen Punkten.
Im gezeigten Demostand ist noch keine Risikomatrix freigegeben. Das Verfahren ist beschrieben, ein Teil der Risiken hat aber noch keinen Risikoeigentümer. Die offenen Punkte werden sichtbar, ohne den gesamten Rahmen pauschal zu bewerten.
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.
Elf Teilschritte in Kapitel 2: Kontext der Institution, Compliance-Management, Anwendungsbereich, interessierte Parteien, Geschäftsprozesse, Schutzbedarfsfeststellung, Informationssicherheitsleitlinie, Rollen und Zuständigkeiten, Dokumentation und Kommunikation, Freigabe der Vorgehensweise und Initiierung der Risikobetrachtung.
Der Standard verlangt, wesentliche Aspekte knapp festzuhalten (Kapitel 2.1). BlueProceedings ISMS hält jeden Faktor kurz, verbindet ihn aber mit den Entscheidungen und Maßnahmen, die auf ihm beruhen, und gibt ihm einen Termin zur Überprüfung.
Zwei: normal und hoch, je Geschäftsprozess und Schutzziel (Kapitel 2.6). Eigene Kategorien sind möglich, müssen aber auf diese beiden abgebildet werden. Bei hohem Schutzbedarf ist eine eigene Risikobetrachtung erforderlich.
Nein. Bei normalem Schutzbedarf deckt die allgemeine Risikobetrachtung des Anwenderkatalogs ab. Eine explizite Risikobetrachtung ist nötig bei hohem Schutzbedarf, bei nicht hinreichend abgedeckten Assets und bei dauerhaft nicht erfüllten SOLLTE-Anforderungen (Kapitel 2.11, Anhang 3, Kriterien 32 bis 34).
Die Institutionsleitung. Ihre Verantwortung kann sie nicht delegieren (Kapitel 2.10). Die Anwendung verteilt Erfassung und Vorbereitung auf Fachbereiche und ISB; die Freigaben bleiben bei der Leitung und stehen gesammelt in der Leitungsmappe.
Der Anwendungsbereich legt den formalen und organisatorischen Umfang des ISMS fest (Kapitel 2.3). Der Informationsverbund ist seine inhaltlich-technische Abbildung mit den Assets; ein Anwendungsbereich kann mehrere Informationsverbünde enthalten (Kapitel 3.1).
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. Einige Aufnahmen zeigen den Stand vom 28.10.2026.
Weitere Funktionen sind bereits umgesetzt: alle Funktionen nach den fünf Prozessschritten, Dienstleister und Lieferkette und was sonst noch in der Pre-Alpha steckt.
Geschrieben von Xhoan Qazimi, BlueProceedings, zuletzt am 01.11.2026 mit den Quellen abgeglichen. Die Funktionsbeschreibung gibt den Stand der Pre-Alpha wieder; methodische Aussagen sind als solche benannt und belegt.
Die Beiträge Schritt 1: Erhebung und Planung und Prozessschritt 1 im Detail zeigen die Teilschritte als Folien. Die Testphase ist ab dem 11.11.2026 geplant.