Quando il fornitore IT
scarica il rischio sul cliente

Un caso reale di fine aprile 2026

Il caso che segue è anonimizzato e alcuni dettagli operativi sono stati astratti per non identificare le parti coinvolte. La dinamica descritta è rappresentativa di situazioni che incontriamo regolarmente nel mercato italiano.

Studio professionale italiano. Architettura cloud first: gestionale in cloud, posta in cloud, documenti in cloud, server interno residuale. Rete e perimetro gestiti con apparecchiature managed di livello business, IDS e IPS attivi, nessuna porta pubblicata verso l’esterno. In una parola, una postura di sicurezza ragionevole per il 2026.

Un fornitore IT esterno arriva on site per installare una nuova apparecchiatura on-premise. Non chiede la classe IP, non chiede se esiste una rete dedicata, non propone una propria infrastruttura di rete: gli apparati vengono collegati alla stessa rete dove transitano dati gestionali e documentali, senza segmentazione. Quando si parla del controllo remoto futuro per assistenza, il tecnico chiude la discussione con un sintetico «facciamo una VPN» e rimanda al collega via email.

Da lì partono cinque giorni di scambi. Lo schema delle proposte cambia tre volte: prima una VPN site to site over TLS in modalità client lato cliente per mantenere il controllo dei vincoli; poi il fornitore chiede una VPN client SSL o IKEv2 sul firewall del cliente; alla fine, dopo un confronto con il titolare dello studio, si arriva alla decisione finale: nessuna VPN permanente, sessioni di controllo remoto on demand avviate dall’utente quando serve, e in agenda una segmentazione VLAN che riduce strutturalmente il rischio.

Il fornitore accetta, ma non senza obiezioni. Nella sua mail finale elenca quattro criticità operative dell’accesso on demand (rallentamenti, impossibilità di schedulare, costi, affermando che la soluzione proposta non aumenta in alcun modo la sicurezza rispetto a una VPN client configurata correttamente) e chiude rimettendosi alla decisione del cliente. Il cliente è consapevole. La discussione sembra finita. In realtà qui inizia la parte interessante.

Il punto che il fornitore non vede: di chi è il rischio?

Il fornitore ragiona da fornitore: il suo problema è come accedere comodamente ai propri apparati installati presso il cliente quando deve fare manutenzione, troubleshooting, aggiornamenti. La VPN permanente è il workflow che gli costa meno gestire. Da quel punto di vista la sua argomentazione tecnica non è sbagliata: una VPN client su firewall enterprise, con restrizione IP sorgente, ACL su porte e protocolli, autenticazione a più fattori, è effettivamente una soluzione robusta.

Una precisazione tecnica per i lettori più esperti: in ambiente enterprise reale, una VPN client con identity provider e MFA per-utente offre log e accountability per persona che una VPN site to site basata su pre-shared key o certificato peer non può dare. Resta però vero che in molte implementazioni di filiera IT per PMI, la VPN client si traduce in una credenziale di gruppo installata sui PC di lavoro del fornitore, e quel vantaggio evapora.

Ma la domanda di sicurezza non era «quale VPN scegliamo». Era una domanda diversa: « chi si fa carico del rischio che questa modalità di accesso introduce?». E qui la prospettiva ribalta tutto. Il cliente, per accettare la richiesta del fornitore, avrebbe dovuto:

• acquistare e mantenere licenza e configurazione del VPN server sul proprio firewall;
• integrare un identity provider con MFA per autenticare il fornitore;
• creare e governare un account dedicato per il fornitore, con provisioning, deprovisioning, rotazione credenziali, audit accessi;
• definire e mantenere ACL, policy time based, log review sulla VPN del fornitore;
• assorbire il rischio supply chain: se il fornitore viene compromesso, l’ attaccante eredita un canale stabile verso la rete del cliente.

Tutto questo per un’apparecchiatura on-premise installata nel 2026, in uno studio dove tutto il resto è cloud. La domanda corretta che il fornitore non si è posto è: come erogare il proprio servizio di assistenza senza chiedere al cliente di abbassare la propria postura di sicurezza. Le risposte esistevano: erogazione del servizio in cloud, reverse tunnel call home dal sistema del fornitore, sessioni unattended di controllo remoto attivabili dal cliente, bastion host del fornitore. Tutte mettono il costo operativo dalla parte di chi eroga il servizio, che è il principio corretto.

Lo schema giusto: servizio → impatto → misura → asset

Il modo in cui è stato risolto il caso non è una scelta improvvisata. Segue lo schema esplicitamente richiesto dalla determinazione ACN 155238/2026 sulla categorizzazione delle attività e dei servizi NIS, ed è lo stesso approccio già presente nella ISO/IEC 27001:2022 (Annex A) e nel principio di accountability del GDPR. Non si parte dall’asset, si parte dal servizio e si arriva all’asset alla fine, come passo derivato.

• 1Servizio. Il servizio core dello studio è la consulenza ai propri clienti, non la funzione di supporto erogata dal fornitore. Quella funzione è importante ma non vitale. Categoria di rilevanza intrinseca: bassa o media, mai alta.
• 2Impatto. Cosa succede se il fornitore viene compromesso e qualcuno usa la VPN come pivot? Compromissione dei suoi apparati: impatto basso. Pivot laterale verso la rete dati con documenti di clienti, fascicoli, dati personali e finanziari: impatto alto. Esfiltrazione e ransomware: impatto catastrofico. Il rischio reale non è sulla funzione di supporto, è sull’aggregazione di apparati e dati nella stessa rete.
• 3Misura. Tre livelli, complementari. Organizzativa: accesso on demand sotto controllo dell’utente (riduce drasticamente la finestra di attacco). Architetturale: segmentazione VLAN per funzione (confina il blast radius alla sola VLAN del fornitore qualunque cosa accada). Contrattuale: clausole con il fornitore su MFA, log accessi, notifica vulnerabilità, sub fornitori. Le tre misure si rafforzano a vicenda, nessuna basta da sola.
• 4Asset. Solo ora si parla di apparati specifici, switch managed con supporto 802.1Q, regole firewall, ACL inter VLAN. Sono lo strumento per applicare le misure decise, non il punto di partenza.

La differenza non è teorica. Un fornitore o un consulente che parte dagli asset finisce per giustificare qualunque richiesta tecnica del fornitore con un «la VPN client è sicura configurata bene». Un consulente che parte dal servizio si chiede se la richiesta è proporzionata, e nella maggioranza dei casi scopre che non lo è.

Lo stesso principio in tre norme: GDPR, ISO 27001, NIS2

Quello che il caso ha messo in pratica non è una novità introdotta dalla NIS2. È un principio già scritto in modo netto in tre pilastri normativi che convivono dal 2018 in poi, ognuno con il proprio linguaggio:

Tre versioni dello stesso principio: il rischio di chi lavora per te è tuo. Quello che cambia con la NIS2 non è il principio: è il fatto che diventi pubblico, esigibile e sanzionato. Tutto il resto era già obbligo da almeno otto anni.

Perché lo studio professionale è il caso da manuale

Commercialisti, avvocati, notai, consulenti del lavoro, medici, studi tecnici. Sono per definizione titolari del trattamento di dati personali altrui, spesso di categorie particolari (art. 9 GDPR per i dati relativi alla salute, e nel caso di commercialisti e consulenti del lavoro per i dati fiscali, patrimoniali e dei dipendenti dei loro clienti).

Tradotto: lo studio non sta proteggendo i propri dati. Sta proteggendo i dati che i clienti gli hanno affidato. Se accade un breach, il danno reputazionale e legale ricade in misura significativa sui clienti che gli avevano dato fiducia, oltre che sullo studio stesso. Per questa ragione la responsabilità sulla scelta dei fornitori IT è più pesante, non meno, di quella di una PMI generica.

• Articolo 28 GDPR. Lo studio professionale, in qualità di titolare, deve scegliere fornitori che offrano garanzie sufficienti su misure tecniche e organizzative. Accettare qualunque cosa il fornitore proponga, «perché così si è sempre fatto», non è conforme.
• Articolo 32 GDPR. Le misure devono essere adeguate al rischio. Aprire una VPN permanente verso un fornitore IT esterno per un servizio non vitale è una misura palesemente sproporzionata se sull’altro lato della rete ci sono fascicoli di centinaia di clienti.
• Articolo 5(2) GDPR. Il principio di accountability impone di poter dimostrare le scelte. «Ho aperto la VPN perché il fornitore me l’ha chiesta» non è una giustificazione documentabile davanti al Garante in caso di breach.
• ISO/IEC 27001 A.5.19 – A.5.22. Stessa logica con linguaggio tecnico: censimento fornitori, accordi formali, controlli di sicurezza nei contratti, monitoraggio. Anche chi non è certificato dovrebbe usarla come buona prassi per documentare la propria due diligence.

L’effetto a cascata: anche chi non è soggetto NIS2

C’è un secondo livello che riguarda direttamente gli studi professionali e le PMI italiane, ed è il più sottovalutato. La NIS2 non si applica solo ai soggetti essenziali e importanti. Per via della disciplina sulla sicurezza della catena di approvvigionamento (art. 21(2)(d)), si applica di fatto anche ai loro fornitori, attraverso clausole contrattuali e processi di vendor risk management.

Tradotto: se anche un solo cliente di uno studio professionale è soggetto NIS2 (essenziale o importante), lo studio si trova trascinato dentro gli obblighi del cliente per via contrattuale, anche se come singola entità non rientra nel perimetro NIS. Il cliente NIS2 è obbligato a:

• 1censire lo studio come fornitore rilevante (Det. ACN 127437/2026 sull’obbligo di elencare i fornitori sulla piattaforma ACN);
• 2valutare il rischio di una sua compromissione sul proprio servizio (i dati fiscali, le buste paga, i contratti del cliente sono nelle mani dello studio);
• 3applicare misure proporzionate: clausole contrattuali di sicurezza, requisiti minimi, diritto di audit, notifica incidenti entro tempi stringenti;
• 4documentare queste valutazioni e mantenerne evidenza per l’autorità.

Concretamente, lo studio inizierà a ricevere (se non ha già iniziato): questionari di sicurezza fornitori, clausole contrattuali con MFA obbligatorio sui sistemi che processano i dati del cliente, obblighi di notifica incidenti, richieste di evidenze documentali (registro dei trattamenti GDPR, policy di sicurezza, certificazioni ISO 27001 dove possibile, attestazioni delle misure tecniche). Se non riesce a rispondere in modo credibile, il cliente NIS è obbligato a rinegoziare o sostituirlo.

Bastano due conti rapidi per capire la portata. Tra le PMI manifatturiere italiane importanti NIS, tra le utility, le aziende sanitarie, i soggetti della pubblica amministrazione, i fornitori critici della filiera ICT, già oggi sono oltre 21.000 i soggetti registrati, di cui almeno 5.000 essenziali (dato comunicato da ACN all’ottava riunione del Tavolo NIS, aprile 2026). Quanti commercialisti italiani non hanno almeno uno di questi tra i propri clienti? Pochissimi.

Il paradosso che chiude il cerchio

Ed eccolo, il paradosso che lega il caso al tema della supply chain: lo studio professionale che, in nome del «si è sempre fatto così», accetta da un fornitore IT un workflow che trasferisce implicitamente costo e rischio dal lato fornitore al lato cliente, diventa proprio quel tipo di fornitore non conforme che il suo cliente NIS2 dovrà censire, valutare e — se non si mette in regola nei tempi previsti — sostituire.

La stessa permissività che lo studio mostra verso i propri fornitori IT, se la ritroverà specchiata dai propri clienti NIS che lo valuteranno con criteri opposti. Restare nella supply chain di un soggetto NIS richiede di applicare gli stessi standard che si pretende dai propri fornitori. E non si può chiedere ai propri clienti rigore se non lo si applica ai propri fornitori.

Cosa fare oggi: cinque mosse concrete

Non serve un programma enterprise. Servono evidenze proporzionate alla dimensione e al rischio. Per uno studio professionale o una PMI cinque mosse coprono il 90% del valore:

• 1Censire i fornitori IT. Un foglio o una pagina con elenco di chi accede a sistemi e dati: gestionale, posta, archiviazione, telefonia, manutenzione hardware, consulenti, sviluppatori esterni. Per ciascuno: cosa tratta, come accede, da dove.
• 2Classificarli per criticità. Tre livelli sono sufficienti: critico (compromette la continuità del servizio o tratta dati sensibili), rilevante, standard. La classificazione guida l’intensità delle misure.
• 3Allineare i contratti. Per i fornitori critici: DPA ai sensi dell’art. 28 GDPR, clausole minime su MFA dove tecnicamente possibile, obbligo di notifica incidenti entro tempi ragionevoli (24-72 ore), divieto di sub fornitori senza preavviso, diritto di audit documentale.
• 4Tracciare le decisioni. Se un fornitore chiede una modalità di accesso e si decide di accettarla con vincoli, o di rifiutarla in favore di un’alternativa, scrivere il perché. Sono tre righe di testo che valgono oro davanti al Garante o a un cliente che fa audit. Tracciabilità decisionale, non burocrazia.
• 5Applicare segmentazione e principio di minimo privilegio. Anche con risorse modeste: reti separate (VLAN voce, VLAN dati, VLAN ospiti), niente porte pubblicate verso l’esterno se evitabili, accessi remoti solo on demand, MFA ovunque, log conservati. Sono misure tecniche standard, non ricerca di frontiera.

Il messaggio finale per uno studio professionale nel 2026

Per uno studio professionale — commercialista, avvocato, notaio, medico, consulente del lavoro — la domanda nel 2026 non è più «sono soggetto NIS2?». Sono quattro:

1. Quanti dei miei clienti sono soggetti NIS2 (essenziali o importanti)?
2. Quanti dei miei clienti sono subfornitori di soggetti NIS2 anche senza saperlo?
3. Sono in grado di rispondere al questionario di sicurezza che mi arriverà nei prossimi mesi?
4. I miei fornitori IT mi mettono nelle condizioni di rispondere bene, o mi creano rischi che dovrò poi spiegare al cliente NIS che mi audita?

Se la risposta alla quarta è negativa, lo studio ha un problema reale, ma il problema si manifesterà come perdita di clienti e di credibilità molto prima che come sanzione amministrativa. E in entrambi i casi non si tratterà di un onere «NIS2»: si tratterà di fare finalmente bene quello che GDPR e ISO 27001 chiedevano già da anni.

Un partner certificato per la supply chain IT

AtWorkStudio opera da Piacenza dal 2000. Siamo certificati ISO/IEC 27001:2022, ISO/IEC 27017:2015, ISO/IEC 27018:2019 e UNI EN ISO 9001:2015, con qualificazione ACN QC1 per i servizi cloud (Email Security Gateway e Backup Microsoft 365). Siamo membri di Clusit (Associazione Italiana per la Sicurezza Informatica) e associati a Confindustria Piacenza nel cluster RICT.

Possiamo affiancare studi professionali e PMI nel governo della supply chain IT con un percorso proporzionato: censimento dei fornitori, valutazione del rischio, allineamento contrattuale, definizione delle modalità di accesso accettabili, segmentazione di rete, MFA, tracciabilità delle decisioni. Lo facciamo dal lato del cliente, mai del fornitore.

Una nota di onestà intellettuale: anche AtWorkStudio è un fornitore IT, e gli stessi principi che chiediamo agli altri li applichiamo a noi. Pubblichiamo la lista dei nostri sub-fornitori, manteniamo certificazioni ISO/IEC 27001:2022, ISO/IEC 27017:2015 e ISO/IEC 27018:2019 (gestione di informazioni di identificazione personale in cloud), abbiamo ottenuto la qualificazione ACN QC1 per i servizi cloud su misure di sicurezza superiori al baseline. Si può predicare bene se si razzola coerente, e siamo i primi a essere giudicati con gli stessi criteri che proponiamo ai nostri clienti.