Guardian360
Inizia la prova gratuitaDiventa partner
← Tutti i post

Opinione

MSP, la NIS2 ha alzato il dovere di diligenza del tuo cliente. Ha alzato anche il tuo.

Di Jan Martijn Broekhof ·

Mentre mi preparavo per un webinar sulla Cyberbeveiligingswet, l’attuazione olandese della NIS2, ho parlato con Henk Bijsterbosch di Samen Digitaal Veilig. Mi ha detto una cosa che mi è rimasta impressa: il doppio dovere di diligenza salta fuori in quasi ogni conversazione che ha con gli MSP. Non come un rischio ipotetico che un giorno potrebbero affrontare, ma come qualcosa che già in silenzio plasma il modo in cui clienti e MSP discutono su chi fosse responsabile di cosa.

Vale la pena affrontare quella conversazione come si deve, perché non è un problema olandese. La Cyberbeveiligingswet è in vigore nei Paesi Bassi dal 15 agosto 2026. Il Belgio ha recepito la NIS2 nel diritto nazionale già nell’ottobre 2024. Il NIS2UmsuCG tedesco è entrato in vigore il 6 dicembre 2025. La Francia, al momento in cui scrivo, non ha ancora completato il recepimento ed è stata deferita alla Corte di giustizia dell’UE per il ritardo. Quattro mercati, quattro tempistiche diverse, e una cosa che non aspetta nessuno di loro: il dovere di diligenza civilistico che si applica ai fornitori professionali di IT e sicurezza da decenni, molto prima che qualcuno avesse mai sentito parlare della NIS2.

Che cos’è esattamente il doppio dovere di diligenza?

Ci sono due livelli, e gli MSP tendono a notare il primo e a mancare il secondo. Il primo è il dovere di legge del cliente. La NIS2, e le sue attuazioni nazionali, mettono la responsabilità della gestione del rischio, della registrazione e della segnalazione degli incidenti direttamente sull’organizzazione stessa. La guida tecnica di implementazione dell’ENISA è esplicita nel dire che anche i managed service provider e i managed security service provider rientrano nell’ambito di questi requisiti, il che è un utile promemoria del fatto che non si tratta di una storia puramente lato cliente.

Il secondo livello è più antico e facile da trascurare proprio perché precede la normativa. Nei Paesi Bassi, l’articolo 7:401 del Codice civile olandese obbliga il prestatore di servizi professionali ad agire con la diligenza di un operatore competente, e la giurisprudenza olandese ha ripetutamente imposto ai fornitori IT un accresciuto dovere di informazione e di avvertimento a causa del divario di competenza tra loro e i loro clienti, come illustra la panoramica di Dirkzwager sulle sentenze rilevanti. Il Belgio ha la propria versione di questa dottrina: lo Hof van Cassatie ha stabilito già nel 2006 che un fornitore IT ha il dovere di informare, consigliare e avvertire il proprio cliente, un principio ancora oggi citato nella dottrina giuridica belga. La Germania arriva a una conclusione simile attraverso la propria giurisprudenza. Quando l’OLG Schleswig ha ritenuto responsabile un fornitore di servizi IT per non aver consigliato adeguatamente un cliente prima della stipula del contratto, e il Bundesgerichtshof ha rifiutato di esaminare un ulteriore ricorso, ha confermato un dovere precontrattuale completo di informare e consigliare. La Cour de cassation francese ha stabilito lo stesso, ovvero che un fornitore di prodotti IT complessi ha nei confronti del cliente un dovere di consiglio, almeno dal 2006, e la Cour d’appel de Rennes ha applicato quel principio direttamente a una controversia in materia di cybersicurezza nel novembre 2024.

Quattro paesi, quattro sistemi giuridici, la stessa idea di fondo: la NIS2 non ha inventato questo dovere. Ha soltanto alzato la posta in gioco per chi lo ignora.

Perché la responsabilità del cliente non può semplicemente diventare un problema del cliente?

È qui che si annida il paradosso, e vale la pena soffermarcisi anziché passarci sopra di corsa. La NIS2 mette il cliente al posto di guida. Il cliente decide quale rischio accetta, in cosa investe e come stabilisce le priorità. Un MSP può consigliare, ma non può costringere un cliente ad agire in base a quel consiglio. Finora, sembrerebbe una cosa che dovrebbe mettere l’MSP al riparo.

Non è così, e il motivo è coerente in ogni giurisdizione che ho esaminato: la parte più esperta porta il dovere più pesante, a prescindere da chi firma le carte della conformità. Una Corte d’appello olandese, in un caso discusso da Elferink & Kortier Advocaten, si è spinta ancora oltre, stabilendo che un fornitore IT professionale deve indagare attivamente se le scelte del cliente stesso siano effettivamente giustificate, e non limitarsi a lanciare un avvertimento e andare avanti. Avere ragione sul fatto che la decisione spettasse al cliente non significa automaticamente che l’MSP abbia fatto abbastanza.

Quando un cliente rifiuta il tuo consiglio

Questo è lo schema che la maggior parte degli MSP riconosce d’istinto, e si svolge più o meno allo stesso modo ovunque. Consigli una misura, EDR, gestione delle patch, autenticazione a più fattori, qualcosa che considereresti igiene di base. Il cliente la rifiuta, per ragioni di costo, di comodità, o semplicemente perché “non abbiamo mai avuto problemi”. Mesi dopo, un’autorità di vigilanza effettua un controllo, o peggio, si verifica un incidente. Il cliente, ora esposto alla propria responsabilità di legge ai sensi della NIS2, cerca qualcun altro con cui condividere la colpa, e l’MSP che aveva dato il consiglio è il candidato più ovvio. Come sottolinea Critical.Matters, questa dinamica è già visibile nei Paesi Bassi ancor prima che gli obblighi della Cyberbeveiligingswet si siano pienamente consolidati: i clienti scaricano le richieste di sicurezza lungo la catena verso i loro fornitori ben prima di qualsiasi azione di enforcement.

Quando un cliente non vuole investire nella certificazione

Il secondo schema è leggermente diverso ma finisce nello stesso punto. Un cliente rifiuta di ottenere una certificazione di sicurezza riconosciuta, che si tratti di un framework di supply chain allineato alla NIS2, della ISO 27001 o di uno standard di settore. Sia chiaro, la certificazione non è un requisito legale per dimostrare di avere sotto controllo la propria sicurezza; moltissime organizzazioni possono provarlo attraverso policy documentate, audit e un processo credibile di gestione del rischio. Ma un certificato è un modo rapido ed esterno per dimostrarlo, a un’autorità di vigilanza, a un assicuratore, o a un tuo cliente in ansia. Senza di esso, e senza un’alternativa altrettanto convincente, un’organizzazione è più esposta quando un cliente importante se ne va o un contratto salta dopo una verifica di sicurezza. Ancora una volta, l’MSP che aveva segnalato la lacuna può ritrovarsi accusato di non aver spinto abbastanza.

La visione scettica, e perché non regge

Sarebbe legittimo chiedersi se questa non sia semplicemente paura travestita da thought leadership, un modo comodo per vendere servizi di certificazione o consulenza sulla conformità. Capisco lo scetticismo. Ma lo schema descritto sopra non è speculazione; è documentato in sentenze provenienti da quattro diversi sistemi giuridici, nell’arco di quasi due decenni. Ciò che la giurisprudenza mostra anche, in modo coerente, è che gli MSP capaci di indicare una traccia documentale, consigli documentati, decisioni del cliente messe per iscritto, un resoconto chiaro di ciò che è stato raccomandato e di ciò che è stato rifiutato, escono da queste controversie in una posizione molto più solida rispetto a chi non ne è capace. Il rischio è reale. Ed è anche, nella maggior parte dei casi, gestibile.

Che cosa riduce davvero il rischio?

Questa è la parte rassicurante, e merita tanta attenzione quanto l’avvertimento. Tre cose fanno costantemente la differenza.

Documenta il tuo consiglio, e documenta la decisione del cliente quando lo rifiuta. Non una nota vaga in un sistema CRM, ma qualcosa di abbastanza specifico da reggere mesi o anni dopo: che cosa hai raccomandato, perché, e che cosa il cliente ha scelto di fare invece.

Definisci requisiti minimi di sicurezza prima di prendere un cliente, o prima di rinnovare, anziché scoprire le lacune dopo che qualcosa è andato storto. Non si tratta di fare i difficili; si tratta di essere onesti, presto, quando il rapporto consente ancora una conversazione schietta.

Non lasciare che “il cliente non lo voleva” resti non registrato. È la singola frase che determina se una controversia diventa una conversazione condivisa sul rischio o una discussione a senso unico sulla colpa.

Niente di tutto questo richiede che un MSP diventi un ufficio legale. Richiede di trattare la documentazione come parte del servizio, non come scartoffie da sbrigare se resta tempo.

Se vuoi approfondire il tema, l’8 ottobre ospiterò un webinar per il mercato olandese sulla Cyberbeveiligingswet, che tratterà ciò che richiede davvero e, altrettanto importante, come dimostrare che le tue misure di sicurezza funzionano nella pratica e non solo sulla carta. Puoi iscriverti qui.

Ecco quindi la domanda che vale la pena porsi questa settimana: se domani un cliente ti contestasse un consiglio che gli hai dato diciotto mesi fa, riusciresti davvero a produrlo?

Fonti