SOC 2 Type II per startup SaaS nel 2026: scope, controlli, timeline dell'audit

Yury Pukhov CEO, YuSMP Group · Ingegneria SaaS, programmi di compliance e preparazione al procurement enterprise dal 2014

Type I vs Type II — cosa richiedono gli acquirenti enterprise nel 2026

Il SOC 2 esiste in due versioni, e la differenza conta di più nel 2026 che non due anni fa. Un report Type I è un'attestazione punto-temporale: alla data in cui l'auditor ha esaminato il sistema, i controlli erano progettati in modo appropriato. Un report Type II attesta che quei controlli hanno anche operato efficacemente nel corso di una finestra definita — tipicamente sei o dodici mesi.

Nel 2026 il playbook del procurement in quasi ogni Fortune 1000 e nella maggior parte dei buyer SaaS Series C+ si legge così:

• Al di sotto di $25k ACV: un Type I più un questionario di sicurezza è spesso accettabile.
• $25k–$250k ACV: il Type II con almeno una finestra di sei mesi è il minimo. Il Type I riceverà un «torna quando hai il Type II».
• Sopra $250k ACV o qualsiasi acquirente regolamentato (servizi finanziari, sanità, federale): Type II che copre i dodici mesi precedenti, ISO 27001 a fianco è sempre più standard, e un report di penetration test da una firma nominata.

Il Type I ha un caso d'uso onesto nel 2026: colmare una lacuna. Si può emettere un Type I in 4–6 settimane una volta completata la readiness, consegnarlo a un acquirente per sbloccare il contratto, e emettere il Type II alla fine della prossima finestra di osservazione. Investire il budget del Type I solo se c'è un acquirente specifico che lo attende. Altrimenti saltarlo e andare direttamente a un Type II di sei mesi — il rinnovo del secondo anno cadrà su una cadenza più pulita e si evitano le parcelle duplicate dell'auditor.

Per i founder che vendono principalmente nell'Unione Europea, il SOC 2 viene spesso abbinato a — o sostituito da — ISO 27001 e una postura GDPR. Trattiamo la meccanica lato UE nel nostro articolo sul GDPR per founder US che vendono in Europa, e le integrazioni specifiche per l'AI in conformità EU AI Act.

Trust Services Criteria — quale scegliere

Il SOC 2 viene definito tramite i cinque Trust Services Criteria (TSC), definiti dall'AICPA. Solo uno è obbligatorio; gli altri quattro sono opzionali e ognuno aggiunge un reale costo all'audit. La scelta giusta dipende da ciò che i contratti promettono.

Lo stack pragmatico per una startup SaaS B2B Series A/B nel 2026 è Security + Availability + Confidentiality. Copre le domande del questionario che si affrontano davvero, segnala un impegno SLA e mantiene la parcella dell'audit nella fascia $20k–$35k. Aggiungere Processing Integrity solo se un regolatore o uno dei tre buyer principali lo richiede esplicitamente. Saltare Privacy al primo anno — GDPR e CCPA hanno più peso nel procurement del 2026, e i controlli si sovrappongono largamente.

Scope: sistemi in-scope e carve-out delle sub-service

La definizione dello scope è dove la maggior parte dei programmi SOC 2 perde tempo. Lo scope è il sistema di produzione che eroga il servizio ai clienti — non il sito di marketing, non la Notion delle risorse umane interne, non il cluster di test. Decidere cosa è in-scope chiedendosi: «Questo sistema elabora o conserva dati dei clienti, o è parte del percorso di produzione che lo fa?» Se sì, in-scope. Se no, fuori.

Per una tipica startup SaaS, i sistemi in-scope comprendono:

• L'account AWS / GCP / Azure di produzione che ospita l'app, inclusi tutti i compute, storage, database, code e secrets manager.
• Il sistema di controllo del codice sorgente che contiene il codebase di produzione (GitHub, GitLab, Bitbucket) e le sue protezioni dei branch.
• La pipeline CI/CD che distribuisce in produzione (GitHub Actions, CircleCI, Buildkite, Argo).
• Il provider di identità usato dai dipendenti per accedere alla produzione (Okta, Google Workspace, Microsoft Entra ID).
• Lo stack di monitoring e logging (CloudWatch, Datadog, Grafana, Splunk, Wiz, Sentry).
• Il sistema di ticketing e gestione dei cambiamenti (Linear, Jira, GitHub Issues) — perché è lì che si producono le evidenze delle approvazioni.
• La soluzione MDM che gestisce i laptop dei dipendenti che accedono alle credenziali di produzione (Jamf, Kandji, Intune).

Fuori scope: il WordPress di marketing, il CRM di vendita, il portale di supporto (a meno che non elabori dati dei clienti), e gli ambienti sandbox pre-produzione privi di dati cliente e senza credenziali condivise con la produzione.

Sub-service organization — il metodo carve-out

Quasi ogni startup SaaS si affida a terze parti: AWS per il compute, Stripe per i pagamenti, Auth0 per l'identità, Twilio per la messaggistica, Datadog per il monitoring. Il metodo carve-out dice all'auditor: «Questi fornitori hanno i propri report SOC 2 / ISO 27001. Fidatevi di quelli, non rivedeteli attraverso me.»

Questa è la risposta giusta nel 99% dei casi. La meccanica:

1. Elencare le sub-service organization nella descrizione del sistema SOC 2.
2. Raccogliere i loro report SOC 2 Type II / ISO 27001 correnti ogni anno (AWS Artifact, portale trust di Stripe, trust center di Auth0, ecc.).
3. Implementare i complementary user entity controls (CUEC) che il report di ogni fornitore prescrive. Questi sono gli elementi che si devono fare — che loro non possono fare al posto nostro. Esempi: abilitare MFA sull'account root AWS, non conservare mai la chiave root nel codice, ruotare le chiavi ristrette di Stripe ogni 90 giorni, configurare la protezione brute-force di Auth0, cifrare i bucket S3 gestiti dal cliente con SSE-KMS.
4. Conservare le evidenze che ogni CUEC è applicato. La piattaforma di automazione della conformità automatizza la maggior parte di questa raccolta.

Famiglie di controlli con esempi concreti

I Common Criteria si suddividono in nove famiglie (da CC1 a CC9). La maggior parte dei team di ingegneria si preoccupa concretamente di cinque di esse nel lavoro quotidiano. Di seguito è riportato come appare ognuna in una startup SaaS del 2026 — non il linguaggio delle policy, ma la meccanica reale.

Gestione degli accessi

• SSO ovunque. Okta o Google Workspace come unica sorgente di identità. Provisioning SCIM dove il SaaS lo supporta. Nessun account di servizio condiviso che accede con password.
• MFA applicato su ogni sistema adiacente alla produzione. Chiavi hardware (YubiKey, Titan) per gli admin; TOTP minimo per tutti gli altri. L'MFA solo via SMS è un finding nel 2026.
• RBAC con least privilege. Gruppi AWS IAM, non policy inline. Team GitHub, non collaboratori individuali. Revisioni degli accessi annuali registrate nel sistema di ticketing — trimestrali per i ruoli di tier produzione.
• Off-boarding entro un giorno lavorativo. Checklist documentata che copre Okta, AWS, GitHub, Slack, Notion, Linear, Datadog, Sentry e ogni altro tenant. La maggior parte degli audit falliti inizia qui.

Gestione dei cambiamenti

• Ogni modifica alla produzione passa attraverso una pull request. Nessun commit diretto su main; branch protetti.
• Almeno un reviewer indipendente. Approvazione PR obbligatoria prima del merge; CODEOWNERS per i percorsi sensibili.
• Gate di test automatizzato. Il CI deve passare sulla PR prima del merge. I fallimenti dei test non possono essere bypassati senza un'eccezione documentata.
• Deploy in produzione tracciabili a una PR e a un ticket. I log di deploy si collegano al Git SHA; i messaggi di commit referenziano gli ID Linear/Jira.
• Procedura di emergenza documentata e raramente usata. Gli auditor verificano che «emergency» non sia la modalità predefinita.

Monitoring e detection

• Log centralizzati. CloudWatch + Datadog o Splunk; log conservati 365+ giorni; l'accesso ai log stessi è registrato.
• Alerting sugli eventi di sicurezza. Picchi di login falliti, modifiche alle policy IAM, modifiche alle chiavi KMS, modifiche ai security group, utilizzo dell'account root.
• Copertura CSPM / CNAPP. Wiz, Orca, Lacework, o Prowler che gira continuamente sull'account cloud. Finding triaggiati entro un SLA documentato.
• Endpoint detection. CrowdStrike, SentinelOne, o Jamf Protect su ogni laptop con accesso alla produzione.
• Gestione delle vulnerabilità. Dependabot / Renovate più Snyk o GitHub Advanced Security; l'SLA per i critici (tipicamente 30 giorni) è il controllo che viene testato, non la scelta dello scanner.

Incident response

• Piano IR scritto con scala di gravità, rotazione on-call, template di comunicazione e soglie di notifica al cliente.
• Almeno un esercizio tabletop all'anno con verbale depositato.
• Post-mortem su ogni incidente visibile ai clienti con action item tracciati alla chiusura.
• Percorso forense e di notifica della violazione documentato — anche se non è mai stato usato, l'auditor chiederà.

Gestione dei fornitori

• Inventario dei fornitori. Un elenco aggiornato di ogni sub-processor e SaaS che tocca i dati dei clienti. Le piattaforme di compliance lo mantengono per te se connesse.
• Tier di rischio per fornitore (basso/medio/alto) in base alla sensibilità dei dati e alla profondità dell'integrazione.
• Report SOC 2 / ISO 27001 raccolti annualmente per i fornitori di tier medio e superiore.
• DPA / BAA firmato dove richiesto. Se si vende in ambito healthcare si ha bisogno anche di BAA di livello HIPAA.

Piattaforme di automazione della conformità a confronto

Si può gestire un programma SOC 2 con i fogli di calcolo. Lo abbiamo fatto nel 2018. Nel 2026 nessuno dovrebbe farlo — il costo di una piattaforma di automazione della conformità si recupera in circa 80 ore di raccolta evidenze risparmiate nel corso di una finestra di osservazione.

Le quattro piattaforme che competono davvero nel 2026:

Cosa fanno bene tutte e quattro: raccogliere continuamente evidenze da AWS / GCP / Azure / GitHub / Okta / Jamf / Datadog / Linear e simili; mappare queste evidenze sui test dei controlli; segnalare deviazioni quando un controllo fallisce; fornire template di policy; mettere a disposizione un portale auditor al momento dell'audit.

Cosa nessuna fa: scrivere il proprio SDLC sicuro, eseguire threat modelling, correggere i finding, gestire davvero l'off-boarding, condurre il tabletop. Prevedere un owner part-time all'interno dell'ingegneria — di solito il CTO, il responsabile della piattaforma o un ingegnere DevOps senior — per guidare il programma. Esternalizzare il ruolo di owner al vendor della piattaforma è il motivo più comune per cui un primo audit fallisce o slitra.

Finestra di osservazione — 3, 6 o 12 mesi?

Il minimo che qualsiasi auditor affidabile accetta è tre mesi, e diversi Big Four non scendono sotto i sei. I default che consigliamo:

• Tre mesi: solo se un acquirente enterprise specifico lo ha accettato per iscritto. Fragile, e quasi certamente richiede un secondo engagement immediato.
• Sei mesi: il Type II standard per la prima volta. Abbastanza lungo per campionare le evidenze in modo convincente, abbastanza breve da non causare fatica del programma.
• Dodici mesi: il default dal secondo anno in poi, perché corrisponde al periodo di validità del report e alla cadenza di rinnovo che gli acquirenti si aspettano.

Sequenza pratica per una startup senza precedente compliance: 8–12 settimane di lavoro di readiness, poi un Type I (opzionale) per sbloccare gli acquirenti immediati, poi una finestra di osservazione di 6 mesi per il Type II. Tempo totale da «decidiamo di fare il SOC 2» a «report Type II in mano»: 9–12 mesi.

Selezione dell'auditor e costi

Solo una società CPA autorizzata può emettere un report SOC 2. Il panorama nel 2026 si divide in tre tier:

Scegliere il tier più piccolo che gli acquirenti accettano. Non abbiamo ancora visto un acquirente rifiutare un report Schellman, A-LIGN o Insight Assurance nel 2026. Abbiamo visto acquirenti rifiutare report di auditor sconosciuti — verificare che la firma abbia una lista pubblica di clienti e almeno 100 report SOC 2 emessi.

Costi nascosti oltre la parcella dell'auditor: un penetration test da una firma nominata (Cobalt, NetSPI, Bishop Fox: $8k–$25k), la piattaforma di compliance ($12k–$30k/anno), tempo di ingegneria (0,3–0,6 FTE durante la finestra), e remediation dei finding durante l'audit (di solito 40–80 ore di ingegneria). Totale realistico del primo anno all-in per una startup SaaS Series A/B: $50k–$120k.

Finding comuni da evitare

Negli engagement SOC 2 che abbiamo osservato, quattro finding appaiono in circa il 70% dei report del primo anno. Ognuno è prevenibile con disciplina, non con ingegneria.

1. Dipendente cessato ancora attivo in almeno un sistema. L'off-boarding ha coperto Okta e AWS ma non il tenant Datadog autonomo creato due anni fa, o il team Postman, o l'org Sentry. Soluzione: mantenere una checklist di deprovisioning che elenca ogni tenant per nome; rivederla mensilmente; far firmare all'HR quando un dipendente lascia.
2. Modifica alla produzione senza ticket corrispondente. Un hotfix è andato come commit diretto, o una migrazione manuale del database è stata eseguita senza PR. Soluzione: applicare branch protetti; far sì che ogni log di deploy faccia riferimento a una PR; avere una procedura di emergenza documentata (e raramente usata).
3. Disaster recovery non testato. Il runbook esiste ma nessuno ha effettivamente eseguito un restore-from-backup nella finestra di osservazione. Soluzione: pianificare un drill trimestrale di restore-from-backup, depositare il verbale, anche se il drill dura 30 minuti.
4. Revisione del fornitore saltata. Un nuovo sub-processor è stato aggiunto a metà finestra senza valutazione del rischio e senza raccolta del SOC 2. Soluzione: subordinare ogni decisione «Aggiungi integrazione» a un modulo di intake del fornitore di 15 minuti nella piattaforma di compliance.

Continuous compliance dopo il report

Il giorno in cui viene emesso il report Type II, inizia la prossima finestra di osservazione. Non c'è interruzione. La freschezza delle evidenze degrada immediatamente; i controlli si allontanano dalla baseline mentre il team di ingegneria rilascia funzionalità; vengono aggiunti nuovi fornitori; le persone vanno e vengono. Tre abitudini mantengono il programma in salute:

1. Revisione mensile delle deviazioni. 30 minuti nella piattaforma di compliance guardando i controlli in errore. Quasi sempre banale — un reset MFA non ripristinato, un utente Datadog non in SSO, un report SOC 2 scaduto di un sub-processor.
2. Mini-audit interno trimestrale. Campionare cinque controlli a caso, fingere di essere l'auditor, raccogliere evidenze. Se non si riesce, correggere il gap prima che l'auditor reale lo trovi.
3. Revisione annuale del programma. Ridefinire lo scope man mano che il prodotto evolve — nuovi TSC, nuove sub-service organization, nuove linee di business.

Il SOC 2 si sovrappone anche a framework adiacenti che potrebbero essere necessari: ISO 27001 (più comune in Europa), HIPAA (sanità USA — vedi la nostra checklist per lo sviluppo software HIPAA), GDPR (residenza dati UE e diritti — vedi GDPR per founder US), e i nuovi obblighi del Regolamento UE sull'IA per SaaS arricchiti di AI (vedi conformità EU AI Act). Circa il 70% dei controlli si sovrappone, quindi una volta che il SOC 2 è in salute aggiungere un secondo framework è incrementale, non duplicativo.

FAQ

Gli acquirenti enterprise nel 2026 accettano ancora il SOC 2 Type I?

Raramente, e solo come misura temporanea. Nel 2026 i team di procurement mid-market ed enterprise trattano il Type I come prova che si intende essere conformi, non che lo si è. Un Type I sblocca una conversazione sul questionario di sicurezza; un Type II sblocca il contratto. Se l'acquirente è regolamentato (servizi finanziari, sanità, settore pubblico), aspettarsi che rifiuti il Type I e richieda un Type II che copra almeno i sei mesi precedenti.

Quali Trust Services Criteria dovrebbe scegliere una startup SaaS?

Security (i Common Criteria) è obbligatorio in ogni engagement SOC 2. Per un tipico SaaS multi-tenant, aggiungere Availability se si vende un SLA di uptime, e Confidentiality se si trattano dati business dei clienti sotto NDA. Aggiungere Processing Integrity solo quando le garanzie di accuratezza sono centrali al prodotto (calcoli fintech, buste paga, fatturazione). Privacy è raramente conveniente al primo engagement — GDPR o CCPA fanno di più per gli acquirenti e Privacy aggiunge il 30–50% al costo dell'audit.

Quanto deve durare la finestra di osservazione SOC 2 Type II?

Il minimo che gli auditor accettano è tre mesi e quasi tutti i Big Four rifiutano qualsiasi cosa inferiore a sei. Il default pragmatico per un primo Type II è sei mesi. Estendere a dodici solo se un acquirente enterprise strategico lo richiede esplicitamente o se si intende saltare il Type I e andare direttamente al Type II per la cadenza di rinnovo.

Quanto costa il SOC 2 Type II nel 2026?

Per una startup SaaS Series A/B, aspettarsi $15.000–$25.000 per la parcella dell'auditor presso una boutique CPA affidabile, $25.000–$40.000 presso una firma nazionale, e $40.000–$60.000+ presso i Big Four. Aggiungere $12.000–$30.000/anno per una piattaforma di automazione della conformità (Vanta, Drata, Secureframe, Sprinto), più 0,3–0,6 FTE di tempo di ingegneria e security operations durante la finestra. Totale primo anno all-in: $50.000–$120.000.

Vanta, Drata o Secureframe sostituiscono davvero un ingegnere della sicurezza?

No. Sostituiscono il foglio di calcolo che tiene traccia delle evidenze e il consulente che copia e incolla i template di policy. Le piattaforme raccolgono continuamente evidenze da AWS, GCP, Azure, GitHub, Okta, Jamf e sorgenti simili, le mappano sui test dei controlli e segnalano le deviazioni. Non scrivono il proprio SDLC sicuro, non eseguono threat modelling e non correggono i finding. Pianificare un owner part-time all'interno dell'ingegneria per il primo anno — di solito il CTO o un ingegnere DevOps senior.

Le sub-service organization come AWS, Stripe e Auth0 possono essere escluse dallo scope?

Sì, e quasi sempre dovrebbero esserlo. Il metodo carve-out rimuove i controlli della sub-service organization dal proprio scope e indica all'auditor i loro report SOC 2 / ISO 27001. I complementary user entity controls (CUEC) che AWS, Stripe e Auth0 pubblicano si applicano comunque — bisogna implementarli (ad esempio abilitare MFA sull'account root AWS, ruotare le chiavi ristrette di Stripe) e avere evidenze che l'auditor possa campionare.

Quali sono i finding più comuni in un audit SOC 2 Type II?

Quattro appaiono in modo affidabile negli audit del primo anno: (1) dipendenti cessati ancora attivi in almeno un sistema perché l'off-boarding non ha coperto ogni tenant SaaS, (2) modifiche alla produzione distribuite senza un ticket o un'approvazione PR corrispondenti, (3) un test di disaster recovery o restore-from-backup pianificato ma mai eseguito, (4) revisioni dei fornitori saltate o questionari di sicurezza mancanti per i sub-processor. Tutti e quattro sono prevenibili con disciplina e una revisione mensile di 30 minuti.

Cosa succede dopo il report — il SOC 2 è un'attività una-tantum?

No. I report SOC 2 Type II sono validi per dodici mesi dalla data di emissione e gli acquirenti enterprise si aspettano un rinnovo annuale senza interruzioni. Il problema della «continuous compliance» è che la freschezza delle evidenze degrada, i controlli si allontanano dalla baseline mentre il team di ingegneria rilascia funzionalità, e la prossima finestra di osservazione inizia il giorno in cui si conclude la precedente. Trattare il SOC 2 come una cadenza annuale con mini-audit interni trimestrali e una piattaforma di automazione della conformità che monitora le deviazioni.

Ultimo aggiornamento 27 maggio 2026. Le parcelle degli auditor, i prezzi delle piattaforme e le norme del procurement riflettono le tariffe e le osservazioni sul campo a maggio 2026.