Grundschutz++ Strukturanalyse

Diese Seite ist derzeit noch ein Entwurf.

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

Die Strukturanalyse nach Grundschutz++ beschreibt den organisatorischen, fachlichen und technischen Rahmen eines Informationsverbundes. Sie konsolidiert alle relevanten Informationen zu Kontext, Prozessen, Assets und Anforderungen und dient als zentrales Referenzdokument für Umsetzung, Audits und kontinuierliche Verbesserung.

Einleitung

Die Strukturanalyse nach Grundschutz++ beschreibt den organisatorischen, fachlichen und technischen Rahmen eines Informationsverbundes und bildet die Grundlage für ein systematisches ISMS nach der GS++‑Methodik. Sie verbindet die Ergebnisse aus Erhebung & Planung (Prozessschritt 1) mit der Anforderungsanalyse (Prozessschritt 2) und stellt alle relevanten Informationen zu Kontext, Stakeholdern, Geschäftsprozessen, Assets und Anforderungen strukturiert dar. Das Dokument dient als zentrales Referenzwerk für Modellierung, Umsetzung, Überwachung und kontinuierliche Verbesserung des ISMS. Es schafft Transparenz, Nachvollziehbarkeit und eine konsistente Basis für Audits, Risikoanalysen und die spätere technische Umsetzung.

Geltungsbereich

Die Organisation betreibt ihr Informationssicherheits-Managementsystem (ISMS) gemäß BSI Grundschutz++.

Die beschriebenen Regelungen sind für alle Mitarbeitenden und Dienstleistenden verbindlich, die im Rahmen des ISMS für die Organisation tätig sind.

Diese Strukturanalyse gilt für den im Titel genannten, im Folgenden beschriebenen und abgegrenzten Informationsverbund der Organisation.

Definition des Geltungsbereichs

Im Folgenden werden der Informationsverbund und seine Abgrenzung innerhalb der Organisation beschrieben.

Beschreibung des Informationsverbunds

Kurze Beschreibung des Informationsverbunds: Was zeichnet ihn aus, welchen Zweck erfüllt er, welche Anwendungen bedient er, welche Nutzergruppen bedient er ...

Eingliederung des Informationsverbunds

Es ist darzustellen, wie der Informationsverbund innerhalb der Organisation aufgebaut ist (organisationsübergreifender Verbund oder Verbund innerhalb einer Abteilung).

Abgrenzung des Informationsverbunds

Beschreibung der Grenzen des Informationsverbunds sowie der Bereiche außerhalb des Verbunds.

Beispiel:

Entwicklungs-, Test- und Freigabesysteme: Komponenten, die ausschließlich der Entwicklung, dem Test und der Freigabe dienen, werden abgegrenzt.
Client-Systeme der Benutzer: Alle nicht-administrativen Client-Systeme werden über einen Frontend-Server abgegrenzt.
Netzinfrastruktur außerhalb der Organisation: Alle Netze außerhalb des Informationsverbundes (Internet, Fremdnetze, Bürokommunikationsnetze) sind über ein Security-Gateway abgegrenzt.
Gebäudeinfrastruktur für extern betriebenes Rechenzentrum: Das Rechenzentrum des Dienstleisters, in dem der Informationsverbund betrieben wird, ist selbst nach BSI IT-Grundschutz zertifiziert. Der Schutzbedarf entspricht dem des Informationsverbundes. Damit ist der Rechenzentrumsbetrieb abgegrenzt.
Reine Bürokommunikationssysteme wie Telefonie, Drucker, Smartphones und Tablets sind abgegrenzt.
…

Für abgegrenzte Bereiche muss die Grenze zum Informationsverbund sowie der Übergang und dessen Absicherung beschrieben sein.

Werden elementare Bestandteile des Informationsverbunds (z.B. ein angemietetes externes Rechenzentrum) abgegrenzt, muss beschrieben sein, wie sichergestellt wird, dass diese Teile dem festgestellten Schutzbedarf des Informationsverbunds in gleichem Maße entsprechen (z.B. in Form einer eigenen Zertifizierung, vertraglicher Regelungen und eigener Audits dieser Teile).

Betrachtete Standorte

Physische Standorte
Remote-Arbeitsplätze
Rechenzentren

Kontext der Organisation

Das folgende Kapitel beschreibt den Kontext der Organisation gemäß Prozessschritt 1 Erhebung und Planung (Governance/Compliance) der Methodik zum Grundschutz++.

Beschreibung der Organisation

Beschreibung der Organisation und ihrer Ziele.

Rechtliche Rahmenbedingungen

Kurze Darstellung der wesentlichen rechtlichen Rahmenbedingungen der Organisation (Konkretisierung im Kapitel Compliance).

Geschäftsfeld

Beschreibung des Tätigkeitsbereichs der Organisation (Was macht die Organisation wo ist ihr Kerngeschäft?)

Organisationsplan

Darstellung des Geschäftsverteilungsplans der Organisation (Organigramm)

Managementrahmen des ISMS

Ziele, IS-Leitlinien, IS-Strategie, Verantwortlichkeiten, Dokumentationsprinzipien, KVP.

Layer- und Werkzeugkonzept

Eingesetzte GS++-Layer (Basis, Technik, Beispiel, Audit) und verwendete Tools.

Interessierte Parteien (PS 1)

Das folgende Kapitel beschreibt die Interessierten Parteien gemäß Prozessschritt 1 Erhebung und Planung (Governance/Compliance) der Methodik zum Grundschutz++.

Identifizierte interessierte Parteien

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.

Liste der identifizierten interessierten Parteien:

Interessierte Partei	Typ	Rolle / Beschreibung	Erwartungen an Informationssicherheit	Relevanz	Verbindliche Verpflichtung	Konsequenz für ISMS	Rechtsgrundlage / Quelle	Betroffene Prozesse	Verantwortliche Rolle
Wer ist die Partei?	intern/extern	Warum ist sie relevant?	Was erwartet sie konkret?	Einfluss auf ISMS	Ja/Nein	Welche Anforderungen entstehen?	Gesetz, Vertrag, Richtlinie	Welche Prozesse sind betroffen?	Wer kümmert sich?
Beispiele:
Datenschutz-Aufsichtsbehörde	extern	Regulatorische Überwachung	DSGVO‑Konformität, Nachweise, Meldepflichten	hoch	Ja	Datenschutzanforderungen, TOMs, Meldeprozesse	DSGVO, BDSG	Datenverarbeitung, HR, IT‑Betrieb	Datenschutzbeauftragte
Kunden / Auftraggeber	extern	Empfänger von Dienstleistungen	Verfügbarkeit, Integrität, SLA‑Einhaltung	mittel	Ja	SLA‑Monitoring, Incident‑Reporting	Vertrag, SLA	Service‑Prozesse, Support	Service Owner
Mitarbeitende	intern	Nutzung von Systemen, Verarbeitung von Daten	Klare Regeln, sichere Systeme, Schulungen	mittel	Ja	Awareness‑Programm, Zugriffsregeln	Arbeitsvertrag, interne Richtlinien	Alle operativen Prozesse	ISB / HR
...

Erwartungen und Anforderungen

Erwartungen an Verfügbarkeit, Vertraulichkeit, Integrität, Nachweise, Reaktionszeiten.

Bewertung der Relevanz

Priorisierung gemäß GS++.

Verbindliche Verpflichtungen

Welche Erwartungen werden ins ISMS übernommen.

Compliance-Rahmen (PS 1)

Das folgende Kapitel beschreibt den Compliance-Rahmen der Organisation gemäß Prozessschritt 1 Erhebung und Planung (Governance/Compliance) der Methodik zum Grundschutz++. Dabei unterscheiden wir:

Gesetzliche Verpflichtungen:

DSGVO, HGB, branchenspezifische Vorgaben.

Mögliche rechtliche, regulatorische Rahmenbedingungen sind im Artikel Rechtsgrundlagen aufgelistet.

Vertragliche Verpflichtungen:

SLAs, NDAs, Kundenanforderungen.

Interne Vorgaben:

Richtlinien, Policies, Betriebsvereinbarungen. Liste der rechlichen, vertraglichen und internen Vorgaben:

Quelle	Referenz	Betroffener Bereich	Relevanz für ISMS / IV
Gesetz	DSGVO (EU‑Datenschutz‑Grundverordnung, z.B. Art. 5, 25, 32)	Verarbeitung personenbezogener Daten in Fachverfahren, Portalen, Logs	Vorgibt Schutzziele und technische/organisatorische Maßnahmen für Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit; fließt in Schutzbedarf, Praktiken (z.B. Berechtigungsmanagement, Logging) und ergänzende Anforderungen ein.
Vertrag	Auftragsverarbeitungsvertrag (AVV) nach DSGVO Art. 28	Outsourcing von IT‑Betrieb, Cloud‑Dienste	Definiert technische und organisatorische Maßnahmen, Audit‑ und Informationsrechte; Anforderungen sind als externe Verpflichtungen in das Anforderungspaket zu übernehmen.
Vertrag	Service Level Agreement (SLA) mit Verfügbarkeitszielen	Betrieb von Fachanwendungen, Rechenzentrum	Erhöht Anforderungen an Verfügbarkeit und Wiederanlauf; kann zu höherem Schutzbedarf und strengeren Maßnahmen in den Praktiken (Backup, Notfallmanagement) führen.
Intern	Informationssicherheitsleitlinie	gesamte Institution	Setzt interne Mindestanforderungen (z.B. „alle sicherheitsrelevanten Änderungen sind zu dokumentieren“); bildet Grundlage für ISMS‑Anforderungen (Governance, Rollen, Dokumentation).
...	...	...	...

Sicherheitsorganisation (PS 1)

Das folgende Kapitel beschreibt den den Aufbau der Sicherheitsorganisation im ISMS der Organisation gemäß Prozessschritt 1 Erhebung und Planung (Governance/Compliance) der Methodik zum Grundschutz++.

Rollen und Verantwortlichkeiten

In der Organisation sind folgende Verantwortliche als Teil der Sicherheitsorganisation benannt:

Organisationsleitung

Die Leitung der Organisation trägt die Gesamtverantwortung für die Informationssicherheit der Organisation und hat klare Ziele für die Informationssicherheit definiert. Diese Leitlinien bilden die Grundlage für alle Maßnahmen im Informationsverbund. Die übergreifenden Aufgaben der Leitung bestehen im Wesentlichen darin:

Festlegung von messbaren Sicherheitszielen
Verantwortlichkeiten zu delegieren
Ressourcen bereitzustellen
Sicherheitskultur in der Organisation zu fördern
Bewertung der Risiken für die Organisation
Compliance und Rechenschaftspflicht erfüllen
Überwachung und Bewertung der Zielerreichung

Informationssicherheitsbeauftragter

Die Organisation hat einen Informationssicherheitsbeauftragten (ISB) ernannt.

Der Informationssicherheitsbeauftragte ist für den Aufbau und die Koordination des ISMS verantwortlich und untersteht als Stabsstelle direkt der Organisationsleitung.

Seine Aufgaben sind u.a.:

Berichterstattung und Beratung der Leitung zu Belangen der Informationssicherheit
Koordination der Schulungen und Sensibilisierung der Mitarbeitenden zur Informationssicherheit
Entwicklung und Fortschreibung der Sicherheitskonzeption der Organisation
Begleitung und Auswertung von Sicherheitsvorfällen
Begleitung der Einführung neuer Verfahren und Anwendungen

Der ISB verfügt über die zur Erfüllung seiner Aufgaben notwendigen Kenntnisse und Ressourcen.

Datenschutzbeauftragter

Die Organisation hat einen Datenschutzbeauftragten (DSB) bestellt. Der DSB ist in die Entwicklung des Informationsverbundes eingebunden und bearbeitet alle Fragen des Datenschutzes in einem eigenen DSMS.

weitere Verantwortliche

Ggf. weitere Verantwortlich und ihre Rollen für die Informationssicherheit im Informationsverbund z.B:

Fach- und Verfahrensverantwortliche
Leitung IT-Betrieb / Rechenzentrum
Notffallbeauftragter
...

Entscheidungswege

Freigaben, Eskalationen, Reporting.

Kommunikationswege

Wie wird Informationssicherheit in der Organisation kommuniziert.

Dokumentation und Ablage des ISMS

Dokumentationsform, Ablageorte, Versionierung, Zugriffsregelungen.

Vorgehensweise zur Anwendung von GS++ und Freigabe

Die Organisation betreibt ihr Informationssicherheits-Managementsystem (ISMS) gemäß BSI Grundschutz++.

Beschreibung des Vorgehensmodells, Iterationslogik, Freigabe durch die Leitung.

Informationssicherheitseinstufung (PS 1)

Das folgende Kapitel beschreibt die Informationssicherheitseinstufung der relevanten Geschäftsprozesse der Organisation gemäß Prozessschritt 1 Erhebung und Planung (Governance/Compliance) der Methodik zum Grundschutz++.

Identifizierte Geschäftsprozesse

Ein Geschäftsprozess ist eine systematische Abfolge von Aktivitäten, um ein bestimmtes Geschäftsziel zu erreichen. Die relevanten Geschäftsprozesse des Informationsverbunds sind im folgenden aufgeführt.

Kernprozesse

Kernprozesse sind die zentralen Prozesse der Organisation, die direkt zur Wertschöpfung beitragen und damit essentiell für das Kerngeschäft sind. Sie stellen die Haupttätigkeiten dar, die die Organisation ausführen muss, um seine Produkte oder Dienstleistungen zu erstellen oder bereitzustellen.

Tabelle der Kernprozesse
Kürzel	Prozessname	Beschreibung	Verantwortlich
KP-1	Beispiel	Beispiel	Beispiel
KP-2	Beispiel	Beispiel	Beispiel

Hilfsprozesse

Hilfsprozesse, oder auch Supportprozesse genannt, sind Prozesse, die nicht direkt zur Wertschöpfung beitragen, sondern die Organisation in seiner Tätigkeit unterstützen und optimieren sollen. Sie stellen damit eine indirekte Unterstützung des Kerngeschäfts dar.

Tabelle der Hilfsprozesse
Kürzel	Prozessname	Beschreibung	Verantwortlich
HP-1	Beispiel	Beispiel	Beispiel

Kritikalität / Sicherheitsniveau

Eine angemessene Bestimmung des Sicherheitsniveaus ist wichtig, um die Ressourcen der Organisation effektiv zu nutzen und sicherzustellen, dass die Schutzmaßnahmen den Bedrohungen und Risiken angemessen sind. Das folgende Sicherheitsniveau wurde im Rahmen einer Informationssicherheitseinstufung (siehe Anlage A2) für die genannten Geschäftsprozesse ermittelt:

Tabelle des Sicherheitsniveaus
Prozess	Vertraulichkeit	Integrität	Verfügbarkeit	Gesamt
KP-1	normal	normal	normal	normal
KP-2	hoch	normal	normal	hoch
HP-1	normal	normal	hoch	hoch

Priorisierung

Aufgrund eines hohen Sichereitsniveaus, werden die Prozesse KP-2 und HP-1 priorisiert behandelt.

Überprüfung des gesetzten Sicherheitsniveaus

Verfahren und Kriterien zur regelmäßigen Überprüfung der Angemessenheit.

7. Informationsverbund (GS++ Prozessschritt 2)

7.1 Definition des Informationsverbunds

Fachliche und organisatorische Einheit.

7.2 Eingliederung in die Organisation

Einbettung in die Gesamtorganisation.

7.3 Abhängigkeiten

Interne und externe Abhängigkeiten.

8. Geschäftsprozesse (GS++ Prozessschritt 2)

8.1 Kernprozesse

Beschreibung, Ziele, Abhängigkeiten.

8.2 Unterstützungsprozesse

IT-Betrieb, HR, Einkauf etc.

8.3 Schutzbedarf / Sicherheitsniveau

Ergebnis der Einstufung.

9. Asset-Modellierung (GS++ Prozessschritt 2)

9.1 Erfasste Assets

Informationen, Anwendungen, Systeme, Räume, Rollen, Dienste.

9.2 Zuordnung zu Zielobjektkategorien

Gemäß GS++ Abschnitt 3.4.2.

9.3 Vererbung von Zielobjektkategorien

Gemäß GS++ Abschnitt 3.5.1.

9.4 Assets ohne Anforderungen

Identifikation anforderungsloser Assets und Begründung.

10. Anforderungen (GS++ Prozessschritt 2)

10.1 Ableitung aus Praktiken

Welche Praktiken sind relevant.

10.2 Zuordnung zu Zielobjekten

Welche Anforderungen gelten für welche Assets.

10.3 Konsolidierung

Redundanzprüfung, Zusammenführung.

10.4 Ergänzende Anforderungen

Aufgrund anforderungsloser Assets
Aufgrund externer Verpflichtungen

10.5 Gestaltungsentscheidungen (Parameter)

Gestaltungsentscheidungen konkretisieren die generischen GS++-Anforderungen für die Institution. Sie legen fest, wie Anforderungen organisatorisch, technisch und prozessual umgesetzt werden sollen. Dazu gehören Rollen, Werte, Fristen, Verfahren und technische Parameter, die für Umsetzung, Überwachung und Auditierbarkeit notwendig sind. Die folgenden Parameter stellen die institutionenspezifischen Festlegungen dar, die im Rahmen der Anforderungsanalyse getroffen wurden.

Parameter	Beschreibung	Zugehörige Anforderung(en)	Verantwortliche Rolle	Wert / Entscheidung
Passwortlänge	Mindestanforderung an Authentisierung	PRA-XXX	IT-Betrieb	14 Zeichen
Backup-Frequenz	Intervall für Datensicherungen	OPS-ZZZ	IT-Betrieb	täglich, 02:00 Uhr
Löschfristen	Aufbewahrungs- und Löschregeln	DSGVO, LOG-ABC	Datenschutz	6 Monate
Logging-Level	Umfang der Protokollierung	MON-123	IT-Security	„Security-relevant“
Rollenmodell	Verantwortlichkeiten im ISMS	GOV-001	ISB	ISB, IT-Leitung, Prozessowner

10.6 Verteilung der führenden Zuständigkeiten

Zuordnung führender Verantwortlichkeiten zu Praktiken, Zielobjektkategorien und wesentlichen Anforderungen.

10.7 Wirksamkeitsprüfung der Anforderungen

Verfahren, Kriterien und Dokumentation zur Prüfung der Wirksamkeit.

11. Risikomanagement und Risikobetrachtung (GS++ Prozessschritt 2)

11.1 Risikomanagement-Rahmen

Bewertungsmethode, Risikokriterien, Risikokategorien, Rollen, Umgang mit Restrisiken.

11.2 Identifizierte Risiken

Risiken aus Anforderungen, Prozessen, Assets.

11.3 Bewertung

Eintrittswahrscheinlichkeit, Auswirkung.

11.4 Risikobehandlung

Akzeptieren, reduzieren, vermeiden, übertragen.

12. Infrastruktur (optional)

12.1 Netzplan

Übersicht der Netzsegmente.

12.2 Komponentenlisten

Server, Clients, Netzwerkgeräte.

12.3 Technische Räume

Rechenzentren, Serverräume.

13. Dienstleister / Zulieferer

13.1 Externe Dienstleister

Cloud, Hosting, Support.

13.2 Sicherheitsrelevante Abhängigkeiten

Welche Anforderungen gelten.

14. Schnittstellen zu anderen Managementsystemen

14.1 Datenschutz-Management

Abstimmung mit Datenschutzanforderungen und -prozessen.

14.2 Business Continuity / Notfallmanagement

Schnittstellen zu BCM/Notfallkonzepten.

14.3 Qualitätsmanagement und IT-Service-Management

Abhängigkeiten und gemeinsame Prozesse.

14.4 Audit- und Compliance-Management

Verzahnung mit internen und externen Audits sowie Compliance-Prozessen.

15. Anlagen

Organigramm
Prozesslandkarte
Asset-Listen
Zielobjektkategorien
Anforderungspaket
Risikoanalyse-Matrix