Cybersecurity ist im Recruiting oft ein zu groĂer Sammelbegriff. In Stellenprofilen steht dann âSecurity Engineerâ, gemeint sind aber gleichzeitig Incident Response, Cloud IAM, ISO 27001, Penetration Testing, Architekturberatung und interne Governance. FĂŒr erfahrene Security-Profile klingt das nicht anspruchsvoll, sondern unscharf.
Genau hier verlieren Unternehmen Zeit. Sie suchen zu breit, sprechen die falschen Profile an oder erwarten von einer Person Kompetenzen, die im Markt auf mehrere Rollen verteilt sind. Wer SOC, GRC, Cloud Security und AppSec sauber trennt, verbessert nicht nur die Ansprache. Er erkennt auch frĂŒher, welche Kompromisse realistisch sind und welche Rolle tatsĂ€chlich besetzt werden muss.
SOC und Incident Response
Fokus auf Monitoring, Analyse, Eskalation, Threat Detection und Reaktion auf Sicherheitsereignisse.
GRC und Compliance
Fokus auf Governance, Risiko, Audits, Richtlinien, Standards und NachweisfĂ€higkeit gegenĂŒber Stakeholdern.
Cloud Security
Fokus auf sichere Cloud-Architekturen, IAM, Netzwerkzonen, Plattformrisiken und Betriebsmodelle.
Application Security
Fokus auf sichere Softwareentwicklung, Code-nahe Risiken, Secure SDLC, Reviews und Engineering Enablement.
Das Problem beginnt, wenn Security als Skill-Liste statt als Aufgabe beschrieben wird
Viele Security-Stellenprofile entstehen aus einer berechtigten Sorge: Das Unternehmen will sicherer werden. Daraus wird aber schnell eine Liste aus Tools, Frameworks, Zertifikaten und Schlagworten. SIEM, ISO 27001, Kubernetes, IAM, Vulnerability Management, DevSecOps, Incident Response, DORA, NIS2 und Cloud werden in ein Profil geschrieben, weil alles wichtig wirkt.
FĂŒr Recruiting ist diese Logik gefĂ€hrlich. Sie macht die Rolle nicht prĂ€ziser, sondern unlesbarer. Ein SOC Analyst arbeitet anders als eine GRC Managerin. Ein Cloud Security Engineer denkt anders als ein AppSec-Spezialist. Alle bewegen sich im Security-Kontext, aber sie lösen unterschiedliche Probleme, sprechen mit unterschiedlichen Stakeholdern und werden von unterschiedlichen Wechselargumenten angesprochen.
Soll die Person Sicherheitsereignisse erkennen, Risiken steuerbar machen, Cloud-Infrastruktur absichern oder Softwareentwicklung sicherer machen? Erst diese Aufgabe entscheidet, welches Profil realistisch gesucht werden sollte.
SOC, GRC, Cloud Security und AppSec im Vergleich
Die folgende Matrix hilft, Security-Rollen nicht nach Begriffen, sondern nach Arbeitslogik zu unterscheiden. Sie ersetzt kein Fachbriefing, aber sie verhindert, dass HR und Fachbereich mit demselben Wort ĂŒber verschiedene Rollen sprechen.
| Rollencluster | Worum es wirklich geht | Typische Signale im Profil | HĂ€ufiger Recruiting-Fehler |
|---|---|---|---|
| SOC / Incident Response | Angriffe, AuffĂ€lligkeiten und Sicherheitsereignisse erkennen, bewerten, priorisieren und eskalieren. | SIEM, Detection Engineering, EDR, Log-Analyse, Playbooks, MITRE ATT&CK, Schicht- oder Bereitschaftskontext. | Ein operatives Monitoring-Profil mit strategischer Security-Architektur oder Compliance-Verantwortung zu ĂŒberladen. |
| GRC / Information Security Governance | Sicherheitsanforderungen steuerbar, prĂŒfbar und anschlussfĂ€hig fĂŒr Management, Audit, Legal und Fachbereiche machen. | ISO 27001, ISMS, Risikomanagement, Audit, Policies, DatenschutznĂ€he, Lieferantenrisiken, regulatorische Anforderungen. | GRC als âweniger technische Securityâ zu unterschĂ€tzen oder gleichzeitig tiefes Engineering-Know-how zu erwarten. |
| Cloud Security | Cloud-Umgebungen so gestalten, dass IdentitĂ€ten, Netzwerke, Plattformdienste und Betriebsprozesse sicher funktionieren. | AWS, Azure oder GCP, IAM, Landing Zones, Kubernetes Security, Secrets Management, Cloud-Networking, Infrastructure as Code. | Cloud Security mit klassischer Infrastruktur-Security gleichzusetzen und moderne Plattform- oder DevOps-Erfahrung zu spĂ€t zu prĂŒfen. |
| Application Security / Product Security | Softwareentwicklung befĂ€higen, Sicherheitsrisiken frĂŒh zu erkennen und sichere Produkte zu bauen. | Secure SDLC, Threat Modeling, Code Reviews, SAST/DAST, OWASP, API Security, Engineering-NĂ€he, Beratung von Entwicklerteams. | AppSec als reines Tool-Scanning zu verstehen, obwohl die Rolle stark von Engineering-Vertrauen und Enablement lebt. |
Warum vermischte Security-Profile den Markt unnötig verengen
Im Cybersecurity Recruiting wirkt ein breites Profil zunĂ€chst attraktiv: Eine Person soll möglichst viele LĂŒcken schlieĂen. In der Praxis reduziert diese Breite aber oft die Zahl plausibler Kandidat:innen. Nicht, weil es keine guten Security-FachkrĂ€fte gibt, sondern weil die Kombination fachlich nicht zusammenpasst oder in einer SenioritĂ€t erwartet wird, die kaum erreichbar ist.
Ein Beispiel: Ein Unternehmen sucht jemanden, der ISO-27001-Audits begleitet, ein SIEM betreibt, Cloud-IAM-Konzepte entwickelt, Penetration-Testing-Ergebnisse bewertet und Entwickler:innen in Secure Coding coacht. Jede einzelne Aufgabe ist nachvollziehbar. Zusammen ergeben sie aber eher eine Security-Funktion als eine realistische Einzelrolle.
FĂŒr Kandidat:innen ist das ein Warnsignal. Seniorere Security-Profile prĂŒfen sehr genau, ob eine Rolle klar gefĂŒhrt, priorisiert und organisatorisch ernst genommen wird. Wenn die Ausschreibung wie eine Sammlung offener Baustellen klingt, entsteht kein Wechselmotiv. Das gilt besonders bei passiven Kandidat:innen, die nicht aktiv suchen und nur auf fachlich klare Rollen reagieren.
Der bessere Startpunkt: Welches Sicherheitsproblem soll die Rolle lösen?
Vor der Suche sollte der Fachbereich nicht nur Skills nennen, sondern die eigentliche Sicherheitsaufgabe beschreiben. Daraus entsteht eine belastbare Rollenlogik, die HR, Recruiting und Hiring Manager gemeinsam nutzen können.
- Mehr operative ReaktionsfÀhigkeit: Dann ist SOC, Detection Engineering oder Incident Response wahrscheinlich nÀher am Bedarf.
- Mehr Nachweisbarkeit und Steuerung: Dann liegt der Schwerpunkt eher bei GRC, ISMS, Risk oder Compliance.
- Mehr Sicherheit in Plattformen und Cloud-Betrieb: Dann braucht die Suche Cloud-Security- und Plattformlogik.
- Mehr Sicherheit in Softwareprodukten: Dann ist AppSec oder Product Security der passendere Ausgangspunkt.
Was Recruiter:innen im Briefing konkret klÀren sollten
Ein gutes Security-Briefing muss nicht jede technische Detailfrage vorwegnehmen. Es muss aber verhindern, dass die Rolle in der Suche stÀndig ihre Richtung Àndert. Besonders hilfreich sind Fragen, die Aufgaben, Stakeholder und Erfolgskriterien trennen.
Geht es um Betrieb, Governance, Architektur, Entwicklungssicherheit oder FĂŒhrung eines Security-Programms?
SOC-Team, Entwickler:innen, Cloud Platform Team, Management, Audit, Datenschutz oder externe Dienstleister?
Weniger Eskalationen, bessere AuditfÀhigkeit, sicherere Cloud-Landing-Zones, schnellere Schwachstellenbehebung oder stÀrkere Security-Akzeptanz?
Hands-on Engineering, regulatorische Sicherheit, Architekturentscheidungen, AnalysefÀhigkeit oder Beratung von Fachbereichen?
Kann Cloud-Erfahrung branchennah gelernt werden? Ist Zertifizierung wichtiger als Projekterfahrung? Wird Deutsch zwingend gebraucht?
Diese Gegenfrage deckt oft schneller auf, ob eigentlich SOC, GRC, Cloud Security oder AppSec gesucht wird.
Wie sich die Ansprache je nach Security-Rolle verÀndert
Security-Profile reagieren selten auf allgemeine Aussagen wie âspannende Herausforderung im Bereich Cybersecurityâ. Relevanz entsteht, wenn die Ansprache zeigt, dass die Rolle verstanden wurde. Ein SOC-Profil will wissen, ob Detection-QualitĂ€t, Tooling, Schichtmodell, Eskalationswege und Incident-Reife passen. Eine GRC-Person achtet auf Management-RĂŒckhalt, regulatorische Ausgangslage und die Möglichkeit, Sicherheit wirklich steuerbar zu machen.
Cloud-Security-Profile prĂŒfen, ob sie moderne Plattformen gestalten oder nur nachtrĂ€glich Risiken dokumentieren sollen. AppSec-Profile fragen sich, ob Security in der Entwicklung willkommen ist oder als Kontrollinstanz gegen Engineering arbeiten muss. FĂŒr alle Rollen gilt: Je klarer der fachliche Kontext, desto eher entsteht ein GesprĂ€ch.
Das ist auch fĂŒr AI-basierte Suche und klassische Suchmaschinen relevant. Inhalte, die Security-Rollen sauber unterscheiden, sind leichter einzuordnen als allgemeine Cybersecurity-Texte. Sie machen sichtbar, dass ein Anbieter nicht nur âITâ sagt, sondern die Rollenlogik dahinter versteht.
Wann eine Rolle geteilt oder neu zugeschnitten werden sollte
Nicht jede Vermischung ist falsch. Gerade in mittelstĂ€ndischen Unternehmen ĂŒbernehmen Security-FachkrĂ€fte hĂ€ufig mehrere Aufgaben. Entscheidend ist, ob die Mischung zur SenioritĂ€t, Organisation und PrioritĂ€t passt. Eine Person kann beispielsweise Cloud Security und DevSecOps verbinden, wenn die Rolle klar produkt- und plattformnah ist. GRC und DatenschutznĂ€he können ebenfalls sinnvoll zusammengehören, wenn es primĂ€r um Steuerung, Nachweisbarkeit und Risiko geht.
Kritisch wird es, wenn operative Daueraufgaben und strategische Aufbauarbeit dieselbe Rolle dominieren sollen. Wer permanent Incidents bearbeitet, wird kaum parallel ein ISMS neu aufbauen. Wer Audit- und Managementkommunikation verantwortet, ist nicht automatisch die richtige Person fĂŒr Kubernetes Hardening. Wer Entwicklerteams beraten soll, braucht Akzeptanz im Engineering und nicht nur Toolkenntnis.
FĂŒr HR bedeutet das: Nicht jede LĂŒcke muss in dieselbe Stelle. Manchmal ist die bessere Entscheidung, eine Security-Rolle enger zu schneiden, externe Expertise punktuell zu ergĂ€nzen oder die Reihenfolge der Besetzung neu zu priorisieren.
HĂ€ufige Fragen zu Security-Rollen im IT-Recruiting
Kann eine Person SOC, GRC, Cloud Security und AppSec gleichzeitig abdecken?
In kleinen Organisationen können Security-Generalist:innen mehrere Themen berĂŒhren. Als vollwertige Rolle ist diese Kombination aber selten realistisch. Die Aufgaben unterscheiden sich in Arbeitsweise, Stakeholdern, technischer Tiefe und Erfolgskriterien.
Welche Security-Rolle sollte zuerst besetzt werden?
Das hĂ€ngt vom gröĂten Risiko ab. Bei akuten Sicherheitsereignissen kann SOC oder Incident Response Vorrang haben. Bei Audit- oder Regulierungsdruck ist GRC oft dringender. Bei Cloud-Transformationen oder Produktentwicklung können Cloud Security oder AppSec wichtiger sein.
Warum reagieren Security-Kandidat:innen oft nicht auf Stellenanzeigen?
Viele erfahrene Security-Profile sind nicht aktiv auf Jobsuche und prĂŒfen sehr genau, ob eine Rolle fachlich klar, organisatorisch ernst gemeint und realistisch zugeschnitten ist. Unklare Sammelprofile erzeugen selten Wechselinteresse.
Welche Rolle spielt HR bei der KlÀrung technischer Security-Profile?
HR muss nicht jede technische Detailentscheidung treffen. Wichtig ist, die richtigen KlĂ€rungsfragen zu stellen, WidersprĂŒche im Profil sichtbar zu machen und mit dem Fachbereich eine suchbare, verstĂ€ndliche und marktgerechte Rollenlogik zu entwickeln.
Wenn Security-Rollen schwer greifbar bleiben
indivHR unterstĂŒtzt Unternehmen in Deutschland und Ăsterreich bei anspruchsvollen IT-Fach- und FĂŒhrungsrollen, darunter Cybersecurity, Cloud, Software, Data, AI und IT Leadership. Besonders hilfreich ist externe UnterstĂŒtzung, wenn Rollenprofile zu breit werden, interne Suche nicht genug passende Profile erreicht oder die fachliche Einordnung vor der Ansprache geschĂ€rft werden muss.
Ein erster Austausch reicht oft, um Suchbarkeit, Zielmarkt und realistische Rollenzuschnitte besser einzuschÀtzen.
