Evidenze di audit cloud per ISO 27001, NIS2 e DORA

Maria, CISO di una società di analisi finanziaria in rapida crescita, aveva sei settimane prima che tre scadenze convergessero. L’audit di sorveglianza ISO 27001:2022 era già pianificato. NIS2 aveva portato l’azienda a un nuovo livello di responsabilità della direzione in quanto entità importante. DORA stava per verificare se le sue operazioni fintech fossero in grado di dimostrare la resilienza operativa digitale. Allo stesso tempo, un importante cliente enterprise teneva sospeso un contratto finché il suo team non avesse superato un riesame dettagliato di assurance sulla sicurezza.

L’azienda non era insicura. Eseguiva carichi di lavoro di produzione in AWS e Azure, utilizzava Microsoft 365 e diverse piattaforme SaaS critiche, applicava MFA, eseguiva backup dei dati, effettuava scansioni delle vulnerabilità e raccoglieva log cloud. Il problema erano le evidenze.

Le evidenze erano disperse tra screenshot in Slack, pagine wiki degli sviluppatori, esportazioni dalle console cloud, cartelle procurement, contratti legali e rassicurazioni verbali dei proprietari delle piattaforme. Quando un auditor chiedeva: “Mostratemi come controllate il vostro ambiente cloud”, un link alla pagina di conformità di un fornitore cloud non era sufficiente. I certificati del fornitore dimostravano i controlli del fornitore. Non dimostravano la parte di responsabilità di Maria nel modello di responsabilità condivisa.

È qui che molti programmi di evidenze di audit per la sicurezza cloud falliscono. Non perché manchino i controlli, ma perché l’organizzazione non riesce a dimostrare, in modo strutturato e tracciabile, quali responsabilità spettano al fornitore, quali al cliente, come sono configurati i controlli SaaS e IaaS, come sono applicati gli impegni dei fornitori e come le evidenze sono conservate per auditor, autorità di vigilanza e clienti.

La conformità cloud non è più un’appendice tecnica. Per un fornitore SaaS soggetto a NIS2, un’entità finanziaria soggetta a DORA o qualsiasi organizzazione ISO 27001:2022 che utilizza IaaS, PaaS e SaaS, la governance cloud fa parte del campo di applicazione del SGSI, del piano di trattamento del rischio, del ciclo di vita dei fornitori, del processo di gestione degli incidenti, della responsabilità in materia di privacy e del riesame della direzione.

L’obiettivo pratico è semplice: costruire un’unica architettura di evidenze cloud pronta per le autorità di vigilanza, capace di rispondere alle domande di ISO 27001:2022, NIS2, DORA, GDPR, assurance dei clienti e audit interno senza ricostruire le evidenze per ogni quadro di riferimento.

Il cloud è sempre nel campo di applicazione, anche quando l’infrastruttura è esternalizzata

La prima trappola di audit consiste nel presumere che l’infrastruttura esternalizzata sia fuori dal SGSI. Non lo è. L’esternalizzazione modifica il perimetro di controllo, non elimina la responsabilità.

ISO/IEC 27001:2022 richiede all’organizzazione di definire il proprio contesto, le parti interessate, il campo di applicazione del SGSI, le interfacce, le dipendenze e i processi. In un’azienda cloud-first, il provider di identità, l’account di hosting cloud, il CRM, la piattaforma e-mail, il data warehouse, la pipeline CI/CD, lo strumento di ticketing e il servizio di backup costituiscono spesso infrastruttura aziendale core.

Zenith Blueprint: An Auditor’s 30-Step Roadmap di Clarysec Zenith Blueprint chiarisce questo punto nella fase ISMS Foundation & Leadership, Step 2, Stakeholder Needs and ISMS Scope:

“Se esternalizzi la tua infrastruttura informatica a un fornitore cloud, ciò non la esclude dal campo di applicazione; al contrario, includi la gestione di tale rapporto e gli asset cloud nel campo di applicazione, perché la sicurezza dei tuoi dati nel cloud resta una tua responsabilità.”

Questa affermazione è un punto di riferimento per l’audit. Il campo di applicazione non dovrebbe dire: “AWS è escluso perché lo gestisce Amazon”. Dovrebbe affermare che gli asset informativi e i processi relativi ai servizi ospitati su AWS sono inclusi nel campo di applicazione, compresa la gestione dei controlli di sicurezza cloud, identità, logging, cifratura, backup, assurance dei fornitori e risposta agli incidenti.

Per ISO 27001:2022, questo supporta le clausole 4.1-4.4 su contesto, parti interessate, campo di applicazione e processi del SGSI. Per NIS2, supporta le aspettative di Article 21 in materia di analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e manutenzione sicure, controllo degli accessi, gestione degli asset, crittografia, efficacia dei controlli e MFA ove appropriato. Per DORA, supporta il principio secondo cui le entità finanziarie restano responsabili del rischio ICT anche quando i servizi ICT sono esternalizzati.

La domanda non è se il tuo fornitore cloud sia sicuro. La domanda è se governi il tuo utilizzo del fornitore, configuri correttamente la tua parte, monitori il servizio, gestisci gli impegni dei fornitori e conservi le evidenze.

La responsabilità condivisa deve diventare evidenza condivisa

I fornitori cloud spiegano la responsabilità condivisa. Gli auditor verificano se l’hai resa operativa.

In IaaS, il fornitore di norma protegge le strutture fisiche, l’infrastruttura core e l’hypervisor. Il cliente controlla identità, configurazione dei carichi di lavoro, hardening del sistema operativo, sicurezza applicativa, classificazione dei dati, impostazioni di cifratura, regole di rete, logging, backup, applicazione delle patch e risposta agli incidenti.

In SaaS, il fornitore controlla la maggior parte delle operazioni della piattaforma, ma il cliente controlla comunque la configurazione del tenant, gli utenti, i ruoli amministrativi, le integrazioni, la condivisione dei dati, la conservazione, le opzioni di logging e le procedure di escalation.

Zenith Controls: The Cross-Compliance Guide di Clarysec Zenith Controls tratta il controllo ISO/IEC 27002:2022 5.23, sicurezza delle informazioni per l’utilizzo dei servizi cloud, come un controllo centrale di governance cloud con finalità preventiva su riservatezza, integrità e disponibilità. Collega i servizi cloud ai rapporti con i fornitori, al trasferimento sicuro delle informazioni, all’inventario degli asset, alla prevenzione della perdita di dati, alla sicurezza degli endpoint e della rete e alle pratiche di sviluppo sicuro.

Una interpretazione chiave di Zenith Controls afferma:

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

Questa distinzione è fondamentale. I soli certificati dei fornitori non soddisfano Annex A.5.23. Servono evidenze lato cliente che dimostrino che il servizio cloud è governato, configurato, monitorato e riesaminato.

Questa è la differenza tra disporre di controlli cloud e disporre di controlli cloud pronti per l’audit.

Parti da un registro dei servizi cloud utilizzabile dagli auditor

Il modo più rapido per migliorare la preparazione agli audit cloud è creare un registro dei servizi cloud completo. Non deve essere un elenco di procurement o un’esportazione della funzione finance. Deve collegare i servizi cloud a dati, proprietari, regioni, accessi, contratti, criticità, rilevanza normativa ed evidenze.

La Policy per l’utilizzo del cloud per PMI di Clarysec Policy per l’utilizzo del cloud per PMI fornisce una baseline compatta e adatta all’audit nella clausola 5.3:

“Il fornitore IT o il direttore generale deve mantenere un registro dei servizi cloud. Il registro deve riportare: 5.3.1 Il nome e la finalità di ciascun servizio cloud approvato 5.3.2 La persona o il team responsabile (proprietario dell’applicazione) 5.3.3 I tipi di dati archiviati o trattati 5.3.4 Il Paese o la regione in cui i dati sono archiviati 5.3.5 Le autorizzazioni di accesso degli utenti e gli account amministrativi 5.3.6 I dettagli contrattuali, le date di rinnovo e i contatti di supporto”

Per gli ambienti enterprise, la Policy per l’utilizzo del cloud di Clarysec Policy per l’utilizzo del cloud stabilisce il mandato più ampio:

“La presente policy stabilisce i requisiti obbligatori dell’organizzazione per l’utilizzo sicuro, conforme e responsabile dei servizi di cloud computing nei modelli di erogazione Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) e Software-as-a-Service (SaaS).”

La Policy per l’utilizzo del cloud richiede un registro centralizzato sotto la responsabilità della CISO e configurazioni di baseline approvate per gli ambienti cloud. Tale registro diventa la base probatoria per più obblighi contemporaneamente.

Per ISO 27001:2022, supporta inventario degli asset, governance dell’utilizzo del cloud, rapporti con i fornitori, controllo degli accessi, requisiti legali e contrattuali, trattamento del rischio e informazioni documentate. Per NIS2, supporta sicurezza della catena di fornitura, gestione degli asset, analisi dei rischi, gestione degli incidenti e continuità. Per DORA, supporta la mappatura degli asset ICT e delle dipendenze, i registri delle terze parti ICT, la mappatura delle funzioni critiche o importanti e l’analisi del rischio di concentrazione. Per GDPR, identifica se sono trattati dati personali, dove si trovano, quale fornitore agisce come responsabile del trattamento e quali condizioni di trasferimento o trattamento dei dati si applicano.

Se il registro non identifica categorie di dati e regioni, le evidenze privacy e di resilienza saranno incomplete. Se non identifica i proprietari delle applicazioni, i riesami degli accessi resteranno senza titolare. Se non identifica contratti e date di rinnovo, le clausole di sicurezza dei fornitori non potranno essere verificate.

Trasforma ISO 27001:2022 nella dorsale delle evidenze cloud

ISO 27001:2022 è la migliore dorsale per le evidenze cloud perché collega contesto aziendale, rischio, controlli, evidenze operative, monitoraggio e miglioramento.

I principali requisiti ISO 27001:2022 rilevanti per il cloud includono:

• Clausole 4.1-4.4 per contesto, parti interessate, campo di applicazione del SGSI, interfacce, dipendenze e processi.
• Clausole 5.1-5.3 per leadership, policy, ruoli, responsabilità e accountability.
• Clausole 6.1.1-6.1.3 per valutazione del rischio, trattamento del rischio, confronto con Annex A, Dichiarazione di Applicabilità e accettazione del rischio residuo.
• Clausola 7.5 per informazioni documentate controllate.
• Clausole 8.1-8.3 per pianificazione operativa, esecuzione della valutazione del rischio ed esecuzione del trattamento del rischio.
• Clausole 9.1-9.3 per monitoraggio, misurazione, audit interno e riesame della direzione.
• Clausola 10 per non conformità, azione correttiva e miglioramento continuo.

I controlli Annex A che sostengono maggiormente le evidenze cloud includono A.5.19 sicurezza delle informazioni nei rapporti con i fornitori, A.5.20 gestione della sicurezza delle informazioni negli accordi con i fornitori, A.5.21 gestione della sicurezza delle informazioni nella catena di fornitura ICT, A.5.22 monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori, A.5.23 sicurezza delle informazioni per l’utilizzo dei servizi cloud, A.5.24-A.5.27 gestione degli incidenti, A.5.29 sicurezza delle informazioni durante le interruzioni, A.5.30 prontezza ICT per la continuità operativa, A.5.31 requisiti legali, statutari, normativi e contrattuali, A.5.34 privacy e protezione dei dati personali identificabili, A.5.36 conformità a policy, regole e standard per la sicurezza delle informazioni, A.8.8 gestione delle vulnerabilità tecniche, A.8.9 gestione della configurazione, A.8.13 backup delle informazioni, A.8.15 logging, A.8.16 attività di monitoraggio, A.8.24 uso della crittografia, A.8.25 ciclo di vita dello sviluppo sicuro, A.8.29 test di sicurezza nello sviluppo e nell’accettazione e A.8.32 gestione delle modifiche.

In Zenith Blueprint, la fase Controls in Action, Step 23, spiega i servizi cloud con un linguaggio efficace per gli auditor:

“Il passaggio ai servizi cloud introduce cambiamenti profondi nel modello di fiducia. Non controlli più il server, il perimetro di rete o l’hypervisor. Spesso non sai nemmeno dove risiedano fisicamente i dati. Ciò che controlli, e ciò che questo controllo impone, è la governance di quel rapporto, la visibilità su ciò che utilizzi e le aspettative di sicurezza che stabilisci per i tuoi fornitori.”

Una voce solida della Dichiarazione di Applicabilità per A.5.23 non dovrebbe limitarsi a dire “Applicabile, fornitore cloud certificato”. Deve spiegare perché il controllo si applica, quali rischi tratta, come è attuato e dove sono conservate le evidenze.

Aggiungi una colonna sulla posizione delle evidenze nella SoA o nello strumento di tracciamento dei controlli. Gli auditor non dovrebbero dover cercare in e-mail, sistemi di ticketing e unità condivise per trovare le prove.

Usa un unico modello di evidenze per ISO 27001:2022, NIS2 e DORA

NIS2 e DORA richiedono entrambe una cibersicurezza documentata, basata sul rischio e guidata dalla direzione. La sovrapposizione è significativa, ma la pressione di vigilanza è diversa.

NIS2 si applica a molte entità essenziali e importanti nell’UE, compresi fornitori di infrastrutture digitali, prestatori di servizi gestiti, Managed Security Services, banche, infrastrutture dei mercati finanziari e fornitori digitali. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, tra cui analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e manutenzione sicure, trattamento delle vulnerabilità, valutazione dell’efficacia dei controlli, igiene informatica, formazione, crittografia, controllo degli accessi, gestione degli asset e MFA o comunicazioni protette ove appropriato.

Per le evidenze di audit sulla sicurezza cloud, NIS2 verifica se i rischi cloud e dei fornitori sono gestiti come parte del rischio di erogazione del servizio. Introduce inoltre una segnalazione strutturata degli incidenti significativi, compresi preallarme entro 24 ore, notifica dell’incidente entro 72 ore e relazione finale entro un mese.

DORA si applica dal 17 gennaio 2025 a molte entità finanziarie dell’UE e crea requisiti uniformi per gestione del rischio ICT, segnalazione degli incidenti ICT rilevanti, test di resilienza operativa digitale, condivisione delle informazioni e rischio ICT di terze parti. Per le entità finanziarie identificate anche ai sensi di NIS2, DORA è considerato l’atto giuridico dell’Unione settoriale specifico per gli obblighi operativi sovrapposti.

Per il cloud, DORA è diretto. Le entità finanziarie restano responsabili del rischio ICT quando i servizi sono esternalizzati. Hanno bisogno di strategie per le terze parti ICT, registri contrattuali, valutazioni precontrattuali, due diligence, diritti di audit e accesso, trigger di risoluzione, analisi del rischio di concentrazione, controlli sul subappalto e strategie di uscita testate.

Zenith Controls mappa il controllo ISO/IEC 27002:2022 5.23 su NIS2 Article 21 dell’UE e DORA Articles 28 to 31. Indica inoltre standard di supporto come ISO/IEC 27017 per ruoli di sicurezza cloud e monitoraggio, ISO/IEC 27018 per la protezione dei dati personali identificabili nel cloud pubblico, ISO/IEC 27701 per la gestione della privacy nei rapporti con responsabili del trattamento in cloud, ISO/IEC 27036-4 per il monitoraggio dei servizi cloud e gli accordi con i fornitori, e ISO/IEC 27005 per la valutazione del rischio cloud.

L’implicazione pratica è semplice. Non costruire pacchetti di evidenze separati per ISO 27001:2022, NIS2, DORA e GDPR. Costruisci un’unica architettura di evidenze cloud con mappature specifiche per ciascun quadro di riferimento.

I contratti con i fornitori sono evidenze di controllo, non archivi legali

Le evidenze di audit cloud spesso si interrompono a livello contrattuale. La funzione sicurezza ha un questionario di sicurezza del fornitore. La funzione legale ha il MSA. Il procurement ha la data di rinnovo. Il DPO ha il DPA. Nessuno dispone di una vista unica che dica se l’accordo include le clausole di sicurezza richieste da ISO 27001:2022, NIS2, DORA e GDPR.

La Policy di sicurezza per terze parti e fornitori per PMI di Clarysec Policy di sicurezza per terze parti e fornitori per PMI afferma nella clausola 5.3:

“I contratti devono includere clausole obbligatorie che coprano: 5.3.1 Riservatezza e non divulgazione 5.3.2 Obblighi di sicurezza delle informazioni 5.3.3 Tempistiche di notifica della violazione dei dati personali (ad es. entro 24–72 ore) 5.3.4 Diritto di audit o disponibilità di evidenze di conformità 5.3.5 Restrizioni a ulteriori subappalti senza approvazione 5.3.6 Termini di risoluzione, compresa la restituzione o distruzione sicura dei dati”

Per coerenza di audit, traduci tali clausole in una matrice di riesame contrattuale. ISO 27001:2022 Annex A.5.20 si aspetta che i requisiti di sicurezza siano concordati con i fornitori. GDPR Article 28 richiede condizioni per il responsabile del trattamento riguardanti riservatezza, misure di sicurezza, assistenza, sub-responsabili, cancellazione o restituzione dei dati e supporto agli audit. DORA Article 30 richiede disposizioni contrattuali dettagliate per i fornitori terzi ICT, incluse descrizioni dei servizi, localizzazione dei dati, sicurezza, assistenza sugli incidenti, cooperazione con le autorità, diritti di audit, diritti di accesso, risoluzione e accordi di transizione. Anche la sicurezza della catena di fornitura prevista da NIS2 richiede cooperazione applicabile da parte dei fornitori.

Zenith Controls mappa il controllo ISO/IEC 27002:2022 5.20 sugli accordi con i fornitori e rileva i collegamenti con 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à.

Il punto chiave è l’operativizzazione. Se un contratto cloud concede accesso ai report SOC 2, gli auditor possono chiedere se il report è stato ottenuto, se le eccezioni sono state riesaminate, se le remediation sono state tracciate e se il rischio è stato rivalutato. Se il contratto promette la notifica della violazione, possono chiedere se il playbook di incidente include il percorso di contatto del fornitore e i punti decisionali regolamentari. Se le modifiche ai subappaltatori richiedono approvazione o preavviso, possono chiedere se le notifiche dei sub-responsabili sono riesaminate prima dell’accettazione.

Un contratto senza evidenze di riesame è un archivio. Un contratto collegato al rischio del fornitore, alle registrazioni di monitoraggio e ai workflow di incidente è un controllo.

Logging e configurazione SaaS sono punti ciechi comuni negli audit

Le risultanze cloud spesso derivano dal SaaS, non dall’IaaS. I team infrastrutturali di solito dispongono di proprietari tecnici, pipeline di logging, controlli di baseline e registrazioni delle modifiche. Le piattaforme SaaS sono frammentate tra vendite, HR, finanza, customer success, marketing e operations. Ciascuna può trattare dati sensibili o regolamentati.

La Policy di logging e monitoraggio per PMI di Clarysec Policy di logging e monitoraggio per PMI affronta direttamente il tema nella clausola 5.5:

“5.5 Servizi cloud e logging di terze parti 5.5.1 Per le piattaforme in cui il logging non è sotto il controllo diretto dell’IT (ad es. e-mail SaaS), si applicano i seguenti requisiti: 5.5.1.1 Il logging deve essere abilitato e configurato ove disponibile 5.5.1.2 Gli alert devono essere instradati al fornitore di supporto IT 5.5.1.3 I contratti devono richiedere ai fornitori di conservare i log per almeno 12 mesi e fornire accesso su richiesta”

Per le imprese, la Policy per l’utilizzo del cloud aggiunge:

“I servizi cloud devono essere integrati nel SIEM dell’organizzazione per il monitoraggio continuo.”

Questo requisito sposta il SaaS da “strumento aziendale” a “sistema informativo monitorato”. Le evidenze devono includere esportazioni delle impostazioni di logging, prova del connettore SIEM, regole di alerting, ticket di triage, impostazioni di conservazione e riesami degli accessi amministrativi.

Per i SaaS critici, prepara evidenze per creazione di account amministrativi, accessi sospetti, download massivi, condivisione pubblica, disabilitazione della MFA, creazione di token API, attività di guest esterni ed elevazione dei privilegi. Per IaaS, prepara CloudTrail o logging equivalente del control plane, log di accesso allo storage, modifiche IAM, flow log ove appropriato, risultanze CSPM, scansioni di vulnerabilità, evidenze di patching, impostazioni di cifratura, stato dei backup, riesami dei security group di rete e ticket di modifica.

La metodologia di audit di Zenith Controls per il controllo 5.23 osserva che un audit in stile ISO/IEC 27007 può ispezionare autorizzazioni dei bucket AWS S3, cifratura, policy IAM e logging CloudTrail. Un auditor orientato a COBIT può riesaminare configurazioni di alerting, controlli DLP, utilizzo di Microsoft 365 Secure Score e log di gestione delle modifiche. Una prospettiva NIST SP 800-53A può testare gestione degli account e monitoraggio, compreso se i carichi di lavoro cloud sono sottoposti a patch, scansioni e monitoraggio con lo stesso rigore dei sistemi interni.

Auditor diversi parlano dialetti diversi. Le tue evidenze devono essere le stesse.

Costruisci un pacchetto di evidenze pronto per le autorità di vigilanza per un servizio SaaS e un servizio IaaS

Un workflow pratico parte da una piattaforma SaaS critica e da un ambiente IaaS critico. Per esempio, Microsoft 365 per la collaborazione e AWS per l’hosting di produzione.

Step 1: aggiorna il registro dei servizi cloud

Per Microsoft 365, registra finalità, proprietario, tipi di dati, regione, account amministrativi, contratto, DPA, contatto di supporto, data di rinnovo e criticità. Per AWS, registra l’account di produzione, le regioni, le categorie di dati, i carichi di lavoro, il proprietario dell’account, lo stato dell’account root, il piano di supporto, le condizioni contrattuali e i servizi aziendali collegati.

Usa i campi della Policy per l’utilizzo del cloud per PMI come dataset minimo. Aggiungi criticità, rilevanza normativa e posizione delle evidenze.

Step 2: documenta la responsabilità condivisa

Per Microsoft 365, le responsabilità del cliente includono ciclo di vita degli utenti, MFA, accesso condizionale, condivisione guest, etichette di conservazione, DLP ove utilizzata, logging ed escalation degli incidenti. Per AWS, le responsabilità del cliente includono IAM, regole di rete, hardening dei carichi di lavoro, configurazione della cifratura, backup, logging, applicazione delle patch e sicurezza applicativa.

Allega la documentazione del fornitore sulla responsabilità condivisa, quindi mappa ogni responsabilità del cliente a un proprietario del controllo e a una fonte di evidenza.

Step 3: acquisisci le evidenze di configurazione

Per Microsoft 365, esporta o acquisisci screenshot delle policy MFA e di accesso condizionale, dei ruoli amministrativi, delle impostazioni di condivisione esterna, del logging di audit, della configurazione di conservazione e delle azioni di security score. Per AWS, esporta la policy delle password IAM, lo stato MFA privilegiato, la configurazione CloudTrail, il blocco dell’accesso pubblico S3, lo stato della cifratura, il riesame dei security group, i job di backup e lo stato delle scansioni di vulnerabilità.

La Policy per l’utilizzo del cloud richiede che gli ambienti cloud rispettino una configurazione di baseline documentata e approvata dall’architetto della sicurezza cloud. Il tuo pacchetto di evidenze deve includere sia la baseline sia la prova di allineamento.

Step 4: collega evidenze dei fornitori e privacy

Allega contratto, DPA, elenco dei sub-responsabili, termini di notifica della violazione, report di assurance dell’audit ed evidenze sulla localizzazione dei dati. Se sono trattati dati personali, registra se il fornitore agisce come responsabile del trattamento, come è gestita la cancellazione, come funziona il supporto alle richieste degli interessati e quali misure di sicurezza per il trasferimento si applicano.

Per DORA, identifica se il servizio cloud supporta una funzione critica o importante. In caso affermativo, collega le evidenze al registro delle terze parti ICT, al fascicolo di due diligence, ai diritti di audit, al piano di exit e al riesame del rischio di concentrazione.

Step 5: collega il logging alla risposta agli incidenti

Dimostra che i log sono abilitati, instradati, riesaminati e utilizzati. Allega dashboard SIEM, regole di alerting e almeno un ticket di alert chiuso. Quindi mappa il workflow ai punti decisionali di segnalazione NIS2 e DORA.

Per NIS2, il processo di incidente deve supportare il preallarme entro 24 ore, la notifica dell’incidente entro 72 ore e una relazione finale entro un mese per gli incidenti significativi. Per DORA, il processo di incidente ICT deve classificare gli incidenti in base a clienti interessati, transazioni, durata, downtime, diffusione geografica, impatto sui dati, criticità del servizio e impatto economico.

Step 6: conserva le evidenze con disciplina

La clausola 6.2 della Policy di audit e monitoraggio della conformità per PMI di Clarysec Policy di audit e monitoraggio della conformità per PMI definisce una disciplina pratica per le evidenze:

“6.2 Raccolta e documentazione delle evidenze 6.2.1 Tutte le evidenze devono essere archiviate in una cartella di audit centralizzata. 6.2.2 I nomi dei file devono indicare chiaramente l’oggetto dell’audit e la data. 6.2.3 I metadati (ad es. chi li ha raccolti, quando e da quale sistema) devono essere documentati. 6.2.4 Le evidenze devono essere conservate per almeno due anni, o più a lungo ove richiesto da certificazioni o accordi con i clienti.”

La Policy di audit e monitoraggio della conformità enterprise Policy di audit e monitoraggio della conformità indica l’obiettivo:

“Generare evidenze sostenibili e una traccia di audit a supporto di richieste delle autorità di vigilanza, procedimenti legali o richieste di assurance dei clienti.”

Uno screenshot chiamato “screenshot1.png” è un’evidenza debole. Un file denominato “AWS-Prod-CloudTrail-Enabled-2026-05-10-CollectedBy-JSmith.png” è più forte perché descrive sistema, controllo, data e soggetto che lo ha raccolto. I metadati contano perché gli auditor devono poter confidare su quando l’evidenza è stata raccolta, da chi e da quale sistema.

Come gli auditor testano lo stesso controllo cloud

I pacchetti di evidenze cloud più solidi sono progettati per più prospettive di audit. Gli auditor ISO 27001:2022 verificano se il controllo è nel SGSI, nella valutazione del rischio, nel trattamento del rischio e nella SoA. I valutatori orientati a NIST verificano l’applicazione tecnica. Gli auditor COBIT 2019 verificano governance, prestazioni dei fornitori e integrazione dei processi. Gli auditor privacy si concentrano su obblighi del responsabile del trattamento, localizzazione dei dati, preparazione alle violazioni e diritti degli interessati. I riesami di vigilanza DORA si concentrano sul rischio ICT di terze parti e sulla resilienza.

Zenith Controls include queste differenze metodologiche di audit per servizi cloud, accordi con i fornitori e monitoraggio dei fornitori. Per 5.22, monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori, evidenzia che gli auditor possono ispezionare verbali di riesame trimestrale dei fornitori, report KPI, valutazioni dei report SOC, registri delle modifiche, valutazioni del rischio, incidenti dei fornitori e tracciamento delle problematiche. Per 5.20, gestione della sicurezza delle informazioni negli accordi con i fornitori, evidenzia campionamenti contrattuali su riservatezza, obblighi di sicurezza, notifica della violazione, diritto di audit, approvazione dei subappaltatori e termini di risoluzione.

Controlli di conformità trasversale che sostengono il carico dell’audit cloud

Un modello di evidenze cloud pronto per le autorità di vigilanza è costruito intorno a un numero ridotto di controlli ad alto impatto. Questi controlli sostengono gran parte del carico di conformità tra ISO 27001:2022, NIS2, DORA, GDPR, NIST e COBIT 2019.

NIST SP 800-53 Rev.5 aggiunge profondità tecnica tramite gestione degli account, servizi di sistemi esterni, monitoraggio continuo, monitoraggio dei sistemi e protezione dei confini. COBIT 2019 aggiunge profondità di governance tramite gestione dei rapporti con i fornitori, rischio dei fornitori, scambio di dati, sicurezza di rete e preparazione ai cambiamenti.

Gli standard ISO di supporto affinano il modello di evidenze. ISO/IEC 27017 fornisce indicazioni specifiche per il cloud su ruoli condivisi, configurazione delle macchine virtuali e monitoraggio delle attività del cliente. ISO/IEC 27018 si concentra sulla protezione dei dati personali identificabili nel cloud pubblico. ISO/IEC 27701 estende gli obblighi privacy alle operazioni di responsabili e titolari del trattamento. ISO/IEC 27036-4 supporta accordi e monitoraggio dei fornitori cloud. ISO/IEC 27005 supporta la valutazione del rischio cloud.

Il riesame della direzione deve vedere il rischio cloud, non solo l’uptime cloud

Uno degli artifact di audit più trascurati è il riesame della direzione. ISO 27001:2022 si aspetta che il riesame della direzione consideri modifiche, esigenze delle parti interessate, tendenze delle prestazioni, risultati degli audit, stato del trattamento del rischio e opportunità di miglioramento. NIS2 richiede agli organi di direzione di approvare le misure di gestione dei rischi di cibersicurezza e supervisionarne l’attuazione. DORA richiede all’organo di gestione di definire, approvare, supervisionare e restare responsabile della gestione del rischio ICT.

Una dashboard trimestrale sulla sicurezza cloud e sui fornitori dovrebbe mostrare:

• Numero di servizi cloud approvati.
• Servizi cloud critici e proprietari.
• Servizi che trattano dati personali.
• Servizi che supportano funzioni critiche o importanti.
• Errate configurazioni cloud ad alto rischio aperte.
• Stato del riesame MFA e degli accessi privilegiati.
• Copertura di logging per piattaforme SaaS e IaaS critiche.
• Report di assurance dei fornitori ricevuti e riesaminati.
• Eccezioni contrattuali e rischi accettati.
• Incidenti cloud, near miss e lezioni apprese.
• Risultati dei test di backup e ripristino.
• Stato del rischio di concentrazione e del piano di exit.

Questa dashboard diventa evidenza per leadership e valutazione delle prestazioni ISO 27001:2022, governance NIS2 e accountability della direzione DORA.

Zenith Blueprint, nella fase Risk Management, Step 14, raccomanda di incrociare i requisiti normativi quando si applicano trattamenti del rischio e policy. Afferma che mappare i principali requisiti normativi sui controlli del SGSI è un esercizio interno utile e “colpisce positivamente auditor/assessor perché mostra che non gestisci la sicurezza nel vuoto, ma sei consapevole del contesto legale”.

È questo il livello di maturità che autorità di vigilanza e clienti enterprise si aspettano.

Risultanze comuni negli audit cloud e come evitarle

Nel lavoro di preparazione agli audit cloud, le risultanze ricorrenti sono prevedibili:

1. Il registro dei servizi cloud esiste, ma mancano gli strumenti SaaS.
2. La localizzazione dei dati non è registrata oppure è copiata da pagine marketing invece che da evidenze contrattuali.
3. La MFA è applicata ai dipendenti, ma non a tutti gli account amministrativi o break glass.
4. I log cloud sono abilitati, ma non riesaminati, conservati o collegati alla risposta agli incidenti.
5. I report SOC dei fornitori sono archiviati, ma non valutati.
6. Le clausole contrattuali esistono per i nuovi fornitori, ma non per i servizi critici legacy.
7. Le notifiche dei sub-responsabili arrivano via e-mail, ma non sono sottoposte a valutazione del rischio.
8. I job di backup vengono eseguiti con successo, ma i test di ripristino non sono evidenziati.
9. La responsabilità condivisa è compresa dagli ingegneri, ma non documentata per gli auditor.
10. La SoA indica i controlli cloud come applicabili, ma non li collega a voci di rischio, evidenze o proprietari.

Sono problemi di tracciabilità. La soluzione consiste nel collegare policy, rischio, controllo, proprietario, evidenza e riesame.

Quando Maria arrivò al giorno dell’audit, non dipendeva più da screenshot sparsi. Aprì una dashboard centrale che mostrava il registro dei servizi cloud, le valutazioni del rischio, le voci SoA, le evidenze della configurazione di baseline, i fascicoli di riesame dei fornitori, le prove di logging e il riesame DORA del rischio di concentrazione. Quando l’auditor chiese come fossero governati i rischi cloud, mostrò il SGSI. Quando l’auditor chiese come i servizi fossero configurati in modo sicuro, mostrò la baseline e le evidenze CSPM. Quando l’auditor chiese del rischio ICT di terze parti, mostrò il riesame contrattuale, il monitoraggio dei fornitori e la pianificazione dell’uscita.

Il risultato non era un ambiente perfetto. Nessun ambiente cloud lo è. La differenza era che le decisioni di rischio erano documentate, le evidenze erano sostenibili e la responsabilità era visibile.

Costruisci il tuo pacchetto di evidenze cloud prima che lo chieda l’auditor

Se la tua organizzazione si basa su SaaS, IaaS o PaaS, il prossimo audit non accetterà “se ne occupa il fornitore” come risposta sufficiente. Devi dimostrare responsabilità condivisa, configurazione lato cliente, clausole dei fornitori, logging, preparazione agli incidenti, resilienza e supervisione della direzione.

Inizia questa settimana con tre azioni pratiche:

1. Crea o aggiorna il registro dei servizi cloud utilizzando la Policy per l’utilizzo del cloud di Clarysec Policy per l’utilizzo del cloud o la Policy per l’utilizzo del cloud per PMI Policy per l’utilizzo del cloud per PMI.
2. Mappa i tuoi cinque principali servizi cloud sui controlli ISO 27001:2022 Annex A, NIS2 Article 21, obblighi DORA ICT di terze parti ove applicabili e requisiti GDPR per i responsabili del trattamento.
3. Crea una cartella centralizzata delle evidenze utilizzando la disciplina di conservazione e metadati della Policy di audit e monitoraggio della conformità Policy di audit e monitoraggio della conformità o della Policy di audit e monitoraggio della conformità per PMI Policy di audit e monitoraggio della conformità per PMI.

Poi usa Zenith Blueprint Zenith Blueprint per inserire il lavoro nella roadmap di audit SGSI in 30 step, e Zenith Controls Zenith Controls per validare le mappature di conformità trasversale, gli standard ISO di supporto e le aspettative metodologiche di audit.

Clarysec può aiutarti a trasformare screenshot cloud dispersi, fascicoli dei fornitori e impostazioni SaaS in un pacchetto di evidenze pronto per le autorità di vigilanza, capace di reggere audit di certificazione ISO 27001:2022, richieste di vigilanza NIS2, riesami DORA delle terze parti ICT e richieste di assurance dei clienti enterprise.