

Viele Unternehmen betrachten Informationssicherheit immer noch als eine Disziplin, die irgendwo tief in der IT-Abteilung angesiedelt ist. Dort sitzen die Administratoren, die Passwortrichtlinien einführen, Firewalls konfigurieren, Updates einspielen und im Ernstfall versuchen, Angriffe abzuwehren. Diese Sichtweise hat sich über Jahrzehnte gehalten, weil IT-Sicherheit tatsächlich in den Serverräumen, Rechenzentren und Netzwerken beginnt. Doch sie ist gefährlich verkürzt – und im Jahr 2025 schlicht nicht mehr haltbar. Informationssicherheit ist längst keine rein technische Aufgabe mehr, sondern ein strategisches Kernthema, das das gesamte Unternehmen betrifft, von der Produktentwicklung über die Lieferkette bis hin zur externen Kommunikation. Und weil sie alle Bereiche betrifft, ist sie letztlich eine Führungsaufgabe, die an der Spitze beginnt und nicht delegierbar ist.
Der Grund dafür ist einfach: Informationssicherheit schützt nicht nur Dateien auf Festplatten, sondern das Fundament des Unternehmens – seine Daten, Prozesse, Beziehungen und seinen Ruf. Wer glaubt, man könne diese Verantwortung komplett an die IT „auslagern“, verkennt zwei Realitäten. Erstens: Die meisten Sicherheitsvorfälle beginnen nicht mit einer komplizierten Zero-Day-Schwachstelle, sondern mit menschlichen Fehlern, organisatorischen Schwächen oder fehlender Priorisierung. Zweitens: Die juristische Verantwortung bleibt in der Unternehmensleitung. Wenn vertrauliche Kundendaten durch einen Angriff oder eine Unachtsamkeit abfließen, wird nicht nur der IT-Leiter befragt, sondern vor allem das Management. In regulierten Branchen wie dem Finanzwesen, im Gesundheitssektor oder bei Betreibern kritischer Infrastrukturen ist diese Verantwortung sogar ausdrücklich in Gesetzen und Aufsichtsregeln verankert.
Die operative IT kann und muss viel leisten – aber sie entscheidet nicht über Risikotoleranzen, Budgets, Prioritäten und Kompromisse zwischen Time-to-Market und Sicherheit. Genau dort verläuft die eigentliche Frontlinie: beim Setzen von Zielen, im Abwägen von Risiken, im Durchsetzen von Standards und in der Vorbildfunktion des Top-Managements.
Die vergangenen Jahre haben den regulatorischen Rahmen massiv nachgeschärft. Mit NIS2 sind Managementpflichten, Meldefristen und Sanktionsrahmen in der EU spürbar verschärft worden. DORA bringt im Finanzsektor eine Detailtiefe, die weit über klassische IT-Standards hinausgeht, inklusive Tests, Vorfallklassen und Drittparteienaufsicht. Die DSGVO verankert Haftungsfragen rund um personenbezogene Daten ebenso wie strenge Meldepflichten und Transparenzanforderungen. Gemeinsam ist all diesen Regelwerken: Sie adressieren ausdrücklich die Unternehmensleitung. Die Botschaft ist eindeutig: Sicherheit ist Governance, nicht nur Technik.
Damit einher geht ein Kulturwandel. „Ich habe das an die IT delegiert“ schützt Führungskräfte nicht mehr – weder reputationsseitig noch rechtlich. Erwartet werden dokumentierte Entscheidungen, regelmäßige Reviews, klare Verantwortlichkeiten, ausreichende Ressourcen und die Fähigkeit, im Vorfall professionell zu handeln.
Informationssicherheit funktioniert am besten, wenn sie in ein klares Governance-Modell eingebettet ist. Bewährt hat sich das Konzept der Three Lines of Defense:
Für die Geschäftsführung folgt daraus eine Leitfrage: Sind diese drei Linien in unserem Haus sauber aufgestellt, klar abgegrenzt und mit ausreichendem Durchgriffsrecht versehen? Ohne diese Klarheit entsteht Schatten-Governance, in der Verantwortung diffundiert – bis zur Krise.
Sicherheit ohne Zielbild bleibt Flickwerk. Die Geschäftsführung muss festlegen, welches Risikoniveau das Unternehmen akzeptiert und welche Prinzipien gelten. Dazu gehören Entscheidungen über:
Ein solches Zielbild ist kein technisches Detaildokument, sondern ein Management-Statement, an dem sich Budget, Roadmap und Metriken ausrichten.
Standards wie ISO 27001 und der BSI IT-Grundschutz liefern hierfür erprobte Vorgehensmodelle. Ein Informationssicherheits-Managementsystem (ISMS) übersetzt die Managementziele in wiederkehrende Routinen: Risiken werden identifiziert, bewertet, behandelt; Maßnahmen werden geplant, umgesetzt, überprüft; Erkenntnisse fließen zurück („Plan–Do–Check–Act“). Wichtig ist: Das ISMS ist kein Papierprojekt, sondern ein Managementsystem mit Kennzahlen, Verantwortlichkeiten und regelmäßigen Reviews auf Vorstandsebene.
Die Unternehmensleitung entscheidet nicht über jede Kontrollliste – aber sie überprüft, ob das System wirkt: ob Risiken sinken, Vorfälle schneller erkannt werden, Wiederherstellungszeiten eingehalten, Lieferanten abgesichert, Audits bestanden werden.
Sicherheitskultur entsteht nicht durch Mails mit „Bitte beachten!“. Sie entsteht durch gelebtes Verhalten. Wer als Vorstand 2-Faktor-Authentifizierung umgeht, weil es „nervt“, sendet ein klares Signal. Wer in Awareness-Trainings sichtbar teilnimmt, in Managementrunden Sicherheitskennzahlen diskutiert und Ausnahmen nur befristet genehmigt, ebenso.
Kultur bedeutet auch: Fehler dürfen gemeldet werden, ohne Gesichtsverlust. Eine starke Sicherheitsorganisation lebt von früher Meldung, nicht von vertuschten Beinahe-Unfällen. Das ist Chefsache – weil nur die Führung das Klima setzen kann, in dem Meldungen willkommen sind und Konsequenzen fair, aber konsequent gezogen werden.
Informationssicherheit ist Teamarbeit über Bereichsgrenzen hinweg. Die IT betreibt Firewalls, Identity- und Patch-Management. Aber:
Ohne orchestrierende Führung verläuft diese Zusammenarbeit zufällig. Mit Führung entsteht ein Programm.
Viele Vorfälle beginnen nicht im eigenen Datacenter, sondern beim Dienstleister: kompromittierte Wartungszugänge, unsichere Cloud-Konfigurationen, lax gehandhabte Admin-Konten. Das Management muss Third-Party-Risiken als strategisches Thema behandeln: Tiering kritischer Lieferanten, Mindestanforderungen, Prüfmechanismen, Exit-Pläne. Es reicht nicht, Zertifikate abzuheften. Entscheidend ist, was geprüft wird, wie häufig und welche Konsequenzen schlechte Ergebnisse haben.
Wer digitale Produkte oder vernetzte Geräte anbietet, trägt besondere Verantwortung. Das Top-Management muss sicherstellen, dass der Secure Development Lifecycle verbindlich ist: Bedrohungsmodellierung, Architektur-Reviews, automatisierte Sicherheits-Scans (SAST/DAST/Dependency), Secrets-Management, signierte Builds, sichere Update-Ketten, koordinierte Vulnerability-Disclosure-Prozesse. Kunden honorieren nachweisbar sichere Produkte – Aufsichtsbehörden erst recht.
Die Cloud verlagert nicht die Verantwortung, sie teilt sie neu. Führungskräfte müssen wissen, wer wofür verantwortlich ist (Shared Responsibility), welche Nachweise vom Anbieter benötigt werden und welche Kontrollen in der eigenen Sphäre greifen (Identitäten, Zugriffe, Datenklassifikation, Logging, Backup/Restore). Besonders riskant ist Schatten-IT: einzelne Teams buchen SaaS-Dienste, die nie durch den Sicherheitsprozess liefen. Ohne klare Policies, Freigabewege und Transparenz wird aus Flexibilität ein unkalkulierbares Risiko.
In Produktion, Logistik oder Gebäudetechnik verschmelzen IT und Operational Technology (OT). Angriffe auf Steuerungen, Fernwartungszugänge oder alte Protokolle können reale Schäden auslösen. Die Geschäftsleitung muss für OT-spezifische Schutzprinzipien sorgen: Zonen/Conduits, strikte Fernwartungsprozesse, Patch-Fenster und Kompensationsmaßnahmen, Monitoring spezialisierter Protokolle, Notfallpläne, Safety-Integration – und vor allem: klare Zuständigkeit zwischen Produktion, Facility und IT.
Kein System ist unangreifbar. Entscheidend ist daher: Wie gut reagieren wir? Das ist Führungsdisziplin. Tabletop-Übungen mit Geschäftsführung, ISB/CISO, IT, Recht, PR und Fachbereichen zeigen gnadenlos, ob Zuständigkeiten klar sind, Meldewege funktionieren, Entscheidungen getroffen werden, ohne in Endlosschleifen zu geraten. Die Unternehmensleitung verantwortet:
Wer hier vorbereitet ist, reduziert Schäden, schützt Reputation und erfüllt Pflichten.
Was das Management misst, wird gemacht. Gute Kennzahlen sind wenige, belastbare und trendfähige Indikatoren, die Wirkung abbilden:
Solche KPIs gehören auf die Agenda von Vorstandssitzungen – quartalsweise mindestens.
Sicherheit kostet – aber Vorfälle kosten mehr. Die Unternehmensleitung muss Investitionen priorisieren, die Risiken messbar senken und Betriebseffizienz steigern: Identity und MFA, Vulnerability/Patch-Automation, Backup-Immutability und Restore-Tests, SIEM/SOAR mit klaren Use-Cases, Härtungs- und Baseline-Programme, DevSecOps-Automationen. Cyberversicherungen können finanzielle Folgen abfedern, ersetzen aber keine Kontrollen; im Gegenteil: Versicherer verlangen Reifegrade und verweigern Leistungen bei grober Fahrlässigkeit.
Ohne Menschen scheitert jede Kontrolle. Führung bedeutet, Ressourcen für rollenbasierte Schulung bereitzustellen: Management-Briefings (Risiken, Meldepflichten, Krisenrollen), Entwicklertrainings (sichere Patterns, SBOMs), Administratoren (Härtung, Logging, Forensik-Basics), Fachbereiche (Datenklassifikation, sichere Kollaboration). Positives Verhalten gehört anerkannt: Meldungen von Schwachstellen, gute Praxis in Teams, Champions-Programme. Verbote allein erzeugen Umgehungsstrategien – sinnvolle, nutzerfreundliche Lösungen erzeugen Akzeptanz.
Es hilft, wenn Führungskräfte die großen Stellhebel kennen:
Diese Säulen liefern die höchste Risikoreduktion pro investiertem Euro.
Wer morgen anfangen will, beginnt so:
Nach 100 Tagen liegen sichtbare Fortschritte vor – und ein Takt, der Resilienz erzeugt.
In einem international tätigen Unternehmen kam es zu einem gravierenden Datendiebstahl. Ursache war kein direkter Angriff auf die IT-Infrastruktur, sondern ein kompromittierter Account eines externen Wartungsdienstleisters. Die technische Sicherheitsarchitektur war grundsätzlich solide, doch das Lieferantenmanagement hatte versäumt, Sicherheitsanforderungen vertraglich zu fixieren, Nachweise einzufordern und privilegierte Zugänge regelmäßig zu rezertifizieren. Hinzu kam eine Kultur, in der Ausnahmen großzügig, aber unbefristet gewährt wurden. Erst nachdem der Vorstand das Thema zur Chefsache erklärte, wurden Tiering, Mindestanforderungen, Rezertifizierung und Notfall-Exit-Strategien verbindlich; parallel wurden Admin-Zugriffe auf PAM und MFA umgestellt. Ergebnis: Angriffsfläche reduziert, Auditbefunde geschlossen, erneute Vorfälle aus der Richtung blieben aus. Der Unterschied lag nicht in einem „magischen Tool“, sondern in Führung, Klarheit und Konsequenz.
Die IT kann schützen, was ihr anvertraut wird. Sie kann Systeme härten, Netzwerke überwachen und Vorfälle analysieren. Doch die Entscheidung, was geschützt werden soll, welche Risiken akzeptabel sind und welche Prioritäten gelten, fällt nicht im Serverraum, sondern im Vorstandsbüro. Informationssicherheit ist Strategie, Governance und Kultur – und damit Chefsache. Nicht als Sonntagsrede, nicht als Unterschrift unter Policies, sondern als gelebte Führungsaufgabe mit Zielen, Kennzahlen, Ressourcen, Vorbildfunktion und Konsequenz.
Wer diesen Anspruch annimmt, erntet mehr als Compliance: schnellere Reaktion im Ernstfall, geringere Ausfallzeiten, robustere Lieferketten, vertrauenswürdigere Produkte – und ein Fundament, auf dem Innovation sicher wachsen kann. In einer Welt, in der digitale Risiken komplexer und vernetzter werden, wird genau das zum Wettbewerbsvorteil. Führung macht den Unterschied. Und Informationssicherheit beginnt – und gelingt – an der Spitze.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.

Kommentare 33
Der Beitrag trifft einen wichtigen Punkt. Mich würde interessieren, wie aus der formalen Vorgabe eine wirksame Sicherheitsroutine wird. Welche Mindestinformation sollte dafür immer vorliegen?
Aus meiner Sicht sollte man mit einem kritischen, aber überschaubaren Fall beginnen. Daran werden fehlende Zuständigkeiten meist schneller sichtbar als in einer allgemeinen Bewertung.
Zusätzlich sollte erkennbar sein, welche Quelle maßgeblich ist. Unterschiedliche Datenstände können sonst schon vor der eigentlichen Bewertung zu Scheingenauigkeit führen.
Genau diese Verbindung ist entscheidend: klein beginnen, aber Wirkung und Entscheidungsfolge vorher festlegen. So bleibt der Aufwand vertretbar und das Ergebnis trotzdem belastbar.
Das überzeugt mich. Ein konkreter Fall mit klarer Zuständigkeit und Nachprüfung dürfte mehr zeigen als ein umfangreiches Modell ohne praktische Rückkopplung.
Eine Frage zur Umsetzung: Wie verhindert man, dass die Dokumentation den eigentlichen Sicherheitsgewinn überlagert?
Für mich hilft die Frage, welche Entscheidung oder Handlung ein Dokument unterstützt. Was im Alltag niemand nutzt, sollte man kritisch prüfen.
Welche Entscheidung müsste zu Verbindung von Risikobewertung und Maßnahmenplanung zuerst fallen, wenn die Maßnahme bereits auf dem Papier abgeschlossen ist?
Ich würde die Umsetzung an einem konkreten Fall nachvollziehen und dabei das tatsächliche Ergebnis prüfen. Entscheidend wäre für mich, ob das Ergebnis für den konkreten Fall nachprüfbar bleibt. Bei Verbindung von Risikobewertung und Maßnahmenplanung sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Welche Rolle sollten Fachbereiche übernehmen, wenn die IT die Technik besser kennt?
Ich würde es so einordnen: Die Fachbereiche müssten die Auswirkungen erklären können. Die technische Sicht und die Bedeutung für den Betrieb ergänzen sich dabei. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Den Nutzen sehe ich. Trotzdem würde ich vermeiden, jede Ausnahme sofort mit einer weiteren Richtlinie zu beantworten. Meine Ausgangsfrage bleibt: Welche Rolle sollten Fachbereiche übernehmen, wenn die IT die Technik besser kennt?
Wie verhindert ihr bei Verbindung von Risikobewertung und Maßnahmenplanung, dass eine vorläufige Lösung ohne erneute Prüfung dauerhaft bestehen bleibt?
Ich würde einen festen Wiedervorlagetermin und eine klare Entscheidung über Fortführung oder Abschluss vorsehen. Wichtig ist, dass die Ausnahme nicht allein deshalb bestehen bleibt, weil niemand mehr nachfragt. Mit Blick auf Verbindung von Risikobewertung und Maßnahmenplanung würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.
Wo würdet ihr bei Behandlung befristeter Ausnahmen anfangen, wenn mehrere Fachbereiche unterschiedliche Prioritäten haben?
Mein Vorschlag wäre, zuerst die betroffene Entscheidung und deren Auswirkungen klären, bevor gemeinsame Kriterien festgelegt werden. Anschließend sollte klar sein, wer die Wirkung prüft und wann erneut entschieden wird. Bei Behandlung befristeter Ausnahmen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Ein weiterer Punkt: Woran würde man erkennen, dass ein Sicherheitsmanagementsystem tatsächlich besser wird? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ein weiterer Punkt: Wie detailliert sollte eine Schutzbedarfseinstufung sein, damit sie noch gepflegt werden kann? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ich sehe darin vor allem eine Gestaltungsfrage. Ich würde die Detailtiefe von den Entscheidungen abhängig machen, die sie unterstützen soll. Eine sehr feine Einteilung hilft wenig, wenn sie im Alltag nicht aktualisiert wird. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Könnte diese Lösung nicht gerade bei kleinen Teams zu viel Aufwand verursachen? Ich würde die Mindestanforderung deutlicher abgrenzen.
Die Grenze sehe ich dort, wo zusätzlicher Aufwand keine bessere Entscheidung mehr unterstützt. Das müsste man an einem konkreten Fall prüfen und nicht pauschal behaupten. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Das wäre für mich ein sinnvoller Einstieg. Wichtig wäre dann, den ersten Fall auch wirklich auszuwerten und nicht nur abzuschließen. Die Ausgangsfrage „Wie detailliert sollte eine Schutzbedarfseinstufung sein, damit sie noch gepflegt werden kann?“ ist damit für mich noch nicht vollständig beantwortet.
Dazu eine Rückfrage: Wie findet man einen vernünftigen Einstieg zwischen zu grober Übersicht und vollständigem Inventar? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Für mich wären zunächst die wichtigsten Leistungen und Informationen zentral. Von dort aus ließen sich die relevanten Abhängigkeiten gezielt ergänzen.
Einverstanden, mit einer Einschränkung: Wenn die notwendige Information fehlt, funktioniert die Abwägung nicht. Woher sollte sie kommen? Meine Ausgangsfrage bleibt: Wie findet man einen vernünftigen Einstieg zwischen zu grober Übersicht und vollständigem Inventar?
Wie verhindert man, dass das Managementsystem hauptsächlich für das nächste Audit gepflegt wird? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Ich sehe darin vor allem eine Gestaltungsfrage. Ich würde seine Ergebnisse in normale Entscheidungen einbinden. Wenn Risiken und Maßnahmen außerhalb des Audits niemanden interessieren, wäre das für mich ein Warnsignal.
Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Meine Ausgangsfrage bleibt: Wie verhindert man, dass das Managementsystem hauptsächlich für das nächste Audit gepflegt wird?
Bei fehlenden Informationen würde ich die Unsicherheit sichtbar machen und eine vorläufige Entscheidung mit klarer Wiedervorlage treffen. Einfach so zu tun, als wäre alles bekannt, wäre die schlechtere Grundlage. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Damit kann ich mehr anfangen. Die Grenze zwischen einem hilfreichen Nachweis und zusätzlichem Papier bleibt für mich der entscheidende Punkt. Die Ausgangsfrage „Wie verhindert man, dass das Managementsystem hauptsächlich für das nächste Audit gepflegt wird?“ ist damit für mich noch nicht vollständig beantwortet.
Welche Grenze sollte bei Behandlung befristeter Ausnahmen ausdrücklich festgelegt werden, damit der Umfang handhabbar bleibt?
Zunächst würde ich den konkreten Anwendungsfall und seine Grenzen festhalten. Ausnahmen sollten anschließend bewusst entschieden werden, damit der Umfang nicht unbemerkt wächst. Für Behandlung befristeter Ausnahmen würde ich den ersten Prüfschritt bewusst klein halten.
Ergänzend würde ich den Blick auf die tatsächliche Wirksamkeit des ISMS richten. Welche Mindestinformation wird dafür im Alltag wirklich benötigt?