Der sinnvolle Startpunkt für ein ISMS

Problem in der Praxis

Unternehmen starten ein ISMS häufig aus externem Druck: ein Kunde verlangt ISO-27001-Nachweise, ein Investor fragt nach Security Governance, eine Ausschreibung nennt Zertifizierung, oder ein Vorfall hat Lücken sichtbar gemacht.

Unter Zeitdruck greifen Teams dann zu Templates. Es entstehen Richtlinien, Risikoformulare, Assetlisten und Schulungsunterlagen. Was oft fehlt, ist die Managementklärung: Welcher Teil des Unternehmens ist gemeint? Welche Services oder Prozesse sind kritisch? Wer entscheidet über Risiken? Welche Nachweise können realistisch im Betrieb entstehen?

Ohne diese Klärung wird das ISMS entweder zu breit und schwerfällig oder zu eng und unglaubwürdig. Beides ist für einen späteren Audit- und Betriebsalltag problematisch.

CISO-Einordnung

Ein ISMS braucht einen bewusst gewählten Anfang. Der CISO sollte nicht fragen: "Welche Dokumente verlangt das Zielmodell?" Die bessere Startfrage lautet: "Welche Sicherheitssteuerung braucht dieses Unternehmen jetzt, damit es seine Ziele verlässlicher erreicht?"

Dieser Perspektivwechsel hat konkrete Folgen: Ein Unternehmen mit SaaS-Produkt, Cloud-Betrieb und internationalen Kunden braucht andere Prioritäten als ein produzierender Mittelständler mit OT-Abhängigkeiten, Lieferantenketten und Standortbetrieb. Beide können sich an denselben Normen orientieren, aber der praktische Einstieg unterscheidet sich.

Der Startpunkt sollte daher die Realität des Geschäfts abbilden. Dazu gehören Kundenversprechen, regulatorische Erwartungen, kritische Daten, Kernprozesse, technische Plattformen, Lieferanten und die vorhandene Organisationsreife.

Umsetzungsperspektive

Ein pragmatischer Einstieg besteht aus sechs Arbeitspaketen:

1. Kontext klären: Warum wird das ISMS aufgebaut, und welche Geschäftsziele soll es unterstützen?
2. Scope festlegen: Welche Organisationseinheiten, Services, Standorte, Systeme und Lieferanten sind zuerst betroffen?
3. Verantwortung benennen: Wer entscheidet, wer betreibt, wer liefert Nachweise, wer akzeptiert Risiken?
4. Kritische Informationswerte identifizieren: Welche Daten, Anwendungen und Prozesse verdienen besondere Aufmerksamkeit?
5. Risiko- und Maßnahmenlogik definieren: Wie werden Risiken beschrieben, priorisiert und behandelt?
6. Betriebstaktung starten: Welche Meetings, Reports und Reviewpunkte halten das ISMS lebendig?

Diese Pakete sind keine Normrekonstruktion. Sie sind ein CISO-Pragmatismus: Ohne diese Grundlagen wird jedes ISMS schwer steuerbar.

Ein wirksamer Start braucht zudem ein sichtbares Mandat der obersten Leitung. Erst ein klares Bekenntnis des Top-Managements - idealerweise verankert in einer kurzen, richtungsweisenden Sicherheitsleitlinie mit wenigen Zielen - macht aus den sechs Arbeitspaketen ein steuerbares Managementsystem. Ohne dieses Mandat bleiben Scope und Rollen Papier, und spätere Entscheidungen über Risiken und Ressourcen verlieren ihre Verbindlichkeit.

Typische Fehler

1. Der Scope wird zu groß gewählt, weil das Unternehmen sofort alles abdecken will.
2. Der Scope wird zu klein gewählt, weil nur ein Auditprojekt bedient werden soll.
3. Rollen werden in Dokumenten benannt, aber nicht im Alltag gelebt.
4. Risiken werden technisch gesammelt, aber nicht in Managemententscheidungen übersetzt.
5. Dokumente werden erstellt, bevor klar ist, welche Prozesse sie steuern sollen.

Risiken und Trade-offs

Ein enger Startscope beschleunigt den Aufbau, kann aber später Integrationsaufwand erzeugen. Ein breiter Scope schafft früh Gesamttransparenz, kann aber die Organisation überlasten. Die Entscheidung sollte bewusst getroffen und begründet werden.

Auch beim Detailgrad gibt es einen Trade-off. Zu wenig Struktur führt zu Beliebigkeit. Zu viel Struktur verlangsamt den Start und erzeugt Scheinpräzision. Ein CISO sollte den Detailgrad an Risiko, Unternehmensgröße und Reife anpassen.

Ein dritter Zielkonflikt betrifft Zertifizierung. Wenn ein Zertifikat kurzfristig gebraucht wird, steigt der Druck auf formale Nachweise. Trotzdem sollte der Aufbau nicht so gestaltet werden, dass nach dem Audit kein betreibbares System übrig bleibt.

Hilfreich ist hier die Einordnung in die anerkannte Zertifizierungspraxis: Ein externes Audit betrachtet typischerweise sowohl die Dokumenten- und Bereitschaftslage als auch die gelebte, wirksame Umsetzung im Betrieb. Ein Start, der nur Dokumente erzeugt, aber kein betreibbares System, trägt diese Lücke direkt in das Audit hinein. Verbindliche Anforderungen an Ablauf und Bewertung von Audits regeln die einschlägigen Zertifizierungsnormen; im Zweifel ist lizenzierte Beratung heranzuziehen.

Entscheidungspunkte

• Soll der erste ISMS-Scope ein Produkt, eine Organisationseinheit, ein Standort oder das gesamte Unternehmen sein?
• Welche Geschäftsziele machen Informationssicherheit jetzt prioritär?
• Welche Risiken müssen auf Managementebene entschieden werden?
• Welche Rollen können mit vorhandenen Personen realistisch besetzt werden?
• Welche Nachweise lassen sich im Regelbetrieb erzeugen?

Praktische Empfehlungen

1. Formulieren Sie eine klare ISMS-Startthese: "Wir bauen das ISMS zuerst für ... auf, weil ..."
2. Halten Sie den Scope schriftlich knapp, aber entscheidbar.
3. Starten Sie mit wenigen kritischen Prozessen und Informationen, nicht mit Vollständigkeit.
4. Definieren Sie eine feste Taktung für Risiken, Maßnahmen und Entscheidungen.
5. Legen Sie für jede Maßnahme fest, wer sie besitzt, wie Fortschritt sichtbar wird und wann eskaliert wird.

Relevante Normreferenzen

• ISO/IEC 27001:2022: Aktuelle, maßgebliche Ausgabe; Referenz für ISMS-Anforderungen und Zertifizierungsbasis.