Come ottenere un report SOC 2

Per Paul Gillet · Aggiornato il 2026-10-17

Se un cliente chiede "siete conformi a SOC 2?", sta chiedendo un report SOC 2: il parere di uno studio CPA indipendente sui tuoi controlli, emesso secondo gli standard di attestazione dell'AICPA. Non esiste un certificato SOC 2 né una soglia di superamento. Il report descrive il tuo sistema, i tuoi controlli e i test dell'auditor, e il team di sicurezza del cliente lo legge per decidere se affidarti i propri dati.

Cosa copre il report

SOC 2 verifica i tuoi controlli rispetto ai Trust Services Criteria dell'AICPA (2017, con punti di attenzione rivisti nel 2022). Le categorie sono cinque:

• Security (i criteri comuni, CC1–CC9): sempre inclusa. Copre governance, valutazione del rischio, monitoraggio, accesso logico e fisico, operatività, gestione dei cambiamenti e rischio dei fornitori.
• Availability (A1): capacità, backup e ripristino. Aggiungila se i clienti dipendono dalla tua disponibilità.
• Confidentiality (C1): identificazione e smaltimento delle informazioni riservate. Comune per i prodotti B2B che trattano dati dei clienti.
• Processing Integrity (PI1): elaborazione completa, accurata e tempestiva. Rilevante per servizi di pagamento, paghe ed elaborazione dati.
• Privacy (P1–P8): informativa, consenso, conservazione e comunicazione di dati personali. Pochi framework di sicurezza la coprono; il GDPR (RGPD, DSGVO) è quello più vicino.

La maggior parte dei primi report include solo Security oppure Security più Availability e Confidentiality. Aggiungi categorie quando i clienti le richiedono, non per impostazione predefinita: ognuna comporta controlli da gestire ed evidenze da raccogliere.

Type I o Type II?

• Un report Type I attesta che i tuoi controlli erano adeguatamente progettati e in essere a una data specifica. È più rapido ed è utile come primo passo quando una trattativa non può attendere.
• Un report Type II attesta che i tuoi controlli erano progettati e operavano in modo efficace per un periodo, di norma da 3 a 12 mesi. È ciò che la maggior parte dei team di vendor risk dei clienti vuole davvero, perché dimostra che i controlli funzionano nella pratica.

Un percorso comune prevede un Type I appena sei pronto, poi un primo Type II che copre un periodo di 3–6 mesi, quindi report Type II annuali che coprono 12 mesi.

I passaggi

1. Definisci il sistema nel perimetro: il prodotto o servizio che i clienti acquistano, insieme a infrastruttura, persone, processi e dati che lo sostengono. Mantienilo su ciò su cui i clienti fanno affidamento; un perimetro ristretto costa meno da gestire ed è più facile da spiegare.
2. Scegli i criteri: Security più le eventuali categorie richieste dai clienti.
3. Esegui una valutazione di readiness rispetto ai criteri. Usa la gap analysis se già segui un altro framework, quindi confermala con lo studio CPA o con un consulente.
4. Chiudi i gap e documenta tutto: policy, valutazione del rischio, revisioni degli accessi, gestione dei cambiamenti, revisioni dei fornitori, risposta agli incidenti, onboarding e offboarding, backup. Gli auditor verificano ciò che fai rispetto a ciò che dichiari di fare, quindi i documenti devono corrispondere alla realtà.
5. Scegli uno studio CPA. Solo gli studi CPA abilitati possono emettere report SOC 2. Confronta l'esperienza con aziende simili alla tua, la profondità tecnica degli auditor e le modalità di raccolta delle evidenze.
6. Type I facoltativo: l'auditor verifica progettazione e implementazione in un momento specifico.
7. Avvia il periodo di osservazione per un Type II: opera ogni controllo e conserva le evidenze man mano.
8. Fieldwork e report: l'auditor campiona le evidenze del periodo, discute con te eventuali eccezioni ed emette il report, di norma alcune settimane dopo la fine del periodo.
9. Mantieni il processo attivo: un report SOC 2 copre il passato, quindi i clienti si aspettano un nuovo report ogni anno, senza interruzioni tra un periodo e l'altro.

Tempistiche tipiche

Per una piccola software house con una buona igiene di sicurezza, readiness e rimedi richiedono di norma da uno a tre mesi, un Type I può seguire subito e un primo Type II arriva dopo altri tre-sei mesi. Perimetri più ampi, più categorie o processi non maturi allungano ogni fase. Considera ogni promessa di un fornitore di "SOC 2 in poche settimane" come una promessa riferita al Type I.

Evidenze richieste dagli auditor

Il test Type II consiste soprattutto in campionamento. Aspettati richieste di questo tipo, relative al periodo di osservazione:

• nuovi assunti e cessazioni, con prova che l'accesso è stato concesso dopo approvazione e rimosso in tempo;
• revisioni periodiche degli accessi utente per i sistemi chiave;
• ticket di change che mostrano revisione, test e approvazione prima della produzione;
• risultati di scansioni di vulnerabilità e penetration test, con i relativi rimedi;
• la valutazione del rischio e la sua revisione da parte del management;
• registrazioni di due diligence sui fornitori per i fornitori critici;
• ticket di incidente e prove di test della risposta agli incidenti;
• test di backup e ripristino, e alert di monitoraggio con relativo follow-up;
• registrazioni della formazione di sensibilizzazione sulla sicurezza e policy firmate.

Gli aspetti che colgono di sorpresa

• Organizzazioni di subservice: i controlli del tuo cloud provider non sono tuoi. La maggior parte dei report usa il metodo carve-out: indichi il provider, ti affidi al suo report SOC 2 e dimostri di riesaminarlo.
• Complementary user entity controls: il report elenca i controlli che i tuoi clienti devono gestire autonomamente, come la gestione dei propri utenti. Rendili realistici.
• Eccezioni: un Type II può contenere eccezioni (campioni non conformi) ed essere comunque utile. Spiegale con chiarezza nella tua risposta del management, invece di nasconderle.
• Scope creep: ogni sistema nel perimetro deve rispettare ogni controllo, ogni giorno del periodo.

Come ti aiuta questo sito

ControlMapping associa ogni criterio SOC 2 agli altri framework che copre, così puoi vedere quale lavoro già svolto può essere riutilizzato. Il testo dei criteri è protetto da copyright dell'AICPA, quindi mostriamo i nostri riepiloghi di una riga; ogni collegamento a SOC 2 è una valutazione editoriale di ControlMapping, con la sua motivazione: le mappature dell'AICPA non sono pubblicate con una licenza aperta. Usalo per pianificare, non come evidenza di audit.

Hai già un altro framework?

Quanti requisiti di SOC 2 corrispondono a ciascun framework che potresti già seguire. Apri un report dei gap per l'elenco requisito per requisito.

Crosswalk una tabella di corrispondenza pubblicata (NIST, ENISA, CIS, PCI SSC) stabilisce il collegamento · Redazione Giudizio di ControlMapping dove non esiste una tabella di corrispondenza; la motivazione è indicata · Correlazione debole condivide solo un esito di CSF 2.0: da verificare, non è una mappatura · Nessuna mappatura nei nostri dati nessuna mappatura nei nostri dati; spesso si tratta di lavoro nuovo, ma verifica le note sulla copertura. I conteggi derivano dagli stessi dati di analisi del gap; una mappatura indica requisiti correlati, non la prova che l'uno soddisfi l'altro.

Domande

SOC 2 è una certificazione?

No. Un report SOC 2 è un'attestazione: il parere di uno studio CPA sui tuoi controlli. Nessuno è "certificato SOC 2", sebbene l'espressione sia diffusa.

Serve SOC 2 Type I o Type II?

La maggior parte dei clienti chiede il Type II, perché verifica se i controlli hanno operato per un periodo. Il Type I è un primo passo ragionevole quando un cliente lo accetta mentre il periodo del Type II è in corso.

SOC 2 è richiesto dalla legge?

No. È un'aspettativa di mercato, soprattutto dai processi di vendor risk dei clienti statunitensi. I contratti possono renderlo obbligatorio per te.

Non costituisce consulenza legale o di conformità. Verifica il testo ufficiale e confrontati con il tuo auditor, valutatore o ente regolatore prima di farvi affidamento.