Da PM a Security: Cosa Effettivamente Ti Serve

I project manager che pensano di passare a cybersecurity spesso assumono che stiano ripartendo da zero. Non è così. Le soft skill che ti hanno reso bravo nella gestione dei progetti — gestione degli stakeholder, tracciamento dei rischi, coordinamento degli incidenti — si applicano direttamente al lavoro di security. Quello che manca è la base tecnica, e questo gap è colmabile in 12-18 mesi se agisci con metodo.

Cosa effettivamente rimane valido

Se hai gestito un progetto con un risk register, capisci già la logica centrale di una security risk assessment: identificare l'asset, stimare probabilità e impatto, decidere un trattamento (accettare, mitigare, trasferire, evitare). I team di security usano lo stesso framework, solo applicato a sistemi invece che a deliverable. Il NIST Risk Management Framework e ISO 27005 sono versioni formalizzate di quello che un project manager certificato PMP già fa istintivamente.

La gestione degli incidenti è un'altra sovrapposizione. Coordinare una war room durante un'interruzione di produzione è strutturalmente simile a farlo durante un evento ransomware: qualcuno deve gestire le comunicazioni, qualcuno deve tracciare la timeline, qualcuno deve prendere decisioni sotto pressione senza informazioni complete. I team di security lo chiamano incident command; tu potresti riconoscerlo come crisis management con un vocabolario diverso.

La supervisione dei vendor e dei contratti si trasferisce bene. La gestione del rischio di terze parti — fare due diligence sui vendor SaaS, revisionare i report SOC 2, negoziare clausole di security nei contratti — è un settore crescente nei ruoli GRC (governance, risk, and compliance), e ricompensa chi già sa leggere un contratto e gestire una relazione con un vendor.

Il gap tecnico che non puoi saltare

Questo è dove la maggior parte delle transizioni da PM a security si blocca: non puoi gestire un SOC, revisionare un rapporto di penetration test, o pianificare un piano di remediation delle vulnerabilità senza capire cosa c'è sotto. Hai bisogno di conoscenza operativa della networking (TCP/IP, DNS, come un firewall filtra veramente il traffico), nozioni basilari di Linux command line, e come le vulnerabilità OWASP Top 10 funzionano in pratica, non solo come punti su una slide.

Non significa diventare un penetration tester. Significa essere in grado di leggere l'output di una scansione Nessus o Qualys e capire perché una patch mancante sulla porta 445 conta, o perché un'istanza Redis non autenticata esposta su internet è un allarme massimo. Passa tempo con un home lab: fai girare qualche VM in VirtualBox, installa pfSense come firewall, esegui Wireshark sul tuo traffico. I concetti rimangono meglio in mente quando hai rotto qualcosa di persona.

Certificazioni che hanno senso per questo percorso

Non saltare direttamente a OSCP o nulla di offensivo — è una strada diversa. Per un background da PM, la sequenza che di solito funziona è:

1. CompTIA Security+ — ti dà il vocabolario e i concetti fondamentali su networking, minacce e controlli.
2. CISM o CRISC (ISACA) — questi si concentrano su governance e rischio, che sfruttano i tuoi punti di forza esistenti ed è spesso più rilevante ai ruoli GRC o security program manager rispetto alle certificazioni tecniche.
3. CISSP — alla fine, una volta che hai un po' di esposizione pratica; comunque richiede cinque anni di esperienza rilevante per la certificazione completa, quindi è un obiettivo di metà percorso, non un punto di partenza.

Evita di accumulare certificazioni come sostituto dell'esperienza. Un hiring manager per un ruolo di Security Program Manager vuole vedere che sai parlare intelligentemente di un processo di triage di alert SIEM, non che hai quattro acronimi dopo il tuo nome.

Dove effettivamente sbarcherai per primo

Il punto di ingresso realistico di solito non è