Das zentrale Problem: Verantwortlichkeit in der Grauzone

Ein Vorstand liest den Incident-Report: „Critical vulnerability im ERP-System, 500 Tage offen."

Der CTO sagt: „Das ist ein Business-Risk, die Fachabteilung hat entschieden, ihn zu akzeptieren."

Die Fachabteilung sagt: „Wir wollten den fixen ja schließen, aber IT hat keine Kapazität."

Der IT-Chef sagt: „Das ISMS sagt, dass dafür die Risikoakzeptanz vom Geschäftsführer kommen muss, und das ist nie passiert."

Wer trägt die Verantwortung? Niemand, und gleichzeitig jeder. Das ist das Kernproblem fehlender ISMS-Governance in Konzernen.

Die drei Governance-Modelle

Modell A: Der Zentral-CISO (Klassisch, Top-Down)

Ein CISO sitzt in der Zentrale, definiert Policies für alle. Alle müssen followen.

Struktur Modell A

  • Vorstand ↓ CISO ↓ Information Security Officer ↓ IT / HR / Finance (Prozess-Eigentümer)
  • Policy-Richtung: Top-Down. Wer weicht ab? Exception-Prozess oder Audit-Finding.
  • Risikoakzeptanz: CISO oder Vorstand.
  • Incident Escalation: CISO entscheidet, ob Aufsichtsrat informiert wird.

Vorteile: Klare Verantwortlichkeit, schnelle Eskalation, einheitliche Standards, Audit-freundlich.

Nachteile: Bottleneck (alles durch den CISO), zu starr für dezentrale Strukturen, Business-Realität oft komplexer als Policy.

Wann geeignet: Konzerne mit Zentral-IT, klare Hierarchie, wenige regulative Anforderungen.

Modell B: Das föderale Modell (Dezentral, Matrix)

Jede Sparte, jedes Land hat einen lokalen ISO (Information Security Officer). Sie koordinieren über ein Governance-Board.

Struktur Modell B

  • Zentrale ISMS-Policy + Lokale ISOs mit Autonomie innerhalb des Rahmens
  • Governance Board: Trifft sich monatlich, eskaliert, setzt Standards
  • Risikoakzeptanz: Lokal bis zu Schwellenwert, dann Zentral
  • Incident Escalation: Lokal bearbeitet, automatische Eskalation bei Severity 1 oder Regulierung

Vorteile: Flexibel, Lokal angepasst, schneller Zugang zu lokalem Wissen, skaliert besser.

Nachteile: Unterschiedliche Standards, Koordinierungsaufwand, Interpretation-Drift, Audits komplexer.

Wann geeignet: Multinationale Konzerne, dezentralisierte Strukturen, unterschiedliche Märkte / Kulturen.

Modell C: Das Hybrid-Modell (Kern + Peripherie)

Zentrale Team definiert Mindeststandards (Kern). Jeder Bereich nimmt lokale Verantwortung (Peripherie).

Struktur Modell C

  • Kern (zentral): Access Management, Incident Management, Risk Management, Compliance Auditing
  • Peripherie (dezentral): Sparten-spezifische Controls, lokale Policies, Vendor Management
  • Quarterly Board: Nur Kern-Themen, Peripherie-Updates async
  • Risikoakzeptanz: Kern = CISO/Vorstand, Peripherie = lokal bis Schwellenwert

Vorteile: Skaliert, flexible Lokalisierung, klare Kern-Verantwortlichkeit, Audit-einfacher als B.

Nachteile: Abstraktion nötig (Was ist Kern? Was ist Peripherie?), Koordinierung bei Kern-Änderungen.

Wann geeignet: Die meisten Konzer­ne >1000 Mitarbeiter wählen dieses Modell.

Das RACI-Modell für ISMS-Entscheidungen

Unabhängig vom Modell, diese Rollen müssen klar sein:

RACI: Wer macht was?

Entscheidung Responsible (Macht es) Accountable (Trägt Verantwortung) Consulted (Input) Informed (Muss es wissen)
Policy-Update ISO / CISO CISO IT, HR, GRC Vorstand, Auditor
Risikoakzeptanz <100k€ Prozess-Eigentümer ISO / Bereichsleiter CISO Compliance
Risikoakzeptanz >100k€ Geschäftsführung CISO / CFO Risk Officer, Auditor Aufsichtsrat, Versicherer
Incident Severity 1 Incident Commander CISO IT, Business, Legal Geschäftsführung, Aufsichtsrat (24h)
Vendor Risk Assessment IT / Procurement ISO CISO, Business GRC, Legal

Das ist das Kern-RACI. Jedes Unternehmen hat weitere Rollen, aber ohne diese Klarheit läuft ISMS zu Chaos.

Integration mit Enterprise-Governance

Die Reporting-Kette: Von ISO zu Aufsichtsrat

Ein häufiger Fehler: Der CISO berichtet dem CTO oder dem IT-Chef. Das ist falsch.

Richtig: Der CISO berichtet direkt dem Geschäftsführer oder dem Chief Risk Officer, nicht zu IT.

Warum? Weil ISMS ein Business-Risiko ist, keine IT-Funktion. Wenn IT entscheidet, welche Risks zu akzeptieren sind, entstehen Interessenskonflikte.

Reporting-Linie (Best Practice)

  • CISO → Geschäftsführung → Aufsichtsrat-Audit-Komitee (1 × Jahr)
  • ISO → CISO → ISMS-Governance Board → Geschäftsführung (monatlich/quartalsweise)
  • Incident Reporting: Severity 1/2 → CISO → GF (sofort), Aufsichtsrat (24-48h)
  • Risk Acceptance: CEO / CFO (endgültig), mit CISO-Empfehlung

Im Aufsichtsrat braucht es einen Punkt „ISMS Status & Risiken" auf der Agenda. Nicht als Technologie-Thema, sondern als Governance-Thema.

Praktische Checkliste: Governance aufbauen

10-Punkte-Checkliste für ISMS-Governance

  • 1. Governance-Modell wählen: A, B oder C? Dokumentieren in Writing.
  • 2. Rollen definieren: CISO-Profil, ISO-Profil, Board-Mitglieder. Nicht zu viele, nicht zu wenige.
  • 3. RACI schreiben: Für die Top 10 Entscheidungstypen. Alle müssen unterschreiben.
  • 4. Reporting-Linie klarstellen: CISO direkt zur GF. In Organigramm zeigen.
  • 5. Board-Cadence: Monatlich? Quartalsweise? Agenda-Template erstellen.
  • 6. Eskalationspfade dokumentieren: Wann geht was an Geschäftsführung, Aufsichtsrat, externe Behörde?
  • 7. Risikoakzeptanz-Prozess: Schwellenwert definieren (<50k€, <100k€, etc.). Genehmiger klar.
  • 8. Exception-Prozess: Wie wird eine Policy-Abweichung genehmigt? (Business Case, CISO-Review, Zeitlimit)
  • 9. Audit-Vorbereitung: Governance-Dokumentation ist erste Frage eines Auditors. Muss sortiert sein.
  • 10. Jährliche Überprüfung: Hat das Modell funktioniert? Was ändern?

Das kritische Gespräch mit dem Aufsichtsrat

Der Aufsichtsrat fragt oft: „Sind wir sicher?"

Ein unvorbereiteter CISO antwortet: „Naja, wir haben ISO 27001 und einen Risk Scorecard von 7 aus 10."

Ein vorbereiteter CISO antwortet:

„Unser ISMS deckt die 5 kritischsten Risiken für den Konzern ab: Access Management, Incident Management, Vendor Risk, Compliance und Datenintegrität. Wir haben klare Eskalationspfade, und jedes Severity-1-Incident wird innerhalb 4 Stunden zur Geschäftsführung eskaliert. Die Top-3-Findings aus unserem letzten Audit sind in Remediation. Unsere aktuellen Risiken sind dokumentiert und vom Management akzeptiert."

Beispielhafte CISO-Antwort, abgeleitet aus ISO/IEC 27001 Abschnitt 5.3

Das ist Governance-Sprache. Der Aufsichtsrat hört: Struktur, Klarheit, Handlungsfähigkeit.

Drei häufige Fallstricke bei mehrstufiger ISMS-Governance

Drei Fehler tauchen in nahezu jeder Konzern-ISMS-Bewertung auf.

1. Zentralität ohne lokale Verantwortung. Manche Konzerne wollen alle Entscheidungen aus der Zentrale treffen und dokumentieren eine durchgängige zentrale Verantwortung. Im Vor-Ort-Audit zeigt sich dann, dass lokale Standortleiter die Policies nicht kennen, weil sie nie eingebunden waren. ISO 27001 Abschnitt 5.3 fordert eine angemessene Verteilung von Verantwortlichkeiten, nicht zentrale Allmacht.

2. Lokale Insellösungen ohne Konzernanbindung. Das umgekehrte Extrem: Jeder Standort baut sein eigenes ISMS, mit eigener Asset-Klassifikation, eigenen Risikoschwellwerten, eigenen Incident-Kategorien. Beim Konzernaudit fehlt die Vergleichbarkeit, beim CISO-Reporting fehlen aggregierbare KPIs. Sinnvoll ist ein Minimum-Set zentraler Vorgaben (Klassifikationsschema, Risk-Appetite, Top-Risk-Liste) und ein Maximum-Set für lokale Ausgestaltung.

3. Eskalationspfade ohne Verbindlichkeit. RACI-Matrizen existieren oft als Excel-Dokument, das niemand kennt. Wirksam wird Governance erst, wenn Eskalationsentscheidungen im Ticketsystem hinterlegt sind und Incident-Tickets der Severity 1 automatisch eine E-Mail an benannte Personen erzeugen. Das ist eine technische Frage der ISMS-Tool-Konfiguration, keine reine Policy-Frage.

Governance vor Prozessen, Klarheit vor Perfektion

Der häufigste Fehler in Konzernen: Es werden perfekte technische Controls gebaut, aber die Governance bleibt vage. Das führt dazu, dass Risiken nicht eskaliert werden, Budgets nicht freigegeben werden, und im Audit sieben unterschiedliche Personen "die" Verantwortung haben.

ISMS-Governance ist fundamental. Ein simples, gut dokumentiertes System schlägt ein perfektes System mit unklaren Rollen jedes Mal.

Der erste Schritt: Rollen klären. Der zweite: Entscheidungswege dokumentieren. Der dritte: Aufsichtsrat einbinden. Erst dann kann ISMS wirklich funktionieren.

QUELLEN

  1. ISO/IEC 27001:2022, Information security management systems — Requirements, Abschnitt 5.3 (Organizational roles, responsibilities and authorities), iso.org
  2. ISO/IEC 27002:2022, Information security controls, A.5.1-A.5.4, iso.org
  3. Bundesamt für Sicherheit in der Informationstechnik, BSI-Standard 200-1 (Managementsysteme für Informationssicherheit), bsi.bund.de