L'adozione della sicurezza inizia nel consiglio di amministrazione, non all'helpdesk

Il settore MSP ha finalmente iniziato a parlare di adozione. Si parla di licenze Copilot, punteggi di awareness e strutture Teams, tutto incentrato sugli utenti finali. La conversazione più difficile, quella che conta di più, non è ancora iniziata sul serio: le persone personalmente responsabili del rischio cyber capiscono davvero le dashboard che il loro MSP mostra loro?

Quella domanda è tornata a galla in diverse recenti conversazioni con i clienti, in varie sessioni con i partner, e ancora una volta durante un recente episodio di MSP Late Night, dove l’adozione era, finalmente, il tema centrale. Le voci attorno al tavolo erano acute su Copilot, sulla formazione di awareness e sul divario tra vendere una licenza e cambiare i comportamenti. Ma la discussione è rimasta quasi interamente sull’utente finale. Nella sicurezza delle informazioni e nella compliance, dove NIS2 ha ormai reso gli amministratori personalmente responsabili, il punto cieco più grande sta un piano più su.

L’adozione non è solo un problema dell’utente finale

Quando gli MSP parlano di adozione, tendono a intendere la stessa cosa che intendono i vendor di produttività. Le persone usano lo strumento? Danno prompt a Copilot? Completano il modulo di awareness? Cliccano i pulsanti giusti nel sistema giusto?

Quelle domande contano. Ma nella sicurezza e nella compliance c’è una seconda domanda sull’adozione che quasi mai viene posta. Il dirigente che ha approvato il contratto capisce cosa gli sta dicendo lo strumento? L’amministratore personalmente responsabile del risultato legge la dashboard? Il management che possiede il rischio d’impresa guida l’organizzazione sulla base dei numeri che produce?

Se non lo fanno, la dashboard non è adottata. È stata pagata. Che è una cosa diversa.

Come fa un amministratore a sapere se il suo MSP lo sta davvero proteggendo?

Questa è la domanda che titolari, amministratori e membri del consiglio digitano nelle barre di ricerca e pongono ai loro consulenti di fiducia. È anche la domanda a cui gli MSP sono meno attrezzati a rispondere in un linguaggio comprensibile per il consiglio.

Il Global Cybersecurity Outlook 2026 del World Economic Forum, pubblicato a gennaio 2026 insieme ad Accenture e basato sulle risposte di 804 senior leader in 92 paesi, cattura il divario in due cifre. Tra le organizzazioni che il WEF classifica come altamente resilienti, il novantanove per cento riferisce il coinvolgimento del consiglio nella cybersecurity. Incoraggiante di primo acchito. Leggi più in basso nello stesso report e solo il cinquantadue per cento di quelle stesse organizzazioni dice che i membri del consiglio ricevono effettivamente aggiornamenti regolari sulla cybersecurity. “Il coinvolgimento senza informazione non è la stessa cosa della supervisione.”

Lo stesso sondaggio è schietto su un secondo punto: ciò che preoccupa il CEO e ciò che preoccupa il CISO non coincidono più. I CEO mettono in cima alle loro preoccupazioni la frode abilitata dal cyber e il phishing; i CISO classificano ancora al primo posto il ransomware. Guardano lo stesso panorama di minacce e traggono conclusioni diverse, perché leggono dashboard diverse in vocabolari diversi.

Per un amministratore, alla domanda “sono protetto” non si può rispondere indicando un Secure Score, una percentuale di compliance o una mappa di calore a colori. Si può rispondere solo grazie a qualcuno disposto a tradurre il punteggio nelle conseguenze per l’azienda: fatturato a rischio, contratti a rischio, responsabilità personale a rischio.

Una dashboard non è una strategia

Entra nella tipica organizzazione mid-market che usa un MSP per sicurezza e compliance, e troverai dashboard. Microsoft Secure Score. Un conteggio di vulnerabilità da uno scanner. Una percentuale di readiness ISO 27001. Un self-assessment NIS2. Una console Defender o EDR. A volte una vista personalizzata dell’MSP stesso.

Ciò che di solito non troverai è una breve risposta alla domanda: “Cosa significa tutto questo per la nostra azienda in questo trimestre?”

Il Defenders Survey 2025 di Trend Micro, che ha interpellato più di tremila professionisti della cybersecurity, ha centrato il punto con chiarezza. Solo circa il trenta per cento degli intervistati ha detto che la propria organizzazione ha “un modello strutturato e continuo per comunicare con gli stakeholder sugli eventi di sicurezza”. Il report ha concluso che gestire il rischio cyber a livello dirigenziale “richiede traduzione: esprimere i rischi in termini di business invece che tecnici”.

Le dashboard esistono, i dati esistono, gli strumenti funzionano. Il collo di bottiglia è il livello di traduzione. E il livello di traduzione è, quasi per definizione, il ruolo di chiunque si trovi tra la tecnologia e il consiglio. Per la maggior parte delle organizzazioni mid-market, quello è l’MSP.

Hans ten Hove, un habitué del tavolo di MSP Late Night, l’ha catturato con schiettezza in un post LinkedIn in olandese: “una soluzione non adottata, ha scritto, è semplicemente una fattura costosa con una dashboard attaccata”. Vale la pena tenere a mente questa frase ogni volta che viene lanciata una nuova dashboard di compliance.

Cosa ha cambiato silenziosamente NIS2 riguardo alla responsabilità del consiglio?

La discussione sarebbe teorica se non fosse per lo spostamento normativo ormai saldamente arrivato.

Ai sensi dell’Articolo 20 della Direttiva NIS2, l’organo di gestione di un’entità essenziale o importante deve approvare le misure di gestione del rischio di cybersecurity dell’organizzazione, sovrintendere alla loro implementazione e seguire una formazione obbligatoria per poter valutare i rischi cyber. Come ha esposto DLA Piper in un’analisi della direttiva del novembre 2025, questa responsabilità non può essere delegata al reparto IT né esternalizzata a un fornitore esterno. Gli Stati membri hanno ricevuto il potere di imporre la responsabilità personale ai singoli amministratori, e nei casi gravi di sospendere un CEO o un legale rappresentante dalle sue funzioni.

Il BSI-Gesetz rivisto della Germania, entrato in vigore il 6 dicembre 2025, va ancora oltre. Rende gli organi di gestione personalmente responsabili dell’effettiva implementazione delle misure di rischio cyber, non solo della loro approvazione. Il regolatore tedesco ha confermato che, con la scadenza di registrazione del 6 marzo 2026 ormai passata, è passato all’enforcement attivo.

Per un MSP, l’implicazione è più netta di quanto appaia a prima vista. Un amministratore personalmente responsabile del rischio cyber e che non riesce a spiegare, in un linguaggio semplice, cosa significhi la sua dashboard di compliance è esposto. Non perché l’MSP abbia fallito tecnicamente; perché il divario di adozione, tra lo strumento e la persona legalmente responsabile del risultato, non è mai stato colmato.

NIS2 non dice che gli MSP debbano diventare interpreti di business. Ma rende impossibile per qualsiasi membro serio del consiglio restare un ricevitore passivo di un Secure Score che non legge.

Da vendor IT a interprete di business

È qui che il ruolo dell’MSP deve evolvere, ed è qui che molti MSP onestamente lo trovano più scomodo. L’implementazione è terreno battuto. Cicli di patch, baseline, monitoraggio, incident response, SLA sui ticket. L’arte tecnica di gestire un parco IT è genuinamente difficile, e le persone che la svolgono bene meritano più credito di quello che ricevono.

Ciò che l’arte tecnica non produce automaticamente è una conversazione in cui un amministratore capisce, in cinque minuti, contro cosa è protetto, contro cosa non è protetto, quanto costerebbe colmare il divario, e cosa succederebbe all’azienda se il divario venisse sfruttato.

Quella conversazione è una competenza diversa. Serve qualcuno capace di sedersi tra una console Microsoft Defender e un conto economico, e spiegare perché l’una influisce sull’altro. Serve qualcuno a suo agio nel dire: “Il tuo punteggio di compliance è del settantotto per cento, ecco i tre controlli che mancano, ed ecco il contratto che potresti perdere se l’audit di un cliente li scopre.” Serve che l’MSP smetta di vendere strumenti e inizi a vendere chiarezza.

Alcuni MSP nei mercati olandese, belga e tedesco stanno silenziosamente costruendo questa capacità all’interno dei propri team. La maggior parte non lo sta ancora facendo. Quelli che lo faranno scopriranno che le loro conversazioni di rinnovo diventano più brevi e i loro margini migliorano, perché il valore che offrono diventa visibile alla persona che firma l’assegno. Quelli che non lo faranno saranno ricordati come il fornitore le cui dashboard nessuno leggeva.

Dove si colloca Guardian360

Gestisco un ISV che produce una di quelle dashboard, quindi sarebbe disonesto scrivere tutto questo senza affrontare cosa facciamo e cosa non facciamo.

La piattaforma Lighthouse produce i consueti output tecnici che qualsiasi strumento di sicurezza serio produce: risultati di scansione su reti, IP e applicazioni web, insight di sicurezza Microsoft 365 tramite la Graph API, rilevamenti di vulnerabilità e raccomandazioni di compliance rispetto a più di quaranta norme e leggi. Nulla di tutto ciò è unico. Ciò che abbiamo costruito negli ultimi anni, e ciò che riteniamo conti di più per la conversazione di questo blog, è un business risk score che affianca i punteggi di rischio tecnico. L’obiettivo è semplice: dare al consiglio un numero che si colleghi al business, non solo all’asset.

Una piattaforma può supportare la conversazione di traduzione. Non può avere la conversazione. Quello è il compito del partner, ed è dove dipendiamo, ogni giorno, dagli MSP, dagli integratori e dai consulenti che lavorano con noi. Lo strumento colma parte del divario di adozione. La relazione colma il resto.

Una domanda diversa da porre alla tua prossima review con l’MSP

Se sei un amministratore, un titolare o un membro del consiglio, non hai bisogno di leggere gli articoli di NIS2 per agire su ciò che implicano. Alla tua prossima review con il tuo partner IT, non chiedere cosa hanno implementato in questo trimestre. Chiedi se tu, il tuo management e idealmente il tuo consiglio capite cosa significano quelle implementazioni per l’azienda.

Se la risposta richiede più tempo del riepilogo delle implementazioni, hai la tua conclusione.

L’adozione della sicurezza inizia nel consiglio di amministrazione, non all’helpdesk. Il settore MSP, il più ampio comparto IT e i regolatori hanno tutti iniziato, ciascuno a modo suo, a spingere nella stessa direzione. I blog e i podcast sull’adozione da parte dell’utente finale sono un inizio sano. La prossima conversazione, quella più difficile, riguarda le persone i cui nomi compaiono in cima all’organigramma e le cui firme finiscono sulla lettera del regolatore.

Se quella conversazione non è ancora avvenuta nella tua organizzazione, è la più utile da mettere in agenda.