Was ein Informationsverbund in Grundschutz++ ist
BSI-Standard 300-1 definiert den Informationsverbund in Kapitel 3.1 als „Gesamtheit von infrastrukturellen, organisatorischen, personellen und technischen Assets“. Zu den Assets zählt der Standard „alle materiellen und immateriellen Werte der Institution, die für die betrachteten Geschäftsprozesse benötigt werden“. Wie weit der Verbund reicht, legen Sie selbst fest: Er kann den ganzen Anwendungsbereich abdecken oder nur einen Ausschnitt, etwa eine Organisationseinheit oder ein Fachverfahren mit den Prozessen, die darauf laufen.
Die Abgrenzung ist kein Formalakt. Kapitel 3.1 begründet sie so: „Eine klare und nachvollziehbare Abgrenzung des Informationsverbunds stellt sicher, dass alle relevanten Informationen, Assets und deren Abhängigkeiten vom ISMS erfasst werden.“ Die im Informationsverbund erfassten Assets sind Voraussetzung für das Anforderungspaket. Wer hier unscharf arbeitet, bekommt später ein Anforderungspaket, das entweder Lücken hat oder Bereiche einschließt, die niemand verantwortet.
Im Anwenderkatalog Grundschutz++ steht die Abgrenzung als Methodik-Anforderung STM.1.1: „Strukturmodellierung MUSS den nachvollziehbar abgegrenzten Informationsverbund auf Basis des Geltungsbereichs festlegen.“ Die Schnittstellen regelt STM.1.2: „Strukturmodellierung MUSS Schnittstellen des Informationsverbunds zu externen Prozessen festlegen.“ Beide stehen auf MUSS, eine Risikoakzeptanz statt Erfüllung ist bei MUSS-Anforderungen nach Kapitel 4.1.2 des Standards ausgeschlossen.
Anwendungsbereich und Informationsverbund: zwei Ebenen
Hier unterscheidet sich 300-1 deutlich vom klassischen IT-Grundschutz. BSI-Standard 200-2 setzt in Kapitel 3.3.4 beide Begriffe gleich: Der Geltungsbereich für die Sicherheitskonzeption wird dort „Informationsverbund“ genannt. 300-1 trennt sie (Kap. 3.1): „Ein Anwendungsbereich legt den formalen und organisatorischen Umfang fest, in dem das ISMS angewendet wird. Der Informationsverbund stellt die inhaltlich-technische Abbildung des Anwendungsbereichs dar. Der Anwendungsbereich kann einen oder mehrere Informationsverbünde enthalten.“
Den Anwendungsbereich legt die Institutionsleitung fest (Kapitel 2.3). Grundlage sind der institutionelle Kontext, die gesetzlichen, regulatorischen und vertraglichen Anforderungen und die strategischen Ziele. Nach Kapitel 2.10 wird der Leitung die Festlegung des Anwendungsbereichs als Entscheidungsvorlage vorgelegt; im Katalog steht dazu GC.6.1: „Governance und Compliance MUSS den nachvollziehbar abgegrenzten Geltungsbereich nach Freigabe der Institutionsleitung festlegen.“ Der Katalog verwendet für den Anwendungsbereich das Wort Geltungsbereich. Gemeint ist damit der formale Rahmen aus 300-1 Kapitel 2.3, nicht der Geltungsbereich im Sinne von 200-2, der dort dem Informationsverbund entspricht.
Der Anwendungsbereich umfasst nach Kapitel 2.3 Geschäftsprozesse, relevante Institutionseinheiten, Standorte, Anwendungen und IT-Systeme. Wichtig ist, dass die betrachteten Geschäftsprozesse vollständig enthalten sind. Das galt schon in 200-2, wo es heißt, die betrachteten Geschäftsprozesse müssten „komplett im Geltungsbereich enthalten“ sein. Ausgeschlossene Bereiche dürfen ausdrücklich benannt werden, um die Grenze klarer zu ziehen.
Für die Praxis heißt das: Zuerst entscheidet die Leitung, welche Institutionsbereiche, Standorte und Geschäftsprozesse das ISMS umfasst. Danach wird für diesen Rahmen beschrieben, welche Assets dazugehören und wo die technischen, organisatorischen und räumlichen Grenzen verlaufen. Mehrere Informationsverbünde innerhalb eines Anwendungsbereichs bieten sich an, wenn Bereiche technisch weitgehend getrennt betrieben werden, etwa ein Fachverfahren mit eigener Infrastruktur neben der allgemeinen Verwaltungs-IT.
Die vier Prüffragen des Standards
Für die Identifikation der relevanten Assets verlangt Kapitel 3.1, dass vier Fragenblöcke beantwortet und dokumentiert werden. Sie sind zugleich die Gliederung jeder belastbaren Abgrenzung. Wortlaut nach BSI-Standard 300-1, Kap. 3.1, S. 13:
- Organisatorische und personelle Zuordnung: „Welche Institutionsbereiche, Rollen und Personen gehören zum Geschäftsprozess?“
- Technische Zuordnung: „Welche Anwendungen, Systeme und Netze sind Bestandteil des Informationsverbundes?“ „Wo verlaufen die technischen Grenzen und wie sind Schnittstellen zu externen Systemen gestaltet?“
- Infrastrukturelle Zuordnung: „Welche Standorte, Gebäude und Räumlichkeiten gehören zum Informationsverbund?“
- Outsourcing-Abgrenzung: „Welche organisatorischen, technischen und infrastrukturellen Teile werden lokal betrieben und welche werden an externe Parteien ausgelagert?“ „Welche Cloud-Dienste werden genutzt?“
Außerdem verlangt derselbe Abschnitt, alle Übergänge nach außen festzuhalten: zu externen Prozessen und Systemen und zu anderen Informationsverbünden, jeweils auf organisatorischer, technischer und räumlicher Ebene (Kapitel 3.1, „Dokumentation und Schnittstellen“). Für die Dokumentation dürfen vorhandene Assetdaten und digital erfasste Systemdaten genutzt werden. Wie Sie diese Bestände auswerten, beschreibt die Seite Strukturanalyse.
Scope-Arbeitsblatt: Abgrenzung in einer Tabelle
Das folgende Arbeitsblatt fasst die Vorgaben aus 300-1 und den Katalog-Anforderungen in prüfbare Felder. Die rechte Spalte zeigt Einträge für ein fiktives Beispiel: eine Förderstelle eines Landes, die mit dem Geschäftsprozess „GP-01 Förderanträge bearbeiten“ als erstem Prozess startet. Name, Systeme und Dienstleister sind erfunden.
| Feld | Leitfrage | Fundstelle | Fiktives Beispiel |
|---|---|---|---|
| Anwendungsbereich | Welche Institutionsbereiche, Standorte und Geschäftsprozesse umfasst das ISMS? Wann hat die Leitung das freigegeben? | 300-1 Kap. 2.3, 2.10; GC.6.1 | Gesamte Förderstelle, ein Standort; Leitungsbeschluss vom TT.MM.JJJJ |
| Betrachtete Geschäftsprozesse | Welche Prozesse liegen im Informationsverbund, und sind sie vollständig enthalten? | 300-1 Kap. 2.3, 2.5 | GP-01 Förderanträge bearbeiten (erster Zyklus), weitere Prozesse folgen |
| Organisation und Personen | Welche Bereiche, Rollen und Personen wirken am Prozess mit? | 300-1 Kap. 3.1 Frage 1 | Referat Förderung, Fachadministration, IT-Betrieb, externe Entwickler des Portals |
| Technik | Welche Anwendungen, Systeme und Netze gehören dazu? Wo verläuft die technische Grenze? | 300-1 Kap. 3.1 Frage 2 | Förderportal, Fachverfahren, Virtualisierungsplattform, Verwaltungsnetz; Grenze an der Firewall zum Landesnetz |
| Infrastruktur | Welche Standorte, Gebäude und Räume gehören dazu? | 300-1 Kap. 3.1 Frage 3 | Dienstgebäude, Serverraum, Büroflächen des Referats |
| Auslagerung und Cloud | Was wird lokal betrieben, was ausgelagert? Welche Cloud-Dienste? | 300-1 Kap. 3.1 Frage 4 | Portal-Hosting als IaaS bei einem Dienstleister; Fachverfahren im eigenen Serverraum |
| Externe Schnittstellen | Welche organisatorischen, technischen und räumlichen Übergänge zu externen Prozessen, Systemen und anderen Verbünden gibt es? | 300-1 Kap. 3.1; STM.1.2 | Datenübergabe an die Landeskasse, Internetanbindung, Wartungszugang des Portal-Dienstleisters |
| Ausgeschlossene Bereiche | Was gehört bewusst nicht dazu, und warum? | 300-1 Kap. 2.3 | Kantinenabrechnung (eigener Dienstleister, keine Verbindung zum Verwaltungsnetz) |
| Verantwortung | Wer ist für Verbund und Schnittstellen zuständig? | 300-1 Kap. 2.8 | ISB koordiniert, Referatsleitung als Prozessverantwortliche |
| Änderungsauslöser | Welche Änderungen erzwingen eine neue Abgrenzung? | 300-1 Kap. 5.5 | neuer Dienstleister, neuer Standort, neuer Geschäftsprozess |
Die Spalte „Änderungsauslöser“ ist unsere Ergänzung. Der Standard verlangt in Kapitel 5.5, Änderungen im Informationsverbund bei der Validierung der Anforderungen zu berücksichtigen; mit festen Auslösern erkennen Sie solche Änderungen, bevor ein Audit sie findet.
Grenzfälle und wie Sie sie dokumentieren
Grenzfälle entstehen vor allem dort, wo ein Geschäftsprozess die eigene Organisation verlässt oder wo Infrastruktur mit Bereichen außerhalb des Anwendungsbereichs geteilt wird. Der Standard gibt dafür keine Einzelfallregeln vor. Er verlangt aber, dass die Abgrenzung nachvollziehbar ist und die Schnittstellen dokumentiert sind. Die Behandlungsvorschläge in der Tabelle sind unsere Einschätzung, wie sich das prüfbar umsetzen lässt.
| Grenzfall | Frage | Vorschlag zur Behandlung | Anknüpfung in 300-1 |
|---|---|---|---|
| SaaS-Anwendung für einen Prozess im Scope | Liegt der Dienst innerhalb oder außerhalb des Verbunds? | Als Asset aufnehmen und der Zielobjektkategorie Cloud-Dienste zuordnen; Vertrag, Schnittstellen und Verantwortungsteilung dokumentieren | Kap. 3.1 Frage 4; Anhang 1 (Cloud-Dienste) |
| Server stehen im Rechenzentrum eines Dienstleisters (Housing) | Gehört der fremde Raum zum Verbund? | Die eigenen Systeme gehören dazu, die Leistung des Dienstleisters wird als Outsourcing erfasst; Raum- und Zutrittsfragen über den Vertrag und dessen Nachweise abbilden | Anhang 1 (Outsourcing, Beispiel „RZ-Housing“) |
| Gemeinsamer Verzeichnisdienst mit Bereichen außerhalb des Scopes | Muss der ganze Verzeichnisdienst in den Verbund? | Der Verzeichnisdienst ist für die Anmeldung im Prozess nötig und gehört damit als Asset dazu; die Grenze zu den übrigen Nutzenden als Schnittstelle beschreiben | Kap. 3.1 Frage 2; Anhang 1 (Verzeichnisdienste) |
| Externe Entwickler oder Berater mit Zugang | Sind das Personen des Verbunds? | Ja, wenn sie regelmäßig Assets nutzen können; als Nutzende erfassen | Anhang 1 (Nutzende, Beispiel „externe Berater“) |
| Mobiles Arbeiten und Homeoffice | Zählen private Räume zum Verbund? | Die mobilen Endgeräte gehören dazu; für Räume außerhalb der Liegenschaft die Regelung zum mobilen Arbeiten als Grenze dokumentieren | Kap. 3.1 Frage 3; Anhang 1 (Mobile Endgeräte) |
| Papierakten und Archiv | Gehören analoge Informationen dazu? | Ja, wenn der Prozess sie verarbeitet; Akten als Informationen bzw. Daten, Lagerräume als Datenträgerarchiv erfassen | Anhang 1 (Daten, Beispiel „Aktenordner“; Datenträgerarchiv) |
| Datenübergabe an eine andere Behörde oder einen Partner | Wo endet der Verbund? | An der eigenen Übergabestelle; Leitung und Übergabe als externer Netzanschluss und als Schnittstelle zu einem externen Prozess dokumentieren | Kap. 3.1; Anhang 1 (Externe Netzanschlüsse); STM.1.2 |
| Start mit nur einem Geschäftsprozess | Ist ein schmaler erster Verbund zulässig? | Ja, als erster Zyklus; die übrigen Prozesse des Anwendungsbereichs sind schrittweise zu untersuchen, das gehört in den Plan | Kap. 2.6 |
Wie groß der erste Informationsverbund sein sollte
300-1 empfiehlt in Kapitel 2.6, bei der erstmaligen Implementierung mit dem wichtigsten Geschäftsprozess aus der höchsten Schutzbedarfskategorie zu beginnen. Sukzessive sind alle Geschäftsprozesse des Anwendungsbereichs zu untersuchen. Die Erläuterung zur Katalog-Anforderung STM.2.1.2 ergänzt, dass es im ersten Durchgang des PDCA-Zyklus ausreicht, die Assets für den wichtigsten Geschäftsprozess zu erfassen; weitere Prozesse können in Folgezyklen oder parallel hinzukommen.
Ein enger erster Verbund ist damit methodisch gedeckt, die übrigen Prozesse kommen in späteren Zyklen dazu. Wenn der Anwendungsbereich die ganze Institution umfasst, gehört in die Entscheidungsvorlage an die Leitung auch die Reihenfolge, in der die übrigen Geschäftsprozesse folgen. Nach Kapitel 2.10 ist die Festlegung dieser Reihenfolge ebenfalls eine Leitungsentscheidung.
Ein typischer Fehler ist ein Verbund, der nach der Organisationsstruktur geschnitten ist, während der Prozess quer dazu läuft. Wenn ein Antrag im Fachreferat beginnt, über die IT eines Dienstleisters läuft und in der Kasse endet, muss der Verbund diesen Weg abbilden oder die Übergänge als Schnittstellen festhalten. Ein Zuschnitt nach Organisationsstrukturen ist nach Kap. 3.1 zulässig. Dann müssen aber die Übergänge des Prozesses in andere Bereiche als Schnittstellen dokumentiert sein, und im Anwendungsbereich muss der Prozess vollständig enthalten sein (Kap. 2.3).
Was nach der Abgrenzung folgt
Mit der Abgrenzung steht fest, für welche Assets Sie anschließend Abhängigkeiten dokumentieren. Wie tief das geht, hängt nach Kapitel 3.2 vom Schutzbedarf des Geschäftsprozesses ab: Bei hohem Schutzbedarf wird die Zugehörigkeit der Assets zum Prozess mit ihren Abhängigkeiten dokumentiert, bei normalem Schutzbedarf mindestens die Abhängigkeiten zwischen Anwendungen und IT-Systemen sowie zwischen IT-Systemen und Räumen.
Die nächsten Schritte haben jeweils eine eigene Seite:
- Schutzbedarf je Geschäftsprozess festlegen: Schutzbedarfsfeststellung
- Assets aus CMDB, Netzplan und Asset-Register erfassen: Strukturanalyse und Asset-Erfassung
- Assets Zielobjektkategorien zuordnen und das Anforderungspaket bilden: Modellierung mit Zielobjektkategorien
- Bestehende Abgrenzung aus einem Grundschutz-ISMS überführen: Migration nach Grundschutz++
Blackfort Technology unterstützt bei der Abgrenzung und bereitet die Entscheidungsvorlage für die Leitung vor. Mehr dazu auf der Seite Beratung.
Rechtehinweis: Zitate aus BSI-Standard 300-1 © Bundesamt für Sicherheit in der Informationstechnik 2026, Quelle: BSI-Standard 300-1 „Methodik Grundschutz++“, Version 1.0 vom 20.10.2026, https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Grundschutz-in-der-Informationssicherheit/Grundschutz-Plus-Plus/grundschutz-plus-plus_node.html. Zitate aus BSI-Standard 200-2 © Bundesamt für Sicherheit in der Informationstechnik, Quelle: BSI-Standard 200-2 „IT-Grundschutz-Methodik“, Version 1.0, https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-2-IT-Grundschutz-Methodik/bsi-standard-200-2-it-grundschutz-methodik_node.html. Sie stehen nicht unter CC BY-SA 4.0; der Lizenzhinweis am Seitenende gilt nur für die Auszüge aus den Katalogdaten.