- Perché cresce il Cloud Repatriation: la visione di Intesys Networking
- I driver del Cloud Repatriation: Governance, Risk e Compliance
- Conformità normativa e sovranità del dato: perché è un fattore chiave
- Il ruolo della rete nella Cloud Repatriation
- Costruire un data center privato “future‑proof” secondo i principi GRC
- Public vs Private Cloud: come governare la scelta in ottica GRC
- Sintesi e conclusioni
Le imprese stanno vivendo un cambiamento significativo nel modo in cui progettano e governano la propria infrastruttura IT. Il fenomeno del cloud repatriation, ovvero il rientro strategico di workload dal cloud pubblico verso data center privati o ambienti ibridi, è sempre più diffuso e spesso guidato da esigenze di governance, conformità e controllo dei costi.
Per approfondire questo tema, abbiamo intervistato Alessandro Caso, Amministratore Delegato di Intesys Networking, che ha condiviso la visione dell’azienda su come la Cloud Repatriation si inserisca nel nuovo paradigma GRC (Governance, Risk & Compliance) e su quali criteri guidano oggi le scelte infrastrutturali delle organizzazioni.
Perché cresce il Cloud Repatriation: la visione di Intesys Networking
Negli ultimi anni abbiamo assistito a un ritorno strategico dal cloud pubblico al data center privato. Come interpreta Intesys Networking questa evoluzione?
Alessandro Caso:
L’adozione massiva del cloud pubblico ha generato inizialmente un’aspettativa di agilità, scalabilità e riduzione dei costi (approfondisci le vere sfide della migrazione al cloud). Tuttavia, la maturità digitale delle organizzazioni sta portando a una visione più analitica e, direi, più governata.
Il fenomeno del cloud repatriation nasce proprio da una revisione critica dei modelli di governance, dei rischi operativi e dei requisiti di compliance. I dati sono chiari: secondo il Private Cloud Outlook 2025 di Broadcom, il 69% delle imprese sta valutando un rientro verso il cloud privato, e un terzo lo ha già avviato. Anche in Italia il trend è evidente: l’Osservatorio Cloud Transformation 2025 parla di un 35% di iniziative di rientro, in forte crescita.
Questa non è una marcia indietro: è un processo di riallineamento tra strategia, rischio e conformità (approfondisci con la nostra Roadmap alla compliance NIS2). E in questo contesto, le direttrici GRC sono centrali (Governance, Risk, Compliance).
I driver del Cloud Repatriation: Governance, Risk e Compliance
Quali sono i principali driver di questo rientro, guardandolo da una prospettiva di Governance, Risk e Compliance?
A. Caso:
Ne identificherei tre, perfettamente allineati a un approccio GRC moderno:
In quest’ottica un data center privato è spesso più efficace.
Le normative NIS2, DORA, ISO 27001 e ISO 20000 richiedono misure dimostrabili e meccanismi di controllo tracciabili. Il cloud pubblico, con modelli di localizzazione dinamica e catene di subfornitura complesse, rende più oneroso garantire piena conformità.
Conformità normativa e sovranità del dato: perché è un fattore chiave
La conformità normativa sembra essere uno dei fattori chiave. Perché?
Alessandro Caso:
Perché le normative europee sono molto chiare: la responsabilità del dato è sempre dell’organizzazione.
Con NIS2 aumentano drasticità delle sanzioni, obblighi di reporting, audit e resilienza.
Con DORA, nel settore finanziario, diventano vincolanti la continuità operativa, la segregazione, la tracciabilità e la governance dell’outsourcing ICT.
Nel cloud pubblico, la localizzazione fisica dei dati non è sempre garantita e la catena di responsabilità è più articolata.
In un data center privato possiamo implementare:
- controlli fisici e logici in linea con ISO 27001 (A.7, A.8, A.9)
- processi di gestione del servizio conformi a ISO 20000
- retention policy e criteri di sovranità allineati ai requisiti europei
- audit trail completo, fondamentale per DORA e NIS2
Il risultato è una conformità più semplice, solida e verificabile.
Il ruolo della rete nella Cloud Repatriation
La rete gioca un ruolo fondamentale in questo processo di “repatriation”. Come la vede Intesys Networking?
Alessandro Caso:
La rete è la colonna vertebrale di qualsiasi strategia di rientro.
Rendere un data center parte integrante dell’enterprise network richiede una progettazione specifica: core switches con doppio ruolo, interconnessione dei Top of Rack, architetture spine‑leaf, resilienza N+1.
Le soluzioni di networking avanzato – come quelle basate su micro‑segmentazione, SDN e automazione – permettono:
- prestazioni elevate
- sicurezza by design
- riduzione del rischio operativo
- piena visibilità e tracciabilità
- integrazione semplificata verso ambienti ibridi
Sono principi abilitanti della ISO 27001 e prerequisiti funzionali per la NIS2.
Costruire un data center privato “future‑proof” secondo i principi GRC
Come si costruisce oggi un data center privato “future‑proof” secondo i framework GRC?
Alessandro Caso:
Servono tre elementi:
1. Una governance chiara
Allineare strategia, ruoli, processi e controllo degli asset ICT alle best practice di ISO 27001 e ISO 20000.
2. Una gestione del rischio continua
Integrare processi di risk assessment dinamici, valutazione di impatti, test di resilienza e continuità operativa, come richiesto da DORA e NIS2.
3. Un modello di compliance misurabile
Monitoraggio dei KPI, audit periodici, gestione degli incidenti, conformità ai requisiti di sicurezza e disponibilità.
In questo senso, il cloud ibrido – e un data center privato moderno – non sono un ritorno al passato, ma l’evoluzione naturale di un modello di controllo più maturo e coerente con le aspettative normative e di business.
Public vs Private Cloud: come governare la scelta in ottica GRC
In quali casi ha più senso mantenere i workload nel cloud pubblico e in quali, invece, è più opportuno rientrare verso un data center privato o un Private Cloud? Come si governa questa scelta in ottica GRC?
Alessandro Caso:
La vera evoluzione non è scegliere “public” o “private”, ma adottare un approccio di Hybrid Governance guidato da criteri GRC e basato su un’analisi strutturata del rischio, della criticità del servizio e della sensibilità del dato.
In Intesys Networking utilizziamo una matrice che combina:
• sensibilità e classificazione del dato (ISO 27001 – Annex A.5)
• criticità operativa del servizio (DORA e NIS2 – continuità e resilienza)
• requisiti di performance e latenza
• costi e prevedibilità del TCO
• dipendenza dai provider cloud e rischio vendor lock‑in
Sulla base di questi criteri, le categorie si suddividono in modo piuttosto netto.
Workload tipicamente ideali per rimanere in Cloud Pubblico
1. Applicazioni ad alta variabilità di carico
Esempi: portali, e‑commerce, front‑end esposti al pubblico, microservizi elastici.
Motivazione: scalabilità on‑demand e provisioning rapido.
Governance: ISO 20000 (capacity management), DORA (elasticità).
2. Servizi che beneficiano di componenti gestite (PaaS, SaaS)
Esempi: AI generativa, API gateway fully managed, servizi di logging‑as‑a‑service, database serverless.
Motivazione: riduzione del carico operativo e accelerazione del time‑to‑market.
Governance: ISO 27001 A.5 e A.12 (outsourcing e supply chain security).
3. Applicazioni non critiche o non core‑business
Esempi: collaboration suite, ticketing non finanziario, servizi di posta elettronica o CRM non sensibili.
Motivazione: minore impatto in caso di interruzione.
Compliance: requisiti minori di sovranità del dato.
4. Workload geograficamente distribuiti
Esempi: distribuzione applicativa multi‑regione.
Motivazione: riduzione della latenza verso gli utenti finali.
Workload per cui ha più senso rientrare in un Data Center Privato / Private Cloud
1. Dati altamente sensibili o soggetti a localizzazione obbligatoria
Esempi: dati finanziari soggetti a DORA, dati critici di operatori essenziali NIS2, dati proprietari ad alta riservatezza, log tecnici e di sicurezza che non possono uscire dal perimetro.
Motivazione: auditabilità, pieno controllo, tracciabilità.
Riferimento: ISO 27001 A.5, A.8, A.12 (data governance, classification, transfer).
2. Applicazioni critiche a bassa latenza e alta affidabilità
Esempi: trading finanziario, sistemi SCADA/OT, IoT real‑time industriale, piattaforme ERP core, sistemi di monitoraggio industriale o sanitario
Motivazione: il cloud pubblico introduce variabilità di latenza e dipendenza dalla connettività.
3. Workload con costi prevedibili e carichi stabili nel tempo
Esempi: sistemi di back‑end, database persistenti e massivi, repository documentali strutturati.
Motivazione: prevedibilità del TCO e minori costi di storage/egress.
4. Componenti infrastrutturali soggette a forte personalizzazione o integrazione profonda
Esempi: sistemi IAM interni altamente personalizzati, piattaforme API aziendali con policy proprietarie, SIEM/SOC con log retention avanzata, cluster Kubernetes ottimizzati per carichi specifici.
Motivazione: maggiore controllo, compliance e tuning prestazionale.
5. Processi soggetti a requisiti stringenti di audit, segregazione e continuità operativa
Esempi: servizi ICT critici per banche o assicurazioni (DORA),infrastrutture di operatori essenziali (NIS2), processi con forte dipendenza dalla disponibilità (ISO 20000 – service continuity).
Motivazione: la responsabilità dell’ente resta totale e il private semplifica gli audit.
Sintesi e conclusioni
La regola GRC che guida le aziende
Cloud pubblico quando prevale elasticità e time‑to‑market.
Private Cloud quando prevalgono controllo, sicurezza, continuità e prevedibilità dei costi.
Il punto non è scegliere dove mettere tutto, ma mettere ogni cosa nel posto giusto, secondo criteri di governance e rischio misurabili.
Una battuta finale?
Alessandro Caso:
Il futuro non è pubblico o privato: è controllato.
È un ecosistema distribuito dove le aziende mantengono sovranità, sicurezza e capacità decisionale.
Come Intesys Networking lavoriamo proprio per abilitare questo modello: infrastrutture robuste, compliance verificabile, sicurezza continua e governance allineata agli standard internazionali.
