De la PM la Security: Ce se transferă efectiv

Managerii de proiect care se gândesc la o trecere în cybersecurity presupun adesea că pornesc de la zero. Nu e adevărat. Abilitățile soft care te-au făcut bun în conducerea de proiecte — stakeholder management, risk tracking, coordonarea incidentelor — se mapează direct pe munca de security. Ce-ți lipsește este fundamentul tehnic, și acea decalaj se poate închide în 12-18 luni dacă ești deliberat în privința asta.

Ce se transferă efectiv

Dacă ai condus un proiect cu un risk register, înțelegi deja logica de bază a unei evaluări de risc de securitate: identifici activul, estimezi probabilitatea și impact, decizi asupra unui tratament (accept, mitigate, transfer, avoid). Echipele de security folosesc exact același cadru, doar aplicat sistemelor în loc de livrabile. NIST's Risk Management Framework și ISO 27005 sunt versiuni formalizate ale ceea ce un manager certificat PMP deja face intuitiv.

Managementul incidentelor este o altă suprapunere. A conduce o war room într-o pană de producție e similar structural cu a o conduce într-un eveniment de ransomware: cineva trebuie să dețină comunicațiile, cineva trebuie să urmărească cronologia, cineva trebuie să ia decizii sub presiune fără informații complete. Echipele de security numesc asta incident command; tu ar putea să-l recunoști ca management de criză cu alt vocabular.

Supravegherea furnizorilor și a contractelor se transferă și ea bine. Third-party risk management — validarea furnizorilor SaaS, revizuirea rapoartelor SOC 2, negocierea clauzelor de securitate în contracte — e o nișă în creștere în roluri GRC (governance, risk, and compliance), și recompensează pe cineva care deja știe cum să citească un contract și cum să gestioneze o relație cu un furnizor.

Decalajul tehnic pe care nu-l poți sări

Aici se-ncurcă cele mai multe tranziții de la PM la security: nu poți gestiona un SOC, revizui un raport de pen test sau să stabilești domeniu pentru un plan de remediere a vulnerabilităților fără a înțelege ce-i dedesubt. Ai nevoie de cunoștințe de lucru în networking (TCP/IP, DNS, cum filtrează efectiv un firewall traficul), linie de comandă Linux de bază, și cum funcționează în practică vulnerabilitățile OWASP Top 10, nu doar ca bullet points pe o diapozitiv.

Aceasta nu înseamnă a deveni pentester. Înseamnă a putea citi o ieșire de scan Nessus sau Qualys și a înțelege de ce un patch lipsă pe port 445 conteaza, sau de ce o instanță Redis neautentificată expusă internetului e un incendiu de grad cinci. Petrece timp cu un home lab: pornește câteva VM-uri în VirtualBox, instalează pfSense ca firewall, rulează Wireshark împotriva propriului trafic. Conceptele se prind mai repede când ai stricat ceva tu însuți.

Certificări care au sens pe această cale

Eviți să saturi direct la OSCP sau orice gândire offensive-security-heavy — aia e o cale diferită. Pentru o experiență PM, secvența care de obicei funcționează e:

1. CompTIA Security+ — îți dă vocabularul și conceptele de bază în networking, amenințări și controls.
2. CISM sau CRISC (ISACA) — acestea se-inclină spre governance și risk, ceea ce joacă la punctele tale forte și e adesea mai relevant pentru roluri GRC sau security program manager decât certificările tehnice.
3. CISSP — eventuali, odată ce ai o expunere hands-on; necesită oricum cinci ani de experiență relevantă pentru certificarea completă, deci e un scop pe cale de mijloc, nu un punct de plecare.

Evită colectarea certificărilor ca înlocuitor pentru experiență. Un hiring manager pentru un rol de Security Program Manager vrea să vadă că poți vorbi inteligent despre un proces de triage de alerte SIEM, nu că ai patru acronime după nume.

Unde aterizezi efectiv mai întâi

Punctul de intrare realist de obicei nu e