2026-07-19 · GUIDA · Il team di Offensive Technology

SOC 2 richiede un penetration test?

Risposta breve: no, ma anche sì. SOC 2 non contiene alcuna riga che dica "devi eseguire un penetration test". Tuttavia, la maggior parte degli auditor se ne aspetta comunque uno. Se stai leggendo questo articolo perché un cliente o una trattativa commerciale è in attesa del tuo report, il divario tra la lettera dello standard e ciò che il tuo auditor accetta è esattamente ciò che va chiarito. Eccolo spiegato, senza retorica di vendita.

Cos'è davvero SOC 2

SOC 2 non è una checklist di controlli. È un report di attestazione redatto da una società CPA abilitata, valutato rispetto ai Trust Services Criteria dell'AICPA. L'AICPA (American Institute of Certified Public Accountants) pubblica questi criteri pubblicamente, e sono scritti come obiettivi generali, non come strumenti specifici. Si tratta di una scelta progettuale precisa. Allo standard interessa se rispetti l'obiettivo, non quale prodotto hai acquistato per farlo.

Ecco perché non troverai mai la dicitura "penetration test" indicata come requisito vincolante. SOC 2 non funziona così. Chiede se monitori i tuoi sistemi, gestisci le vulnerabilità e valuti i tuoi controlli, lasciando il come a te e al tuo auditor.

Da dove nasce davvero l'aspettativa del pentest

Leggendo i criteri, due di essi svolgono il lavoro principale.

• CC4.1, il criterio relativo al monitoraggio, riguarda il modo in cui il management valuta se i propri controlli funzionano. La documentazione di supporto dell'AICPA cita il penetration testing come esempio del tipo di valutazione separata che un'organizzazione può utilizzare a questo scopo. Viene citato come illustrazione, non come obbligo, ma viene citato.
• CC7.1 copre il rilevamento di vulnerabilità e modifiche di configurazione. Il vulnerability scanning si adatta perfettamente a questo punto, e la maggior parte degli auditor si aspetta di vederlo eseguito periodicamente.

Quindi il pentest non è richiesto dal testo. È il modo più comune e difendibile per produrre evidenze che soddisfino il criterio CC4.1, e gli auditor concordano nell'aspettarselo perché è l'evidenza di cui si fidano. Quando si dice che "SOC 2 richiede un pentest", s'intende in realtà questo: il tuo auditor ne chiederà con ogni probabilità uno, anche se lo standard non lo impone.

Cosa significa questo all'atto pratico

Alcune schiette realtà che i criteri implicano ma non esplicitano:

• È il tuo auditor a stabilire lo standard, non un blog. Due società di audit possono accettare evidenze diverse per lo stesso criterio. Prima di acquistare qualsiasi cosa, chiedi direttamente al tuo auditor cosa si aspetta per i criteri CC4.1 e CC7.1. La sua risposta è l'unica che determina il valore del tuo report.
• Una scansione non è un pentest, e gli auditor sanno distinguerli. Il vulnerability scanning supporta il criterio CC7.1. Non dimostra però, da solo, il tipo di valutazione indipendente a cui punta il criterio CC4.1. Se fornisci una scansione rietichettata spacciandola per penetration test, un auditor esperto se ne accorgerà, e così farà il cliente enterprise che leggerà il tuo report.
• Il Type 2 presenta un'insidia sulle tempistiche. Un SOC 2 Type 1 è un'istantanea riferita a un momento preciso. Un Type 2 copre un arco temporale, spesso da diversi mesi a un anno. Affinché il test sia valido come evidenza per un Type 2, deve generalmente rientrare in quella finestra di osservazione. Un pentest eseguito diciotto mesi fa potrebbe non esserti di alcun aiuto.
• La cadenza annuale è la prassi comune. La maggior parte degli auditor considera un test eseguito almeno una volta all'anno come l'aspettativa minima, richiedendone uno nuovo prima di ogni rinnovo. Analizziamo il quadro completo nei vari framework in ogni quanto bisognerebbe fare un penetration test?

Non confondere SOC 2 con una garanzia di sicurezza

Su questo punto dobbiamo essere chiari, perché è l'aspetto su cui chi acquista si sbaglia di più. Un report SOC 2 comunica a un cliente che una società CPA ha valutato i tuoi controlli rispetto a una serie di criteri durante un periodo. Non significa che tu non possa subire un attacco informatico, né che il pentest incluso sia stato approfondito. Un test con un perimetro ridotto al minimo solo per spuntare una casella, eseguito dal fornitore più economico, può tecnicamente supportare il report e comunque non rilevare la modalità con cui un attaccante entrerebbe davvero.

Se esegui un pentest solo per superare l'audit, ottieni un certificato. Se ne esegui uno per scoprire davvero dove sei esposto, ottieni sicurezza. Possono essere lo stesso test, ma non lo sono automaticamente, e la differenza la fanno chi esegue il lavoro e la trasparenza con cui viene definito il perimetro.

Quindi, cosa dovresti fare concretamente?

Se SOC 2 è nei tuoi piani, la sequenza logica è: conferma con l'auditor scelto cosa si aspetta per i criteri CC4.1 e CC7.1, quindi definisci il perimetro di un penetration test che soddisfi tale aspettativa e che sia pianificato all'interno della tua finestra di osservazione. Non acquistare un test al buio e non accettare una semplice scansione mascherata da attività di penetration testing.

Esiste però un passaggio più economico che precede tutto questo. Prima di impegnarti in un'attività di livello audit da cinque cifre, vale la pena sapere cosa vede già un attaccante dall'esterno, in modo da affrontare il percorso senza vulnerabilità evidenti pronte a prenderti di sorpresa. Questo non sostituirà il pentest richiesto dal tuo auditor, e te lo diremo in tutta franchezza. Significa solo che affronterai il percorso SOC 2 a occhi aperti anziché chiusi.

La nostra verifica da $100 rappresenta questo primo sguardo: un'analisi mirata della tua superficie di attacco esterna, eseguita su un perimetro di tua proprietà verificata e autorizzata per iscritto, analizzata da un operatore senior e consegnata con un resoconto di 30 minuti. Se il tuo auditor SOC 2 necessita di un penetration test completo, questa verifica non lo soddisferà, e te lo diremo prima del pagamento, non dopo. È tuttavia il punto di partenza più trasparente ed economico.

SOC 2 e penetration testing: risposte rapide

SOC 2 richiede un penetration test?

No. SOC 2 non contiene alcuna clausola che ne imponga uno; i Trust Services Criteria dell'AICPA sono scritti come obiettivi generali, non come strumenti specifici. Tuttavia, la maggior parte degli auditor richiede un penetration test come evidenza per i criteri di monitoraggio e gestione delle vulnerabilità, quindi nella pratica ne avrai quasi sempre bisogno.

Quali criteri SOC 2 fanno riferimento al penetration testing?

CC4.1 (monitoraggio) e CC7.1 (rilevamento delle vulnerabilità). Le linee guida di supporto dell'AICPA citano il penetration testing come esempio della valutazione separata che può soddisfare il criterio CC4.1. Si tratta di un esempio, non di un obbligo.

Con quale frequenza serve un pentest per SOC 2?

La maggior parte degli auditor richiede un'attività di test almeno annuale, pianificata in modo da rientrare nella finestra di osservazione del Type 2. Per la cadenza esatta, confrontati con il tuo auditor.

Una scansione delle vulnerabilità è sufficiente per SOC 2?

Una scansione supporta le evidenze legate alla gestione delle vulnerabilità, ma non dimostra, da sola, la valutazione indipendente cercata dagli auditor. Una scansione rietichettata come penetration test viene generalmente notata.

Letture correlate

• Serve un pentest per la polizza cyber insurance?
• Quanto costa un penetration test?