Il lock-in tecnologico è la condizione in cui un’organizzazione diventa così dipendente da un vendor specifico – per ragioni tecniche, contrattuali, operative o normative – da rendere la transizione verso un’alternativa eccessivamente costosa, rischiosa o temporalmente impraticabile.

Non è, di per sé, una patologia in quanto un certo grado di dipendenza dai propri fornitori è fisiologico in qualsiasi ecosistema tecnologico complesso.

Semmai, il problema emerge quando questa stessa dipendenza raggiunge un livello tale da compromettere la capacità dell’organizzazione di prendere decisioni autonome sul proprio stack IT, di rispondere a variazioni del mercato o di gestire una crisi del fornitore senza subire interruzioni operative significative.

Lock-in tecnologico: tipologie e impatto sulla sicurezza

Nel contesto della cyber security, il lock-in tecnologico introduce una dimensione di rischio specifica che va oltre la semplice dipendenza commerciale.

Un’organizzazione profondamente dipendente da un singolo vendor per funzioni di sicurezza critiche, come possono essere un EDR, un SIEM o una piattaforma di identity management, è esposta a un rischio che combina la concentrazione operativa con la superficie di attacco: se quel vendor viene compromesso (come nel caso CrowdStrike del 2024), non solo il servizio si interrompe, ma il sistema di difesa stesso diventa il vettore del problema.

Dunque, la diversificazione non è solo una scelta commerciale ma una misura di resilienza.

Per i soggetti NIS2 e DORA, il rischio di lock-in ha una dimensione normativa esplicita:

• DORA identifica la concentrazione verso un singolo provider ICT come rischio sistemico da presidiare e impone alle entità finanziarie di valutare e documentare le dipendenze critiche.
• NIS2, più in generale, richiede che le misure di sicurezza includano la continuità operativa, un obiettivo difficilmente raggiungibile in presenza di dipendenze non presidiate da adeguate strategie di uscita.

La pianificazione della reversibilità non è, quindi, un’opzione avanzata per le organizzazioni più mature: è un requisito di governance che le normative stanno progressivamente rendendo obbligatorio.

Le quattro forme del lock-in nelle forniture IT

Quando si parla di forniture IT si possono quindi identificare quattro differenti forme di lock-in tecnologico

Lock-in contrattuale

Il lock-in contrattuale è la forma più immediata e, paradossalmente, la più facilmente prevenibile se affrontata nella fase di negoziazione.

Si manifesta attraverso clausole che rendono la cessazione del rapporto commerciale eccessivamente onerosa: penali di uscita anticipata calcolate sull’intero valore residuo del contratto, rinnovi automatici con finestre di disdetta strette, limitazioni al diritto di portabilità dei dati, periodi minimi contrattuali pluriennali senza clausole di revisione.

Nei contratti con i grandi hyperscaler e con i vendor di software Enterprise, queste clausole sono spesso la norma, non l’eccezione.

La difesa contrattuale contro questo tipo di lock-in richiede attenzione in fase di negoziazione:

• clausole di exit esplicite con termini e costi predefiniti;
• diritto di portabilità dei dati in formato standard senza costi aggiuntivi;
• finestre di disdetta ragionevoli (90 giorni è uno standard accettabile per la maggior parte dei servizi);
• limitazione delle penali di uscita anticipata a importi proporzionati e non punitivi.

Per i contratti con vendor che gestiscono funzioni critiche, è opportuno negoziare anche obblighi di supporto alla transizione: un periodo di affiancamento post-contratto durante il quale il vendor fornisce accesso ai dati e supporto tecnico alla migrazione.

Lock-in tecnico

Il lock-in tecnico è la forma più pervasiva e difficile da rimuovere una volta instauratasi.

Si manifesta attraverso la dipendenza da formati proprietari (e quindi, dati che non possono essere esportati in formati standard senza perdita di informazioni o senza strumenti specifici del vendor) e da API proprietarie che richiedono riscrittura significativa delle integrazioni per migrare verso un’alternativa.

Un CRM che archivia i dati in un formato interno non esportabile in CSV o JSON standard, un SIEM che produce log in un formato proprietario non leggibile da altri strumenti, una piattaforma cloud che offre servizi managed senza equivalenti standard: questi sono esempi concreti di lock-in tecnico che si accumula silenziosamente nel tempo, spesso senza che l’organizzazione ne sia consapevole fino al momento in cui cerca di uscire.

La prevenzione del lock-in tecnico richiede una strategia di architettura deliberata: privilegiare standard aperti e interoperabili nelle scelte tecnologiche, evitare dipendenze da servizi proprietari privi di alternative equivalenti, mantenere layer di astrazione (API gateway, middleware) che isolino il business logic dalle specificità del vendor sottostante.

Per le piattaforme cloud, l’adozione di strumenti di Infrastructure as Code (Terraform, Pulumi) con provider-agnostic configuration riduce significativamente il costo di una eventuale migrazione verso un hyperscaler alternativo.

Lock-in operativo

Il lock-in operativo è il meno visibile dei quattro e spesso il più costoso da risolvere.

Si accumula nel tempo attraverso la specializzazione del personale su tecnologie proprietarie specifiche: team IT che conoscono profondamente una piattaforma ma non hanno esperienza con le alternative, processi operativi costruiti attorno alle specificità di un vendor, procedure di troubleshooting e documentazione che assumono implicitamente la presenza di quel vendor.

Quando l’organizzazione deve cambiare, si trova a dover affrontare non solo la migrazione tecnica, ma anche un gap di competenze che richiede tempo e risorse significative per essere colmato.

La gestione del lock-in operativo richiede un approccio proattivo alla formazione e alla documentazione:

• mantenere competenze interne che non dipendano esclusivamente da un singolo vendor;
• costruire processi operativi che siano il più possibile vendor-agnostic;
• documentare le configurazioni e le procedure in modo da renderle trasferibili.

Per le competenze critiche, è buona pratica mantenere almeno una risorsa interna con conoscenza dell’alternativa principale, anche se non la si utilizza attivamente, per garantire la capacità di valutazione in caso di necessità di transizione.

Lock-in normativo

Il lock-in normativo è una categoria specifica dei settori regolamentati: si verifica quando la scelta di un vendor crea dipendenze che sono difficili da sciogliere per ragioni di conformità.

Un sistema di archiviazione che garantisce la conservazione dei log per 10 anni secondo requisiti normativi specifici, una piattaforma di firma elettronica certificata secondo standard nazionali, un sistema di gestione dei dati sanitari conforme a requisiti specifici di settore: migrare da questi sistemi richiede non solo la migrazione tecnica dei dati, ma la verifica che il nuovo vendor garantisca la stessa conformità normativa, spesso un processo lungo e costoso.

Per le organizzazioni nei settori critici NIS2, il lock-in normativo può manifestarsi anche attraverso la data residency: un vendor che garantisce la residenza dei dati in specifiche regioni geografiche richieste dalla normativa applicabile crea una dipendenza che limita le alternative disponibili.

La prevenzione richiede di verificare, in fase di selezione, che esistano almeno due vendor alternativi in grado di soddisfare i requisiti normativi applicabili — non uno solo.

Misurare il lock-in: il Vendor Dependency Index

Riconoscere il lock-in è necessario, ma non sufficiente: per prendere decisioni informate, l’organizzazione ha bisogno di uno strumento che consenta di misurarlo in modo coerente e comparabile tra vendor diversi.

Il Vendor Dependency Index (VDI) è un framework di valutazione strutturato in sei dimensioni, ciascuna con un peso relativo proporzionale al suo impatto sulla capacità di transizione. Il risultato è un punteggio da 1 (dipendenza minima, transizione agevole) a 5 (lock-in critico, transizione estremamente costosa o impraticabile nel breve termine).

Il VDI non è uno strumento assoluto, ma uno strumento di confronto e prioritizzazione. Il suo valore principale è rendere visibile e quantificabile un rischio che altrimenti rimane implicito nelle valutazioni soggettive dei team IT. Un VDI superiore a 3,5 per un vendor che gestisce funzioni critiche deve attivare un piano di mitigazione; un VDI superiore a 4,5 rappresenta una dipendenza che richiede attenzione immediata del management.

Scenari di crisi: quando la exit strategy non è più una scelta

La pianificazione della reversibilità è spesso percepita come un esercizio accademico, utile in teoria ma difficilmente necessario nella pratica quotidiana.

Gli scenari di crisi che seguono hanno lo scopo di ancorare questa percezione alla realtà: sono casi che si sono verificati, si verificano regolarmente, e che le organizzazioni prive di una exit strategy hanno affrontato in condizioni di estrema difficoltà operativa.

Fallimento o insolvenza del vendor

Un vendor IT che gestisce infrastrutture critiche entra in procedura fallimentare. Il servizio si interrompe con preavviso di 30-60 giorni. I dati sono bloccati fino alla nomina del curatore. L’organizzazione deve migrare in emergenza verso un’alternativa senza il supporto del vendor.

Casi reali: il fallimento di diversi provider cloud di secondo livello negli anni 2015-2020 ha lasciato centinaia di clienti senza accesso ai propri dati per settimane. La lezione: la solidità finanziaria del vendor è un elemento del rischio lock-in, non solo un indicatore commerciale.

Un VDI elevato su un vendor con indicatori finanziari in deterioramento è un segnale di allerta critico.

Acquisizione ostile o cambio di strategia

Un vendor critico viene acquisito da un concorrente diretto dell’organizzazione cliente, o da un soggetto con interessi in conflitto. Il nuovo proprietario modifica le condizioni contrattuali, aumenta i prezzi in modo significativo, o discontinua il prodotto. L’organizzazione si trova vincolata a un contratto con un vendor che non avrebbe mai scelto.

Casi reali: l’acquisizione di VMware da parte di Broadcom (2023) e la successiva ristrutturazione delle licenze ha costretto migliaia di organizzazioni a rivalutare la propria dipendenza dalla piattaforma di virtualizzazione, con costi di migrazione non previsti. La lezione: il vendor che si acquista oggi potrebbe non essere lo stesso tra due anni.

Sanzione regolatoria o esclusione dal mercato

Un vendor viene sanzionato da un’autorità regolatoria (ACN, Garante privacy, autorità di vigilanza finanziaria) o incluso in liste di restrizione per ragioni di sicurezza nazionale. L’organizzazione deve cessare il rapporto entro tempi imposti dalla normativa, indipendentemente dal costo e dalla complessità della migrazione.

Casi reali: le restrizioni imposte in diversi paesi europei e negli USA a vendor di telecomunicazioni e software di origine cinese (Huawei, ZTE, Kaspersky) hanno costretto le organizzazioni nei settori critici a migrazioni urgenti.

La lezione che ne possiamo trarre è che il rischio geopolitico è un componente del rischio lock-in che deve essere valutato esplicitamente per i vendor con sede o interessi in paesi ad alto rischio.

Lock-in e Vendor Risk Management: la reversibilità come presidio strategico

Sviluppare un piano di transizione verso provider alternativi evita l’interruzione operativa del business in caso di crisi del fornitore. La pianificazione della reversibilità è un pilastro del Vendor Risk Management moderno per mitigare i rischi cyber: la capacità di uscire da una relazione con un vendor critico in tempi ragionevoli e senza interruzioni operative non è una misura difensiva straordinaria, ma un requisito di resilienza che le normative NIS2 e DORA stanno progressivamente codificando.

La reversibilità non significa necessariamente cambiare vendor frequentemente o mantenere architetture ridondanti costose: significa avere la capacità di farlo quando necessario, in tempi accettabili, con un costo proporzionato.

Questa capacità si costruisce nel tempo attraverso scelte architetturali deliberate, clausole contrattuali adeguate e un monitoraggio continuo del grado di dipendenza.

Un’organizzazione che ha investito nella portabilità dei dati, nell’interoperabilità dei sistemi e nella formazione del personale su più piattaforme è intrinsecamente più resiliente e più conforme ai requisiti normativi di una che ha ottimizzato esclusivamente sull’integrazione con un singolo vendor.

Strategie di mitigazione: portabilità, interoperabilità e approccio multi-vendor

Portabilità dei dati: il requisito non negoziabile

La portabilità dei dati è il prerequisito tecnico di qualsiasi strategia di exit. Senza la capacità di estrarre i propri dati in formato standard e completo, qualsiasi piano di migrazione è teorico.

Eppure, nella pratica, molte organizzazioni scoprono i limiti alla portabilità dei dati solo quando tentano di effettuare la migrazione: formati di esportazione incompleti, API con rate limit che rendono l’estrazione di grandi volumi impraticabile in tempi ragionevoli, costi di egress per il trasferimento dei dati fuori dalla piattaforma del vendor.

La difesa contro questo rischio deve essere contrattuale e tecnica insieme. Sul piano contrattuale: clausole esplicite che garantiscono l’esportazione completa dei dati in formati aperti e documentati, senza costi aggiuntivi, entro termini definiti dalla richiesta di cessazione.

Sul piano tecnico: test periodici di esportazione dei dati critici (non solo la verifica che la funzione esista, ma la verifica che funzioni correttamente con i volumi reali) e documentazione aggiornata del formato dei dati esportati per facilitare l’importazione nel sistema del vendor alternativo.

Interoperabilità e standard aperti: costruire senza muri

L’adozione di standard aperti e di architetture interoperabili è la strategia di prevenzione del lock-in tecnico più efficace a lungo termine.

Nel contesto cloud, questo si traduce nella preferenza per servizi che implementano API standard (REST, OpenAPI, GraphQL) rispetto a API proprietarie, nell’utilizzo di formati di dati aperti (JSON, Parquet, CSV) rispetto a formati binari proprietari, e nell’adozione di strumenti di orchestrazione e provisioning che supportano nativamente più provider (Kubernetes per i container, Terraform per l’Infrastructure as Code).

Per le piattaforme di sicurezza, l’interoperabilità è garantita dall’adozione di standard come STIX/TAXII per la condivisione di threat intelligence, OpenC2 per l’automazione della risposta, e OCSF (Open Cybersecurity Schema Framework) per la normalizzazione dei log di sicurezza.

L’adozione di questi standard non è solo una scelta tecnica: è una misura di resilienza che riduce il costo di sostituzione di un componente della stack di sicurezza e facilita l’integrazione con nuovi vendor.

Approccio multi-vendor: bilanciare rischio e complessità

La strategia multi-vendor, ossia distribuire le funzioni critiche tra vendor diversi per ridurre la concentrazione del rischio, è la risposta più diretta al lock-in tecnologico, ma anche quella con i costi operativi più elevati.

Gestire più vendor per la stessa funzione introduce complessità: interfacce diverse, procedure operative distinte, costi di formazione moltiplicati, potenziali problemi di integrazione.

La scelta tra vendor singolo e multi-vendor non è quindi una scelta tra sicurezza e comodità: è una valutazione del trade-off tra rischio di concentrazione e costo operativo della diversificazione.

Un approccio pragmatico prevede di applicare la strategia multi-vendor selettivamente, in funzione della criticità della funzione e del VDI del vendor primario: per le funzioni essenziali con VDI elevato, la duplicazione è giustificata e raccomandabile; per le funzioni con VDI basso e alternative disponibili in tempi ragionevoli, la complessità aggiuntiva di un secondo vendor non è necessariamente giustificata.

Il caso degli hyperscaler è emblematico: una strategia multi-cloud attiva (workload distribuiti tra AWS, Azure e GCP) riduce il lock-in ma aumenta significativamente la complessità operativa; una strategia cloud-agnostic basata su Kubernetes e Terraform mantiene la portabilità senza la complessità della gestione multi-cloud attiva.

La exit strategy: come strutturarla contrattualmente e tecnicamente

Clausole di reversibilità nei contratti IT

La exit strategy inizia dal contratto. Le clausole di reversibilità, spesso trascurate nella negoziazione, quando l’attenzione è concentrata sulla funzionalità e sul prezzo, sono lo strumento che garantisce all’organizzazione il diritto e la capacità pratica di uscire dalla relazione con il vendor in condizioni controllate.

Gli elementi essenziali di una clausola di reversibilità efficace coprono quattro aree:

1. il diritto di portabilità (esportazione completa dei dati in formato standard, senza costi aggiuntivi);
2. il supporto alla transizione (periodo di affiancamento post-contratto, tipicamente 90-180 giorni, durante il quale il vendor continua a fornire accesso ai dati e supporto tecnico alla migrazione);
3. la cancellazione certificata (distruzione sicura dei dati residui con certificazione documentata);
4. la continuità del servizio (garanzia che il servizio continui a funzionare normalmente durante il periodo di transizione, senza degradazione delle performance o delle funzionalità).

Piano di migrazione: fasi, costi e tempistiche

Il piano di migrazione è il documento operativo che traduce la strategia di exit in un progetto concreto con fasi, responsabilità, risorse e tempistiche.

Deve essere preparato con anticipo: idealmente al momento dell’onboarding del vendor, non quando la migrazione diventa urgente, e aggiornato periodicamente per riflettere l’evoluzione dell’ambiente tecnologico e della relazione con il vendor.

Un piano di migrazione mai aggiornato è quasi inutile nel momento del bisogno.

Le fasi tipiche di un piano di migrazione da un vendor critico sono:

• assessment dell’ambiente attuale (inventario di dati, integrazioni, dipendenze, competenze);
• selezione del vendor alternativo (con processo di valutazione formale che include security assessment e VDI preliminare);
• progettazione dell’architettura target;
• migrazione pilota su ambiente non produttivo;
• migrazione progressiva degli ambienti produttivi con rollback plan;
• verifica funzionale e di sicurezza;
• dismissione dell’ambiente del vendor precedente con cancellazione certificata dei dati.

Per i sistemi critici, la fase di coesistenza in cui entrambi i vendor operano in parallelo è raccomandata anche quando aumenta il costo a breve termine: garantisce la continuità operativa durante la transizione e riduce il rischio di interruzione.

Cloud provider e lock-in: il caso degli hyperscaler e degli ambienti ibridi

Il lock-in nei servizi cloud degli hyperscaler (AWS, Microsoft Azure, Google Cloud Platform) merita una trattazione specifica per la sua pervasività e per la complessità delle dipendenze che può generare.

I grandi provider cloud offrono ecosistemi di servizi managed estremamente ricchi e integrati: database proprietari (DynamoDB, Cosmos DB, BigQuery), servizi serverless (Lambda, Azure Functions, Cloud Run), strumenti di ML/AI nativi, servizi di sicurezza integrati.

L’adozione di questi servizi genera produttività immediata e integrazione nativa e il lock-in tecnico che cresce con ogni servizio managed aggiuntivo adottato.

La risposta non è evitare i servizi managed degli hyperscaler, sarebbe come rinunciare a vantaggi competitivi reali, ma adottarli con consapevolezza del lock-in che generano.

Una strategia cloud pragmatica distingue tra i servizi che sono accettabile avere in lock-in (servizi non critici, facilmente riproducibili, con basso VDI) e quelli per cui la portabilità deve essere preservata (dati critici, funzioni essenziali, sistemi con compliance normativa specifica). Per questi ultimi, l’investimento in architetture cloud-agnostic (container-based, IaC-managed, con storage in formati aperti) è un investimento in resilienza, non solo in flessibilità tecnica.

Per le organizzazioni che operano in ambienti ibridi (infrastruttura on-premise combinata con servizi cloud) il rischio di lock-in si manifesta anche attraverso la dipendenza dagli strumenti di gestione dell’ambiente ibrido stesso: soluzioni come VMware (ora Broadcom), Azure Arc, AWS Outposts.

L’acquisizione di VMware da parte di Broadcom e la conseguente ristrutturazione del modello di licensing è diventata il caso di scuola del lock-in negli ambienti ibridi: migliaia di organizzazioni si sono trovate a dover rivalutare la propria infrastruttura di virtualizzazione in condizioni di urgenza, con costi non previsti e alternative tecnicamente complesse da implementare in tempi brevi.