«Il nostro SaaS opera in più regioni» non risponde da solo alla domanda di continuità. I dati possono risiedere in una regione, le copie in un’altra, mentre identità, chiavi, amministrazione o supporto dipendono da un componente comune. Per decidere se il servizio sostiene una funzione aziendale, il cliente deve separare localizzazione dei dati, capacità effettiva di failover, servizi necessari all’accesso e compiti che restano a suo carico. Questa guida offre una scheda di dipendenze regionali per un singolo fornitore SaaS, con domande verificabili e un esempio di decisione.
La mappa della concentrazione cloud di quarta parte cerca cause comuni fra fornitori diversi. Qui il perimetro è diverso: un solo servizio SaaS presentato come multi-regione. La guida NIST SP 1305 aiuta a formulare requisiti di rischio di fornitura e a comunicarli. Per le entità finanziarie cui si applica DORA, gli accordi TIC e le funzioni essenziali o importanti richiedono valutazioni specifiche; la scheda può fornire elementi a quelle valutazioni, ma non rende DORA applicabile a ogni cliente SaaS.
Definire la funzione che il SaaS deve sostenere
Iniziate dall’attività che non deve fermarsi: fatturare, autorizzare pagamenti, ricevere ordini o assistere clienti. Descrivete utenti, dati, integrazioni e conseguenze di un’interruzione. Solo dopo chiedete quali componenti del SaaS sono indispensabili. Un servizio può mantenere disponibili i dati ma impedire nuovi accessi; per un’attività che richiede operatori nuovi, il risultato pratico resta un’interruzione. La mappatura dei sistemi e dei flussi aiuta a collegare servizio, processo e dipendenze interne.
Stabilite il livello di tolleranza con il proprietario della funzione, senza adottare automaticamente l’SLA del fornitore come obiettivo aziendale. Disponibilità percentuale, tempo di ripristino e perdita massima di dati misurano cose diverse. Un SLA può descrivere credito commerciale dopo un disservizio, non la capacità del cliente di riprendere un processo entro la sua scadenza. Annotate quali operazioni possono essere recuperate in seguito e quali no. Questa distinzione orienta le domande al fornitore.
Definite anche la configurazione acquistata. Opzioni multi-regione, replica, esportazione e supporto possono dipendere dal piano, dalla scelta del cliente o da un servizio aggiuntivo. Chiedete una risposta riferita al tenant e al contratto proposti, non alla capacità teorica della piattaforma. Se la configurazione non è ancora stata scelta, registrate le alternative e il requisito da verificare prima della messa in esercizio. Non trasformate una brochure in una prova di attivazione.
La scheda: cinque dimensioni che non coincidono
Organizzate il dossier in cinque sezioni: dati, failover, identità, obblighi del cliente e assistenza. Ogni affermazione deve avere fonte, data e grado di conferma. Una dichiarazione contrattuale può sostenere un impegno, mentre un esercizio mostra comportamento in una condizione specifica. Distinguete ciò che il fornitore ha dimostrato, ciò che ha descritto e ciò che resta una vostra ipotesi.
| Dimensione | Domanda concreta | Prova o limite da registrare |
|---|---|---|
| Dati | Dove risiedono contenuto, copie e metadati? | Descrizione del servizio e configurazione del tenant |
| Failover | Che cosa passa davvero alla seconda regione? | Prova, data, funzioni escluse e tempi osservati |
| Identità | Come accedono utenti e operatori durante il guasto? | Dipendenza da IdP, DNS, chiavi e piano di emergenza |
| Cliente | Quali passaggi deve avviare o mantenere il cliente? | Ruoli, autorizzazioni, dati da esportare e procedure |
| Assistenza | Quale canale resta raggiungibile? | Contatti, escalation e dipendenze della comunicazione |
Non riempite ogni cella con «ridondato». Scrivete per esempio «contenuto replicato, autenticazione dipendente dall’IdP del cliente» o «failover dichiarato dal fornitore, non provato per le integrazioni esterne». Una descrizione precisa rende possibile scegliere una compensazione. Un aggettivo generale non permette di capire che cosa fallirà insieme alla regione primaria.
Localizzazione dei dati: contenuto e accesso
Chiedete dove sono memorizzati dati applicativi, backup, log, metadati e chiavi. Una selezione della regione di hosting può riguardare solo parte di queste categorie. Registrate anche dove il personale di assistenza può accedere, con quali condizioni e per quali finalità. La posizione del server non esaurisce la valutazione dei trasferimenti di dati personali. Se si tratta di dati personali, verificate separatamente ruoli, contratto con il responsabile del trattamento e eventuali trasferimenti secondo GDPR.
Una copia in una seconda regione può ridurre il rischio di perdita, ma non dimostra che l’applicazione possa servirla. Chiedete se la replica è sincrona o asincrona, quale ritardo massimo è previsto, chi seleziona la copia e come si risolvono modifiche parziali. Se il fornitore non comunica un valore preciso, non inventatelo: registrate la lacuna e il metodo con cui la funzione aziendale sopporta un possibile arretrato. Un’esportazione periodica può essere un’ulteriore protezione, ma va testata per integrità e utilizzabilità.
Distingete sovranità, disponibilità e recuperabilità. Dati collocati nell’Unione europea possono dipendere da un’identità globale; dati replicati in più regioni possono non essere recuperabili dal cliente se l’unico account amministrativo è bloccato. Una decisione sulla collocazione soddisfa una domanda di trattamento; una prova di failover risponde a una domanda operativa. La scheda le mette una accanto all’altra proprio per evitare che una sostituisca l’altra.
Failover: la funzione realmente disponibile
Chiedete che cosa avviene quando la regione primaria è isolata. Il passaggio è automatico, manuale o deciso caso per caso dal fornitore? Quali funzioni rimangono attive: lettura, scrittura, importazioni, API, report e amministrazione? Un’istanza può rispondere a richieste di salute mentre i processi principali sono sospesi. Perciò l’esito deve riguardare una transazione rappresentativa della funzione, non soltanto lo stato dell’infrastruttura.
Documentate l’ultima prova rilevante e il suo perimetro. È stata condotta con il servizio e il piano acquistati, oppure con una piattaforma di riferimento? Sono state incluse integrazioni del cliente e gestione delle chiavi? Quali tempi sono stati osservati e quali prerequisiti erano già preparati? Una prova fatta dal fornitore può essere utile, ma descrive il suo perimetro. Il piano di disaster recovery del cliente deve coprire i passaggi che ricadono fuori da esso.
Preparate una domanda di degradazione parziale. Se la prima regione continua a leggere ma non a scrivere, il fornitore come evita conflitti e come informa i clienti? Se il cambio di regione modifica indirizzi, certificati o comportamento delle API, chi aggiorna le integrazioni? Un piano multi-regione progettato per guasti totali può comportarsi diversamente durante errori intermittenti. Annotate ciò che è stato dimostrato e il rischio che resta su scenari non provati.
Identità, chiavi e piano di controllo
Molti percorsi di recupero richiedono autenticazione. Verificate se l’IdP del cliente, il DNS o un portale di amministrazione centralizzato è necessario sia nella regione primaria sia nella secondaria. Un sistema di identità disponibile può comunque non autorizzare utenti in una nuova istanza se gruppi e ruoli non sono sincronizzati. Esercitate un accesso rappresentativo con un utente ordinario e uno amministrativo, senza creare credenziali permanenti eccessive.
Esaminate gestione delle chiavi e dei segreti. Chi può decrittare i dati replicati? Una chiave conservata solo nel componente guasto può rendere inutilizzabile la copia. Se il cliente controlla le chiavi, la sua procedura di emergenza diventa parte del failover. Se il fornitore le gestisce, chiedete come sono rese disponibili nel percorso di recupero e quale prova sostiene la risposta. Non è necessario ricevere informazioni segrete per valutare la dipendenza; servono ruoli e sequenza operativa.
Controllate il piano di controllo: attivazione, configurazione, gestione degli utenti, fatturazione e richiesta di supporto possono essere globali pur in presenza di dati regionali. La matrice delle responsabilità condivise cloud consente di separare questi passaggi dal funzionamento dell’applicazione. Annotate se il cliente può vedere lo stato, cambiare regione o esportare dati durante la perdita del pannello di amministrazione.
Compiti che rimangono al cliente
La continuità del fornitore non elimina gli obblighi operativi del cliente. Occorre sapere chi rileva il disservizio, chi decide di attivare una procedura alternativa, chi informa utenti e chi verifica che i dati siano coerenti al ritorno. Un backup interno, se previsto, richiede personale, credenziali e spazio di ripristino. Una seconda regione disponibile non aiuta se l’applicazione aziendale continua a puntare alla prima e nessuno può aggiornare la configurazione.
Scrivete una procedura breve per l’operatore in reperibilità. Deve contenere contatto del fornitore, criteri per non attendere, dati necessari alla valutazione e azioni consentite. Distinguete le azioni che il cliente può eseguire da quelle che il fornitore deve fare. Una clausola che promette assistenza continua va collegata a un canale realmente raggiungibile durante il guasto. La valutazione dei fornitori TIC e dell’uscita approfondisce contratti e alternative quando DORA è pertinente; questa scheda resta concentrata sul percorso operativo regionale.
Prevedete come ricondurre il servizio alla situazione ordinaria. Dopo un failover possono esserci code, dati duplicati o sessioni da riaprire. Chi controlla la completezza delle transazioni? Chi decide il ritorno alla regione primaria? Un piano che si ferma al passaggio iniziale non dimostra la continuità del processo fino alla stabilizzazione. Registrate anche quali prove il cliente può ottenere dal fornitore a posteriori.
Un esempio: SaaS documentale in due regioni
Un’impresa utilizza un SaaS per consegnare documenti ai clienti. Il fornitore dichiara replica del contenuto fra due regioni. La scheda conferma che i file sono copiati, ma mostra che l’autenticazione degli operatori avviene tramite l’IdP dell’impresa e che il link pubblico dei clienti usa una configurazione DNS gestita internamente. Il test del fornitore copre la disponibilità dell’applicazione nella seconda regione; non comprende il cambio di DNS né la verifica dell’accesso degli utenti reali.
L’impresa prepara una prova controllata con un dominio di test e documenti sintetici. La seconda regione rende disponibili i file entro il tempo osservato, ma un utente nuovo non può accedere perché il gruppo corretto non era sincronizzato. Il team aggiorna la procedura di identità, ripete il caso e annota il nuovo risultato. Il fascicolo non afferma che ogni regione sia autonoma: spiega quali passaggi devono funzionare insieme e quali sono stati davvero esercitati.
Rimane aperta la domanda sui log e sull’assistenza durante un’interruzione del piano di controllo. Il responsabile del servizio decide di avviare il SaaS con una procedura alternativa limitata per la consegna urgente, mentre richiede al fornitore una prova o una spiegazione più specifica. La decisione descrive popolazione, durata e trigger di riesame. Se il servizio sostenesse una funzione essenziale di un’entità finanziaria, la valutazione dovrebbe inoltre essere inserita nel quadro DORA applicabile; non si può ricavare questa qualifica dal solo fatto che il prodotto sia un SaaS.
Verificare risposte e limiti prima del rinnovo
Una risposta del fornitore deve conservare data, versione del servizio e livello di prova. “Multi-regione” può cambiare significato con una nuova architettura o un nuovo piano commerciale. Riesaminate i punti aperti dopo incidenti, migrazioni, nuove integrazioni e modifiche contrattuali. Se il fornitore non rende disponibile un dettaglio architetturale per ragioni di sicurezza, chiedete una prova di comportamento o una dichiarazione sul risultato operativo che la vostra funzione richiede.
Nella revisione non cercate una certezza impossibile su ogni componente. Cercate la distinzione fra fatti confermati, affermazioni non dimostrate e compiti vostri. La scheda deve permettere a una persona nuova di capire dove stanno i dati, quale funzione riparte, da quali identità e chiavi dipende e chi deve fare il primo passo. Questo rende la decisione sul SaaS multi-regione concreta e rivedibile, senza trasformare una posizione geografica in una garanzia di continuità.
Esportazione e accesso ai dati durante un guasto
Chiedete se l’esportazione resta disponibile quando la regione primaria o il piano di controllo non funzionano. Un pulsante di download mostrato in condizioni ordinarie non dimostra che il cliente possa recuperare dati nel momento in cui serve. Valutate formato, completezza, relazione fra file e metadati, permessi necessari e tempo misurato per un campione rappresentativo. Se il recupero dipende da una richiesta di supporto, annotate il canale, i tempi dichiarati e la persona autorizzata a presentarla. Una copia di emergenza gestita dal cliente può ridurre questa dipendenza solo se viene prodotta e provata regolarmente.
L’esportazione risponde a due scopi diversi. Per un’interruzione breve può servire a continuare un’attività manuale; per la perdita definitiva del fornitore può sostenere un’uscita ordinata. Il primo percorso ha tempi stretti e richiede dati immediatamente leggibili dagli operatori. Il secondo può consentire una migrazione più lunga, ma necessita di documentazione dei campi e delle relazioni. Scrivete nella scheda quale scopo viene coperto dalla prova, evitando di usare un export notturno come dimostrazione di failover applicativo istantaneo.
Provate a ricostruire una pratica completa, non soltanto a scaricare un archivio. Una persona che non ha preparato il test dovrebbe poter trovare documento, stato, autore e data, quindi spiegare cosa manca. Se il campione è sintetico, mantenete comunque la complessità di una pratica reale. Un file correttamente esportato ma impossibile da usare nel processo alternativo non soddisfa l’obiettivo di continuità. Conservate il risultato e la versione del servizio, perché una modifica del formato può riaprire la verifica.
Confermare il percorso di assistenza
Durante un incidente il fornitore può offrire una pagina di stato e una linea di supporto, ma entrambe possono dipendere dalla stessa identità o piattaforma indisponibile. Verificate l’accesso a un canale alternativo e la possibilità di autenticare il cliente senza esporre segreti. Stabilite chi può chiedere un failover, quali dati deve fornire e come riceve aggiornamenti. Un contratto con assistenza continua non chiarisce automaticamente queste operazioni. Inserite un contatto reale nella prova e annotate le risposte osservate, distinguendo l’esercizio da un incidente vero.