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.
