Indice
1. La decisione che il mercato ha gia preso 2. Cosa dice ISAE 3402 e cosa fanno i fascicoli 3. Il lavoro vero sotto carve-out: i CSOC 4. Quando l'inclusive si applica davvero 5. Esempio pratico: pagamenti digitali con cloud carve-out 6. Disaccordo legittimo: quanto testare i CSOC sui Big-3 cloud 7. Checklist operativa 8. Errori comuni 9. Contenuti correlati
La decisione che il mercato ha gia preso
ISAE 3402.22 lettere (a) e (b) descrive due metodi possibili. La scelta, sulla carta, dipende dal service organization e dalla sua capacita di ottenere evidenza dai sub-service. Nei fascicoli che vediamo da tre anni, l'inclusive method compare in meno di un caso su venti.
La ragione non e tecnica. E contrattuale. Le clausole degli MSA (Master Service Agreement) di AWS, Azure e GCP escludono esplicitamente la fornitura di rapporti SOC inclusive: il cloud provider firma il proprio SOC 2 Type II, lo distribuisce ai propri clienti, e si rifiuta di essere incluso nello scope di un altro auditor. Lo stesso vale per Stripe, Adyen, e per la maggior parte dei processori di pagamento di rilievo. Il revisore eredita questa decisione contrattuale come fatto del mercato.
ISAE 3402.22 offre due opzioni; il mercato ne offre una.
Cosa cambia per il revisore-utente. Sotto carve-out, il rapporto SOC del service organization documenta i propri controlli e identifica i sub-service esclusi. Lascia al revisore dell'utente il compito di valutare se i CSOC siano stati implementati. Si tratta di un lavoro che la maggior parte dei fascicoli italiani che abbiamo letto non esegue, o esegue solo in superficie.
Cosa dice ISAE 3402 e cosa fanno i fascicoli
ISAE 3402.22 stabilisce che il service auditor, quando il service organization si avvale di un sub-service organization, deve scegliere tra includere i controlli del sub-service nello scope del rapporto (inclusive) o escluderli con descrizione (carve-out). I paragrafi .B14-.B19 dettagliano gli effetti di ciascuna scelta sulla descrizione del sistema, sull'opinion, e sui CSOC che vanno divulgati nel rapporto.
Sulla carta, la decisione si basa su tre fattori (.B15): la natura dei servizi forniti dal sub-service, la materialita degli stessi rispetto agli obiettivi di controllo, e la capacita del service organization di ottenere evidenza adeguata sui controlli del sub-service.
Nei fascicoli che vediamo, il fattore decisivo non compare in questa lista. E la disponibilita contrattuale del sub-service. Se AWS rifiuta, l'inclusive non e tecnicamente impossibile, e commercialmente impossibile.
ISAE 3402.B17 e chiaro. Quando si applica il carve-out, il rapporto del service auditor deve identificare il sub-service organization, descrivere i servizi che eroga, e divulgare i CSOC che il sub-service e tenuto a operare perche gli obiettivi di controllo del service organization possano essere raggiunti. Questi CSOC sono il ponte tra il sub-service e l'utente finale. Il problema e che spesso restano in fondo al rapporto SOC, in una sezione che il fascicolo dell'utente non legge davvero.
ISAE 3402.B18 e il paragrafo che chiude il cerchio. Sotto carve-out, il revisore dell'utente deve considerare i CSOC come responsabilita propria del cliente, e valutare se il cliente li abbia implementati. Si tratta di lavoro aggiuntivo, non di un esercizio di reliance.
Il lavoro vero sotto carve-out: i CSOC
Le carte di lavoro che vediamo si fermano quasi sempre alla lettura del SOC. Il senior tickka i controlli interni del service organization, conclude che il rapporto e unqualified, e procede. Il fascicolo non identifica i CSOC, non li riconcilia con la configurazione del cliente, non documenta procedure su di essi. Si scrivono le carte dopo, in fase di review, e si capisce subito.
ISA Italia 402.18 chiede al revisore dell'utente di ottenere comprensione dei controlli rilevanti del service organization e di valutare se i CSOC siano stati implementati dall'entita utente. Il verbo e "valutare". Non basta listarli.
Cosa significa in pratica. Si prende l'elenco dei CSOC dal SOC, lo si confronta riga per riga con i controlli effettivi del cliente, e si documenta una conclusione su ciascuno. Esempio comune: il SOC del provider di pagamenti elenca tra i CSOC "the user entity is responsible for restricting access to the merchant portal to authorized personnel". Sul fascicolo, questo si traduce in una procedura che verifica chi ha accesso al portale, con quali ruoli, con quale review periodica del cliente.
Tre cose che osserviamo nei fascicoli puliti.
Il revisore mappa ogni CSOC a un controllo IT general controls (ITGC) o a un controllo applicativo del cliente. Se il mapping non e univoco, lo dice e lo documenta. Si cita il numero di pagina del SOC dove il CSOC e elencato. Le carte tengono.
Il revisore esegue procedure dirette su almeno i CSOC che incidono su rischi rilevanti per il bilancio. Non si limita a inquiry. Per CSOC su autenticazione, si testa la configurazione MFA. Per CSOC su backup, si verifica l'esistenza e il restore test recente.
Il revisore documenta cosa fa quando il CSOC non e implementato. La risposta non e ignorarlo. La risposta e estendere le procedure sostantive, comunicare al management un control deficiency, e considerare l'impatto sul giudizio.
Quando l'inclusive si applica davvero
L'inclusive method non e estinto. Si vede in due configurazioni precise.
Primo caso: il service organization controlla legalmente il sub-service. E.g., una capogruppo che esternalizza il payroll a una controllata; una piattaforma proprietaria che usa un data center di proprieta del gruppo. In questi casi, l'accesso ai controlli del sub-service e contrattualmente garantito, e il service auditor puo testarli direttamente. ISAE 3402.B16 contempla esplicitamente questa fattispecie.
Secondo caso: il sub-service e piccolo, indipendente, e accetta l'inclusive perche il service organization rappresenta una quota significativa del suo fatturato. Si vede nei mercati locali, raramente con i fornitori globali.
In entrambi i casi, l'inclusive richiede che il service auditor ottenga evidenza diretta sui controlli del sub-service. Significa testing presso il sub-service, oppure utilizzo del lavoro di un altro service auditor sotto ISAE 3402.25-.27. La seconda opzione e quella che si incontra piu spesso. ISAE 3402.27 chiede al service auditor di valutare la competenza, l'indipendenza e l'adeguatezza del lavoro del component auditor, esattamente come ISA 600 chiede al revisore di gruppo.
C'e un punto che spesso si dimentica. Quando il sub-service e incluso, il service auditor assume la responsabilita per l'opinion sul sistema combinato, e i CSOC scompaiono dalla descrizione. Sotto inclusive, non ci sono CSOC del sub-service, perche i suoi controlli sono dentro lo scope. Sotto carve-out, ci sono. Tradurre male questo punto e l'errore numero uno che vediamo nei fascicoli che provano a fare ibridi non documentati.
Esempio pratico: pagamenti digitali con cloud carve-out
Pagamenti Digitali Italia SRL processa pagamenti per 85 e-commerce italiani. Ricavi annui 12 milioni di euro. Il sistema applicativo e proprietario; gira su AWS Frankfurt; usa CryptoSecure SPA per tokenizzazione delle carte; usa DataBackup Europe BV per backup off-site dei database.
Tre sub-service. Tre decisioni metodologiche distinte.
AWS. Il MSA esclude inclusive. La direzione di Pagamenti Digitali si rivolge al SOC 2 Type II di AWS Frankfurt per il periodo 1 gennaio - 31 dicembre 2025. Il rapporto e in carve-out per ovvie ragioni: AWS non sara mai dentro lo scope di nessun service auditor. I CSOC sono dieci, elencati alle pagine 78-82 del rapporto AWS. Il revisore di Pagamenti Digitali eredita il compito di verificare che la configurazione AWS del cliente sia coerente con i CSOC: VPC isolata, KMS keys gestite dal cliente, IAM policies restrittive, CloudTrail abilitato, MFA obbligatorio sugli account root.
CryptoSecure. Fornitore italiano, controllo significativo del cliente sull'integrazione, accetta inclusive. Si include nello scope. Il service auditor di Pagamenti Digitali ottiene il SOC 2 Type II di CryptoSecure (emesso da altro auditor) e lo utilizza secondo ISAE 3402.27, valutando competenza e indipendenza dell'altro service auditor. Otto controlli sulla crittografia entrano direttamente nella descrizione del sistema di Pagamenti Digitali.
DataBackup Europe. Servizio di supporto, non critico (il cliente ha replica real-time su data center secondario di proprieta). Si applica carve-out. Tre controlli di interfaccia testati direttamente dal service auditor: verifica del completamento dei backup, restore test mensile documentato, riconciliazione delle integrita.
La complicazione che fa saltare i fascicoli arriva qui. Il SOC di AWS copre 1 gennaio - 31 dicembre 2025. Il rapporto del cliente copre 1 luglio 2025 - 30 giugno 2026. Gap di sei mesi. Servirebbe una bridge letter di AWS che attesti l'assenza di cambiamenti materiali sui controlli tra il 1 gennaio 2026 e il 30 giugno 2026. AWS non emette bridge letter su richiesta, e la sua rotazione del periodo SOC non si allinea con il fiscal year del cliente.
Cosa dice ISAE 3402.B14 a riguardo. Il paragrafo prevede che, in assenza di copertura completa del periodo, il service auditor (qui parliamo del service auditor di Pagamenti Digitali) esegua procedure aggiuntive di rollover sui controlli del service organization. Il problema e che la logica di .B14 si applica al service organization, non al sub-service in carve-out. Sul sub-service in carve-out, la responsabilita ricade sul revisore dell'utente, non sul service auditor.
Risposta operativa. Il revisore di Pagamenti Digitali, lato suo, esegue procedure dirette sulla configurazione AWS al 30 giugno 2026: snapshot delle IAM policies, conferma delle KMS keys, verifica dei flag CloudTrail. La configurazione attuale del cliente diventa l'evidenza che copre il gap, perche i CSOC riguardano cio che il cliente fa, non cio che AWS fa.
Risultato del rapporto SOC di Pagamenti Digitali: 32 controlli interni, 8 di CryptoSecure (inclusive), 5 di interfaccia per i due sub-service in carve-out, AWS divulgato come carve-out con i suoi dieci CSOC riportati per intero. Zero eccezioni.
Disaccordo legittimo: quanto testare i CSOC sui Big-3 cloud
Su questo punto i partner non sono d'accordo, ed e onesto dirlo.
Posizione A. Il SOC 2 Type II di AWS, Azure o GCP basta come reliance esterna ai sensi di ISA 600, applicato per analogia ai service organization. Si controlla il rapporto, se e unqualified si confida, si documentano i CSOC come responsabilita del cliente, e su questi si esegue inquiry mirata piu walkthrough. Procedure dirette ridotte. La motivazione: il rapporto SOC del Big-3 e il prodotto piu testato del mondo, qualunque procedura aggiuntiva del revisore-utente avrebbe un costo enorme con beneficio marginale.
Posizione B. Il SOC 2 ha uno scope diverso da cio che serve al revisore. Il SOC 2 testa i controlli del cloud provider, non la configurazione che il cliente ha scelto. I CSOC esistono proprio perche AWS dichiara: "io ti do questi mattoni; il muro lo costruisci tu". Su quei mattoni va eseguito testing diretto, non reliance. La motivazione: una configurazione MFA non abilitata e una IAM policy permissiva possono compromettere completamente l'environment, indipendentemente dalla qualita del SOC del provider.
La posizione B e quella che, nei fascicoli passati al peer review CNDCEC e ai bollettini CONSOB sulle societa quotate, regge meglio. La A e quella che si trova piu spesso nei fascicoli reali, dove i compensi sono irrisori e il tempo non c'e. Non e una bella verita. E quello che osserviamo.
Una via di mezzo difendibile. Identificare i CSOC che incidono su rischi rilevanti per il bilancio (autenticazione, access management, data integrity) e testarli direttamente. Sui CSOC su rischi residuali (logging, monitoring, change management su componenti non finanziarie), accettare reliance documentata. Si scrivono pero le carte prima, non dopo.
Checklist operativa
1. Identificare ogni sub-service organization usato dal cliente nel periodo. Inventario completo prima del fieldwork. Senza inventario, lo scope si gonfia in chiusura (ISAE 3402.22, .B15).
2. Per ciascun sub-service, determinare carve-out o inclusive. Se contrattualmente l'inclusive non e disponibile (Big-3 cloud, processori globali), si documenta che l'opzione e stata considerata e respinta per ragioni di mercato.
3. Sotto carve-out, estrarre i CSOC dal rapporto SOC del service organization. Riferimento alla pagina del rapporto, numero di CSOC totali, classificazione per area di rischio.
4. Mappare ogni CSOC a un controllo del cliente. Se il mapping non esiste, il cliente non ha implementato il CSOC, e si comunica al management.
5. Sui CSOC che incidono su rischi rilevanti per il bilancio, eseguire procedure dirette di testing. Inquiry da sola non basta sotto ISA Italia 402.18.
6. Verificare la copertura temporale. Se il SOC del sub-service non copre il periodo del cliente, eseguire procedure di rollover sulla configurazione al period-end. Le bridge letter dei Big-3 raramente arrivano.
7. Documentare la metodologia. Il workpaper deve dire perche carve-out, perche inclusive, dove sono i CSOC, come sono stati testati. ISAE 3402.18 lo richiede; CONSOB nei bollettini lo verifica.
8. Sotto inclusive con utilizzo del lavoro di altro service auditor, applicare ISAE 3402.25-.27. Valutazione di competenza, indipendenza, scope, file review. Documentazione separata.
Errori comuni
Si confonde carve-out con esclusione totale. Sotto carve-out, il sub-service esce dallo scope del rapporto del service organization, ma non esce dalla responsabilita del revisore dell'utente. I CSOC restano. ISAE 3402.B17 e .B18 lo dicono.
Si tratta il SOC 2 del cloud provider come se fosse un SOC 1 sul sistema del cliente. Sono due cose diverse. Il SOC 2 testa i controlli del cloud, il SOC 1 testa i controlli rilevanti per il financial reporting. Per un audit di bilancio, serve SOC 1 sul service organization che processa transazioni finanziarie e SOC 2 (o SOC 1) sul cloud provider che ospita l'environment.
Si dimentica il gap temporale. Il periodo SOC del provider quasi mai coincide con il periodo del cliente. Senza bridge letter o procedure aggiuntive, c'e un buco nell'evidenza. La direzione del cliente raramente segnala il problema; lo deve segnalare il revisore.
Si tratta i CSOC come elenco da appendere al fascicolo. Un CSOC non testato e una procedura di revisione mancante. Le carte sono leggere, e in caso di ispezione non reggono.
Si scrivono le carte dopo. Si arriva al closing, si capisce che il SOC era in carve-out, e si retroatta la documentazione sui CSOC. Si vede dalla data dei file. Il peer review CNDCEC e i bollettini CONSOB lo notano.
Contenuti correlati
- Glossario ISAE 3402: service organization controls. Definizioni dei termini tecnici e requisiti normativi per i rapporti SOC, con riferimenti CONSOB e ISA Italia. - ISAE 3402 Workbook. Template per la documentazione dei controlli, mappatura dei CSOC, gestione dei sub-service organization sotto carve-out. - Testing controls in ISAE 3402 engagements. Metodologie di testing per controlli diretti, di interfaccia, e CSOC sotto carve-out.