L’evoluzione del quadro normativo europeo in materia di cybersecurity sta producendo effetti profondi non solo sulle misure tecniche e organizzative richieste alle imprese, ma anche sulla funzione stessa della contrattualistica ICT. La Direttiva (UE) 2022/2555 (NIS2), come attuata in Italia dal D.Lgs. 4 settembre 2024, n. 138, non si limita infatti a introdurre nuovi obblighi di sicurezza, ma impone un cambiamento strutturale nel modo in cui le organizzazioni devono concepire e governare le proprie interdipendenze tecnologiche. In un ecosistema digitale caratterizzato da un’elevata esternalizzazione di servizi, infrastrutture e processi critici, il perimetro della sicurezza non coincide più con i confini organizzativi dell’impresa, ma si estende lungo l’intera catena di fornitura.
In tale contesto, la contrattualistica ICT non può più essere interpretata come uno strumento accessorio o meramente difensivo, finalizzato a disciplinare rapporti commerciali o a trasferire il rischio su soggetti terzi. Al contrario, essa assume una funzione sempre più centrale nella costruzione dell’architettura di sicurezza dell’organizzazione, diventando il luogo in cui si definiscono, si formalizzano e – soprattutto – si rendono esigibili le misure di protezione dei sistemi e dei dati. La NIS2, attraverso l’enfasi posta sulla gestione del rischio e sulla sicurezza della supply chain, richiede infatti che il rapporto con i fornitori sia governato non solo in termini giuridici, ma anche in termini operativi e sostanziali.
È proprio questa trasformazione a determinare una progressiva ridefinizione del ruolo delle clausole contrattuali, e in particolare di quelle a contenuto sanzionatorio. Se nel modello tradizionale la funzione principale del contratto era quella di allocare responsabilità e disciplinare le conseguenze dell’inadempimento, nel nuovo contesto regolatorio il contratto diventa uno strumento di governo attivo del rischio. In tale prospettiva, anche istituti apparentemente consolidati e “statici”, come la clausola penale, sono chiamati a svolgere una funzione diversa e più sofisticata, contribuendo non solo a reagire all’inadempimento, ma a prevenirlo, incidendo direttamente sui comportamenti dei fornitori e sulla loro capacità di rispettare gli standard di sicurezza richiesti.
Indice degli argomenti
Il limite della contrattualizzazione tradizionale
La prassi consolidata nella gestione dei fornitori ICT – fortemente influenzata dall’art. 28 del Regolamento (UE) 2016/679 – ha storicamente privilegiato un approccio centrato sulla formalizzazione degli obblighi, fondato sull’idea che la corretta strutturazione del vincolo contrattuale fosse di per sé idonea a governare il rischio derivante dall’esternalizzazione. Il Data Processing Agreement è divenuto, in questo contesto, il fulcro della relazione tra titolare e fornitore, assumendo la funzione di strumento principale attraverso cui trasporre nel rapporto giuridico le prescrizioni normative in materia di sicurezza, riservatezza, controllo e responsabilità.
Tale modello ha prodotto, nel tempo, una standardizzazione significativa delle clausole contrattuali, spesso costruite secondo logiche replicabili e uniformi, indipendenti dalla reale criticità del servizio erogato o dal ruolo del fornitore all’interno dell’architettura tecnologica dell’organizzazione. Il risultato è stato un sistema nel quale la conformità è stata frequentemente interpretata come coincidenza tra obbligo normativo e previsione contrattuale, generando una sostanziale sovrapposizione tra “compliance documentale” e “compliance sostanziale”.
È proprio in questa sovrapposizione che si annida il limite strutturale dell’approccio tradizionale. L’art. 28 GDPR richiede al titolare di selezionare responsabili che offrano “garanzie sufficienti” e di disciplinare il rapporto mediante un atto giuridico vincolante. Tuttavia, la norma non si esaurisce nella formalizzazione del rapporto, ma implica una responsabilità più ampia, che attiene alla capacità effettiva di verificare, mantenere e, se necessario, correggere il comportamento del fornitore nel tempo. La trasformazione della disposizione in un mero esercizio di drafting contrattuale ha progressivamente indebolito tale dimensione sostanziale.
In concreto, il modello dominante ha privilegiato strumenti di controllo prevalentemente statici: due diligence iniziali basate su questionari, autocertificazioni, audit sporadici e, soprattutto, dichiarazioni contrattuali di conformità. Tali strumenti, pur utili, presentano un limite evidente: operano prevalentemente ex ante o ex post, senza incidere in modo significativo sul comportamento operativo quotidiano del fornitore. Il contratto, in questa configurazione, diventa un documento che “descrive” un livello di sicurezza atteso, ma non necessariamente uno strumento che lo rende effettivo.
Questo scollamento tra previsione e attuazione assume particolare rilevanza nel contesto attuale, caratterizzato da una crescente complessità della supply chain digitale. I fornitori ICT non si limitano più a eseguire attività marginali o facilmente isolabili, ma intervengono su componenti critiche dell’infrastruttura tecnologica: gestione di ambienti cloud, amministrazione di sistemi, sviluppo e manutenzione di software, gestione di servizi essenziali per la continuità operativa. In tali condizioni, il rischio non è più confinato all’interno dell’organizzazione, ma si distribuisce lungo una rete di interdipendenze difficilmente governabili attraverso strumenti puramente formali.
È in questo scenario che la Direttiva (UE) 2022/2555 e il D.Lgs. 138/2024 introducono una discontinuità radicale. L’obbligo di gestione del rischio non è più inteso come un’attività episodica o documentale, ma come un processo continuo, che include espressamente la sicurezza della supply chain. Le organizzazioni sono chiamate non solo a selezionare fornitori adeguati, ma a dimostrare una capacità persistente di controllo, valutazione e intervento rispetto alle loro prestazioni in termini di sicurezza.
Ciò comporta un mutamento profondo nella funzione del contratto. Non è più sufficiente che esso contenga obblighi di sicurezza formalmente corretti; è necessario che sia strutturato in modo tale da rendere tali obblighi effettivamente esigibili, verificabili e, soprattutto, coercibili. In assenza di meccanismi che incidano sul comportamento del fornitore, il contratto rischia di rimanere una rappresentazione ideale della sicurezza, priva di reale capacità trasformativa.
Il limite della contrattualizzazione tradizionale, dunque, non risiede nella sua esistenza, ma nella sua incompletezza. Il contratto continua a essere uno strumento necessario, ma non più sufficiente. Esso deve essere integrato all’interno di un sistema più ampio di gestione del rischio, capace di combinare previsione normativa, controllo operativo e meccanismi di enforcement.
È proprio in questo spazio che si colloca la necessità di ripensare il ruolo delle clausole contrattuali, e in particolare di quelle sanzionatorie. Se il problema fondamentale è il divario tra obbligo previsto e comportamento effettivo, allora la questione centrale diventa individuare strumenti giuridici in grado di colmare tale divario. Le clausole penali, tradizionalmente relegate a una funzione risarcitoria o deterrente di carattere generale, possono essere reinterpretate proprio in questa chiave: non più come rimedio all’inadempimento, ma come leva per prevenirlo.
In questo senso, il superamento del modello tradizionale non implica l’abbandono della contrattualizzazione, ma la sua evoluzione verso una forma più sofisticata, nella quale il contratto non si limita a “dire” cosa deve essere fatto, ma contribuisce attivamente a creare le condizioni affinché ciò avvenga.
Dalla previsione all’enforcement
Il passaggio più significativo imposto dal nuovo quadro normativo europeo in materia di cybersecurity non riguarda soltanto l’ampliamento del catalogo degli obblighi a carico delle organizzazioni, ma la trasformazione della loro natura. La Direttiva (UE) 2022/2555 e, in Italia, il D.Lgs. 4 settembre 2024, n. 138, non chiedono semplicemente alle imprese di prevedere misure di sicurezza, di inserirle in documenti interni o di richiamarle nei contratti con i fornitori. Chiedono, in modo molto più radicale, che tali misure siano effettivamente governate, applicate, monitorate, aggiornate e rese dimostrabili. La differenza è sostanziale: la compliance non si misura più soltanto sulla presenza di un obbligo scritto, ma sulla capacità dell’organizzazione di trasformare tale obbligo in comportamento operativo stabile.
È proprio qui che si colloca il vero punto di frizione tra la contrattualistica ICT tradizionale e il nuovo paradigma NIS2. Nel modello tradizionale, la clausola contrattuale ha spesso avuto una funzione prevalentemente dichiarativa: il fornitore si impegna a rispettare determinati standard, a garantire livelli di servizio, a implementare misure di sicurezza, a cooperare in caso di incidente, a comunicare tempestivamente eventuali violazioni, a consentire audit o verifiche. Tale architettura è, in astratto, corretta. Tuttavia, essa resta incompleta se non è accompagnata da strumenti che rendano l’obbligo effettivamente esigibile e che creino una pressione concreta al rispetto della prestazione promessa.
Il problema, quindi, non è la mancanza di obblighi contrattuali. Al contrario, nei contratti ICT moderni gli obblighi sono spesso numerosi, articolati e formalmente sofisticati. Il problema è la loro capacità di incidere realmente sul comportamento del fornitore. Una clausola che impone l’adozione di misure di sicurezza, ma che non prevede conseguenze proporzionate e immediate in caso di inadempimento, rischia di rimanere confinata nella dimensione del dover essere. Essa descrive un assetto ideale, ma non necessariamente determina un assetto effettivo. La sicurezza, tuttavia, non si realizza nella dichiarazione dell’obbligo, bensì nella sua esecuzione.
Il nuovo scenario regolatorio rende questa distinzione decisiva. La NIS2, nella sua logica di fondo, non consente più di trattare la sicurezza della supply chain come una questione di pura allocazione del rischio. Non è sufficiente stabilire contrattualmente che il fornitore sia responsabile per l’inosservanza di determinati obblighi, se l’organizzazione non dimostra di aver strutturato un sistema idoneo a prevenire, rilevare e gestire tale inosservanza. La responsabilità non viene eliminata dal fatto che il contratto contenga una clausola ben scritta. La responsabilità si governa solo se il contratto è inserito in un sistema di controllo effettivo.
In questo senso, il passaggio dalla previsione all’enforcement rappresenta una trasformazione concettuale profonda. La previsione contrattuale appartiene alla dimensione della normazione privata: stabilisce cosa deve essere fatto. L’enforcement appartiene invece alla dimensione dell’effettività: determina cosa accade se ciò che deve essere fatto non viene fatto. Nel diritto della cybersecurity, questa seconda dimensione diventa centrale, perché la sicurezza dipende da comportamenti continuativi, non da dichiarazioni istantanee. Un fornitore può firmare clausole molto rigorose e, nondimeno, non mantenere nel tempo un livello adeguato di patch management, logging, segregazione degli accessi, hardening dei sistemi, gestione delle vulnerabilità o risposta agli incidenti. La firma del contratto non garantisce il mantenimento della postura di sicurezza.
È in questo spazio che le clausole penali assumono un ruolo diverso da quello tradizionalmente loro riconosciuto. Nel diritto civile, la clausola penale è normalmente letta come uno strumento di predeterminazione delle conseguenze economiche dell’inadempimento o del ritardo, con funzione risarcitoria, liquidatoria e, in parte, deterrente. Nel contesto dei contratti ICT soggetti a obblighi di sicurezza rafforzati, tale funzione non scompare, ma si arricchisce di una dimensione regolatoria. La penale diventa un meccanismo attraverso il quale l’organizzazione rende più effettiva la propria governance della supply chain, introducendo nel rapporto contrattuale un incentivo economico al rispetto delle misure di sicurezza.
Questa funzione è particolarmente importante perché molti obblighi di sicurezza non sono facilmente riducibili a una logica risarcitoria tradizionale. Il danno derivante da una vulnerabilità non sanata, da un ritardo nella comunicazione di un incidente, da un mancato aggiornamento di sicurezza o da una carenza nei controlli sugli accessi può essere difficile da quantificare ex post. Può manifestarsi sotto forma di interruzione del servizio, perdita di disponibilità, esposizione di dati personali, obblighi di notifica, danno reputazionale, costi di remediation, perdita di fiducia da parte degli utenti o contestazioni da parte delle autorità. In molti casi, il problema non è solo compensare un danno già verificatosi, ma evitare che l’inadempimento produca effetti sistemici.
La clausola penale, se costruita correttamente, interviene proprio su questo piano. Essa anticipa la rilevanza economica dell’inadempimento e rende il mancato rispetto di determinati obblighi un evento immediatamente significativo per il fornitore. In questo modo, contribuisce a spostare l’attenzione dal danno finale alla violazione del presidio. Non occorre attendere che si verifichi un incidente grave per attribuire rilevanza alla mancata osservanza di una misura di sicurezza essenziale; il mancato rispetto della misura può essere, di per sé, sanzionato contrattualmente. Questa impostazione è perfettamente coerente con la logica preventiva della NIS2, che non mira soltanto a reagire agli incidenti, ma a ridurne probabilità e impatto.
Ciò significa che la penale può diventare uno strumento di prevenzione regolatoria. Essa non serve solo a punire il fornitore dopo un evento dannoso, ma a costruire un ambiente contrattuale nel quale il fornitore abbia un interesse concreto e continuativo a rispettare gli obblighi di sicurezza. Se il ritardo nella notifica di un incidente comporta una penale significativa, il fornitore sarà incentivato a dotarsi di processi interni idonei a rilevare e comunicare tempestivamente gli eventi rilevanti. Se il mancato rispetto degli SLA di continuità o ripristino comporta conseguenze economiche definite, il fornitore sarà incentivato a rafforzare le proprie capacità operative. Se la mancata chiusura di vulnerabilità critiche entro termini stabiliti genera una penale, il fornitore sarà spinto a strutturare processi di vulnerability management più maturi.
Questa impostazione consente di superare uno dei limiti più ricorrenti dei contratti ICT: la distanza tra obblighi formalmente severi e assenza di conseguenze realmente operative. Molti contratti prevedono obblighi molto ampi, ma rinviano la tutela del cliente a rimedi generali, spesso complessi, costosi o difficili da azionare. La penale riduce tale distanza perché rende l’inadempimento misurabile, contestabile e immediatamente rilevante. Essa non sostituisce gli altri rimedi contrattuali, ma introduce una soglia di effettività che rafforza l’intero sistema.
Naturalmente, questa funzione regolatoria della penale richiede una progettazione attenta. Una penale generica, sproporzionata o non collegata a obblighi specifici rischia di essere inefficace, contestabile o addirittura controproducente. Per assumere una funzione di enforcement della sicurezza, la clausola penale deve essere collegata a obblighi chiari, verificabili e coerenti con il profilo di rischio del fornitore. Deve essere possibile stabilire quando l’obbligo è stato violato, quali evidenze dimostrano la violazione, quale conseguenza economica si applica e in che modo tale conseguenza si coordina con gli altri rimedi contrattuali.
In altri termini, la penale non deve essere costruita come minaccia astratta, ma come parte di un sistema di controllo. Deve dialogare con gli SLA, con gli obblighi di reporting, con le procedure di incident response, con i diritti di audit, con i livelli di criticità dei servizi, con gli obblighi di cooperazione e con le misure di sicurezza richieste. Solo in questo modo può diventare realmente uno strumento di governance. Diversamente, resta una clausola isolata, priva di capacità sistemica.
Il punto centrale è che l’enforcement contrattuale diventa una componente della gestione del rischio. Nel momento in cui la normativa richiede all’organizzazione di governare la sicurezza della supply chain, ogni strumento idoneo a rendere effettivi gli obblighi dei fornitori assume rilevanza organizzativa. La penale, in tale prospettiva, non è più soltanto un rimedio civilistico; è una misura organizzativa che contribuisce a rendere credibile il sistema di controllo sui terzi. Non garantisce, da sola, la conformità, ma rafforza la dimostrabilità della conformità.
Questa distinzione è fondamentale anche rispetto al GDPR. L’art. 28 impone al titolare di scegliere responsabili che offrano garanzie sufficienti e di disciplinare il rapporto mediante un atto vincolante; l’art. 32 impone misure adeguate al rischio; l’art. 5, par. 2, e l’art. 24 impongono al titolare di essere in grado di dimostrare la conformità. In un simile quadro, una clausola penale calibrata sugli obblighi di sicurezza del fornitore può contribuire a dimostrare che l’organizzazione non si è limitata a ricevere dichiarazioni, ma ha costruito un sistema contrattuale volto a rendere effettive le garanzie richieste.
La stessa logica vale, con ancora maggiore intensità, nel contesto NIS2. La sicurezza della catena di fornitura non può essere dimostrata soltanto attraverso questionari o clausole standard. Deve emergere da un sistema di valutazione, contrattualizzazione, monitoraggio ed enforcement. La penale si colloca nella parte finale di questa catena: dopo aver identificato il fornitore critico, valutato il rischio, definito gli obblighi di sicurezza e stabilito i livelli di servizio, l’organizzazione deve anche prevedere cosa accade se tali obblighi non vengono rispettati. Senza questo passaggio, il sistema resta incompleto.
In definitiva, il passaggio dalla previsione all’enforcement è il punto in cui la contrattualistica ICT diventa realmente parte della cybersecurity governance. Non basta stabilire che il fornitore debba essere sicuro; occorre costruire un rapporto in cui la sicurezza sia una prestazione contrattuale effettiva, misurabile e presidiata da conseguenze. La clausola penale, se progettata con rigore e proporzionalità, consente precisamente questo: trasformare la sicurezza da obbligo dichiarato a comportamento economicamente incentivato.
È in questa trasformazione che si coglie il carattere innovativo della tesi. La penale non è semplicemente una clausola “punitiva”. È un dispositivo di effettività. È il punto in cui il contratto smette di essere una rappresentazione della compliance e diventa uno strumento della compliance. È il passaggio attraverso cui l’organizzazione dimostra di non essersi limitata a pretendere sicurezza dal fornitore, ma di aver creato un assetto giuridico ed economico idoneo a renderla più probabile, più stabile e più verificabile.
Penali e gestione del rischio nella NIS2
La funzione delle clausole penali nei contratti ICT deve essere letta, alla luce della NIS2, dentro la più ampia logica della gestione del rischio. Il punto non è semplicemente prevedere una conseguenza economica in caso di inadempimento del fornitore, ma costruire un meccanismo contrattuale coerente con la criticità del servizio, con il ruolo del fornitore nella catena di fornitura digitale e con l’impatto che un suo comportamento non conforme può produrre sulla sicurezza, sulla continuità operativa e sulla capacità dell’organizzazione di adempiere ai propri obblighi regolatori.
La Direttiva (UE) 2022/2555 e il D.Lgs. 4 settembre 2024, n. 138, infatti, non impongono un modello di sicurezza uniforme, indifferenziato e uguale per tutti i fornitori. Al contrario, l’intero impianto della NIS2 si fonda su una logica di proporzionalità, adeguatezza e gestione del rischio. Le misure tecniche, operative e organizzative devono essere calibrate rispetto all’esposizione concreta dell’organizzazione, alla natura dei servizi erogati, alla criticità dei sistemi interessati, alle dipendenze tecnologiche e all’impatto potenziale di un incidente. La stessa logica deve necessariamente riflettersi nei contratti con i fornitori ICT.
Ne deriva che la clausola penale, se vuole assumere una funzione coerente con il modello NIS2, non può essere formulata come previsione generica, standardizzata o meramente accessoria. Una penale uguale per tutti i fornitori, indipendente dal servizio prestato, dalla rilevanza del sistema coinvolto o dalla gravità dell’obbligo violato, rischia di tradire la stessa logica del risk-based approach. In un contratto con un fornitore marginale, una penale eccessivamente severa potrebbe risultare sproporzionata e difficilmente giustificabile; in un contratto con un fornitore critico, una penale simbolica potrebbe invece essere del tutto inadeguata a produrre un reale effetto deterrente.
Classificazione del fornitore e proporzionalità della penale
Il primo passaggio, quindi, è la classificazione del fornitore. Una penale di sicurezza ha senso solo se inserita in un sistema che abbia preliminarmente distinto tra fornitori ordinari, fornitori rilevanti e fornitori critici. Tale classificazione non può essere costruita sulla sola base del valore economico del contratto, poiché nel contesto cyber il valore commerciale del rapporto non coincide necessariamente con il valore di rischio. Un fornitore economicamente modesto può essere altamente critico se gestisce credenziali privilegiate, se amministra sistemi esposti, se interviene su ambienti produttivi, se fornisce un componente software essenziale o se ha accesso a dati personali su larga scala. Al contrario, un fornitore economicamente rilevante può avere un’esposizione cyber più contenuta, ove non acceda a sistemi critici o non incida sulla continuità dei servizi.
La clausola penale deve dunque essere costruita a valle di una valutazione sostanziale del ruolo del fornitore nell’ecosistema digitale dell’organizzazione. Tale valutazione dovrebbe considerare almeno tre dimensioni: l’impatto operativo di un disservizio, l’impatto sulla sicurezza dei sistemi e l’impatto sulla protezione dei dati personali. È proprio dall’incrocio tra tali dimensioni che può emergere il corretto livello di severità del meccanismo sanzionatorio contrattuale.
In questa prospettiva, la Business Impact Analysis e il Third Party Risk Assessment diventano strumenti indispensabili anche per la redazione della clausola penale. La penale non dovrebbe nascere da una scelta negoziale astratta, né da una formula riciclata da contratti precedenti, ma da una lettura documentata del rischio. Se un fornitore supporta un processo essenziale, se il suo inadempimento può determinare indisponibilità di un servizio, perdita di integrità dei dati, compromissione di sistemi rilevanti o ritardi nella gestione di un incidente, la clausola penale dovrebbe riflettere tale criticità. In altri termini, la sanzione economica deve essere proporzionata non solo all’inadempimento contrattuale in sé, ma all’impatto regolatorio e operativo che tale inadempimento può generare.
Incident reporting, continuità operativa e vulnerabilità
Il collegamento tra penale e rischio diventa particolarmente evidente con riferimento agli obblighi di incident reporting. Nel modello NIS2, la tempestività della comunicazione degli incidenti non è un profilo accessorio, ma una componente essenziale della capacità dell’organizzazione di adempiere ai propri obblighi verso l’autorità competente. Se un fornitore ritarda la comunicazione di un evento rilevante, omette informazioni essenziali o non coopera nella ricostruzione tecnica dell’incidente, l’organizzazione committente può trovarsi nell’impossibilità di rispettare le tempistiche regolatorie o di valutare correttamente la significatività dell’evento. In tale scenario, una penale collegata al ritardo, all’incompletezza o all’inesattezza della comunicazione non ha una funzione meramente punitiva: serve a presidiare un obbligo regolatorio del cliente.
Lo stesso vale per gli obblighi di continuità operativa. Se un fornitore ICT eroga un servizio necessario alla continuità di un processo critico, il mancato rispetto dei livelli di servizio o dei tempi di ripristino non rappresenta soltanto un disservizio commerciale, ma può incidere direttamente sulla resilienza dell’organizzazione. La penale, in tal caso, deve essere disegnata in modo coerente con gli SLA e con i parametri individuati tramite BIA, quali tempi massimi tollerabili di interruzione, Recovery Time Objective e Recovery Point Objective. Una penale svincolata da tali parametri sarebbe debole sul piano metodologico; una penale costruita su tali parametri diventa invece parte del sistema di continuità operativa.
Anche la gestione delle vulnerabilità rappresenta un ambito nel quale la penale può assumere una funzione regolatoria particolarmente rilevante. Nel contesto NIS2, la vulnerabilità non corretta tempestivamente non è solo un difetto tecnico: è un fattore di esposizione al rischio. Se il fornitore è responsabile dello sviluppo, della manutenzione o della gestione di una componente software o infrastrutturale, la mancata applicazione di patch critiche, la mancata comunicazione di vulnerabilità note o l’assenza di remediation entro tempi prestabiliti possono aumentare significativamente la probabilità di incidente. Una clausola penale collegata al mancato rispetto delle finestre di remediation contribuisce a rendere effettivo il processo di vulnerability management, trasformando un obbligo tecnico in un vincolo contrattuale economicamente presidiato.
La medesima logica si applica agli obblighi relativi agli accessi privilegiati. Molti incidenti di sicurezza derivano non da sofisticate compromissioni esterne, ma da debolezze nella gestione degli account amministrativi, delle credenziali, delle autorizzazioni e delle sessioni di accesso remoto. Un fornitore che accede ai sistemi del cliente con privilegi elevati rappresenta un rischio specifico, che deve essere disciplinato con particolare attenzione. In tale contesto, la penale può presidiare obblighi quali l’uso di autenticazione multifattore, la segregazione delle utenze, il divieto di condivisione delle credenziali, la registrazione delle attività amministrative, la revoca tempestiva degli accessi del personale non più autorizzato. Anche qui, la funzione della penale non è “risarcire” in senso tradizionale, ma rendere effettivo un presidio essenziale di sicurezza.
Accountability e sistema di controllo della supply chain
Il punto più interessante, tuttavia, è che la penale può contribuire a dimostrare la proporzionalità delle misure di gestione del rischio. Nel modello NIS2, l’organizzazione deve essere in grado di spiegare perché ha adottato determinate misure e perché le ha ritenute adeguate rispetto al rischio. Una clausola penale ben strutturata diventa un elemento di tale spiegazione. Essa dimostra che l’organizzazione ha identificato determinati obblighi del fornitore come rilevanti, ha compreso l’impatto della loro violazione e ha introdotto un meccanismo volto a incentivarne il rispetto. In altri termini, la penale diventa parte della narrativa di accountability.
Questo aspetto è decisivo. La compliance moderna non è più solo l’insieme delle misure adottate, ma anche la capacità di dimostrare la razionalità delle scelte compiute. Un contratto ICT che preveda obblighi di sicurezza dettagliati, ma non contenga alcun meccanismo di enforcement, può apparire incompleto, soprattutto se riferito a fornitori critici. Al contrario, un contratto che colleghi obblighi, livelli di servizio, audit, reporting e penali a una valutazione documentata del rischio mostra un livello superiore di maturità organizzativa. Non perché la penale elimini il rischio, ma perché dimostra che l’organizzazione ha tentato di governarlo attraverso strumenti giuridici coerenti con la sua intensità.
La penale, quindi, deve essere considerata come uno degli elementi del sistema di controllo della supply chain. Non è l’unico e non può essere isolato. Deve coordinarsi con la fase di selezione del fornitore, con la due diligence iniziale, con la qualificazione contrattuale, con le attività di audit, con gli obblighi di reporting, con le clausole di cooperazione, con i diritti di accesso alle evidenze, con le procedure di escalation e con le ipotesi di sospensione o risoluzione del contratto. Una penale priva di questo ecosistema rischia di essere una clausola decorativa; una penale inserita in questo ecosistema diventa un dispositivo di governance.
Occorre anche evitare un equivoco: la penale non deve essere concepita come sostitutiva della responsabilità del fornitore né come limite assoluto del danno risarcibile, salvo che tale effetto sia espressamente voluto e giuridicamente sostenibile. Nei contratti ICT ad alta criticità, la clausola penale deve essere costruita con attenzione per non produrre effetti indesiderati. Se formulata male, potrebbe diventare un tetto economico di fatto, riducendo la tutela del cliente proprio nei casi più gravi. Se formulata bene, invece, opera come conseguenza minima e immediata dell’inadempimento, fatta salva la possibilità di agire per il maggior danno o di attivare ulteriori rimedi nei casi di violazioni gravi, dolose, reiterate o incidenti su obblighi regolatori.
Questa distinzione è fondamentale per evitare che la penale, pensata come misura di sicurezza, si trasformi in una misura di indebolimento della posizione contrattuale del cliente. Nei rapporti con fornitori critici, infatti, non basta prevedere “una penale”: occorre definire il suo rapporto con il risarcimento del danno, con i limiti di responsabilità, con le esclusioni di responsabilità, con la risoluzione per inadempimento, con gli obblighi di manleva, con gli SLA e con le clausole di cooperazione in caso di incidente. La penale deve essere parte di un disegno contrattuale coerente, non un innesto isolato.
Graduazione, audit ed evidenze verificabili
Un ulteriore profilo riguarda la graduazione della penale. In un contratto ICT complesso, non tutti gli inadempimenti di sicurezza hanno la stessa gravità. Il ritardo di poche ore in una comunicazione non critica non equivale alla mancata notifica di un incidente significativo; la mancata consegna di una reportistica periodica non equivale alla mancata chiusura di una vulnerabilità critica sfruttata attivamente; il superamento occasionale di un livello di servizio non equivale all’interruzione prolungata di un servizio essenziale. La clausola penale deve quindi prevedere un sistema graduato, capace di distinguere tra violazioni lievi, rilevanti e gravi, e di collegare a ciascuna conseguenze proporzionate.
Tale graduazione è coerente con la logica della NIS2, che non tratta il rischio come una categoria binaria, ma come una grandezza da valutare e trattare in funzione della probabilità e dell’impatto. Un sistema di penali graduato consente di tradurre tale logica nel contratto. La contrattualistica, in questo modo, diventa il luogo in cui il risk assessment si trasforma in obblighi giuridicamente azionabili. La valutazione del rischio non resta confinata nel documento tecnico, ma informa la struttura economica e sanzionatoria del rapporto con il fornitore.
Particolarmente rilevante è anche il collegamento tra penali e audit. Una penale può essere applicata solo se l’inadempimento è individuabile e dimostrabile. Per questo motivo, essa deve poggiare su evidenze verificabili: report, log, attestazioni, ticket, verbali di audit, tracciamenti di incidenti, esiti di vulnerability assessment, mancato rispetto di tempi di remediation, indisponibilità del servizio, ritardi nelle comunicazioni. La penale non deve dipendere da valutazioni arbitrarie o eccessivamente discrezionali del cliente, ma da indicatori oggettivi o ragionevolmente accertabili. In questo senso, la penale rafforza indirettamente anche la qualità del sistema di monitoraggio: per poter sanzionare, occorre misurare; per poter misurare, occorre costruire evidenze.
Questa relazione tra penale ed evidenza è particolarmente importante in un contesto regolatorio fondato sulla dimostrabilità. Se l’organizzazione deve dimostrare di governare la supply chain, deve poter produrre evidenze del controllo esercitato. Una clausola penale attivata, o anche solo attivabile, sulla base di indicatori chiari, mostra che il controllo non è meramente teorico. Dimostra che il contratto contiene meccanismi effettivi di reazione alle deviazioni. Anche quando la penale non viene concretamente applicata, la sua presenza può incidere sulla condotta del fornitore e rafforzare la posizione del cliente nelle interlocuzioni correttive.
In questa prospettiva, la penale ha anche una funzione di deterrenza collaborativa. Non deve essere necessariamente concepita come strumento conflittuale, destinato a deteriorare il rapporto con il fornitore. Può invece essere utilizzata come componente di un sistema di escalation progressiva: prima il rilievo della non conformità, poi la richiesta di remediation, poi l’applicazione di penali in caso di mancato adeguamento, infine l’attivazione di rimedi più incisivi nei casi gravi o reiterati. In tal modo, la penale non distrugge la relazione contrattuale, ma la disciplina, introducendo un quadro prevedibile di conseguenze.
La prevedibilità è un elemento essenziale della sicurezza. Un fornitore che conosce in anticipo le conseguenze economiche del mancato rispetto di determinate misure è incentivato a strutturare processi interni coerenti. Il cliente, a sua volta, dispone di uno strumento di pressione non improvvisato. Questo riduce l’incertezza e rafforza la governance del rapporto. La penale, quindi, opera anche come strumento di chiarezza organizzativa: stabilisce quali obblighi sono davvero essenziali, quali violazioni sono considerate critiche e quali conseguenze derivano dal mancato rispetto.
Un contratto privo di penali su obblighi cyber essenziali può trasmettere al fornitore un messaggio implicito: tali obblighi sono importanti sul piano formale, ma non realmente prioritari sul piano economico. Al contrario, una penale calibrata su obblighi di sicurezza critici comunica che l’organizzazione attribuisce a tali obblighi un valore concreto. Il contratto, in tal modo, non solo regola il rapporto, ma orienta la cultura della sicurezza tra le parti.
Subfornitori, post-incidente e governance cyber
La penale può inoltre avere un ruolo significativo nella gestione dei subfornitori. Uno dei punti più delicati della supply chain ICT riguarda infatti la catena dei subappalti, dei sub-responsabili e dei fornitori ulteriori. L’organizzazione committente può avere un rapporto diretto solo con il fornitore principale, ma il rischio può derivare da soggetti collocati a valle. In tale scenario, le clausole penali possono essere utilizzate per incentivare il fornitore principale a governare efficacemente la propria sub-supply chain, imponendo obblighi di verifica, approvazione, trasparenza e controllo sui subfornitori. Anche questo è coerente con la logica NIS2, che impone una visione estesa della sicurezza della catena di approvvigionamento.
Un altro ambito in cui la penale assume valore strategico è quello della cooperazione post-incidente. Dopo un incidente di sicurezza, il tempo diventa un fattore regolatorio. Occorre comprendere rapidamente cosa è accaduto, quali sistemi sono coinvolti, se vi sono dati personali impattati, quali misure sono state adottate, quali informazioni devono essere comunicate alle autorità e quali azioni correttive devono essere implementate. Se il fornitore non coopera, ritarda, minimizza o fornisce informazioni incomplete, l’organizzazione può subire un danno regolatorio enorme. Una penale specifica per la mancata cooperazione o per il ritardo nella fornitura delle informazioni post-incidente può quindi rappresentare un presidio essenziale.
Anche in tal caso, la funzione della penale non è meramente economica. Serve a rendere chiaro che la cooperazione non è cortesia commerciale, ma obbligo regolatorio riflesso. Il fornitore deve comprendere che la sua inerzia può compromettere la posizione del cliente davanti all’ACN, al Garante o ad altre autorità competenti. La penale traduce questa rilevanza in conseguenza contrattuale.
Va poi considerato il profilo della proporzionalità. Una clausola penale eccessiva, svincolata dal rischio o costruita in modo punitivo può essere contestata e può risultare meno efficace. La forza della tesi non sta nel suggerire penali elevate in modo indiscriminato, ma nel sostenere penali intelligenti, risk-based, calibrate, documentabili. La penale come misura di sicurezza non è la penale “più alta possibile”, ma la penale più coerente con il rischio che si intende presidiare. La proporzionalità è ciò che consente di trasformarla da clausola aggressiva a strumento regolatorio difendibile.
Questa impostazione consente anche di superare la possibile obiezione secondo cui la penale sarebbe un istituto puramente civilistico e quindi estraneo alla compliance NIS2. È vero che la clausola penale appartiene al diritto civile dei contratti. Ma gli strumenti civilistici possono svolgere funzioni regolatorie quando sono inseriti in un quadro normativo che richiede alle organizzazioni di governare rischi derivanti da terzi. Il fatto che uno strumento nasca nel diritto privato non impedisce che esso diventi parte di un sistema di compliance. Al contrario, nei modelli moderni di regolazione del rischio, il contratto è uno dei principali luoghi in cui gli obblighi pubblicistici vengono tradotti in comportamenti privati.
È precisamente ciò che accade nella supply chain digitale. La legge impone all’organizzazione di gestire il rischio; l’organizzazione trasferisce una parte delle attività a fornitori; il contratto diventa lo strumento attraverso cui quel rischio viene governato; la penale diventa il meccanismo attraverso cui l’obbligo contrattuale viene reso effettivo. In questa catena logica, la penale non è un elemento esterno alla sicurezza, ma uno dei mezzi attraverso cui la sicurezza viene implementata nel rapporto con il terzo.
Questa prospettiva è particolarmente utile anche per i consigli di amministrazione e per il management. La NIS2 rafforza la responsabilità degli organi di amministrazione nella supervisione delle misure di gestione del rischio. Un modello contrattuale che includa penali risk-based per fornitori critici può essere presentato come parte delle scelte organizzative adottate per presidiare la supply chain. Non basta, certamente, ma contribuisce a dimostrare che il vertice aziendale non ha trattato i fornitori come un tema puramente procurement o legal, bensì come componente della governance cyber.
La conseguenza finale è che la penale diventa un indice di maturità contrattuale. Nei modelli meno maturi, il contratto contiene obblighi generici, spesso copiati da template, non collegati al rischio concreto. Nei modelli più maturi, invece, il contratto riflette la classificazione del fornitore, gli esiti della BIA, gli SLA, gli obblighi regolatori, le esigenze di incident response, la gestione delle vulnerabilità e i meccanismi di enforcement. La penale, in questo secondo modello, non è un’aggiunta decorativa, ma il punto in cui la valutazione del rischio diventa conseguenza giuridica.
In definitiva, le penali nei contratti ICT alla luce della NIS2 devono essere ripensate come strumenti di gestione del rischio. La loro funzione non si esaurisce nel compensare un eventuale inadempimento, ma consiste nel rafforzare la probabilità che gli obblighi di sicurezza siano rispettati. Esse introducono un incentivo economico, rendono più credibile il sistema di controllo, supportano la dimostrazione dell’accountability e collegano la contrattualistica alla governance cyber.
La penale, quindi, non è la sicurezza. Ma può diventare una misura organizzativa a supporto della sicurezza. Non sostituisce la due diligence, l’audit, il monitoraggio o la gestione degli incidenti. Ma li rafforza. Non garantisce che il fornitore sarà conforme. Ma rende la non conformità meno conveniente, più visibile e più facilmente azionabile. Ed è proprio questa funzione di effettività, nel nuovo contesto NIS2, a renderla uno strumento molto più importante di quanto la prassi contrattuale tradizionale abbia finora riconosciuto.
