Open Innovation: guide e best practice

IT Security per Project Manager: Guida Operativa 2026

Il 68% dei progetti che subiscono una violazione dei dati viene compromesso non da un attacco esterno sofisticato, ma da una falla interna al team di progetto: una credenziale condivisa via email, un documento caricato su un servizio cloud non autorizzato, un accesso non revocato dopo la fine del contratto. Secondo ricerche di settore, il costo medio di una violazione per una PMI europea supera i 150.000 euro. Eppure la maggior parte dei project manager considera la sicurezza informatica un problema dell'IT, non loro. Questo è l'errore più costoso che si possa fare. La IT security per project manager non è un corso avanzato per tecnici. È una competenza operativa che cambia il modo in cui si pianifica un progetto, si gestiscono i fornitori e si proteggono le informazioni sensibili del team. Nelle prossime sezioni spiego cosa deve sapere concretamente un project manager sulla sicurezza IT — e cosa deve smettere di ignorare. Perché la sicurezza IT è responsabilità del project manager, non dell'ufficio tecnico La delega cieca al reparto tecnico è la prima causa di vulnerabilità nei progetti. L'IT può definire le policy. Ma è il project manager che decide chi entra nel team, quali strumenti si usano, quali dati si condividono e con chi. Queste sono decisioni operative con implicazioni di sicurezza dirette. Considera un progetto tipico: 8-12 persone, due o tre fornitori esterni, documenti che transitano tra email, piattaforme di collaborazione e chat aziendali. Ogni nodo è un potenziale punto di accesso non controllato. Il project manager è l'unica figura con visibilità simultanea su tutti questi nodi. In Italia, il GDPR prevede sanzioni fino al 4% del fatturato annuo globale per le violazioni. Non è un rischio astratto. È un rischio di progetto, da inserire nel registro dei rischi con la stessa serietà di un ritardo sulla consegna. Se stai lavorando su un processo strutturato di gestione delle idee e dei progetti , integrare la sicurezza fin dalla fase di pianificazione non aggiunge complessità: la riduce, perché evita le crisi a progetto avanzato. I 5 rischi di sicurezza IT che colpiscono più spesso i team di progetto Non serve un elenco di 50 minacce. Servono le 5 che colpiscono davvero i team di progetto. 1. Gestione degli accessi non strutturata. Si aggiungono collaboratori, consulenti e fornitori durante il progetto. Gli accessi, però, quasi mai vengono revocati alla fine. Il risultato è che persone esterne continuano ad accedere a sistemi aziendali per mesi dopo la chiusura del progetto. È una delle vulnerabilità più difficili da rilevare e delle più facili da prevenire. 2. Uso di strumenti non approvati. Il team usa app di messaggistica personali, servizi di file sharing gratuiti, tool di produttività non aziendali. È il cosiddetto "shadow IT". Si stima che nelle PMI italiane oltre il 40% degli strumenti usati quotidianamente dai team non sia approvato dall'IT aziendale. 3. Condivisione di credenziali. Password di accesso a sistemi di progetto condivise via email o chat. Una pratica diffusissima. Impossibile da tracciare e da revocare in modo selettivo. 4. Mancata classificazione dei dati. Il team non sa distinguere quale documento è pubblico, quale è riservato, quale è critico. Tutti i file finiscono nello stesso spazio condiviso, con gli stessi permessi. Il danno non è ipotetico: è la norma in assenza di regole esplicite. 5. Vendor management senza controllo. Fornitori e consulenti esterni ricevono accessi ampi per comodità operativa. Nessuno verifica le loro policy di sicurezza né contrattualizza obblighi specifici. Quando qualcosa va storto, il progetto paga il conto. Gli errori che i project manager ripetono sulla sicurezza IT — e perché costano caro Il primo errore è trattare la sicurezza come un adempimento da spuntare a inizio progetto. Si firma un documento con l'IT, si fa girare un'email sul corretto uso degli strumenti. Poi non se ne parla più. La sicurezza non è un evento. È un processo continuo per tutta la durata del progetto. Il secondo errore è non includere i rischi di sicurezza nel registro dei rischi. Se un data breach bloccherebbe il progetto per settimane, quel rischio ha una probabilità e un impatto precisi. Va stimato, monitorato e mitigato come qualsiasi altro rischio. Ignorarlo non lo elimina: lo rende solo più difficile da gestire quando si manifesta. Il terzo errore è considerare la formazione del team un problema dell'IT o delle Risorse Umane. Il phishing colpisce le persone, non i sistemi. Se un membro del team clicca su un link malevolo, l'impatto ricade sul progetto. Il project manager è responsabile di aver creato un ambiente in cui il team sa come comportarsi. Questa responsabilità non si delega. 7 controlli di IT security che ogni project manager dovrebbe fare prima del kickoff Questa non è una checklist teorica. È quello che faccio verificare ai team di progetto prima del kickoff e durante le revisioni periodiche. 1. Mappatura degli accessi. Chi ha accesso a cosa, con quale livello di permessi. Aggiornala ogni volta che entra o esce qualcuno dal team. 2. Lista degli strumenti approvati. Definisci all'inizio quali piattaforme il team può usare. Documentala. Aggiornala. 3. Procedura di offboarding. Quando un membro del team lascia il progetto, entro 24 ore devono essere revocati tutti gli accessi. Metti questa procedura nel piano di progetto. 4. Classificazione dei documenti. Almeno tre livelli: pubblico, interno, riservato. Ogni documento deve avere una classificazione visibile. 5. Clausole di sicurezza nei contratti con i fornitori. Ogni fornitore esterno deve firmare un accordo esplicito su come tratta i dati del progetto. Non basta la buona fede. 6. Piano di risposta agli incidenti. Se domani si verifica una violazione, chi avvisi? Entro quanto tempo? Chi è il referente IT? Questo piano deve esistere prima che serva. 7. Formazione minima del team. Almeno un briefing iniziale su phishing, gestione delle password e uso degli strumenti approvati. Trenta minuti possono evitare settimane di crisi. Strutturare questi controlli all'interno di un sistema di documentazione strutturata come IdeaDocs significa rendere la sicurezza parte naturale del metodo, non un'aggiunta dell'ultimo minuto. Come integrare la sicurezza IT nel ciclo di vita del progetto senza rallentarlo Il timore principale dei project manager è che aggiungere controlli di sicurezza rallenti l'esecuzione. È un timore comprensibile. Ed è infondato, se si integra la sicurezza fin dalla fase di pianificazione invece di gestirla come un'emergenza a progetto avanzato. In fase di avvio, la mappatura degli accessi e la selezione degli strumenti richiedono meno di due ore. Molto meno di quanto costa gestire una violazione in corsa. In fase di esecuzione, il controllo degli accessi è un task ricorrente come qualsiasi altra attività di monitoraggio. In fase di chiusura, l'offboarding strutturato è la procedura più trascurata — e più facile da automatizzare. Il punto è questo: la sicurezza IT non aggiunge lavoro al project manager. Ridefinisce come si organizza il lavoro già esistente. Lo rende misurabile, tracciabile, difendibile di fronte al cliente e alla direzione. Domande frequenti Cosa deve sapere un project manager sulla sicurezza informatica? Un project manager deve conoscere i fondamenti della gestione degli accessi, la classificazione dei dati, le principali minacce che colpiscono i team (phishing, shadow IT, accessi non revocati) e come inserire i rischi di sicurezza nel registro dei rischi di progetto. Non serve una competenza tecnica profonda: serve consapevolezza operativa e capacità di coordinamento con l'IT. Come si inserisce la sicurezza IT nel piano di progetto? La sicurezza IT si integra nel piano di progetto come insieme di attività, rischi e milestone specifici. Include: mappatura degli accessi in fase di avvio, revisioni periodiche in fase di esecuzione, procedura di offboarding in chiusura. I rischi di sicurezza vanno registrati nel registro dei rischi con probabilità e impatto stimati. Il project manager è responsabile legalmente delle violazioni dei dati nel progetto? La responsabilità legale formale dipende dalla struttura aziendale e dal ruolo definito contrattualmente. Tuttavia, secondo il GDPR, l'organizzazione è responsabile delle violazioni che avvengono nell'ambito delle sue attività. Il project manager che non ha implementato controlli adeguati può essere esposto a conseguenze disciplinari e, in alcuni casi, a responsabilità civile. Cos'è lo shadow IT e perché è un rischio nei progetti? Lo shadow IT è l'uso di strumenti tecnologici non approvati dall'azienda da parte dei membri del team. È un rischio perché questi strumenti non rispettano le policy di sicurezza aziendali, non sono integrati nei sistemi di backup e controllo, e possono esporre dati sensibili del progetto a terze parti non autorizzate. Si stima che colpisca oltre il 40% delle PMI italiane. Come si gestisce la sicurezza quando si lavora con fornitori esterni? Ogni fornitore esterno che accede a dati o sistemi del progetto deve firmare un accordo esplicito sulla protezione dei dati (spesso un Data Processing Agreement se si tratta di dati personali). Gli accessi devono essere limitati al minimo necessario e revocati alla fine della collaborazione. Le policy di sicurezza del fornitore devono essere verificate prima dell'ingaggio. Esistono certificazioni di sicurezza IT utili per i project manager? Sì. Le più rilevanti per chi gestisce progetti sono la ISO 27001 (gestione della sicurezza delle informazioni) come riferimento metodologico, e corsi specifici sulla cybersecurity awareness. Non è necessario diventare un esperto tecnico: è utile comprendere i framework di rischio e come si integrano con le metodologie di project management come PMBOK o PRINCE2. Quello che un project manager non può più permettersi di ignorare — e uno strumento per non farlo La sicurezza IT nei progetti è responsabilità operativa del project manager, non solo dell'IT. I rischi di sicurezza vanno inseriti nel registro dei rischi con la stessa serietà di qualsiasi altro rischio di progetto. Sette controlli concreti — dalla mappatura degli accessi all'offboarding strutturato — sono sufficienti per ridurre drasticamente l'esposizione al rischio. Lo shadow IT colpisce oltre il 40% delle PMI italiane: definire gli strumenti approvati all'inizio del progetto è la contromisura più semplice ed efficace. Integrare la sicurezza in fase di pianificazione costa meno del 2% del tempo totale di progetto. Gestire una violazione a progetto avanzato può costare il progetto intero. Il problema, nella maggior parte dei team, non è la mancanza di volontà. È la mancanza di un metodo condiviso: un posto unico dove ruoli, accessi, documenti e processi siano visibili, tracciabili e aggiornabili da tutti. Senza quel metodo, ogni progetto ricomincia da zero — e i rischi si accumulano in silenzio. BrainRooms è la piattaforma che permette al tuo team di lavorare in modo strutturato, con visibilità su chi fa cosa, quando e con quali permessi. Perché un progetto senza controllo non è un problema dell'IT. È un problema tuo. ```