La gestione dei fornitori tecnologici sta assumendo un peso crescente nelle strategie di resilienza aziendale. L’8 luglio 2026 il NIST ha pubblicato la versione definitiva della guida SP 1326, dedicata alla due diligence nella supply chain informatica. Il documento rafforza un principio ormai centrale: prima di acquistare un prodotto o affidare un servizio occorre raccogliere informazioni sufficienti sul fornitore, sulla sua struttura e sui rischi associati.
Esternalizzare un’attività, infatti, non trasferisce automaticamente le conseguenze operative di un’interruzione. L’impresa continua a rispondere degli effetti prodotti su clienti, ricavi, dati e obblighi normativi. Il vendor management deve quindi superare la semplice verifica del prezzo e comprendere prestazioni, dipendenze, capacità di recupero e condizioni necessarie per cambiare provider.
Indice degli argomenti:
Il ruolo strategico del vendor management nelle scelte tecnologiche aziendali
La selezione di un fornitore influenza l’architettura informatica, i costi futuri e la libertà negoziale dell’organizzazione. Una soluzione conveniente nella fase iniziale può diventare difficile da sostituire quando applicazioni, procedure e competenze interne vengono costruite intorno a tecnologie proprietarie.
La valutazione deve precedere il contratto e proseguire per l’intera durata del rapporto. Solidità economica, sicurezza, uso di subfornitori, localizzazione dei dati e capacità di risposta agli incidenti sono elementi che possono cambiare nel tempo. Una due diligence eseguita una sola volta offre quindi una fotografia destinata a perdere rapidamente validità.
La crescente dipendenza dai fornitori IT e i rischi di lock-in tecnologico
Cloud, SaaS e servizi gestiti riducono parte delle attività interne, ma accrescono la dipendenza da API, formati, configurazioni e competenze controllate dal provider. Il lock-in diventa critico quando la migrazione richiede tempi incompatibili con le esigenze aziendali o quando l’esportazione dei dati non consente di ricostruire il servizio altrove.
Il Data Act, applicabile nell’Unione europea dal 12 settembre 2025, introduce obblighi destinati a facilitare il passaggio tra fornitori di servizi di trattamento dei dati. Il regolamento prevede anche la progressiva eliminazione dei costi di switching, che dal 12 gennaio 2027 non potranno più essere imposti. La normativa riduce alcune barriere, ma non elimina le difficoltà tecniche di una migrazione mal pianificata.
Perché una gestione inefficiente dei partner danneggia i margini operativi
Licenze inutilizzate, servizi sovrapposti e livelli di supporto sproporzionati aumentano la spesa senza produrre vantaggi equivalenti. A questi costi visibili si aggiungono quelli generati da indisponibilità, rallentamenti e incidenti che interrompono vendite, produzione o attività amministrative.
Il NIST considera la gestione del rischio della supply chain un processo continuo di identificazione, valutazione e mitigazione delle minacce associate a prodotti e servizi. Il controllo economico del fornitore non può quindi essere separato da quello operativo. Un contratto conveniente perde valore quando introduce dipendenze non comprese o rende troppo onerosa la sostituzione del servizio.
Come negoziare SLA tecnici efficaci per proteggere gli investimenti
Uno SLA efficace traduce le esigenze aziendali in parametri misurabili. Non dovrebbe limitarsi a descrivere genericamente un servizio affidabile, ma indicare quali prestazioni devono essere garantite, come saranno rilevate e quali rimedi scatteranno in caso di mancato rispetto.
Il livello richiesto deve derivare dall’impatto sul processo sostenuto. Un’applicazione utilizzata occasionalmente non necessita delle stesse garanzie di una piattaforma che gestisce ordini, pagamenti o produzione. Prima della negoziazione occorre pertanto distinguere i servizi critici da quelli sostituibili o temporaneamente differibili.
Definire metriche chiare oltre la disponibilità percentuale dei sistemi
Una disponibilità del 99,9% può sembrare elevata, ma consente comunque diverse ore di indisponibilità nell’arco di un anno. Il dato medio può inoltre nascondere interruzioni concentrate nei momenti più delicati per il business.
Agli indicatori di uptime vanno affiancati latenza, tasso di errore, capacità, tempi di presa in carico e ripristino. RTO e RPO chiariscono rispettivamente entro quanto tempo il servizio deve tornare operativo e quale perdita di dati può essere tollerata. Lo SLA deve precisare periodo di osservazione, fonte dei dati, esclusioni e finestre di manutenzione.
Inserire penali finanziarie e clausole di uscita orientate alla business continuity
I service credit possono compensare una parte del canone quando il fornitore non raggiunge i livelli concordati, ma raramente corrispondono alla perdita effettivamente subita dal cliente. Penali, risarcimenti e limitazioni di responsabilità devono essere valutati in base alla legge applicabile e alla capacità negoziale delle parti.
La clausola di uscita è altrettanto importante. Dovrebbe disciplinare formati e tempi di restituzione dei dati, assistenza alla migrazione, continuità durante il passaggio e cancellazione delle copie residue. Senza procedure già definite, la sostituzione del provider rischia di diventare più costosa dell’inadempimento che l’ha resa necessaria.
Le criticità nel monitoraggio dei contratti e delle prestazioni dei fornitori
Il controllo degli SLA fallisce quando le metriche vengono verificate soltanto al momento del rinnovo o quando il soggetto valutato è anche l’unica fonte dei dati. Un report mensile può documentare il risultato dichiarato dal provider senza mostrare come il disservizio sia stato percepito dagli utenti.
È necessario definire responsabilità interne, frequenza delle verifiche e modalità di escalation. Il monitoraggio deve inoltre distinguere l’inadempimento contrattuale da un degrado che, pur restando formalmente entro le soglie, produce un impatto rilevante sui processi aziendali.
La mancanza di visibilità indipendente sulle metriche dichiarate dal vendor
Monitoraggio sintetico, log applicativi e telemetria di rete consentono di confrontare le misure del provider con quelle osservate dal cliente. L’obiettivo non è costruire automaticamente una prova contro il fornitore, ma disporre di una base tecnica indipendente per comprendere durata, perimetro e conseguenze dell’evento.
Eventuali divergenze devono essere analizzate prima di attribuire responsabilità. Fusi orari, punti di osservazione, esclusioni contrattuali e differenti definizioni di indisponibilità possono produrre risultati non coincidenti anche quando i dati sono stati raccolti correttamente.
La frammentazione delle responsabilità in architetture multi-cloud e ibride
In un ambiente distribuito, lo stesso incidente può coinvolgere rete aziendale, cloud provider, integratore e produttore del software. Ogni contratto descrive una parte dell’architettura, mentre il cliente subisce l’effetto complessivo del disservizio.
Una matrice delle responsabilità deve stabilire chi rileva l’evento, chi esegue la diagnosi, chi comunica agli utenti e chi coordina il ripristino. Nel settore finanziario, DORA richiede una gestione strutturata del rischio legato ai fornitori ICT e particolare attenzione agli accordi che sostengono funzioni essenziali o importanti.
Ottimizzare il vendor management e far rispettare gli SLA grazie all’AIOps
L’AIOps può riunire dati provenienti da infrastrutture, applicazioni, reti e servizi cloud, confrontando le prestazioni osservate con i livelli contrattuali. Non sostituisce il contratto e non decide se si sia verificato un inadempimento, ma aiuta a costruire una ricostruzione tecnica più completa.
Il suo valore dipende dalla qualità della telemetria. Dati incompleti, orologi non sincronizzati o configurazioni incoerenti possono alterare la sequenza degli eventi e rendere meno affidabile l’analisi.
Disporre di una verità condivisa e oggettiva sulle prestazioni infrastrutturali
Una verità condivisa non coincide con una singola dashboard. Richiede metriche definite in modo comune, punti di misurazione conosciuti e dati conservati per un periodo sufficiente. Soltanto queste condizioni consentono di distinguere un’impressione operativa da un evento documentato.
Le evidenze devono rimanere accessibili anche durante audit, rinnovi e controversie. Se i dati storici dipendono esclusivamente dalla piattaforma del provider, il cliente potrebbe perderli proprio nel momento in cui decide di uscire dal rapporto.
Identificare le reali responsabilità dei disservizi con la correlazione degli eventi di AIOps
La correlazione può ricostruire una catena causale probabile tra componenti, mostrando se il degrado sia iniziato nella rete, nell’applicazione o nell’infrastruttura del fornitore. Non determina però una responsabilità giuridica e non sostituisce l’analisi tecnica definitiva.
Un sistema affidabile deve mostrare le evidenze utilizzate, il livello di confidenza e le ipotesi alternative. Attribuzioni automatiche non spiegabili possono irrigidire il confronto tra le parti anziché favorire una soluzione.
Guidare la rinegoziazione dei contratti IT con l’approccio predittivo di AIOps
Lo storico delle prestazioni permette di comprendere quali livelli di servizio abbiano realmente protetto il business e quali siano rimasti inutilizzati. Le analisi predittive possono inoltre segnalare capacità insufficienti o degradi ricorrenti prima che producano un’interruzione.
Queste informazioni migliorano la negoziazione, ma non garantiscono il comportamento futuro del servizio. Le previsioni devono essere accompagnate da dati osservati, metodologie comprensibili e soglie operative concordate.
Analizzare lo storico dei dati per ridefinire i livelli di servizio necessari al business
L’analisi degli incidenti può evidenziare fasce orarie critiche, componenti fragili e tempi di ripristino superiori a quelli dichiarati. La rinegoziazione può così introdurre SLA differenziati per processo, area geografica o periodo dell’anno.
Garanzie più severe hanno normalmente un costo maggiore. Dovrebbero essere acquistate quando la perdita evitata supera il prezzo aggiuntivo, evitando di applicare lo stesso livello di protezione a servizi con impatti molto diversi.
Ottimizzare i costi delle licenze e del supporto scoprendo gli sprechi infrastrutturali
Telemetria e dati di utilizzo possono individuare licenze inattive, capacità sovradimensionata e livelli di supporto raramente utilizzati. La riduzione deve però considerare picchi stagionali, crescita attesa e necessità di continuità.
Un vendor management maturo combina contratto, architettura ed evidenze operative. Gli SLA proteggono l’investimento soltanto quando misurano ciò che conta per il business, prevedono un’uscita praticabile e possono essere verificati attraverso dati indipendenti.
Bibliografia
NIST, Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide, SP 1326, 8 luglio 2026.
NIST, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, SP 800-161 Rev. 1, Update 1, novembre 2024.
NIST, U.S. Government Cloud Computing Technology Roadmap, Volume II, SP 500-293, con tassonomia e metriche per gli SLA.
Unione europea, Regolamento (UE) 2023/2854 relativo a norme armonizzate sull’accesso equo ai dati e sul loro utilizzo — Data Act.
Unione europea, Regolamento (UE) 2022/2554 relativo alla resilienza operativa digitale per il settore finanziario — DORA.
Commissione europea, Regolamento delegato (UE) 2024/1773 sugli accordi contrattuali per i servizi ICT a supporto di funzioni essenziali o importanti.
ENISA, Technical Implementation Guidance on Cybersecurity Risk-Management Measures, giugno 2025.
Partecipa alla community