NIST CSF 2.0 vs SOC 2: un framework che si adotta vs un report su cui si viene verificati

Per Paul Gillet · Aggiornato il 2026-10-17

NIST CSF 2.0 è un framework volontario basato sui risultati: decidi tu il profilo obiettivo e misuri la tua posizione rispetto ad esso. SOC 2 è un'attestazione indipendente da parte di un CPA rispetto ai Trust Services Criteria dell'AICPA, ed è ciò che molti clienti nordamericani richiedono a un fornitore SaaS in fase di procurement.

La maggior parte dei requisiti di sicurezza SOC 2 (Common Criteria) ha controparti nel CSF: accesso logico, monitoraggio, gestione degli incidenti, gestione dei cambiamenti, valutazione del rischio e gestione dei fornitori. Un programma allineato al CSF ti fornisce la maggior parte dei controlli che un auditor verificherà.

Passando dal CSF a SOC 2, quasi ogni Common Criterion ha una controparte nel CSF, inclusi i criteri sull'ambiente di controllo (etica, supervisione del consiglio di amministrazione, responsabilità), che il CSF copre attraverso la sua funzione Govern. Gli elementi senza corrispondenza sono le categorie facoltative di SOC 2 Processing Integrity e Privacy, che hanno scarse controparti in un framework di sicurezza. Non esiste un crosswalk SOC 2 pubblico e leggibile da macchina, quindi il lato SOC 2 di questo confronto è la mappatura editoriale di ControlMapping.

Passando da SOC 2 al CSF, le lacune riguardano principalmente i risultati più ampi del CSF in materia di governance e resilienza: strategia di rischio, ciclo di vita della gestione del rischio della catena di fornitura, threat intelligence e processi di miglioramento, che SOC 2 non richiede esplicitamente.

In sintesi

Come si integrano

Il CSF descrive cosa ottiene un buon programma; SOC 2 dimostra ai clienti che specifici controlli funzionano. Molte aziende usano il CSF per strutturare il programma e riferire al consiglio di amministrazione, e SOC 2 per fornire ai clienti le evidenze. Poiché SOC 2 non ha un crosswalk aperto e licenziato, ogni collegamento SOC 2 qui riportato è un giudizio editoriale di ControlMapping, con una motivazione.

Chi richiede cosa

• SOC 2 è richiesto dai clienti, principalmente grandi aziende statunitensi che valutano fornitori di software e servizi. Risponde alla domanda "possiamo fidarci di voi con i nostri dati?" con il parere di un auditor indipendente.
• NIST CSF 2.0 è richiesto da consigli di amministrazione, autorità di vigilanza, assicuratori e partner che vogliono sapere come un'organizzazione gestisce nel complesso il rischio cyber. Nessuno può consegnare un "certificato CSF"; si mostrano invece i propri profili e le evidenze che li sostengono.
• Un numero crescente di aziende usa il CSF internamente e produce un report SOC 2 per i clienti. I due si completano a vicenda invece di competere.

Usare il CSF per prepararsi a SOC 2

Se gestisci già un programma basato sul CSF, possiedi gran parte di ciò che verificano i criteri di sicurezza di SOC 2. Mappa i tuoi risultati CSF sui Trust Services Criteria, poi verifica tre aspetti che il CSF non impone: che ogni controllo produca evidenze in modo continuativo (SOC 2 Type II campiona nell'arco di mesi), che i criteri sull'ambiente di controllo siano coperti (supervisione del consiglio di amministrazione, integrità e valori etici, competenza, responsabilità) e che la descrizione del sistema corrisponda al perimetro che interessa ai clienti. Il report di gap CSF → SOC 2 elenca ogni criterio con la sua corrispondenza nel CSF e la motivazione di ciascun collegamento.

Costi e impegno

Il CSF in sé è gratuito; l'impegno consiste nel valutare e migliorare il tuo profilo. SOC 2 aggiunge le parcelle di uno studio CPA e, per un Type II, la disciplina di raccogliere evidenze nell'intero periodo di osservazione. Per un'azienda con un programma CSF maturo, lo sforzo aggiuntivo per SOC 2 riguarda soprattutto la raccolta delle evidenze, la descrizione del sistema e le eventuali categorie facoltative che includi. Per un'azienda che parte da zero, costruire prima sul CSF offre una base più ampia; costruire prima su SOC 2 produce prima un output rivolto ai clienti.

Tempistiche

Da un programma CSF operativo a un primo report SOC 2 Type II occorrono in genere da sei a nove mesi: da uno a tre mesi per mappare i controlli, chiudere le lacune e ingaggiare un auditor, poi un periodo di osservazione da tre a sei mesi e alcune settimane per il report. Nel senso inverso, un'azienda con un report SOC 2 può produrre un CSF Current Profile in poche settimane, perché la maggior parte dei risultati Protect, Detect e Respond è già documentata; la funzione Govern di solito richiede più lavoro.

Caso pratico: una start-up fintech

Una fintech di 30 persone possiede un report SOC 2 Type II per la propria API di pagamento. Il suo consiglio di amministrazione e il suo assicuratore cyber ora chiedono come gestisca in modo più ampio il rischio cyber. L'azienda costruisce un CSF 2.0 Current Profile a partire dai propri controlli SOC 2 e riscontra una buona copertura di Protect, Detect e Respond, con lacune in Govern: nessuna dichiarazione formale di propensione al rischio, nessun programma di rischio della catena di fornitura oltre ai questionari sui fornitori e nessuna reportistica periodica di supervisione. Definisce un Target Profile, aggiunge un report trimestrale al consiglio di amministrazione in termini CSF e mantiene invariato il ciclo di audit SOC 2. Un unico insieme di controlli risponde ora a entrambi i pubblici.

Errori comuni

• Ritenere che l'allineamento al CSF significhi prontezza per SOC 2. Il CSF non richiede evidenze continuative su un periodo, che invece un report Type II verifica.
• Trascurare l'ambiente di controllo. I criteri CC1 a CC5 di SOC 2 (supervisione del consiglio di amministrazione, integrità, competenza, responsabilità) richiedono evidenze che i programmi tecnici basati sul CSF spesso non hanno.
• Estendere eccessivamente l'ambito del report SOC 2 fino a coincidere con l'intero programma CSF, invece di limitarlo al sistema su cui fanno affidamento i clienti.
• Gestire due programmi. Un unico insieme di controlli, mappato in entrambe le direzioni, evita evidenze duplicate.
• Lasciare Govern per ultimo. I risultati Govern del CSF 2.0 sono spesso la parte più debole di un programma impostato prima su SOC 2 ed è quella su cui i consigli di amministrazione chiedono più spesso.

Punti chiave

• Il CSF indica come appare il buono; SOC 2 dimostra a un cliente che lo gestisci davvero.
• Raccogli le evidenze in modo continuativo: un report Type II richiede prove nell'intero periodo di audit.
• Tratta Processing Integrity e Privacy come progetti separati, se rientrano nell'ambito.

Scarica questo confronto (CSV) Apri in analisi dei gap →