Von Christoph Gruber, CTO & CISO
Eine unbequeme Beobachtung aus München
Ich sitze auf der Munich Cyber Security Conference 2025, höre den Vorträgen zu, folge den Diskussionen — und mir fällt etwas auf, das mich seit Jahren beschäftigt: Die meisten Akteure in der Cybersecurity-Branche verhalten sich so, als wäre ihr Fachgebiet völlig unabhängig von der IT.
Eigene Budgets. Eigene Abteilungen. Eigene Tools. Eigene Konferenzen. Eine eigene Sprache. Eine eigene Karriereleiter.
Und ich frage mich: Wann genau haben wir beschlossen, dass Cybersecurity keine IT-Disziplin mehr ist?
Die unbequeme Wahrheit: Ein CISO arbeitet in ITIL
Wenn ich mir anschaue, was ein CISO im Tagesgeschäft tatsächlich verantwortet, dann komme ich zu einem Ergebnis, das auf Security-Konferenzen niemand gerne hört: Rund 80 Prozent der operativen Aufgaben eines CISO sind in ITIL bereits vollständig abgebildet.
Das ist keine Provokation um der Provokation willen. Es ist eine nüchterne Analyse:
Change Management ist vielleicht das deutlichste Beispiel. Unkontrollierte Änderungen an Systemen gehören zu den häufigsten Angriffsvektoren. Wer ein sauberes Change Management betreibt, hat einen erheblichen Teil seiner Security-Probleme bereits gelöst — ganz ohne ein einziges Security-Tool.
Incident Management bildet die direkte Grundlage für Security Incident Response. Die Prozesse sind nahezu identisch: Erkennung, Klassifizierung, Eskalation, Behebung, Lessons Learned. Ob ein Server wegen eines Hardwaredefekts ausfällt oder wegen eines Ransomware-Angriffs — der Prozess ist derselbe.
Configuration Management und eine gepflegte CMDB sind die Voraussetzung für jedes Schwachstellenmanagement. Ohne vollständiges Asset-Inventar kein Patching. Ohne Patching keine Security. So einfach ist das.
Access Management in ITIL ist praktisch deckungsgleich mit Identity and Access Management in der Security-Welt. Dieselben Prinzipien, dieselben Prozesse, nur mit anderem Etikett.
Service Continuity Management deckt Business Continuity und Disaster Recovery ab — Kernthemen jedes CISO.
Supplier Management ist die Basis für Third Party Risk Management, das gerade durch NIS2 und DORA in Europa enorm an regulatorischer Bedeutung gewonnen hat.
Die Liste lässt sich fortsetzen. Problem Management, Availability Management, Information Security Management — ITIL hatte das alles schon, bevor „Cybersecurity“ zum Milliardenmarkt wurde.
Was bleibt dann noch?
Die verbleibenden 20 Prozent — die Bereiche, die tatsächlich spezifische Security-Expertise erfordern — sind wichtig, keine Frage: Threat Intelligence, Penetration Testing, Red Teaming, forensische Analyse, das adversariale Denken in Bedrohungsszenarien.
Aber selbst diese Disziplinen funktionieren nicht im luftleeren Raum.
Und hier wird es wirklich unbequem: Was macht eine Security-Architektur ohne IT-Architektur? Sie produziert PowerPoints.
Man kann die elegantesten Zero-Trust-Konzepte entwerfen. Aber wenn man nicht weiß, wie das Netzwerk segmentiert ist, welche Applikationen über welche Schnittstellen kommunizieren und wo die Daten tatsächlich liegen, bleibt das Ganze eine theoretische Übung. Security Architecture ist keine eigenständige Disziplin — sie ist eine Spezialisierung innerhalb der IT-Architektur. Oder sie ist wertlos.
Dasselbe gilt für Penetration Testing ohne Kenntnis der Infrastruktur. Für Threat Intelligence ohne Verständnis der eigenen Angriffsfläche. Für Vulnerability Management ohne funktionierende CMDB.
Warum die Trennung trotzdem existiert
Wenn die Überlappung so offensichtlich ist, warum halten wir an der Trennung fest? Ich sehe drei Gründe:
Erstens: Geld. Die Cybersecurity-Branche ist ein Wachstumsmarkt. Eigene Budgets, eigene Abteilungen und eigene Beratungsmandate lassen sich leichter rechtfertigen, wenn man Security als eigenständige Disziplin positioniert. Das ist nicht verwerflich — es ist Marktlogik. Aber es ist auch nicht im besten Interesse der Organisationen, die wir schützen sollen.
Zweitens: Ego. Auf beiden Seiten. Der IT-Betrieb sieht Security oft als Störfaktor, der Prozesse verlangsamt. Security sieht den IT-Betrieb als inkompetent und nachlässig. Beide Seiten profitieren von der Trennung, weil sie die jeweils andere Seite für Versäumnisse verantwortlich machen können.
Drittens: Regulatorik. NIS2, DORA und andere Regularien fordern explizit Security-Verantwortlichkeiten auf Leitungsebene. Das ist richtig und wichtig. Aber die Schlussfolgerung, dass diese Verantwortlichkeiten in einer von der IT isolierten Struktur besser aufgehoben sind, ist ein Trugschluss.
Die Ironie
Die größte Ironie, die ich in meiner Beratungspraxis erlebe: Organisationen, die ihre ITIL-Prozesse wirklich sauber leben, sind fast immer deutlich sicherer als solche, die Millionen in Security-Tools investieren, aber kein ordentliches Change Management haben.
Ein Unternehmen mit einer aktuellen CMDB, sauberem Change Management, funktionierendem Incident Management und konsequentem Access Management hat seine Hausaufgaben gemacht. Die Security-Tools obendrauf sind dann das Sahnehäubchen — nicht das Fundament.
Umgekehrt habe ich Unternehmen gesehen, die SIEM, SOAR, EDR, XDR und ein ganzes Alphabet an Security-Lösungen betreiben — aber nicht wissen, wie viele Server sie haben.
Was folgt daraus?
Ich plädiere nicht dafür, die Rolle des CISO abzuschaffen. Ich plädiere dafür, sie ehrlich zu definieren.
Ein CISO, der seine Aufgabe ernst nimmt, muss die IT-Prozesse seiner Organisation nicht nur kennen, sondern mitgestalten. Er muss ITIL nicht als fremdes Framework betrachten, sondern als sein wichtigstes Werkzeug. Und er muss den Mut haben, in Security-Meetings zu sagen: „Das lösen wir nicht mit einem neuen Tool, sondern mit einem sauberen Change-Prozess.“
Die eigentliche Frage ist nicht, ob wir Security und IT trennen sollten. Die Frage ist, ob wir es uns leisten können, so zu tun, als wären sie jemals getrennt gewesen.
#MCSC #CISO #CIO #ITIL #ISMS