Skip to content
Resilienza informatica e sicurezza dei dati

La progettazione per la sovranità digitale inizia con le domande giuste

Perché le strategie di sovranità più efficaci partono dal rischio, non dalla tecnologia.


Nel primo episodio della nostra serie STRIVE dedicata alla sovranità digitale, Alex Zinin di Commvault e Max Mortillaro di Osmium Data Group hanno sfatato uno dei più grandi malintesi del settore: la sovranità digitale non è una funzionalità che si acquista, ma una sfida aziendale che occorre comprendere prima di poterla risolvere.

Questa conversazione riprende da dove si era interrotta la precedente. Questa volta ho incontrato Thomas Maurer, Global Black Belt per Sovereign Cloud (EMEA) presso Microsoft, per approfondire cosa succede dopo che un’organizzazione ha deciso che la sovranità è una questione importante. In che modo i team dirigenziali passano da preoccupazioni di carattere generale relative alla normativa, alla giurisdizione o all’incertezza geopolitica a decisioni pratiche in materia di architettura?

A quanto pare, la risposta raramente è così semplice come scegliere un fornitore di servizi cloud o selezionare il modello di implementazione più adatto. Si tratta piuttosto di porsi le domande giuste prima di prendere decisioni tecniche. Guarda l’episodio completo.

Punti di forza

  • Ogni organizzazione definisce la sovranità digitale in modo diverso – ed è proprio da qui che dovrebbe partire il dibattito.
  • La sovranità non può essere garantita dalla sola tecnologia. Le considerazioni di natura giuridica, operativa, architettonica e commerciale contribuiscono tutte a determinare il risultato.
  • Il cloud e l’approccio on-premises non sono strategie in competizione tra loro. Per molte organizzazioni, il futuro consiste in una combinazione attentamente studiata di entrambe.
  • Sono le misure di gestione del rischio – e non la paura – a dover guidare le decisioni in materia di sovranità.
  • Una buona architettura parte dalla comprensione delle esigenze aziendali, non dalla scelta dell’infrastruttura.

Il concetto di sovranità assume significati diversi a seconda delle organizzazioni

Una delle prime osservazioni fatte da Thomas è stata anche una delle più importanti. Non esiste una definizione universale di sovranità digitale. Per un’organizzazione, può significare semplicemente soddisfare i requisiti normativi o mantenere i dati all’interno di un’area geografica specifica. Per un’altra, può implicare indipendenza operativa, continuità operativa o preparazione a perturbazioni geopolitiche. Questa differenza è importante perché cambia completamente il quadro di riferimento.

Troppo spesso le organizzazioni danno per scontato che esista un modello standard di sovranità pronto per essere implementato. In realtà, la prima sfida non consiste nella scelta della tecnologia, bensì nel comprendere quale problema l’organizzazione stia effettivamente cercando di risolvere. È solo allora che l’architettura comincia ad avere senso.

La tecnologia dovrebbe seguire la strategia

Un tema emerso ripetutamente nel corso della nostra discussione è stata la tentazione di passare direttamente alla progettazione tecnica. È comprensibile. Gli architetti pensano naturalmente alle infrastrutture, ai carichi di lavoro, alla connettività e ai modelli di implementazione. Ma Thomas ha sottolineato che i progetti di maggior successo partono da tutt’altro punto. Cominciano col dare ascolto.

Quali sono le preoccupazioni alla base dell’iniziativa? L’obiettivo è la conformità normativa? La continuità operativa? La residenza dei dati? Il controllo operativo? La protezione contro le perturbazioni geopolitiche? Risposte diverse portano ad architetture diverse. Potrebbe sembrare ovvio, ma è sorprendente quanto spesso le organizzazioni inizino a valutare le soluzioni prima ancora di aver concordato l’obiettivo aziendale che intendono raggiungere.

Anteprima: Partite dal rischio, non dalle ipotesi

Uno dei momenti più concreti della nostra conversazione si verifica quando Thomas ed io discutiamo del motivo per cui le iniziative in materia di sovranità dovrebbero partire da una valutazione dei rischi – e non da uno schema architettonico.

Ogni organizzazione ha una propensione al rischio diversa. Una scuderia di Formula 1, un ente governativo e un’azienda manifatturiera globale non prenderanno le stesse decisioni, né dovrebbero farlo. La chiave sta nel capire quali rischi sono più rilevanti per la propria attività, quali compromessi si è disposti ad accettare e, quindi, progettare un’architettura che supporti tali decisioni.

Come sottolinea Thomas, non esiste una soluzione perfetta, ma solo compromessi consapevoli. Quanto prima le organizzazioni adotteranno questa mentalità, tanto più solida sarà la loro strategia di sovranità.

«Cloud o on-premises?» è la domanda sbagliata da porsi

Uno degli aspetti più interessanti della conversazione ha messo in discussione un altro luogo comune, ovvero che le organizzazioni debbano scegliere tra un cloud pubblico e uno privato. Thomas ha descritto una realtà ben diversa. Molte organizzazioni non stanno sostituendo l’uno con l’altro. Stanno progettando ambienti in cui i carichi di lavoro possano spostarsi da uno all’altro in base alle esigenze aziendali, ai requisiti normativi o a considerazioni relative alla resilienza.

Tale flessibilità cambia il modo in cui dovremmo concepire l’architettura. Anziché chiedersi se sia meglio il cloud o l’on-premises, la domanda più utile diventa: “Dove appartiene oggi questo carico di lavoro – e quella risposta potrebbe cambiare domani?” Quando la sovranità entra a far parte del processo di progettazione, la mobilità dei carichi di lavoro assume la stessa importanza del loro posizionamento.

L’architettura è solo una parte dell’equazione

Un altro spunto che apprezzo è il richiamo di Thomas al fatto che l’architettura da sola non risolve la questione della sovranità.

  • I contratti sono importanti.
  • I quadri giuridici sono importanti.
  • I processi operativi sono importanti.
  • Le persone incaricate di gestire l’ambiente sono fondamentali.

Nessuna di queste discipline può operare in modo isolato. La sovranità richiede che i team legali, di sicurezza, di conformità e di infrastrutture collaborino fin dall’inizio, anziché passarsi i progetti l’uno all’altro solo dopo che le decisioni sono già state prese. È uno schema ben noto a chiunque lavori nel settore della resilienza informatica. I risultati migliori raramente provengono da singoli team, ma da quelli che operano in modo coordinato.

Il rischio dovrebbe guidare ogni decisione

Verso la fine della nostra discussione, il discorso si è spostato naturalmente sul rischio. Per me, è qui che la sovranità comincia a sembrarmi molto più familiare. Ogni progetto di resilienza inizia chiedendosi cosa l’organizzazione stia cercando di proteggere, quali siano le minacce più rilevanti e quanto rischio sia disposta ad accettare.

Lo stesso vale per la sovranità digitale. Anziché cercare una soluzione perfetta, le organizzazioni devono individuare gli scenari specifici relativi alla sovranità che destano loro preoccupazione e quindi stabilire quali controlli architetturali, operativi o contrattuali siano più adatti a gestire tali rischi. È proprio questo passaggio – dal confronto delle caratteristiche alla gestione del rischio – che, in ultima analisi, porta a decisioni migliori.

Perché questa discussione è importante

La sovranità digitale continua a evolversi rapidamente. Emergeranno nuove normative. La tecnologia cambierà. Le realtà geopolitiche continueranno a mutare. Ciò significa che la sovranità non è una questione che le organizzazioni risolvono una volta per tutte. È un aspetto che valutano regolarmente man mano che le priorità aziendali e i rischi esterni si evolvono.

Le organizzazioni che avranno successo non saranno necessariamente quelle con le architetture più rigide. Saranno invece quelle che avranno una visione più chiara dei propri obiettivi aziendali, la disciplina necessaria per valutare i rischi in modo ponderato e la flessibilità per adattarsi man mano che tali rischi cambiano. In definitiva, la sovranità digitale non è qualcosa che le organizzazioni possano acquistare già pronta. Si tratta piuttosto di un processo volto a comprendere i rischi, gestire le dipendenze e operare scelte ponderate ben prima che tali decisioni vengano messe alla prova.

Guarda l’episodio completo

In questa puntata di STRIVE, Thomas e io parliamo di:

  • Perché il concetto di sovranità assume significati diversi a seconda delle organizzazioni.
  • Come i dirigenti dovrebbero affrontare la strategia in materia di sovranità.
  • Cloud pubblico contro cloud privato – e perché spesso non si tratta di una scelta esclusiva.
  • Perché la gestione del rischio dovrebbe guidare le scelte architetturali.
  • Il ruolo della resilienza nella pianificazione della sovranità moderna.

Guardalo subito.

Domande frequenti

D: La sovranità digitale significa conservare tutto in locale?

R: No. Molte organizzazioni adottano approcci ibridi che conciliano le funzionalità del cloud con specifici requisiti di sovranità.

D: Da dove dovrebbero partire i progetti di sovranità?

R: Prima di valutare la tecnologia, inizia definendo il problema aziendale e comprendendo i rischi che stai cercando di mitigare.

D: La sovranità è una questione puramente tecnica?

A: No. Richiede la collaborazione tra i team legali, di conformità, di sicurezza, operativi e di architettura.

D: In che modo la sovranità è collegata alla resilienza?

R: Entrambe le discipline mirano a garantire la continuità operativa riducendo l’esposizione ai rischi che potrebbero compromettere l’attività aziendale.

D: Qual è uno dei principali errori che le organizzazioni commettono in materia di sovranità digitale?

R: Affrettarsi a prendere decisioni architetturali prima di aver concordato cosa significhi la sovranità per la propria organizzazione.

D: Qual è la prima domanda che i dirigenti dovrebbero porsi quando si tratta di pianificare la sovranità digitale?

A: «Quale problema stiamo cercando di risolvere?» Tutto il resto deriva da quella risposta.

Darren Thomson è vicepresidente e direttore tecnico (CTO) per l’area EMEA presso Commvault.

Altri post correlati


Thumbnail_Blog_Ready-or-Not-Ep5-Data

Dati: quando «troppo» diventa «mai abbastanza»

Per saperne di più su Dati: quando «troppo» diventa «mai abbastanza»
Thumbnail_Blog_Ready-or-Not-Ep5-Data

Dati: quando “troppo” diventa “mai abbastanza”

Per saperne di più su "Dati: quando troppo diventa mai abbastanza"
Thumbnail_Blog_Ransomware-Trends-2025-1

Perché i rischi informatici moderni richiedono una resilienza informatica completa

Per saperne di più su Perché i rischi informatici moderni richiedono una resilienza informatica a 360 gradi