Grundschutz++ Umsetzungsleitfaden

Diese Seite ist derzeit noch ein Entwurf. Weitere Informationen sowie Diskussionen über Änderungen an diesem Entwurf gibt es evtl. auf der Diskussion-Seite.

---

Der Leitfaden soll Organisationen mit begrenzter ISMS‑Erfahrung dabei unterstützen, ein ISMS nach Grundschutz++ neu aufzubauen – verständlich, praxisnah und Schritt für Schritt. Er übersetzt die noch recht abstrakte Grundschutz++‑Methodik in ein konkret anwendbares Vorgehen: von der Vorbereitung und Kontextanalyse über Erhebung und Planung, Anforderungsanalyse und Realisierung bis hin zu Überwachung und kontinuierlicher Verbesserung.

Einleitung und Ziel des Leitfadens

Dieser Leitfaden unterstützt Organisationen dabei, ein ISMS nach Grundschutz++ praxisnah und verständlich aufzubauen. Er richtet sich vor allem an Einsteigerinnen und Einsteiger, die bisher mit IT-Grundschutz, ISO 27001 oder anderen Methodiken gearbeitet haben oder erstmals ein Informationssicherheitsmanagement aufbauen möchten.

Der Leitfaden soll den Aufbau nicht nur fachlich beschreiben, sondern als konkrete Schritt-für-Schritt-Anleitung nutzbar machen. Im Mittelpunkt steht deshalb nicht eine theoretische Gesamtdarstellung, sondern eine praktische Orientierung für die Einführung, Strukturierung und Pflege eines ISMS nach Grundschutz++.

Dieser Leitfaden richtet sich ausdrücklich an alle, die ein neues ISMS aufbauen möchten!

Für alle die einen Umstieg vom klassischen IT-Grundschutz-Kompendium zu Grundschutz++ planen gibt es einen speziellen Leitfaden Migration von IT-Grundschutz zu Grundschutz++.

Warum dieser Leitfaden

Grundschutz++ verfolgt einen modernen, stärker prozessorientierten Ansatz für Informationssicherheit. Für viele Organisationen ist diese Methodik jedoch noch nicht in allen Details vertraut, und die vorhandenen Unterlagen sind eher methodische Grundlagen als vollständige Umsetzungshilfen. Genau hier setzt der Leitfaden an: Er übersetzt die Methodik in eine handhabbare Praxisanleitung.

Ziel ist es, den Einstieg zu erleichtern, typische Unsicherheiten zu reduzieren und die einzelnen Schritte verständlich miteinander zu verbinden. Der Leitfaden soll dabei helfen, nicht nur die Methodik zu lesen, sondern sie im Alltag eines ISMS tatsächlich anzuwenden.

Zielgruppe

Der Leitfaden richtet sich an Personen, die ein ISMS aufbauen oder weiterentwickeln sollen und dafür eine klare Orientierung brauchen. Dazu gehören insbesondere Informationssicherheitsverantwortliche, ISB, Management, Projektleitungen und Personen, die an der Dokumentation oder Umsetzung beteiligt sind.

Er ist bewusst so aufgebaut, dass auch Personen mit grundlegenden Kenntnissen im ISMS-Bereich ihm folgen können. Fachbegriffe werden daher nicht vorausgesetzt, sondern im Verlauf des Leitfadens schrittweise eingeführt und in den praktischen Zusammenhang gestellt.

Was der Leitfaden leisten soll

Der Leitfaden soll erklären, wie ein ISMS nach Grundschutz++ strukturiert aufgebaut werden kann. Dazu beschreibt er die wichtigsten Vorbereitungen, die einzelnen Prozessschritte, die erforderlichen Ergebnisse und die typischen Entscheidungen, die im Verlauf zu treffen sind.

Außerdem soll er deutlich machen, wie sich Grundschutz++ von der bisherigen IT-Grundschutz-Methodik unterscheidet und worauf bei der praktischen Anwendung besonders zu achten ist. Der Leitfaden verfolgt damit das Ziel, methodische Einordnung und praktische Umsetzbarkeit miteinander zu verbinden.

Abgrenzung

Dieser Leitfaden ersetzt keine offizielle Methodik des BSI und keine verbindliche Referenzimplementierung. Er ist als praktische Arbeitshilfe gedacht, die vorhandene methodische Grundlagen verständlich aufbereitet und auf die konkrete Nutzung im Alltag eines ISMS ausrichtet.

Da Grundschutz++ noch nicht in allen Punkten vollständig ausformuliert ist, enthält der Leitfaden dort, wo notwendig, auch pragmatische Annahmen und Arbeitshilfen. Diese sollen nicht als abschließende Wahrheit verstanden werden, sondern als Orientierung für einen sicheren und nachvollziehbaren Einstieg.

Weitere Praxishilfen:

Grundschutz++ Einführung und Aufbau

BSI Leitfaden zur Grundschutz++-Methodik

Grundlagen von Grundschutz++ Grundidee und Zielsetzung der Methodik

Grundschutz++ ist als moderne Weiterentwicklung des IT-Grundschutzes gedacht und soll den Aufbau und den Betrieb eines ISMS stärker strukturieren, stärker standardisieren und zugleich besser maschinenlesbar machen. Im Mittelpunkt steht nicht mehr nur die Frage, welche Bausteine auf welche Systeme angewendet werden, sondern wie Sicherheitsanforderungen systematisch aus dem organisatorischen Kontext, den Geschäftsprozessen, den Assets und den zugehörigen Zielobjektkategorien abgeleitet werden können. Dadurch soll Informationssicherheit nicht nur dokumentiert, sondern auch konsistenter, wiederverwendbarer und langfristig besser pflegbar werden.

Grundschutz++ ist nicht nur ein rein technisches Datenmodell. Die Methodik dient vor allem dazu, ein ISMS nachvollziehbar aufzubauen, Anforderungen sauber zuzuordnen und Sicherheitsmaßnahmen über den gesamten Lebenszyklus hinweg steuerbar zu machen. Der Nutzen liegt damit sowohl in der methodischen Klarheit als auch in der besseren Eignung für digitale Werkzeuge und strukturierte Nachweise.

Der PDCA-Zyklus im Grundschutz++

Wie der klassische ISMS-Ansatz folgt auch Grundschutz++ dem PDCA-Prinzip: Plan, Do, Check, Act. Neu ist dabei vor allem, dass die Prozessschritte methodisch deutlicher voneinander abgegrenzt und enger an eine strukturierte Anforderungsmodellierung gekoppelt werden. Planung, Umsetzung, Überwachung und Verbesserung werden dadurch als zusammenhängender Kreislauf sichtbar, nicht als lose Folge einzelner Aktivitäten.

Für die praktische Arbeit bedeutet das: Ein ISMS nach Grundschutz++ ist kein einmalig erstelltes Dokument, sondern ein fortlaufend gepflegtes Managementsystem. Jede Änderung am Kontext, an Anforderungen, an Geschäftsprozessen oder an der Sicherheitslage kann Rückwirkungen auf die Modellierung haben. Deshalb muss der Prozess so aufgebaut werden, dass Aktualisierungen nicht als Ausnahme, sondern als normaler Bestandteil des Betriebs verstanden werden.

Die fünf Prozessschritte

Grundschutz++ beschreibt den Sicherheitsprozess über fünf aufeinander aufbauende Prozessschritte:

1. Erhebung und Planung
2. Anforderungsanalyse
3. Realisierung
4. Überwachung
5. kontinuierliche Verbesserung

Diese Struktur ist für Einsteiger besonders hilfreich, weil sie den Weg von der organisatorischen Grundlage bis zur laufenden Weiterentwicklung nachvollziehbar macht. Jeder Schritt liefert Ergebnisse, die in den nächsten Schritt übergehen und dort weiterverarbeitet werden.

Im Unterschied zu älteren, stärker bausteinorientierten Vorgehensweisen liegt der Schwerpunkt hier stärker auf der Modellierung des Gesamtzusammenhangs. Das heißt: Erst wird der Rahmen geklärt, dann werden Anforderungen systematisch abgeleitet, anschließend umgesetzt und schließlich überprüft und verbessert. Für die Praxis ist diese Reihenfolge wichtig, weil sie verhindert, dass Maßnahmen ohne ausreichenden organisatorischen und fachlichen Kontext eingeführt werden.

Begriffe und Rollen

Damit Grundschutz++ verständlich und anwendbar bleibt, müssen die wichtigsten Begriffe sauber voneinander getrennt werden. Dazu gehören insbesondere Kontext, Geltungsbereich, Informationsverbund, Geschäftsprozess, Asset, Zielobjektkategorie, Anforderung, Praktik und Sicherheitsniveau. Gerade für Einsteiger ist es entscheidend, diese Begriffe nicht nur theoretisch zu kennen, sondern in ihrer praktischen Rolle im Vorgehen zu verstehen.

Ebenso wichtig sind die Rollen im ISMS. Grundschutz++ betont, dass Informationssicherheit eine Führungsaufgabe ist und nicht nur auf Arbeitsebene entstehen darf. Deshalb müssen Zuständigkeiten, Freigaben, Verantwortlichkeiten und Stellvertretungen früh festgelegt werden. Wichtig ist, dass die Rollen nicht nur benannt sind, sondern auch mit konkreten Aufgaben, Kompetenzen und Nachweisen verbunden werden.

Was sich gegenüber IT-Grundschutz verändert

Gegenüber dem bisherigen IT-Grundschutz verschiebt sich der Schwerpunkt von festen Bausteinstrukturen hin zu einer flexibleren, prozessorientierten und stärker modellierten Vorgehensweise. Statt primär mit Bausteinen, Schutzbedarf und klassischen Zuordnungslisten zu arbeiten, sollen Anforderungen in Grundschutz++ über Praktiken, Zielobjektkategorien und strukturierte Datenmodelle abgebildet werden. Das Ziel ist eine bessere Skalierbarkeit und eine klarere Trennung zwischen fachlicher Anforderung, technischer Ausprägung und organisatorischer Zuständigkeit.

Für die Praxis bedeutet das auch: Es reicht nicht, bestehende Inhalte einfach nur umzubenennen. Wer ein ISMS neu aufbaut, muss von Anfang an in Grundschutz++-Logik denken, also prozessorientiert, strukturiert und nachvollziehbar modellieren. Gleichzeitig bleibt aber die inhaltliche Grundidee ähnlich: Informationssicherheit wird systematisch geplant, umgesetzt, überwacht und verbessert.

Vorbereitung

Für den Aufbau deines ISMS ist dieses Kapitel besonders wichtig, weil es die Grundlage für alle späteren Schritte schafft. Wer hier sorgfältig arbeitet, vermeidet viele typische Probleme in den nachfolgenden Prozessschritten.

Zielbild und Projektauftrag festlegen

Bevor mit dem Aufbau eines ISMS nach Grundschutz++ begonnen wird, sollte die Organisation ein klares Zielbild formulieren. Dabei ist festzulegen, warum das ISMS aufgebaut wird, welchen Schutz es leisten soll und welchen Reifegrad die Organisation mittelfristig erreichen möchte. Das Zielbild sollte nicht nur abstrakt formuliert sein, sondern konkrete Erwartungen enthalten, etwa zur Auditierbarkeit, zur Verantwortungsverteilung, zur Dokumentation und zur künftigen Nutzbarkeit von Grundschutz++ im Regelbetrieb.

Aus diesem Zielbild wird der Projektauftrag abgeleitet. Dieser sollte den Zweck des Vorhabens, den groben Umfang, die angestrebten Ergebnisse und die wesentlichen Erfolgsfaktoren beschreiben. Für Einsteiger ist wichtig, dass der Projektauftrag nicht mit einer Detailplanung verwechselt wird: Er schafft zunächst nur den verbindlichen Rahmen, innerhalb dessen das ISMS aufgebaut wird.

Ausgangslage der Organisation bewerten

Für einen sinnvollen Neuaufbau muss zunächst die Ausgangslage der Organisation verstanden werden. Dazu gehört die Frage, welche Strukturen, Prozesse, Rollen und Dokumente bereits vorhanden sind und welche davon für den Aufbau eines ISMS nutzbar sind. Selbst wenn noch kein formal aufgebautes ISMS existiert, gibt es meist bereits Elemente wie Organisationshandbücher, Verfahrensanweisungen, Verzeichnisse, technische Dokumentation oder Verantwortlichkeitsmodelle, die als Grundlage dienen können.

Die Bewertung der Ausgangslage sollte sowohl organisatorische als auch technische Aspekte berücksichtigen. Besonders wichtig ist, ob bereits ein Bewusstsein für Informationssicherheit vorhanden ist, ob die Leitung eingebunden ist und ob grundlegende Managementprozesse überhaupt etabliert sind. Je realistischer die Ausgangslage eingeschätzt wird, desto besser kann der Neuaufbau geplant werden.

Reifegrad und Rahmenbedingungen erfassen

Ein ISMS lässt sich nur dann sinnvoll aufbauen, wenn die Organisation weiß, auf welchem Reifegrad sie sich befindet. Der Reifegrad betrifft nicht nur die vorhandenen Sicherheitsmaßnahmen, sondern auch die Fähigkeit, Prozesse zu steuern, Nachweise zu führen, Verantwortlichkeiten zu regeln und Verbesserungen systematisch umzusetzen. Ein niedriger Reifegrad bedeutet nicht, dass ein Aufbau nicht möglich ist, aber er beeinflusst die Reihenfolge und den Umfang der ersten Schritte.

Zu den Rahmenbedingungen gehören außerdem rechtliche, vertragliche und organisatorische Vorgaben. Dazu zählen etwa gesetzliche Pflichten, branchenspezifische Anforderungen, interne Vorgaben, externe Verpflichtungen und vorhandene Ressourcen. Für einen Neuaufbau ist besonders relevant, welche Vorgaben von Anfang an berücksichtigt werden müssen und wo eine spätere Vertiefung möglich ist.

Audit- und Zertifizierungsziele klären

Wenn ein ISMS nach Grundschutz++ aufgebaut wird, muss früh entschieden werden, ob und in welcher Form Audits oder Zertifizierungen vorgesehen sind. Diese Entscheidung beeinflusst die gesamte Ausgestaltung des ISMS, weil sie Anforderungen an Dokumentation, Nachweisführung, Verbindlichkeit und Kontinuität mit sich bringt. Wer auditierbar arbeiten will, muss von Beginn an strukturierter und strenger dokumentieren als jemand, der zunächst nur intern ein Sicherheitsmanagement etablieren möchte.

Auch die zeitliche Perspektive ist wichtig. Falls eine Zertifizierung mittelfristig angestrebt wird, sollte der Neuaufbau so gestaltet werden, dass spätere Nachweise nicht nachträglich mühsam ergänzt werden müssen. Die Frage nach Auditierbarkeit ist deshalb kein spätes Detail, sondern ein zentrales Planungskriterium.

Ressourcen, Rollen und Verantwortlichkeiten bestimmen

Der Aufbau eines ISMS ist ohne klare Zuständigkeiten nicht praktikabel. Deshalb müssen früh die Rollen definiert werden, die den Neuaufbau fachlich, organisatorisch und operativ tragen. Dazu gehören insbesondere die Leitungsebene, die koordinierende Sicherheitsfunktion, die fachlich verantwortlichen Stellen sowie gegebenenfalls ergänzende Rollen für Betrieb, Datenschutz, Risiko und Dokumentation.

Neben den Rollen ist auch die Verfügbarkeit von Ressourcen zu klären. Dazu zählen Zeit, Personal, Fachwissen, Budget und gegebenenfalls externe Unterstützung. Gerade bei einem Neuaufbau wird oft unterschätzt, dass nicht nur die Erstgestaltung, sondern auch die spätere Pflege und Weiterentwicklung personelle Kapazitäten erfordern. Ein ISMS ist nur dann tragfähig, wenn die Organisation die gewählten Rollen auch tatsächlich mit Leben füllen kann.

Vorgehensmodell und Zeitplan festlegen

Ein Neuaufbau sollte in klaren, überschaubaren Schritten erfolgen. Es ist sinnvoll, die Einführung nicht als einmaliges Großprojekt zu verstehen, sondern als strukturierte Aufbauphase mit definierten Etappen. Dazu gehört zunächst der organisatorische Rahmen, dann die inhaltliche Modellierung und schließlich die Umsetzung und laufende Pflege. Für Einsteiger ist eine stufenweise Vorgehensweise in der Regel deutlich hilfreicher als ein sofortiger Vollausbau.

Der Zeitplan sollte realistisch sein und die verfügbaren Ressourcen berücksichtigen. Außerdem muss er ausreichend Puffer für Abstimmungen, Korrekturen und Priorisierungen enthalten. Ein gutes Vorgehensmodell verhindert, dass der Aufbau des ISMS zu früh in technische Detailfragen abgleitet, bevor die Grundstruktur geklärt ist.

Werkzeuge, Dokumentationsform und Arbeitsweise auswählen

Bereits in der Vorbereitungsphase sollte entschieden werden, wie das ISMS dokumentiert und verwaltet wird. Dabei geht es nicht nur um konkrete Werkzeuge, sondern auch um die grundsätzliche Arbeitsweise: eher dokumentenbasiert, datenstrukturiert oder werkzeuggestützt. Für Grundschutz++ ist es sinnvoll, von Anfang an auf eine strukturierte und möglichst konsistente Dokumentation zu achten, damit Anforderungen, Rollen, Zielobjekte und Nachweise später gut gepflegt werden können.

Wichtig ist außerdem, dass die gewählte Arbeitsweise zur Organisation passt. Eine kleine Organisation benötigt andere Hilfsmittel als eine große Organisation mit mehreren Fachbereichen und komplexen Abhängigkeiten.

Ergebnis der Vorbereitung

Am Ende der Vorbereitungsphase sollte die Organisation ein belastbares Fundament für den eigentlichen Aufbau des ISMS haben. Dazu gehören ein klar formuliertes Zielbild, ein definierter Projektauftrag, eine realistische Einschätzung der Ausgangslage, geklärte Rahmenbedingungen, benannte Rollen und ein grober Umsetzungsplan. Erst auf dieser Basis kann der eigentliche Aufbau nach Grundschutz++ sinnvoll beginnen.

Schritt 1: Erhebung und Planung

Dieser Schritt legt das Fundament für das gesamte ISMS nach Grundschutz++. Hier wird geklärt, in welchem organisatorischen, rechtlichen und fachlichen Umfeld das ISMS aufgebaut wird, welche Anforderungen zu berücksichtigen sind und wie der Rahmen für den späteren Betrieb aussehen soll. Dieser Schritt ist besonders wichtig, weil hier die Qualität der späteren Modellierung und Umsetzung entscheidend vorbereitet wird.

Kontext der Organisation erfassen

Zunächst muss die Organisation verstehen, in welchem Umfeld das ISMS arbeiten soll. Dazu gehören interne Faktoren wie Aufbauorganisation, Zuständigkeiten, vorhandene Prozesse, technische Landschaft, Kultur und Reifegrad ebenso wie externe Faktoren wie Gesetze, Marktbedingungen, Kundenanforderungen, Lieferantenabhängigkeiten und sicherheitsrelevante Entwicklungen. Der Kontext ist deshalb mehr als eine formale Vorübung; er bestimmt, welche Anforderungen überhaupt relevant sind und wo die Organisation besondere Risiken oder Abhängigkeiten hat.

Für einen praxistauglichen Einstieg genügt es nicht, den Kontext allgemein zu beschreiben. Es sollte konkret festgehalten werden, welche organisatorischen Bereiche betroffen sind, welche kritischen Dienstleistungen oder Geschäftsprozesse existieren und welche besonderen Rahmenbedingungen beachtet werden müssen. Je klarer dieser Überblick ist, desto einfacher lassen sich spätere Entscheidungen zu Scope, Schutzbedarf und Maßnahmen begründen.

Gesetzliche, vertragliche und interne Anforderungen identifizieren

Im nächsten Schritt werden alle Anforderungen gesammelt, die das ISMS beeinflussen. Dazu gehören gesetzliche Vorgaben, regulatorische Anforderungen, vertragliche Verpflichtungen, interne Richtlinien und fachliche Vorgaben aus der Organisation selbst. Wichtig ist dabei, nicht nur Sicherheitsgesetze im engeren Sinn zu betrachten, sondern auch Pflichten, die sich mittelbar auf Informationssicherheit auswirken, etwa aus Datenschutz, Aufbewahrung, Verfügbarkeit, Nachweisführung oder Lieferantenbeziehungen.

Für die praktische Arbeit ist es hilfreich, diese Anforderungen früh in einer einfachen Struktur zu erfassen: Was gilt, woher kommt die Anforderung, für welchen Bereich ist sie relevant und welche Konsequenz hat sie für das ISMS? So entsteht eine belastbare Grundlage für spätere Entscheidungen. Gerade Einsteiger profitieren davon, wenn Anforderungen nicht nur gesammelt, sondern direkt grob eingeordnet werden.

Weitere Praxishilfen:

• Meldepflichten

Interessierte Parteien und ihre Erwartungen bestimmen

Ein ISMS muss nicht nur auf Vorschriften reagieren, sondern auch auf die Erwartungen derjenigen, die von Informationssicherheit betroffen sind oder ein berechtigtes Interesse daran haben. Dazu gehören beispielsweise Leitung, Mitarbeitende, Kunden, Partner, Aufsichtsstellen, Dienstleister oder andere Betroffene. Im Grundschutz++-Verständnis ist diese Betrachtung wichtig, weil Sicherheitsziele und organisatorische Entscheidungen nicht losgelöst vom Umfeld getroffen werden dürfen.

Die Erwartungen der interessierten Parteien sollten möglichst konkret beschrieben werden. Es reicht nicht aus, allgemein festzustellen, dass „Sicherheit wichtig ist“. Vielmehr sollte erfasst werden, was die jeweilige Partei tatsächlich erwartet, etwa Verfügbarkeit, Vertraulichkeit, Nachvollziehbarkeit, schnelle Reaktionsfähigkeit oder klare Zuständigkeiten. Es ist entscheidend, dass diese Erwartungen später mit den Sicherheitszielen der Organisation abgeglichen werden können.

Informationssicherheitsleitlinie erstellen

Die Informationssicherheitsleitlinie ist das grundlegende Steuerungsdokument des ISMS. Sie beschreibt, warum Informationssicherheit für die Organisation wichtig ist, welche Ziele verfolgt werden und welche Grundsätze die Arbeit prägen. Sie sollte die Verantwortung der Leitung, die grundsätzliche Sicherheitsstrategie, den Willen zur kontinuierlichen Verbesserung und die Verbindung zum organisatorischen Kontext deutlich machen.

Für Einsteiger ist wichtig, dass die Leitlinie nicht zu umfangreich sein muss, aber klar und verbindlich formuliert sein sollte. Sie soll Orientierung geben und nicht in Detailregelungen abdriften. Eine gute Leitlinie ist verständlich, freigegeben und kommunizierbar. Wenn sie nur formal existiert, aber im Alltag keine Rolle spielt, verliert sie ihren Zweck.

Weitere Praxishilfen:

• Leitlinie zur Informationssicherheit
• Strategie zur Informationssicherheit
• Meldepflichten

Geltungsbereich des ISMS festlegen

Der Geltungsbereich oder Scope legt fest, welche Teile der Organisation vom ISMS erfasst werden. Das ist einer der wichtigsten Schritte, weil davon alle weiteren Betrachtungen abhängen. Der Scope sollte so definiert sein, dass er fachlich sinnvoll, organisatorisch handhabbar und realistisch umsetzbar ist.

Für die praktische Anwendung bedeutet das: Nicht die gesamte Organisation muss zwingend gleichzeitig betrachtet werden, aber der gewählte Bereich muss sauber abgegrenzt sein. Dabei sollten Prozesse, Standorte, Systeme, organisatorische Einheiten und relevante Abhängigkeiten nachvollziehbar beschrieben werden. Ein guter Scope ist klar genug, um später modelliert und umgesetzt zu werden, aber nicht so kompliziert, dass er die Arbeit unnötig erschwert.

Informationssicherheitseinstufung der Geschäftsprozesse durchführen

Grundschutz++ setzt stärker auf die Betrachtung von Geschäftsprozessen als auf rein technische Einzelobjekte. Deshalb sollte im ersten Schritt ermittelt werden, welche Geschäftsprozesse besonders relevant sind und welches Sicherheitsniveau für sie erforderlich ist. Die Einstufung hilft dabei, Prioritäten zu setzen und die nächsten Schritte nicht über alle Bereiche gleich zu verteilen.

Welche Prozesse sind kritisch, welche haben mittlere Bedeutung und welche sind nachrangig? Welche Auswirkungen hätte ein Ausfall, eine Manipulation oder ein Informationsverlust? Diese Fragen helfen dabei, den späteren Modellierungsaufwand gezielt auf die wichtigsten Bereiche zu konzentrieren. Gerade für Einsteiger ist das wichtig, weil so ein realistischer Einstieg ohne Überforderung möglich wird.

Weitere Praxishilfen:

• Grundlagenartikel Geschäftsprozesse
• Grundschutz++ Schutzbedarf

Sicherheitsorganisation und Rollen aufbauen

Ein ISMS funktioniert nur dann dauerhaft, wenn Zuständigkeiten klar geregelt sind. Deshalb müssen früh die Rollen definiert werden, die für Steuerung, Umsetzung, Kontrolle und Freigabe zuständig sind. Dazu gehören insbesondere die Leitungsebene, die koordinierende Sicherheitsrolle, fachliche Verantwortliche und gegebenenfalls weitere unterstützende Rollen.

Für die Praxis ist hier entscheidend, dass Rollen nicht nur benannt, sondern mit Aufgaben, Kompetenzen und Stellvertretungen versehen werden. Eine gute Rollenverteilung verhindert Lücken, Doppelzuständigkeiten und unklare Freigaben. Rollenkonflikte müssen dabei erkannt und vermieden werden.

Weitere Praxishilfen:

• Benutzer und Rechteverwaltung
• Richtlinie Rollen und Berechtigungen

Dokumentation und Kommunikation sicherstellen

Schon in der Planungsphase muss festgelegt werden, wie Entscheidungen, Ergebnisse und Verantwortlichkeiten dokumentiert werden. Ohne eine gute Dokumentation lässt sich das ISMS später weder sauber betreiben noch nachvollziehbar weiterentwickeln. Gleichzeitig muss geregelt sein, wie Informationen im ISMS kommuniziert werden, damit die relevanten Personen rechtzeitig eingebunden sind.

Für die praktische Anwendung heißt das: Es sollte klar sein, welche Dokumente geführt werden, wo sie abgelegt werden, wer sie freigibt und wie Änderungen nachvollziehbar bleiben. Ebenso sollte die Organisation wissen, wie Ergebnisse aus dem ISMS an Leitung, Fachbereiche und beteiligte Stellen kommuniziert werden. Gute Kommunikation ist dabei kein Nebenpunkt, sondern eine Voraussetzung dafür, dass das ISMS akzeptiert und gelebt wird.

Weitere Praxishilfen:

• Grundlagen zum Dokumentenmanagement
• Richtlinie zur Lenkung von Dokumenten

Risikomanagement initialisieren

Am Ende dieses Schritts wird das Risikomanagement vorbereitet, damit es in den folgenden Prozessschritten wirksam eingesetzt werden kann. In Grundschutz++ ist das Risikomanagement nicht von der Methodik getrennt, sondern eng mit Planung, Anforderungsmodellierung und Umsetzung verbunden. Schon in der frühen Phase sollte daher klar sein, nach welchen Regeln Risiken betrachtet, bewertet und behandelt werden.

Wichtig ist vor allem, dass Risiken nicht erst am Ende des Aufbaus betrachtet werden, sondern bereits jetzt als fester Bestandteil des Vorgehens verstanden werden. Das schafft die Grundlage dafür, spätere Anforderungen, Ausnahmen und Maßnahmen nachvollziehbar zu begründen und nicht nur formal zu dokumentieren.

Weitere Praxishilfen:

• Risikomanagement nach BSI Standard 200-3
• Richtlinie zur Risikoanalyse

Ergebnis von Schritt 1

Am Ende dieses Schritts sollte die Organisation ein klares Bild vom eigenen Kontext, den relevanten Anforderungen, den interessierten Parteien, dem Geltungsbereich, den Sicherheitszielen, den Rollen und dem Umgang mit Risiken haben. Damit ist die organisatorische und fachliche Grundlage geschaffen, auf der die eigentliche Modellierung und Realisierung des ISMS aufbauen kann. Gerade für Einsteiger ist dieser Schritt deshalb entscheidend, weil hier die Richtung für das gesamte Projekt festgelegt wird.

5. Schritt 2: Anforderungsanalyse

In diesem Schritt wird aus dem organisatorischen Rahmen ein konkretes Anforderungspaket für das ISMS nach Grundschutz++ abgeleitet. Während Schritt 1 den Rahmen definiert, geht es hier darum, die relevanten Objekte, Prozesse und Anforderungen so zu modellieren, dass daraus ein belastbares Sicherheitskonzept entstehen kann. Für den Praxisleitfaden ist dieser Schritt besonders wichtig, weil hier aus abstrakten Vorgaben erstmals eine greifbare Arbeitsgrundlage wird.

5.1 Informationsverbund abgrenzen

Der Informationsverbund beschreibt den Teil der Organisation, für den das ISMS konkret aufgebaut wird. Er ist die fachliche und organisatorische Einheit, innerhalb derer Geschäftsprozesse, Assets, Zielobjekte und Anforderungen zusammen betrachtet werden. Eine klare Abgrenzung ist wichtig, damit das ISMS nicht zu groß, nicht zu vage und nicht unnötig kompliziert wird.

Für die Praxis sollte der Informationsverbund so abgegrenzt werden, dass er handhabbar bleibt und dennoch alle relevanten Elemente enthält. Dazu gehören die wichtigsten Prozesse, Systeme, Daten und unterstützenden Strukturen. Wenn der Verbund zu weit gefasst wird, wird die Modellierung schnell unübersichtlich; wenn er zu eng gefasst wird, entstehen Lücken und Abhängigkeiten außerhalb des betrachteten Bereichs.

5.2 Geschäftsprozesse und relevante Assets erfassen

Ausgangspunkt der Anforderungsanalyse sind die Geschäftsprozesse, die im definierten Informationsverbund relevant sind. Diese sollten nicht nur benannt, sondern hinsichtlich ihrer Bedeutung und Abhängigkeiten kurz beschrieben werden. Anschließend werden die dazugehörigen Assets erfasst, also die Objekte, die für den Betrieb dieser Prozesse notwendig sind oder von ihnen beeinflusst werden.

Für Einsteiger ist es hilfreich, hier zunächst mit den wichtigsten Prozessen zu beginnen und nicht sofort den gesamten Verbund vollständig modellieren zu wollen. Relevante Assets können beispielsweise Anwendungen, Systeme, Informationen, Räume, Kommunikationsverbindungen, Rollen oder Dienstleistungen sein. Entscheidend ist, dass die Erfassung nachvollziehbar ist und sich klar an den Geschäftsprozessen orientiert.

5.3 Zielobjektkategorien bestimmen

Zielobjektkategorien dienen dazu, Assets und Anforderungen strukturiert einzuordnen. Sie helfen dabei, ähnliche Objekte zusammenzufassen und Anforderungen nicht für jedes einzelne Objekt isoliert neu zu formulieren. Dadurch wird die Modellierung übersichtlicher und später leichter pflegbar.

Für die praktische Anwendung sollte die Organisation die Zielobjektkategorien so wählen, dass sie zum eigenen Betriebsmodell passen und die realen Strukturen gut abbilden. Dabei geht es nicht darum, möglichst viele Kategorien zu definieren, sondern die vorhandenen Objekte sinnvoll zu ordnen. Je klarer die Kategorien sind, desto besser lassen sich später Anforderungen zuordnen, vererben und auswerten.

5.4 Anforderungen aus Praktiken ableiten

In Grundschutz++ werden Anforderungen über Praktiken in den Blick genommen. Praktiken beschreiben dabei die inhaltliche Ebene, aus der sich konkrete Anforderungen für das ISMS ergeben. Für den Praxisleitfaden ist wichtig, dass diese Ableitung verständlich bleibt: Eine Praktik ist nicht nur ein abstrakter Begriff, sondern ein strukturierter Anforderungskern, aus dem sich konkrete Sicherheitsanforderungen ergeben.

Die Anforderungen sollten nicht isoliert gelesen werden, sondern immer im Zusammenhang mit dem jeweiligen Prozess und dem jeweiligen Zielobjekt. So wird vermieden, dass Anforderungen zwar formal vorhanden sind, aber im Alltag niemand ihre Bedeutung erkennt. Für Einsteiger ist deshalb hilfreich, jede Anforderung mit einer kurzen fachlichen Einordnung zu versehen.

5.5 Anforderungen auf Zielobjekte und Kategorien verknüpfen

Nachdem die Anforderungen abgeleitet wurden, müssen sie mit den passenden Zielobjekten und Zielobjektkategorien verknüpft werden. Genau an dieser Stelle entsteht die praktische Nutzbarkeit der Grundschutz++-Modellierung. Nur wenn klar ist, welche Anforderung zu welchem Objekt gehört, kann später sinnvoll umgesetzt, geprüft und nachverfolgt werden.

Für die Praxis sollte diese Verknüpfung so einfach und eindeutig wie möglich erfolgen. Wenn eine Anforderung für mehrere Objekte gilt, sollte das erkennbar sein, ohne dass sie mehrfach unübersichtlich dupliziert werden muss. Der Leitfaden sollte hier besonders betonen, dass gute Verknüpfung nicht nur Dokumentation bedeutet, sondern die spätere Pflege deutlich erleichtert.

5.6 Anforderungspaket konsolidieren

Nach der Zuordnung werden die Anforderungen zusammengeführt und geprüft. Ziel ist es, Dubletten, Überschneidungen und unklare Formulierungen zu erkennen. Gerade bei einem neu aufgebauten ISMS ist dieser Schritt wichtig, weil sich sonst leicht mehrere ähnliche Anforderungen nebeneinander entwickeln, die später schwer zu pflegen sind.

Die Konsolidierung sollte daher nicht nur technisch, sondern auch fachlich erfolgen. Fragen wie „Ist diese Anforderung bereits anderweitig abgedeckt?“, „Ist sie für mehrere Zielobjekte identisch?“ oder „Kann sie verallgemeinert werden?“ helfen dabei, das Paket übersichtlich zu halten. Für Einsteiger ist es oft besser, ein kompaktes und klar strukturiertes Anforderungspaket zu haben als ein umfangreiches, aber unübersichtliches Sammelwerk.

5.7 Zusätzliche Anforderungen aus externen Verpflichtungen berücksichtigen

Nicht alle Anforderungen ergeben sich unmittelbar aus der Grundschutz++-Methodik. Hinzu kommen externe Verpflichtungen, etwa aus Gesetzen, Verträgen, regulatorischen Vorgaben oder Kundenanforderungen. Diese müssen in das Anforderungspaket integriert werden, wenn sie für den betrachteten Informationsverbund relevant sind.

Für die Praxis ist es sinnvoll, diese zusätzlichen Anforderungen gesondert zu markieren und nicht mit den methodischen Grundanforderungen zu vermischen. So bleibt nachvollziehbar, woher eine Anforderung stammt und warum sie berücksichtigt wurde. Das ist besonders wichtig, wenn später Fragen zur Nachweisführung oder zur Priorisierung auftreten.

5.8 Risikobetrachtung für ergänzende Anforderungen durchführen

Sobald Anforderungen über den methodischen Standard hinausgehen oder zusätzliche Verpflichtungen entstehen, ist eine Risikobetrachtung notwendig. Das gilt insbesondere für Anforderungen, die nicht direkt aus dem Standardbild abgeleitet wurden oder für die eine besondere Schutzbedürftigkeit vorliegt. Die Risikobetrachtung hilft dabei, zu begründen, warum bestimmte Maßnahmen erforderlich sind oder warum von einer Standardlösung abgewichen wird.

Für den Leitfaden sollte dieser Schritt einfach erklärt werden: Nicht jede Zusatzanforderung muss gleich mit hoher Komplexität behandelt werden, aber sie sollte immer bewusst bewertet werden. Entscheidend ist, dass nachvollziehbar bleibt, welches Risiko mit einer Ergänzung verbunden ist und wie die Organisation darauf reagiert. So wird verhindert, dass Zusatzanforderungen nur aus Gewohnheit übernommen werden, ohne ihren Nutzen zu prüfen.

5.9 Sicherheitsniveau und Gestaltungsentscheidungen festlegen

Am Ende der Anforderungsanalyse muss entschieden werden, welches Sicherheitsniveau für den Informationsverbund gelten soll und welche Gestaltungsentscheidungen daraus folgen. Dazu gehört etwa, ob Anforderungen im normalen Niveau ausreichen oder ob für bestimmte Bereiche ein erhöhtes Sicherheitsniveau erforderlich ist. Ebenso müssen Zuständigkeiten, Prioritäten und gegebenenfalls Parameter festgelegt werden, die die spätere Umsetzung beeinflussen.

Für die Praxis ist wichtig, dass diese Entscheidung nicht rein formal getroffen wird. Sie sollte die Bedeutung der Geschäftsprozesse, die Risiken, die vorhandenen Ressourcen und die organisatorischen Rahmenbedingungen berücksichtigen. Der Leitfaden sollte deshalb klar machen, dass das Sicherheitsniveau nicht nur ein Etikett ist, sondern eine Steuerungsentscheidung mit direkten Auswirkungen auf die weitere Realisierung.

Ergebnis von Schritt 2

Am Ende dieses Schritts sollte ein belastbares, konsolidiertes und nachvollziehbar strukturiertes Anforderungspaket vorliegen. Es verbindet Geschäftsprozesse, Assets, Zielobjektkategorien, methodische Anforderungen und zusätzliche Verpflichtungen zu einer Grundlage, auf der die spätere Umsetzung aufbauen kann. Für Einsteiger ist dies der Punkt, an dem aus der Planung erstmals ein konkret nutzbares Sicherheitsmodell entsteht.

6. Schritt 3: Realisierung

In diesem Schritt wird das zuvor erarbeitete Anforderungspaket in konkrete Maßnahmen und organisatorische Umsetzung überführt. Für den Praxisleitfaden ist das der Punkt, an dem aus Planung und Modellierung tatsächliche Sicherheitsarbeit wird. Entscheidend ist dabei, dass die Umsetzung nicht unsystematisch erfolgt, sondern nachvollziehbar priorisiert, gesteuert und dokumentiert wird.

6.1 Umsetzungsstatus erfassen

Zunächst muss erfasst werden, welche Anforderungen bereits erfüllt sind und welche noch offen sind. Dazu wird jede Anforderung darauf geprüft, ob sie bereits umgesetzt, teilweise umgesetzt oder noch nicht umgesetzt ist. Diese Bestandsaufnahme ist wichtig, weil nur so sichtbar wird, wo die Organisation bereits gut aufgestellt ist und wo noch Handlungsbedarf besteht.

Für die Praxis sollte dieser Schritt möglichst einfach und einheitlich durchgeführt werden. Es genügt nicht, pauschal festzustellen, dass „vieles schon erledigt“ ist. Vielmehr sollte zu jeder Anforderung ein klarer Status vorliegen, damit später Entscheidungen auf einer belastbaren Grundlage getroffen werden können.

6.2 Fehlende Anforderungen bewerten

Nicht umgesetzte Anforderungen dürfen nicht nur als Lücke betrachtet werden, sondern müssen fachlich bewertet werden. Dabei ist zu klären, welche Bedeutung die fehlende Umsetzung für den Schutz der Geschäftsprozesse, der Informationen und der Organisation hat. Nicht jede Abweichung ist gleich kritisch, aber jede muss bewusst eingeordnet werden.

Für Anwendende mit mäßiger ISMS-Erfahrung ist es hilfreich, die Bewertung pragmatisch zu halten. Die zentrale Frage lautet: Welche Auswirkungen hätte es, wenn diese Anforderung vorerst nicht umgesetzt wird? Diese Einschätzung schafft die Grundlage für Priorisierung und Umsetzungsplanung.

6.3 Maßnahmen priorisieren

Aus der Bewertung fehlender Anforderungen ergibt sich die Reihenfolge der Umsetzung. Maßnahmen sollten nicht zufällig oder nur nach Aufwand ausgewählt werden, sondern nach fachlicher Bedeutung, Risiko, Abhängigkeiten und Machbarkeit. Besonders wichtige oder sicherheitskritische Maßnahmen müssen früh behandelt werden.

Für den Leitfaden ist es sinnvoll, hier eine einfache Priorisierungslogik zu verwenden. Typische Kriterien sind zum Beispiel Schutzwirkung, kritische Geschäftsprozesse, rechtlicher Druck, Aufwand und notwendige Vorarbeiten. So entsteht eine Reihenfolge, die nicht nur praktisch umsetzbar, sondern auch begründbar ist.

6.4 Umsetzungsplan erstellen

Die priorisierten Maßnahmen werden anschließend in einen Umsetzungsplan überführt. Dieser Plan sollte so aufgebaut sein, dass klar erkennbar ist, was umgesetzt werden soll, warum es umgesetzt werden soll und in welcher Reihenfolge dies geschieht. Ein guter Umsetzungsplan ist damit nicht nur ein Arbeitsdokument, sondern auch ein Steuerungsinstrument für das ISMS.

Für die Praxis sollte der Plan nicht unnötig komplex sein. Wichtig ist vor allem, dass die offenen Punkte vollständig erfasst sind und die Organisation jederzeit den Überblick behält. Je einfacher und klarer der Plan aufgebaut ist, desto besser lässt er sich im Alltag nutzen.

6.5 Zuständigkeiten und Fristen festlegen

Jede Maßnahme braucht eine verantwortliche Person oder Stelle. Ohne klare Zuständigkeit bleibt Umsetzung oft unvollständig oder verzögert sich. Deshalb muss für jede Maßnahme festgelegt werden, wer sie fachlich verantwortet, wer sie umsetzt und wer die Freigabe oder Kontrolle übernimmt.

Ebenso wichtig sind realistische Fristen. Diese sollten weder zu kurz noch zu unbestimmt sein. Für den Leitfaden ist wichtig, dass Zuständigkeiten und Fristen nicht nur formal eingetragen werden, sondern tatsächlich als Verbindlichkeit für die weitere Arbeit dienen.

6.6 Ausnahmen behandeln und freigeben

Nicht jede Anforderung kann sofort umgesetzt werden. In solchen Fällen braucht die Organisation einen geregelten Umgang mit Ausnahmen. Eine Ausnahme sollte immer begründet, dokumentiert und von einer zuständigen Stelle freigegeben werden. So bleibt nachvollziehbar, warum eine Anforderung vorübergehend nicht erfüllt wird.

Für die Praxis ist entscheidend, dass Ausnahmen nicht stillschweigend akzeptiert werden. Sie sollen bewusst behandelt werden und idealerweise mit einer zeitlichen Perspektive versehen sein. Der Leitfaden sollte hier klar machen, dass Ausnahmen kein Ersatz für Umsetzung sind, sondern eine kontrollierte Übergangslösung.

6.7 Umsetzung nachverfolgen

Nach der Planung beginnt die eigentliche Nachverfolgung der Maßnahmen. Dabei wird geprüft, ob vereinbarte Schritte tatsächlich umgesetzt wurden und ob der Fortschritt dem Plan entspricht. Diese Nachverfolgung ist wichtig, weil ein Plan allein noch keine Sicherheit schafft.

Für Einsteiger sollte dieser Punkt einfach erklärt werden: Eine Maßnahme ist erst dann erledigt, wenn sie tatsächlich umgesetzt und dokumentiert wurde. Dazwischen kann es Rückfragen, Verzögerungen oder Anpassungen geben. Deshalb braucht die Organisation eine laufende Übersicht, die den Umsetzungsstand sichtbar macht.

6.8 Compliance in der Umsetzung sichern

Auch während der Umsetzung muss sichergestellt werden, dass gesetzliche, vertragliche und interne Vorgaben eingehalten werden. Maßnahmen dürfen nicht nur technisch funktionieren, sondern müssen auch regelkonform und organisatorisch sauber umgesetzt werden. Gerade bei sicherheitsrelevanten Änderungen ist das wichtig, weil sonst neue Risiken oder Regelverstöße entstehen können.

Für den Praxisleitfaden bedeutet das: Umsetzung ist nie nur eine technische Aufgabe. Sie muss immer auch im Hinblick auf Freigaben, Dokumentation, Nachvollziehbarkeit und Verbindlichkeit betrachtet werden. Nur so bleibt das ISMS nicht nur wirksam, sondern auch auditierbar und anschlussfähig.

Ergebnis von Schritt 3

Am Ende dieses Schritts sollte ein klar gesteuerter Umsetzungsprozess vorliegen, in dem offene Anforderungen bewertet, priorisiert, geplant, verantwortet und nachverfolgt werden. Zusätzlich müssen Ausnahmen sauber geregelt und Compliance-Aspekte berücksichtigt sein. Für Einsteiger ist dieser Schritt besonders wichtig, weil hier aus der Modellierung eine gelebte Sicherheitsarbeit wird.

7. Schritt 4: Überwachung

In diesem Schritt wird geprüft, ob das ISMS nach Grundschutz++ im Alltag tatsächlich wirksam ist. Für den Praxisleitfaden ist das besonders wichtig, weil ein ISMS nicht nur gut geplant und umgesetzt, sondern auch regelmäßig beobachtet, bewertet und bei Bedarf nachgesteuert werden muss. Überwachung ist damit kein Kontrollschritt am Rand, sondern ein zentrales Steuerungselement des gesamten Sicherheitsprozesses.

7.1 Leistungsbewertung des ISMS durchführen

Die Leistungsbewertung zeigt, ob das ISMS seine Ziele erreicht und ob die gewählten Maßnahmen im Alltag tragen. Dazu werden geeignete Kriterien betrachtet, zum Beispiel Umsetzungsstände, Fristen, Vorfälle, offene Abweichungen oder erkennbare Schwachstellen. Für den Einstieg sollte diese Bewertung einfach und nachvollziehbar bleiben, damit sie nicht zu einem rein formalen Bericht ohne praktische Aussagekraft wird.

Wichtig ist, die Leistungsbewertung nicht mit einer Detailprüfung einzelner Technikmaßnahmen zu verwechseln. Sie soll vielmehr ein Gesamtbild liefern: Ist das ISMS funktionsfähig, wird es gelebt und bewegt sich die Organisation in die gewünschte Richtung? Gerade für weniger erfahrene Anwendende ist diese Sicht hilfreich, weil sie den Fokus auf Steuerung statt auf reine Dokumentation lenkt.

7.2 Compliance überwachen

Im laufenden Betrieb muss überprüft werden, ob die Organisation weiterhin alle relevanten gesetzlichen, vertraglichen und internen Anforderungen erfüllt. Diese Überwachung ist notwendig, weil sich Rahmenbedingungen ändern können und neue Vorgaben hinzukommen können. Für den Leitfaden sollte deutlich werden, dass Compliance kein einmalig erledigter Prüfungspunkt ist, sondern fortlaufend begleitet werden muss.

Praktisch bedeutet das, dass die Organisation eine einfache, aber regelmäßige Kontrolle ihrer Verpflichtungen braucht. Dazu gehören zum Beispiel neue rechtliche Anforderungen, geänderte Verträge, interne Vorgaben oder Anpassungen im Geschäftsmodell. Wer diese Entwicklung nicht beobachtet, riskiert, dass das ISMS zwar formal besteht, aber inhaltlich nicht mehr aktuell ist.

7.3 Audits planen und durchführen

Audits dienen dazu, das ISMS unabhängig und systematisch zu überprüfen. Sie helfen dabei festzustellen, ob Vorgaben eingehalten werden, ob Prozesse funktionieren und ob die Dokumentation belastbar ist. Für den Praxisleitfaden sollte klar sein, dass Audits nicht nur zur Fehlerfindung da sind, sondern auch zur Verbesserung beitragen sollen.

Die Auditplanung sollte risikoorientiert und pragmatisch erfolgen. Nicht alles muss gleichzeitig geprüft werden, sondern vor allem die Bereiche, die für das ISMS besonders wichtig oder besonders kritisch sind. Ein gutes Audit ist für die Organisation verständlich, fair und nachvollziehbar und liefert konkrete Hinweise für Nachbesserungen.

7.4 Managementbewertung vorbereiten

Die Managementbewertung ist die Stelle, an der die Leitungsebene einen Überblick über die Lage des ISMS erhält und Entscheidungen für die Weiterentwicklung trifft. Sie sollte auf den Ergebnissen der Leistungsbewertung, der Compliance-Überwachung, der Audits und der offenen Maßnahmen aufbauen. Für den Leitfaden ist wichtig, dass diese Bewertung nicht als Formalie verstanden wird, sondern als Steuerungsinstrument.

Damit die Managementbewertung sinnvoll ist, müssen die relevanten Informationen verständlich aufbereitet werden. Die Leitung sollte auf einen Blick erkennen können, wo das ISMS steht, welche Risiken oder Schwächen sichtbar sind und welche Entscheidungen erforderlich werden. Je klarer diese Aufbereitung ist, desto besser kann das Management Verantwortung übernehmen.

7.5 Monitoring-Methoden und Werkzeuge einsetzen

Zur Überwachung können unterschiedliche Methoden und Werkzeuge eingesetzt werden, je nach Größe und Reife der Organisation. Das können einfache Statuslisten, regelmäßige Berichte, technische Überwachungswerkzeuge, Kennzahlenübersichten oder strukturierte Prüfformulare sein. Wichtig ist nicht das Werkzeug selbst, sondern dass es zur Organisation passt und brauchbare Informationen liefert.

Für Einsteiger ist meist ein schrittweiser Aufbau sinnvoll. Zunächst reicht oft eine überschaubare Form der Überwachung, die verlässlich durchgeführt werden kann. Erst wenn die Grundstruktur stabil ist, sollten weitere Auswertungen und Werkzeuge ergänzt werden. So bleibt die Überwachung handhabbar und entwickelt sich mit dem ISMS mit.

7.6 Anforderungen und Wirksamkeit validieren

Am Ende der Überwachung sollte geprüft werden, ob die Anforderungen nicht nur formal erfüllt wurden, sondern auch tatsächlich wirksam sind. Eine Anforderung, die auf dem Papier umgesetzt wurde, kann im Alltag trotzdem zu schwach, unpraktisch oder unvollständig sein. Deshalb ist die Wirksamkeitsprüfung ein wichtiger Bestandteil dieses Schritts.

Für die Praxis bedeutet das: Die Organisation sollte nicht nur fragen, ob etwas erledigt wurde, sondern ob es den gewünschten Schutz tatsächlich bringt. Diese Sichtweise ist besonders wertvoll, weil sie die Überwachung mit der Verbesserung verbindet. So wird aus der Kontrolle ein lernender Prozess.

8. Schritt 5: Kontinuierliche Verbesserung

Dieser Schritt sorgt dafür, dass das ISMS nach Grundschutz++ nicht stehen bleibt, sondern sich weiterentwickelt. Für den Praxisleitfaden ist das zentral, weil Informationssicherheit immer in Bewegung ist. Neue Risiken, neue Anforderungen, organisatorische Veränderungen oder Erkenntnisse aus Audits müssen in das ISMS zurückfließen.

8.1 Nicht-Konformitäten behandeln

Nicht-Konformitäten sind Abweichungen zwischen dem geplanten oder geforderten Zustand und der tatsächlichen Situation. Sie können aus Audits, Überwachung, Vorfällen oder internen Prüfungen hervorgehen. Wichtig ist, dass sie nicht ignoriert, sondern systematisch aufgenommen und bearbeitet werden.

Für den Einstieg sollte dieser Punkt einfach dargestellt werden: Wenn etwas nicht so funktioniert wie vorgesehen, muss die Abweichung benannt, bewertet und weiterverfolgt werden. Eine gute Behandlung von Nicht-Konformitäten verhindert, dass sich Schwächen dauerhaft festsetzen. Genau darin liegt ihr praktischer Wert.

8.2 Verbesserungspotenziale identifizieren

Verbesserungspotenziale sind nicht erst dann relevant, wenn etwas fehlerhaft ist. Oft zeigen sich aus der Praxis, aus Audits oder aus Rückmeldungen auch Möglichkeiten, Prozesse einfacher, klarer oder wirksamer zu machen. Für den Leitfaden ist wichtig, diese positive Perspektive sichtbar zu machen.

Eine Organisation sollte also nicht nur nach Mängeln suchen, sondern auch nach sinnvollen Verbesserungen. Das kann etwa eine bessere Rollenverteilung, eine klarere Dokumentation oder eine praxistauglichere Kontrolle sein. Gerade für Einsteiger ist dieser Gedanke hilfreich, weil er das ISMS als lernendes System verständlich macht.

8.3 Korrektur- und Verbesserungsmaßnahmen planen

Aus den festgestellten Abweichungen und Potenzialen müssen konkrete Maßnahmen abgeleitet werden. Diese sollten klar beschreiben, was geändert wird, warum die Änderung notwendig ist und wer dafür verantwortlich ist. Für den Praxisleitfaden ist wichtig, dass Maßnahmen nicht nur benannt, sondern auch priorisiert und in einen umsetzbaren Ablauf überführt werden.

Die Planung sollte so einfach wie möglich sein, aber dennoch verbindlich. Es reicht nicht, eine Verbesserung nur als Idee festzuhalten. Sie muss so beschrieben werden, dass daraus tatsächliches Handeln entstehen kann. Das ist ein zentraler Unterschied zwischen bloßer Erkenntnis und wirksamer Verbesserung.

8.4 Wirksamkeit der Maßnahmen prüfen

Nachdem eine Maßnahme umgesetzt wurde, muss geprüft werden, ob sie das gewünschte Ergebnis bringt. Das ist wichtig, weil eine Veränderung auf dem Papier noch keine tatsächliche Verbesserung bedeutet. Für den Leitfaden sollte klar sein, dass Verbesserungen erst dann abgeschlossen sind, wenn ihre Wirkung nachvollziehbar ist.

Diese Prüfung kann einfach gehalten sein, muss aber belastbar sein. Entscheidend ist, dass die Organisation erkennt, ob die Maßnahme die Abweichung tatsächlich behoben oder das ISMS spürbar gestärkt hat. Ohne diese Prüfung bleibt Verbesserung ein Behauptungspunkt statt eines methodischen Schritts.

8.5 Sicherheitsniveau bewerten

Die kontinuierliche Verbesserung sollte auch dazu genutzt werden, das erreichte Sicherheitsniveau neu einzuordnen. Die Organisation muss erkennen können, ob sie stabil auf dem gewünschten Niveau arbeitet, ob sich das Niveau verbessert hat oder ob neue Lücken entstanden sind. Für den Praxisleitfaden ist das wichtig, weil so der Fortschritt sichtbar wird.

Eine solche Bewertung sollte nicht überkomplex sein. Es genügt oft, wenn die Organisation regelmäßig erkennt, ob das ISMS robuster, klarer und wirksamer geworden ist. Damit wird die Verbesserung direkt mit dem Gesamtbild der Sicherheit verbunden.

8.6 Compliance-Verstöße behandeln

Wenn Anforderungen verletzt wurden, muss dies nicht nur als fachliches Problem, sondern auch als Compliance-Frage behandelt werden. Das betrifft insbesondere Verstöße gegen gesetzliche, vertragliche oder interne Vorgaben. Der Leitfaden sollte hier klar machen, dass solche Fälle besonders sorgfältig dokumentiert und bearbeitet werden müssen.

Für die Praxis bedeutet das: Compliance-Verstöße brauchen eine eindeutige Behandlung, eine klare Entscheidungslage und gegebenenfalls zusätzliche Maßnahmen. Sie dürfen nicht im Alltag untergehen, weil sie sonst sowohl Sicherheits- als auch Nachweispflichten gefährden. Eine saubere Behandlung ist daher ein wichtiger Teil der Reife eines ISMS.

8.7 Verbesserungen in den nächsten Zyklus übernehmen

Die Ergebnisse aus diesem Schritt müssen in den nächsten Zyklus zurückgeführt werden. Genau das macht den PDCA-Gedanken in Grundschutz++ praktisch wirksam. Erkenntnisse, Maßnahmen und neue Bewertungen dürfen nicht nur einmalig dokumentiert werden, sondern müssen den nächsten Planungs- und Umsetzungsdurchlauf beeinflussen.

Für den Leitfaden ist das der entscheidende Abschluss: Verbesserung ist kein Endpunkt, sondern ein fortlaufender Kreislauf. Eine Organisation, die ihre Erfahrungen systematisch zurückführt, entwickelt ihr ISMS beständig weiter und bleibt anschlussfähig an neue Anforderungen und Risiken.

10. Werkzeuge und Nachweise

Dieses Kapitel beschreibt, wie das ISMS nach Grundschutz++ organisatorisch und technisch so unterstützt wird, dass Anforderungen, Nachweise und Dokumentation im Alltag handhabbar bleiben. Gerade bei einem neu aufgebauten ISMS ist es wichtig, früh eine geeignete Arbeitsumgebung festzulegen, damit die Methodik nicht an unklarer Ablage, uneinheitlicher Dokumentation oder fehlenden Nachweisen scheitert.

10.1 Geeignete Toolunterstützung auswählen

Für den praktischen Einsatz sollte die Organisation früh entscheiden, mit welchen Werkzeugen das ISMS geführt werden soll. Dabei geht es nicht nur um eine Softwarefrage, sondern darum, ob die gewählte Unterstützung die Grundstruktur von Grundschutz++ überhaupt sinnvoll abbilden kann. Wichtig ist insbesondere, dass die Lösung den Umgang mit Geltungsbereich, Geschäftsprozessen, Assets, Zielobjektkategorien, Anforderungen, Maßnahmen und Zuständigkeiten unterstützt.

Für Einsteiger ist eine einfache, aber konsistente Toolunterstützung meist hilfreicher als ein komplexes Spezialwerkzeug, das zwar viele Funktionen bietet, im Alltag aber kaum gepflegt wird. Entscheidend ist, dass das Werkzeug zur Größe, Reife und Arbeitsweise der Organisation passt und nicht zusätzlichen Aufwand erzeugt. Eine gute Toolunterstützung sollte außerdem Auswertungen, Statusübersichten und die Nachverfolgung von Maßnahmen ermöglichen.

10.2 Datenmodell und Ablagestruktur definieren

Damit ein ISMS nach Grundschutz++ nicht unübersichtlich wird, braucht es eine klare Daten- und Ablagestruktur. Schon zu Beginn sollte festgelegt werden, wo welche Informationen abgelegt werden und wie die Bezüge zwischen den Inhalten dargestellt werden. Dazu gehört zum Beispiel, wie Geltungsbereich, Prozesse, Assets, Anforderungen, Maßnahmen und Nachweise miteinander verknüpft werden.

Die Struktur sollte so einfach wie möglich, aber so vollständig wie nötig sein. Für die Praxis bedeutet das: Es sollte klar erkennbar sein, welche Dokumente führend sind, welche nur unterstützend wirken und wo die jeweils aktuelle Version zu finden ist. Besonders wichtig ist eine Struktur, die auch bei Änderungen nachvollziehbar bleibt und nicht bei jedem Fortschritt umgebaut werden muss.

10.3 Nachweisführung und Dokumentation standardisieren

Nachweise sind im ISMS nicht nur Belege für Prüfungen, sondern auch Steuerungsinstrumente. Deshalb sollte die Organisation früh festlegen, welche Nachweise in welcher Form geführt werden und welche Mindestinhalte sie enthalten müssen. Dazu gehören zum Beispiel Freigaben, Entscheidungen, Bewertungen, Umsetzungsstände, Ausnahmen und Audit-Ergebnisse.

Eine Standardisierung der Dokumentation hilft dabei, wiederkehrende Inhalte gleichartig zu erfassen und später leichter zu prüfen. Für Einsteiger ist das besonders hilfreich, weil damit Unsicherheiten reduziert und Qualitätsschwankungen vermieden werden. Ziel sollte nicht eine möglichst umfangreiche Dokumentation sein, sondern eine verlässliche und konsistente Dokumentation, die den tatsächlichen Nachweisbedarf erfüllt.

10.4 Vorlagen, Checklisten und Arbeitsblätter nutzen

Vorlagen und Checklisten erleichtern den Einstieg, weil sie die einzelnen Arbeitsschritte greifbar machen. Sie helfen dabei, nichts Wesentliches zu übersehen, und geben eine Orientierung, welche Informationen in welcher Phase benötigt werden. Besonders bei einem neuen ISMS nach Grundschutz++ sind solche Hilfsmittel sinnvoll, um den Einstieg zu strukturieren und die Arbeit für unterschiedliche Rollen nachvollziehbar zu machen.

Wichtig ist allerdings, dass Vorlagen nicht zu einem Selbstzweck werden. Sie sollen die Arbeit unterstützen, nicht ersetzen. Der Leitfaden sollte deshalb klar machen, dass Vorlagen, Checklisten und Arbeitsblätter immer an die Organisation angepasst werden müssen, damit sie wirklich nützlich sind und nicht nur formal ausgefüllt werden.

10.5 Umgang mit Maschinenlesbarkeit und Exporten

Grundschutz++ zielt darauf ab, Anforderungen und Strukturen künftig stärker maschinenlesbar nutzbar zu machen. Für die Praxis bedeutet das, dass die Organisation bereits beim Aufbau darauf achten sollte, Informationen so zu strukturieren, dass sie später möglichst gut exportiert, ausgewertet oder weiterverarbeitet werden können. Das betrifft vor allem die konsistente Modellierung von Anforderungen, Zielobjekten und Nachweisen.

Der Leitfaden sollte hier aber realistisch bleiben: Nicht jede Organisation wird sofort vollständig maschinenlesbar arbeiten können. Deshalb ist es sinnvoll, einen pragmatischen Übergang zu beschreiben, in dem zunächst eine saubere fachliche Struktur aufgebaut wird, die später bei Bedarf in technisch stärker strukturierte Formate überführt werden kann. Exportmöglichkeiten sind dabei wichtig, um Auswertungen, Berichte und Übergänge zwischen Werkzeugen zu unterstützen.

11. Praktische Arbeitshilfen

Dieses Kapitel bündelt einfache und direkt nutzbare Arbeitshilfen für den Aufbau eines ISMS nach Grundschutz++. Es richtet sich an Anwendende mit mäßiger ISMS-Erfahrung, die nicht erst eine umfangreiche Methodik verstehen wollen, sondern vor allem konkrete Unterstützung für den Einstieg und die ersten Arbeitsschritte suchen.

Die Arbeitshilfen sollen dabei helfen, den Aufbau des ISMS praktisch zu strukturieren, typische Fehler zu vermeiden und die wichtigsten Ergebnisse sauber festzuhalten. Sie ersetzen nicht die Methodik, sondern übersetzen sie in leicht anwendbare Vorlagen, Checklisten und Beispiele.

11.1 Checkliste für den Start

Die Start-Checkliste soll den Einstieg vereinfachen und dafür sorgen, dass die wichtigsten Grundlagen nicht übersehen werden. Sie ist bewusst kurz und praxisnah gehalten, damit sie direkt am Anfang eines ISMS-Projekts genutzt werden kann.

Die ersten Fragen lauten:

• Gibt es einen klaren Auftrag der Leitung?
• Ist das Ziel des ISMS verständlich formuliert?
• Ist bekannt, welche Bereiche, Prozesse oder Systeme zunächst betrachtet werden sollen?
• Sind die wesentlichen Rollen benannt?
• Gibt es bereits vorhandene Unterlagen, die weiter genutzt werden können?
• Ist klar, wer die Arbeit koordiniert und wer Entscheidungen freigibt?

Zusätzlich sollte geprüft werden, ob für den Start ausreichend Zeit, Personen und Unterstützung zur Verfügung stehen. Wer diese Fragen früh beantwortet, verhindert spätere Unsicherheiten und schafft eine gute Grundlage für die nächsten Prozessschritte.

11.2 Checkliste je Prozessschritt

Für jeden Prozessschritt von Grundschutz++ sollte es eine einfache Checkliste geben. Diese Checklisten helfen dabei, den jeweiligen Schritt vollständig abzuarbeiten und die Ergebnisse nachvollziehbar festzuhalten. Für Anwendende mit begrenzter ISMS-Erfahrung ist das besonders hilfreich, weil dadurch klar wird, was in jedem Schritt konkret zu tun ist.

Eine gute Checkliste sollte immer dieselbe Struktur haben:

• Was ist zu tun?
• Welche Informationen werden benötigt?
• Welche Entscheidung ist zu treffen?
• Was ist das erwartete Ergebnis?
• Welche Nachweise sollten am Ende vorliegen?

So entsteht eine klare Arbeitsreihenfolge, die auch ohne tiefes Methodikwissen nachvollziehbar bleibt. Die Checklisten sollten nicht zu umfangreich sein, sondern jeweils nur die wirklich wesentlichen Punkte enthalten.

11.3 Muster für Leitlinie, Scope und Anforderungspaket

Für den praktischen Aufbau sind drei Muster besonders wichtig: eine Vorlage für die Informationssicherheitsleitlinie, eine Vorlage für den Scope und eine Vorlage für das Anforderungspaket. Diese Dokumente bilden die Grundlage für das ISMS und sollten deshalb möglichst einfach, klar und wiederverwendbar sein.

Die Leitlinien-Vorlage sollte enthalten:

• das Ziel der Informationssicherheit,
• die Verantwortung der Leitung,
• die grundsätzliche Sicherheitsausrichtung,
• die wichtigsten Rollen,
• den Hinweis auf kontinuierliche Verbesserung.

Die Scope-Vorlage sollte helfen, den Geltungsbereich verständlich zu beschreiben. Dafür sollten die wichtigsten Geschäftsprozesse, Organisationseinheiten, Standorte und Systeme benannt werden. Wichtig ist, dass der Scope klar genug ist, um spätere Modellierung und Umsetzung zu ermöglichen, aber nicht unnötig kompliziert formuliert wird.

Das Muster für das Anforderungspaket sollte so aufgebaut sein, dass Anforderungen eindeutig erfasst, zugeordnet und verfolgt werden können. Dazu gehören mindestens eine Bezeichnung der Anforderung, der Bezug zu einem Zielobjekt oder einer Zielobjektkategorie, die Zuständigkeit und der Umsetzungsstatus. Gerade für Einsteiger ist eine einheitliche Struktur hier wichtiger als eine besonders ausgefeilte Darstellungsform.

11.5 Beispiel für Rollen- und Aufgabenverteilung

Ein ISMS funktioniert nur dann gut, wenn klar ist, wer was macht. Deshalb braucht dieses Kapitel ein einfaches Beispiel für die Rollen- und Aufgabenverteilung. Es soll zeigen, welche Aufgaben bei der Leitung, beim ISB, bei den fachlich Verantwortlichen und bei den umsetzenden Stellen liegen.

Für die Praxis ist eine einfache Rollenübersicht besonders hilfreich. Sie sollte beantworten:

• Wer entscheidet?
• Wer koordiniert?
• Wer erstellt?
• Wer prüft?
• Wer gibt frei?
• Wer setzt um?

Das Beispiel sollte zudem zeigen, dass Rollen nicht nur Titel sind, sondern mit konkreten Aufgaben verbunden sein müssen. Wichtig ist auch eine Stellvertretung, damit das ISMS nicht an einzelnen Personen hängt. Für Einsteiger reicht eine einfache Darstellung oft völlig aus, solange sie eindeutig und nachvollziehbar ist.

12. Anhang

12.1 Begriffsübersicht

Hier sind typische Begriffe aus dem Grundschutz++ definiert und ausführlicher erläutert.

Anforderungen

Anforderungen beschreiben, was umgesetzt werden muss, um ein bestimmtes Sicherheitsniveau zu erreichen. Sie beziehen sich auf organisatorische, personelle, technische und infrastrukturelle Aspekte der Informationssicherheit.

Wie eine Anforderung praktisch erfüllt wird, wird durch passende Maßnahmen festgelegt.

In englischen Standards wird für Anforderungen häufig der Begriff „control“ verwendet.

Im Grundschutz++ wird der Verbindlichkeitsgrad analog zum klassischen IT-Grundschutz durch das Modalverb der Anforderung festgelegt:

• MUSS → verpflichtend, keine Abweichungen zulässig.
• SOLLTE → grundsätzlich verpflichtend, Ausnahmen mit Begründung möglich.
• KANN → optional, je nach Situation sinnvoll.

Assets

Assets sind alle materiellen oder immateriellen Werte einer Organisation, die für den Geschäftsbetrieb erforderlich sind. Dazu gehören z. B. Informationen/Daten, Mitarbeitende, IT-Systeme, Software, Gebäude oder Fachwissen. Sie stellen die Grundlage für die Erreichung von Organisations- oder Geschäftsziele dar.

Gleichartige und gleich behandelte Assets sollten sinnvoll zusammen gefasst (gruppiert) und als ein Asset behandet werden.

Assets entsprechen damit weitgehend den "Komponenten" im klassischen IT-Grundschutz, die dort in einer "Komponentenliste" geführt wurden.

Midestanforderungen an Atribute für Assets:

• ASSET-ID: Eindeutiges Kennzeichen des Assets (Inventrnummer)
• Asset-Name: Kurzbeschreibung (was ist das, wofür wird es genutzt?).
• Asset-Typ: z.B. Server, Anwendung, Dokument, Prozess, Dienstleistung.
• Eigentümer/Verantwortliche: Verantwortliche Person / Asset Owner (fachlich, nicht nur IT).

Assets sollten sinnvoll zusammengefasst (gruppiert) werden, um das Register überschaubar zu halten und Risikoanalysen effizient zu gestalten.

Gruppierungskriterien:

• Gleicher Typ/Klasse: z.B. alle „Vertriebs-Laptops“ statt 100 einzelne Geräte.​
• Ähnlicher Schutzbedarf: gleiche CIA-Klassifizierung (Vertraulichkeit, Integrität, Verfügbarkeit).
• Gleiche Nutzung/Konfiguration: z.B. identisch konfigurierte Server, dieselben Anwendungen, gleicher Standort/Netzbindung.​
• Geschäftsbezug: z.B. Assets pro Abteilung (Vertrieb, HR) oder Prozess (Rechnungsstellung).
• Risikogruppen: Assets mit denselben Bedrohungen/Schwachstellen.​

Vorsicht: Nur gruppieren, wenn die auf die Assets wirkenden Risiken homogen sind – sonst riskiert ihr Sicherheitslücken.

Grupierte Assets bezeichnet man als Asset-Gruppen, die ihrerseits wie Assets behandelt werden.

Blaupausen

Eine Blaupause ist eine vordefinierte Vorlage mit einer Auswahl relevanter Zielobjekte und Praktiken und zugehöriger Sicherheitsanforderungen. Sie dient als Einstiegshilfe für Organisationen, um basierend auf dem initialen Schutzbedarf (normal oder erhöht) passende Maßnahmen rasch zu identifizieren und umzusetzen, ohne eine vollständige eigene Modellierung vornehmen zu müssen.

Im Gegensatz zur traditionellen IT-Grundschutz-Methodik, die eine detaillierte Strukturanalyse und Modellierung erfordert, ermöglicht die Blaupause einen effizienten, risikoorientierten Top-down-Ansatz und kann an den Geltungsbereich angepasst werden, um den PDCA-Zyklus eines ISMS zu unterstützen.

Du kannst Blaupausen nutzen, um den Umstieg von älteren Grundschutz-Versionen zu erleichtern oder neu einzusteigen, indem Du den Schutzbedarf deines Informationsverbunds bewertest und die passende Vorlage als Ausgangspunkt wählst. Ergänzende Anpassungen erfolgen durch GAP-Analysen.

Blaupausen entsprechen damit in etwa den "Profilen" im klassischen IT-Grundschutz.

Geltungsbereich

Der Geltungsbereich (Scope) definiert, für welchen organisatorischen und fachlichen Bereich das Informationssicherheitsmanagementsystem (ISMS) gilt. Er legt fest, welche Standorte, Systeme, Prozesse oder Einheiten vom ISMS abgedeckt werden und welche nicht. Damit wird klar abgegrenzt, wo das ISMS anzuwenden ist.

Informationssicherheitsmanagementsystem (ISMS)

Das ISMS ist ein systematischer Ansatz, um Informationssicherheit in einer Organisation zu planen, zu steuern, zu überwachen und fortlaufend zu verbessern.

Es stellt sicher, dass Sicherheitsstrategien und -maßnahmen regelmäßig auf ihre Wirksamkeit überprüft und bei Bedarf angepasst werden. Ziel ist ein dauerhaft wirksamer, ganzheitlicher Schutz von Informationen.

Informationsverbund

Ein Informationsverbund umfasst alle technischen, organisatorischen, personellen und infrastrukturellen Komponenten, die gemeinsam Aufgaben der Informationsverarbeitung erfüllen.

Dies kann die gesamte Institution oder abgegrenzte Bereiche (z. B. einzelne Abteilungen oder IT-Systemgruppen) betreffen, die durch gemeinsame Prozesse oder Strukturen verbunden sind.

Maßnahmen

Maßnahmen sind konkrete Handlungen, Vorgaben oder technische Umsetzungen, die dazu dienen, erkannte Risiken zu steuern und Anforderungen zu erfüllen. Sie können organisatorischer, personeller, technischer oder infrastruktureller Art sein und sollen die Informationssicherheit (die Umsetzung der Anforderungen) wirksam sicherstellen.

Praktiken

Praktiken fassen Anforderungen zu thematischen Gruppen zusammen, die typischerweise bestimmten Rollen oder Prozessen zugeordnet werden. Dadurch wird klar, wer für die Umsetzung verantwortlich ist.

Es gibt drei Arten von Praktiken:

• ISMS-Praktiken (übergreifendes Management nach dem PDCA-Zyklus)
• Organisatorische Praktiken
• Technische Praktiken

Die ISMS-Praktiken bilden den Regelkreis zur laufenden Steuerung und Verbesserung der Informationssicherheit.

Schutzbedarf

Der Schutzbedarf zeigt, wie stark Informationen, Systeme oder Prozesse geschützt werden müssen. Er ergibt sich aus möglichen Auswirkungen auf die Grundwerte:

• Vertraulichkeit
• Integrität
• Verfügbarkeit

Je nach Bewertung wird der Schutzbedarf als „normal“ oder „hoch“ eingestuft und bestimmt das erforderliche Sicherheitsniveau sowie die Auswahl passender Anforderungen.

Sicherheitsleitlinie

Die Sicherheitsleitlinie ist das grundlegende Dokument für Informationssicherheit in einer Organisation.

Sie beschreibt Ziele, Prinzipien und Strategien, mit denen Informationssicherheit erreicht werden soll. Sie legt fest, welche Bedeutung Informationssicherheit hat, welche Ziele verfolgt werden und wie Verantwortlichkeiten verteilt sind. Damit definiert sie das angestrebte Sicherheitsniveau.

Sicherheitsniveau

Das Sicherheitsniveau gibt an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.

Unterschieden werden:

• Normales Sicherheitsniveau: entspricht dem Stand der Technik
• Erhöhtes Sicherheitsniveau: für besonders schutzbedürftige Informationen oder Systeme

Stufen

Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:

• Stufe 0: Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).

Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:

• Stufe 1: Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
• Stufe 2: Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
• Stufe 3: Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
• Stufe 4: Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.

Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.

• Stufe 5: Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.

Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.

Zielobjekte

Zielobjektkategorien und Zielobjekte sind Bestandteile eines Informationsverbunds, denen spezifische Anforderungen zugeordnet sind. Das können sowohl physische Objekte (z. B. Server, Räume) als auch logische Objekte (z. B. Anwendungen, Datenbestände) sein. Die Zielobjekte entsprechen damit eher den "Bausteinen" im klassischen IT-Grundschutz.

Zielobjektkategorien

Zielobjektkategorien sind übergeordnete Zielobjekte, die für ein oder mehrere untergeordneten Zielobjetekategorien oder Zielobjete geltende Anforderungen enthalten, die für diese mitgelten. D.h. Anforderungen werden entlang der gesamten Baumstruktur weiter vererbt.

12.2 Abkürzungen

Hier sind wichtige Abkürzungen und Begriff kurz erklärt:

Abkürzung / Begriff	Erläuterung
ISMS	Managementsystem für Informationssicherheit; umfasst Aufbau, Betrieb, Überwachung und Verbesserung der Informationssicherheit in der Organisation.
IT‑Grundschutz	Vom BSI entwickelte Methodik zur systematischen Absicherung von Informationen auf Basis von Bausteinen, Schutzbedarfsfeststellung, Modellierung und IT‑Grundschutz‑Check.
IT‑Grundschutz‑Kompendium	Katalog der IT‑Grundschutz‑Bausteine mit Anforderungen für typische Geschäftsprozesse, Anwendungen, IT‑Systeme, Netze und Räume.
ISO 27001	Internationale Norm für Managementsysteme für Informationssicherheit, auf der u.a. BSI‑Standard 200‑1 aufbaut.
Grundschutz++	Weiterentwicklung des IT‑Grundschutzes mit prozessorientierter, modellbasierter und stärker maschinenlesbarer Methodik für Anforderungen und Zielobjekte.
BSI	Bundesamt für Sicherheit in der Informationstechnik; Herausgeber von IT‑Grundschutz, Grundschutz++ und den BSI‑Standards.
PDCA	Zyklus aus Plan, Do, Check, Act; Strukturprinzip für den kontinuierlichen Verbesserungsprozess eines ISMS.
Geschäftsprozess	Fachlicher Ablauf zur Erbringung einer Dienstleistung oder eines Produkts; zentrale Bezugsgröße für Schutzbedarf und Anforderungen im ISMS.
Asset	Schutzwürdiges Gut im Informationsverbund, z.B. Informationen, Anwendungen, IT‑Systeme, Räume, Kommunikationsverbindungen oder Dienstleistungen.
Informationsverbund	Gesamtheit der miteinander verbundenen Geschäftsprozesse, Assets, Zielobjekte und Systeme, die im Rahmen des ISMS gemeinsam betrachtet werden.
Zielobjekt	Konkretes Objekt im Informationsverbund (z.B. eine bestimmte Anwendung oder ein Server), dem Anforderungen zugeordnet werden.
Zielobjektkategorie	Oberkategorie für Zielobjekte mit ähnlichen Eigenschaften (z.B. „Anwendung“, „Server“, „Netzwerkkomponente“), zur strukturierten Zuordnung und Vererbung von Anforderungen.
Praktik	Themenbezogene Gruppe von Anforderungen in Grundschutz++, die eine bestimmte sicherheitsrelevante Tätigkeit oder ein Themenfeld beschreibt.
Anforderungspaket	Gesamtheit der für einen Informationsverbund geltenden Anforderungen (ISMS‑weit und zielobjektbezogen), Grundlage für Umsetzung und Nachweisführung.
Sicherheitsniveau	Einstufung des angestrebten Schutzniveaus (z.B. normal oder erhöht) für Geschäftsprozesse und Informationsverbund, beeinflusst Umfang und Tiefe der Anforderungen.
Reifegrad	Einschätzung, wie weit ISMS‑Strukturen, Prozesse, Verantwortlichkeiten und Nachweisführung in der Organisation bereits entwickelt sind.
Scope / Geltungsbereich	Abgegrenzter Anwendungsbereich des ISMS (z.B. bestimmte Organisationseinheiten, Standorte, Prozesse und Systeme), auf den sich alle weiteren Schritte beziehen.
Informationssicherheitsleitlinie	Von der Leitung freigegebenes Grundlagendokument mit Zielen, Grundsätzen, Verantwortlichkeiten und strategischer Ausrichtung der Informationssicherheit.
Interessierte Parteien	Interne und externe Personen oder Organisationen (z.B. Leitung, Mitarbeitende, Kunden, Aufsichtsstellen), die Anforderungen oder Erwartungen an die Informationssicherheit haben.
Managementbewertung	Regelmäßige Bewertung des ISMS durch die Leitungsebene auf Basis von Leistungsbewertung, Audits, Compliance‑Status und offenen Maßnahmen.
Nicht‑Konformität	Festgestellte Abweichung zwischen geforderter/vereinbarter ISMS‑Vorgabe und der tatsächlichen Umsetzung (z.B. aus Audit, Review oder Überwachung).
Compliance	Einhaltung gesetzlicher, regulatorischer, vertraglicher und interner Vorgaben im Rahmen des ISMS.
Ausnahme	Bewusst akzeptierte, begründete und freigegebene Abweichung von einer Anforderung, meist zeitlich befristet und mit Risikobetrachtung verbunden.

Definition und Abgrenzung des Informationsverbunds

Erhebung der Assets

Beginne mit Kategorien wie „Hardware“, „Software“, „Daten“, „Prozesse“ und verfeinere iterativ. Tools wie Excel oder ISMS-Software automatisieren Gruppierung und Reviews.

• Analyse des aktuellen Umsetzungsstands je Zielobjekt/Asset, möglichst auf Ebene einzelner Teilanforderungen (mit Dokumentation aller MUSS/SOLL/KANN-Nachweise getrennt für jede Instanz).
• Auflösung redundanter und historisch gewachsener Strukturen, klare Gruppierung der Assets/Zielobjekte nach aktuellem Betriebsmodell.
• Konsolidierte Zuordnung und Mapping zu bestehenden Grundschutz-Praktiken.

Asset-Register

Typische Kategorien eines Asset-Registers sind:

Informationen

Informationen bilden den Kernwert des Informationsverbunds und müssen hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit bewertet werden, da ihr Verlust oder Missbrauch direkte Geschäftsschäden verursacht.

Beispiel: Daten, Dokumente, Datenbanken und Wissensbestände unabhängig vom Speichermedium, z. B. Geschäftsdaten, Verträge oder Geschäftsgeheimnisse.​

Anwendungen

Sie verarbeiten und speichern Informationen; ihr Schutzbedarf vererbt sich auf zugrunde liegende IT-Systeme und bestimmt Maßnahmen gegen Ausfälle oder Manipulationen.

Beispiel: Softwarelösungen wie ERP-Systeme, Datenbanken, Webanwendungen oder Geschäftsanwendungen.​

Nutzende

Sie greifen auf Assets zu und stellen das schwächste Glied dar; Schutzmaßnahmen fokussieren Sensibilisierung und Zugriffsrechte, um Insider-Risiken zu minimieren.

Beispiel: Personen oder Rollen wie Mitarbeitende, externe Dienstleistende, Endbenutzer, Prozessverantwortliche oder Administrierende.

IT-Systeme

Sie hosten Anwendungen und Informationen; der Schutzbedarf ergibt sich aus Vererbung und schützt vor Hardwareausfällen oder Angriffen auf die Basisinfrastruktur.

Beispiel: Hardware wie Server, Arbeitsplatzrechner, Speichersysteme oder Virtualisierungsplattformen.

Netze

Sie ermöglichen den Datenfluss zwischen Assets; Maßnahmen sichern den sicheren Transport und verhindern unbefugten Zugriff oder Abhörangriffe.

Beispiel: Kommunikationsinfrastrukturen wie LAN, WAN, WLAN, Firewalls oder VPN-Verbindungen.

Standorte

Sie beherbergen alle anderen Assets; Schutz adressiert physische Bedrohungen wie Einbruch oder Katastrophen und gewährleistet die Verfügbarkeit des gesamten Informationsverbunds.

Beispiele: Physische Orte wie Gebäude, Rechenzentren, Räume oder Arbeitsplätze.

Praxis-Tipp:

• Nutze möglichst vorhanende systemaische und autoatisatisierte Erfassungssysteme (CMDB-, Inventory-, oder ISMS-Systeme)

• Halte das Register so schlank wie möglich, aber so detailliert, dass jedes Asset eindeutig identifizierbar ist, einem Verantortlichem (Owner) zugeordnet werden kann und sein Schutzbedarf nachvollziehbar ist.
• Tiefergehende Attribute (RTO/RPO, Datenklassen, Lieferanten-Nachweise usw.) kannst Du für die „kritischen Top-Assets“ ergänzen und für weniger kritische auf den Kernumfang beschränken.

Modellierung

Asset Erfassung (Strukturanalyse)

Die Erfassung der relevanten Assets erfolgt wie gewohnt in Komponentenlisten in den folgenden Kategorien:

Gruppierung der Assets

Um die Komplexität und den Aufwand zu reduzieren, sollten Assets sinnvoll gruppiert werden. Dabei sollten gleiche und gleich zu behandelnde Assets zu einem Asset zusammen gefasst werden.

Zielobjektmapping

Jedes Asset wird einem oder mehreren passenden Zielobjekten zugewiesen.

Vererbung der Zielobjekte

Für die zugewiesenen Zielobjekte müssen auch alle darüber liegenden Zielobjekte in der Hierarchie zugewiesen werden.