Es gibt Dinge, die versteht man theoretisch sofort — und spürt sie praktisch erst, wenn man ein paar Runden gedreht hat: Budgetzyklen, Incident-Nächte, schwierige Stakeholder, zu viele Baustellen gleichzeitig.
Als CISO ist man selten „nur“ für Security verantwortlich. Man ist Übersetzer, Priorisierer, Krisenmanager, Architekt, Coach — und manchmal auch derjenige, der unangenehme Wahrheiten aussprechen muss. Rückblickend gab es sieben Punkte, die mir viel Reibung (und einige Umwege) erspart hätten, wenn ich sie früher konsequent gelebt hätte.
Dieser Artikel ist bewusst praxisnah. Keine Theorie, kein Buzzword-Bingo — sondern Prinzipien, die sich in verschiedensten Organisationen bewährt haben.
1) Security ist ein Business-Outcome, kein Tool-Stack
Viele Security-Programme starten mit Technologie: EDR, SIEM, CASB, PAM, ZTNA, SASE, XDR … Du kannst damit Jahre füllen — und trotzdem keine spürbare Verbesserung erzielen, wenn der Fokus falsch gesetzt ist.
Der entscheidende Perspektivwechsel: Security ist kein Selbstzweck. Security ist ein Mittel, um Business Outcomes zu verbessern.
Risiko reduzieren — nicht abstrakt, sondern konkret: „Weniger erfolgreiche Kontoübernahmen“, „geringere Ausfallwahrscheinlichkeit“
Verfügbarkeit erhöhen — Widerstandsfähigkeit, Wiederherstellbarkeit, Betriebsstabilität
Delivery beschleunigen — weniger Blocker, klare Standards, schnelleres Enablement
Wenn du diese Outcomes nicht messbar verbesserst, wird Security automatisch als Kostenstelle wahrgenommen — egal wie gut deine Tools sind.
Pragmatischer Test: Wenn du einem CFO/COO nur einen Satz sagen dürftest — welche messbare Verbesserung lieferst du in den nächsten 90 Tagen? Wenn du zögerst, fehlt dir wahrscheinlich noch die Outcome-Story.
2) Identity ist der stärkste Hebel
Wenn ich heute eine Security-Organisation neu aufbauen müsste, würde ich nicht mit „Perimeter“ starten. Ich würde mit Identität starten. Warum? Weil Identität der gemeinsame Nenner fast aller erfolgreichen Angriffe ist: Credentials werden abgegriffen, Privilegien ausgenutzt, Tokens gestohlen, Legacy-Flows umgehen Kontrollen.
PAM — klare Trennung zwischen normalen und privilegierten Konten, Just-in-Time / Just-enough Access, sauberes Break-Glass-Konzept
Phishing-resistente MFA — für privilegierte Identitäten ist „SMS/OTP“ oft nicht mehr ausreichend. Die Hürde sollte dort am höchsten sein, wo der Schaden am größten ist.
Conditional Access / Risk-based Policies — Zugriff abhängig von Risiko, Gerät, Standort, Session. Weniger „one size fits all“, mehr dynamische Steuerung.
Merksatz: Wenn du Identity nicht im Griff hast, baust du Security auf Sand.
3) Im Incident entscheidet das Operating Model, nicht das Produkt
In einer Folie sehen Incident-Programme oft perfekt aus. In der Realität entscheidet sich alles an drei Fragen:
Wer darf isolieren? (Endpoint, Account, Netzwerksegment, SaaS-Session)
Wer entscheidet? (Security, IT Ops, Produktteam, Management)
Wer trägt Ownership? (klarer Incident Commander, klare Rollen)
In vielen Unternehmen gibt es Tools, aber im Ernstfall fehlt: Berechtigung, Klarheit, Routine, ein eingeübter Ablauf. Und dann wird aus Minuten schnell eine Stunde, aus einer Stunde ein halber Tag.
Merksatz: Tools helfen. Aber im Incident gewinnt das Team, das Entscheidungen schnell treffen kann.
4) 8–10 KPIs reichen — Tier-0/1 first
Zu viele KPIs führen fast immer zu einem Effekt: Man optimiert Zahlen statt Sicherheit. Ich halte es bewusst schlank: 8–10 Steuerungs-KPIs, konsequent auf Tier-0/1 ausgerichtet (Crown Jewels, Identität, kritische Prozesse).
Warum Tier-0/1 so wichtig ist: Weil „Durchschnitt“ dich betrügt. 95% Abdeckung klingt gut — bis die 5% genau die Systeme sind, die den größten Impact haben.
Merksatz: Wenn ein KPI nicht zu einer Entscheidung führt, ist er Deko.
5) Sag seltener „Nein“, häufiger „Ja, wenn…“
Das ist eine der größten Führungslektionen: Ein hartes „Nein“ macht dich schnell zum Bremsklotz — auch wenn du fachlich recht hast.
In der Praxis ist es meist besser, in Optionen zu denken: „Ja, wenn wir diese Bedingung erfüllen“, „Ja, aber mit diesen Trade-offs“, „Ja, und hier ist die sicherere Alternative“.
Mein Standardformat: 2 sichere Optionen + Trade-offs. Das schafft Tempo, Transparenz und Vertrauen.
Merksatz: Security gewinnt durch Enablement — nicht durch Blockade.
6) Ausnahmen sind normal — unbegrenzte Ausnahmen sind Risiko
Jedes Unternehmen hat Legacy, Engpässe, Spezialfälle. Security-Exceptions sind nicht das Problem. Das Problem sind Exceptions ohne Ende. „Nur vorübergehend“ ist die häufigste Lüge in Security-Programmen.
Owner — eine Person, keine Abteilung
Mitigation — was reduziert das Risiko bis zur Lösung?
Ablaufdatum — wirklich ein Datum
Review-Termin — wenn es länger dauert
Merksatz: Zeitlich unbegrenzte Ausnahmen sind versteckte Security-Schulden.
7) Kommunikation schlägt Perfektion
Die beste technische Lösung bringt nichts, wenn sie nicht verstanden wird. Als CISO ist Kommunikation nicht „nice to have“. Sie ist ein Control.
Die 30-Sekunden-Regel: Wenn du eine Initiative nicht in 30 Sekunden erklären kannst, bekommst du keine Priorität, kein Budget, keine echte Unterstützung. Und du verlierst dein Gegenüber.
Was ich in der Praxis nutze: Sehr kurze Executive Summaries (3 Punkte, 1 Entscheidung), klare Sprache ohne Jargon, Story über Impact („Was passiert, wenn wir nichts tun?“).
Merksatz: Klarheit ist ein Sicherheitsfaktor. Unklarheit ist Risiko.
Wenn ich heute neu anfangen würde
Wenn ich heute als CISO in eine neue Organisation käme und schnell Wirksamkeit zeigen müsste, würde ich fokussieren auf:
1. Identity (PAM, phishing-resistente MFA, Conditional Access)
2. Logging/Visibility (kritische Quellen, Qualität, Nutzbarkeit)
3. Restore-Tests (Wiederherstellbarkeit wirklich beweisen)
Das sind die drei Säulen, die am schnellsten Risiko spürbar reduzieren, Incident-Resilienz erhöhen und Vertrauen im Business schaffen.
Diese Themen behandle ich ausführlich in meinem Buch Cybersecurity für Executives und in der Executive Masterclass — dort üben wir genau diese Entscheidungen live in einer 3-stündigen Krisensimulation.