Un sistema legacy è un software, un’applicazione o un componente che continua a supportare un’attività aziendale ma che non può essere aggiornato, sostituito o configurato con la stessa semplicità dei sistemi più recenti. Può governare una produzione, conservare dati tecnici, gestire un collegamento con un cliente o sostenere un passaggio operativo che nessuno vuole interrompere.
Il problema non è la sua età. Il problema nasce quando l’azienda non sa con precisione che cosa quel sistema abilita, quali informazioni tratta, chi lo usa e che cosa accadrebbe se fosse indisponibile o compromesso. In un percorso TISAX, ignorare questa domanda crea una doppia difficoltà: scegliere misure non adatte e non riuscire a spiegare perché le decisioni prese sono proporzionate al rischio.
Legacy non significa automaticamente inaccettabile
Un sistema non diventa inutilizzabile solo perché è datato. Alcune applicazioni restano necessarie per vincoli contrattuali, compatibilità con macchinari, dipendenze tecniche o tempi di sostituzione non immediati. Trattarle tutte come un’unica categoria porta però a due errori opposti: investire nello stesso modo su elementi con impatto molto diverso oppure rimandare ogni intervento perché la sostituzione sembra troppo complessa.
La domanda iniziale è concreta: quale attività si ferma se il sistema non è disponibile? Per esempio, un archivio usato soltanto per consultare documenti storici non ha lo stesso impatto di un’applicazione che scambia informazioni tecniche con la filiera, gestisce accessi in stabilimento o supporta una fase produttiva. La criticità dipende dal ruolo reale del sistema, non dall’etichetta “legacy”.
Partire da attività, informazioni e dipendenze
Per classificare un sistema in modo utile, la direzione e i responsabili operativi devono ricostruire pochi elementi verificabili. Quale processo aziendale supporta? Quali informazioni entrano, escono o restano archiviate? Quali persone, fornitori o altri sistemi devono poterlo usare? Qual è il tempo massimo accettabile di fermo per quell’attività?
Questa ricostruzione evita inventari fatti solo di nomi tecnici e versioni software. Se un’applicazione riceve disegni, dati di progetto, specifiche di prodotto o informazioni di clienti, il suo impatto va valutato anche in relazione a queste informazioni. Se dipende da un fornitore che può intervenire solo da remoto, occorre chiarire chi autorizza l’accesso, con quale canale, in quali orari e dove viene registrato l’intervento.
In un contesto automotive, TISAX offre un quadro condiviso di assessment e scambio di informazioni per la filiera. Non trasforma ogni scelta organizzativa in un requisito identico per tutte le imprese: aiuta piuttosto a rendere coerente e dimostrabile il modo in cui un’organizzazione identifica rischi e mette in campo protezioni adeguate.
Definire una criticità che porti a decisioni
Una classificazione utile non deve produrre una scala complessa che nessuno aggiorna. Può partire da tre domande: quale danno crea un fermo? quale danno può derivare da un accesso non autorizzato o dalla perdita di informazioni? quanto è difficile ripristinare servizio, dati e configurazioni?
Le risposte devono essere attribuite a persone che conoscono il lavoro. Il responsabile di produzione può descrivere le conseguenze di un blocco; chi segue clienti o progettazione può spiegare il valore delle informazioni coinvolte; l’IT può indicare limiti tecnici, dipendenze e possibilità di ripristino. La direzione usa questi elementi per decidere priorità, budget e rischio residuo, non per configurare direttamente il sistema.
Il risultato atteso è leggibile: sistema, attività supportata, informazioni rilevanti, proprietario della decisione, livello di criticità e azioni previste. Senza questa sintesi, una vulnerabilità o una richiesta di aggiornamento rischiano di essere valutate soltanto in base all’urgenza percepita.
Scegliere misure proporzionate ai limiti reali
Dopo la classificazione, non è sempre possibile installare subito un aggiornamento o sostituire il sistema. È però possibile ridurre l’esposizione con misure coerenti con il caso concreto. Un’applicazione che non può essere aggiornata potrebbe essere separata dalla rete ordinaria, accessibile solo a utenti autorizzati, protetta da copie di sicurezza testate e monitorata con controlli adatti alle sue caratteristiche.
Anche le modalità di assistenza contano. Se un fornitore assiste il cliente per una determinata applicazione, l’azienda può prevedere una richiesta autorizzata, un accesso limitato nel tempo, una persona di riferimento e una registrazione dell’attività svolta. Non serve trasformare ogni intervento in un blocco burocratico: serve poter ricostruire chi è entrato, perché, su quale sistema e con quale esito.
La misura più forte sulla carta non è sempre quella più efficace. Una regola che interrompe la produzione e viene aggirata non protegge l’azienda. Una misura proporzionata è applicabile, ha un responsabile e viene verificata quando cambiano servizio, fornitore, configurazione o priorità operative.
Gestire il rischio residuo senza renderlo invisibile
Può accadere che una parte del rischio resti aperta: un componente non più supportato, un’integrazione difficile da modificare o una sostituzione pianificata ma non ancora realizzata. In questi casi la scelta non dovrebbe restare in una conversazione informale tra tecnici.
È utile registrare quale limite esiste, quali misure sono già attive, chi accetta il rischio residuo, entro quando verrà riesaminato e quale evento richiede una nuova decisione. Un incidente, una modifica del processo, un nuovo collegamento esterno o il cambio del fornitore possono rendere insufficiente una valutazione precedente.
Questa traccia non è un modo per giustificare l’inazione. È il modo per distinguere una decisione temporanea e governata da un problema lasciato senza proprietario. Durante un assessment, permette inoltre di mostrare come l’organizzazione collega una situazione tecnica a responsabilità e verifiche operative.
Preparare evidenze che raccontino il lavoro reale
Le evidenze più credibili non nascono pochi giorni prima dell’assessment. Possono comprendere una scheda di classificazione aggiornata, l’elenco dei sistemi e delle dipendenze, le autorizzazioni agli accessi remoti, gli esiti delle prove di ripristino e le decisioni su priorità o sostituzioni.
Non occorre raccogliere documenti ridondanti. Occorre che quanto è scritto corrisponda al lavoro quotidiano. Chi usa il sistema deve poter spiegare quale attività svolge; chi lo gestisce deve poter indicare le protezioni e i limiti; chi decide deve poter mostrare perché una misura è stata finanziata, rinviata o sottoposta a riesame.
Conclusione
I sistemi legacy non scompaiono perché vengono chiamati “eccezioni”. Per gestirli in modo credibile, un’azienda deve prima collegarli a processi, informazioni e conseguenze operative. Solo allora può scegliere misure realistiche, assegnare responsabilità e verificare nel tempo se la decisione resta adeguata. Questo approccio non promette rischio zero: rende il rischio conosciuto, discusso e governabile.