Scelta del sito per emergenze: matrice di valutazione per Recovery-Sites inclusa verifica di conformità

La scelta del sito di emergenza è una delle decisioni che, in caso di necessità, o funzionano silenziosamente e senza clamore – o falliscono in modo molto pubblico. Sulla carta «sito di ripristino» suona come un secondo data center o una regione cloud. Nella pratica però si tratta di più: della domanda se i vostri processi aziendali critici, in scenari di disturbo reali (incendio, interruzione di corrente, ransomware, guasto di un operatore di rete, problema alla catena di fornitura, evento naturale, indisponibilità del personale) possano ripartire entro i tempi richiesti, senza introdurre nuovi rischi di compliance e sicurezza.

Questo contributo fornisce una matrice valutabile per i siti di ripristino – con criteri, pesature, requisiti minimi (criteri «knock-out») e un controllo di conformità adatto come supporto probatorio negli audit. Il target sono la direzione IT, la Security, la Compliance, il Risk Management e la direzione aziendale con competenze IT: ruoli che devono assumersi la responsabilità delle decisioni e poi spiegare perché un sito è stato scelto (o scartato).

Termini e obiettivi: cosa deve esattamente garantire il sito di ripristino?

Prima di confrontare i siti, dovete definire l’obiettivo – altrimenti confrontate mele con pere.

• RTO (Recovery Time Objective): tempo massimo tollerabile per il ripristino. Esempio: «L’ERP deve essere nuovamente disponibile entro 8 ore». L’RTO è un parametro guida per architettura, automazione, allocazione di capacità e processi operativi.
• RPO (Recovery Point Objective): perdita di dati tollerabile in termini temporali. Esempio: «perdita massima di dati di 15 minuti». L’RPO determina i metodi di replica, gli intervalli di backup e la consistenza dei dati.
• Classi di workload: non tutti i sistemi richiedono lo stesso sito di ripristino. Tipiche sono classi come «Tier 1 (critico per il business)», «Tier 2 (importante)», «Tier 3 (secondario)» – ciascuna con RTO/RPO, dipendenze e classificazione dei dati.
• Tipologia di sito di ripristino:
  • Hot Site: operatività quasi immediata, costi elevati, RTO/RPO bassi.
  • Warm Site: componenti di base presenti, attivazione con preavviso, costi medi.
  • Cold Site: infrastruttura/area disponibili, i sistemi devono essere installati, economico ma con RTO elevato.

Importante: RTO/RPO non sono valori desiderati dall’IT, ma devono derivare da una Business Impact Analysis (BIA) (analisi degli impatti su processi, fatturato, obblighi normativi, reputazione). Negli audit si richiede sempre più che RTO/RPO siano ragionevolmente derivati, approvati e periodicamente verificati.

La scelta del sito è più della geografia: assunzioni errate tipiche

„Lontano è automaticamente meglio“

La distanza geografica riduce rischi comuni (p.es. interruzione elettrica regionale). Allo stesso tempo spesso aumenta latenza, dipendenza dalle tratte dei carrier e la complessità operativa (p.es. team amministrativi separati, catene di fornitura diverse). Non sono decisivi i «chilometri», ma la separazione dei domini di rischio: approvvigionamento energetico, operatori di rete, approvvigionamento idrico, zone a rischio, rischi politici, catene di fornitura, disponibilità del personale.

„Il cloud è automaticamente conforme“

Le regioni cloud possono essere operativamente molto robuste, ma non esentano dalle responsabilità. Ai fini della compliance contano la residenza dei dati, i controlli di accesso, la registrazione dei log, la gestione delle chiavi (p.es. HSM/KMS), le catene dei subappaltatori e la capacità di exit. Il sito di ripristino non deve solo essere operativo, ma deve essere controllabile e dimostrabile.

„Il backup basta come sito di ripristino“

I backup sono l’ultima linea di difesa, ma non costituiscono un’architettura di recovery. Senza procedure di ripristino testate, capacità di calcolo sufficiente, percorsi di rete, gestione DNS-/certificati e IAM (Identity & Access Management) il backup RESTa un deposito di dati – non una continuità operativa. Negli scenari di ransomware si aggiunge: i backup devono essere protetti contro la manomissione (es. immutabili, account amministrativi separati, approcci Air-Gap).

Matrice di valutazione per siti di ripristino: struttura, ponderazione, criteri knock-out

Una matrice praticabile combina:

• Criteri knock-out (Obbligatori): Se non soddisfatti, il sito viene escluso indipendentemente dal punteggio.
• Criteri di scoring (Desiderabili/Facoltativi): Valutazione 0–5 o 0–10, con ponderazione in base alla rilevanza.
• Prove: Per ogni criterio deve essere chiaro quale evidenza è accettata (contratto, rapporto di audit, diagramma di architettura, protocollo di test, descrizione del processo).

Esempio: scala e ponderazione

Si è dimostrata efficace una scala 0–5 (0 = assente, 3 = soddisfa, 5 = supera), con ponderazione per categoria (es. 25% Operazioni/Resilienza, 25% Security/Compliance, 20% Rete/Connettività, 15% Dati/Piattaforma, 15% Costi/Contratto). La ponderazione dovrebbe dipendere dall’appetito di rischio e dalle classi di processo. Per workload Tier‑1 è raro che «costi» venga ponderato più di «ripristino operativo garantito».

Criteri knock-out (Obbligatori) – realistici per molte organizzazioni

• Residenza dei dati & giurisdizione: Le categorie di dati possono essere elaborate nel sito (protezione dei dati, normativa di settore, contratti con i clienti).
• RTO/RPO raggiungibili in linea di principio: Plausibile sulla base dell’architettura e della capacità, non solo affermato.
• Domini di amministrazione separati: Possibilità di gestire l’ambiente di ripristino con identità/chiavi separate (importante contro ransomware e rischi insider).
• Controlli di sicurezza fisici e logici verificabili: Accesso, segmentazione, logging, gestione patch/vulnerabilità, processi di incident response.
• Servizi contrattuali di emergenza: Diritti di attivazione, priorità in caso di crisi, finestre di test, SLA/OLA chiari, regole di exit.

Categoria 1: Profilo di rischio e del sito (geografia, infrastruttura, effetti a cascata)

Per la scelta del sito di emergenza dovRESTe considerare il profilo del sito come un «pacchetto di rischio».

Domande di verifica

• Rischio condiviso: Il sito primario e il sito di ripristino condividono le stesse dipendenze energetiche o dei carrier (stesso collegamento alla sottostazione, stesso percorso in fibra, stesse infrastrutture di accesso)?
• Zone di pericolo: Il sito si trova in aree soggette a inondazioni, terremoti, attività industriali o zone ad alto rischio? Non solo storicamente, ma sulla base di mappe aggiornate e degli sviluppi locali.

Prospettiva di audit: Non è essenziale eliminare ogni rischio naturale, ma che abbiate consapevolmente scelto e documentato: assunzioni sul rischio, contromisure e rischio residuo.

Categoria 2: Capacità tecnica di riavvio (RTO/RPO, capacità, automazione)

Qui si decide se il sito di recovery «esiste solo» oppure è operativamente sostenibile.

Modello di capacità invece dell’approccio basato sull’intuito

Una valutazione robusta della sede richiede un modello di capacità: quali workload devono funzionare in emergenza, con quali requisiti di pRESTazione (CPU/RAM/IOPS), per quanto tempo e con quali dipendenze (servizi directory, PKI, DNS, Time/NTP, message broker, interfacce)? Punto debole frequente: si considera solo l’applicazione, non l’ecosistema (gestione delle identità, monitoring, logging, gestione dei segreti, job batch, partner di integrazione).

Valutare i meccanismi di riavvio

• Replicazione (sincrona/asincrona): la replica sincrona riduce l’RPO, ma richiede bassa latenza e collegamenti stabili; l’asincrona è più robusta, ma può lasciare una lacuna di dati.
• Backup/RESTore: i tempi di RESTore devono essere misurati (non stimati). Questo include il recovery del database, il rebuild degli indici, il ripristino dell’object storage e la configurazione dell’applicazione.
• Infrastructure as Code (IaC): la provisioning automatizzata riduce gli errori sotto stress. La governance è importante: l’IaC deve essere versionata, approvata e testata.
• Runbooks: sequenze operative per failover e failback, con responsabilità, approvazioni e canali di comunicazione.

Blocco di evidenza riutilizzabile: attestazione minima del test DR

Per gli audit è utile un protocollo di test standardizzato. Esempio come modello:

DR-Testprotokoll (Versione breve)

1) Ambito
- Workload / classe di processo:
- Valori obiettivo: RTO ____, RPO ____
- Tipo di test: Tabletop / test parziale / test completo / non annunciato

2) Prerequisiti
- Approvazioni (IT, business unit, compliance):
- Change-Window:
- Canali di comunicazione / contatti:

3) Esecuzione (timestamp)
- Orario di inizio simulazione incidente:
- Trigger di failover:
- Identity/Access attivi:
- Stato dei dati verificato (punto di misura RPO):
- Verifica dell'applicazione (smoke test):
- Partner di integrazione convalidati:
- Monitoring/Logging attivi:
- Accettazione business:

4) Risultato
- RTO raggiunto:
- RPO raggiunto:
- Deviazioni / cause:
- Azioni immediate:
- Piano di azione con owner e scadenza:

5) Allegati di evidenza
- Stato architettura (versione diagramma):
- ID ticket / change record:
- Misurazioni / screenshot di monitoring:
- Approvazioni / accettazioni:

Categoria 3: Netzwerk, Connectivity und „Failover der Realität“

Molti concetti di ripristino non falliscono per il compute, ma per dettagli di rete: DNS, routing, certificati, spazi di indirizzi IP, regole firewall, connessioni con partner, varianti MPLS/VPN/Direct-Connect.

Criteri di valutazione

• Percorsi di collegamento indipendenti: la ridondanza è efficace solo se non percorre lo stesso corridoio fisico di infrastruttura (parola chiave „Diverse Routing“).
• Meccanica di failover: DNS-TTL, Anycast, BGP-failover o commutazione del load balancer – ognuno con chiara responsabilità operativa.
• Connessioni con partner e terze parti: le interfacce critiche (p. es. fornitori di servizi di pagamento, logistica, EDI) possono essere deviate verso il sito di ripristino? Esistono possibilità contrattuali di test?
• Segmentazione: separazione delle reti di amministrazione, dati e applicazioni, incluso il funzionamento di emergenza (p. es. accesso limitato, jump host, MFA).

Nota di governance: documentare quali modifiche di rete sono consentite in emergenza senza CAB (Change Advisory Board), quali autorizzazioni „Break-Glass“ si applicano e come verrà eseguita la documentazione successiva.

Categoria 4: Dati, requisiti di protezione e residenza dei dati

La scelta del sito di ripristino è anche architettura dei dati. I conflitti tipici sorgono tra il ripristino rapido e una rigorosa classificazione dei dati.

Punti di verifica per dati e piattaforma

• Classificazione dei dati: quali dati possono andare dove? (dati personali, riservati, soggetti a controllo delle esportazioni, segreti aziendali). Il sito di ripristino deve consentire il trattamento di queste classi – incluso l’accesso amministrativo e l’accesso di supporto.
• Crittografia: at-REST e in-transit. È cruciale chi controlla le chiavi (chiavi del cliente vs chiavi del provider) e come sono gestite la rotazione delle chiavi e l’accesso d’emergenza.
• Modelli di consistenza: database, code di messaggi, filesystem. L’RPO è inutile se le applicazioni presentano stati inconsistenti dopo il ripristino (p. es. doppie registrazioni, ordini orfani).
• Retention e WORM/immutabilità: per alcuni dati l’immutabilità (Write Once Read Many) può essere rilevante. Verificare se il sito di ripristino supporta questa modalità operativa.

Categoria 5: Controlli di sicurezza contro ransomware e rischi trasversali

Un sito di ripristino che opera nello stesso contesto di sicurezza dell’ambiente primario verrà rapidamente travolto in caso di compromissione di identità o di amministratore. Una buona scelta della sede significa quindi anche: rendere pianificabile l’isolamento.

Criteri concreti

• IAM separato / account amministrativi separati: almeno ruoli separati e MFA forte, idealmente un dominio di directory separato o una zona di identità chiaramente segmentata.
• Processo Break-Glass: accesso di emergenza con autorizzazione documentata, forte registrazione e controllo a posteriori.
• Logging & analisi forense: i log di sicurezza devono essere disponibili centralmente anche in caso di funzionamento di emergenza (integrazione SIEM, log immutabili, sincronizzazione temporale via NTP).
• Gestione delle vulnerabilità e delle patch: il sito di recovery non deve „rimanere inattivo per anni“ e avviarsi non patchato in caso di emergenza. Aggiornamento almeno mensile, con prova della baseline.

Blocco di policy copiabile: Break-Glass (policy sintetica)

Accesso Break-Glass (policy sintetica)

Scopo:
- Consente operazioni di recovery in caso di indisponibilità/compromissione degli accessi amministrativi regolari.

Regole:
- Account di emergenza separati, non per uso operativo quotidiano.
- MFA obbligatoria, token hardware preferiti.
- Attivazione solo dopo autorizzazione a due persone (direzione IT + Security/Compliance).
- Ogni utilizzo genera un ticket di incidente e viene documentato a posteriori entro 24 ore.
- Le sessioni vengono registrate (Command Logging / Session Recording, se disponibile).
- Gli account di emergenza vengono testati trimestralmente e le password/segreti vengono ruotati.

Evidenza:
- Elenco account, ruoli, ultimi test, protocolli di attivazione, protocollo di revisione.

Categoria 6: Compliance-Check (a prova di audit): quali evidenze richiedere precocemente

La parte di compliance viene spesso considerata troppo tardi – a quel punto i contratti sono firmati, le decisioni tecniche prese e mancano le evidenze. Per una scelta del sito di recovery a prova di audit è fondamentale che vincoliate i requisiti in approvvigionamento, contrattualistica e operatività.

Punti di riferimento normativi (senza pretesa di esaustività)

• ISO 22301 (Business Continuity Management): richiede, tra l’altro, BIA, analisi dei rischi, strategie di ripartenza, esercitazioni, procedure documentate e miglioramento continuo.
• DORA (Digital Operational Resilience Act): rilevante per molti operatori del mercato finanziario; enfatizza resilienza, testabilità, rischi da terze parti e governance.
• BAIT/VAIT/KAIT (requisiti di vigilanza in Germania, a seconda del settore): focus tipico su piani di emergenza, esternalizzazioni, sicurezza delle informazioni e obblighi di rendicontazione.
• KRITIS/NIS2-Kontext: a seconda dell’ambito di applicazione requisiti aggiuntivi su misure di sicurezza, obblighi di notifica e resilienza.
• DSGVO: trattamento, subappalto di trattamento, AVV (contratto di nomina), TOM (misure tecniche e organizzative), trasferimenti verso paesi terzi, politiche di cancellazione.

Importante: non è necessario soddisfare ogni norma, ma dovete sapere quali si applicano alla vostra organizzazione e come il vostro sito di recovery supporta tali requisiti.

Lista di controllo di compliance per siti di recovery (orientata alle evidenze)

• Contratto & esternalizzazione
  • Descrizione del servizio per il funzionamento di emergenza (attivazione, prioritizzazione, impegni di capacità).
  • Diritti per test/esercitazioni (frequenza, portata, regolazione dei costi).
  • Trasparenza sui subfornitori e consenso, inclusa la catena dei siti.
  • Exit-strategy: restituzione dei dati, cancellazione, migrazione, termini, supporto.
• Protezione dei dati
  • Ruoli (titolare/responsabile del trattamento), AVV (contratto di nomina), allegato TOM.
  • Residenza dei dati e regole per i trasferimenti verso paesi terzi, accessi da stati terzi.
  • Concetto di cancellazione e retention anche in emergenza (es. dati di test, log).
• Sicurezza & operatività
  • Prove relative a controllo accessi, monitoraggio, gestione degli incidenti, change management.
  • Registrazione e conservazione (Audit Logs, attività amministrative).
  • Test DR regolari con risultati documentati e piani d’azione.

Categoria 7: Operatività quotidiana: chi fa cosa quando la situazione è davvero critica?

Le Recovery-Site vengono reperite dal punto di vista tecnico e poi dimenticate dal punto di vista organizzativo. Al più tardi in sede di audit o durante un incidente questo salta fuori. Ciò che conta è la capacità operativa sotto stress: ruoli, autorizzazioni, comunicazione e logica decisionale.

Ruoli e responsabilità (logica RACI)

• Direzione IT: decisione „Failover sì/no“, prioritarizzazione delle risorse, escalation alla direzione aziendale.
• Service Owner / responsabili delle applicazioni: validazione dei test smoke, gestione delle dipendenze, accettazione funzionale.
• Security: autorizzazione degli accessi d’emergenza, monitoring, indicatori di compromissione (per evitare di avviare un ambiente «infettato»).
• Compliance/Gestione del rischio: obblighi di documentazione e dimostrazione, comunicazione agli organi di vigilanza/stakeholder a seconda del contesto.
• Coordinamento provider/fornitori di servizi: attivazione dei servizi contrattuali, coordinamento dei subfornitori.

Regola pratica: se la vostra Recovery-Site può effettuare il failover solo con “i due amministratori senior”, questo rappresenta un rischio. Pianificate turnazioni, sostituzioni e trasferimento di conoscenza. È un criterio nella valutazione del sito perché determina le conseguenze operative.

Categoria 8: Realtà dei costi e dei contratti: cosa dovete rappresentare nel modello TCO

I costi vengono spesso ridotti all’infrastruttura («secondo sito = doppio hardware»). Nella realtà si generano blocchi di costo per esercizio, test, licenze, linee e governance.

Componenti tipiche del TCO

• Riserva di capacità: compute riservato, storage, cluster di database, eventuali costi di licenza in standby.
• Connettività: linee ridondanti, Cross-Connects, firewall aggiuntive, protezione DDoS.
• Ambito di test: esercizi DR, finestre di manutenzione, oneri del reparto, documentazione.
• Controlli di sicurezza: integrazione SIEM, EDR, PAM (Privileged Access Management), registrazione delle sessioni.
• Exit & portabilità: esportazione dati, strumenti di migrazione, competenze doppie/formazione duplicata.

Consiglio per la matrice di valutazione: i costi non dovrebbero essere considerati solo come cifra assoluta, ma anche come rischio di costo (es. logica tariffaria poco chiara in emergenza, clausole «Best Effort», tariffe per test, assenza di garanzia di capacità).

Come applicare praticamente la matrice di valutazione (modello operativo in 6 fasi)

1. Definire lo scope: classi di processo, workload, classi di dati, dipendenze, RTO/RPO.
2. Stabilire i criteri obbligatori: lista knock-out inclusa la compliance.
3. Catalogare i criteri: categorie (rischio/sito, tecnologia, rete, dati, security, operazioni, contratto, costi).
4. Stabilire i pesi: da parte di IT, Security, Compliance e rappresentanza del reparto (per classe di Tier).
5. Richiedere evidenze: prove accettate per ogni criterio; l’assenza di evidenza vale come «non soddisfatto».
6. Review & Entscheidung: risultato, rischio residuo, piano di misure, momento per il re-assessment (es. annuale o in caso di cambiamento di sito/provider).

Blocco matrice copiabile: lista criteri (forma breve per iniziare)

Matrice di valutazione sito di ripristino – Avvio rapido (0–5 punti, peso per categoria)

A) Profilo sede/rischi
- Indipendenza energia/carrier
- Zone a rischio / rischi condivisi
- Raggiungibilità / disponibilità del personale

B) Capacità RTO/RPO
- Procedure di replica/backup verificabili
- Capacità e scalabilità in caso di emergenza
- Automazione (IaC/Runbooks)
- Test regolari (frequenza, portata, risultati)

C) Rete & connettività
- Diversità dei percorsi di collegamento
- Meccanismi di failover (DNS/BGP/Loadbalancer)
- Connessioni ai partner commutabili
- Segmentazione & accessi amministrativi

D) Dati & protezione dei dati
- Residenza dei dati / giurisdizione
- Crittografia & possesso delle chiavi
- Conservazione/cancellazione anche in modalità d'emergenza

E) Sicurezza
- Domini amministrativi separati / break-glass
- Logging/forense/SIEM
- Gestione patch/vulnerabilità

F) Governance/contratto/costi
- Diritti di attivazione, SLA/OLA, diritti di test
- Subappaltatori/catena di fornitura trasparente
- Strategia di exit e RESTituzione dei dati
- Modello di costo (incl. test, funzionamento d'emergenza)

Prospettiva di audit: cosa i verificatori tipicamente vogliono vedere

Indipendentemente dal fatto che la verifica sia interna o esterna: buoni risultati nascono quando documentate le decisioni come una catena verificabile. Punti di controllo tipici:

• Derivazione: la BIA e l’analisi dei rischi conducono a RTO/RPO e alla strategia di localizzazione.
• Implementazione: architettura e concetti operativi mostrano come gli obiettivi vengono raggiunti.
• Efficacia: test/esercitazioni dimostrano che non è solo teorico.
• Miglioramento: le deviazioni danno luogo ad azioni con owner e scadenza.
• Terze parti: il controllo dell’outsourcing e l’exit sono regolati, non solo „da qualche parte nel contratto“.

Se volete approfondire internamente: un catalogo strutturato di domande di verifica aiuta a raccogliere le evidenze precocemente e a colmare le lacune prima della prossima verifica o esercitazione.

Conclusione: una buona scelta del sito di ripristino è una decisione con onere della prova

Un sito di ripristino non è un simbolo di resilienza, ma una modalità operativa solida. La migliore scelta del sito di emergenza nasce quando tecnica, operation e compliance vengono valutate insieme: con criteri obbligatori, scoring verificabile, evidenze chiare e test periodici. Così la decisione non è robusta solo in situazione di crisi, ma anche nelle revisioni di budget e negli audit — inclusi i rischi residui consapevoli.

Il passo decisivo non è quasi mai la selezione del „sito perfetto“, ma la logica di attuazione coerente: mappare completamente le dipendenze, pianificare l’isolamento contro attacchi trasversali, assicurare contrattualmente i diritti di test e tradurre i risultati nella governance. Allora il sito di ripristino non è solo presente, ma operativo.

Per questo tema sono importanti anche il sito di ripristino e il Disaster Recovery. Il contributo inquadra questi aspetti in maniera comprensibile e mostra cosa conta nella pratica quotidiana.