Governance delle regioni cloud per GDPR, NIS2 e DORA

Alle 08:17 di un martedì mattina, Maria, CISO di una fintech europea in rapida crescita, riceve il messaggio che, prima o poi, ogni cliente cloud regolamentato teme.

Il team acquisti inoltra una breve comunicazione del fornitore:

“Il nostro provider di analisi cloud sta spostando la telemetria dei clienti UE verso una nuova regione per motivi di prestazioni. Dicono che non vi sia alcun impatto sulla sicurezza. Possiamo approvare?”

Prima che Maria possa rispondere, arriva una seconda notifica dal principale fornitore di servizi cloud. Entro 90 giorni, il fornitore “ottimizzerà il proprio modello globale di supporto” instradando i ticket di supporto di secondo livello tramite un nuovo sub-responsabile. Un rapido riesame mostra che il sub-responsabile ha sede in un paese privo di una decisione di adeguatezza ai sensi del GDPR.

Alle 09:00, legale, privacy, resilienza, acquisti, ingegneria cloud e conformità finanziaria sono già nella conversazione. Il DPO chiede se sia necessaria una valutazione d’impatto sul trasferimento. Il responsabile della resilienza chiede se la nuova regione incida sul piano di ripristino di un servizio critico. Il referente della conformità finanziaria chiede se il fornitore compaia nel registro DORA delle terze parti ICT. Il team cloud verifica il data plane di produzione e capisce che il problema è più ampio dell’analisi. Backup, log operativi, ticket di supporto, esportazioni del data lake, accesso di emergenza e accesso dei subappaltatori potrebbero rientrare tutti nell’ambito di applicazione.

Questo è il vero problema della governance cloud nel 2026.

La maggior parte delle organizzazioni dispone di una policy cloud. Molte hanno un registro dei fornitori. Alcune hanno una valutazione dei trasferimenti GDPR. Meno organizzazioni sanno rispondere, con evidenze, alla domanda di audit più difficile:

Dove risiedono esattamente i dati regolamentati e il trattamento ICT critico, chi può accedervi e da dove, cosa accade durante il failover e quale controllo contrattuale impedisce al fornitore di modificare la risposta senza approvazione?

Questa è la governance delle regioni cloud. Non è una singola casella legale da spuntare. È un sistema di controllo dinamico che attraversa ISO/IEC 27001:2022, i controlli cloud e sui fornitori di ISO/IEC 27002:2022, la responsabilizzazione GDPR, la resilienza dei servizi NIS2 e la vigilanza DORA sulle terze parti ICT.

La residenza dei dati è ormai un controllo operativo

Per anni, l’“hosting solo nell’UE” è stato trattato come una clausola in un accordo sul trattamento dei dati. Non è più sufficiente. Un programma moderno di residenza dei dati e governance delle regioni cloud deve coprire almeno sei livelli operativi:

1. Regioni primarie di archiviazione ed elaborazione in produzione.
2. Regioni di backup, archiviazione e disaster recovery.
3. Ubicazioni dei dati di logging, monitoraggio, SIEM e osservabilità.
4. Accesso di supporto, inclusi amministrazione remota e accesso di emergenza.
5. Sub-responsabili e subappaltatori, inclusi servizi gestiti e componenti marketplace.
6. Percorsi di trasferimento dei dati tra ambienti, API, piattaforme di analisi e strumenti di supporto clienti.

Il GDPR rende questo aspetto inevitabile perché i dati personali possono includere identificativi online, indirizzi IP, ID degli account cliente, registrazioni degli utenti, identificativi dei dispositivi, metadati operativi e registrazioni di supporto. Anche il trattamento è definito in modo ampio e include archiviazione, accesso, uso, divulgazione, cancellazione e distruzione. “Inviamo solo log” non è un’eccezione sicura se quei log contengono identificativi.

Il GDPR Article 5 include anche il principio di responsabilizzazione. I titolari del trattamento non devono soltanto rispettare i principi di liceità, correttezza, trasparenza, limitazione delle finalità, minimizzazione dei dati, limitazione della conservazione, integrità e riservatezza. Devono anche essere in grado di dimostrare la conformità. La governance delle regioni cloud è uno dei modi in cui tale dimostrazione diventa concreta.

NIS2 estende il tema dalla privacy alla resilienza. Ai sensi dell’Article 21, i soggetti essenziali e importanti devono attuare misure tecniche, operative e organizzative adeguate per gestire i rischi per i sistemi informativi e di rete utilizzati per le operazioni o l’erogazione dei servizi. Le misure elencate includono sicurezza della catena di fornitura, continuità operativa, gestione dei backup, disaster recovery, gestione delle crisi, controllo degli accessi, gestione degli asset, cifratura e valutazione dell’efficacia. Se una decisione sulla regione cloud incide sulla disponibilità o sul ripristino di un servizio nell’ambito di applicazione, non è solo una questione di protezione dei dati. È una questione di resilienza.

Per le entità finanziarie, DORA innalza ulteriormente lo standard. DORA si applica dal 17 gennaio 2025 e stabilisce requisiti per la gestione dei rischi ICT, la segnalazione degli incidenti, i test di resilienza operativa digitale, la gestione del rischio di terze parti ICT e gli accordi contrattuali. L’Article 28 richiede alle entità finanziarie di gestire il rischio di terze parti ICT come parte integrante del quadro di gestione del rischio ICT, mantenere registri degli accordi contrattuali, valutare il rischio di concentrazione e pianificare l’uscita per funzioni critiche o importanti. L’Article 30 richiede chiarezza contrattuale su ubicazioni del servizio e del trattamento dei dati, diritto di audit e di accesso, supporto agli incidenti, subappalto, ripristino, restituzione e transizione in uscita.

DORA opera come regime settoriale specifico per le entità finanziarie, mentre NIS2 resta rilevante lungo la catena di fornitura più ampia, in particolare per fornitori di servizi di cloud computing, provider di data center e fornitori di servizi gestiti. Un singolo sub-responsabile non valutato può quindi creare un effetto domino tra resilienza finanziaria, sicurezza della catena di fornitura e obblighi privacy.

In termini semplici, se un’azienda regolamentata non può governare dove avviene il trattamento cloud, non può governare in modo credibile il rischio di terze parti ICT.

Usare ISO 27001 come ancoraggio del sistema di gestione

ISO/IEC 27001:2022 fornisce la struttura per trasformare la confusione sulla residenza dei dati in un sistema di gestione controllato.

Le clausole 4.1-4.4 richiedono all’organizzazione di definire il SGSI nel proprio contesto, inclusi fattori interni ed esterni, requisiti delle parti interessate, obblighi legali, normativi e contrattuali, interfacce e dipendenze con altre organizzazioni. Per la governance delle regioni cloud, il campo di applicazione del SGSI deve includere esplicitamente servizi cloud, trattamento ICT esternalizzato, dipendenze da servizi critici e flussi di dati regolamentati.

Le clausole 5.1-5.3 rendono responsabile la leadership. L’alta direzione deve allineare la politica per la sicurezza delle informazioni e gli obiettivi alla direzione strategica, fornire risorse, assegnare responsabilità e assicurare che le prestazioni del SGSI siano oggetto di reporting. È qui che la residenza dei dati nel cloud diventa un tema di gestione e di consiglio di amministrazione, in particolare per i soggetti NIS2, nei quali gli organi di gestione devono approvare e vigilare sulle misure di gestione del rischio di cibersicurezza, e per le entità finanziarie DORA, nelle quali l’organo di gestione è responsabile della governance del rischio ICT.

Le clausole 6.1.1-6.1.3 forniscono il motore del rischio. L’organizzazione necessita di un processo ripetibile di valutazione del rischio, titolari del rischio, criteri di impatto e probabilità, opzioni di trattamento, controlli selezionati, una Dichiarazione di Applicabilità e accettazione del rischio residuo. Una modifica della regione cloud non deve essere approvata tramite una e-mail informale. Deve attivare una valutazione del rischio o un riesame della modifica quando incide su dati regolamentati, funzioni critiche, fornitori o assunzioni di continuità.

La clausola 8.1 trasforma la pianificazione in controllo operativo. I processi devono essere attuati, controllati, documentati, modificati in modo gestito ed estesi a prodotti e servizi forniti esternamente rilevanti per il SGSI. Le clausole 8.2 e 8.3 richiedono rivalutazione e trattamento a intervalli pianificati o quando si verificano modifiche significative. Migrazione di una regione cloud, replica dei backup, nuova piattaforma di logging o modifica di un sub-responsabile del supporto sono tutti candidati alla rivalutazione.

Il set di controlli ISO/IEC 27002:2022 fornisce poi la famiglia di controlli operativi. I controlli più rilevanti includono:

• 5.9 Inventario delle informazioni e degli altri asset associati.
• 5.14 Trasferimento delle informazioni.
• 5.15 Controllo degli accessi.
• 5.19 Sicurezza delle informazioni nei rapporti con i fornitori.
• 5.20 Gestione della sicurezza delle informazioni negli accordi con i fornitori.
• 5.22 Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori.
• 5.23 Sicurezza delle informazioni per l’uso dei servizi cloud.
• 5.29 Sicurezza delle informazioni durante le interruzioni.
• 5.30 Prontezza ICT per la continuità operativa.
• 5.31 Requisiti legali, statutari, normativi e contrattuali.
• 5.34 Privacy e protezione dei dati personali identificabili.
• 5.36 Conformità a politiche, regole e standard per la sicurezza delle informazioni.
• 8.11 Mascheramento dei dati.
• 8.12 Prevenzione della perdita di dati.
• 8.13 Backup delle informazioni.
• 8.15 Registrazione degli eventi.
• 8.16 Attività di monitoraggio.
• 8.20 Sicurezza delle reti.
• 8.24 Uso della crittografia.
• 8.25 Ciclo di vita dello sviluppo sicuro.
• 8.27 Architettura di sistema sicura e principi di ingegneria.
• 8.32 Gestione delle modifiche.

Zenith Controls: The Cross-Compliance Guide di Clarysec Zenith Controls tratta il controllo ISO/IEC 27002:2022 5.23, Sicurezza delle informazioni per l’uso dei servizi cloud, come controllo preventivo a supporto di riservatezza, integrità e disponibilità, con capacità operativa nella sicurezza dei rapporti con i fornitori e nei domini di sicurezza relativi a governance, ecosistema e protezione. La guida collega 5.23 a 5.19 rapporti con i fornitori, 5.14 trasferimento delle informazioni, 5.9 inventario degli asset, 8.11 e 8.12 mascheramento dei dati e prevenzione della perdita di dati, 8.20 sicurezza della rete e 8.25 ciclo di vita dello sviluppo sicuro.

Un’osservazione chiave di Zenith Controls è:

“I fornitori di servizi cloud (CSP) operano come fornitori critici e, pertanto, si applicano tutti i controlli relativi alla selezione dei fornitori, alla contrattualizzazione e alla gestione del rischio previsti dal 5.19. Tuttavia, il 5.23 va oltre, affrontando rischi specifici del cloud, quali multi-tenancy, trasparenza sull’ubicazione dei dati e modelli di responsabilità condivisa.”

Questa frase cattura il cambio di governance. Un cloud provider non è semplicemente un altro fornitore. È spesso il luogo in cui risiede il trattamento regolamentato.

Le trappole nascoste della residenza dei dati: backup, log, supporto e sub-responsabili

La maggior parte dei fallimenti della residenza dei dati non inizia dal database di produzione. Inizia dai sistemi di supporto che non sono mai stati inclusi correttamente nel riesame dei flussi di dati.

I backup sono l’esempio classico. Una piattaforma SaaS può essere eseguita a Francoforte o Dublino, mentre i backup automatizzati vengono replicati altrove per ragioni di resilienza o costo. Se il backup contiene dati personali, registrazioni dei clienti, log di autenticazione o cronologia delle transazioni regolamentate, la regione di backup è rilevante. Ai sensi di NIS2 Article 21, la gestione dei backup e il disaster recovery fanno parte della baseline di sicurezza. Ai sensi di DORA, la continuità delle funzioni critiche o importanti e le strategie di uscita testate richiedono conoscenza delle ubicazioni e delle dipendenze di ripristino.

I log sono un altro punto debole. I team di sicurezza centralizzano la telemetria in servizi SIEM, di osservabilità e data lake. Tali log possono includere indirizzi IP, identificativi utente, azioni degli amministratori, metadati di pagamento, tentativi di autenticazione non riusciti, ID degli account cliente o dati di tracciamento del supporto. Se i log vengono trasferiti in un servizio di monitoraggio globale, l’organizzazione può aver creato un trasferimento transfrontaliero senza rendersene conto.

La Logging and Monitoring Policy-sme di Clarysec Logging and Monitoring Policy - SME affronta direttamente le evidenze dei fornitori:

“I contratti devono richiedere ai fornitori di conservare i log per almeno 12 mesi e di fornire accesso su richiesta”

Questa citazione proviene dalla sezione “Requisiti di governance”, clausola della policy 5.5.1.3. Per la governance della residenza dei dati, lo stesso riesame contrattuale deve confermare dove tali log sono conservati, chi può accedervi e se l’evidenza dei log è disponibile durante un’indagine su un incidente o una richiesta dell’autorità di regolamentazione.

L’accesso di supporto è più sottile. Un fornitore può ospitare i dati nell’UE, mentre gli ingegneri di supporto fuori dall’UE possono accedere ad ambienti cliente, snapshot di database, pacchetti diagnostici o allegati dei ticket. L’accettabilità dipende dai dati coinvolti, dal meccanismo di trasferimento, dal ruolo, dalle misure contrattuali di protezione, dai controlli di accesso e dalla registrazione degli eventi. L’architettura può essere regionale, mentre il modello di accesso umano è globale.

I sub-responsabili creano l’ultimo punto cieco. Il tuo fornitore diretto può dipendere da infrastruttura cloud, content delivery network, database gestiti, piattaforme di ticketing, servizi di analisi, team di supporto offshore o fornitori di sicurezza. DORA Article 29 richiede la valutazione dei rischi di subappalto, dei fornitori di paesi terzi, dei vincoli di recupero dei dati, della conformità alla protezione dei dati e delle catene complesse di subappalto. NIS2 Article 21 richiede ai soggetti di considerare le pratiche di cibersicurezza dei fornitori diretti e dei prestatori di servizi. Il GDPR richiede ai responsabili del trattamento di gestire i sub-responsabili in modo da preservare la capacità del titolare del trattamento di essere conforme.

La Third-Party and Supplier Security Policy-sme di Clarysec Third-Party and Supplier Security Policy - SME rende operativo questo punto:

“Quando ai fornitori è richiesto di archiviare dati fuori sede, l’azienda deve ottenere garanzie in merito a protezione dei dati, sicurezza fisica e ubicazione geografica dello storage (ad esempio, hosting solo nell’UE ove richiesto dal GDPR).”

Questo proviene dalla sezione “Requisiti di applicazione della policy”, clausola della policy 6.2.4. La stessa policy richiede inoltre:

“Restrizioni a ulteriore subappalto senza approvazione”

Questa citazione proviene dalla sezione “Requisiti di governance”, clausola della policy 5.3.5. Insieme, queste clausole trasformano la residenza dei dati in un workflow di gestione dei fornitori, non in una preferenza di acquisto.

Trasformare la policy in governance applicabile delle regioni cloud

La governance delle regioni cloud deve essere applicabile, riesaminabile e verificabile in audit.

Per le PMI, la Cloud Usage Policy-sme Cloud Usage Policy - SME definisce la baseline:

“Le pratiche di residenza dei dati e privacy sono conformi ai requisiti legali applicabili (ad esempio, GDPR)”

Questo proviene dalla sezione “Requisiti di governance”, clausola della policy 5.2.3. La stessa policy richiede che le registrazioni di governance cloud includano:

“Il paese o la regione in cui i dati sono archiviati”

Questa citazione proviene dalla sezione “Requisiti di governance”, clausola della policy 5.3.4.

Per le organizzazioni più grandi, la Cloud Usage Policy Cloud Usage Policy è più esplicita sull’applicazione contrattuale:

“I requisiti di residenza dei dati devono essere applicati contrattualmente (ad esempio, storage solo nell’UE per dati regolamentati dal GDPR).”

Questo proviene dalla sezione “Requisiti di applicazione della policy”, clausola della policy 6.6.2. La policy afferma inoltre:

“I trasferimenti transfrontalieri di dati devono rispettare il GDPR Chapter V e, ove applicabile, DORA Article 28.”

Questo proviene dalla sezione “Requisiti di applicazione della policy”, clausola della policy 6.6.3.

La versione enterprise assegna inoltre attenzione a:

“Garanzie di residenza dei dati e titolarità dei dati”

Questa citazione proviene dalla sezione “Ruoli e responsabilità”, clausola della policy 4.5.1.2.

La Third party and supplier security policy Third party and supplier security policy aggiunge il livello contrattuale richiedendo:

“Requisiti di gestione dei dati, inclusi ubicazione dello storage, controlli di accesso e clausole di restituzione o distruzione”

Questa citazione proviene dalla sezione “Requisiti di governance”, clausola della policy 5.3.2.

Infine, la Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy identifica le modifiche che devono attivare un riesame di conformità, incluse:

“Modifiche ai meccanismi di trasferimento dei dati, ai sub-responsabili o ai flussi di dati transfrontalieri”

Questo proviene dalla sezione “Requisiti di governance”, clausola della policy 5.3.1.1.

Questi documenti non devono operare come file separati. In un SGSI maturo, diventano un unico modello operativo: inventario cloud, registro dei flussi di dati, registro dei fornitori, matrice contrattuale, valutazione del rischio, riesame dei trasferimenti, approvazione delle modifiche e pacchetto di evidenze di audit.

Costruire un registro di governance delle regioni cloud

Un registro operativo trasforma la residenza dei dati da assunzione a evidenza. Parti da un servizio critico rivolto ai clienti, in particolare uno che potrebbe rientrare nell’ambito di NIS2, della due diligence dei clienti DORA o di una verifica GDPR.

Ora collega il registro all’attuazione.

In Zenith Blueprint: An Auditor’s 30-Step Roadmap di Clarysec Zenith Blueprint, la fase Controls in Action, Step 23, si concentra sui controlli organizzativi da 5.19 a 5.37, inclusi accordi con i fornitori e governance dei servizi cloud. Il Blueprint avverte che gli accordi con i fornitori devono coprire più della riservatezza generica:

“In molti settori, gli accordi con i fornitori definiscono anche titolarità dei dati e giurisdizione. Dove sono trattati i dati? Chi mantiene il controllo? Esistono restrizioni ai trasferimenti? Esistono controlli specifici del cloud, come segmentazione dei dati, titolarità delle chiavi o limitazioni geografiche? Questi elementi non sono solo legali: sono temi di sicurezza operativa, soprattutto nei settori regolamentati.”

La stessa fase e lo stesso step affrontano la gestione delle modifiche dei fornitori:

“La maggior parte dei rapporti con i fornitori inizia con buone intenzioni. Un riesame approfondito, aspettative chiare, accordi firmati (vedere 5.20), forse persino una checklist di sicurezza. Ma cosa succede un anno dopo, quando il fornitore propone di spostare i tuoi dati in una nuova regione cloud?”

Questo è il problema del martedì mattina di Maria. Il registro offre al CISO un modo per rispondere prima di approvare lo spostamento.

Il Zenith Blueprint chiarisce inoltre il significato di governance del controllo cloud 5.23:

“Un bucket di storage configurato in modo errato, una dashboard esposta pubblicamente o autorizzazioni eccessive in una configurazione IAM cloud non sono fallimenti del cloud. Sono fallimenti della governance.”

Nella fase Controls in Action, Step 22, il Blueprint affronta il trasferimento delle informazioni e afferma:

“Se dati personali vengono trasferiti oltre confine, il metodo deve rispettare gli obblighi privacy e legali, non solo le preferenze interne.”

Questa frase è importante per i team cloud. Cifratura, API sicure e connettività privata sono necessarie, ma non sostituiscono la governance legale e normativa dei trasferimenti.

Condurre il primo workshop di 90 minuti sulle evidenze

Non iniziare mappando l’intera organizzazione. Parti da un servizio critico e conduci un workshop mirato con ingegneria cloud, acquisti, legale, privacy, resilienza e operazioni di sicurezza.

Per prima cosa, elenca ogni componente cloud o del fornitore che archivia, tratta, trasmette, sottopone a backup, monitora o supporta il servizio. Includi sistemi minori come monitoraggio dell’uptime, allegati dei ticket, tracciamento degli errori, strumenti di condivisione schermo per il supporto ed esportazioni diagnostiche.

Secondo, contrassegna ogni categoria di dati. Se il team dice “solo metadati”, metti in discussione l’assunzione. I metadati possono comunque essere dati personali o dati riservati dei clienti.

Terzo, verifica la regione sulla base delle evidenze. Usa configurazioni della console cloud, policy di backup, impostazioni della tenancy SIEM, allegati DPA, elenchi dei sub-responsabili, termini contrattuali, documentazione sull’accesso di supporto e rapporti di audit CSP. Non fare affidamento solo sulle rassicurazioni commerciali.

Quarto, registra le lacune nel registro dei rischi del SGSI. Esempi includono “regione di replica dei backup non limitata contrattualmente”, “accesso di supporto da paese terzo privo di workflow di approvazione documentato”, “log SIEM conservati globalmente”, “elenco dei sub-responsabili non identifica la regione di hosting” oppure “il registro DORA non distingue la dipendenza da funzione critica o importante”.

Quinto, decidi il trattamento. I trattamenti possono includere modifica contrattuale, blocco della regione, notifica al cliente, cifratura con chiavi gestite dal cliente, tokenizzazione, minimizzazione dei log, approvazione di un nuovo fornitore, aggiornamento della strategia di uscita o accettazione del rischio residuo da parte del titolare del rischio.

Sesto, conserva le evidenze. Gli auditor non chiederanno solo cosa è stato deciso. Chiederanno come sai che è stato attuato.

Mappare un set di evidenze a ISO, GDPR, NIS2, DORA e NIST CSF 2.0

Un programma solido di governance delle regioni cloud evita lavoro duplicato di conformità. Le stesse evidenze possono supportare più obblighi se sono strutturate correttamente.

NIST CSF 2.0 è utile come livello di integrazione. La sua funzione GOVERN si allinea a obblighi legali, normativi, contrattuali e privacy, propensione al rischio, responsabilizzazione, policy e supervisione. La categoria GV.SC supply chain si mappa bene alle aspettative DORA sulle terze parti ICT, ai requisiti NIS2 di catena di fornitura e ai controlli ISO sui fornitori.

COBIT 2019 e una lente di audit ISACA spesso verificano gli stessi fatti attraverso obiettivi di governance: titolarità, diritti decisionali, ottimizzazione del rischio, prestazioni dei fornitori, realizzazione dei benefici e assurance. Un revisore in stile COBIT potrebbe non iniziare con “quale regione cloud è configurata?” Potrebbe iniziare con “chi ha l’autorità di approvare una modifica di regione, come viene effettuata l’escalation del rischio e come sa la direzione che i fornitori cloud restano entro la tolleranza?”

Per questo il modello Clarysec acquisisce proprietari, punti di approvazione, evidenze contrattuali e reporting verso la direzione, non solo impostazioni tecniche.

Prepararsi alle domande dell’auditor

La governance delle regioni cloud è un esempio perfetto di come auditor diversi osservino lo stesso controllo da angolazioni diverse.

Un auditor ISO/IEC 27001:2022 inizierà da campo di applicazione, requisiti delle parti interessate, valutazione del rischio e Dichiarazione di Applicabilità. Chiederà se i requisiti legali, normativi e contrattuali sono identificati, se i controlli cloud e sui fornitori sono inclusi, se i rischi sono stati valutati, se i controlli sono attuati e se le evidenze sono conservate. Potrebbe campionare un servizio cloud e chiedere il riesame di onboarding, le clausole contrattuali, la configurazione della regione, il riesame del monitoraggio e l’approvazione della modifica.

Un’autorità di controllo per la protezione dei dati o un revisore GDPR si concentrerà sui dati personali. Chiederà quali dati personali sono trattati, dove sono archiviati, da dove vi si accede, quali responsabili del trattamento e sub-responsabili sono coinvolti, se i meccanismi di trasferimento sono documentati, se è necessaria una valutazione d’impatto sul trasferimento e se sono in atto misure tecniche e organizzative adeguate. Log, dati di supporto e backup ricevono spesso attenzione perché le organizzazioni li sottovalutano.

Un auditor NIS2 o un’autorità competente si concentrerà sui servizi nell’ambito di applicazione. Esaminerà la responsabilità della direzione ai sensi dell’Article 20, le misure di gestione del rischio ai sensi dell’Article 21, continuità, gestione dei backup, disaster recovery, gestione degli incidenti, sicurezza della catena di fornitura, controllo degli accessi, gestione degli asset e valutazione dell’efficacia.

Un’autorità di vigilanza DORA o un gruppo di audit interno cercherà governance del rischio ICT, vigilanza dell’organo di gestione, registro delle informazioni per gli accordi con terze parti ICT, mappatura delle funzioni critiche o importanti, rischio di concentrazione, rischio di subappalto, ubicazioni del trattamento dei dati, diritto di audit, supporto alla segnalazione degli incidenti, test di continuità e piani di uscita. DORA è chiaro: l’esternalizzazione non trasferisce la responsabilità.

Zenith Controls aiuta i responsabili della sicurezza a prepararsi a questi stili di audit perché mette in relazione i controlli tra loro. Per il controllo ISO/IEC 27002:2022 5.20, Gestione della sicurezza delle informazioni negli accordi con i fornitori, Zenith Controls lo collega a 5.19 rapporti con i fornitori, 5.14 trasferimento delle informazioni, 5.22 monitoraggio dei fornitori, 5.11 restituzione degli asset e 5.36 conformità a politiche, regole e standard. Per il controllo 5.22, Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori, collega la vigilanza continuativa sui fornitori a 5.29 sicurezza durante le interruzioni, 8.8 gestione delle vulnerabilità tecniche, 5.15 controllo degli accessi, 8.27 architettura di sistema sicura e principi di ingegneria e 5.36 conformità.

Questa vista trasversale dei controlli è rilevante perché una modifica di regione non è mai solo una modifica di regione. Può alterare il rischio del fornitore, il rischio di trasferimento, il rischio di accesso, il rischio di continuità, le evidenze di risposta agli incidenti e la conformità contrattuale.

Usare questa checklist CISO 2026 prima di approvare una modifica cloud

Usa questa checklist prima di approvare qualsiasi nuova regione cloud, percorso di trattamento transfrontaliero, ubicazione di backup, piattaforma di logging, modello di supporto o modifica critica di un fornitore ICT.

Se la risposta a qualsiasi domanda è “lo presumiamo”, il controllo non è sufficientemente maturo per operazioni regolamentate.

La roadmap di remediation

Il percorso di remediation è pratico quando è ancorato al SGSI.

1. Confermare che il campo di applicazione del SGSI includa servizi cloud, dipendenze ICT critiche e trattamento di dati regolamentati.
2. Costruire il registro di governance delle regioni cloud per i servizi prioritari.
3. Mappare ogni servizio a categorie di dati, regioni, ubicazioni di backup, accesso di supporto e sub-responsabili.
4. Riesaminare gli accordi con i fornitori per clausole su ubicazione dello storage, trasferimento, audit, incidente, subappalto, restituzione e distruzione.
5. Aggiornare il registro dei rischi per lacune, rischi di concentrazione e trasferimenti non documentati.
6. Allineare il registro DORA delle terze parti ICT e la mappatura delle dipendenze di servizio NIS2 ove applicabile.
7. Convalidare l’applicazione tecnica, inclusi blocchi di regione, policy di backup, impostazioni di logging, cifratura, controlli di accesso e gestione delle chiavi.
8. Preparare un pacchetto di evidenze di audit con screenshot, contratti, registrazioni dei rischi, approvazioni, verbali di riesame e risultati dei test.
9. Stabilire un trigger di modifica per nuove regioni, sub-responsabili, meccanismi di trasferimento o modifiche critiche ai servizi dei fornitori.
10. Rendicontare alla direzione il rischio di residenza dei dati nel cloud, le eccezioni e le decisioni di accettazione del rischio residuo.

Questa non è conformità teorica. È la differenza tra un parco cloud in grado di superare il controllo di audit e uno che dipende da rassicurazioni verbali.

Il business case: sovranità, resilienza e fiducia

I dirigenti talvolta considerano la governance della residenza dei dati come un vincolo all’agilità cloud. In pratica, una governance matura delle regioni migliora l’agilità perché i team conoscono le regole prima di acquistare, costruire o migrare.

Un team di prodotto può lanciare più rapidamente quando le regioni approvate sono chiare. Gli acquisti possono negoziare più rapidamente quando le clausole obbligatorie sono già definite. Il legale può valutare i trasferimenti più rapidamente quando i flussi di dati sono documentati. Le operazioni di sicurezza possono indagare più rapidamente quando sono note le ubicazioni dei log e i diritti di accesso. Il consiglio di amministrazione può assumere decisioni di rischio più rapidamente quando rischio di concentrazione, impatto sulla continuità e accettazione del rischio residuo sono visibili.

Per i clienti, soprattutto quelli regolamentati, questo diventa un segnale di fiducia. Un fornitore SaaS che sa spiegare dove risiedono i dati, come sono governati i backup, come è controllato l’accesso di supporto, come sono approvati i sub-responsabili e come sono riesaminate le modifiche di regione supererà un fornitore che si limita a dire “usiamo un cloud provider leader”.

Nel 2026, questa distinzione conta. NIS2 ha portato la governance della cibersicurezza ai soggetti essenziali e importanti in tutta l’UE. DORA ha reso la vigilanza sulle terze parti ICT una disciplina formale del settore finanziario. La responsabilizzazione GDPR resta centrale. ISO/IEC 27001:2022 fornisce il sistema di gestione che tiene insieme questi elementi.

Prossimi passi con Clarysec

Se la tua organizzazione non sa rispondere a dove risiedono i dati regolamentati e il trattamento ICT critico tra produzione, backup, log, accesso di supporto e subappaltatori, è il momento di colmare la lacuna.

Clarysec può aiutarti a costruire un pacchetto di evidenze per la governance delle regioni cloud usando:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint per un’attuazione ISO per fasi e la preparazione agli audit.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls per mappare i controlli cloud e sui fornitori di ISO/IEC 27002:2022 alle evidenze operative e alle aspettative tra quadri di riferimento.
• Cloud Usage Policy Cloud Usage Policy e Cloud Usage Policy-sme Cloud Usage Policy - SME per i requisiti di residenza dei dati nel cloud.
• Third party and supplier security policy Third party and supplier security policy e Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME per contratti con i fornitori, subappalto e garanzie sull’ubicazione geografica dello storage.
• Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME per conservazione dei log ed evidenze del provider.
• Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy per i trigger di riesame della conformità relativi a meccanismi di trasferimento, sub-responsabili e flussi di dati transfrontalieri.

Inizia con un servizio critico, un cloud provider e un registro. In pochi workshop puoi passare dalle assunzioni alle evidenze, e da una conformità frammentata a una resilienza cloud governata.

Scarica il toolkit Clarysec, richiedi una demo o prenota una valutazione della governance delle regioni cloud per trasformare gli impegni di residenza dei dati nel cloud in evidenze pronte per l’audit.