"Come superiamo SOC 2" è la domanda che la maggior parte delle startup al primo approccio si pone, e la risposta onesta inizia correggendo la premessa. SOC 2 non è un esame con un punteggio di superamento e non rilascia un certificato. Una società di revisione CPA indipendente verifica i controlli rispetto ai Trust Services Criteria dell'AICPA e emette un parere, un rapporto scritto che attesta se i controlli sono stati progettati in modo adeguato e, per il tipo di report che quasi tutti i clienti richiedono effettivamente, se hanno funzionato correttamente durante un periodo di osservazione. "Superare" significa che il parere del revisore risulta non qualificato: senza eccezioni gravi tali da renderlo condizionato. Tutto ciò che segue descrive il processo che porta una startup a ottenere quel parere non qualificato, e si basa principalmente su ambito e disciplina, non su una lista di controlli di modifica del codice.
Tipo I vs Tipo II, e perché il Tipo II è quello che conta
Un report di Tipo I verifica se i controlli sono progettati in modo adeguato a una data specifica. Risponde alla domanda: "Se questi controlli funzionassero come descritto, soddisferebbero i criteri?", ma non dice nulla sul fatto che siano stati effettivamente applicati nella pratica. Un report di Tipo II verifica gli stessi controlli per l'efficacia operativa durante un periodo di osservazione, solitamente tre mesi per un primo report e sei-dodici mesi per un rinnovo. Risponde alla domanda che interessa realmente a una revisione di sicurezza del cliente: l'accesso, la gestione delle modifiche e il monitoraggio hanno resistito nel tempo reale, non solo sulla carta.
La maggior parte delle startup alla fine ha bisogno del Tipo II, perché è ciò che la procacciamento aziendale e i questionari di sicurezza dei fornitori richiedono sempre più esplicitamente. Il Tipo I ha comunque un ruolo: è più veloce da produrre (non c'è un periodo di attesa) e alcune startup lo utilizzano come primo documento per dimostrare progressi a un cliente aziendale precoce, mentre il periodo di osservazione del Tipo II procede in parallelo. Nessun report è una certificazione e nessuno ha un punteggio numerico; il prodotto finale è un rapporto che contiene la descrizione del sistema e dei controlli (da parte della direzione), la dichiarazione della direzione, i test e i risultati del revisore per un Tipo II e il parere del revisore.
Definire l'ambito prima di costruire un singolo controllo: solo Security è obbligatorio
SOC 2 è organizzato intorno a cinque Trust Services Categories: Security, Availability, Confidentiality, Processing Integrity e Privacy. Security, i Common Criteria (i criteri CC, da CC1 a CC9), è l'unica categoria obbligatoria; ogni report SOC 2 la include. Le altre quattro sono opzionali, e una startup che include tutte e cinque per default sta probabilmente costruendo e documentando controlli che nessuno ha richiesto.
Definisci l'ambito in base a ciò che le revisioni di sicurezza dei tuoi clienti richiedono effettivamente, non in base a un modello. Un'azienda B2B SaaS di solito include Security più Availability (impegno all'uptime) e Confidentiality (gestione dei dati aziendali dei clienti sotto un obbligo simile a un NDA). Processing Integrity conta soprattutto se la funzione principale del sistema è l'elaborazione di transazioni in cui completezza e accuratezza di tale elaborazione rappresentano la promessa del prodotto, ad esempio pagamenti o fatturazione, non solo "abbiamo un database". Privacy è la categoria AICPA per gli impegni di gestione delle informazioni personali nella propria informativa sulla privacy, una cosa separata dal GDPR o da altre leggi sulla privacy; la maggior parte delle startup soddisfa le aspettative dei clienti sulla gestione dei dati personali senza aggiungere questa categoria. Chiedi ai tuoi primi potenziali clienti aziendali cosa richiede il loro team di sicurezza dei fornitori prima di impegnarti su un ambito; è molto più economico aggiungere una categoria in seguito che documentarne una che nessuno ha richiesto.
La tempistica realistica
Prima viene la preparazione: un'analisi delle lacune rispetto ai criteri che hai definito, la stesura delle policy richieste dai criteri (controllo degli accessi, gestione delle modifiche, risposta agli incidenti, ecc.) e la chiusura delle lacune nei sistemi effettivi (imposizione dell'MFA, attivazione della registrazione di audit, formalizzazione di un passaggio di approvazione delle modifiche). Per una piccola startup che utilizza una piattaforma di automazione della conformità per tracciare prove e controlli, la preparazione richiede solitamente quattro-otto settimane; di più se un controllo deve essere costruito piuttosto che solo documentato, ad esempio l'implementazione di una registrazione centralizzata che non esisteva prima.
Per un report di Tipo II, il periodo di osservazione viene dopo, e la sua durata non può essere accorciata dal fornitore: i controlli devono funzionare per un periodo concordato prima che il revisore possa testarli, quindi un periodo di tre mesi sono tre mesi calendariali, non un insieme di prove raccolte a posteriori. Non esiste un minimo statale universale; il periodo viene concordato con la società CPA e definito in base a ciò che gli utenti previsti del report si aspettano. I primi report coprono solitamente tre-sei mesi, i rinnovi spesso sei-dodici. Durante il periodo, i controlli in ambito devono funzionare in modo coerente: una lacuna può diventare un'eccezione campionata a seconda dei test del revisore, della sua natura, frequenza e gravità, non automaticamente.
Il lavoro sul campo del revisore segue il periodo: il revisore esamina le prove, campiona transazioni e modifiche, intervista i responsabili dei controlli e redige le constatazioni, solitamente in due-quattro settimane, poi emette il report finale. In totale, il primo report di Tipo II di una startup richiede realisticamente cinque-nove mesi dal via al report in mano come benchmark tipico, non un requisito AICPA. Tratta con cautela una promessa di "SOC 2 in un mese": di solito significa lavoro di preparazione, un report di Tipo I o un periodo di segnalazione insolitamente breve accettato da un revisore specifico, non un Tipo II convenzionale di diversi mesi.
Cosa può compromettere il periodo di osservazione
Il periodo di osservazione è dove la maggior parte delle startup al primo approccio riceve una spiacevole sorpresa, perché è abbastanza lungo perché il lavoro di ingegneria quotidiano possa silenziosamente annullare un controllo appena impostato durante la fase di preparazione. Una pull request di una riga che allarga una policy IAM a un wildcard per comodità, una pulizia che rimuove la riga di audit log per un'azione privilegiata, una hotfix che salta il passaggio di approvazione delle modifiche sotto pressione: nessuna di queste sembra un'attività di conformità mentre avviene, e ciascuna è esattamente il tipo di cosa che può diventare un'eccezione campionata se viene applicata durante il periodo e i test del revisore la rilevano. I dettagli a livello di controllo su quali criteri compaiono effettivamente in una diff, principalmente la famiglia CC6 di accesso logico più CC7.2 monitoraggio e CC8.1 gestione delle modifiche, sono nell'approfondimento sul framework SOC 2 e nella guida di accompagnamento su cosa verifica SOC 2 nel repository.
Questo è il livello in cui un controllo di conformità a livello di pull request aggiunge valore durante il periodo: legge ogni modifica rispetto ai criteri che hai definito e identifica quello che tocca, ad esempio CC6.1 sulla policy IAM allargata, come commento di revisione nel momento in cui la modifica viene proposta. Se rilevata lì, il team può valutarla e correggerla prima che venga mai distribuita, solitamente con un costo molto inferiore rispetto a un intervento successivo. Se non viene rilevata, è una modifica che il revisore potrebbe campionare come eccezione che dovresti spiegare, il che potrebbe complicare il parere per cui hai lavorato per mesi.
Cosa non sostituisce questo strumento
Un controllo delle pull request è uno strato di un processo molto più ampio, ed è importante essere precisi sul resto, perché nessuna di queste parti è compito di heygrc. Scegliere il revisore, definire le categorie di fiducia, scrivere le policy, eseguire l'analisi delle lacune di preparazione, raccogliere prove in tutto lo stack (provider di identità, configurazione cloud, onboarding e offboarding HR, gestione dei fornitori) per l'intero periodo di osservazione e emettere il parere: tutto questo fa parte del programma di conformità, solitamente gestito tramite una piattaforma appositamente creata (la guida sugli strumenti di automazione della conformità mappa questo strato) più il revisore. heygrc è progettato per leggere le pull request rispetto ai criteri selezionati e identificare il controllo che una modifica tocca. Non esegue l'audit, non sostituisce il revisore e non ti porta da solo a un parere non qualificato; è progettato per aiutare il team a rilevare precocemente le modifiche delle pull request rilevanti per i controlli, durante il programma, prima che possano trasformarsi nel tipo di eccezione che rende più difficile ottenere il parere.