Test di ripristino pronti per l'audit per ISO 27001, NIS2 e DORA
Sono le 07:40 di lunedì mattina e Sarah, CISO di una società fintech in rapida crescita, osserva una crisi prendere forma in tempo reale. Il CFO non riesce ad accedere alla piattaforma di approvazione dei pagamenti. Il service desk ritiene che si tratti di un problema di storage. Il team infrastrutturale sospetta un ransomware perché diverse cartelle condivise mostrano ora nomi di file cifrati. Il CEO vuole sapere se la gestione delle paghe è al sicuro. La funzione legale chiede se sia necessario notificare le autorità di regolamentazione.
Sarah apre la dashboard dei backup. È piena di spunte verdi.
Dovrebbe essere rassicurante, ma non lo è. Un job di backup riuscito non è la prova di un ripristino riuscito. È come vedere un estintore appeso al muro senza sapere se sia carico, accessibile e utilizzabile sotto pressione.
L’azienda di Sarah rientra nell’ambito di ISO 27001:2022, è considerata un soggetto importante ai sensi di NIS2 ed è soggetta a DORA in quanto entità finanziaria. La domanda non è più se l’organizzazione esegua backup. La domanda è se sia in grado di ripristinare i sistemi corretti, al punto temporale corretto, entro i Recovery Time Objectives e i Recovery Point Objectives approvati, con evidenze sufficientemente solide per auditor, autorità di regolamentazione, clienti, assicuratori e consiglio di amministrazione.
È qui che molti programmi di backup falliscono. Dispongono di job di backup. Hanno dashboard. Hanno snapshot. Possono persino disporre di archiviazione cloud. Ma quando arriva la pressione, non riescono a dimostrare che i sistemi critici sono recuperabili, che i test di ripristino sono stati eseguiti, che i test falliti hanno attivato azioni correttive e che le evidenze sono mappate in modo chiaro alle aspettative di ISO 27001:2022, NIS2, DORA, NIST e COBIT 2019.
I test di backup e ripristino sono diventati una questione di resilienza operativa a livello di consiglio di amministrazione. NIS2 innalza le aspettative in materia di gestione dei rischi di cibersicurezza e continuità operativa. DORA rende la resilienza operativa digitale un obbligo centrale per le entità finanziarie e per i loro fornitori critici di servizi ICT. ISO 27001:2022 fornisce la struttura del sistema di gestione per ambito, rischio, selezione dei controlli, evidenze, audit e miglioramento continuo.
La sfida pratica consiste nel trasformare un test tecnico di ripristino in evidenze pronte per l’audit.
Il backup non è evidenza finché il ripristino non è dimostrato
Un job di backup completato con successo è solo un segnale parziale. Indica che i dati sono stati copiati da qualche parte. Non dimostra che i dati possano essere ripristinati, che le dipendenze applicative siano integre, che le chiavi di cifratura siano disponibili, che i servizi di identità funzionino ancora o che il sistema ripristinato supporti le reali operazioni aziendali.
Gli auditor lo sanno. Le autorità di regolamentazione lo sanno. Gli attaccanti lo sanno.
Un auditor tecnicamente maturo non si fermerà a uno screenshot che mostra il 97% di job di backup riusciti. Chiederà:
- Quali sistemi sono critici o ad alto impatto?
- Quali RTO e RPO si applicano a ciascun sistema?
- Quando è stato eseguito l’ultimo test di ripristino?
- Il test era completo, parziale, a livello applicativo, a livello di database o a livello di file?
- Chi ha validato il processo aziendale dopo il ripristino?
- I fallimenti sono stati registrati come non conformità o azioni di miglioramento?
- Per quanto tempo vengono conservati i log e le registrazioni dei test di ripristino?
- Le copie di backup sono segregate tra ubicazioni diverse?
- In che modo le evidenze sono mappate al Registro dei rischi e alla Dichiarazione di Applicabilità?
Per questo il linguaggio delle policy Clarysec è intenzionalmente diretto. La Politica di backup e ripristino per PMI [BRP-SME], sezione Requisiti di governance, clausola di policy 5.3.3, richiede:
I test di ripristino sono condotti almeno trimestralmente e i risultati sono documentati per verificare la recuperabilità
Questa singola frase cambia la conversazione in sede di audit. Sposta l’organizzazione da “abbiamo i backup” a “verifichiamo la recuperabilità con una frequenza definita e conserviamo i risultati”.
La stessa Politica di backup e ripristino per PMI, sezione Applicazione e conformità, clausola di policy 8.2.2, rafforza l’obbligo di evidenza:
I log e le registrazioni dei test di ripristino sono conservati per finalità di audit
Questa clausola impedisce che i test di ripristino diventino conoscenza informale non documentata. Se un ingegnere infrastrutturale afferma: “Lo abbiamo testato a marzo”, ma non esiste alcuna registrazione, non si tratta di evidenza pronta per l’audit.
La stessa policy affronta anche la resilienza attraverso la diversificazione dello storage. Nella sezione Requisiti di applicazione della policy, clausola di policy 6.3.1.1, i backup devono essere:
Archiviati in almeno due ubicazioni (locale e cloud)
Questa è una baseline pratica. Non sostituisce una valutazione del rischio, ma riduce la probabilità che un singolo dominio di guasto fisico o logico distrugga sia i dati di produzione sia i dati di backup.
La catena delle evidenze ISO 27001:2022 inizia prima del test
Le organizzazioni spesso trattano la conformità dei backup come un tema di operatività IT. In termini ISO 27001:2022, è un’impostazione troppo ristretta. I test di backup e ripristino devono essere integrati nel Sistema di gestione della sicurezza delle informazioni, collegati ad ambito, rischio, selezione dei controlli, monitoraggio, audit interno e miglioramento continuo.
Il Zenith Blueprint: roadmap in 30 passaggi per auditor di Clarysec [ZB] avvia questa catena delle evidenze prima che venga eseguito qualsiasi test di ripristino.
Nella fase Fondamenti e leadership del SGSI, Step 2, Esigenze degli stakeholder e ambito del SGSI, il Zenith Blueprint indica alle organizzazioni di definire ciò che rientra nel SGSI:
Azione 4.3: Redigere una dichiarazione del campo di applicazione del SGSI. Elencare ciò che è incluso (unità aziendali, sedi, sistemi) e le eventuali esclusioni. Condividere questa bozza con l’alta direzione per ottenere contributi: deve concordare quali parti dell’attività saranno soggette al SGSI. È inoltre opportuno verificare la coerenza di questo ambito rispetto all’elenco dei requisiti degli stakeholder definito in precedenza: il campo di applicazione copre tutte le aree necessarie per soddisfare tali requisiti?
Per i test di ripristino, l’ambito definisce il perimetro del ripristino. Se la piattaforma di pagamento, il provider di identità, il database ERP, il server di gestione degli endpoint e lo storage a oggetti cloud rientrano nell’ambito, le evidenze di ripristino devono includerli o motivarne l’esclusione. Se un sistema è escluso, l’esclusione deve essere sostenibile rispetto ai requisiti degli stakeholder, agli obblighi contrattuali, agli obblighi normativi e alle esigenze di continuità operativa.
Il collegamento successivo è il rischio. Nella fase Gestione del rischio, Step 11, Costruzione e documentazione del Registro dei rischi, il Zenith Blueprint descrive il registro dei rischi come la registrazione principale di rischi, asset, minacce, vulnerabilità, controlli esistenti, titolari e decisioni di trattamento.
Una voce di rischio relativa ai backup deve essere pratica, non teorica.
| Elemento di rischio | Esempio di voce |
|---|---|
| Asset | Piattaforma di approvazione dei pagamenti e database di supporto |
| Minaccia | Cifratura da ransomware o azione distruttiva di un amministratore |
| Vulnerabilità | Backup non ripristinati trimestralmente e dipendenze applicative non validate |
| Impatto | Ritardo nelle paghe, esposizione normativa, impatto sulla fiducia dei clienti |
| Controlli esistenti | Job di backup giornalieri, archiviazione cloud immutabile, test di ripristino trimestrale |
| Titolare del rischio | Responsabile dell’infrastruttura |
| Decisione di trattamento | Mitigare tramite backup testati, evidenze di ripristino documentate e aggiornamenti del BCP |
È qui che il backup diventa verificabile in audit. Non è più “abbiamo i backup”. Diventa “abbiamo identificato un rischio aziendale, selezionato i controlli, assegnato la titolarità, testato il controllo e conservato le evidenze”.
Il Zenith Blueprint, fase Gestione del rischio, Step 13, Pianificazione del trattamento del rischio e Dichiarazione di Applicabilità, chiude il ciclo di tracciabilità:
Mappare i controlli a rischi e clausole (tracciabilità)
Ora che disponi sia del Piano di trattamento del rischio sia della SoA:
✓ Mappa i controlli ai rischi: nel piano di trattamento del tuo Registro dei rischi hai elencato determinati controlli per ciascun rischio. Puoi aggiungere una colonna “Riferimento controllo Allegato A” a ciascun rischio ed elencare i numeri dei controlli.
Per i test di backup e ripristino, la Dichiarazione di Applicabilità deve collegare lo scenario di rischio ai controlli dell’Allegato A di ISO/IEC 27001:2022, in particolare 8.13 Backup delle informazioni, 5.30 Preparazione ICT per la continuità operativa, 8.14 Ridondanza delle strutture di elaborazione delle informazioni e 5.29 Sicurezza delle informazioni durante le interruzioni.
La SoA non deve limitarsi a contrassegnare questi controlli come applicabili. Deve spiegare perché sono applicabili, quali evidenze di attuazione esistono, chi è il titolare del controllo e come vengono gestite le eccezioni.
La mappa dei controlli che gli auditor si aspettano di vedere
Zenith Controls: la guida alla cross-compliance di Clarysec [ZC] non crea controlli separati o proprietari. Organizza standard e quadri di riferimento ufficiali in una vista pratica di cross-compliance, affinché le organizzazioni possano comprendere come una prassi operativa, come i test di ripristino, supporti più obblighi.
Per il controllo ISO/IEC 27002:2022 8.13 Backup delle informazioni, Zenith Controls classifica il controllo come correttivo, collegato a Integrità e Disponibilità, allineato alla funzione di cibersicurezza Ripristinare, a supporto della capacità operativa di Continuità e collocato nel dominio di sicurezza Protezione. Questo profilo riformula i backup come capacità di ripristino, non semplicemente come processo di archiviazione.
Per il controllo ISO/IEC 27002:2022 5.30 Preparazione ICT per la continuità operativa, Zenith Controls classifica il controllo come correttivo, focalizzato sulla Disponibilità, allineato a Rispondere, a supporto della Continuità e posizionato nel dominio di sicurezza Resilienza. È qui che i test di ripristino si collegano direttamente alla resilienza operativa.
Per il controllo ISO/IEC 27002:2022 8.14 Ridondanza delle strutture di elaborazione delle informazioni, Zenith Controls identifica un controllo preventivo focalizzato sulla Disponibilità, allineato a Proteggere, a supporto della Continuità e della gestione degli asset, e collegato ai domini Protezione e Resilienza. Ridondanza e backup non sono la stessa cosa. La ridondanza aiuta a prevenire l’interruzione. I backup consentono il ripristino dopo perdita, corruzione o attacco.
Per il controllo ISO/IEC 27002:2022 5.29 Sicurezza delle informazioni durante le interruzioni, Zenith Controls mostra un profilo più ampio: preventivo e correttivo, che copre Riservatezza, Integrità e Disponibilità, allineato a Proteggere e Rispondere, a supporto della Continuità e collegato a Protezione e Resilienza. Questo aspetto è rilevante durante il ripristino da ransomware perché il ripristino non deve creare nuovi fallimenti di sicurezza, come ripristinare immagini vulnerabili, bypassare la registrazione o riattivare privilegi eccessivi.
| Controllo dell’Allegato A ISO/IEC 27001:2022 | Ruolo nella resilienza | Evidenze attese dagli auditor |
|---|---|---|
| 8.13 Backup delle informazioni | Dimostra che dati e sistemi possono essere recuperati dopo perdita, corruzione o attacco | Piano dei backup, registrazioni dei test di ripristino, criteri di successo, log, eccezioni, evidenze di conservazione |
| 5.30 Preparazione ICT per la continuità operativa | Dimostra che le capacità ICT supportano gli obiettivi di continuità | BIA, mappatura RTO/RPO, runbook di ripristino, rapporti di test, lezioni apprese |
| 8.14 Ridondanza delle strutture di elaborazione delle informazioni | Riduce la dipendenza da un’unica struttura di elaborazione o da un unico percorso di servizio | Diagrammi di architettura, risultati dei test di failover, riesame della capacità, mappatura delle dipendenze |
| 5.29 Sicurezza delle informazioni durante le interruzioni | Mantiene la sicurezza durante operazioni degradate e ripristino | Registrazioni degli accessi in crisi, approvazioni di modifiche d’emergenza, logging, cronologia dell’incidente, validazione di sicurezza post-ripristino |
La lezione pratica è semplice. Un test di ripristino non è un controllo isolato. È evidenza lungo una catena di resilienza.
Il divario nascosto in audit: RTO e RPO senza prova
Una delle risultanze di audit più comuni in ambito continuità è il divario tra RTO/RPO documentati e capacità reale di ripristino.
Il Piano di continuità operativa può indicare che il portale clienti ha un RTO di quattro ore e un RPO di un’ora. La piattaforma di backup può essere eseguita ogni ora. Ma durante la prima esercitazione realistica di ripristino, il team scopre che il ripristino del database richiede tre ore, le modifiche DNS richiedono un’altra ora, il certificato applicativo è scaduto e l’integrazione con l’identità non è mai stata inclusa nel runbook. Il tempo reale di ripristino è otto ore.
L’RTO documentato era fittizio.
La Politica di continuità operativa e disaster recovery per PMI di Clarysec [BCDR-SME], sezione Requisiti di governance, clausola di policy 5.2.1.4, esplicita il requisito di continuità:
Recovery Time Objectives (RTOs) e Recovery Point Objectives (RPOs) per ciascun sistema
È importante perché “ripristinare rapidamente i servizi critici” non è misurabile. “Ripristinare il database di approvazione dei pagamenti entro quattro ore con non più di un’ora di perdita dati” è misurabile.
La stessa Politica di continuità operativa e disaster recovery per PMI, sezione Requisiti di applicazione della policy, clausola di policy 6.4.2, trasforma il test in miglioramento:
Tutti i risultati dei test devono essere documentati e le lezioni apprese devono essere registrate e utilizzate per aggiornare il BCP.
Un ripristino fallito non è automaticamente un disastro in audit. Lo è un ripristino fallito senza una lezione documentata, un titolare, una correzione e un nuovo test.
Per gli ambienti enterprise, la Politica di backup e ripristino di Clarysec [BRP] fornisce una governance più formale. Nella sezione Requisiti di governance, clausola di policy 5.1, stabilisce:
Deve essere mantenuto e riesaminato annualmente un Piano generale dei backup. Deve specificare:
Questo requisito iniziale stabilisce l’artefatto di governance principale. Un Piano generale dei backup deve identificare sistemi, set di dati, frequenza dei backup, conservazione, ubicazione, titolarità, classificazione, dipendenze e frequenza dei test.
La stessa Politica di backup e ripristino, sezione Requisiti di governance, clausola di policy 5.2, collega le aspettative sui backup all’impatto aziendale:
Tutti i sistemi e le applicazioni classificati come Critici o ad alto impatto nella Business Impact Analysis (BIA) devono:
È qui che BIA e governance dei backup convergono. I sistemi critici e ad alto impatto richiedono una maggiore assurance di ripristino, test più frequenti, una migliore mappatura delle dipendenze ed evidenze più disciplinate.
Un unico modello di evidenze per ISO 27001:2022, NIS2, DORA, NIST e COBIT 2019
I team di conformità spesso faticano con la duplicazione tra quadri di riferimento. ISO 27001:2022 richiede selezione dei controlli ed evidenze basate sul rischio. NIS2 si aspetta misure di gestione dei rischi di cibersicurezza, inclusa la continuità operativa. DORA richiede resilienza operativa digitale, risposta e ripristino, procedure di backup e ripristino, nonché test di resilienza operativa digitale. NIST e COBIT 2019 usano ancora un linguaggio diverso.
La risposta non è costruire programmi di backup separati per ogni quadro di riferimento. La risposta è costruire un unico modello di evidenze osservabile attraverso più prospettive di audit.
| Prospettiva del quadro di riferimento | Che cosa dimostrano i test di backup e ripristino | Evidenze da mantenere pronte per l’audit |
|---|---|---|
| ISO 27001:2022 | I rischi sono trattati tramite controlli selezionati, testati, monitorati e migliorati attraverso il SGSI | Ambito, registro dei rischi, SoA, piano dei backup, registrazioni dei ripristini, risultati dell’audit interno, registro CAPA |
| NIS2 | I servizi essenziali o importanti possono resistere a una perturbazione cyber e ripristinarsi | Piani di continuità operativa, procedure di crisi, test dei backup, collegamenti con la risposta agli incidenti, supervisione della direzione |
| DORA | I servizi ICT a supporto di funzioni critiche o importanti sono resilienti e recuperabili | Mappatura degli asset ICT, RTO/RPO, rapporti dei test di ripristino, evidenze sulle dipendenze da terze parti, procedure di ripristino |
| NIST CSF | Le capacità di ripristino supportano esiti di cibersicurezza resilienti | Piani di ripristino, controlli di integrità dei backup, procedure di comunicazione, lezioni apprese |
| COBIT 2019 | Gli obiettivi di governance e gestione sono supportati da controlli misurabili e titolarità responsabile | Titolarità dei processi, metriche, prestazioni dei controlli, tracciamento delle criticità, reportistica alla direzione |
Per NIS2, il riferimento più diretto è Article 21 sulle misure di gestione dei rischi di cibersicurezza. Article 21(2)(c) include specificamente la continuità operativa, come la gestione dei backup, il Disaster Recovery e la gestione delle crisi. Anche Article 21(2)(f) è rilevante, perché riguarda politiche e procedure per valutare l’efficacia delle misure di gestione dei rischi di cibersicurezza. Il test di ripristino è esattamente questo: evidenza che la misura funziona.
Per DORA, i collegamenti più forti sono Article 11 su risposta e ripristino, Article 12 su politiche e procedure di backup, procedure e metodi di ripristino e recupero, e Article 24 sui requisiti generali per i test di resilienza operativa digitale. Per le entità finanziarie, un test di ripristino del database da solo può essere insufficiente se il servizio aziendale dipende da identità cloud, connettività al gateway di pagamento, hosting esternalizzato o monitoraggio gestito. Le evidenze in stile DORA devono essere a livello di servizio, non solo a livello di server.
| Controllo ISO/IEC 27001:2022 | Collegamento DORA | Collegamento NIS2 |
|---|---|---|
| 8.13 Backup delle informazioni | Article 12 richiede politiche di backup, procedure e metodi di ripristino e recupero | Article 21(2)(c) include gestione dei backup e Disaster Recovery come misure di continuità operativa |
| 5.30 Preparazione ICT per la continuità operativa | Article 11 richiede capacità di risposta e ripristino, e Article 24 richiede test di resilienza | Article 21(2)(c) include continuità operativa e gestione delle crisi |
| 8.14 Ridondanza delle strutture di elaborazione delle informazioni | Articles 6 e 9 supportano la gestione del rischio ICT, la protezione, la prevenzione e la riduzione dei singoli punti di guasto | Article 21 richiede misure adeguate e proporzionate per gestire i rischi per le reti e i sistemi informativi |
| 5.29 Sicurezza delle informazioni durante le interruzioni | Article 11 su risposta e ripristino richiede un ripristino controllato durante gli incidenti | Le misure di gestione del rischio di Article 21 richiedono continuità senza abbandonare i controlli di sicurezza |
Questa è l’efficienza di una strategia di conformità unificata. Un test di ripristino trimestrale per un sistema di pagamento può supportare le evidenze dell’Allegato A di ISO 27001:2022, le aspettative di continuità NIS2, i requisiti di ripristino ICT DORA, gli esiti Ripristinare del NIST CSF e la reportistica di governance COBIT 2019, se le evidenze sono strutturate correttamente.
Un test di ripristino pratico che diventa evidenza pronta per l’audit
Torniamo allo scenario del lunedì mattina di Sarah, ma immaginiamo che la sua organizzazione si sia preparata utilizzando il toolkit di Clarysec.
La piattaforma di approvazione dei pagamenti è classificata come Critica nella BIA. L’RTO approvato è quattro ore. L’RPO approvato è un’ora. La piattaforma dipende da un cluster di database, un provider di identità, un vault dei segreti, una pipeline di logging, DNS, certificati e un relay e-mail in uscita.
Il team di Sarah costruisce un test di ripristino trimestrale in sei passaggi.
Step 1: confermare ambito e dipendenze
Utilizzando lo Step 2 del Zenith Blueprint, Sarah conferma che la piattaforma di pagamento, il database, l’integrazione dell’identità, l’infrastruttura di backup e l’ambiente di ripristino rientrano nel campo di applicazione del SGSI. La funzione legale conferma la rilevanza normativa. La finanza conferma l’impatto aziendale. L’IT conferma le dipendenze.
Questo evita l’errore classico di ripristinare solo il database ignorando il servizio di autenticazione necessario per accedere all’applicazione.
Step 2: collegare il test al registro dei rischi
Utilizzando lo Step 11 del Zenith Blueprint, il registro dei rischi include lo scenario: “La perdita o cifratura dei dati della piattaforma di approvazione dei pagamenti impedisce le operazioni di pagamento e crea esposizione normativa”.
I controlli esistenti includono backup giornalieri, archiviazione cloud immutabile, copie di backup multi-ubicazione, test di ripristino trimestrali e runbook di ripristino documentati. Il titolare del rischio è il Responsabile dell’infrastruttura. Il titolare del processo aziendale è Finance Operations. La decisione di trattamento è Mitigare.
Step 3: mappare il trattamento alla SoA
Utilizzando lo Step 13 del Zenith Blueprint, la SoA mappa il rischio ai controlli dell’Allegato A di ISO/IEC 27001:2022 8.13, 5.30, 8.14 e 5.29. La SoA spiega che il test dei backup fornisce capacità correttiva di ripristino, le procedure di continuità ICT supportano la continuità operativa, la ridondanza riduce la probabilità di indisponibilità e la sicurezza durante le interruzioni impedisce scorciatoie insicure nel ripristino.
Step 4: utilizzare le clausole di policy come criteri di test
Il team utilizza la clausola 5.3.3 della Politica di backup e ripristino per PMI per i test di ripristino trimestrali, la clausola 8.2.2 per la conservazione delle evidenze e la clausola 6.3.1.1 per lo storage multi-ubicazione. Utilizza la clausola 5.2.1.4 della Politica di continuità operativa e disaster recovery per PMI per gli obiettivi RTO/RPO e la clausola 6.4.2 per le lezioni apprese e gli aggiornamenti del BCP.
| Criterio di test | Obiettivo | Evidenza |
|---|---|---|
| Frequenza del ripristino | Trimestrale | Calendario dei test e piano approvato |
| RTO | 4 ore | Ora di inizio, ora di fine, tempo di ripristino trascorso |
| RPO | 1 ora | Marcatura temporale del backup e validazione delle transazioni |
| Ubicazioni | Fonti di backup locali e cloud disponibili | Report del repository di backup |
| Integrità | Superamento dei controlli di coerenza del database | Log di validazione |
| Applicazione | L’utente Finance può approvare un pagamento di test | Approvazione della validazione aziendale |
| Sicurezza | Logging, controllo degli accessi e segreti validati dopo il ripristino | Checklist di sicurezza e screenshot |
Step 5: eseguire il ripristino e registrare i fatti
Il ripristino viene eseguito in un ambiente di ripristino isolato. Il team registra marcature temporali, identificativi dei set di backup, passaggi di ripristino, errori, risultati di validazione e approvazioni.
Una solida registrazione del test di ripristino deve includere:
| Campo del test di ripristino | Esempio |
|---|---|
| ID test | Q2-2026-PAY-RESTORE |
| Sistema testato | Piattaforma di approvazione dei pagamenti |
| Set di backup utilizzato | Backup della piattaforma di pagamento dal punto di ripristino approvato |
| Ubicazione del ripristino | Ambiente di ripristino isolato |
| Obiettivo RTO | 4 ore |
| Obiettivo RPO | 1 ora |
| Tempo effettivo di ripristino | 2 ore e 45 minuti |
| Punto effettivo di ripristino | 42 minuti |
| Validazione dell’integrità | Controlli di coerenza del database superati |
| Validazione aziendale | Utente Finance ha approvato il pagamento di test |
| Validazione di sicurezza | Logging, controllo degli accessi, segreti e monitoraggio confermati |
| Esito | Superato con riserva |
| Approvazione | CISO, Responsabile infrastruttura, Titolare Finance Operations |
Durante il test, il team rileva un problema. L’applicazione ripristinata non riesce a inviare e-mail di notifica perché la lista di autorizzazione del relay e-mail non include la sottorete di ripristino. L’approvazione core dei pagamenti funziona, ma il workflow risulta degradato.
Step 6: registrare lezioni apprese e azione correttiva
È qui che molte organizzazioni si fermano troppo presto. L’approccio di Clarysec spinge il problema nel sistema di miglioramento.
Nella fase Audit, riesame e miglioramento, Step 29, Miglioramento continuo, il Zenith Blueprint utilizza un registro CAPA per tracciare descrizione del problema, causa radice, azione correttiva, titolare, data obiettivo e stato.
| Campo CAPA | Esempio |
|---|---|
| Descrizione del problema | La piattaforma di pagamento ripristinata non riusciva a inviare notifiche e-mail dalla sottorete di ripristino |
| Causa radice | Rete di ripristino non inclusa nella progettazione della lista di autorizzazione del relay e-mail |
| Azione correttiva | Aggiornare l’architettura di ripristino e la procedura della lista di autorizzazione del relay e-mail |
| Titolare | Responsabile infrastruttura |
| Data obiettivo | 15 giorni lavorativi |
| Stato | Aperto in attesa di nuovo test |
Questo singolo test di ripristino produce ora una catena di evidenze pronta per l’audit: requisito di policy, conferma dell’ambito, mappatura del rischio, mappatura SoA, piano di test, registrazione dell’esecuzione, validazione aziendale, validazione di sicurezza, registrazione del problema, azione correttiva e aggiornamento del BCP.
Come auditor diversi esaminano le stesse evidenze
Un solido pacchetto di evidenze anticipa la prospettiva dell’auditor.
Un auditor ISO 27001:2022 inizierà di norma dal sistema di gestione. Chiederà se i requisiti di backup e ripristino sono compresi nell’ambito, basati sul rischio, attuati, monitorati, sottoposti ad audit interno e migliorati. Si aspetterà tracciabilità dal registro dei rischi alla SoA fino alle registrazioni operative. Potrebbe anche collegare test falliti e azioni correttive alla clausola 10.2 di ISO/IEC 27001:2022 su non conformità e azioni correttive.
Un auditor DORA si concentrerà sulla resilienza operativa digitale per funzioni critiche o importanti. Vorrà vedere ripristino a livello di servizio, dipendenze da terze parti ICT, test basati su scenari, supervisione dell’organo di gestione ed evidenze dell’efficacia delle procedure di ripristino.
Una prospettiva di vigilanza NIS2 cercherà misure di gestione dei rischi di cibersicurezza adeguate e proporzionate. Le evidenze di backup e Disaster Recovery devono dimostrare che i servizi essenziali o importanti possono mantenere o ripristinare le operazioni dopo incidenti, con la direzione consapevole del rischio residuo.
Un valutatore orientato a NIST si concentrerà sugli esiti di cibersicurezza attraverso Identificare, Proteggere, Rilevare, Rispondere e Ripristinare. Potrebbe chiedere informazioni su backup immutabili, accessi privilegiati ai repository di backup, ripristino in ambienti puliti, comunicazioni e lezioni apprese.
Un auditor in stile COBIT 2019 o ISACA porrà enfasi su governance, titolarità dei processi, metriche, reportistica alla direzione e tracciamento delle criticità. Sarà meno colpito da un ripristino tecnicamente elegante se titolarità e reportistica non sono chiare.
Le stesse evidenze possono soddisfare tutte queste prospettive, ma solo se sono complete.
Errori comuni nei test di ripristino che generano risultanze di audit
Clarysec osserva ripetutamente le stesse lacune evitabili nelle evidenze.
| Schema di errore | Perché crea rischio di audit | Correzione pratica |
|---|---|---|
| Il successo del backup è trattato come successo del ripristino | Il completamento della copia non dimostra la recuperabilità | Eseguire test di ripristino documentati con validazione |
| RTO e RPO sono definiti ma non testati | Gli obiettivi di continuità possono essere irrealistici | Misurare durante i test il tempo effettivo di ripristino e il punto di ripristino |
| Solo l’infrastruttura valida il ripristino | Il processo aziendale può restare inutilizzabile | Richiedere l’approvazione del titolare del processo aziendale per i sistemi critici |
| Le registrazioni dei test sono disperse | Gli auditor non possono verificare la coerenza | Utilizzare un modello standard di rapporto di test di ripristino e un repository delle evidenze |
| I test falliti vengono discussi ma non tracciati | Mancano evidenze di miglioramento continuo | Registrare le criticità in CAPA con titolare, scadenza e nuovo test |
| I backup sono archiviati in un unico dominio di guasto logico | Ransomware o errata configurazione possono distruggere la recuperabilità | Utilizzare ubicazioni segregate, storage immutabile e controllo degli accessi |
| Le dipendenze sono escluse | Le applicazioni ripristinate potrebbero non funzionare | Mappare identità, DNS, segreti, certificati, integrazioni e logging |
| La sicurezza viene ignorata durante il ripristino | I servizi ripristinati possono essere vulnerabili o non monitorati | Includere la validazione di sicurezza post-ripristino |
L’obiettivo non è la burocrazia. L’obiettivo è un ripristino affidabile sotto pressione ed evidenze sostenibili in sede di audit.
Costruire un pacchetto di evidenze di ripristino per il consiglio di amministrazione
I dirigenti non hanno bisogno di log grezzi dei backup. Hanno bisogno di assurance sul fatto che i servizi critici siano recuperabili, le eccezioni siano note e le azioni di miglioramento stiano avanzando.
Per ciascun servizio critico, riportare:
- Nome del servizio e titolare del processo aziendale
- Criticità dalla BIA
- RTO e RPO approvati
- Data dell’ultimo test di ripristino
- RTO e RPO conseguiti
- Risultato del test
- Azioni correttive aperte
- Dipendenze da terze parti che incidono sul ripristino
- Dichiarazione del rischio residuo
- Prossimo test pianificato
| Servizio critico | RTO/RPO | Ultimo test | Risultato | Criticità aperta | Messaggio alla direzione |
|---|---|---|---|---|---|
| Piattaforma di approvazione dei pagamenti | 4h/1h | 2026-04-12 | Superato con riserva | Lista di autorizzazione del relay e-mail per la sottorete di ripristino | Approvazione core dei pagamenti ripristinata entro l’obiettivo, remediation del workflow di notifica in corso |
| Portale clienti | 8h/2h | 2026-03-20 | Fallito | Ripristino del database oltre l’RTO di 90 minuti | Necessario migliorare capacità e processo di ripristino |
| Ripristino del provider di identità | 2h/15m | 2026-04-05 | Superato | Nessuno | Supporta il ripristino dei servizi critici dipendenti |
Questo stile di reportistica crea un ponte tra team tecnici, auditor e leadership. Supporta inoltre il riesame della direzione del SGSI e la supervisione della resilienza ai sensi di NIS2 e DORA.
Checklist pratica di audit per i prossimi 30-90 giorni
Se il tuo audit si avvicina, parti dalle evidenze già disponibili e chiudi prima le lacune a rischio più elevato.
- Identificare tutti i sistemi critici e ad alto impatto dalla BIA.
- Confermare RTO e RPO per ciascun sistema critico.
- Verificare che ogni sistema critico compaia nel Piano generale dei backup.
- Confermare le ubicazioni dei backup, inclusi repository locali, cloud, immutabili o segregati.
- Selezionare almeno un test di ripristino recente per ciascun servizio critico o pianificarne immediatamente uno.
- Assicurare che le registrazioni dei test di ripristino mostrino ambito, marcature temporali, set di backup, risultato, RTO/RPO conseguiti e validazione.
- Ottenere l’approvazione del titolare del processo aziendale per il ripristino a livello applicativo.
- Validare la sicurezza dopo il ripristino, includendo controllo degli accessi, logging, monitoraggio, segreti, certificati ed esposizione alle vulnerabilità.
- Mappare le evidenze al registro dei rischi e alla SoA.
- Registrare le criticità in CAPA, assegnare titolari e tracciare il nuovo test.
- Sintetizzare i risultati per il riesame della direzione.
- Preparare una vista di cross-compliance per le conversazioni di audit su ISO 27001:2022, NIS2, DORA, NIST CSF e COBIT 2019.
Se non riesci a completare ogni punto prima dell’audit, sii trasparente. Gli auditor di solito rispondono meglio a una lacuna documentata con un piano di azione correttiva che a vaghe dichiarazioni di maturità.
Rendere i test di ripristino la tua evidenza di resilienza più forte
I test di backup e ripristino sono uno dei modi più chiari per dimostrare la resilienza operativa. Sono tangibili, misurabili, rilevanti per il business e direttamente collegati a ISO 27001:2022, NIS2, DORA, NIST, COBIT 2019, reportistica al consiglio di amministrazione, assurance verso i clienti e aspettative degli assicuratori.
Ma solo se sono documentati correttamente.
Clarysec aiuta le organizzazioni a trasformare le operazioni di backup in evidenze pronte per l’audit tramite la Politica di backup e ripristino, la Politica di backup e ripristino per PMI, la Politica di continuità operativa e disaster recovery per PMI, Zenith Blueprint e Zenith Controls.
La prossima azione pratica è semplice. Scegli un servizio critico questa settimana. Esegui un test di ripristino rispetto ai suoi RTO e RPO approvati. Documenta il risultato. Mappalo al registro dei rischi e alla SoA. Registra ogni lezione appresa.
Se vuoi che questo processo sia ripetibile su ISO 27001:2022, NIS2, DORA, NIST e COBIT 2019, il toolkit di Clarysec ti fornisce la struttura per dimostrare il ripristino senza costruire da zero un labirinto di conformità.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
