Was das BSI unter einem Sicherheitskonzept versteht
Im klassischen IT-Grundschutz ist die Erstellung der Sicherheitskonzeption eine der zentralen Aufgaben des Informationssicherheitsmanagements. Bei der Standard-Absicherung gehören dazu die Aktionsfelder Festlegung des Geltungsbereichs, Strukturanalyse, Schutzbedarfsfeststellung, Modellierung, IT-Grundschutz-Check und Risikoanalyse (200-2, Kap. 8). Die Umsetzung folgt einem Realisierungsplan, der mindestens Zielobjekt, Baustein, Anforderung, Maßnahme, Terminplanung, Budget und Verantwortliche nennt (200-2, Kap. 9.4).
Das Konzept ist kompakt, weil es auf die Anforderungen im Kompendium verweist, statt sie zu wiederholen (200-2, Kap. 2.7). Erarbeitet wird das Konzept vom Informationssicherheitsbeauftragten, freigegeben von der Leitungsebene (200-2, Kap. 5.2.1). Als Beispiel für Dokumente des Sicherheitsmanagements nennt 200-2 ausdrücklich das „Sicherheitskonzept mit den Berichten zur Risikoanalyse“ (Kap. 5.2.2). Kommen aus der Risikoanalyse ergänzende Maßnahmen hinzu, ist das Konzept anschließend zu konsolidieren (200-3, Kap. 7).
BSI-Standard 300-1 verwendet das Wort Sicherheitskonzept nicht. Er gliedert das Vorgehen in fünf Prozessschritte und verlangt in jedem dokumentierte Ergebnisse, etwa Anwendungsbereich, Geschäftsprozesse mit Schutzbedarf, Informationsverbund und Assets, Anforderungspaket, Umsetzungsstatus, Risikobetrachtung, Umsetzungsplan sowie Auditprogramm und Managementbewertung. Für Institutionen, die ein Sicherheitskonzept vorlegen sollen, etwa gegenüber einem Auftraggeber oder intern, ist das Dossier aus diesen Ergebnissen die naheliegende Entsprechung. Diese Zuordnung ist unsere Gliederung, keine Vorgabe des BSI.
Dossierstruktur: zehn Teile aus den Ergebnissen von 300-1
Die Tabelle ordnet jedem Teil des Dossiers die Ergebnisse aus 300-1 zu, die hineingehören, die Entsprechung im klassischen Konzept nach 200-2 und die Stelle, die freigibt. Teil J gehört streng genommen zum Betrieb des ISMS; wir führen ihn mit, weil Prüfende danach fragen, ob das Konzept gelebt wird.
| Teil | Inhalt (Ergebnisse aus 300-1) | Entsprechung 200-2 | Freigabe |
|---|---|---|---|
| A Rahmen | Kontext der Institution (Kap. 2.1), Compliance-Anforderungen (2.2), interessierte Parteien (2.4), Informationssicherheitsleitlinie mit messbaren Zielen und Strategie (2.7) | Leitlinie, Rahmenbedingungen | Institutionsleitung (2.7, 2.10) |
| B Anwendungsbereich und Informationsverbund | Anwendungsbereich mit Geschäftsprozessen, Institutionseinheiten, Standorten, Anwendungen, IT-Systemen und Ausschlüssen (2.3); Abgrenzung des Informationsverbunds mit Schnittstellen und Auslagerungen (3.1) | Geltungsbereich, Informationsverbund | Institutionsleitung für den Anwendungsbereich (2.10) |
| C Geschäftsprozesse und Schutzbedarf | Dokumentierte Geschäftsprozesse (2.5, Anhang 2), Schutzbedarf je Geschäftsprozess „normal“ oder „hoch“ (2.6), Reihenfolge der Abarbeitung (2.10) | Schutzbedarfsfeststellung je Zielobjekt | Institutionsleitung (2.10) |
| D Assets und Abhängigkeiten | Erfasste Assets; bei hohem Schutzbedarf Zugehörigkeit und Abhängigkeit zum Geschäftsprozess, bei normalem mindestens Anwendungen zu IT-Systemen und IT-Systeme zu Räumen (3.2) | Strukturanalyse | ISB bzw. festgelegte Rolle (eigene Festlegung, 300-1 nennt keine Freigabestelle) |
| E Anforderungspaket | Gewählte Blaupausen mit Version (3.3), verpflichtende Anforderungen (3.4.1), Zuordnung der Zielobjektkategorien (3.4.2), ergänzende eigene Anforderungen (3.4.3), konkretisierte Parameter (3.5), Katalogstand | Modellierung | ISB bzw. festgelegte Rolle (eigene Festlegung, 300-1 nennt keine Freigabestelle) |
| F Umsetzungsstatus | Status je Anforderung „erfüllt“, „nicht erfüllt“ oder „nicht anwendbar“ mit Begründungen; Einordnung nicht erfüllter SOLLTE-Anforderungen (4.1) | IT-Grundschutz-Check | Mitteilung offener Risiken an die Institutionsleitung (4.1.1) |
| G Risikobetrachtung | Rahmen nach Kap. 2.11, Risikoregister, Behandlungsentscheidungen (4.2), Mindestkriterien aus Anhang 3 | Risikoanalyse nach 200-3 | Institutionsleitung für Rahmen und Restrisiken, Risikoeigentümer für die Umsetzungsplanung |
| H Umsetzungsplan | Maßnahmen je Anforderung mit Zuordnung, Priorität, Datum, dokumentierender oder prüfender Person und Nachweis (4.3); Zuständigkeiten und Fristen (4.4); Fortschritt (4.5) | Realisierungsplan | Institutionsleitung für das Vorgehen (4.4) |
| I Organisation und Dokumentenlenkung | Rollen und Zuständigkeiten (2.8), Kommunikation, Verfahren zur Dokumentenlenkung (2.9) | Sicherheitsorganisation | Institutionsleitung über die Leitlinie (2.7); im Übrigen eigene Festlegung |
| J Überwachung und Verbesserung | Leistungsbewertung (5.1), internes Auditprogramm (5.2), Managementbewertung (5.3), Monitoring-Verfahren (5.4), Validierung der Anforderungen (5.5), Korrektur- und Verbesserungsplan (6.3) | Aufrechterhaltung und Verbesserung (200-2, Kap. 10) | Institutionsleitung (Managementbewertung) |
Unterlagenliste mit Wiederverwendung
Wer bereits ein Sicherheitskonzept nach 200-2 hat, fängt nicht von vorn an. Die Tabelle zeigt je Unterlage, was sich übernehmen lässt und was neu zu erarbeiten ist. Die Einschätzung „übernehmen“ bedeutet, dass die Unterlage als Eingabe dient und gegen die genannte Fundstelle geprüft wird.
| Unterlage | Wiederverwendung | Was zu prüfen oder zu ändern ist | Fundstelle 300-1 |
|---|---|---|---|
| Informationssicherheitsleitlinie | übernehmen | Konkrete, messbare Ziele und eine Strategie zu ihrer Erreichung ergänzen; Verpflichtung der Leitung; Kommunikation an alle Mitarbeitenden | Kap. 2.7 |
| Geltungsbereich, Informationsverbund | übernehmen | Anwendungsbereich und Informationsverbund getrennt beschreiben; Geschäftsprozesse vollständig im Anwendungsbereich; Ausschlüsse benennen | Kap. 2.3, 3.1 |
| Geschäftsprozessliste | übernehmen, wenn vorhanden | Je Prozess Kennung, Name, Verantwortliche, Kurzbeschreibung mit Zweck und Ergebnis, wesentliche Anwendungen | Kap. 2.5, Anhang 2 |
| Schutzbedarfsfeststellung | als Eingabe | Neu je Geschäftsprozess in zwei Kategorien; eigene Kategorien sind auf „normal“ und „hoch“ abzubilden. Mehr auf der Seite Schutzbedarfsfeststellung | Kap. 2.6 |
| Strukturanalyse (Listen, Netzplan) | weitgehend übernehmen | Abhängigkeiten nach Schutzbedarf ergänzen; CMDB, Asset-Register, Netzpläne dürfen genutzt werden. Mehr auf der Seite Strukturanalyse | Kap. 3.2 |
| Modellierung (Bausteine auf Zielobjekte) | nur als Hilfe | Neu: Assets den Zielobjektkategorien zuordnen. Das Mapping 2023 auf Grundschutz++ hat den Status Entwurf. Mehr auf der Seite Modellierung | Kap. 3.4.2 |
| Ergebnisse des IT-Grundschutz-Checks | Bemerkungen übernehmen | Status neu bewerten; „teilweise“ entfällt, „entbehrlich“ ist nicht dasselbe wie „nicht anwendbar“. Mehr auf der Seite Anforderungen bewerten | Kap. 4.1 |
| Risikoanalyse nach 200-3 | Gefährdungen und Maßnahmen übernehmen | Verfahren gegen die 35 Mindestkriterien prüfen, Risiken auf Ebene der Geschäftsprozesse zuordnen. Mehr auf den Seiten Risiko-Mindestkriterien und Risikoanalyse | Kap. 2.11, 4.2, Anhang 3 |
| Realisierungsplan | in den Umsetzungsplan überführen | Je Maßnahme ergänzen, welche Anforderung sie erfüllt, wann sie umgesetzt oder geprüft wurde und wer das dokumentiert oder geprüft hat; Nachweise zuordnen | Kap. 4.3, 4.4 |
| Rollenbeschreibungen | übernehmen | Interessenkonflikte prüfen (IT-Leitung und ISB, DSB und ISB); festlegen, wann der ISB in Projekten beteiligt wird | Kap. 2.8 |
| Richtlinien zu Dokumentenlenkung, internen Audits, Korrekturmaßnahmen | übernehmen | Dokumentenlenkung für alle ISMS-relevanten Dokumente; Auditprogramm mit Zielen und Risiken | Kap. 2.9, 5.2, 6.3 |
| Managementberichte | Aufbau übernehmen | Inhalte der Managementbewertung ergänzen, etwa Status der Risikobehandlung und früherer Managemententscheidungen | Kap. 5.3 |
Gliederung des Dokuments und Deckblatt
Ob Sie das Dossier als ein Dokument führen oder als Mappe aus Einzeldokumenten mit einem Deckdokument, ist Ihre Wahl. 300-1 verlangt ein Verfahren zur Lenkung aller ISMS-relevanten Dokumente, das Nachvollziehbarkeit, Aktualität und Vollständigkeit über den Lebenszyklus sichert (Kap. 2.9). Für das Deckblatt hat sich die Mindestkennzeichnung aus 200-2 bewährt (Kap. 5.2.3). Wir verwenden diese Gliederung:
- Deckblatt: eindeutige Bezeichnung, Ersteller bzw. Dokumenteninhaber und Funktion, Versionsnummer, letzte und nächste geplante Überarbeitung, freigegeben am und durch, Klassifizierung, berechtigte Rollen (200-2, Kap. 5.2.3). Ergänzt um die Fassung von BSI-Standard 300-1 und das Build-Datum des Anwenderkatalogs.
- Zusammenfassung für die Leitung: Anwendungsbereich in einem Absatz, Zahl der Geschäftsprozesse je Schutzbedarf, Stand der Umsetzung, offene MUSS-Anforderungen, Restrisiken zur Freigabe.
- Teile A bis I nach der Tabelle oben, jeweils mit Verweis auf die gelenkten Einzeldokumente.
- Teil J als Verweis auf Auditprogramm, Managementbewertung und Verbesserungsplan.
- Anhang: Abkürzungen, Verzeichnis der Freigaben mit Datum, Änderungsübersicht.
Wie im klassischen Konzept verweist das Dossier auf die Anforderungen per Kennung, statt ihren Text zu wiederholen. Das hält es kurz und erleichtert den Abgleich mit einem neuen Katalogstand.
Qualitätsprüfung vor der Freigabe
BSI-Standard 200-3 nennt in Kap. 7 vier Gesichtspunkte für die Konsolidierung eines Sicherheitskonzepts. Wir übertragen sie mit eigenen Leitfragen auf das Dossier und nutzen sie als letzte Durchsicht vor der Vorlage an die Leitung.
| Gesichtspunkt (nach 200-3, Kap. 7) | Unsere Leitfrage für das Dossier |
|---|---|
| Eignung | Gibt es zu jeder Gefährdung aus den Risikobetrachtungen eine Maßnahme, und passt sie zu den Zielen der Leitlinie? |
| Zusammenwirken | Behindern sich Maßnahmen aus verschiedenen Teilen des Dossiers, etwa Protokollierung und Löschfristen? |
| Benutzerfreundlichkeit | Würden Beschäftigte die Maßnahme im Alltag umgehen, und fiele es auf, wenn sie ausfällt? |
| Angemessenheit | Passt der Aufwand zum Schutzbedarf des Geschäftsprozesses, und ist keine Maßnahme zu schwach für ihr Risiko? |
Ergänzend prüfen wir drei Punkte, die aus 300-1 folgen: Jede Anforderung im Paket hat einen Status (Kap. 4.1.1). Jede Maßnahme ist mindestens einer Anforderung zugeordnet und umgekehrt (Kap. 4.3). Jedes Restrisiko hat eine Freigabe der Institutionsleitung (Kap. 4.2.3).
Freigabe und Pflege
300-1 hält fest: „Die Verantwortung für die Umsetzung eines ISMS liegt bei der Institutionsleitung und kann nicht delegiert werden.“ (Kap. 2.10). Zur Freigabe gehen an die Leitung vor allem Anwendungsbereich, Schutzbedarf und Reihenfolge der Geschäftsprozesse, Ressourcen und Leitlinie. Dazu kommen die Restrisiken aus der Risikobetrachtung (Kap. 4.2.3) und das Vorgehen der Umsetzungsplanung (Kap. 4.4). Im Dossier halten Sie diese Freigaben mit Datum fest.
Ein Dossier bleibt nur brauchbar, wenn es mit dem ISMS mitwächst. 300-1 nennt die Anlässe: Änderungen im Informationsverbund, Anpassungen an den Anforderungen der Stand-der-Technik-Bibliothek und an verwendeten Blaupausen sowie Änderungen in der Methodik (Kap. 5.5). Die Risikobetrachtung ist mindestens jährlich zu überprüfen (Anhang 3, Kriterium 35). Ändert sich eine Maßnahme, ihr Umsetzungsstand oder ein Prüfergebnis, ist die Dokumentation zu aktualisieren; eine Historie wird empfohlen (Kap. 4.3).
Weil der Anwenderkatalog maschinenlesbar ist, lassen sich große Teile von E, F und H aus einem Werkzeug erzeugen. Automatisierte Prüfungen sind als Nachweis zulässig, wenn Tool, Zeitpunkt und Ergebnis dokumentiert sind (Kap. 4.3). Wer welchen Nachweis wann liefert, planen Sie auf der Seite Nachweisplan; wie das Dossier im Audit verwendet wird, beschreibt die Seite Zertifizierung.
Wann sich Unterstützung lohnt
Ein Dossier nach dieser Struktur lässt sich zu großen Teilen aus vorhandenen Unterlagen bilden. Aufwändig wird es dort, wo die Methodik wechselt: beim Schutzbedarf je Geschäftsprozess, bei der Zuordnung zu Zielobjektkategorien und bei der Neubewertung des Umsetzungsstatus. Diese Arbeit übernimmt das Team von Blackfort Technology als Bestandsbewertung mit Migrationskonzept, siehe Bestandsbewertung und Migrationskonzept und Beratung. Wie Sie einzelne Nachweise planen, steht auf der Seite Nachweisplan, das Prüfverfahren auf der Seite Zertifizierung.
Rechtehinweis: Kurze Zitate aus BSI-Standard 300-1 „Methodik Grundschutz++“, Version 1.0 vom 20.10.2026, © Bundesamt für Sicherheit in der Informationstechnik 2026, Quelle: BSI-Seite zu Grundschutz++; aus BSI-Standard 200-2 „IT-Grundschutz-Methodik“, Version 1.0, © Bundesamt für Sicherheit in der Informationstechnik 2017, Quelle: BSI-Seite zu BSI-Standard 200-2; aus BSI-Standard 200-3 „Risikoanalyse auf der Basis von IT-Grundschutz“, Version 1.0, © Bundesamt für Sicherheit in der Informationstechnik 2017, Quelle: BSI-Seite zu BSI-Standard 200-3.