SOC 1 vs ISAE 3402: Differenze Chiave per Revisori Europei

Indice dei contenuti

- Da dove nasce il problema: la falla che si vede in fascicolo - Cosa richiedono effettivamente SOC 1 e ISAE 3402 - La zona grigia: periodo, CUEC, sub-service organization - Esempio pratico: payroll texano, bilancio milanese, gap di tre mesi - Disaccordo legittimo: il SOC 1 e fungibile con l'ISAE 3402? - Tabella comparativa - Errori che il peer reviewer trovera

Da dove nasce il problema: la falla che si vede in fascicolo

La sequenza che si ripete nei fascicoli che si rivedono in qualita interna e quasi sempre la stessa. Arriva il SOC 1 fornito dal cliente, qualcuno scrive due righe nel memo "ricevuto SOC 1 Type II del fornitore X, controlli operativi", si tickara il riferimento accanto al rischio sul ciclo paghe, e il fascicolo si chiude. Nessuno ha letto la sezione 4 del SOC 1 (i CUEC). Nessuno ha verificato che il periodo coperto dal report combaci con l'esercizio in revisione. Nessuno ha controllato se la service organization esternalizzi a sua volta a una sub-service organization (con conseguente carve-out o inclusive method). Le carte sono leggere. Cosa significa nella pratica: davanti al MEF, il revisore non riuscira a spiegare quali rischi del bilancio italiano siano coperti da quei controlli e quali no.

L'ISA Italia 402 al paragrafo 18 e successivi richiede che il revisore valuti se il rapporto sul service auditor sia adeguato per gli scopi della propria revisione. Non dice "se esiste un report, si tickara il fascicolo". Dice che si valuti la competenza del service auditor, l'idoneita del periodo coperto, la natura dei test, e la conclusione. La differenza concreta tra ricevere un SOC 1 e usarlo come evidenza la fa il revisore, non il fornitore.

> Si potrebbe obiettare che, in una controllata medio-piccola con compensi irrisori, il revisore non puo permettersi di ri-eseguire procedure alternative che gli studi Big 4 invece scaricano sui senior. E un'obiezione vera. Non e un'obiezione che reggera davanti al peer reviewer.

Cosa richiedono effettivamente SOC 1 e ISAE 3402

ISAE 3402: il riferimento internazionale

L'ISAE 3402 disciplina l'incarico di assurance del service auditor. Il service auditor verifica i controlli della service organization che siano rilevanti per il financial reporting delle user entity. Il report distingue tra Type 1 (idoneita del disegno a una data) e Type 2 (idoneita del disegno e operating effectiveness su un periodo). La sezione del report contiene la descrizione del sistema fornita dalla direzione della service organization, l'asserzione della direzione, l'opinione del service auditor, la descrizione dei test e i relativi risultati. La direzione della service organization e responsabile di identificare i CUEC, ossia i controlli che la user entity deve avere in essere perche il sistema funzioni come descritto.

SOC 1 (SSAE 21): l'omologo statunitense

Il SOC 1 e l'attestation engagement disciplinato dall'AICPA secondo SSAE 21 (sezione AT-C 320) per il financial reporting delle user entity. La struttura del report e analoga: Type 1 e Type 2, descrizione del sistema, asserzione del management, opinione del service auditor, sezione 4 con i test e i risultati. Il SOC 1 si distingue dal SOC 2 (Trust Services Criteria su sicurezza, disponibilita, integrita di processo, confidenzialita, privacy) e dal SOC 3 (versione pubblica generale del SOC 2). Solo il SOC 1 e progettato per supportare la revisione del bilancio della user entity. Per carita, un SOC 2 puo contenere informazioni utili sul controllo IT generale, pero non sostituisce il SOC 1 ai fini ISA Italia 402.

Cosa significa nella pratica

Sul piano probatorio, ISAE 3402 e SOC 1 producono evidenze sostanzialmente equivalenti per il revisore italiano, purche il periodo combaci, i CUEC siano identificati e applicati nella user entity, e le sub-service organization siano trattate coerentemente. Il problema non e quasi mai lo standard. Il problema e cosa il SOC 1 (o l'ISAE 3402) effettivamente copre.

La zona grigia: periodo, CUEC, sub-service organization

Il gap di periodo

Capita raramente che il periodo del SOC 1 corrisponda all'esercizio italiano. Il SOC 1 Type II tipicamente copre 9-12 mesi (spesso ottobre-giugno o luglio-giugno per ragioni interne al fornitore statunitense). Se il bilancio chiude al 31 dicembre e il SOC 1 copre fino al 30 giugno, restano sei mesi scoperti. Si possono fare due cose: ottenere una bridging letter dalla direzione della service organization che attesti l'assenza di modifiche significative ai controlli (evidenza debole), oppure svolgere procedure alternative direttamente sulla user entity ai sensi dell'ISA Italia 330 (evidenza forte). Nella mia esperienza su PMI italiane controllate da gruppi USA, la bridging letter da sola non basta, soprattutto quando in quei sei mesi la service organization ha cambiato sistema, fornitore cloud, o personale chiave.

CUEC: il punto piu trascurato

I Complementary User Entity Controls sono controlli che la user entity (cioe il cliente revisionato) deve avere in atto perche i controlli della service organization funzionino. Esempio tipico: la service organization elabora gli stipendi solo a partire dai dati che il cliente carica nel portale. Il controllo sul corretto caricamento e un CUEC e responsabilita della user entity. Se il revisore italiano si fida del SOC 1 senza verificare i CUEC nel cliente, sta affermando in sostanza che dei controlli che non sono stati testati funzionano comunque. Questa e la falla che il peer reviewer trova in due ore.

Sub-service organization: carve-out vs inclusive

La service organization puo esternalizzare a sua volta. Il SOC 1 puo trattare la sub-service organization in due modi: carve-out (i suoi controlli sono esclusi dal report) o inclusive (i suoi controlli sono inclusi). Se il SOC 1 e in carve-out, il revisore deve ottenere assurance separata sulla sub-service organization, tipicamente un secondo SOC 1 o ISAE 3402, oppure svolgere procedure dirette. Si tickara il primo SOC 1 e si dimentica della sub-service organization: e un classico, e non regge.

Esempio pratico: payroll texano, bilancio milanese, gap di tre mesi

Cliente: Beta Italia S.r.l., controllata di Beta US Inc., 320 dipendenti, bilancio chiuso al 31 dicembre 2025, ricavi EUR 41M.

Service organization: PayrollCo LLC, Texas, fornisce elaborazione stipendi per il gruppo. Rilascia un SOC 1 Type II per il periodo 1 ottobre 2024 - 30 settembre 2025.

Sub-service organization: PayrollCo usa un fornitore cloud (CloudBase Inc.) per l'hosting dei dati. Il SOC 1 di PayrollCo tratta CloudBase in carve-out.

Step 1 - Lettura della sezione 4 del SOC 1. Si identificano 14 control objectives, 47 controlli testati, 4 eccezioni rilevate (su autorizzazioni utenti, documentate come isolated). Si valuta che le eccezioni non compromettano l'opinione complessiva, ma si annota un follow-up sui controlli IT general.

Step 2 - Identificazione dei CUEC. La sezione 4 elenca 6 CUEC, di cui 3 rilevanti per Beta Italia: caricamento corretto delle anagrafiche dipendenti nel portale, autorizzazione delle modifiche retributive, riconciliazione mensile tra dati caricati e cedolini ricevuti. Si testa ciascuno di questi controlli in Beta Italia con una selezione mensile (12 mesi). Si rileva che la riconciliazione mensile non e documentata da marzo a giugno 2025. Cosa significa nella pratica: per quattro mesi, Beta Italia non ha effettivamente esercitato un controllo che il SOC 1 assume come operativo.

Step 3 - Gestione del gap di periodo. Il SOC 1 termina il 30 settembre 2025; il bilancio chiude il 31 dicembre. Tre mesi scoperti. Si chiede a PayrollCo una bridging letter (ottenuta, conferma assenza di modifiche significative). Pero la bridging letter non e sufficiente per il rischio sul ciclo paghe (rischio identificato come significativo in fase di pianificazione). Si svolgono procedure alternative direttamente: ricalcolo di un campione di cedolini di novembre e dicembre, riconciliazione tra costo del personale a CE e cedolari elaborati, verifica dei versamenti contributivi a INPS.

Step 4 - Trattamento della sub-service organization. Il carve-out su CloudBase obbliga a procedure separate. Si valuta che i controlli IT general su CloudBase siano rilevanti per la disponibilita e integrita dei dati paghe. Si ottiene un SOC 2 Type II di CloudBase (non un SOC 1, perche CloudBase non si pone come financial reporting service). Si documenta il razionale per cui il SOC 2 di CloudBase, combinato con i CUEC IT testati su PayrollCo, fornisce assurance sufficiente.

Esito. Il fascicolo regge davanti al peer reviewer perche ogni assunzione fatta sul SOC 1 e tracciata, ogni CUEC e testato, il gap di periodo e chiuso con procedure dirette, e la sub-service organization e trattata esplicitamente. Le ore aggiuntive sono state circa 22 rispetto a un fascicolo che si limita a tickare il SOC 1.

Disaccordo legittimo: il SOC 1 e fungibile con l'ISAE 3402?

La domanda non e accademica. Si presenta in studio ogni volta che un cliente USA-centric fornisce solo il SOC 1.

Il Partner A sostiene che il SOC 1 e l'ISAE 3402 producono evidenza fungibile per il revisore italiano. La logica: i due standard hanno requisiti convergenti su descrizione del sistema, asserzione della direzione, test sui controlli, opinione del service auditor; il PCAOB e l'IAASB si parlano regolarmente; il peer reviewer italiano accetta SOC 1 senza obiezioni se l'evidenza e tracciata. Per il Partner A, distinguere tra SOC 1 e ISAE 3402 sul piano probatorio e una distinzione formale che non aggiunge qualita al fascicolo.

Il Partner B sostiene che i requisiti probatori dell'ISA Italia 402 differiscono in dettagli sostanziali da AICPA AU-C 402, e che un SOC 1 non risponde meccanicamente a tutti i punti dell'ISA Italia 402. La logica: il peer reviewer italiano, in particolare quello del MEF dal 2025, sta affinando l'esame sui rapporti di service auditor stranieri; alcune verifiche (ad esempio la valutazione di indipendenza del service auditor secondo i criteri italiani) non sono automaticamente soddisfatte da un SOC 1; in caso di contestazione CONSOB su una EIP, il revisore che si e basato solo su un SOC 1 senza valutare la corrispondenza ai requisiti ISA Italia avra una difesa piu fragile.

La mia posizione: il Partner B ha ragione nei fatti, il Partner A ha ragione nella prassi su clienti non EIP. Il punto pratico: per ogni SOC 1 ricevuto, si scrive una mezza pagina di memo che mappa i requisiti ISA Italia 402 sul contenuto del SOC 1, si nominano le aree dove il SOC 1 e silente, e si spiega come si chiude il gap. Questa mezza pagina e cio che separa un fascicolo che regge da uno che no.

Tabella comparativa

Errori che il peer reviewer trovera

1. SOC 1 ricevuto e tickato senza lettura della sezione 4. Il fascicolo non spiega quali controlli del fornitore sono rilevanti per quali asserzioni del bilancio italiano.

2. CUEC non testati nella user entity. I controlli che la service organization assume in atto presso il cliente non sono stati verificati. Le carte sono leggere e la conclusione sul rischio non e sostenuta.

3. Gap di periodo coperto solo da bridging letter. Per rischi significativi, la sola attestazione della direzione della service organization non basta. L'ISA Italia 330 richiede procedure responsive alla risk assessment.

4. Sub-service organization in carve-out ignorata. Il SOC 1 di PayrollCo non copre CloudBase. Se non si ottiene assurance separata, c'e un buco nella catena probatoria che il revisore non ha colmato.

5. SOC 2 usato in sostituzione del SOC 1. Il SOC 2 risponde ai Trust Services Criteria, non al financial reporting. Puo integrare ma non sostituire.

6. Indipendenza del service auditor non valutata. L'ISA Italia 402 richiede che si valuti la competenza professionale e l'indipendenza del service auditor. Tickare il riferimento al firm name del SOC 1 non equivale a tale valutazione.

Contenuti correlati

- Guida ISAE 3402 - Definizione completa dello standard internazionale per l'attestazione sui controlli presso service organization - Calcolatore di campionamento per controlli - Strumento per determinare la frequenza e l'ampiezza del testing dei controlli manuali in engagement ISAE 3402 - ISAE 3402 Type I vs Type II - Confronto tra i due tipi di engagement ISAE 3402 e criteri per la scelta del tipo appropriato