Security-Rollen im Unternehmen: Wie Hierarchie, Aufgaben und Abgrenzung wirklich funktionieren

Es gibt unglaublich viele Security oder security-nahe Rollen in Unternehmen. Es gibt keine Blaupause dafür, welche vorhanden sein müssen oder sollten. Es gibt verschiedene Verantwortungsbereiche und oft nicht so klare Abgrenzungen. Ich habe mich hingesetzt und versucht für euch genau dieses Gewirr ein wenig aueinander zu nehmen und kann mir vorstellen hier in Zukunft für noch mehr Klarheit zu sorgen bzw vielleicht sogar doch mal eine Blaupause odfer Empfehlung für Unternehmen unterschiedlicher Größen und Branchen aufzustellen. Aber gehen wir mal rein.

Stell dir ein Unternehmen vor, in dem jeder „irgendwie für Security“ zuständig ist. Der IT-Leiter kümmert sich zusätzlich, der Entwickler schaut beim Absichern mit, der Auditor prüft später, ob alles passt. In der Theorie klingt das flexibel. In der Praxis führt es schnell zu Lücken, Doppelungen und Verantwortungsverwirrung.

Security funktioniert nur, wenn Technik, Organisation und Management ineinandergreifen – und das auf Basis klarer Rollen. Ohne Struktur entstehen typische Probleme: Maßnahmen werden doppelt umgesetzt, wichtige Entscheidungen bleiben liegen, Sicherheitslücken werden nicht sichtbar, und irgendwann ist niemand wirklich verantwortlich, weil alle „etwas dazu tun“. Gerade in Zeiten von NIS-2, ISO 27001, DSGVO und einer wachsenden Cyber-Bedrohungslage reicht ein lockeres „Security machen wir irgendwie“ nicht mehr. Es braucht eine bewusste Security-Organisation: mit getrennten Aufgabenbereichen, klaren Hierarchien und nachvollziehbaren Zuständigkeiten. Nur so wird Security steuerbar, nachvollziehbar und wirksam.

Vom Operativen bis zum Strategischen: Die Struktur einer Security-Organisation

In vielen Unternehmen zeigt sich Security-Struktur auf drei bis fünf Ebenen, die aufeinander aufbauen: operative Rollen, technische Rollen, Architekturrollen, Governance- und Risikorollen sowie Führungsrollen. Jede Ebene hat eigene Ziele und eine eigene Sprache.

Die operative Ebene ist nah am Tagesgeschäft: Hier werden Alarme gesehen, Incidents bewertet und Maßnahmen eingeleitet. Security Analyst, SOC Analyst, Incident Response Analyst oder Vulnerability Analyst beobachten Logs, SIEM-Alarme und Schwachstellenlisten. Sie bewerten Auffälligkeiten, leiten erste Maßnahmen ein und eskalieren, wenn es ernst wird. Diese Rollen sind stark auf Erkennung, Analyse und Reaktion ausgerichtet. Sie entscheiden nicht über übergreifende Richtlinien, Sicherheitsstrategien oder Architekturprinzipien. Ihre Stärke liegt in der schnellen, zuverlässigen Bearbeitung von Sicherheitsereignissen im Alltag. Ohne sie bliebe Security blind: Sie sehen, was passiert, und sorgen dafür, dass Vorfälle nicht ungehört verpuffen.

Auf der nächsten Ebene bauen Security Engineers den Schutz technisch auf. Security Engineer, Network Security Engineer, Cloud Security Engineer, Application Security Engineer oder IAM Engineer konfigurieren Firewalls, IDS/IPS, WAF, EDR und weitere Security-Komponenten. Sie setzen Kontrollen in Netzwerken, Cloud-Umgebungen, Endpunkten und Anwendungen um und automatisieren wiederkehrende Prozesse. Im Unterschied zur operativen Ebene reagieren Engineers nicht primär auf Incidents, sondern bauen langfristige Schutzmechanismen auf. Im Unterschied zu Architekten sind sie stärker in der konkreten Umsetzung als in der übergeordneten konzeptionellen Gestaltung tätig. Sie übersetzen Anforderungen in funktionierende Technik. Ohne sie bliebe Security abstrakt: Architektur und Governance wären trotz guter Konzepte ohne reale Wirkung.

Security Architects übersetzen Sicherheitsanforderungen in technische Leitplanken und Zielarchitekturen. Security Architect, Cloud Security Architect, Network Security Architect oder Enterprise Security Architect entwickeln Prinzipien und Muster, definieren Standards und begleiten Lösungsdesigns aus Security-Perspektive. Sie sorgen dafür, dass Systeme nicht nur punktuell, sondern strukturell sicher gebaut werden. Der zentrale Unterschied zu Engineers ist folgender: Der Architect beschreibt, wie etwas grundsätzlich sicher aufgebaut sein soll. Der Engineer setzt diese Anforderungen praktisch um. Wenn diese Rollen vermischt werden, entstehen oft entweder zu abstrakte Konzepte ohne Umsetzung oder technische Insellösungen ohne übergreifende Linie. Eine klare Trennung schafft hier Stabilität und Konsistenz über das gesamte Unternehmen hinweg.

In Governance, Risiko und Compliance definieren und prüfen Rollen wie Information Security Officer, GRC Manager, Security Risk Manager oder Security Compliance Manager den organisatorischen Rahmen. Sie erstellen und pflegen Security-Richtlinien, steuern Maßnahmen und Verbesserungspfade, bereiten Audits vor und begleiten sie, managen Risiken und setzen sich mit Aufsichtsbehörden und Partnern auseinander. Auch Security Awareness und Schulungen fallen häufig in diesen Bereich. Governance definiert den Rahmen, Technik setzt innerhalb dieses Rahmens um. Governance prüft, ob Maßnahmen angemessen sind und wirken. Die technische und operative Umsetzung ist für die Realisierung verantwortlich. Diese Trennung reduziert Interessenkonflikte und sorgt für Nachvollziehbarkeit, besonders in regulierten Umfeldern wie NIS-2 oder ISO 27001.

Auf der Führungsebene finden sich Rollen wie Security Manager, Head of IT Security, Head of Cybersecurity, Director of Information Security, CISO und CSO. Diese Funktionen tragen die Gesamtverantwortung für Security, in unterschiedlicher Breite und Tiefe. Der CISO ist typischerweise für Informationssicherheitsstrategie, Cyber-Risiko, Governance und die Sicherheitslage des Unternehmens verantwortlich. Der CSO hat häufig einen breiteren Fokus und kann zusätzlich physische Sicherheit, personelle Schutzmaßnahmen oder allgemeine Unternehmenssicherheit abdecken. Die Führungsebene setzt Prioritäten, legt Richtung fest und verantwortet die Eskalation auf Management- oder Vorstandsebene. Sie nimmt nicht die operative Arbeit selbst vor, sondern sorgt dafür, dass die Organisation funktioniert und Security strategisch verankert bleibt. Ohne diese Ebene fehlt oft der Druck und die Sichtbarkeit, die Security im Tagesgeschäft braucht, um wirklich gelebt zu werden.

Vom Analyst bis zum CISO: Der typische Entwicklungsweg und klare Abgrenzungen

Ein häufiger Karriereweg in Security beginnt operativ oder technisch und entwickelt sich dann hin zu Architektur, Management und Führung. Typisch ist ein Pfad von Security Analyst über Security Engineer und Security Architect hin zu Security Manager, Head of Security und schließlich CISO oder CSO. Dieser Weg ist nicht zwingend linear. Viele wechseln von der Technik direkt in Governance, kommen aus Audit oder Compliance in Security oder steigen aus dem IT-Management in CISO-Rollen ein. Was sich mit jedem Schritt ändert, sind die Kompetenzen: Am Anfang zählen technisches Verständnis, Sorgfalt und Reaktionsfähigkeit. Später werden Kommunikation, Priorisierung, Stakeholder-Management, Budgetverständnis und strategisches Denken wichtiger. Security ist also nicht nur eine technische Karriere. Es ist eine Karriere, die von der Umsetzung hin zur Steuerung und Verantwortung wächst.

Eine funktionierende Security-Struktur lebt von drei klaren Fragen: Wer definiert die Vorgabe? Wer setzt sie um? Wer prüft die Wirksamkeit? In einer gesunden Organisation sollte nicht dieselbe Person alle drei Ebenen vollständig abdecken, weil sonst die Kontrolle über die eigene Arbeit fehlt und Interessenkonflikte entstehen. Diese Trennung schafft Nachvollziehbarkeit, Klarheit bei Entscheidungen, weniger Reibung im Alltag und bessere Compliance-Ergebnisse. Gerade in regulierten Umfeldern ist das ein wesentlicher Erfolgsfaktor für eine wirksame Security-Organisation.

KMU: Weniger Rollen, aber dieselbe Logik

In kleinen und mittelständischen Unternehmen sind viele Rollen nicht separat vorhanden. Das ist völlig normal. Oft übernimmt der IT-Leiter Security-Verantwortung zusätzlich. Eine Person macht Engineering, Governance und operative Abstimmung zugleich. Externe Dienstleister übernehmen SOC, Security Services oder Beratung, und ein externer Informationssicherheitsbeauftragter wird genutzt. Das ist nicht per se schlecht, sondern oft pragmatischer als künstliche Aufteilung. Wichtig ist jedoch, dass Aufgaben bewusst kombiniert werden und nicht zufällig verteilt sind. Zuständigkeiten müssen dokumentiert und kommuniziert sein. Auch bei Rollenkombination sollte klar bleiben, wer definiert, wer umsetzt und wer prüft. Externe Unterstützung kann helfen, Governance- und Fachaufgaben zu entzerren, wenn intern die Ressourcen begrenzt sind.

Eine funktionierende Security-Organisation braucht definierte Rollen, klare Hierarchien, getrennte Aufgabenbereiche und bewusste Entscheidungen darüber, wer was macht. Operative Rollen erkennen und reagieren. Technische Rollen setzen Schutzmaßnahmen um. Architekten geben den technischen Rahmen vor. Governance steuert Risiko, Regeln und Kontrolle. Führung trägt die Gesamtverantwortung.

Auch im KMU gilt: Selbst wenn Rollen zusammengelegt werden, müssen Aufgabenbereiche klar benannt und dokumentiert sein. Nur so wird Security steuerbar, nachvollziehbar und wirksam – unabhängig von der Unternehmensgröße.

Stefan Pilarczyk ist Head of Cybersecurity bei BRL und Sprecher beim Cyberwald. Durch seine jahrelange Expertise im Consulting und allen Bereichen der IT hat er bereits viele Unternehmen gesehen und erfolgreich beraten. Als Sprecher ist er oft auf Veranstaltungen zu hören und spricht gerne zu allen Themen im Bereich IT-Security, IT allgemein, KI, Datenschutz und Regulatorik.