Von PM zu Security: Was sich wirklich überträgt
Ein praktischer Blick darauf, wie Projektmanager in Cybersecurity-Rollen wechseln können, welche Fähigkeiten sich übertragen und welche Lücken Sie noch schließen müssen.
Projektmanager, die über einen Wechsel in Cybersecurity nachdenken, gehen oft davon aus, dass sie bei null anfangen. Das stimmt nicht. Die Soft Skills, die Sie gut im Projektmanagement gemacht haben — Stakeholder-Management, Risiko-Tracking, Incident-Koordination — lassen sich direkt auf Security-Arbeit anwenden. Was fehlt, ist die technische Grundlage, und diese Lücke lässt sich in 12–18 Monaten schließen, wenn Sie dabei zielgerichtet vorgehen.
Was sich wirklich überträgt
Wenn Sie ein Projekt mit einem Risk Register geleitet haben, kennen Sie bereits die Kernlogik einer Security-Risiko-Bewertung: Asset identifizieren, Wahrscheinlichkeit und Auswirkung schätzen, eine Behandlung festlegen (akzeptieren, mindern, weitergeben, vermeiden). Security-Teams verwenden exakt denselben Rahmen, nur angewendet auf Systeme statt auf Lieferungen. NIST's Risk Management Framework und ISO 27005 sind formalisierte Versionen von dem, was ein PMP-zertifizierter Projektmanager bereits intuitiv tut.
Incident Management ist ein weiterer Überschneidungsbereich. Ein War Room während eines Produktionsausfalls zu leiten ähnelt strukturell dem Leiten eines War Rooms während eines Ransomware-Events: Jemand muss die Kommunikation verantworten, jemand muss die Timeline nachverfolgen, jemand muss unter Druck entscheidungen treffen, ohne alle Informationen zu haben. Security-Teams nennen das Incident Command; Sie könnten es als Krisenmanagement mit anderem Vokabular erkennen.
Vendor- und Contract-Oversight übertragen sich ebenfalls gut. Third-Party-Risk-Management — die Bewertung von SaaS-Anbietern, die Überprüfung von SOC 2-Berichten, die Verhandlung von Security-Klauseln in Verträgen — ist eine wachsende Nische in GRC-Rollen (Governance, Risk and Compliance), und sie belohnt jemanden, der bereits weiß, wie man einen Vertrag liest und eine Vendor-Beziehung verwaltet.
Die technische Lücke, die Sie nicht überspringen können
Hier stecken die meisten PM-to-Security-Übergänge fest: Sie können ein SOC nicht verwalten, einen Penetration-Test-Bericht nicht überprüfen oder einen Vulnerability-Remediation-Plan nicht abstecken, ohne zu verstehen, was darunter liegt. Sie brauchen Arbeitskenntnisse in Netzwerken (TCP/IP, DNS, wie ein Firewall Traffic tatsächlich filtert), grundlegende Linux-Befehlszeile und wie die OWASP Top 10 Schwachstellen in der Praxis funktionieren, nicht nur als Aufzählungspunkte auf einer Folie.
Das bedeutet nicht, ein Penetration Tester zu werden. Es bedeutet, in der Lage zu sein, eine Nessus- oder Qualys-Scan-Ausgabe zu lesen und zu verstehen, warum ein fehlender Patch auf Port 445 wichtig ist, oder warum eine unauthentifizierte Redis-Instanz im Internet ein großes Problem ist. Verbringen Sie Zeit mit einem Home Lab: Starten Sie ein paar VMs in VirtualBox, installieren Sie pfSense als Firewall, führen Sie Wireshark gegen Ihren eigenen Traffic aus. Konzepte verfestigen sich schneller, wenn Sie selbst etwas beschädigt haben.
Zertifikationen, die für diesen Weg sinnvoll sind
Vermeiden Sie es, direkt zu OSCP zu springen oder etwas Offensive-Security-Lastiges — das ist ein anderer Weg. Bei einem PM-Hintergrund funktioniert die Reihenfolge üblicherweise so:
- CompTIA Security+ — vermittelt Ihnen das Vokabular und grundlegende Konzepte über Netzwerke, Threats und Controls.
- CISM oder CRISC (ISACA) — diese konzentrieren sich auf Governance und Risk, was Ihre bestehenden Stärken nutzt und ist oft relevanter für GRC- oder Security Program Manager-Rollen als technische Certs.
- CISSP — irgendwann, sobald Sie etwas praktische Erfahrung haben; es braucht fünf Jahre einschlägige Erfahrung für die vollständige Zertifizierung ohnehin, also ist es ein mittelfristiges Ziel, kein Ausgangspunkt.
Vermeiden Sie es, Certs als Ersatz für Erfahrung zu sammeln. Ein Hiring Manager für eine Security Program Manager-Rolle möchte sehen, dass Sie intelligent über einen SIEM Alert Triage-Prozess sprechen können, nicht dass Sie vier Akronyme nach Ihrem Namen haben.
Wo Sie tatsächlich zuerst landen werden
Der realistische Einstiegspunkt ist üblicherweise nicht
Mit KI-Unterstützung geschrieben, von Michal Pilch (CISSP), Korra Studio, überprüft und veröffentlicht.
Das ist eine Notiz aus der Korra-Studio-Wissensdatenbank — die Plattform verbindet jedes Thema mit 1-zu-1-Mentoring.
Kostenlos startenarrow_forward