SOC 2 AICPA: cos'è, Type I vs Type II e compliance

La risposta breve: la SOC 2 è un'attestazione, non una certificazione. La rilascia un revisore indipendente (un CPA, l'equivalente americano di un revisore contabile) che esamina i tuoi controlli rispetto ai Trust Services Criteria definiti dall'AICPA. Il risultato è un report, non un timbro. Serve soprattutto al SaaS che vende negli Stati Uniti, dove i clienti la chiedono prima di firmare.

Cos'è la SOC 2, senza giri di parole

SOC sta per System and Organization Controls. La SOC 2 nasce dall'AICPA (l'associazione dei commercialisti americani) e vive nel mondo dell'assurance: un professionista terzo e indipendente verifica le tue affermazioni sui controlli e le mette per iscritto in un report. Questa è la differenza culturale con l'Europa: non ottieni un certificato appeso al muro, ottieni un documento firmato da un revisore che dice se i tuoi controlli reggono.

Il report è pensato per essere condiviso con i clienti e i loro auditor. In pratica risponde a una domanda che ogni azienda americana fa ai propri fornitori software: "se ti do i miei dati, come li tratti e chi lo garantisce?".

Per questo, quando un cliente chiede se sei SOC 2 compliant, in pratica chiede di vedere un report SOC 2 recente: la conformità non si dimostra con un certificato, si dimostra con il report. E la SOC 2 ha due sigle sorelle che l'AICPA tiene distinte. La SOC 1 riguarda i controlli di un fornitore che incidono sul controllo interno dei clienti sull'informativa finanziaria. La SOC 3 usa gli stessi Trust Services Criteria della SOC 2, ma in un report per uso generale, pensato per essere distribuito liberamente. Per un fornitore software la richiesta dei clienti è quasi sempre la SOC 2.

Su cosa si basa: i Trust Services Criteria

La SOC 2 misura i controlli rispetto a cinque categorie, i Trust Services Criteria. Una è obbligatoria, le altre quattro le includi solo se sono rilevanti per il servizio che offri. I criteri li stabilisce l'Assurance Services Executive Committee (ASEC) dell'AICPA, e la versione di riferimento è quella del 2017, con i points of focus rivisti nel 2022:

• Security (sicurezza): è la base, sempre presente. Riguarda il controllo degli accessi ai sistemi e ai dati e la prevenzione di quelli non autorizzati.
• Availability (disponibilità): il servizio è accessibile e operativo come promesso, utile se hai impegni di uptime.
• Processing integrity (integrità di elaborazione): i dati vengono elaborati in modo completo, accurato e tempestivo.
• Confidentiality (riservatezza): le informazioni classificate come riservate sono trattate come tali.
• Privacy: i dati personali sono raccolti, usati e conservati secondo criteri dichiarati.

La scelta di quali criteri includere non è un dettaglio formale: definisce l'ampiezza dell'esame e quindi lo sforzo. La maggior parte delle aziende SaaS parte da Security, aggiungendo Availability e Confidentiality quando il contratto lo richiede.

SOC 2 Type I e Type II: cosa attesta ciascuno e quale serve

È la distinzione che genera più confusione. I due report guardano gli stessi Trust Services Criteria e la stessa descrizione del sistema: cambia l'orizzonte temporale, e con lui quello che il revisore può affermare.

• SOC 2 Type I attesta, a una data precisa, che la descrizione del sistema è corretta e che i controlli sono progettati in modo adeguato a rispettare i criteri. È una fotografia: dice che i controlli ci sono e sono disegnati bene, non che abbiano funzionato.
• SOC 2 Type II attesta le stesse cose lungo un periodo e aggiunge l'efficacia operativa: il revisore testa i controlli nell'arco del periodo e riporta nel report i test svolti e i risultati, eccezioni comprese. Dice che i controlli hanno funzionato nel tempo, non solo il giorno dell'esame.

Il periodo di osservazione. Nel Type II è l'arco di tempo su cui il revisore raccoglie le prove. Non è un numero unico: la durata si concorda con il revisore in base a quello che chiedono i clienti, e nella prassi di mercato va di solito da 3 a 12 mesi. Il report arriva solo dopo la fine del periodo, ed è per questo che un Type II si pianifica in anticipo e non si comprime all'ultimo momento.

Quale serve. Il Type I ha senso quando un cliente vuole un primo segnale in tempi brevi, quando i controlli sono stati appena messi in piedi o quando il sistema è cambiato di recente. Il Type II è quello che i procurement strutturati chiedono di regola, perché è l'unico dei due che dimostra continuità. Il percorso tipico è in due tempi: prima il Type I per non bloccare le trattative, poi il Type II a fine periodo di osservazione. Chi ha già controlli maturi può anche partire direttamente dal Type II. Prima di scegliere, la domanda da fare al cliente è semplice: quale dei due accetta.

A chi serve davvero la SOC 2

Se dovessimo indicare un profilo tipo: azienda SaaS o fornitore di servizi cloud che vende a clienti statunitensi. Negli USA la SOC 2 è di fatto lo standard implicito dei vendor assessment: quando un'azienda valuta un nuovo fornitore software, tra i documenti richiesti c'è quasi sempre il report SOC 2.

Il segnale che è arrivato il momento è quasi sempre commerciale, non tecnico: un deal importante si blocca perché il procurement del cliente chiede il report e tu non ce l'hai. Da quel momento la SOC 2 smette di essere un tema "da fare prima o poi" e diventa un requisito per chiudere contratti. Se sei una startup o uno scale-up SaaS, questa dinamica la abbiamo raccontata in ISO 27001 per startup SaaS, e vale in modo molto simile.

Come si ottiene: il percorso in concreto

Il percorso, semplificando, ha alcuni passaggi ricorrenti:

1. Definire l'ambito. Quali sistemi e servizi copri e quali Trust Services Criteria includi. Sbagliare qui gonfia inutilmente il lavoro.
2. Fare una gap analysis. Confronti i controlli che hai con quelli attesi e vedi cosa manca. È la mappa dei lavori da fare.
3. Chiudere i gap e implementare i controlli. Policy, gestione degli accessi, logging, gestione dei fornitori, risposta agli incidenti e così via.
4. Raccogliere le prove. Il revisore non crede sulla parola: vuole evidenze che i controlli operano. Questa è la parte più noiosa e più lunga, soprattutto per il Type II.
5. L'esame del revisore. Un CPA indipendente conduce l'esame e produce il report. Per il Type II osserva un intero periodo.

Sui tempi: il Type I si chiude in settimane o pochi mesi, mentre il Type II richiede in più il periodo di osservazione richiesto dal revisore. La variabile che sposta di più il calendario è la raccolta prove, ed è esattamente lì che entra l'automazione.

Il ruolo dell'automazione della compliance

Il collo di bottiglia della SOC 2 raramente è "capire cosa fare". È tenere insieme decine di controlli e produrre continuamente le prove che funzionano: screenshot, log, configurazioni, elenchi di accessi, evidenze di formazione. Farlo a mano, in un foglio di calcolo, è dove i progetti si impantanano.

Gli strumenti di automazione della compliance come Vanta si collegano ai sistemi che già usi (cloud, gestione identità, HR, ticketing) e raccolgono le prove in modo continuo, segnalando quando un controllo esce dai parametri. Il risultato non è "la SOC 2 gratis", ma un percorso più corto e ripetibile, con meno lavoro manuale e meno sorprese in fase di esame. Cosa fa nel dettaglio Vanta, quali framework copre e cosa resta comunque in capo al revisore indipendente è in Vanta: cos'è e come funziona. Per farti un'idea dell'impatto in termini di tempo e sforzo, puoi usare il nostro calcolatore per la certificazione ISO 27001, SOC 2 e NIS2.

Cosa c'è dentro il report (e cosa guardano i clienti)

Vale la pena sapere che aspetto ha il prodotto finale, perché è quello che finirà sul tavolo del procurement del tuo cliente. Un report SOC 2 non è una paginetta con un timbro: è un documento articolato che di regola contiene:

• L'opinione del revisore: il giudizio del CPA, la parte che i clienti leggono per prima.
• L'attestazione del management: le affermazioni dell'azienda sui propri sistemi e controlli.
• La descrizione del sistema: cosa fa il servizio, quali sono i confini e quali controlli sono in essere.
• I test e i risultati: nel Type II, l'elenco dei controlli testati, come sono stati verificati e l'esito, incluse eventuali eccezioni.

Le eccezioni meritano una nota: un report può contenere osservazioni senza per questo essere "bocciato". Ciò che conta per il cliente è capire quanto sono rilevanti e come sono state gestite. Sapere questo aiuta a non vivere l'esame come un test tutto-o-niente, ma come una fotografia onesta dei tuoi controlli.

SOC 2 e ISO 27001: come si rapportano

Ultima domanda ricorrente: se ho la ISO 27001 mi serve anche la SOC 2, o viceversa? Sono due cose diverse ma con una forte sovrapposizione. La ISO 27001 è una certificazione internazionale su un sistema di gestione della sicurezza delle informazioni, molto richiesta in Europa. La SOC 2 è un'attestazione americana su controlli specifici, molto richiesta negli USA. Molti dei controlli sottostanti sono gli stessi, quindi chi le affronta insieme riusa gran parte del lavoro.

La scelta dipende dai clienti: se vendi in Europa parti spesso dalla ISO 27001, se vendi negli Stati Uniti dalla SOC 2, e se fai entrambe le cose ha senso pianificarle in parallelo. Abbiamo messo a confronto le due nel dettaglio in ISO 27001 e SOC 2, quale scegliere. Quando decidi di partire con la SOC 2, i nostri servizi SOC 2 ti accompagnano dall'ambito fino al report.

In sintesi: la SOC 2 è un'attestazione che dimostra ai clienti, soprattutto americani, che i tuoi controlli reggono. Type I fotografa il disegno, Type II dimostra che funziona nel tempo. Il modo più rapido di ottenerla è definire bene l'ambito e automatizzare la raccolta prove, così l'esame diventa una conferma e non una corsa.