Una PMI può iniziare a occuparsi di NIS2 perché rientra direttamente nel suo ambito oppure perché un cliente le chiede garanzie sulla sicurezza dei servizi forniti. Sono situazioni da distinguere: ricevere un questionario da un committente non dimostra, da solo, che l’impresa sia un soggetto essenziale o importante.
Per chi sta acquistando un gestionale, un portale o un’integrazione, la questione diventa concreta: quali dati tratta il sistema, chi vi accede, come si mantiene e cosa succede in caso di incidente? La scelta del software deve tenere conto di queste risposte, insieme alle responsabilità organizzative.
NIS2 si applica a tutte le PMI?
No. Il decreto legislativo 138/2024 recepisce NIS2 in Italia. L’articolo 3 sull’ambito di applicazione combina tipologie di soggetti, settori, criteri dimensionali ed eccezioni, comprese situazioni indipendenti dalla dimensione. Non basta quindi contare i dipendenti o riconoscersi genericamente come azienda tecnologica.
Prepara una scheda con attività effettive, servizi forniti, struttura del gruppo e comunicazioni ricevute dall’autorità. Affida la verifica a chi segue l’inquadramento normativo dell’impresa, consultando anche le indicazioni ACN applicabili. La guida qui proposta riguarda soprattutto la preparazione del progetto software e delle evidenze operative.
Non usare una scadenza letta in un articolo come calendario universale. Individuazione del soggetto, comunicazioni e atti attuativi possono incidere sugli adempimenti applicabili. Conserva la fonte di ogni termine nel piano aziendale, con un responsabile del suo aggiornamento.
Perché un cliente chiede informazioni sulla sicurezza
L’articolo 24 del decreto include la sicurezza della catena di approvvigionamento e considera anche pratiche e vulnerabilità dei fornitori diretti. Questo spiega perché un’impresa coinvolta in una filiera possa ricevere domande su accessi, sviluppo, assistenza e continuità del servizio.
Per ogni richiesta distingui base normativa, clausola contrattuale e buona pratica proposta dal cliente. Se un questionario chiede una capacità che non esiste, non rispondere positivamente soltanto perché è prevista nel piano futuro. Indica stato effettivo, eventuale attività in corso e limiti del servizio fornito.
Chiarisci anche quali sistemi siano nel perimetro della fornitura. L’accesso occasionale a un portale, la gestione continuativa di un’infrastruttura e lo sviluppo di un modulo non comportano le stesse responsabilità operative.
Preparare un inventario utile al progetto
Raccogli applicazioni, archivi, integrazioni e soggetti che li gestiscono. Per ogni componente indica funzione, dati trattati, utenti, dipendenze e referente. L’inventario deve permettere di capire quale servizio si ferma se un componente non è disponibile.
| Elemento | Domanda pratica | Evidenza da preparare |
|---|---|---|
| Account | Chi accede e con quale ruolo? | Elenco e procedura di revisione |
| Integrazioni | Quali dati e credenziali vengono scambiati? | Mappa dei collegamenti |
| Backup | Cosa si può recuperare e come? | Esito di una prova di ripristino |
| Manutenzione | Chi gestisce problemi e aggiornamenti? | Responsabilità e procedura operativa |
| Incidenti | Chi riceve una segnalazione? | Contatti e percorso di escalation |
Non occorre iniziare da un documento enorme. Serve una rappresentazione abbastanza precisa da assegnare le attività e abbastanza semplice da poter essere mantenuta quando il sistema cambia.
Tradurre il bisogno in requisiti del software
Per un nuovo gestionale specifica ruoli, operazioni consentite e modalità di revoca degli accessi. Chiedi come vengono gestiti account amministrativi, credenziali dei collegamenti e accessi del fornitore durante l’assistenza.
Definisci quali eventi devono essere registrati per ricostruire un problema: accessi amministrativi, modifiche ai permessi o esportazioni rilevanti possono richiedere trattamenti diversi. Evita di raccogliere ogni dato senza una finalità; stabilisci consultazione, protezione e conservazione dei registri.
Per le integrazioni tra CRM e gestionale, chiedi come si riconosce un errore, chi può ripetere un invio e cosa accade alle operazioni già completate. La disponibilità di un connettore non risponde automaticamente a queste domande.
Ripristino e continuità: fare una prova completa
Un backup disponibile non dimostra che l’azienda possa riprendere il lavoro nel tempo necessario. Concorda un caso di prova: recuperare una versione dei dati, riattivare i collegamenti e verificare che le persone autorizzate possano operare.
Misura quanto dura la prova e quali informazioni restano da ricostruire. Se il sistema dipende da documenti archiviati altrove, includili nel test. Recuperare il database senza gli allegati o senza le credenziali necessarie può lasciare il processo incompleto.
Definisci un modo temporaneo di lavorare durante l’interruzione e il successivo recupero dei dati. Un foglio d’emergenza deve avere regole di compilazione e riconciliazione; altrimenti il ritorno al sistema produce duplicazioni e pratiche non allineate.
Chiarire il rapporto con il fornitore
Nel contratto o nella documentazione di servizio indica chi monitora, chi interviene, come si segnala un problema e quali informazioni vengono fornite al cliente. Distingui tempi di presa in carico da tempi di risoluzione: sono impegni differenti.
Chiedi come vengono gestite vulnerabilità, dipendenze e rilasci urgenti. Se l’assistenza è affidata a più soggetti, individua il punto di coordinamento. Il cliente non dovrebbe dover scoprire durante un guasto chi possiede l’accesso necessario.
Nessuna singola funzione o etichetta commerciale prova da sola la conformità dell’intera impresa. Un software può sostenere controlli e produrre evidenze; organizzazione, contratti e procedure richiedono una valutazione propria.
Un piano di lavoro verificabile
Come esempio organizzativo, una PMI che riceve un questionario da un cliente può iniziare collegando ogni risposta a un’evidenza esistente. Le risposte senza prova diventano attività da valutare, con responsabile, priorità e criterio di completamento.
Separare le attività aiuta a evitare un generico progetto “NIS2” senza risultati osservabili. Una prova di ripristino riuscita, un inventario verificato e una procedura di revoca collaudata sono risultati più leggibili di una percentuale di avanzamento non definita.
Se il lavoro include cloud e nuovi servizi, confronta il perimetro con la guida al voucher cloud e cybersecurity, senza assumere che ogni misura di sicurezza sia finanziabile. L’ammissibilità delle spese richiede una verifica distinta.
Domande frequenti
Essere fornitore di un soggetto NIS rende automaticamente soggetti NIS?
Non si può concluderlo dal solo rapporto commerciale. Occorre verificare l’ambito del decreto e le eventuali condizioni particolari applicabili. Restano da considerare le richieste contrattuali del cliente.
Un gestionale nuovo basta per adeguarsi?
No. Può supportare accessi, tracciamento e procedure, ma non sostituisce analisi del rischio, responsabilità e organizzazione. I requisiti vanno definiti nel perimetro effettivo dell’impresa.
Cosa chiedere a Melcode?
Una valutazione tecnica di dati, accessi, integrazioni e gestione del sistema. Nella consulenza software possiamo definire controlli ed evidenze del progetto, da coordinare con chi segue l’inquadramento normativo e la sicurezza aziendale.