La responsabilità di governance non si delega con un contratto: il board deve rispondere anche delle falle dei propri fornitori
Il firewall che apre la porta
Immaginate questo scenario. Il vostro vendor di sicurezza subisce una breach. La prima comunicazione è rassicurante: solo il 5% dei clienti è coinvolto. Settimane dopo, la verità emerge nella sua interezza, il 100% dei clienti è stato impattato. Nel frattempo i file di configurazione dei firewall sono stati esfiltrati, e voi siete già stati colpiti senza saperlo. È esattamente ciò che è accaduto a una fintech statunitense che serve oltre settecento istituti bancari. Colpita da ransomware in estate, ha scoperto solo un mese dopo che il proprio fornitore di firewall aveva subito a sua volta un'intrusione, con esfiltrazione massiva delle configurazioni di rete di tutti i clienti. La mancata disclosure tempestiva ha impedito qualsiasi mitigazione. Ne è nata una causa legale che ridefinisce il perimetro della responsabilità nella catena di fornitura della sicurezza. Come osserva Erin Jane Illman, partner dello studio Bradley, i vendor di sicurezza non sono più semplici partner tecnici. Sono potenziali co-convenuti.
Il rischio bilaterale che nessun board ha previsto
La tentazione post-breach è nota: scaricare la colpa sul fornitore. Dopo un incidente, il management ha un incentivo strutturale a posizionare il vendor come causa esclusiva del danno, per proteggersi da azioni di azionisti e regolatori. Ma il tavolo si capovolge con facilità. Joseph Lazzarotti, attorney presso JacksonLewis, ribalta la prospettiva: se l'organizzazione non ha condotto una due diligence adeguata nella selezione del fornitore, né ha previsto clausole contrattuali con scenari worst-case, la negligenza nella selezione ricade sul cliente stesso. Il rischio è quindi bilaterale. Vendor e organizzazione possono trovarsi entrambi sotto accusa, in una dinamica in cui l'assenza di chiarezza contrattuale pre-incidente diventa la vera vulnerabilità. Per il board, questo significa che la firma su un contratto di fornitura senza SLA calibrati sullo scenario peggiore non è solo un'imprudenza operativa. È un'esposizione diretta della governance.
Il blame-shifting come strategia di sopravvivenza
La frizione reale è più profonda di un contenzioso legale. Dopo una breach, si attiva un meccanismo prevedibile: il board cerca un capro espiatorio contrattuale, il vendor nega il nesso causale, e nel mezzo resta una catena di responsabilità che nessuno ha definito con precisione prima dell'incidente. Chi detiene realmente l'ownership del rischio di terze parti? Chi ha scelto il vendor sul piano tecnico, chi ha negoziato il contratto sul piano commerciale, o chi ha approvato il budget senza pretendere garanzie operative adeguate? In molte organizzazioni, questa domanda non ha un proprietario. Il blame-shifting post-breach non è un difetto caratteriale del management. È il sintomo di un'architettura di governance che ha delegato il rischio senza delegare l'autorità di gestirlo, e che ha distribuito la responsabilità fino a renderla di nessuno. Jackson Stephens, senior cybersecurity counsel di Galactic Advisors, lo definisce un pattern ricorrente: la governance del rischio di terze parti è spesso l'ultimo capitolo scritto e il primo a saltare sotto stress.
NIS2 e DORA: il quadro europeo non lascia margini
Il caso descritto è statunitense, ma il pattern è universale. E in Europa, il quadro normativo ha già chiuso molti degli spazi di ambiguità che negli USA restano aperti al contenzioso. La Direttiva NIS2, all'articolo 20, impone agli organi di gestione delle entità essenziali e importanti di approvare e supervisionare direttamente le misure di gestione del rischio cyber, con responsabilità personale. L'articolo 21, comma 2, lettera d, richiede esplicitamente la sicurezza della catena di approvvigionamento, inclusa la valutazione delle vulnerabilità specifiche di ciascun fornitore diretto. Non è un principio generico: è un obbligo puntuale. Per il settore finanziario, il Regolamento DORA al Capo V disciplina la gestione del rischio ICT derivante da terze parti con obblighi di valutazione, monitoraggio continuo e clausole contrattuali obbligatorie verso i fornitori ICT critici. Una fintech europea che serve centinaia di banche rientrerebbe pienamente in questo perimetro. Il ponte tra il caso americano e il contesto europeo è concettuale, non giuridico. Ma la lezione è la stessa: la responsabilità di governance sulla supply chain non è un'opzione contrattuale. È un vincolo regolatorio.
La domanda che il vostro contratto non prevede
Se domani il vostro fornitore di firewall venisse compromesso, e scopriste che i file di configurazione della vostra rete sono stati esfiltrati settimane prima che qualcuno ve lo comunicasse, il vostro contratto reggerebbe? I vostri SLA prevedono tempi di notifica vincolanti per breach che coinvolgono i dati dei clienti del vendor? La vostra due diligence ha incluso la verifica della postura di sicurezza del fornitore stesso, o si è fermata alla compliance documentale? E soprattutto: davanti a un regolatore europeo che applica NIS2 o DORA, il vostro board potrebbe dimostrare di aver esercitato la supervisione richiesta dalla norma? Queste non sono domande teoriche. Sono le domande che un'autorità di vigilanza porrà il giorno dopo l'incidente. E le risposte non si improvvisano in sala crisi.
I contratti con i vendor di sicurezza vengono scritti per il giorno in cui tutto funziona. La governance si misura il giorno in cui il fornitore diventa il problema, e quel giorno, nella maggior parte delle organizzazioni, non è ancora stato previsto.