In einem Satz. Der BSI-Standard 200-2 beschreibt die operative IT-Grundschutz-Methodik in sieben Phasen — von der Initiierung des Sicherheitsprozesses über Strukturanalyse, Schutzbedarfsfeststellung, Modellierung mit dem IT-Grundschutz-Kompendium, IT-Grundschutz-Check und ggf. ergänzende Risikoanalyse nach 200-3 bis zur Aufrechterhaltung — und ist damit das zentrale Vorgehensmodell für jede ISO-27001-Zertifizierung auf Basis IT-Grundschutz.
Wichtige Punkte
- BSI 200-2 ersetzt seit 2017 den alten Standard 100-2; aktuelle Version 1.0.
- Drei Absicherungsstufen: Basis, Standard, Kern.
- Sieben Methodikschritte von Initiierung bis Aufrechterhaltung.
- Schutzbedarf “hoch”/“sehr hoch” löst zwingend Risikoanalyse nach 200-3 aus.
- Modellierung greift auf über 100 Bausteine des IT-Grundschutz-Kompendiums (Edition 2023) zurück.
1. Initiierung des Sicherheitsprozesses
Verankerung in der Leitungsebene. Sicherheitsleitlinie, Rollen (ISB, Sicherheitsbeauftragte), Geltungsbereich (Informationsverbund). Ohne formales Commitment der Geschäftsführung scheitert jedes Grundschutz-Projekt — das ist Erfahrung aus jedem zweiten BSI-Auditbericht.
2. Wahl der Vorgehensweise
| Vorgehensweise | Aufwand | Reifegrad | Typischer Anwender |
|---|---|---|---|
| Basis-Absicherung | Niedrig (3-6 Monate) | Mindestschutz | KMU, Pilotbereiche |
| Standard-Absicherung | Hoch (9-18 Monate) | Vollständig | ISO-27001-Kandidaten |
| Kern-Absicherung | Mittel | Fokussiert | Hochrisiko-Werte |
Für die ISO-27001-Zertifizierung ist Standard-Absicherung zwingend.
3. Strukturanalyse
Erfassung aller Komponenten des Informationsverbunds: Geschäftsprozesse, Anwendungen, IT-Systeme, virtuelle Systeme, Räume, Kommunikationsverbindungen. Gruppierung gleichartiger Objekte zur Komplexitätsreduktion (z.B. alle Mitarbeiter-Laptops als ein Objekt).
Die Strukturanalyse ist die Grundlage für alles Folgende — und zugleich die Phase, in der die meisten Projekte an Detailtiefe scheitern. Zwei Fehler dominieren: Entweder wird zu fein modelliert (jeder einzelne Rechner als eigenes Objekt, was die Analyse unbeherrschbar macht), oder Abhängigkeiten werden übersehen (eine Anwendung wird erfasst, aber nicht der Datenbankserver, auf dem sie läuft). Der Netzplan und die Objektlisten müssen den tatsächlichen Betrieb abbilden, nicht ein idealisiertes Soll-Bild. Ein bewährter Ansatz ist die Gruppenbildung: Systeme mit gleicher Funktion, gleichem Schutzbedarf und gleicher Konfiguration werden zu einem repräsentativen Objekt zusammengefasst. So bleibt die Analyse handhabbar, ohne relevante Abhängigkeiten zu verlieren.
4. Schutzbedarfsfeststellung
Bewertung pro Grundwert (Vertraulichkeit, Integrität, Verfügbarkeit) in drei Stufen: normal, hoch, sehr hoch. Vererbung des Schutzbedarfs vom Geschäftsprozess auf abhängige IT-Systeme nach Maximumprinzip, ggf. mit Kumulations- oder Verteilungseffekt.
Das Maximumprinzip bedeutet: Ein IT-System erbt den höchsten Schutzbedarf aller Geschäftsprozesse und Anwendungen, die darauf laufen. Ein Server, der sowohl eine unkritische interne Wiki-Anwendung als auch die Lohnbuchhaltung hostet, erhält den Schutzbedarf der Lohnbuchhaltung. Der Kumulationseffekt hebt den Schutzbedarf zusätzlich an, wenn viele einzeln unkritische Verarbeitungen zusammengenommen ein hohes Schadenspotenzial ergeben — etwa ein zentraler Fileserver mit den Daten des gesamten Unternehmens. Der Verteilungseffekt wirkt umgekehrt: Verteilt sich eine Verarbeitung redundant auf mehrere Systeme, kann der Schutzbedarf des Einzelsystems sinken. Für den Datenschutz ist besonders die Vertraulichkeit personenbezogener Daten relevant — Verarbeitungen besonderer Kategorien nach Art. 9 DSGVO rechtfertigen fast immer die Einstufung “hoch” oder “sehr hoch”.
5. Modellierung
Zuordnung passender Bausteine aus dem IT-Grundschutz-Kompendium an jedes Objekt. Das Kompendium gliedert in 10 Schichten: ISMS, ORP, CON, OPS, DER, APP, SYS, IND, NET, INF. Jeder Baustein enthält Basis-, Standard- und ggf. erhöhte Anforderungen.
Die Modellierung ist im Kern ein Abgleich: Für jedes Objekt der Strukturanalyse wird der passende Baustein — etwa SYS.1.1 für allgemeine Server, APP.3.1 für Webanwendungen oder NET.1.1 für die Netzarchitektur — aus dem Kompendium ausgewählt und angewendet. Das Ergebnis ist ein Prüfplan, der genau festlegt, welche Anforderungen für welches Objekt gelten. Der große Vorteil gegenüber generischen Standards: Die Bausteine formulieren konkrete, umsetzbare Anforderungen (“Server müssen X, Y, Z”) statt abstrakter Kontrollziele. Das nimmt der Umsetzung viel Interpretationsspielraum und macht den Fortschritt objektiv messbar.
6. IT-Grundschutz-Check
Soll-Ist-Vergleich pro Anforderung mit vier Status: entbehrlich, ja, teilweise, nein. Ergebnis: Defizitliste mit Maßnahmenplan. Realistisch: Erst-Check zeigt 40-60% offene Anforderungen — selbst bei mittlerer IT-Reife.
Der IT-Grundschutz-Check ist der Moment, in dem sich Anspruch und Wirklichkeit begegnen. Wichtig ist die ehrliche Bewertung: Der Status “entbehrlich” muss begründet werden und wird vom Auditor auf Plausibilität geprüft — er ist kein Schlupfloch, um unbequeme Anforderungen wegzudefinieren. Der Status “teilweise” verlangt einen konkreten Maßnahmenplan mit Termin und Verantwortlichem. Erfahrungsgemäß liefert der Erst-Check die wertvollste Erkenntnis des gesamten Projekts, weil er die tatsächliche Sicherheitslage schonungslos sichtbar macht. Organisationen, die den Check als lästige Formalie abhaken, verschenken genau diesen diagnostischen Wert und stehen im Audit mit einer beschönigten Selbstauskunft da, die der Prüfer schnell entlarvt.
7. Ergänzende Sicherheitsanalyse (200-3)
8. Konsolidierung und Umsetzungsplan
Maßnahmen priorisieren nach Risiko, Aufwand und Abhängigkeiten. Realisierungsplan mit Verantwortlichen, Terminen, Budgets. Sicherheitskonzept als zentrales Dokument für Audit und Aufsicht.
Die Konsolidierung entscheidet über die Wirtschaftlichkeit des gesamten Projekts. Aus der Defizitliste des IT-Grundschutz-Checks entsteht schnell eine dreistellige Zahl offener Anforderungen — ohne Priorisierung führt das zu Lähmung. Bewährt hat sich eine Priorisierung nach dem Verhältnis von Risikoreduktion zu Umsetzungsaufwand: Maßnahmen mit hoher Schutzwirkung und geringem Aufwand (etwa Multi-Faktor-Authentifizierung, Patch-Disziplin, Backup-Tests) werden zuerst umgesetzt, aufwändige Umbauten (Netzsegmentierung, Redundanzarchitekturen) folgen geplant. Restrisiken, die bewusst akzeptiert werden, müssen von der Leitung formal freigegeben und dokumentiert werden — diese Freigabe ist im Audit und in einem etwaigen Aufsichtsverfahren ein zentraler Nachweis dafür, dass Sicherheitsentscheidungen auf der richtigen Ebene getroffen wurden.
9. Aufrechterhaltung und Verbesserung
PDCA-Zyklus: regelmäßige Überprüfung, Aktualisierung bei Änderungen, Managementreview. Mindestens jährliche Überarbeitung des Sicherheitskonzepts. Bei ISO-27001-Zertifizierung: Überwachungsaudits jährlich, Re-Zertifizierung alle drei Jahre.
10. Typische Stolperfallen
- Zu großer Geltungsbereich beim Erstprojekt — besser Pilot wählen.
- Schutzbedarf zu hoch ansetzen → unnötige Risikoanalysen.
- IT-Grundschutz-Check als reine Formalie behandeln statt als Lerngelegenheit.
- Dokumentation fehlt oder veraltet → Audit-K.O.
Ein weiterer, oft unterschätzter Fehler ist die fehlende Verzahnung mit dem Datenschutz. Wer die Strukturanalyse und Schutzbedarfsfeststellung isoliert vom Verzeichnis der Verarbeitungstätigkeiten betreibt, produziert zwei getrennte Datenbestände, die schnell auseinanderlaufen. Effizienter ist es, die Verarbeitungen personenbezogener Daten von Anfang an als schützenswerte Werte in den Informationsverbund aufzunehmen. So entsteht eine einzige, konsistente Sicht, die sowohl die BSI-Auditierung als auch die DSGVO-Rechenschaftspflicht bedient — und die bei einer Aufsichtskontrolle belegt, dass technische Sicherheit und Datenschutz nicht als konkurrierende, sondern als integrierte Disziplinen geführt werden.
11. Tool-Unterstützung
Fazit
BSI 200-2 ist sperrig, aber der einzige in Deutschland behördlich anerkannte Pfad zu strukturierter Informationssicherheit. Wer ihn diszipliniert geht, hat sowohl Aufsichtsbehörden als auch Auditoren auf seiner Seite.
Der wiederkehrende Rat aus der Praxis: klein anfangen, ehrlich prüfen, konsequent dokumentieren. Ein eng gefasster Geltungsbereich, eine realistische Schutzbedarfsfeststellung und ein schonungslos ausgefüllter IT-Grundschutz-Check bringen mehr Sicherheit als ein ambitioniertes Gesamtprojekt, das nach sechs Monaten am eigenen Umfang erstickt. Wer die Methodik als Lernwerkzeug versteht statt als Zertifizierungshürde, erhält nebenbei den vollständigen Art.-32-Nachweis — und eine Sicherheitsorganisation, die auch nach einem Personalwechsel funktioniert.
FAQ
Wie lange dauert eine Standard-Absicherung nach 200-2?
Typisch 9-18 Monate für mittelständische Unternehmen mit 100-500 Mitarbeitern, abhängig von IT-Reife und Geltungsbereich.
Muss jedes Unternehmen alle 100+ Bausteine modellieren?
Nein. Nur relevante Bausteine je nach Informationsverbund. Typischer Mittelstand kommt mit 30-50 Bausteinen aus.
Was kostet eine 200-2-Implementierung?
Externe Beratung 50-200k Euro, interne Aufwände 1-3 Personenjahre. Zertifizierungskosten zusätzlich 15-40k Euro je nach Größe.
Welcher Unterschied zu reiner ISO 27001?
ISO 27001 ist generisch, IT-Grundschutz liefert konkrete Bausteine mit detaillierten Anforderungen — höherer Reifegrad-Nachweis, aber mehr Aufwand.
Wo finde ich das aktuelle IT-Grundschutz-Kompendium?
Kostenfrei auf der BSI-Website unter bsi.bund.de in der Edition 2023. PDF und HTML-Version verfügbar.