SOC 2 in 90 giorni: come un SaaS sanitario ha superato il suo primo audit

Progetto rappresentativo. Dettagli del cliente anonimizzati ed elementi specifici modificati sotto NDA.

L’email che ha dato il via a tutto non veniva da un team di sicurezza. L’aveva inoltrata un fondatore, tre righe, con l’oggetto “rischiamo di perdere il contratto”. Un’azienda SaaS sanitaria di circa 40 persone aveva un contratto enterprise fermo all’ufficio legale, e il gruppo rischio fornitori dell’acquirente aveva risposto con una sola condizione: fornire un report SOC 2 prima del go-live. L’azienda non ne aveva uno. Le restavano 90 giorni prima che si chiudesse la finestra di rinnovo.

È così che inizia davvero la maggior parte dei progetti di preparazione a SOC 2. Non perché un team di sicurezza decide di maturare, ma perché un cliente trattiene un contratto finché non dimostri di prendere sul serio la sicurezza. Novanta giorni sono davvero pochi, ma sono gestibili per un Type II con una finestra di osservazione breve se ti muovi in fretta e smetti di trattare l’audit come una pratica burocratica. La trappola è il perimetro. I team bruciano regolarmente il primo mese a discutere di cosa includere invece di raccogliere prove.

Ecco cosa abbiamo fatto, cosa ha rivelato la gap analysis e la manciata di cambiamenti che ha permesso loro di superarlo.

Punti chiave

• La preparazione a SOC 2 consiste nel dimostrare che i controlli funzionano nel tempo, non nello scrivere policy la settimana prima che arrivi l’auditor. Fai partire l’orologio delle prove dal primo giorno.
• Per un Type II su una finestra breve, la via più rapida è un perimetro ristretto: il sistema di produzione che tocca i dati dei clienti, e nient’altro.
• Le lacune che fanno fallire i primi audit sono banali. Nessuna revisione degli accessi, nessuna prova di offboarding, un logging che gira ma che nessuno legge. Non attacchi esotici.
• Collega la raccolta delle prove all’identità, alla configurazione cloud e alla gestione dei ticket, così i controlli generano da soli la propria prova invece di dipendere dagli screenshot.
• Una valutazione di preparazione prima dell’audit trasforma il “speriamo che passi” in un elenco noto di lacune con responsabili e date.

Cosa richiede davvero SOC 2 a un’azienda

SOC 2 è un report di attestazione prodotto da uno studio CPA autorizzato rispetto ai Trust Services Criteria dell’AICPA. Ogni SOC 2 copre la Security, nota come common criteria, e opzionalmente si aggiungono Availability, Confidentiality, Processing Integrity o Privacy. Un report Type I dice che i tuoi controlli erano progettati correttamente a una data specifica. Un Type II dice che hanno effettivamente funzionato per un periodo, di solito da tre a dodici mesi. Gli acquirenti enterprise vogliono quasi sempre il Type II, perché un’istantanea limitata alla progettazione non prova nulla su come ti comporti giorno per giorno.

Per un SaaS sanitario, la Confidentiality rientra di solito nel perimetro, e sopra si aggiunge una seconda realtà: se tratti dati sanitari protetti, HIPAA continua ad applicarsi. SOC 2 non sostituisce HIPAA. In questo progetto i due si sovrapponevano abbastanza da farci mappare ogni controllo una volta sola e soddisfare entrambi i requisiti ovunque coincidessero, il che ha risparmiato al team di fare due volte lo stesso lavoro.

Ecco la parte che alla gente sfugge. SOC 2 non ti consegna un elenco di controlli da implementare. Non esiste una checklist principale dell’AICPA. Sei tu a definire i tuoi controlli rispetto ai criteri, e l’auditor verifica se quei controlli esistono e funzionano. È proprio questa libertà a far incagliare i team lasciati a se stessi.

Il piano di 90 giorni che abbiamo eseguito

Abbiamo suddiviso la finestra in tre fasi e fatto partire subito l’orologio delle prove, invece di aspettare che il corpus di policy fosse perfetto.

Giorni da 1 a 20: perimetro, gap analysis e l’orologio delle prove

Per prima cosa abbiamo bloccato il perimetro, ed è stata una battaglia. L’istinto del cliente era includere tutto: il sito di marketing, uno strumento di analytics interno, tre account AWS separati. Lo abbiamo ridotto al solo account di produzione che ospita l’applicazione e tratta i dati dei clienti. L’espansione del perimetro è l’errore più costoso di un primo audit. Ogni sistema che ci trascini dentro moltiplica le prove che devi produrre e i controlli che devi mantenere in funzione per l’intero periodo di osservazione.

Poi la valutazione di preparazione. Abbiamo esaminato ogni controllo dei common criteria e lo abbiamo contrassegnato come presente, parziale o mancante. Il risultato era un semplice registro delle lacune con un responsabile e una scadenza per riga, non un report di 60 pagine che nessuno apre dopo il kickoff.

Giorni da 20 a 55: remediation

È qui che avviene il lavoro vero. Abbiamo messo in piedi i controlli mancanti, collegato la raccolta delle prove agli strumenti che il team già usava e avviato la finestra di osservazione, in modo che l’auditor avesse una storia operativa autentica da campionare invece di una settimana di attività raffazzonata all’ultimo.

Giorni da 55 a 90: operare, raccogliere e l’audit

I controlli giravano mentre le prove si accumulavano da sole. Abbiamo fatto una prova generale interna rispetto all’elenco di richieste atteso dall’auditor, sistemato i due punti ancora deboli e consegnato un pacchetto di prove pulito allo studio CPA.

Cosa abbiamo trovato nella gap analysis

Nessuna delle lacune serie era spettacolare. È il modello di quasi ogni progetto di prima preparazione a SOC 2 che gestiamo. Ciò che fa fallire gli audit è l’igiene operativa, non gli zero-day.

Nessuna revisione degli accessi utente. Nessuno si era mai seduto a chiedersi chi potesse raggiungere la produzione e se ne avesse ancora bisogno. Due ex collaboratori esterni avevano ancora utenti IAM attivi, uno di loro quasi un anno dopo la fine del contratto. CC6.1 e CC6.2 se ne occupano entrambi, e l’accesso è una delle prime cose che un auditor campiona.

L’offboarding era informale. Quando qualcuno andava via, il portatile tornava indietro ma l’accesso veniva revocato “quando qualcuno se ne ricordava”. Nessun ticket, nessun timestamp, nessuna prova. Un auditor non accetta il “lo facciamo sempre”. Sceglie una persona uscita dall’elenco HR e ti chiede di mostrare il record di deprovisioning con una data sopra.

Il logging era attivo ma non osservato. CloudTrail era abilitato, cosa che i team adorano indicare. I log finivano in un bucket S3 che nessun essere umano e nessun alert hanno mai toccato. Il rilevamento che non guardi mai non è un controllo. È spazio di archiviazione con una fattura mensile.

Nessuna gestione formale del cambiamento. Gli ingegneri effettuavano merge e deploy tramite pull request revisionate dai pari su GitHub, il che era in realtà una pratica solida. Ma nulla di scritto legava quella pratica a un controllo, quindi dalla sedia dell’auditor non esisteva.

La gestione dei fornitori era un foglio di calcolo toccato l’ultima volta nel 2023. Un SaaS sanitario si appoggia a subfornitori, e i criteri si aspettano che tu li tenga tracciati e monitori la loro postura di sicurezza.

Guarda quanti di questi sono problemi di documentazione e di prova piuttosto che di “questo non lo facciamo affatto”. Una grande parte della preparazione a SOC 2 consiste nel rendere leggibili, a qualcuno che non era nella stanza, pratiche buone ma invisibili.

Come abbiamo chiuso le lacune senza rallentare l’engineering

La regola che abbiamo fissato con il cliente era netta: automatizzare le prove così un controllo produce da solo il proprio giustificativo, e ripiegare su un processo manuale solo dove l’automazione non vale lo sforzo.

Per identità e accessi, abbiamo messo tutti dietro SSO, imposto l’MFA e istituito una revisione degli accessi trimestrale ricorrente, con l’esito archiviato come artefatto datato invece che in un thread Slack che scorre nell’oblio. Per il deprovisioning, abbiamo legato l’offboarding a un modello di ticket, così ogni uscita genera ora un record con timestamp della rimozione degli accessi. Quell’unico cambiamento ha trasformato un controllo non dimostrabile in uno verificabile.

Per logging e monitoraggio non siamo andati a comprare una grande piattaforma. Abbiamo instradato i log di CloudTrail e applicativi verso una destinazione con alert sugli eventi che contano: uso dell’account root, modifiche alle policy IAM e accessi falliti alla console oltre una soglia. Poi abbiamo documentato chi esamina gli alert e con quale frequenza. Ecco come si leggeva nella loro matrice dei controlli:

Control ID : CC7.2
Statement  : Security events are logged and monitored; anomalies alert the on-call.
Evidence   : CloudTrail -> log sink; alert rules (root use, IAM change, failed logins);
             on-call rotation; sample alert + triage ticket from the observation window.
Frequency  : Continuous; reviewed weekly.
Owner      : Head of Engineering

Per la gestione del cambiamento non abbiamo cambiato nulla nel modo di lavorare degli ingegneri. Abbiamo scritto la policy in modo che corrispondesse alla realtà già in atto: pull request, revisione obbligatoria, controlli CI, branch main protetto. Poi abbiamo usato la storia GitHub esistente come prova. Allineare il documento alla pratica è molto più rapido, e molto più onesto, che innestare un nuovo processo la settimana in cui si presenta l’auditor.

Le policy sono venute per ultime. Abbiamo scritto le policy di sicurezza, controllo degli accessi, risposta agli incidenti, gestione del cambiamento e gestione dei fornitori per descrivere controlli che erano già in funzione. Le policy scritte prima della pratica descrivono una fantasia, e gli auditor sono bravissimi a individuare il divario tra una policy scintillante e ciò che i log dicono sia realmente accaduto.

Il risultato

Hanno superato l’audit. Lo studio CPA ha emesso un report SOC 2 Type II senza eccezioni nel perimetro dei common criteria, il che è un ottimo risultato per un primo audit. Presentato come esito rappresentativo per un’azienda di queste dimensioni: la valutazione di preparazione ha fatto emergere circa una dozzina di lacune significative, la maggior parte è stata chiusa entro la fase di remediation, e il contratto enterprise che aveva dato il via a tutto ha raggiunto il go-live.

La vittoria più duratura è stata più silenziosa. La raccolta delle prove è diventata un processo di sottofondo. Le revisioni degli accessi, i record di offboarding e il triage degli alert generano ora i propri artefatti, così il prossimo periodo di audit è per lo più manutenzione invece di un’altra corsa di 90 giorni. È questa la vera linea di confine tra rincorrere un report e far funzionare un programma di sicurezza.

Come aiuta CyberXplore

Gestiamo la preparazione a SOC 2 nello stesso modo in cui abbiamo gestito questa. Definire un perimetro ristretto, valutare con onestà, chiudere le lacune che gli auditor testano davvero e integrare le prove così i tuoi controlli si dimostrano da soli. Mappiamo i controlli sui Trust Services Criteria, eseguiamo la prova generale pre-audit rispetto all’elenco di richieste e lavoriamo al fianco del tuo studio CPA affinché nulla ti sorprenda sulla strada verso il report. Se hai un acquirente in attesa di un report o una scadenza che non hai scelto, richiedi un preventivo e ti diremo con onestà se la tua finestra è realistica e cosa serve per rispettarla.

FAQ

Si può davvero ottenere SOC 2 in 90 giorni?

Puoi raggiungere la preparazione a SOC 2 e completare un Type II con una finestra di osservazione breve in circa 90 giorni se il perimetro è ristretto e inizi subito a raccogliere le prove. Il vincolo è il periodo di osservazione, poiché un Type II richiede che i controlli funzionino nel tempo e non puoi comprimerlo a zero. Alcuni studi CPA non osservano sotto i tre mesi, quindi un ripiego comune è fare prima un Type I per soddisfare un acquirente urgente, seguito da un periodo Type II.

Qual è la differenza tra SOC 2 Type I e Type II?

Il Type I attesta che i tuoi controlli sono progettati in modo appropriato a una singola data. Il Type II attesta che quei controlli hanno effettivamente funzionato in modo efficace per un periodo, tipicamente da tre a dodici mesi. Gli acquirenti enterprise di solito richiedono il Type II perché prova il comportamento nel tempo, non solo l’intenzione di un giorno.

SOC 2 copre HIPAA per un SaaS sanitario?

No. SOC 2 e HIPAA sono separati. SOC 2 è un’attestazione rispetto ai Trust Services Criteria dell’AICPA, mentre HIPAA è una normativa statunitense che copre i dati sanitari protetti. Si sovrappongono su molti controlli di sicurezza, quindi puoi mappare il lavoro per soddisfarli entrambi, ma un report SOC 2 non ti rende conforme a HIPAA da solo.

Quali Trust Services Criteria dovremmo includere?

Ogni SOC 2 deve includere la Security, i common criteria. Aggiungi Availability, Confidentiality, Processing Integrity o Privacy in base a ciò che prometti ai clienti. La maggior parte delle aziende SaaS parte da Security più Availability e Confidentiality, e aggiunge Privacy solo quando assume impegni specifici sulla privacy.

Cosa fa fallire alle aziende il loro primo audit?

Quasi mai guasti di sicurezza esotici. Sono prove mancanti: nessuna revisione degli accessi, nessun record di offboarding datato, un logging che nessuno monitora e policy che descrivono un processo che il team in realtà non segue. Una valutazione di preparazione prima che arrivi l’auditor è il modo più economico per trovare quelle lacune mentre hai ancora tempo di correggerle.

Quanto di tutto questo può essere automatizzato?

Una grande parte. Le prove di identità e accesso, i controlli di configurazione cloud, la storia dei cambiamenti e il monitoraggio dei log possono generare tutti i propri artefatti in modo pianificato. Automatizzare la raccolta delle prove è ciò che trasforma SOC 2 da un’esercitazione antincendio ricorrente in un compito di manutenzione, ed è il singolo cambiamento che ripaga di più nei futuri periodi di audit.