SOC 2

SOC 2 è un report indipendente di un revisore su come un fornitore di servizi protegge i dati e i sistemi che gestisce per i clienti. Il quadro di riferimento nasce dall'American Institute of Certified Public Accountants (AICPA) e il report è redatto da una società CPA abilitata. SOC significa System and Organization Controls: nonostante la sigla simile, non ha alcun legame con un centro operativo di sicurezza.

Il metro di giudizio sono i Trust Services Criteria (criteri dei servizi fiduciari): sicurezza, disponibilità, integrità dell'elaborazione, riservatezza e privacy. La sicurezza è sempre inclusa e l'organizzazione sceglie tra gli altri quattro quelli adatti al servizio che vende. Il revisore esamina poi la descrizione del sistema fornita dalla direzione e i controlli che sostengono i criteri, ed esprime un parere.

SOC 2 non è una legge né un certificato. Nessuno è obbligato ad averlo e il revisore non assegna un voto di superamento: il report dice se i controlli hanno soddisfatto i criteri ed elenca le eccezioni riscontrate. Gli acquirenti lo chiedono perché offre uno sguardo esterno sulla sicurezza dei dati di un fornitore, cosa che un questionario non può fare.

Un report SOC 2 è il punto d'arrivo di un processo, non il processo stesso. L'audit è breve rispetto alla preparazione e gran parte del lavoro si svolge prima dell'arrivo del revisore:

1. 1

   Definire ambito e criteri

   Decidere quali servizi, sistemi e sedi sono coperti e quali categorie aggiungere a Security.

2. 2

   Verificare la preparazione

   Confrontare i controlli attuali con i criteri ed elencare le lacune prima che le trovi un revisore.

3. 3

   Operare e registrare

   Colmare le lacune, poi applicare i controlli nel lavoro quotidiano e conservare le evidenze: ticket, log, revisioni degli accessi, approvazioni.

4. 4

   Affrontare l'audit

   Una società CPA indipendente esamina la descrizione del sistema e testa i controlli rispetto ai criteri.

5. 5

   Ricevere e condividere il report

   Il report contiene il parere del revisore, di solito viene condiviso con i clienti sotto NDA e si rinnova con un ciclo regolare, spesso ogni anno.

La sicurezza è obbligatoria e costituisce i criteri comuni: accesso, gestione dei cambiamenti, valutazione dei rischi, monitoraggio e risposta agli incidenti. Gli altri quattro si aggiungono solo quando il servizio assume impegni al riguardo:

SOC 2 chiede a un'organizzazione di mostrare chi può accedere ai dati dei clienti, come è protetto quell'accesso e come vengono registrate le modifiche ai sistemi. Anexet non è uno strumento di audit, ma la sua console conserva diverse di queste tracce: i privilegi si assegnano per gruppo di utenti, il salvataggio delle impostazioni dell'Administrator Console può richiedere una password aggiuntiva, e le sessioni terminano automaticamente dopo un tempo impostato e il Journal registra le azioni degli amministratori. Gli eventi possono inoltre essere inoltrati a un SIEM per il monitoraggio centralizzato.

1 / 3

• 
• 
• 

Un report Type I descrive i controlli e riporta il parere del revisore sulla loro idoneità di progettazione in un singolo momento. Un report Type II copre un periodo, in genere da alcuni mesi a un anno, e aggiunge i test del revisore per verificare se i controlli hanno davvero funzionato in modo efficace per tutto quel tempo.

Per l'acquirente il Type II pesa di più: un controllo che esiste non equivale a un controllo che ha funzionato ogni settimana. Molti fornitori iniziano con il Type I per avere qualcosa da mostrare e poi passano al Type II. I clienti chiedono inoltre una bridge letter, una breve dichiarazione della direzione sul tempo trascorso tra la fine del periodo e oggi. È una dichiarazione del fornitore stesso, non un audit.

SOC 1 riguarda i controlli rilevanti per l'informativa finanziaria del cliente, SOC 2 i criteri dei servizi fiduciari, e SOC 3 è una sintesi breve a uso generale dello stesso tipo di incarico di SOC 2, senza i test dettagliati, perciò può essere pubblicata.

L'ISO/IEC 27001 è l'altro documento che gli acquirenti richiedono. È la certificazione di un sistema di gestione della sicurezza delle informazioni (SGSI) da parte di un ente accreditato, mentre SOC 2 è un report di attestazione su controlli descritti dall'organizzazione stessa. L'uno non sostituisce l'altro, ma un unico patrimonio di evidenze mantenuto con la gestione della conformità può servire a entrambi.

La maggior parte dei problemi nasce dal trattare SOC 2 come un distintivo anziché come un modo di lavorare. I clienti attenti leggono ambito, periodo ed eccezioni prima del parere, perché le lacune di un fornitore diventano anche il loro rischio di conformità. Gli schemi si ripetono:

• Definire un'azienda «certificata SOC 2» quando non esiste un certificato, ma solo un report
• Fissare un ambito così ristretto che il report lascia fuori il prodotto che il cliente usa davvero
• Cercare di ricostruire le evidenze dopo la fine del periodo, mentre un test Type II copre l'intero periodo
• Leggere solo il parere e saltare le eccezioni e i controlli che il cliente stesso deve applicare
• Ritenere che il criterio Privacy dimostri la conformità a una legge sulla privacy come il GDPR

Parti da ciò che i clienti chiedono davvero, non dai criteri. Scegli come ambito il servizio che acquistano, comincia da Security e aggiungi le altre categorie solo quando un cliente ne ha bisogno. Poi fai una verifica di preparazione e lascia ai controlli il tempo sufficiente per produrre tracce prima che inizi il periodo di audit.

Fai produrre ai sistemi le evidenze come sottoprodotto del lavoro normale: elenchi degli accessi, registri delle modifiche e report di sicurezza pianificati, invece di schermate raccolte di fretta alla fine. Un report poco costoso da rinnovare è un report che viene rinnovato.