Conformità SOC 2 per Google Workspace: cosa è necessario sapere

Se la sua organizzazione sta perseguendo la conformità SOC 2 — e la maggior parte delle aziende B2B di software prima o poi lo fa, perché i clienti lo richiedono — Google Workspace rientrerà nell'ambito. Contiene identità, documenti e controlli di accesso che si collegano direttamente ai criteri esaminati da un auditor. Questo articolo spiega come Workspace si inserisce in un programma SOC 2 e come preparare la parte relativa a Workspace senza l'affanno dell'ultimo minuto.

Una precisazione terminologica: SOC 2 è un'*attestazione* eseguita da una società di revisione contabile indipendente (CPA), non un badge che ci si autoassegna. Il risultato è un report prodotto da un auditor, non un'etichetta autodichiarata. Ciò che è possibile fare internamente è costruire e dimostrare i controlli, e raccogliere le evidenze, in modo che l'attestazione proceda senza intoppi. Di questo tratta l'articolo.

Un rapido orientamento su SOC 2

SOC 2 valuta i controlli di un'organizzazione di servizi rispetto ai Trust Services Criteria (TSC): Security (sempre inclusa, spesso chiamata Common Criteria) e, facoltativamente, Availability, Processing Integrity, Confidentiality e Privacy. I criteri Security — la serie CC — sono quelli in cui Google Workspace compare più frequentemente.

Un report di Tipo I valuta se i controlli sono *progettati* in modo appropriato in un dato momento. Un report di Tipo II valuta se hanno *operato efficacemente* nel corso di un periodo (tipicamente 3–12 mesi). Il Tipo II è solitamente ciò che i clienti richiedono, e questo comporta un'implicazione importante: sono necessari controlli che funzionino, ed evidenze che abbiano funzionato, per tutta la finestra temporale — non solo il giorno dell'audit.

Dove Google Workspace si collega ai criteri

Diversi Common Criteria si collegano in modo diretto ai controlli di Workspace già gestiti quotidianamente:

• CC6.1 — Controlli di accesso logico. Chi può accedere alle informazioni protette, e come l'accesso è limitato agli utenti autorizzati. In termini di Workspace: provisioning degli account, applicazione dell'MFA, controlli di condivisione e l'accesso detenuto da ogni identità, inclusi account esterni e di servizio.
• CC6.2 — Registrazione e autorizzazione. I nuovi utenti vengono registrati e autorizzati prima che l'accesso venga concesso; l'accesso viene rimosso quando non più necessario. La corretta gestione di joiner/mover/leaver rientra qui.
• CC6.3 — Privilegio minimo e separazione dei compiti. L'accesso è basato sui ruoli ed è limitato al minimo necessario. Accessi eccessivamente permissivi e proliferazione di privilegi amministrativi rappresentano rilievi rispetto a questo criterio.
• CC6.6 — Protezione dalle minacce esterne. La superficie raggiungibile dall'esterno: link pubblici, condivisioni esterne e accesso concesso a identità esterne all'organizzazione.
• CC7.x — Monitoraggio e risposta agli incidenti. Rilevare anomalie e rispondere agli eventi di sicurezza. Sapere quando cambiano condivisioni o accessi, ed essere in grado di indagare, supporta questi criteri.

Non è necessario memorizzare la numerazione. Il punto è che il lavoro quotidiano su Workspace — applicare l'MFA, controllare la condivisione, rimuovere accessi obsoleti, governare le app di terze parti — *è* l'evidenza di controllo che un auditor vuole vedere.

Cosa chiedono realmente gli auditor

Gli auditor non vogliono rassicurazioni; vogliono evidenze. Per i controlli relativi a Workspace, ci si può aspettare richieste come:

• Prova che l'MFA sia applicato (la policy e la sua effettiva applicazione, non solo "l'abbiamo attivata").
• L'elenco degli amministratori e una motivazione per ciascun ruolo privilegiato.
• Evidenza delle revisioni di accesso — la verifica periodica di chi può raggiungere dati sensibili e le azioni intraprese in base a quanto rilevato.
• Registri della revoca degli accessi quando i dipendenti lasciano l'organizzazione.
• La configurazione di condivisione e come la condivisione esterna viene controllata.
• Un registro di come i rilievi di sicurezza vengono tracciati fino alla risoluzione.

Il tema ricorrente è un processo documentato e ripetibile, con una traccia di audit. Un controllo che esiste ma non lascia traccia è difficile da attestare. Un controllo che opera in continuo e registra quanto rilevato è facile.

Come preparare la parte relativa a Workspace

1. Stabilire una baseline di configurazione. Documentare lo stato previsto delle impostazioni amministrative — condivisione, verifica in due passaggi, restrizioni del Marketplace, autenticazione delle email — e verificare periodicamente la realtà rispetto a essa. Il drift è il nemico di un audit pulito.
2. Eseguire revisioni di accesso documentabili. Rivedere periodicamente chi può raggiungere dati sensibili, incluse identità esterne e non umane, e conservare l'output. "Abbiamo rivisto gli accessi trimestralmente, ecco i registri" è esattamente ciò che richiede il CC6.3.
3. Rafforzare e documentare la condivisione. Collegarsi a CC6.1 e CC6.6 controllando la condivisione pubblica ed esterna ed essendo in grado di mostrare lo stato attuale.
4. Tracciare i rilievi fino alla risoluzione. Quando si individua un'esposizione, la si registra, la si corregge e se ne conserva la traccia. Questo supporta i criteri di monitoraggio e correzione.
5. Mantenere un registro di audit. Un registro con marca temporale delle azioni rilevanti per la sicurezza rende banale rispondere alle domande "chi ha fatto cosa, quando".

Gran parte di tutto ciò si sovrappone a una buona pratica generale di sicurezza di Google Workspace — ed è proprio questo il punto. SOC 2 non è un progetto separato aggiunto in un secondo momento; è la propria pratica di sicurezza, resa leggibile e documentata.

Le evidenze continue battono l'affanno da audit

Il classico modello di fallimento è trattare la conformità come un evento: un mese frenetico di screenshot e fogli di calcolo prima dell'audit, ripetuto ogni anno. È stressante, soggetto a errori, e produce evidenze puntuali che un auditor di Tipo II metterà giustamente in discussione.

L'alternativa è la continuità: controllare la postura tutto l'anno, generare le evidenze come sottoprodotto, e arrivare all'audit con la traccia già pronta. Uno strumento di postura che mappa i rilievi sui criteri SOC 2 e produce evidenze pronte per l'auditor trasforma l'affanno in un semplice export.

Errori comuni nella parte di Workspace di un audit

Alcuni errori ricorrono con frequenza e vale la pena prevenirli:

• Confondere "configurato" con "applicato". Attivare una policy di verifica in due passaggi non equivale a farla applicare a ogni account. Gli auditor verificano quest'ultimo aspetto. Verificare che l'applicazione sia effettiva a livello di intera organizzazione — si veda la nostra guida su come applicare l'MFA in Google Workspace.
• Trattare le revisioni di accesso come una formalità. "Rivediamo gli accessi" senza registri, ambito o follow-through non costituisce evidenza. Conservare l'output e dimostrare che i rilievi sono stati gestiti.
• Dimenticare le identità non umane. Anche account di servizio e agenti AI detengono accesso, e un auditor che verifica il privilegio minimo (CC6.3) non accetterà "abbiamo rivisto solo le persone". Governarli — si veda rilevare agenti AI a rischio.
• Lasciare che la configurazione derivi tra un audit e l'altro. Una baseline pulita a gennaio e alterata a giugno produce un rilievo di Tipo II. È il controllo continuo, non un'istantanea annuale, a mantenere la linea.

La conformità è un sottoprodotto di una buona sicurezza

Il riquadro concettuale più utile per la parte Workspace di SOC 2 è che non si stanno costruendo controlli *per l'audit* — si sta gestendo un programma di sicurezza solido e si lascia che l'audit lo osservi. Tutto ciò che un auditor vuole vedere in base ai criteri di controllo degli accessi è qualcosa che si vorrebbe comunque: identità applicata, condivisione controllata, accesso di terze parti governato e una baseline di configurazione mantenuta. L'audit chiede semplicemente di renderlo leggibile e documentato.

I team che interiorizzano questo principio smettono di temere il ciclo annuale. I controlli operano tutto l'anno, le evidenze si accumulano come sottoprodotto, e l'audit diventa una revisione di un lavoro già svolto anziché un progetto a sé stante. Questa è anche, in pratica, la differenza tra affannarsi ed essere pronti.

8200.dev mappa la postura di Google Workspace sulle famiglie di controlli SOC 2, ISO 27001 e GDPR e genera pacchetti di evidenze da consegnare a un auditor — onesti, limitati a quanto effettivamente osservato, mai una dichiarazione di conformità non comprovata. Per saperne di più, consulti come funziona o le nostre pratiche di sicurezza.

Si sta preparando per un audit? Avvii il suo audit di sicurezza gratuito e scopra come la postura del suo Google Workspace si mappa sui criteri di controllo degli accessi esaminati dagli auditor.