Pronto per l'audit: ISO 27001, SOC 2, Cyber Essentials
Una guida pratica su cosa verificano realmente gli auditor per ISO 27001, SOC 2 e Cyber Essentials, e come prepararsi senza il panico.
La maggior parte dei team tratta un audit di compliance come un'esercitazione antincendio che capita una volta all'anno. Non deve andare così, e i framework stessi non sono così misteriosi come i vendor li descrivono. Ecco cosa conta davvero quando ti stai preparando per ISO 27001, SOC 2 o Cyber Essentials.
Sapere quale framework ti viene effettivamente richiesto
Questi tre vengono spesso raggruppati ma risolvono problemi diversi. ISO 27001 è uno standard di sistema di gestione — certifica che hai un Information Security Management System (ISMS) funzionante con valutazioni dei rischi, policy e miglioramento continuo incorporati. SOC 2 è un rapporto di attestazione, solitamente Type II, che copre un periodo di tempo (comunemente 6-12 mesi) rispetto ai Trust Services Criteria: security, availability, processing integrity, confidentiality, privacy. Cyber Essentials è uno schema sostenuto dal governo del Regno Unito focalizzato su cinque controlli tecnici base: firewalls, secure configuration, access control, malware protection e patch management.
Se un cliente dice "abbiamo bisogno che tu sia conforme a SOC 2", chiedisci quale tipo e quali criteri gli importano davvero. La maggior parte dei deal B2B SaaS richiede solo Security e Availability, non tutti i cinque criteri.
Costruisci la traccia di evidence prima che l'auditor la chieda
Gli auditor non si fidano solo della tua parola — vogliono artefatti. Per ISO 27001 significa una Statement of Applicability che mappa tutti i 93 controlli in Annex A (revisione 2022) a quello che hai implementato o escluso, con giustificazione. Per SOC 2, significa screenshot, log e ticket che provano che i controlli hanno funzionato coerentemente durante la finestra di audit, non solo il giorno in cui qualcuno si è ricordato di configurarlo.
Configura la raccolta di evidence come un processo continuo, non una corsa:
# Example: pull IAM access review evidence monthly via AWS CLI
aws iam generate-credential-report
aws iam get-credential-report --output text --query 'Content' | base64 -d > access-report-$(date +%Y%m).csv
Archivia questi con timestamp in un repository dedicato di evidence (cartella Google Drive, Vanta, Drata — quello che usi) organizzato per ID del controllo, non per mese. Gli auditor campionano lungo il periodo; devi provare che il controllo era attivo a marzo e a ottobre, non solo quando ti sei ricordato.
I controlli che fanno inciampare la gente ogni volta
Le access review sono il numero uno tra i finding. Se non riesci a mostrare una revisione trimestrale di chi ha accesso ai sistemi di produzione, con evidence che qualcuno ha effettivamente rimosso account stali, aspettati un finding indipendentemente dal framework. Esegui questa come un compito ricorrente del calendario, non come un favore ad hoc.
La vendor risk management è il secondo grande gap. ISO 27001 clause A.5.19-A.5.23 e i criteri di vendor management di SOC 2 si aspettano che tu valuti i subprocessor — provider cloud, processori di pagamento, qualunque cosa tocchi i dati dei clienti. Un questionario sulla vendor risk di una pagina per ciascun vendor critico, revisionato annualmente, copre gran parte di questo.
I piani di incident response che esistono solo come documento che nessuno ha testato sono un finding comune. Esegui un esercizio tabletop almeno una volta prima che la finestra di audit si chiuda e conserva le note della riunione. Gli auditor chiedono specificatamente evidence che il piano sia stato esercitato, non solo scritto.
Per Cyber Essentials, le domande di scope tecnico contano più di quanto la gente si aspetti. Devi descrivere accuratamente il tuo boundary — ogni dispositivo, servizio cloud e policy BYOD in scope — perché misrepresentare lo scope è motivo di fallimento anche se i controlli tecnici sono a posto. Il patch management è controllato letteralmente: patch critiche e high-severity devono essere applicate entro 14 giorni dal rilascio per servizi internet-facing.
Gestire una timeline interna realistica
Per SOC 2 Type II, metti in conto 3-6 mesi di raccolta di evidence prima che il periodo di audit inizi, poiché Type II richiede di provare che i controlli hanno funzionato lungo la finestra di osservazione stessa, non solo in un punto nel tempo. La certificazione ISO 27001 tipicamente dura 6-12 mesi dalla gap assessment al certificato, includendo una revisione della documentazione Stage 1 e una valutazione Stage 2 on-site (o remota) dal body di certificazione. Cyber Essentials è più veloce — i questionari self-assessment possono essere completati in settimane se i tuoi fondamenti sono già in forma, con Cyber Essentials Plus che aggiunge una verifica tecnica esterna.
Non lasciar che l'audit sia l'unica volta che verifichi il tuo lavoro
Esegui una valutazione interna di readiness rispetto alla lista di controllo effettiva 60-90 giorni prima dell'audit vero. Tratta i finding di quella valutazione interna nello stesso modo in cui tratteresti i finding dell'auditor — rimedia, documenta la correzione e mantieni la traccia di documentazione. Quella valutazione interna è solitamente dove i team scoprono i gap nelle access review e i vendor contract stali prima che qualcuno esterno lo faccia per loro, con un rapporto allegato al rinnovo di un contratto cliente.
Se vuoi approfondire i controlli tecnici dietro questi framework — progettazione dell'access control, logging, incident response — controlla le tracce Blue Team e Certifications su Korra Studio.
Scritto con assistenza AI, revisionato e pubblicato da Michal Pilch (CISSP), Korra Studio.
Questa è una nota dalla knowledge base di Korra Studio — la piattaforma abbina ogni argomento a mentoring 1-to-1.
Inizia gratisarrow_forward