Allineamento NIS2 per software house: adeguare i processi interni in 6 mesi

A settembre 2025 mi ha contattato il fondatore di una software house torinese con 20 sviluppatori interni, una pipeline di 14 clienti enterprise in settore bancario, sanità e pubblica amministrazione, e un fatturato annuo di circa 3,2 milioni di euro. La richiesta era operativa e stringente: "abbiamo ricevuto tre lettere da tre clienti diversi che ci chiedono di dimostrare il nostro allineamento a NIS2 come fornitore di servizi digitali, e i contratti con due di loro vengono rinnovati a marzo 2026. Se non siamo in grado di rispondere entro gennaio 2026 con documentazione credibile, perdiamo contratti per circa 800.000 euro l'anno". La domanda implicita era se NIS2 si applicasse davvero a loro, in quale categoria ricadessero, e soprattutto se sei mesi fossero realistici per adeguarsi partendo da uno stato in cui l'unica procedura di sicurezza formalizzata era "password complesse su GitLab". Il fondatore non era paranoico né tardivo - era rappresentativo di un pattern che ho visto ripetersi decine di volte nel 2025 e 2026: aziende che scoprono NIS2 non leggendo il testo normativo ma ricevendo richieste di supply chain assessment dai loro clienti, che a loro volta si stanno adeguando come entità essenziali o importanti e stanno imponendo la compliance ai fornitori per propagazione contrattuale.

In sei mesi esatti abbiamo portato quella software house da zero documentazione strutturata a un pacchetto di compliance che ha passato con successo i due audit di verifica imposti dai clienti enterprise più rigorosi. Il percorso non ha richiesto una transformation aziendale: ha richiesto una sequenza disciplinata di interventi pragmatici, con un budget complessivo inferiore ai 40.000 euro fra consulenza esterna, strumenti nuovi e ore interne di sviluppatori. Questo articolo è la roadmap operativa che applico come standard nelle software house italiane con 10-30 dipendenti e contratti B2B nel perimetro NIS2, fase per fase, con il deliverable di ogni fase, il costo reale e i trappoloni di cui nessun consulente commerciale ti avvisa nelle slide di vendita.

In che categoria NIS2 ricade una software house italiana e perché la risposta giusta spesso non è quella che il cliente vorrebbe sentire

La prima cosa da chiarire a chiunque inizi un progetto NIS2 è la questione dell'ambito applicativo, perché il 60% del lavoro inutile che vedo fare su questa normativa deriva dalla confusione sull'ambito. La Direttiva UE 2022/2555, conosciuta come NIS2, pubblicata integralmente su EUR-Lex distingue due categorie principali di soggetti: entità essenziali (Annex I) ed entità importanti (Annex II). Per le software house italiane, la domanda non è "rientro in NIS2?" ma "in quale modalità rientro?". Le software house pure - quelle che producono software per clienti ma non gestiscono direttamente infrastrutture cloud, non erogano servizi DNS, non gestiscono data center - generalmente non rientrano direttamente come entità essenziali o importanti. Ma rientrano quasi sempre indirettamente come fornitori critici di entità che sono nel perimetro, e questa distinzione cambia radicalmente l'approccio operativo.

Nel caso della software house torinese, l'analisi iniziale ha mostrato che loro stessi, come soggetto giuridico, non rientravano nell'Annex I né nell'Annex II: il loro fatturato era sotto la soglia della media impresa UE (250 dipendenti o 50 milioni di fatturato) e nessuna delle loro attività coincideva con i settori elencati direttamente. Ma dodici dei loro quattordici clienti enterprise rientravano nell'Annex I (due banche, tre operatori sanitari regionali) o nell'Annex II (quattro PA, un distributore energetico, due fornitori di telecomunicazioni), e in forza del principio di supply chain security sancito dall'Articolo 21 della direttiva, che elenca le misure minime di gestione del rischio di cybersicurezza, quei clienti dovevano per legge verificare l'adeguatezza della sicurezza della loro supply chain, software house inclusa. In pratica: tu non sei direttamente obbligato, ma il tuo cliente lo è, e il tuo cliente ha bisogno di vedere che tu hai messo in piedi le misure che avresti messo se lo fossi stato - pena la rescissione o non-rinnovo del contratto.

La conseguenza operativa di questa distinzione è che il percorso di adeguamento di una software house "fornitore di soggetti NIS2" può essere più leggero dell'adeguamento di una entità essenziale diretta, ma non può essere superficiale: deve essere documentato con lo stesso rigore perché quella documentazione andrà prodotta a un auditor terzo assunto dal cliente. Il recepimento italiano con il D.lgs. 138/2024, attuato dall'Agenzia per la Cybersicurezza Nazionale (ACN) che governa gli obblighi di notifica incidenti e le sanzioni, ha calibrato sanzioni fino al 2% del fatturato globale per entità essenziali e fino al 1,4% per entità importanti - ma il costo reale del non-allineamento per una software house è solitamente la perdita di contratti, non la sanzione diretta. Il cliente torinese stava perdendo contratti prima ancora che ACN arrivasse con un'ispezione.

Mese 1-2: gap analysis e mappa dei requisiti, fra teoria e pragmatismo

Il primo bimestre è dedicato a produrre una gap analysis seria contro i dieci gruppi di misure dell'Articolo 21 NIS2, mappando per ciascun gruppo lo stato attuale, il gap rispetto alla maturità richiesta e il piano di remediation con priorità. La tentazione è di fare tutto e subito; il pragmatismo impone di ordinare gli interventi per rapporto rischio/costo e di affrontarli in sequenza. I dieci gruppi di misure elencati dalla direttiva sono: policy di gestione del rischio, gestione incidenti, continuità operativa, sicurezza supply chain, sicurezza in sviluppo e acquisizione, efficacia delle misure, training e igiene informatica, crittografia, sicurezza risorse umane, autenticazione forte e gestione accessi.

La gap analysis che produco per ogni cliente è un documento di 20-30 pagine strutturato in dieci capitoli (uno per gruppo di misure) e in ciascun capitolo contiene sempre: la domanda normativa (cosa richiede NIS2), lo stato as-is osservato in azienda (cosa c'è oggi, con evidenze), il gap identificato, la priorità assegnata (critica/alta/media/bassa), l'intervento proposto, la stima di effort in giorni-persona, e il deliverable atteso alla chiusura. Il risultato è una lista priorizzata di interventi che funge da roadmap operativa per i mesi successivi. Sul cliente torinese la gap analysis ha identificato 47 interventi totali, di cui 9 in priorità critica (da chiudere nel primo trimestre), 18 in priorità alta (secondo trimestre), 14 in priorità media (terzo trimestre se rimane budget), 6 in priorità bassa (opzionali o out-of-scope del primo ciclo).

I nove interventi critici che emergono quasi sempre nelle software house sono prevedibili e meritano di essere elencati perché costituiscono il nucleo minimo sotto cui non si scende mai: una policy di gestione del rischio di cybersicurezza versionata e approvata dal management (2 giorni), un piano di incident response con ruoli e procedure operative (3 giorni), una vulnerability disclosure policy pubblica che definisca come chiunque può segnalare vulnerabilità nei prodotti dell'azienda (1 giorno), un registro degli incidenti con classificazione per severity e obbligo di notifica alle autorità nei casi previsti (2 giorni), un programma di training di sicurezza con cadenza almeno annuale per tutto il personale (3 giorni per setup + 1 giornata per il delivery formativo), l'introduzione della multi-factor authentication obbligatoria su tutti gli accessi amministrativi e su repository Git (2 giorni), la cifratura dei dati in transito e a riposo per tutti i servizi che gestiscono dati cliente (5-10 giorni a seconda dello stato attuale), la gestione centralizzata degli accessi con principio del minimo privilegio (4 giorni), la log retention strutturata con almeno 180 giorni di conservazione per i log di sicurezza applicativi e infrastrutturali (3 giorni per setup iniziale più costo ricorrente di storage).

Stai cercando un Consulente Informatico esperto per accompagnare la tua software house nel percorso di allineamento NIS2 senza sprecare tempo in interventi cosmetici o in tool vendor-driven? Nel mio profilo professionale trovi l'esperienza concreta su gap analysis, incident response plan, log retention e audit di supply chain per PMI italiane nel perimetro NIS2.

Mese 3: vulnerability disclosure policy, registro asset e baseline hardening applicativa

Chiusa la fase di analisi, il terzo mese è dedicato agli interventi a più alto impatto percepito dal cliente enterprise che audita la supply chain. Il pragmatismo qui è ancora più necessario: un auditor esperto guarda per prima cosa tre cose, e se tutte e tre sono in ordine spesso dà per scontato che il resto sia sufficiente. Quelle tre cose sono: l'esistenza di una vulnerability disclosure policy pubblica, l'esistenza di un registro degli asset software/infrastrutturali mantenuto, e l'evidenza di hardening applicativo sui prodotti rilasciati al cliente stesso.

La vulnerability disclosure policy è un documento che ho standardizzato in un template di mezza pagina che ogni cliente adotta con minime personalizzazioni. Contiene: un indirizzo email dedicato ([email protected]) con PGP opzionale, una promessa di risposta entro 72 ore lavorative, un impegno di non-prosecuzione giudiziale verso il ricercatore di buona fede, la specifica dei sistemi in scope e quelli esclusi, e il riferimento al framework ISO/IEC 29147:2018 per il vulnerability disclosure responsabile come standard di riferimento. La policy va pubblicata su una pagina /security del sito aziendale, referenziata in security.txt a /.well-known/security.txt secondo RFC 9116, e linkata visibilmente nel footer. Il costo di produzione e pubblicazione è di una giornata, il valore percepito dall'auditor è sproporzionato rispetto al costo.

Il registro degli asset è dove molte software house si perdono, perché la tentazione è di costruirlo come CMDB enterprise in un tool dedicato (Jira Assets, ServiceNow, Device42) e spendere tre mesi di setup. Per una software house con 20 dipendenti questo è eccessivo, e il registro che propongo è un file CSV versionato in Git con cinque colonne essenziali per ogni asset: identificativo, descrizione, tipo (server, repository, servizio esterno, dispositivo utente), responsabile, data ultima review. Ogni trimestre il responsabile IT (o un ruolo equivalente) fa un passaggio di review che aggiorna le ultime due colonne e aggiunge/rimuove righe. La vera innovazione non è il formato - è la disciplina del passaggio trimestrale, che garantisce che il registro non diventi stantio dopo sei mesi.

L'hardening applicativo sui prodotti rilasciati al cliente è l'area più tecnica e quella che il mio approfondimento sulla checklist di hardening Laravel e Symfony in 14 giorni per le PMI che si preparano a NIS2 copre in dettaglio per lo stack PHP. Le voci critiche che verifico come parte della gap analysis sono: header HTTP di sicurezza (HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy), gestione delle sessioni con cookie flags completi (Secure, HttpOnly, SameSite), rate limiting sui login e sulle API pubbliche, mascheramento degli errori in produzione, rotazione delle chiavi applicative con procedura documentata, separazione fra segreti di staging e produzione con vault dedicato, logging strutturato di eventi di sicurezza con chi/cosa/quando/dove per ogni azione sensibile. Sul cliente torinese questa parte ha richiesto 12 giornate-uomo distribuite su tre delle quattro applicazioni enterprise in rilascio, e il beneficio è stato visibile immediatamente nel cambio di linguaggio nelle conversazioni con i clienti: da "vi chiediamo se avete implementato X" a "rileviamo che avete implementato X, possiamo procedere".

Mese 4: incident response plan con esercitazione, e la disciplina della notifica in 24 ore

Il quarto mese è quello dell'incident response plan e della sua prima esercitazione pratica. La direttiva NIS2 all'Articolo 23 impone una timeline di notifica che va rispettata nel concreto, non solo scritta in un documento: early warning al CSIRT entro 24 ore dalla consapevolezza di un incidente significativo, incident notification entro 72 ore con maggiori dettagli, final report entro un mese. Per la supply chain di entità essenziali, il rispetto di questa timeline diventa un requisito contrattuale esplicito: se la software house non notifica entro 24 ore al cliente che c'è stato un incidente di sicurezza sul sistema fornito, il cliente a sua volta non può notificare entro le 24 ore al CSIRT, e si trova in violazione.

Il piano di incident response che installo è strutturato in cinque pagine di markdown versionato nel repository aziendale, accessibile offline come PDF stampato in ufficio, e contenente: la matrice di classificazione degli incidenti (minore, significativo, grave, critico) con criteri oggettivi basati su numero di utenti impattati, sensibilità dei dati coinvolti, durata del downtime e presenza di accesso non autorizzato confermato; la catena di responsabilità (chi viene avvisato, in quale ordine, attraverso quale canale) con numeri di cellulare e backup di ciascuno; le procedure operative standardizzate per contenimento immediato, raccolta evidenze forensi, notifica alle autorità e comunicazione ai clienti; il template della comunicazione di notifica al CSIRT e al cliente, pre-compilato dove possibile; il registro degli incidenti passati con le lezioni apprese da ciascuno. L'intero documento è vivo - viene aggiornato dopo ogni esercitazione e dopo ogni incidente reale.

L'esercitazione è il componente che molti consulenti dimenticano e che gli auditor invece cercano nei log. Dopo aver prodotto il piano, il cliente torinese ha organizzato un tabletop exercise di mezza giornata con me in qualità di facilitatore: ho presentato un scenario ipotetico (una vulnerabilità critica scoperta in una dipendenza usata in tre dei loro prodotti enterprise in produzione), e il team ha eseguito tutto il protocollo come se fosse reale - dalla classificazione iniziale alla comunicazione finale al cliente. L'esercitazione ha fatto emergere tre gap operativi non ovvi: la matrice di comunicazione assumeva che il CTO fosse sempre disponibile come backup del CISO, ma la CTO era in ferie quella settimana; il template di comunicazione al cliente includeva un campo "impatto sui dati personali GDPR" che in tre casi su quattro il team non sapeva compilare senza una query ad-hoc al database di produzione; la procedura di raccolta evidenze non specificava come preservare il /var/log/ del server quando l'incidente coinvolgeva il server stesso. Tutti e tre i gap sono stati fixati nel piano entro la settimana successiva, e l'esercitazione è stata documentata con un verbale firmato - documentazione che vale oro in fase di audit. Il pattern completo di incident response è descritto in dettaglio nella mia guida operativa all'incident response in 72 ore per applicazioni Laravel e Symfony in regime NIS2.

Mese 5: log retention, SIEM minimo e audit trail degli accessi

Il quinto mese è dedicato al componente più tecnicamente denso: costruire l'infrastruttura di log retention e audit trail che dimostri in qualsiasi momento chi ha fatto cosa nei sistemi dell'azienda. La direttiva NIS2 non specifica un periodo minimo di retention dei log di sicurezza, ma la prassi che si è consolidata nelle linee guida dei CSIRT europei - documentate in dettaglio nei rapporti tecnici ENISA su incident reporting e log management - indica 180 giorni come minimo accettabile per log applicativi e 365 giorni per log di accesso ai sistemi critici. Sul cliente torinese abbiamo scelto 365 giorni come baseline uniforme per semplificare la governance.

Il pattern operativo che implemento è volutamente a basso costo. I log delle applicazioni client (log Laravel/Symfony, log Nginx, log PHP-FPM) vengono forwardati via Filebeat a una istanza Loki self-hosted su un VPS Hetzner CX31 dedicato, con retention di 365 giorni e costo storage inferiore a 30 euro al mese per 300 GB di log compressi. I log di accesso ai repository Git (GitLab/GitHub audit log) vengono esportati settimanalmente via API verso lo stesso storage. I log di accesso ai sistemi critici (server di produzione via SSH, console dei provider cloud, accessi amministrativi alle applicazioni cliente) vengono raccolti via auditd o equivalente del SO, e inviati via syslog a Loki con filtraggio dedicato. L'accesso ai log di sicurezza è ristretto a tre persone designate, ogni accesso genera a sua volta un log, e due volte all'anno viene eseguito un dry-run di "forensic query" dove il responsabile IT deve essere in grado di ricostruire in mezz'ora cosa è successo su un arbitrario sistema in una arbitraria fascia oraria - un esercizio che verifica la copertura effettiva della retention e l'indicizzazione della soluzione.

Il punto critico del log retention non è tecnico ma di governance: la direttiva impone anche la protezione dei log da manomissioni. Questo significa che i log non possono risiedere esclusivamente sullo stesso server che li produce (perché un attaccante che compromette il server può cancellarli prima di essere rilevato), e devono essere accessibili anche al responsabile della sicurezza attraverso un canale distinto da quello usato per l'operazione normale. La soluzione Loki self-hosted soddisfa entrambi i requisiti: lo storage è su un VPS diverso da quelli applicativi, e l'accesso via Grafana è autenticato con credenziali gestite separatamente dal team di sviluppo.

Mese 6: documentazione finale, audit di verifica e come si sopravvive alla supply chain question

Il sesto mese è dedicato alla produzione del pacchetto di documentazione finale che verrà consegnato ai clienti enterprise come evidenza di allineamento. Il pacchetto è strutturato in sette documenti che corrispondono ai sette requisiti più frequentemente richiesti negli audit di supply chain che ho visto nell'ultimo anno: policy di gestione del rischio (5 pagine), piano di incident response (5 pagine), vulnerability disclosure policy (mezza pagina), policy di log retention e accesso (3 pagine), policy di gestione degli accessi e MFA (2 pagine), programma di training di sicurezza con verbali delle ultime sessioni (2 pagine + allegati), registro degli asset critici (CSV esportato in PDF). Il pacchetto è versionato, firmato digitalmente dal legale rappresentante dell'azienda, e aggiornato con cadenza annuale. L'aggiornamento annuale è non negoziabile - la documentazione stantia è un segnale negativo che gli auditor colgono subito.

L'audit di verifica è la prova del nove. Sul cliente torinese, i due audit condotti da terze parti assunti dai clienti enterprise sono stati entrambi completati in una giornata e mezza ciascuno, con un set di domande molto prevedibile che coincideva al 90% con quello per cui la gap analysis iniziale aveva preparato l'azienda. L'auditor chiede di vedere: la policy, quando è stata approvata, chi l'ha approvata; il piano di incident response, l'evidenza dell'ultima esercitazione, il verbale dell'esercitazione; i log retention e una query dimostrativa in cui si recuperi un evento specifico di tre mesi prima; il registro asset e la data dell'ultima review; l'evidenza di MFA su tutti i repository e sui server critici; il training di sicurezza e la lista dei partecipanti dell'ultima sessione; la vulnerability disclosure policy pubblicata. Se questi sette elementi sono in ordine e coerenti fra loro, l'audit passa; se uno soltanto è mancante o contradditorio rispetto agli altri, l'audit si ferma e il cliente enterprise preparare il ritiro del contratto.

L'aspetto più importante che emerge dall'esperienza con il cliente torinese e altri quattro progetti simili nel 2025-2026 è che l'allineamento NIS2 non è un progetto one-shot - è l'istituzione di un ciclo di manutenzione permanente. Le sei mesi di adeguamento costruiscono la base; i mesi successivi devono alimentare quel ciclo con review trimestrali del registro asset, esercitazioni annuali di incident response, aggiornamenti annuali della policy con verbale del management, audit interni periodici. Il costo ricorrente di questa manutenzione, sul cliente torinese, si attesta attorno a 8-10 giornate-uomo all'anno più i costi ricorrenti di storage log e licenze strumenti - un investimento trascurabile confrontato agli 800.000 euro di contratti che erano in gioco. Il valore reale dell'allineamento NIS2, al di là della compliance normativa, è che la software house ha ora un'architettura operativa di sicurezza che la rende più robusta in assoluto: quando a dicembre 2025 è emerso un incidente reale (credenziali compromesse su un account Gitlab di uno sviluppatore che aveva riusato la stessa password su un servizio esterno bucato), il piano di incident response ha funzionato come scritto, il contenimento è partito entro 35 minuti dalla scoperta, e i clienti enterprise sono stati notificati in tempo. Senza l'allineamento NIS2 fatto nei sei mesi precedenti, quell'incidente sarebbe probabilmente costato un contratto. Se gestisci una software house italiana con clienti enterprise che iniziano a chiederti evidenza di allineamento NIS2, oppure se stai già ricevendo questionari di supply chain security a cui non sai come rispondere senza produrre documentazione credibile, contattami per una valutazione iniziale: in una settimana di gap analysis ti consegno la mappa completa degli interventi necessari, la priorità calibrata sul tuo portafoglio clienti, e una stima realistica di budget e tempi per arrivare a un pacchetto di documentazione che passi gli audit reali - non uno che suoni bene nelle slide commerciali.