ISO/IEC 27001:2022 e continuità operativa: guida completa

TL;DR

La revisione ISO/IEC 27001:2022 ha riorganizzato i controlli dell'Annex A e ha introdotto A.5.30 — ICT readiness for business continuity, il controllo che chiede esplicitamente capacità tecnica di ripristino ICT. Insieme a A.8.13 — Information backup e A.8.14 — Redundancy of information processing facilities, definisce gli obblighi DR per chi è certificato. Questa guida copre cosa chiedono questi tre controlli, come si traducono in evidenze concrete e come arrivare al recertification audit senza panico.

Cosa è cambiato fra ISO 27001:2013 e 2022

La 2022 ha tre novità rilevanti per il DR:

• Annex A ridotto: da 114 a 93 controlli, riorganizzati in 4 cluster (organizzativi, persone, fisici, tecnologici).
• 11 nuovi controlli, tra cui A.5.30 (ICT readiness for business continuity) e A.8.16 (monitoring activities).
• Allineamento con ISO 22301 sulla terminologia di continuità operativa.

Le aziende certificate hanno avuto 3 anni dalla pubblicazione (ottobre 2022) per migrare. Da ottobre 2025 il vecchio standard 2013 non è più valido. Significa che nel 2026 chi è ancora con la 2013 è decertificato di fatto.

I tre controlli DR-rilevanti

A.5.30 — ICT readiness for business continuity

Il controllo nuovo che ha messo in difficoltà metà delle aziende certificate. Chiede di:

• definire obiettivi misurabili di continuità ICT (RTO, RPO);
• pianificare e implementare le capacità tecniche per raggiungerli;
• esercitare e verificare regolarmente le capacità.

In termini concreti significa: un piano DR scritto + un calendario di test + verbali dei test. Senza i verbali l'auditor segna NC (non conformità).

A.8.13 — Information backup

Il classico backup, ma con tre richieste specifiche:

• strategia di backup documentata, allineata alla politica di continuità;
• backup memorizzati in modo da resistere agli stessi eventi che potrebbero impattare l'origine (off-site cifrato);
• verifica periodica del ripristino dai backup.

Quest'ultima è quella che fa cadere più audit: avere il backup non basta, serve evidenza di test di ripristino.

A.8.14 — Redundancy of information processing facilities

Le strutture ICT critiche devono avere ridondanza sufficiente a soddisfare gli obiettivi di disponibilità. Si applica a infrastruttura di rete, alimentazione, raffreddamento e — per chi sta in cloud — alla scelta di provider con SLA documentati.

Cosa cerca davvero un auditor

Gli auditor seri non leggono le policy in stage 1. Cercano 5 evidenze:

1. Piano DR firmato dal management, datato negli ultimi 12 mesi.
2. Verbale dell'ultimo test DR con tempi misurati e azioni correttive aperte/chiuse.
3. Politica di backup che dichiari frequenze, retention, off-site, verifica.
4. Risultato di un restore di test (file estratto, hash verificato, log di sistema).
5. Mapping dei controlli ICT alla BIA dei processi business.

Se queste 5 evidenze sono in ordine, l'audit del cluster continuità si chiude in mezza giornata.

La BIA come fondazione

Tutti i controlli DR di ISO 27001 partono dalla Business Impact Analysis. Senza una BIA solida non si può difendere RTO e RPO dichiarati.

Una BIA leggera ma sufficiente per la 27001 deve includere:

• elenco dei processi business critici (10-20 max per PMI);
• per ciascuno: massima durata di interruzione tollerabile (MTPD), RTO, RPO;
• dipendenze ICT (quali sistemi, quali dati);
• impatto in euro al giorno e al picco;
• approvazione del management.

Tre giorni di lavoro, due workshop con i process owner.

Errori che fanno cadere l'audit

I cinque errori più frequenti nel cluster continuità:

• piano DR generico, copiato da template senza personalizzazione;
• test DR mai documentati, oppure documentati senza tempi misurati;
• backup non verificati, o verificati con check superficiali ("il job è andato bene");
• runbook incompleti (mancano credenziali, contatti, ordine restart);
• mappatura BIA → DR mancante: controlli adottati ma non riconducibili a un processo critico.

Come si arriva pronti in 6 mesi

Un piano operativo per le aziende che partono quasi da zero:

• mese 1-2: BIA, redazione policy continuità, scelta soluzione DR.
• mese 3-4: deploy DR, runbook, primo test interno.
• mese 5: test ufficiale documentato, formazione del personale operativo.
• mese 6: pre-audit con consulente esterno, correzione gap, audit certification.

Sei mesi sono il minimo realistico. Sotto i 4 mesi si bara su qualcosa.

Come Sefthy aiuta a coprire questi controlli

Sefthy è costruita esplicitamente per chi punta a una 27001:

• piano DR template generato dal Console al deploy;
• test trimestrali pre-pianificati con verbali esportabili;
• DeepVerify per la verifica periodica dell'integrità dei backup;
• report di restore automatici;
• certificazioni del provider: ISO 27001:2022, 27017, 27018, 9001 — il provider stesso copre A.8.14 sul cloud sovrano italiano.

In sostanza: il cluster continuità della vostra 27001 lo costruisce il vostro fornitore DR. Sceglietelo certificato.

FAQ

Quanto pesa il cluster continuità nell'audit complessivo?

Negli audit del 2025-2026 stiamo vedendo che 5-8 ore su 25-30 dell'audit di certificazione sono dedicate al cluster continuità. È il singolo cluster che ha più non conformità.

Posso avere ISO 27001 senza un fornitore DR esterno?

Sì, se gestite l'infrastruttura ridondata in proprio. È una strada più costosa ma legittima. La 27001 è agnostica rispetto al fornitore.

A.5.30 si applica anche se ho un sito secondario fisico?

Sì. La presenza di un sito secondario non sostituisce le evidenze richieste: piano DR, test, runbook.

Il certificato del provider DR è prova sufficiente per A.8.14?

È una prova significativa ma non sufficiente: serve anche la due diligence documentata sulla scelta del provider, in linea con A.5.19-5.23.

Vuoi vedere come Sefthy si mappa sui controlli ISO 27001? Leggi Annex A.5.30 ICT readiness o ISO 27001 vs 27017 vs 27018.