IT-Grundschutz-Check: Ist Ihr Unternehmen bereit für die Modellierung?

Ein IT-Grundschutz-Check bewertet den Umsetzungsstatus der Anforderungen, die aus einem bereits modellierten Informationsverbund hervorgehen. Viele Unternehmen beginnen jedoch mit Interviews und Statuslisten, obwohl Scope, Strukturanalyse oder Schutzbedarf noch nicht belastbar sind. Das erzeugt Scheingenauigkeit: Anforderungen werden geprüft, ohne sicher zu wissen, ob die richtigen Zielobjekte und Bausteine betrachtet werden.

Ein vorgeschalteter Readiness-Check beantwortet deshalb eine andere Frage: Ist die Organisation fachlich, organisatorisch und datenbezogen bereit, ein tragfähiges IT-Grundschutz-Modell aufzubauen? Die folgende Checkliste trennt diese Vorprüfung vom späteren Soll-Ist-Vergleich und zeigt, welche Lücken vor der Modellierung geschlossen werden sollten.

Readiness-Check und IT-Grundschutz-Check unterscheiden

Bei der Modellierung werden Geschäftsprozessen, Anwendungen, IT-Systemen, Netzen, Räumen und weiteren Zielobjekten passende Bausteine des aktuellen IT-Grundschutz-Kompendiums zugeordnet. Erst auf dieser Basis lässt sich im IT-Grundschutz-Check nachvollziehbar feststellen, welche Anforderungen erfüllt, teilweise erfüllt, nicht erfüllt oder entbehrlich sind. Der Readiness-Check liegt davor und bewertet die Qualität der dafür benötigten Eingaben.

Diese Trennung verhindert, dass ein vermeintlicher Erfüllungsgrad auf einem unvollständigen Inventar beruht. Fehlt beispielsweise eine zentrale SaaS-Anwendung in der Strukturanalyse, tauchen auch ihre Identitäts-, Konfigurations- und Lieferantenrisiken nicht im Modell auf. Ein hoher Prozentwert wäre dann kein Sicherheitsnachweis, sondern Folge eines zu kleinen Prüfgegenstands.

Die sieben Prüffelder der Modellierungsreife

Eine belastbare Vorprüfung betrachtet nicht nur technische Listen. Sie umfasst Leitungsmandat und Geltungsbereich, Organisation und Verantwortlichkeiten, Strukturanalyse, Schutzbedarfsfeststellung, Qualität der Gruppierung, Quellen- und Versionsstand sowie die Fähigkeit, Ergebnisse dauerhaft zu pflegen. Jedes Prüffeld erhält einen nachvollziehbaren Status und konkrete Belege.

Für die Bewertung genügt häufig eine dreistufige Skala. Grün bedeutet, dass das Eingangskriterium belegt ist und ohne grundlegende Nacharbeit genutzt werden kann. Gelb kennzeichnet begrenzte Lücken mit beherrschbarem Korrekturaufwand. Rot zeigt, dass eine Modellierung derzeit voraussichtlich falsche oder instabile Ergebnisse erzeugen würde.

Prüffeld 1: Mandat, Ziel und Vorgehensweise

Die Leitung muss Informationssicherheit als eigene Aufgabe anerkennen, den Projektauftrag genehmigen und Ressourcen bereitstellen. Der Auftrag nennt Anlass, erwartetes Schutzniveau, betrachtete Organisation, gewünschte Vorgehensweise und Entscheidungsweg. Auch eine mögliche Zertifizierung nach ISO 27001 auf Basis von IT-Grundschutz gehört früh in das Zielbild, weil sie Scope, Nachweistiefe und Zeitplanung beeinflusst.

Ein grüner Status verlangt mehr als eine mündliche Zustimmung. Erkennbar sein müssen ein freigegebener Auftrag, eine verantwortliche Leitungsperson, ein benannter Informationssicherheitsbeauftragter und ein regelmäßiger Berichtsweg. Fehlen Budget, Mitwirkung der Fachbereiche oder Entscheidungen über Zielkonflikte, ist die Modellierung organisatorisch noch nicht abgesichert.

Prüffeld 2: Der Informationsverbund ist eindeutig abgegrenzt

Der Informationsverbund beschreibt die Gesamtheit der infrastrukturellen, organisatorischen, personellen und technischen Komponenten, die für die betrachteten Aufgaben und Informationen relevant sind. Seine Grenze darf sich nicht allein an einem Netzwerksegment orientieren. Sie muss aus Leistungen, Geschäftsprozessen, Standorten, Organisationseinheiten und externen Abhängigkeiten abgeleitet werden.

Prüfbar wird der Scope durch eine schriftliche Beschreibung mit Ein- und Ausschlüssen, Schnittstellen, gemeinsamen Plattformen und ausgelagerten Diensten. Organigramm, Servicekatalog, Netzplan und Verträge sollten dieselbe Grenze erkennen lassen. Widersprechen sich diese Quellen, wird der Scope zunächst bereinigt, bevor Zielobjekte modelliert werden.

Checkliste für einen belastbaren Scope

Ein Scope ist rot zu bewerten, wenn wesentliche Leistungen nur durch pauschale Begriffe wie „zentrale IT“ beschrieben werden oder kritische Cloud- und Lieferantenabhängigkeiten außerhalb bleiben. Gelb ist angemessen, wenn die Grenze verständlich ist, aber einzelne Schnittstellen noch verifiziert werden müssen. Grün setzt voraus, dass Verantwortliche den Verbund konsistent erklären und die zugrunde liegenden Unterlagen ihn stützen.

Prüffeld 3: Verantwortliche kennen ihre Zielobjekte

Das Sicherheitsteam kann die Modellierung koordinieren, aber nicht alle fachlichen und technischen Eigenschaften allein beurteilen. Für Prozesse, Anwendungen, Systeme, Netze, Räume und externe Dienste werden sachkundige Eigentümer oder Ansprechpartner benötigt. Sie bestätigen Nutzung, Schutzbedarf, Konfiguration, Abhängigkeiten und später den Umsetzungsstatus der Anforderungen.

Die Rollenmatrix sollte Entscheidung und Zuarbeit trennen. Ein Prozesseigner verantwortet Auswirkungen und Prioritäten, ein Anwendungsverantwortlicher beschreibt fachliche Nutzung, der Betrieb liefert technische Evidenz und Einkauf oder Vendor Management bewertet vertragliche Leistungen. Unbesetzte Zielobjekte sind kein administrativer Schönheitsfehler, sondern ein Hinweis auf fehlende Steuerbarkeit.

Prüffeld 4: Die Strukturanalyse ist vollständig genug

Die Strukturanalyse erfasst die relevanten Geschäftsprozesse und Fachaufgaben, Anwendungen, IT-Systeme, Netze und Kommunikationsverbindungen sowie Räume. Sie bildet das Gerüst für Schutzbedarf und Modellierung. Eine ungeprüfte CMDB-Ausleitung ist dafür selten ausreichend, weil fachliche Nutzung, Cloudservices, Schatten-IT oder physische Abhängigkeiten oft fehlen.

Die Vorprüfung vergleicht mehrere Quellen: Prozesslandkarte, Servicekatalog, CMDB, Cloudinventar, Identitätsverzeichnis, Netz- und Architekturpläne, Verträge, Beschaffung sowie technische Discovery. Abweichungen werden als Klärfälle dokumentiert. Ziel ist keine perfekte Datenbank, sondern ein belastbares und verantwortetes Bild des tatsächlichen Verbunds.

Mindestangaben für jedes Zielobjekt

Fehlen Zweck oder Abhängigkeiten, kann ein Objekt zwar gezählt, aber nicht sinnvoll bewertet werden. Besonders kritisch sind unbekannte Systeme, generische Sammelobjekte und technische Namen ohne fachliche Zuordnung. Solche Datensätze werden vor der Modellierung geklärt oder ausdrücklich als offene Risiken behandelt.

Prozesse vor Technik validieren

Schutzbedarf entsteht aus möglichen Schäden für Aufgaben, Informationen, Personen, Kunden und Organisation. Deshalb sollte die Struktur von wesentlichen Leistungen und Prozessen zur unterstützenden Technik führen. Wer ausschließlich bei Servern beginnt, kann später kaum erklären, warum ein System besonders wichtig ist oder welche Wiederanlaufzeit tatsächlich benötigt wird.

Für jeden relevanten Prozess werden Ergebnis, Eigentümer, verwendete Informationen, Anwendungen, externe Partner und tolerierbare Ausfallfolgen erfasst. Unterstützende Prozesse wie Identitätsverwaltung, Einkauf, Personal oder Gebäudebetrieb werden aufgenommen, wenn sie für den sicheren Betrieb erforderlich sind. Diese Kette erleichtert sowohl Schutzbedarfsvererbung als auch Maßnahmenpriorisierung.

Cloud- und SaaS-Dienste ausdrücklich aufnehmen

Ein ausgelagerter Dienst bleibt Teil der Sicherheitsbetrachtung, auch wenn das Unternehmen seine Infrastruktur nicht administriert. Modellierungsrelevant sind die genutzte Anwendung, Identitäten, Mandantenkonfiguration, Schnittstellen, Endgeräte, Datenflüsse und die organisatorische Beziehung zum Anbieter. Verträge und Prüfberichte ersetzen diese Sicht nicht, sondern liefern ergänzende Nachweise.

Im Readiness-Check wird geprüft, ob Cloudinventar, Single-Sign-on-Verzeichnis, Kostenstellenabrechnung und Einkauf denselben Dienstbestand zeigen. Nicht zentral beschaffte Werkzeuge und privilegierte Fremdzugänge verdienen besondere Aufmerksamkeit. Die gemeinsame Verantwortung wird pro Kontrollbereich benannt, statt pauschal an den Anbieter delegiert.

Netzplan und Kommunikationsbeziehungen auf Arbeitsniveau bringen

Der Netzplan muss relevante Systeme, Sicherheitszonen, Außenverbindungen, Gateways und Kommunikationspfade nachvollziehbar darstellen. Er muss keine physische Verkabelung bis zum letzten Port abbilden. Für die Modellierung sind Vertrauensgrenzen, zentrale Komponenten, Standortkopplungen, Administrationswege und Verbindungen zu Cloud- oder Partnernetzen entscheidend.

Eine technische Validierung kann vergessene Verbindungen, alte VPN-Zugänge und unverwaltete Geräte sichtbar machen. Abweichungen zwischen Sollplan und beobachteter Realität werden untersucht. Ein Plan ohne Eigentümer und Änderungsdatum ist allenfalls ein Hinweis, aber keine belastbare Eingangsinformation.

Räume und Infrastruktur nicht als Nebensache behandeln

Serverräume, Netzwerkverteiler, Leitstände, Archive, Technikflächen und Arbeitsbereiche beeinflussen Verfügbarkeit und Vertraulichkeit. Strom, Klima, Brand, Wasser, Zutritt und Umgebung können zentrale Dienste gleichzeitig beeinträchtigen. Die Zuordnung von technischen Zielobjekten zu Standorten und Räumen ist daher Teil der Strukturanalyse.

Eine kurze Begehung liefert häufig mehr Erkenntnis als zusätzliche Tabellen. Sie zeigt beispielsweise offen zugängliche Verteiler, gemeinsam genutzte Flächen oder nicht dokumentierte Technik. Externe Rechenzentren und Colocation werden über Leistungsgrenzen, Nachweise und vertragliche Verantwortlichkeiten einbezogen.

Prüffeld 5: Schutzbedarf ist begründet und vererbbar

Die Schutzbedarfsfeststellung bewertet Vertraulichkeit, Integrität und Verfügbarkeit anhand definierter Schadensszenarien. Kategorien wie normal, hoch und sehr hoch benötigen organisationsspezifische Kriterien. Ohne konkrete Begründung wird die Einstufung zur Meinung und kann weder Modellierung noch zusätzliche Risikoanalyse zuverlässig steuern.

Der Readiness-Check prüft, ob Prozesse und Informationen zuerst bewertet wurden und ob die Vererbung auf Anwendungen, Systeme, Netze und Räume nachvollziehbar ist. Maximumprinzip, Kumulation und Verteilung werden nicht mechanisch angewendet. Besondere Abhängigkeiten und begründete Abweichungen müssen dokumentiert sein.

Gute Begründungen statt bloßer Etiketten

Eine gute Verfügbarkeitsbegründung nennt die betroffene Leistung, die tolerierbare Unterbrechung und konkrete Folgen bei Überschreitung. Eine gute Integritätsbegründung beschreibt, welche falschen Entscheidungen, fehlerhaften Produkte oder rechtlichen Folgen manipulierte Daten auslösen können. Für Vertraulichkeit werden Informationsarten, betroffene Personen, Verträge und Wettbewerbsschäden berücksichtigt.

Die Aussagen sollten für Fachbereich und Technik verständlich sein. Ein Server übernimmt seinen Schutzbedarf aus den darauf betriebenen Anwendungen und zusätzlichen Konzentrationseffekten. Redundanz darf nur dann zu einer abweichenden Bewertung führen, wenn Ausfall und Umschaltung tatsächlich beherrscht und getestet sind.

Prüffeld 6: Gruppierungen sind sachlich zulässig

Gleichartige Zielobjekte können gemeinsam modelliert werden, wenn Typ, Einsatz, Konfiguration, Betriebsbedingungen und Schutzbedarf hinreichend vergleichbar sind. Gruppierung reduziert Aufwand und ist ausdrücklich nützlich. Sie darf aber keine Ausnahmen verdecken, die andere Bausteine, Anforderungen oder Risiken benötigen.

Der Readiness-Check untersucht Stichproben aus jeder Gruppe. Weichen Betriebssystem, Härtung, Standort, Administration, Exposition oder Kritikalität wesentlich ab, wird das Objekt getrennt. Die Gruppierungsregel und bekannte Ausnahmen werden dokumentiert, damit spätere Änderungen nicht unbemerkt die Homogenität zerstören.

Typische Fehlgruppierungen erkennen

Eine gute Gruppierung besitzt klare Aufnahmekriterien und einen Verantwortlichen. Werden Kriterien durch eine Änderung verletzt, erfolgt eine Neubewertung. So bleibt die Modellierung schlank, ohne relevante Unterschiede aus dem Sicherheitskonzept zu entfernen.

Prüffeld 7: Kompendium und Quellenstand sind festgelegt

Die Modellierung muss auf einer eindeutig benannten Ausgabe des IT-Grundschutz-Kompendiums beruhen. Bausteine und Anforderungen entwickeln sich weiter; Mischstände erschweren Prüfung und Pflege. Die Organisation dokumentiert Version, Bezugsquelle, Aktualisierungsentscheidung und den Umgang mit Änderungen.

Auch interne Datenquellen benötigen einen Stand. Inventare, Netzpläne, Prozessbeschreibungen und Verträge erhalten Datum und Eigentümer. Während eines längeren Projekts werden relevante Änderungen über einen geregelten Prozess aufgenommen, damit das Sicherheitsmodell nicht bereits bei Fertigstellung veraltet ist.

Bausteinzuordnung in einem Pilot erproben

Vor einer Vollmodellierung empfiehlt sich ein repräsentativer Pilot. Er umfasst einen wichtigen Prozess, die zugehörigen Anwendungen, einige technische Plattformen, Kommunikationswege, Räume und einen externen Dienst. Das Team ordnet passende Prozess-, System-, Anwendungs-, Netz- und Infrastrukturbausteine zu und dokumentiert Zweifelsfälle.

Der Pilot zeigt, ob Objektgranularität, Namenskonventionen, Gruppierung und Verantwortlichkeiten funktionieren. Er deckt ebenfalls auf, wo kein passender Baustein existiert oder besondere Einsatzbedingungen eine ergänzende Risikoanalyse nahelegen. Erkenntnisse werden in Modellierungsregeln überführt, bevor größere Mengen bearbeitet werden.

Modellierungsregeln schriftlich festhalten

Ein kurzes Regelwerk sorgt dafür, dass unterschiedliche Bearbeiter vergleichbare Entscheidungen treffen. Es beschreibt Objektarten, Granularität, zulässige Gruppen, Umgang mit Virtualisierung und Cloud, Auswahl mehrfach anwendbarer Bausteine sowie Kennzeichnung nicht passender Anforderungen. Beispiele aus der eigenen Architektur erhöhen die Verständlichkeit.

Das Regelwerk ersetzt keine fachliche Entscheidung. Unklare Fälle werden in einem Reviewgremium geklärt und mit Begründung dokumentiert. Wiederkehrende Entscheidungen fließen in die Regeln zurück, wodurch Qualität und Geschwindigkeit der Modellierung gleichzeitig steigen.

Werkzeuge unterstützen, aber entscheiden nicht

Ein geeignetes ISMS- oder Grundschutz-Werkzeug kann Zielobjekte, Abhängigkeiten, Bausteine, Anforderungen, Maßnahmen und Nachweise verknüpfen. Es hilft bei Versionierung, Auswertungen und Pflege. Ein schlechter Datenbestand wird durch Software jedoch nur schneller in ein formal aussehendes, aber falsches Modell übertragen.

Vor der Auswahl werden Datenmodell, Importmöglichkeiten, Rollen, Freigaben, Historie und Exportfähigkeit geprüft. Verknüpfungen zur CMDB oder zu technischen Inventaren benötigen klare Verantwortlichkeiten. Die fachliche Quelle für Prozess, Schutzbedarf und Risikobegründung bleibt erkennbar.

Vom Readiness-Status zum Maßnahmenplan

Jede rote oder gelbe Feststellung wird in ein abnahmefähiges Arbeitspaket überführt. Das Paket nennt fehlende Eingangsinformation, betroffene Zielobjekte, Verantwortlichen, Termin, erwartetes Ergebnis und Prüfmethode. Grundlegende Lücken bei Scope, Verantwortlichkeit und Inventar erhalten Vorrang vor kosmetischen Datenbereinigungen.

Der Maßnahmenplan unterscheidet Blocker von Verbesserungen, die parallel zur Modellierung bearbeitet werden können. Ein fehlender Eigentümer für eine kritische Plattform kann die Zuordnung und Statusbewertung blockieren. Uneinheitliche Schreibweisen bei ansonsten eindeutigen Datensätzen lassen sich dagegen häufig während der Bearbeitung korrigieren.

Entscheidungskriterien für Start, Pilot oder Stopp

Ein vollständiger Start ist sinnvoll, wenn Scope und Prozesssicht freigegeben, kritische Zielobjekte inventarisiert, Verantwortliche verfügbar und Schutzbedarfsregeln anwendbar sind. Gelbe Detailpunkte dürfen bestehen, sofern sie terminiert sind und keine wesentlichen Modellierungsentscheidungen verfälschen. Ein Pilot eignet sich bei grundsätzlich tragfähiger Datenlage, aber noch unerprobten Regeln.

Ein vorläufiger Stopp ist angezeigt, wenn der Informationsverbund unklar, zentrale Inventare widersprüchlich oder wesentliche Eigentümer nicht verfügbar sind. Das ist kein Projektversagen, sondern verhindert kostspielige Nacharbeit. Nach Schließung der Blocker wird die Entscheidung erneut anhand derselben Kriterien getroffen.

Der spätere IT-Grundschutz-Check braucht Evidenz

Nach abgeschlossener Modellierung bewertet der IT-Grundschutz-Check die relevanten Anforderungen. Das BSI empfiehlt, zuständige Beschäftigte einzubeziehen und Aussagen durch Stichproben, Dokumente, Konfigurationskontrollen oder Begehungen abzusichern. Ein bloßes Selbstrating ohne Beleg reicht für einen belastbaren Status nicht aus.

Die Vorbereitung beginnt bereits im Readiness-Check. Eigentümer wissen, welche Nachweise sie liefern, Statusbegriffe sind definiert und Speicherorte geklärt. Für teilweise erfüllte Anforderungen wird der fehlende Anteil beschrieben. Nicht anwendbare Anforderungen erhalten eine sachliche Begründung statt eines leeren Feldes.

Interviews effizient vorbereiten

Interviews werden nach Zielobjekten und Verantwortlichkeiten geplant, nicht als allgemeine Sicherheitsgespräche. Die Beteiligten erhalten vorab Scope, relevante Bausteine, erwartete Nachweise und offene Datenfragen. Dadurch kann die gemeinsame Zeit für Abweichungen und Wirksamkeit statt für das Suchen von Dokumenten genutzt werden.

Die Gesprächsergebnisse werden mit Quelle, Datum und Geltungsbereich festgehalten. Widersprüchliche Aussagen lösen eine Klärung aus. Kritische Anforderungen und besonders schutzbedürftige Zielobjekte erhalten tiefere Stichproben als standardisierte Bereiche mit stabiler, automatisierter Evidenz.

Beispiel: Readiness eines mittelständischen Herstellers

Ein Hersteller mit 850 Beschäftigten möchte einen Informationsverbund für Auftragsabwicklung und Produktion modellieren. Der erste Datenexport enthält Server und Netzwerkgeräte, aber keine Maschinenzugänge, Cloudanwendungen oder Prozesszuordnung. Der Scope wird gelb, die Strukturanalyse rot und die technische Datenbasis zunächst nur als Quelle bewertet.

In sechs Wochen ergänzt das Team Prozesslandkarte, SaaS-Inventar, Fernwartungsverbindungen, Räume und Eigentümer. Ein Pilot für Produktionsplanung zeigt, dass gemeinsame Identitäts- und Virtualisierungsdienste in den Verbund gehören. Außerdem werden administrative Notebooks getrennt gruppiert und die Verfügbarkeit zentraler Systeme wegen Kumulation neu begründet.

Danach startet die Modellierung mit einem dokumentierten Regelwerk. Offene Detailpunkte zu zwei Lieferanten bleiben gelb und erhalten Fristen. Weil sie die grundlegende Bausteinzuordnung nicht blockieren, können Modellierung und Klärung parallel laufen. Der spätere Grundschutz-Check basiert damit auf einem erklärbaren statt nur umfangreichen Datenbestand.

Häufige Warnsignale vor der Modellierung

Mehrere Warnsignale sprechen für eine begrenzte Vorbereitungsphase statt einer sofortigen Vollmodellierung. Die gewonnenen Erkenntnisse sind dennoch produktiv, weil sie Zuständigkeiten, Inventar und Architekturklärung verbessern. Entscheidend ist, Status und Risiken offen zu berichten.

Eine kompakte 30-Punkte-Prüfung

Die Liste ist kein Ersatz für die BSI-Methodik. Sie schafft einen kompakten Managementblick auf die Eingangsvoraussetzungen. Jedes Ja sollte durch ein Dokument, eine verantwortliche Aussage oder eine Stichprobe belegbar sein; andernfalls bleibt der Punkt gelb oder rot.

Fazit: Erst Modellierungsreife, dann Erfüllungsgrad

Ein verlässlicher IT-Grundschutz-Check beginnt nicht mit Prozentwerten, sondern mit einem belastbaren Informationsverbund. Mandat, Scope, Verantwortlichkeiten, Struktur, Schutzbedarf, Gruppierung und Versionsstand müssen so weit geklärt sein, dass Bausteine nachvollziehbar zugeordnet werden können. Ein kleiner Pilot macht methodische Schwächen sichtbar, bevor sie sich im gesamten Modell vervielfachen.

BlackMount unterstützt mit einem strukturierten Readiness-Check für BSI IT-Grundschutz, bereinigt gemeinsam mit Fachbereichen und Betrieb die Eingangsdaten und führt die Ergebnisse in Modellierung, Grundschutz-Check und Maßnahmenplanung über. So entsteht ein prüfbares Sicherheitsmodell, dessen Aussagen auch technischen und organisatorischen Veränderungen standhalten.

Verwendete Primärquellen