Contratto con un fornitore IT dopo NIS2: clausole di sicurezza, SLA e notifica degli incidenti

Un contratto con un fornitore IT nell’ambito NIS2 non dovrebbe limitarsi a una dichiarazione di conformità, a una clausola di sicurezza generica e a un indicatore mensile di disponibilità. Deve tradurre i rischi associati al servizio in una chiara ripartizione delle responsabilità, livelli di servizio misurabili, un flusso tempestivo di informazioni sugli incidenti, accesso alle evidenze e un piano di uscita concretamente attuabile. Il punto di partenza è la criticità del servizio e l’effettiva ripartizione dei controlli tra le parti. Solo su questa base è possibile stabilire quali misure di sicurezza, tempistiche, diritti di verifica e obblighi di notifica inserire nel contratto.

Il contratto come strumento di controllo del rischio

La revisione dei contratti non dovrebbe partire da un modello predefinito di clausola di sicurezza, ma dalla mappatura delle dipendenze dell’organizzazione dai fornitori. Per ciascun fornitore occorre identificare servizi, processi, sistemi, dati e sedi interessati, valutando poi le conseguenze di un’indisponibilità o di una violazione della sicurezza. La priorità va alle dipendenze la cui interruzione potrebbe fermare le attività, compromettere l’adempimento degli obblighi o ostacolare la gestione di un incidente. Non tutti i servizi IT richiedono quindi le stesse garanzie contrattuali.

La classificazione della criticità di un fornitore dovrebbe derivare dall’analisi dell’impatto sul business e dalla valutazione del rischio, non soltanto dal valore economico del contratto. Richiedono particolare attenzione i servizi per i quali l’impresa resta responsabile della continuità e della gestione degli incidenti, mentre il fornitore controlla informazioni tecniche, log, backup o ambienti necessari al ripristino. L’organizzazione deve inoltre nominare un responsabile del rischio associato al fornitore. In assenza di questo ruolo, le responsabilità tra acquisti, IT, sicurezza e process owner rimangono frammentate.

Il contenuto contrattuale va progettato partendo dagli scenari di disservizio: indisponibilità del servizio, attacco, perdita o danneggiamento dei dati, indisponibilità del personale del fornitore, interruzione della catena dei subfornitori e cessazione del rapporto. Per ogni scenario occorre definire le azioni delle parti, le responsabilità, i flussi informativi e le condizioni di ripristino. Da queste decisioni derivano i livelli di disponibilità, i tempi di risposta e ripristino, la documentazione richiesta e i diritti di verifica.

Una dichiarazione di elevata disponibilità non chiarisce per quanto tempo possa rimanere indisponibile un sistema di controllo della produzione, da quale momento decorra il fermo né chi debba fornire i dati necessari alla valutazione dell’incidente. Non garantisce neppure l’accesso alle copie dei log, alle informazioni sui subfornitori o ai dati necessari per trasferire il servizio in sicurezza. Queste lacune emergono solitamente durante un’interruzione, quando la ripartizione delle responsabilità non può più restare implicita.

Il richiamo alla NIS2 o ai requisiti KSC applicabili dovrebbe completare l’analisi dei rischi e delle responsabilità, non sostituire il contenuto operativo del contratto. Un quadro gestionale più ampio è presentato nell’approfondimento NIS2 per le imprese manifatturiere: soggetti interessati, obblighi e preparazione dell’organizzazione senza ridurre il tema alla sola funzione IT. Le modifiche contrattuali devono essere definite di volta in volta in base al ruolo dell’organizzazione, alla criticità del servizio e all’effettiva ripartizione dei controlli tra le parti.

Perimetro del servizio e responsabilità

La ripartizione dei compiti va descritta in un allegato tecnico, non lasciata nella definizione generale dell’oggetto contrattuale. L’allegato dovrebbe identificare asset e ambienti coperti, tipologie di dati, luoghi di trattamento e di erogazione, interfacce, orari di assistenza ed esclusioni. Senza queste informazioni non è possibile stabilire con precisione dove termini la responsabilità del fornitore, quale evento faccia decorrere la misurazione dello SLA e chi debba proteggere gli elementi di interfaccia tra i sistemi.

È opportuno descrivere le misure di sicurezza indicando il risultato atteso, la parte responsabile e l’evidenza di attuazione, lasciando i dettagli tecnologici alla documentazione tecnica sottoposta a controllo. In questo modo si riduce il rischio che il contratto diventi rapidamente obsoleto. Il catalogo standard dei controlli del fornitore può essere accettato solo dopo averlo confrontato con i rischi specifici del servizio e aver colmato le lacune riscontrate. La matrice delle responsabilità dovrebbe distinguere il titolare del controllo, chi lo attua e il soggetto autorizzato ad approvare eventuali deroghe.

Se l’ambiente è amministrato dal fornitore, il contratto dovrebbe disciplinare anche gli accessi privilegiati: segregazione dei compiti, modalità di autenticazione, registrazione delle attività amministrative e revoca tempestiva delle autorizzazioni in caso di cambio di ruolo o cessazione del rapporto. Una semplice dichiarazione sull’esecuzione dei backup non è sufficiente se il cliente non sa chi li cifra, dove vengono conservati, chi può ripristinarli e quale documento attesti l’esito delle prove di ripristino.

Il fornitore dovrebbe mantenere aggiornato l’elenco dei subfornitori che incidono sul servizio, con la descrizione dei rispettivi ruoli e delle ubicazioni del trattamento, imponendo loro requisiti non meno rigorosi di quelli concordati con il cliente. Il contratto deve distinguere le modifiche soggette ad approvazione preventiva da quelle che richiedono soltanto una comunicazione e una nuova valutazione del rischio. La certificazione di un sistema di gestione può supportare questa valutazione, ma non sostituisce le responsabilità definite per il singolo servizio. Il rapporto è approfondito nel contributo NIS2 e UNI EN ISO 27001: cosa offre la certificazione e cosa manca ancora per la conformità al KSC.

Clausole di sicurezza verificabili

Una clausola di sicurezza diventa verificabile soltanto quando definisce il risultato atteso, il campo di applicazione, la frequenza dell’attività, le modalità di attestazione e il processo di gestione delle deroghe. Espressioni quali “in conformità alle migliori prassi” o “con la dovuta diligenza” possono integrare i requisiti, ma non consentono di stabilire se il fornitore abbia adempiuto correttamente. Per ciascun controllo occorre indicare il titolare del requisito, il periodo di conservazione delle evidenze e la parte autorizzata ad accettare un’eccezione.

I requisiti così formulati dovrebbero coprire almeno la gestione delle vulnerabilità e degli aggiornamenti, il mantenimento di configurazioni sicure, la cifratura, la protezione e conservazione dei log, l’esecuzione dei backup, le prove di ripristino, la gestione delle modifiche e il controllo degli accessi. La frequenza dei riesami delle autorizzazioni, delle prove di ripristino e della reportistica, così come i tempi di rimozione delle vulnerabilità, va determinata in base alla valutazione del rischio del servizio. Non dovrebbe essere uniforme per tutti i fornitori.

Ogni deroga deve essere registrata insieme alla relativa motivazione, alla scadenza, al responsabile del rischio e alle misure compensative. L’approvazione richiede una valutazione della loro effettiva capacità di ridurre il rischio al livello accettato dall’organizzazione.

Una clausola che preveda backup periodici resta incompleta se non identifica dati e sistemi coperti, durata della conservazione, protezione da modifica o cancellazione, regole di accesso e frequenza delle prove di ripristino. Dovrebbe inoltre stabilire come il fornitore segnala un backup o una prova non riusciti, chi approva le azioni correttive e quale rapporto ne documenta la chiusura. Analogamente, l’obbligo di rimediare alle vulnerabilità richiede criteri di classificazione, tempi di intervento commisurati al rischio, regole per il rinvio degli aggiornamenti e documentazione delle protezioni temporanee.

Le evidenze vanno suddivise tra quelle trasmesse periodicamente e quelle rese disponibili su richiesta. Nel primo gruppo possono rientrare riepiloghi delle vulnerabilità, rapporti sugli aggiornamenti, risultati delle prove di ripristino e attestazioni dei riesami degli accessi. Dopo un incidente, una modifica rilevante o il rilievo di una deviazione possono essere necessari risultati dettagliati delle prove, log, cronologia delle modifiche, registro delle eccezioni e piano delle azioni correttive. Ambito, titolari e tempi di conservazione di questi materiali dovrebbero essere collegati ai principi illustrati nell’approfondimento Documentazione NIS2 e KSC prima di un controllo: politiche, registri ed evidenze realmente necessari.

Il diritto di verifica dovrebbe essere graduato e concretamente esercitabile anche nei confronti di un cloud provider. Un primo livello può comprendere l’esame documentale e una riunione di approfondimento; il livello successivo, rapporti indipendenti o test concordati. L’audit in sede può essere riservato a situazioni di rischio elevato, incidenti rilevanti o assenza di evidenze affidabili. Il contratto dovrebbe disciplinare tempistiche, riservatezza, perimetro tecnico e gestione dei rilievi, senza attribuire al cliente diritti impossibili da esercitare in un ambiente condiviso.

SLA per la resilienza, non soltanto per la disponibilità

Lo SLA dovrebbe derivare dall’analisi dell’impatto sul business, non dal catalogo standard del fornitore. Il process owner deve prima definire la durata massima tollerabile dell’interruzione, la perdita di dati accettabile e gli effetti dell’indisponibilità su produzione, assistenza ai clienti, rendicontazione e obblighi di legge. Da queste valutazioni si ricavano gli obiettivi di ripristino, i requisiti per un servizio alternativo e per le modalità di emergenza, nonché le priorità delle segnalazioni. Un indicatore mensile di disponibilità non chiarisce se un singolo guasto, verificatosi in un momento critico, possa interrompere il processo oltre il limite accettabile per l’organizzazione.

Oltre alla disponibilità, il contratto dovrebbe specificare i tempi per la presa in carico della segnalazione, l’avvio della diagnosi, il ripristino della funzionalità e la rimozione della causa, nonché la frequenza degli aggiornamenti, i livelli di escalation e le modalità operative fuori dall’orario ordinario. Il tempo di risposta non coincide con il tempo di ripristino e l’attivazione di una soluzione temporanea non equivale alla piena risoluzione del problema. Distinguere questi concetti consente al team operativo di sapere quando potrà riprendere il lavoro e al service owner di verificare quando il fornitore avrà concluso l’analisi delle cause e introdotto un’azione correttiva permanente.

Per un sistema di controllo di un processo produttivo, un incidente critico può richiedere un’escalation immediata e comunicazioni continue fino all’attivazione della modalità di emergenza. Lo stesso guasto in un ambiente formativo può essere classificato con una priorità inferiore. La classificazione deve quindi basarsi sull’impatto operativo, non soltanto sulla descrizione tecnica dell’anomalia. Se l’organizzazione dispone di dati storici affidabili, nella definizione delle soglie dovrebbe considerare i tempi effettivi di risposta e ripristino, i livelli di disponibilità raggiunti e il numero di guasti ricorrenti.

Il meccanismo di misurazione dovrebbe indicare la fonte dei dati, il fuso orario, il momento di avvio e arresto del conteggio, gli orari concordati di erogazione, le finestre di manutenzione e le regole per modificare la classificazione dell’incidente. Le esclusioni dal calcolo devono formare un elenco chiuso e verificabile. Non possono comprendere eventi che ricadono nella responsabilità del fornitore. La coerenza tra queste disposizioni e l’effettiva preparazione operativa può essere valutata nell’ambito di un audit NIS2 in un’impresa manifatturiera: come verificare se l’organizzazione è pronta per i nuovi obblighi.

I service credit e gli indennizzi simbolici non ripristinano il processo né riducono gli effetti di un fermo. Sono più rilevanti l’obbligo di presentare un piano di rimedio, l’escalation al management, ulteriori prove di resilienza e il diritto di risolvere il contratto in caso di mancato rispetto persistente o ripetuto dei livelli concordati. Una penale economica può rafforzare l’accountability, ma non sostituisce il meccanismo di ripristino del servizio, rimozione delle cause e prevenzione delle recidive.

Incidenti e obblighi di notifica

Il contratto dovrebbe obbligare il fornitore a segnalare senza ritardo ogni evento che possa incidere sul servizio, sui dati, sulla continuità operativa o sulla sicurezza del cliente. La prima comunicazione non dovrebbe dipendere dalla conferma completa della causa, dell’entità del danno o della qualificazione giuridica dell’evento. Il termine contrattuale va definito con un margine che consenta al cliente di effettuare la propria valutazione e rispettare gli eventuali termini esterni. Deve derivare dalla criticità del servizio e dalla disponibilità di un punto di contatto operativo 24 ore su 24, non dalla comodità organizzativa delle parti.

Il flusso informativo va articolato in primo allarme, aggiornamenti sullo stato, rapporto successivo all’evento e analisi delle cause radice. Per ogni fase occorre stabilire contenuti, canale autorizzato, destinatari, frequenza degli aggiornamenti e regole di escalation in caso di mancato contatto. La prima comunicazione dovrebbe includere almeno l’ora di rilevazione, gli asset e i servizi interessati, l’impatto previsto, le azioni intraprese, gli indicatori tecnici disponibili, la valutazione del rischio di ulteriore propagazione e l’orario del successivo aggiornamento. L’elenco dei contatti deve comprendere i sostituti ed essere verificato periodicamente, anche al di fuori dell’orario ordinario.

Se il fornitore rileva traffico anomalo nell’ambiente che ospita un’applicazione critica, dovrebbe avvertire il cliente prima di stabilire se si sia verificata una violazione. Il cliente attiva il proprio processo di gestione degli incidenti, nomina il responsabile delle decisioni, coinvolge il team di risposta e, quando appropriato, anche l’assicuratore, definendo inoltre chi approva le notifiche esterne e le comunicazioni ai clienti. Il fornitore preserva i log e le tracce tecniche concordate e supporta l’analisi, il contenimento e la determinazione del perimetro dell’evento, senza assumere la responsabilità regolamentare del cliente.

Le clausole dovrebbero inoltre disciplinare la conservazione e la messa a disposizione delle evidenze, la tutela della loro integrità, la documentazione delle decisioni e la preparazione dei dati necessari alle notifiche e alla successiva analisi delle cause radice. Termini, destinatari e contenuti delle comunicazioni esterne devono essere verificati di volta in volta alla luce della normativa vigente, dello status dell’organizzazione e della tipologia di evento. I registri delle notifiche, delle decisioni, delle escalation e delle azioni dovrebbero essere collegati all’approfondimento Documentazione NIS2 e KSC prima di un controllo: politiche, registri ed evidenze realmente necessari; il piano temporale di adeguamento va invece coordinato con il contributo Attuazione della NIS2 dopo l’iscrizione nell’elenco KSC: piano di intervento entro il 3 aprile 2027.

Attuazione, monitoraggio e uscita sicura

La firma di un addendum non conclude il processo di gestione del fornitore. Il contract owner dovrebbe effettuare riesami periodici dei risultati SLA, degli incidenti, delle deroghe, delle azioni correttive, dei cambiamenti nella catena dei subfornitori e dell’aggiornamento delle evidenze che attestano il rispetto dei requisiti. Il monitoraggio deve poggiare su un registro dei contratti che includa almeno la data di rinnovo, il responsabile, la criticità del servizio e lo stato di definizione delle misure di sicurezza. Una dichiarazione di conformità non sostituisce rapporti, risultati delle prove e registrazioni che dimostrino l’effettivo adempimento degli obblighi.

Prima del rinnovo del contratto o di una modifica sostanziale del servizio, occorre rivalutarne la criticità, le dipendenze tecniche e di processo, la concentrazione dei servizi presso un unico fornitore, l’attuabilità delle misure di sicurezza e la possibilità di migrare verso una soluzione alternativa. Il riesame consente di stabilire se sia sufficiente un addendum o se serva una nuova procedura di acquisto. Se un fornitore strategico rifiuta un audit o una modifica delle condizioni, l’organizzazione dovrebbe documentare la lacuna e scegliere tra l’introduzione di una misura compensativa, l’accettazione formale del rischio residuo o la sostituzione del fornitore.

Il piano di uscita deve risultare attuabile prima ancora della risoluzione del contratto. Dovrebbe comprendere la restituzione e il trasferimento dei dati in un formato utilizzabile, l’assistenza alla migrazione, la continuità durante il periodo transitorio, la revoca degli accessi, la cancellazione delle copie e la conferma dell’avvenuta esecuzione. Parallelamente vanno conservate le registrazioni richieste per finalità legali, probatorie e di audit. Una verifica pratica consiste nel provare il ripristino dei dati presso un altro fornitore, controllandone completezza, tempi di migrazione e possibilità di disattivare gli account precedenti.

L’aggiornamento del portafoglio contratti dovrebbe partire dai servizi con il maggiore impatto sull’operatività, classificando le lacune in base a conseguenze e urgenza. L’efficacia dei meccanismi adottati dovrebbe essere verificata mediante un’esercitazione di gestione degli incidenti e un audit a campione delle evidenze. I risultati dei riesami degli SLA, degli incidenti, delle deroghe, delle azioni correttive e delle prove di uscita mostreranno se i requisiti funzionano nella pratica o rimangono soltanto disposizioni contrattuali.

Il perimetro della valutazione può essere collegato all’approfondimento Audit NIS2 in un’impresa manifatturiera: come verificare se l’organizzazione è pronta per i nuovi obblighi. Gli obblighi dell’organizzazione vanno inoltre determinati tenendo conto del suo status, esaminato nel contributo Direttiva NIS2: a chi si applica e quali imprese devono soddisfare i nuovi requisiti?