Punti chiave
- Per SOC 2 e ISO 27001 l'auditor valuta i controlli sulla parte di cloud che gestisci tu: la parte fisica è del provider, configurazioni, identità e dati sono tuoi.
- Le evidenze cloud sono sempre le stesse: inventario, configurazioni, identità e accessi, vulnerabilità, esposizione di rete, cifratura, log e monitoraggio.
- Entrambi gli schemi guardano nel tempo: uno screenshot dimostra un giorno, un controllo che gira ogni giorno con lo storico dimostra che il processo funziona.
- Uno strumento di postura come Wiz valuta le risorse in continuo rispetto a oltre 100 framework, SOC 2 compreso, e ordina i rischi per impatto.
- L'integrazione documentata da Vanta porta vulnerabilità, issue e configurazioni di Wiz accanto ai controlli, senza scrivere nulla in Wiz, con sincronizzazioni da ogni ora a ogni 24 ore.
- Valutazione dei rischi, scelte della Dichiarazione di Applicabilità, policy, eccezioni, correzione e giudizio dell'auditor restano decisioni tue: uno strumento le documenta, non le prende.
La risposta breve: per una SOC 2 o una ISO 27001 l'auditor non valuta il data center del provider, valuta i controlli sulla parte di cloud che gestisci tu. Le evidenze che chiede sono sempre le stesse: inventario delle risorse, configurazioni, identità e permessi, vulnerabilità, log. Uno strumento di postura cloud le produce in continuo, una piattaforma di compliance le collega ai controlli. Le decisioni restano a te.
Questa pagina è per chi ha un audit in calendario e un'infrastruttura su AWS, Azure o Google Cloud: quali evidenze servono, area per area, quali si possono raccogliere senza screenshot, e cosa nessuno strumento fa al posto tuo. In fondo spieghiamo come lavoriamo noi, da partner Wiz.
Cosa guarda l'auditor quando il sistema è nel cloud
Il punto di partenza è la responsabilità condivisa. AWS la descrive così: il provider risponde dell'infrastruttura che fa girare i servizi, mentre la responsabilità del cliente dipende dai servizi che sceglie, e comprende per esempio il sistema operativo delle istanze con le sue patch, la configurazione dei security group, la gestione e la cifratura dei dati, i permessi assegnati con gli strumenti IAM (AWS, Shared Responsibility Model). Nella stessa pagina AWS indica i controlli fisici e ambientali come controlli che il cliente eredita per intero.
Tradotto in termini di audit: la parte fisica è responsabilità del provider, e a te tocca valutarlo come fornitore. Tutto quello che hai configurato tu è materia di verifica, ed è lì che servono le evidenze.
Nella ISO 27001
La ISO/IEC 27001:2022 dedica al tema un controllo dell'Annex A, il 5.23 (Information security for use of cloud services), che riguarda il modo in cui l'organizzazione sceglie, usa e governa i servizi cloud. Le evidenze tecniche, però, arrivano soprattutto da altri controlli, che nel cloud si leggono direttamente dalle configurazioni.
Nella SOC 2
La SOC 2 è un esame dei controlli condotto da un revisore indipendente sui Trust Services Criteria dell'AICPA, che coprono sicurezza, disponibilità, integrità di elaborazione, riservatezza e privacy. La sicurezza c'è sempre, le altre categorie entrano se rilevanti per il servizio. Se il tuo prodotto gira nel cloud, il sistema descritto nel report comprende quegli account: il revisore vorrà vedere come sono gestiti accessi, configurazioni, vulnerabilità e monitoraggio. Le basi, comprese le differenze fra Type I e Type II, sono nella guida SOC 2: cos'è e come si ottiene.
Le evidenze cloud, area per area
Le due cornici usano parole diverse, ma sul cloud chiedono prove molto simili. Per ogni area indichiamo il controllo ISO 27001:2022 di riferimento e cosa il revisore si aspetta di vedere.
- Inventario delle risorse (ISO 5.9, inventario delle informazioni e degli altri asset associati). Account, subscription e progetti, macchine virtuali, container, database, bucket di storage. L'evidenza utile è un inventario generato dall'ambiente, non un foglio compilato a mano: è il modo più semplice per dimostrare che il perimetro dichiarato coincide con quello reale.
- Configurazioni (ISO 8.9, gestione delle configurazioni). Una baseline di riferimento, per esempio i CIS Benchmark pubblicati per quel provider, e lo stato di ogni risorsa rispetto a quella baseline, con le eccezioni motivate.
- Identità e accessi (ISO 5.15, 5.18 e 8.2 su controllo degli accessi, diritti di accesso e accessi privilegiati). Chi ha ruoli amministrativi, quali chiavi di accesso sono vecchie o inutilizzate, quali account appartengono a persone che hanno lasciato l'azienda, e la traccia delle revisioni periodiche.
- Vulnerabilità (ISO 8.8, gestione delle vulnerabilità tecniche). L'elenco delle vulnerabilità sui carichi di lavoro, con gravità, data di scoperta e data di chiusura: il revisore guarda se i tempi rispettano quelli che la tua policy promette.
- Rete ed esposizione (ISO 8.20, sicurezza delle reti). Quali risorse sono raggiungibili da internet, su quali porte, e perché.
- Cifratura (ISO 8.24, uso della crittografia). Storage e database cifrati, gestione delle chiavi.
- Log e monitoraggio (ISO 8.15 e 8.16, logging e attività di monitoraggio). Log di audit attivi sugli account, conservati per il periodo previsto, e qualcuno che li guarda davvero.
Tutte queste aree hanno una cosa in comune: lo stato si legge dalle API del provider.
Fotografia o film: perché conta la continuità
Molte aziende preparano le evidenze cloud come si prepara un trasloco: screenshot della console nelle due settimane prima dell'audit. Il problema è che entrambi gli schemi guardano nel tempo. Una SOC 2 di Type II valuta se i controlli hanno funzionato lungo un periodo di osservazione, non solo se esistono a una certa data. Nella ISO 27001, fra il rilascio del certificato e il rinnovo l'ente torna con audit di sorveglianza, e la norma stessa dedica il punto 9.1 a monitoraggio, misurazione, analisi e valutazione.
Nel cloud una configurazione corretta oggi può essere sbagliata domani, perché qualcuno apre un bucket per un test o crea un ruolo con troppi permessi. Uno screenshot dimostra lo stato di un giorno. Un controllo che gira ogni giorno, con lo storico di quando un problema è comparso e quando è stato chiuso, dimostra che il processo funziona. È questa la differenza che il revisore cerca.
Cosa produce uno strumento di postura cloud
Una piattaforma di sicurezza del cloud, come una CNAPP, legge gli account via API e valuta continuamente le risorse rispetto a regole e framework. Prendiamo Wiz, con cui lavoriamo. Nella pagina dedicata alla compliance Wiz dichiara oltre 100 framework già integrati, citando fra gli altri NIST, HIPAA, CIS, HiTrust e SOC 2, la possibilità di costruire framework personalizzati, la valutazione continua e report per framework, per business unit o per applicazione (Wiz, Continuous Cloud Compliance with Wiz). Dallo standard si scende alle categorie, poi ai controlli, fino alla valutazione della singola risorsa.
Per un audit questo significa tre cose:
- Un inventario che si aggiorna da solo, su tutti i cloud collegati, da usare come base del perimetro.
- Lo stato di ogni risorsa rispetto alla baseline, con lo storico dei problemi aperti e chiusi.
- Le priorità: non tutte le configurazioni sbagliate pesano uguale. Google Cloud, nel post che annuncia la chiusura dell'acquisizione, descrive Wiz come lo strumento che identifica l'esposizione e i percorsi di attacco sfruttabili e ordina il rischio in base all'impatto sul business (Google Cloud Blog, 11/03/2026).
Una precisazione sui permessi, perché è la prima domanda del team DevOps: l'inventario e le configurazioni si leggono via API, senza agenti sulle macchine. L'analisi dei dischi, invece, lavora su snapshot, e Wiz spiega che per questo lo scanner ha permessi limitati che includono la creazione, la condivisione e la cancellazione degli snapshot (Wiz, Securing clouds, securely, 31/10/2023). Quindi non è corretto dire che tutto avviene in sola lettura: i permessi esatti si leggono sulla documentazione prima di collegare gli account.
Un limite da tenere presente: la valutazione rispetto a un framework dice come sono configurate le risorse, non che i controlli organizzativi esistono. È un'evidenza tecnica, non un parere di conformità.
Il ponte con la piattaforma di compliance
Le evidenze tecniche servono a poco se restano in uno strumento che il responsabile della compliance non apre. Qui entra la piattaforma di compliance automation, come Vanta, che tiene insieme controlli, policy, persone, fornitori ed evidenze per più framework, ISO 27001 e SOC 2 compresi.
La documentazione di Vanta sull'integrazione con Wiz, aggiornata al 21 agosto 2026, descrive cosa passa da uno all'altro (Vanta Help Center, Connecting Wiz with Vanta):
- Vulnerabilità, importate come tali e filtrabili per gravità, sincronizzate ogni 8 ore.
- Issue di sicurezza, solo quelle aperte e di gravità critica, alta o media, ogni 24 ore.
- Risultati sulle configurazioni, cioè le configurazioni errate rispetto agli standard, ogni 24 ore.
- Account utente, circa ogni ora, importati per le revisioni degli accessi.
- Asset, cioè le risorse monitorate per le vulnerabilità, circa ogni ora.
Secondo Vanta i risultati vengono mappati in automatico sui controlli pertinenti dei framework, e l'integrazione legge soltanto: Vanta non modifica, non riassegna e non cancella dati in Wiz. Il collegamento passa da un service account Wiz con permessi di lettura (risorse, issue, vulnerabilità, configurazioni, account) più quello di creazione dei report.
Il risultato pratico è che il problema trovato nel cloud compare accanto al controllo ISO 27001 o al criterio SOC 2 a cui si riferisce, e la sua chiusura diventa a sua volta un'evidenza.
Cosa nessuno strumento fa al posto tuo
Raccogliere evidenze in continuo toglie il lavoro ripetitivo, non il lavoro di merito. Restano tuoi, e sono quelli su cui l'auditor fa più domande:
- La valutazione dei rischi e la Dichiarazione di Applicabilità, cioè perché un controllo si applica o no al tuo contesto.
- Le policy: quanti giorni per chiudere una vulnerabilità critica, ogni quanto si rivedono gli accessi, quanto si conservano i log. Lo strumento misura rispetto a una regola, la regola la decidi tu.
- Le eccezioni motivate: un bucket pubblico può essere legittimo se serve un sito statico. Va documentato.
- La correzione: una lista di problemi senza nessuno incaricato di lavorarla diventa, a fine periodo, l'evidenza di un controllo che non funziona.
- Il giudizio: lo esprime il revisore SOC 2 o l'ente di certificazione, in modo indipendente. Nessuna dashboard lo sostituisce.
Le differenze fra i due schemi e come scegliere da quale partire sono in ISO 27001 vs SOC 2.
Da dove partire
- Fissa il perimetro: quali account, subscription e progetti rientrano nel sistema da certificare o descritto nel report. Compresi gli ambienti di sviluppo che toccano dati reali.
- Fai una prima fotografia del cloud prima dell'audit, non durante: è il momento in cui una configurazione sbagliata costa una correzione, non un rilievo.
- Scrivi le regole che vuoi misurare: baseline, tempi di correzione, frequenza delle revisioni.
- Collega postura e compliance, così ogni problema trovato e chiuso finisce da solo accanto al controllo giusto.
- Assegna i responsabili della correzione, per area.
Come lavoriamo noi
AmagisTech è partner Wiz. La fotografia del cloud parte da una call con un advisor, collega gli account via API con un ruolo dedicato che resta sotto il tuo controllo, e consegna una lista di problemi in ordine di priorità, letta anche con gli occhi di chi deve preparare un audit SOC 2 o ISO 27001. Wiz fa parte di Google Cloud: Google ha comunicato la chiusura dell'acquisizione l'11 marzo 2026, ha mantenuto il marchio Wiz e ha confermato che i prodotti continuano a funzionare su AWS, Microsoft Azure e Oracle Cloud (Google Cloud Blog, 11/03/2026).
In sintesi
Per SOC 2 e ISO 27001 il cloud del provider conta poco, la tua configurazione conta molto. Le evidenze che servono sono inventario, configurazioni, accessi, vulnerabilità, rete, cifratura e log, e gli schemi le guardano nel tempo, non in un giorno. Uno strumento di postura le produce in continuo, una piattaforma di compliance le porta accanto ai controlli, e le decisioni di merito restano tue.
Se vuoi sapere com'è messo il tuo cloud prima che lo veda l'auditor, parti da qui: la fotografia del cloud con Wiz.