Una valutazione del rischio per ISO 27001, SOC 2 e HIPAA
ISO 27001, SOC 2 e HIPAA partono tutti da una valutazione del rischio. Ne serve una sola, se è progettata per rispondere a tutti e tre gli auditor.
Questo articolo copre i 11 framework che ControlMapping aveva mappato al momento della stesura. Da allora sono stati aggiunti DORA, CPS 234, Cyber Essentials il 2026-10-27; le relative pagine e la matrice di copertura li includono.
La valutazione del rischio è il punto di partenza di tre dei framework più diffusi. ISO 27001 costruisce tutto su di essa (clausola 6.1.2). SOC 2 dedica a questo tema una sezione dei suoi criteri comuni (da CC3.1 a CC3.4). Lo HIPAA Security Rule rende l'analisi del rischio la sua prima implementation specification obbligatoria (§164.308(a)(1)(ii)(A)), ed è il primo documento richiesto dagli investigatori di HHS. Molte organizzazioni ne conducono tre. Una è sufficiente.
Cosa verifica ciascun framework
- ISO 27001 richiede un metodo definito e ripetibile, con criteri di accettazione; rischi identificati per riservatezza, integrità e disponibilità; responsabili; analisi di probabilità e conseguenze; e un collegamento con il trattamento del rischio e la Statement of Applicability.
- SOC 2 richiede obiettivi specificati con chiarezza sufficiente a identificare i rischi (CC3.1), rischi identificati e analizzati in tutta l'entità (CC3.2), considerazione del rischio di frode (CC3.3) e valutazione dei cambiamenti (CC3.4).
- HIPAA richiede una valutazione accurata e completa dei rischi e delle vulnerabilità per gli ePHI, ovunque vengano creati, ricevuti, conservati o trasmessi, mantenuta aggiornata e seguita dalla gestione del rischio (§164.308(a)(1)(ii)(B)).
Nei nostri dati questi requisiti sono collegati direttamente:
| Framework | Risk Assessment | Collegamento |
|---|---|---|
| NIST CSF 2.0 | ID.RA-03ID.RA-04ID.RA-05ID.RA-06 | Definizione dell'argomento |
| ISO 27001 | Clause 6.1.2Clause 6.1.3 | Crosswalk |
| CIS v8.1 | — | Nessuna mappatura nei nostri dati |
| SOC 2 | CC3.2CC3.4CC3.3 | Redazione |
| PCI DSS | 12.3.1 | Crosswalk |
| CMMC | RA.L2-3.11.1 | Crosswalk |
| 800-53 | RA-3RA-7 | Crosswalk |
| HIPAA | §164.308(a)(1)(ii)(A) | Crosswalk |
| GDPR | Art.35(1)Art.35(7) | Redazione |
| NIS2 | 2.1 | Crosswalk |
| Essential Eight | — | Nessuna mappatura nei nostri dati |
Dettaglio completo e motivazione di ogni collegamento: Risk Assessment nei framework →
Progettare un'unica valutazione per tutti e tre
- Definire un perimetro che copra tutto: il perimetro dell'ISMS, il sistema SOC 2 e ogni sede in cui si trovano gli ePHI. Registrare quali asset ricadono in quale framework.
- Usare un unico metodo: basato su asset o scenari, con una scala di probabilità e impatto, criteri di accettazione e responsabili. I requisiti di ISO per un metodo documentato e ripetibile sono i più stringenti, quindi vanno soddisfatti.
- Aggiungere gli stimoli specifici di ciascun framework: rischio di frode (SOC 2 CC3.3), minacce e vulnerabilità specifiche per gli ePHI (HIPAA), e rischi legali e contrattuali.
- Collegare ogni rischio al trattamento: controlli scelti, rischio residuo, accettazione da parte del responsabile. Questa unica tabella alimenta la Statement of Applicability di ISO, le attività di controllo di SOC 2 e la gestione del rischio di HIPAA.
Output che soddisfano tutti e tre gli auditor
- Il metodo, approvato.
- Un registro dei rischi con responsabili, punteggi e decisioni di trattamento.
- Un piano di trattamento del rischio con date.
- L'accettazione del rischio residuo da parte dei responsabili.
- Evidenza di revisione almeno annuale e dopo modifiche significative.
Un formato semplice per il registro dei rischi
Una riga per rischio funziona per tutti e tre i framework:
| Campo | Esempio |
|---|---|
| Rischio | Il ransomware cifra il database di produzione |
| Asset | Database di produzione, backup, archivio ePHI |
| Framework | ISO 27001, SOC 2, HIPAA |
| Probabilità e impatto | Possibile, grave |
| Controlli esistenti | MFA, EDR, backup notturni |
| Trattamento | Isolare i backup; testare i ripristini ogni trimestre |
| Responsabile | Responsabile dell'infrastruttura |
| Rischio residuo e accettazione | Medio, accettato dal CTO |
| Data di revisione | Prossimo trimestre |
La colonna dei framework è il trucco: consente a un unico registro di rispondere a tre auditor senza tre fogli di calcolo.
Punti chiave
- Un unico metodo e un unico registro possono soddisfare ISO 27001, SOC 2 e HIPAA.
- Aggiungere gli stimoli specifici di ciascun framework: rischio di frode e localizzazioni degli ePHI.
- Rivederla almeno annualmente e dopo modifiche significative.
Rilievi frequenti
- Rischi generici («hacker», «violazione dei dati») senza collegamento ad asset o controlli specifici.
- Nessun responsabile, oppure il team di sicurezza che è responsabile di ogni rischio.
- Localizzazioni degli ePHI non censite: esportazioni, backup, posta elettronica, sistemi di test.
- Non aggiornata: valutata una volta per il primo audit e mai più.
Per approfondire come questi framework si relazionano, vedi il confronto ISO 27001 vs HIPAA e l'argomento Risk Assessment. La gap analysis mostra ogni mappatura tra due framework qualsiasi.
Domande
L'analisi del rischio HIPAA è uguale a una valutazione del rischio ISO 27001?
Si sovrappongono molto. Lo HIPAA richiede una valutazione accurata e completa dei rischi per la riservatezza, l'integrità e la disponibilità degli ePHI; una valutazione del rischio ISO 27001 che includa gli ePHI nel perimetro e registri gli elementi specifici dello HIPAA può servire per entrambi.
Con quale frequenza va effettuata una valutazione del rischio?
ISO 27001 richiede valutazioni del rischio a intervalli pianificati e dopo modifiche significative. Gli auditor SOC 2 si aspettano in genere una valutazione del rischio almeno annuale. Lo HIPAA richiede che l'analisi del rischio sia mantenuta aggiornata.
La valutazione del rischio dovrebbe essere qualitativa o quantitativa?
Entrambe funzionano per tutti e tre i framework, purché il metodo sia definito, applicato in modo coerente e produca risultati comparabili. La maggior parte delle organizzazioni parte da un approccio qualitativo e aggiunge valori numerici dove le decisioni ne hanno bisogno.
Dati aggiornati al 2026-10-27: i numeri di questo articolo sono calcolati dal crosswalk attuale e si aggiornano quando questo cambia. Crosswalk una tabella di corrispondenza pubblicata (NIST, ENISA, CIS, PCI SSC) stabilisce il collegamento · Redazione Giudizio di ControlMapping dove non esiste una tabella di corrispondenza; la motivazione è indicata · condivide solo un esito di CSF 2.0: da verificare, non è una mappatura · Nessuna mappatura nei nostri dati nessuna mappatura nei nostri dati; spesso si tratta di lavoro nuovo, ma verifica le note sulla copertura. Non è una consulenza di conformità.
Articoli correlati
Analisi · 2026-10-27APRA CPS 234 e ISO 27001: cosa copre l'ISMS e cosa aggiunge APRAUn ISMS conforme a ISO 27001 copre quasi ogni paragrafo del CPS 234 di APRA, ma APRA aggiunge responsabilità del Consiglio di amministrazione, garanzie di terze parti e scadenze di notifica stringenti.
Analisi · 2026-10-13Requisiti MFA confrontati tra 11 framework di sicurezzaQuali framework richiedono MFA, per chi e con quale rigore: PCI DSS, CMMC, NIS2, Essential Eight, ISO 27001, SOC 2 e HIPAA a confronto diretto.
Analisi · 2026-09-29HIPAA Security Rule attraverso la lente del NIST CSF 2.0Un programma NIST CSF 2.0 copre quasi ogni requisito dell'HIPAA Security Rule. Cosa si riporta, i due che non corrispondono e ciò che il CSF aggiunge rispetto all'HIPAA.