Rapporti SOC 2 - un piccolo studio

Periodicamente mi arrivano richieste in merito ai rapporti SOC 2. Ho chiesto aiuto a Marco Ondoli di Grant Thornton e a Fabrizio Bulgarelli di PKF, che mi hanno fornito materiale e chiarimenti per capire la questione. Li ringrazio molto ed è bene precisare che quanto segue è una mia rielaborazione e gli eventuali errori sono tutti miei e non loro.

Intanto mi ha aiutato la "SOC 2 User Guide" di ISACA (non la trovo più disponibile online). Da qui ho capito che:
- i rapporti SOC servono per dimostrare alle organizzazioni l'efficacia dei propri controlli operativi;
- fino al 2011, la pubblicazione di riferimento era la SAS 70 della AICPA ed era relativa ai rapporti per le organizzazioni che volevano dimostrare l'efficacia della progettazione e dell'esercizio dei controlli con impatto sui rapporti contabili;
- dal 2011 sono entrati in vigore i 3 tipi di rapporti SOC 1, SOC 2 e SOC 3 (SOC sta per Service organization control);
- i rapporti SOC 1 sono relativi ai controlli interni sui rapporti contabili (ICFR, internal control over financial reporting) e sono descritti dalla SSAE 18 e dalla ISAE 3402; in precedenza erano descritti dalla SSAE 16);
- i rapporti SOC 2 e SOC 3 sono descritti dalla SSAE AT Section 101 e servono alle organizzazioni che forniscono servizi informatici (service provider) a clienti (user entitiy) a descrivere i controlli relativi a sicurezza, disponibilità, integrità delle elaborazioni, riservatezza e privacy (questi sono i 5 principi);
- i rapporti SOC 2 descrivono i sistemi IT oggetto del rapporto, i controlli progettati e i test condotti e riportano un parere degli auditor in merito all'efficacia dei controlli; la loro distribuzione dovrebbe essere ristretta;
- i rapporti SOC 2 di tipo 1 descrivono i controlli progettati in un certo momento specifico;
- i rapporti SOC 2 di tipo 2 descrivono anche l'efficacia dei controlli in esercizio lungo un certo periodo di tempo;
- i rapporti SOC 3 riportano solo la descrizione dei sistemi IT oggetto del rapporto e il parere degli auditor in merito all'efficacia dei controlli.

I rapporti SOC 2 devono riportare le seguenti sezioni:
- Description of the service organization's system, che deve essere abbastanza approfondita per poter identificare i rischi pertinenti e far capire al cliente se i sistemi che lo riguardano sono inclusi;
- A written assertion by management of the service organization;
- Design and operating effectiveness testing results, dove sono descritti con maggiore dettaglio e valutati i controlli;
- The service auditor's expressed opinion.

A questo punto ci si può chiedere come valutare i controlli. Ossia se esiste una sorta di check list. La risposta è no, perché la check list può essere ricavata da altri documenti. ISACA, ovviamente, suggerisce di usare COBIT.

Per i servizi cloud è invece possibile usare la CCM della cloud security alliance. E' stato prodotto un rapporto di esempio:
- https://us.aicpa.org/content/dam/aicpa/interestareas/frc/assuranceadvisoryservices/downloadabledocuments/soc2_csa_ccm_report.pdf.

E' disponibile online il rapporto SOC 3 di Dropbox, che non sembra seguire uno schema preciso:
- https://aem.dropbox.com/cms/content/dam/dropbox/www/en-us/business/trust/soc/dropbox-soc-3.pdf.

Non sono previsti corsi su questi rapporti. E' come se facessero parte della "normale" formazione degli auditor tecnici delle società di revisione contabile. Anche leggendo il rapporto di Dropbox si capisce che (come mi scrive Fabrizio Bulgarelli) "dietro a questo documento ci sta tutto il lavoro in dettaglio che non viene reso pubblico, come nelle certificazioni ISO. Ogni società di revisione, ogni team di revisione, usa un suo metodo di attestazione".

Infine sembra che i rapporti SOC possano essere emessi solo da società di revisione contabile.