Chi guida un PMO in un'azienda italiana di medie-grandi dimensioni ha probabilmente incontrato titoli su Cyber Resilience Act, NIS2 e scadenze 2026 senza riuscire a capire se lo riguardino direttamente. Il problema non è la scarsità di informazione, ma la sua frammentazione: le due normative nascono da logiche diverse, colpiscono soggetti diversi e vengono spesso citate insieme in modo impreciso, come se fossero intercambiabili.
Per chi si occupa di scegliere e governare gli strumenti che custodiscono i dati di progetto - budget, schedule, rischi e decisioni - la domanda concreta è un'altra. Questi obblighi normativi 2026 toccano il software PMO che uso ogni giorno, oppure restano confinati ai reparti IT e prodotto? La risposta richiede di separare due perimetri distinti prima di cercare punti di contatto.
Due normative, due destinatari diversi
Il Cyber Resilience Act obbliga fabbricanti, importatori e distributori di prodotti con elementi digitali. Questa categoria include esplicitamente anche il software standalone, non solo dispositivi hardware o IoT (fonte: Agenda Digitale, Cyber Resilience Act, obblighi e scadenze per le aziende). È una normativa che si rivolge a chi produce e immette sul mercato software, non a chi lo utilizza per gestire progetti.
La NIS2 segue una logica opposta: obbliga i soggetti essenziali e importanti operanti nei 18 settori individuati dal D.Lgs. 138/2024 (fonte: Agenda Digitale, NIS2, come adeguarsi ai nuovi obblighi cyber: i punti chiave). Non riguarda i fornitori di strumenti software in quanto tali. È una normativa organizzativa, che impone requisiti di gestione del rischio cyber e obblighi di notifica agli incidenti a chi opera in settori critici - energia, sanità, trasporti, infrastrutture digitali, tra gli altri. Questi obblighi si applicano indipendentemente dal software che l'organizzazione utilizza.
CRA e NIS2 colpiscono soggetti diversi: il primo i produttori di software e hardware, il secondo le organizzazioni essenziali e importanti. Eppure convergono sugli strumenti PMO, perché questi custodiscono dati di progetto sensibili - budget, roadmap, rischi, decisioni. Nel 2026 la priorità per un PMO non è 'diventare compliance', ma mappare quali obblighi ricadono su di sé, quali sul fornitore del software e quali si trasferiscono per via contrattuale lungo la supply chain.
Dove i due perimetri si incrociano
Il punto di contatto non è normativo in senso stretto, ma pratico. Uno strumento PMO che gestisce budget, schedule, rischi e decision log tratta dati che, per un soggetto NIS2, rientrano nel perimetro della gestione del rischio cyber organizzativo. E se quello stesso strumento è un software standalone commercializzato da un fornitore terzo, quel fornitore può rientrare nel perimetro del CRA come fabbricante di un prodotto con elementi digitali.
Una linea di ragionamento ricorrente nei team PMO suona così: 'Il CRA riguarda IoT e hardware, la NIS2 riguarda energia e sanità, il nostro tool di project management non c'entra'. Non è quantificata in survey pubbliche, ma resta plausibile come schema di pensiero diffuso. È una conclusione intuitiva, ma parte da due premesse incomplete. Primo: il CRA copre anche il software standalone. Secondo: le clausole di supply chain della NIS2 spingono i soggetti essenziali e importanti a richiedere garanzie di sicurezza a tutti i loro fornitori, PMO tool incluso. Questo avviene anche quando l'azienda fornitrice non rientra direttamente nei 18 settori regolati.
Questo secondo meccanismo - la propagazione contrattuale lungo la supply chain - è spesso il più sottovalutato. Un'azienda non diventa 'soggetto NIS2' solo perché vende a un cliente regolato. Può però trovarsi comunque a dover rispondere a requisiti di sicurezza specifici imposti per contratto, perché il suo cliente ha l'obbligo di gestire il rischio anche sui propri fornitori.
Un framework a tre livelli per mappare gli obblighi
Prima di chiedersi 'siamo conformi?', un PMO leader dovrebbe rispondere a una domanda più semplice: su quale dei tre livelli seguenti si trova la propria azienda, rispetto a ciascuna normativa? Le tre categorie non sono alternative: un'azienda può trovarsi contemporaneamente su più livelli.
- Obblighi propri diretti: la tua azienda produce, importa o distribuisce software con elementi digitali (CRA)? Opera in uno dei 18 settori NIS2 come soggetto essenziale o importante?
- Obblighi in capo al fornitore del software PMO: chi ti vende lo strumento che usi per budget, schedule e rischi è lui il fabbricante soggetto agli obblighi CRA su quel prodotto?
- Obblighi trasferiti per via contrattuale: un tuo cliente è un soggetto NIS2 e ti richiede, per contratto o tramite questionario di sicurezza, garanzie sui dati di progetto che condividi con lui?
Il CRA definisce inoltre scadenze temporali precise che vale la pena distinguere per non confonderle. Gli obblighi di reporting sugli incidenti (art. 14 - allarme rapido entro 24 ore, notifica completa entro 72 ore, rapporto finale entro 14 giorni per vulnerabilità sfruttate attivamente o entro un mese per incidenti gravi) si applicano dall'11 settembre 2026. I requisiti essenziali di cybersecurity a pieno regime decorrono invece solo dall'11 dicembre 2027 (fonte: ICT Security Magazine, Cyber Resilience Act obblighi 2026). Sono due scadenze distinte, non intercambiabili, e riguardano fasi diverse dell'applicazione del regolamento.
Il meccanismo di propagazione contrattuale
Il collegamento pratico tra NIS2 e strumenti PMO non passa quasi mai da un obbligo diretto, ma da un meccanismo contrattuale. I soggetti essenziali e importanti devono gestire il rischio cyber anche lungo la propria catena di fornitura. Questo si traduce operativamente in richieste concrete ai fornitori: clausole contrattuali su sicurezza dei dati, questionari di due diligence, obblighi di notifica in caso di incidente che coinvolga dati condivisi. Chi fornisce servizi a un soggetto NIS2 non diventa esso stesso 'soggetto NIS2', ma può ritrovarsi comunque a dover rispondere a requisiti equivalenti per via negoziale.
Simulazione illustrativa — Scenario simulato
Un'azienda di ingegneria che fornisce servizi R&D a un cliente del settore energia (soggetto essenziale NIS2) riceve un questionario di sicurezza del cliente. Il questionario chiede quale strumento PMO viene usato per gestire i dati di progetto condivisi, come è regolato l'accesso a budget e roadmap, e quale processo esiste per notificare un incidente che coinvolga quei dati. Nessuna norma obbliga direttamente l'azienda di ingegneria in quanto tale, ma il contratto con il cliente regolato lo fa. Si tratta di uno scenario costruito a scopo esplicativo, non di un caso reale documentato.
Passi pratici per la mappatura nel 2026
- Censire tutti gli strumenti software che gestiscono dati di progetto - budget, schedule, rischi, decisioni - e identificare chi ne è il fabbricante o fornitore ai fini CRA.
- Verificare se l'azienda opera in uno dei 18 settori NIS2 individuati dal D.Lgs. 138/2024, oppure se è fornitrice di un cliente che vi opera.
- Richiedere al fornitore dello strumento PMO documentazione sul proprio percorso di conformità CRA: gestione delle vulnerabilità, processo di notifica, dichiarazione di conformità del prodotto.
- Rivedere contratti e questionari di sicurezza ricevuti da clienti regolati NIS2, per capire quali garanzie sui dati di progetto vengono richieste per via negoziale, indipendentemente da obblighi normativi diretti.
- Coinvolgere legale e compliance prima di dichiarare esternamente uno stato di 'conformità', distinguendo readiness operativa da certificazione legale formale.
Sul fronte NIS2, alcune fonti collocano al 1° gennaio 2026 la piena operatività degli obblighi di notifica incidenti in Italia (D.Lgs. 138/2024), e al 31 ottobre 2026 il termine per l'implementazione delle misure di sicurezza di base per soggetti essenziali e importanti. Trattandosi di scadenze puntuali derivate da un decreto del 2024, richiedono verifica sul testo normativo aggiornato prima di essere trattate come definitive (fonte: Agenda Digitale, NIS2, come adeguarsi ai nuovi obblighi cyber: i punti chiave).
Va inoltre tenuto distinto il regime sanzionatorio. Le sanzioni NIS2 in Italia arrivano fino a 10 milioni di euro o il 2% del fatturato globale per i soggetti essenziali. Per i soggetti importanti, il tetto scende a 7 milioni di euro o l'1,4% del fatturato. Si tratta di un impianto separato da quello previsto dal CRA, da non citare in modo intercambiabile (fonte: Agenda Digitale, NIS2, come adeguarsi ai nuovi obblighi cyber: i punti chiave).
Cosa questo framework non sostituisce
Trade-off
- Beneficio: Mappare i tre livelli di obbligo permette di rispondere in modo tempestivo e circostanziato ai questionari di sicurezza dei clienti regolati, invece di rincorrere richieste last-minute senza documentazione pronta.
- Costo: Richiede coordinamento tra PMO, ufficio acquisti, legale e fornitore del software, spesso senza un budget dedicato esplicitamente a questa attività.
- Rischio: Trattare la mappatura come un esercizio una tantum, senza aggiornarla quando cambiano fornitori, contratti o perimetro clienti, produce un falso senso di sicurezza.
- Prerequisito: Un decision log e una tracciabilità dei dati di progetto già strutturati, che permettano di documentare chi ha avuto accesso a cosa e quando.
- Limite: Nessuno strumento software determina o certifica la conformità legale a CRA o NIS2: quella valutazione resta responsabilità del legale/compliance officer dell'azienda. ControlRoom, ad esempio, centralizza in modo deterministico budget, schedule, rischi e decision log con audit trail nativo. Questo tipo di tracciabilità può costituire materiale utile per un'analisi di readiness o per rispondere a un questionario di sicurezza, ma non sostituisce una valutazione legale e non calcola né attesta alcuna conformità.
Questo framework riguarda esclusivamente l'intersezione tra CRA, NIS2 e dati di progetto PMO. Non tratta gli obblighi specifici dell'EU AI Act di agosto 2026 per il project management, né la certificazione ISO 42001 per la governance dell'IA. Non tratta nemmeno la tracciabilità delle decisioni AI e il tema delle allucinazioni nella reportistica: sono argomenti distinti, coperti in altri articoli dedicati del cluster.
Prima di chiudere il 2026: tre domande da porsi
Il framework a tre livelli aiuta a orientarsi, ma un PMO leader non ha bisogno di un piano di conformità completo per iniziare. Ha bisogno di rispondere, con chi di competenza, a poche domande concrete che chiudono il cerchio tra ciò che è stato mappato e ciò che resta da verificare.
- Sapete indicare, per ogni strumento che gestisce dati di progetto, chi è il fabbricante o fornitore soggetto a eventuali obblighi CRA, e avete richiesto la relativa documentazione?
- Avete verificato se il vostro cliente principale opera in uno dei 18 settori NIS2 individuati dal D.Lgs. 138/2024, e se questo si traduce in clausole contrattuali specifiche sui dati di progetto condivisi?
- Il vostro decision log e la tracciabilità degli accessi ai dati di budget, schedule e rischi sono strutturati bene? Potete rispondere rapidamente a un questionario di sicurezza senza ricostruire tutto ex post?
- Esiste un referente legale o compliance identificato che validi qualsiasi dichiarazione di readiness prima che venga comunicata a un cliente o inserita in un'offerta commerciale?
Nessuna di queste domande richiede di 'diventare compliance' nel senso di ottenere una certificazione. Richiede piuttosto di sapere, con precisione, su quale dei tre livelli - obblighi propri, obblighi del fornitore, obblighi trasferiti per contratto - si colloca ciascuna parte della propria attività. Richiede anche di avere a disposizione la documentazione per dimostrarlo quando viene richiesta.
CRA e NIS2 continueranno a essere citate insieme nei prossimi mesi, spesso in modo impreciso. Per un PMO che gestisce dati di progetto sensibili, la protezione più concreta non è inseguire ogni titolo normativo. È mantenere aggiornata la mappa dei tre livelli descritta in questo articolo, rivedendola ogni volta che cambiano fornitori software, contratti con clienti regolati o perimetro dei settori serviti.