- BSI-Standard 200-2 beschreibt den IT-Grundschutz als Vorgehensmodell: Geltungsbereich festlegen, Strukturanalyse, Schutzbedarf bestimmen, Bausteine modellieren, Umsetzungsstand prüfen.
- Drei Absicherungsstufen bieten flexible Einstiegspfade: Basis-Absicherung für den schnellen Start, Standard-Absicherung für vollständigen Grundschutz, Kern-Absicherung für die „Kronjuwelen”.
- Der IT-Grundschutz-Check übersetzt den Soll-Katalog in ein prüfbares Lagebild – Grundlage für Maßnahmenplanung, Priorisierung und Reporting.
- Jira, Confluence & Assets bilden den Grundschutz-Prozess operativ ab: Anforderungen als Tickets, Nachweise in Confluence, Informationsverbund und Schutzbedarf in Assets.
- Honicon übersetzt die BSI-Methodik in Atlassian-Workflows – für klare Verantwortlichkeiten, prüfbare Umsetzung und beherrschbaren Aufwand.
Informationssicherheit steht längst nicht mehr nur im Rechenzentrum. Kunden verlangen belastbare Nachweise, Aufsichtsgremien erwarten Steuerung, interne Revision fordert Konsistenz. In vielen Organisationen dominieren Einzelmaßnahmen: eine Richtlinie im Intranet, ein Tool für Schwachstellen, ein Auditprojekt kurz vor dem Stichtag. Genau diese Zersplitterung erzeugt Reibung – und am Ende fehlt der rote Faden zwischen Risiko, Maßnahme und Nachweis.
Der BSI-Standard 200-2 setzt an der Methodik an. Er beschreibt den IT-Grundschutz als Vorgehensmodell für Aufbau und Betrieb eines ISMS nach BSI-Grundschutz. Im Zentrum steht ein Prozess, der Anforderungen in nachvollziehbare Schritte übersetzt: Geltungsbereich festlegen, Informationsverbund strukturieren, Schutzbedarf bestimmen, Anforderungen modellieren, Umsetzungsstand prüfen, Maßnahmen planen, Wirksamkeit nachhalten. So entsteht aus Bausteinen kein Papiergebirge, sondern ein Sicherheitskonzept mit klarer Reihenfolge und klaren Artefakten.
Der Fahrplan – Scope, Informationsverbund, Schutzbedarf
Am Anfang steht der Geltungsbereich, im Grundschutz als Informationsverbund gefasst. Der Standard verlangt eine eindeutige Abgrenzung: Welche Geschäftsprozesse, Anwendungen, IT-Systeme, Räume und Kommunikationsverbindungen gehören dazu? Diese Entscheidung wirkt wie eine Weichenstellung. Ein übergroßer Verbund frisst Kapazität, ein zu kleiner Verbund lässt Risiken außerhalb des Blickfelds. Eine saubere Scope-Definition liefert Klarheit, Verantwortlichkeit und realistische Planung.
Darauf folgt die Strukturanalyse. Sie ordnet die Elemente so, dass Abhängigkeiten sichtbar bleiben: welche Anwendung auf welcher Plattform läuft, welche Schnittstellen Daten transportieren, welche Räume physische Sicherheit benötigen, welche Netze welche Zonen verbinden. In dieser Phase treten typische Konflikte offen zutage: unklare Ownership für Fachanwendungen, widersprüchliche Systemnamen, fehlende Übersicht über Kommunikationsbeziehungen. Der Standard erzwingt Klärung und schafft damit belastbare Zuständigkeiten und eine gemeinsame Sprache für IT, Fachbereiche und Audit.
Auf diese Landkarte setzt die Schutzbedarfsfeststellung auf. Der Standard fordert eine Bewertung entlang der Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit. Entscheidend wirkt Priorisierung: Welche Informationen treiben Umsatz, Produktion oder Versorgung? Welche Services sichern Lieferfähigkeit, Zahlungsverkehr oder Kundenservice? Aus dieser Bewertung folgen Schutzbedarfsklassen und damit eine Reihenfolge für Kontrollen und Umsetzung. In der Praxis endet hier das Bauchgefühl. Sicherheitsarbeit erhält dadurch Prioritäten, die sich auch gegenüber Budget, Zeit und Ressourcen begründen lassen.
Von Bausteinen zur Umsetzung – Modellierung und Grundschutz-Check
Jetzt rückt das IT-Grundschutz-Kompendium in den Fokus. Die Modellierung verknüpft die Elemente des Informationsverbunds mit passenden Bausteinen und Anforderungen. Ein mobiler Arbeitsplatz folgt anderen Anforderungen als ein Serverraum, eine Fachanwendung anderen Anforderungen als eine Netzwerkkomponente. Mit dieser Zuordnung entsteht ein strukturierter Soll-Katalog: Für jedes Objekt liegt eine definierte Menge an Anforderungen vor, inklusive Bezug zum Schutzbedarf und einer klaren Zuständigkeit.
Der Standard beschreibt drei Vorgehensweisen, die unterschiedliche Einstiegspfade eröffnen. Basis-Absicherung adressiert den Einstieg und fokussiert priorisierte Anforderungen als Fundament. Standard-Absicherung bildet den vollständigen Grundschutz-Prozess ab und zielt auf durchgängige Absicherung des Informationsverbunds. Kern-Absicherung setzt den Schwerpunkt auf besonders schützenswerte Werte, oft als „Kronjuwelen“ bezeichnet, etwa zentrale Produktionssteuerung, Zahlungsprozesse oder Plattformen mit sensiblen Daten oder hoher Verfügbarkeit.
Moderne IT-Landschaften verschieben Verantwortlichkeiten – und genau dort gewinnt die Modellierung an Bedeutung. Cloud-Betrieb, Virtualisierung, Plattformservices oder SaaS-Modelle verteilen Kontrollen auf mehrere Ebenen: Identity Provider, Plattform-Logging, Endpoint-Management, Provider-Vertrag, interne Prozesse. Eine präzise Zuordnung trennt Provider-Aufgaben von internen Aufgaben und definiert Kontrollpunkte dort, wo Einfluss realistisch bleibt. Beispielhaft: MFA und Rollenmodelle liegen oft im Identity Provider, Gerätehärtung im Endpoint-Management, Logging folgt einem abgestimmten Pfad bis ins SIEM. Ohne diese Trennung entstehen Lücken – oder Doppelarbeit ohne zusätzlichen Sicherheitsgewinn.
Der IT-Grundschutz-Check übersetzt den Soll-Katalog in ein prüfbares Lagebild. Für jede Anforderung erfolgt ein Soll-Ist-Abgleich: umgesetzt, teilweise umgesetzt, offen. Den Ausschlag gibt die Dokumentation: Begründung, Verweis auf Nachweise, Zuordnung zu Verantwortlichen, Datum der Prüfung. Der Check liefert damit die Grundlage für Maßnahmenplanung, Priorisierung und Reporting. Ohne diesen Abgleich bleibt ein Sicherheitskonzept ohne Steuerungswirkung.
Aus dem Check folgt die Maßnahmenplanung. Offene Punkte wandern nicht in eine lose Liste, sondern in ein priorisiertes Arbeitsprogramm: technische Änderungen, Prozessanpassungen, Schulungen, Lieferantenanforderungen. Prüfkriterien und Akzeptanzgrenzen sorgen für eine einheitliche Auslegung, etwa bei Patchzyklen, Berechtigungsreviews, Backup-Tests oder Incident-Response. Das Sicherheitskonzept erhält damit eine operative Übersetzung: Teams sehen konkrete Aufgaben statt abstrakter Anforderungen.
Betrieb und Nachweis – kontinuierliche Verbesserung mit Tool-Unterstützung
Nach dem Check folgt Steuerung im Betrieb. Maßnahmen erhalten Prioritäten, Verantwortliche und Termine. Wirksamkeitsprüfungen sichern Qualität, etwa über Kontrollnachweise, Stichproben, interne Audits oder technische Tests. Der Standard verankert damit einen Kreislauf aus Planung, Umsetzung, Prüfung und Verbesserung. Dieser Kreislauf schafft Anschluss an eine ISO-27001-Zertifizierung auf Basis IT-Grundschutz, sofern ein Zertifizierungsziel im Programm steht.
Im Alltag ändern sich Rahmenbedingungen: neue Anwendungen gehen live, Standorte kommen hinzu, M&A-Projekte verschieben Verantwortlichkeiten, Compliance-Anforderungen steigen, Geräteklassen wechseln. Ein ISMS benötigt deshalb Pflege: Scope-Entscheidungen, Aktualisierung der Struktur, erneute Schutzbedarfsbewertung, Review der Maßnahmenwirksamkeit. Die Methodik aus 200-2 liefert dafür Stabilität, weil sie Veränderung einplant und Nachweise fortlaufend organisiert.
Honicon übersetzt diese Methodik in operativen Alltag mit Atlassian-Tools. Erfahrung aus Aufsetzung, Betrieb und Weiterentwicklung von Jira, Confluence, Assets (früher Insight) sowie Systemen im Atlassian-Kosmos fließt in eine Arbeitsumgebung, die Grundschutz als Prozess abbildet. Jira trägt Steuerung und Nachverfolgung: Scope-Themen als Epics, Strukturobjekte als Datensätze, Anforderungen als Tickets, Check-Ergebnisse als Statusmodell, Maßnahmen als Roadmap mit Verantwortlichen und Fristen. Confluence bündelt Richtlinien, Nachweise und Arbeitsanweisungen; jede Anforderung referenziert die passende Seite, jede Seite verlinkt auf zuständige Tickets. Assets verknüpft Informationsverbund, Owner, Schutzbedarf und Bausteinzuordnung und stärkt damit Nachvollziehbarkeit im Betrieb.
Am Ende zählt ein einfacher Maßstab: klare Verantwortlichkeiten, prüfbare Umsetzung, belastbare Chronologie bei gleichzeitig beherrschbarem Aufwand. BSI 200-2 liefert die Methodik, das Kompendium liefert die Bausteine – und aus Bausteinen entsteht ein Sicherheitskonzept, das im Betrieb trägt.
