# Cyber Academy. Full content dump (Italiano) > GRC & cybersecurity certification training. Led by Christophe Mazzola (a practicing CISO) alongside a small team of practitioners. > Canonical URL: https://cyberacademy.net/it/ > Author: Christophe Mazzola (https://cyberacademy.net/it/christophe) > Index: https://cyberacademy.net/it/llms.txt > Other languages: https://cyberacademy.net/llms-full.txt | https://cyberacademy.net/fr/llms-full.txt | https://cyberacademy.net/es/llms-full.txt | https://cyberacademy.net/it/llms-full.txt | https://cyberacademy.net/de/llms-full.txt | https://cyberacademy.net/pt/llms-full.txt === # PILLAR PAGES # NIS 2: la guida che sostituisce il tuo monitoraggio legale. **URL:** https://cyberacademy.net/it/resources/pillars/nis-2 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition NIS 2 (Direttiva (UE) 2022/2555) è la direttiva UE che chiama in causa i consigli di amministrazione sulla cybersecurity. Rientrano nell'ambito di applicazione le entità di medie o grandi dimensioni operanti in 18 settori elencati. In caso di incidente significativo: preallarme entro 24 ore, notifica entro 72 ore, relazione completa entro un mese. Sanzioni fino a 10 milioni di euro o al 2% del fatturato mondiale per le entità essenziali. Recepita in modo disomogeneo dagli Stati membri a partire da ottobre 2024. ## TL;DR - Nell'ambito di applicazione: 18 settori, entità di medie dimensioni (50+ dipendenti / 10M+ di fatturato) e di dimensioni maggiori. Due categorie, essenziali e importanti, con diversa intensità di vigilanza. - Dieci misure di gestione dei rischi di cybersecurity ai sensi dell'Articolo 21. La direttiva indica cosa fare; ISO 27001 è il come più diffuso. - Segnalazione degli incidenti: preallarme entro 24 ore, notifica entro 72 ore, relazione completa entro un mese. Definisci il percorso prima di averne bisogno. - La responsabilità personale e l'accountability del management sono ora esplicite. Il consiglio di amministrazione è chiamato in causa, non solo il CISO. - Lo stato di recepimento varia da Paese a Paese: verifica la tua autorità nazionale prima di dare per scontato che il testo UE si applichi così com'è. ## Full content ## Stabilire se rientri nell'ambito di applicazione e a quale categoria L'ambito di applicazione è la domanda che determina tutto il resto, quindi risolvila per prima e metti per iscritto il ragionamento. NIS 2 si applica alle entità operanti in uno dei 18 settori elencati che soddisfano anche una soglia dimensionale. La regola predefinita è la soglia della media impresa: almeno 50 dipendenti, oppure fatturato annuo e totale di bilancio superiori a 10 milioni di euro. Al di sotto di tale soglia sei di norma escluso, ma non sempre: la direttiva include determinati fornitori indipendentemente dalla dimensione quando il servizio è sufficientemente critico (ad esempio fornitori di DNS, registri dei domini di primo livello e alcuni fornitori di comunicazioni elettroniche pubbliche e di servizi fiduciari). Le due categorie, essenziali e importanti, non sono due elenchi tra cui scegliere. Derivano dal tuo settore e dalla tua dimensione. I settori ad alta criticità (energia, trasporti, settore bancario, infrastrutture dei mercati finanziari, sanità, acqua potabile, acque reflue, infrastrutture digitali, pubblica amministrazione, spazio) generano entità essenziali alle dimensioni maggiori; gli altri settori elencati, e le entità di dimensioni minori in quelli ad alta criticità, sono generalmente classificati come importanti. La conseguenza pratica è l'intensità della vigilanza, non un insieme di obblighi più leggero: le misure di sicurezza e le scadenze di segnalazione sono identiche per entrambe le categorie. > **Esegui il test dell'ambito di applicazione su carta, poi conservalo** L'errore comune è trattare la domanda "rientriamo nell'ambito di applicazione?" come una conversazione di corridoio. Esegui il test in modo esplicito: settore, dimensione e qualsiasi trigger indipendente dalla dimensione, con i dati che hanno alimentato ciascuna risposta. Un'autorità nazionale in disaccordo chiederà come hai concluso di essere fuori, e "non pensavamo si applicasse" non è una posizione difendibile quando la responsabilità ricade sul management. ## Essenziali vs importanti: dove le due categorie divergono davvero Entrambe le categorie sono soggette alle stesse misure dell'Articolo 21 e allo stesso orologio di segnalazione degli incidenti. Ciò che cambia è il modo in cui il regolatore ti sorveglia e cosa può fare quando qualcosa non va. Le entità essenziali sono soggette a una vigilanza proattiva, ex ante: un'autorità può effettuare ispezioni e richiedere prove senza attendere un incidente. Le entità importanti sono soggette a una vigilanza reattiva, ex post, il che significa che il controllo segue tipicamente un incidente o un reclamo credibile. Anche i massimali sanzionatori differiscono, e tale divario è la ragione più citata per confermare la propria categoria con anticipo. **Vigilanza e sanzioni NIS 2 per categoria di entità** | Dimensione | Entità essenziali | Entità importanti | | --- | --- | --- | | Modello di vigilanza | Proattivo (ex ante): ispezioni e richieste di prove in qualsiasi momento | Reattivo (ex post): attivato da un incidente o da un reclamo | | Sanzione amministrativa massima | Almeno 10 milioni di euro o il 2% del fatturato annuo mondiale totale, se superiore | Almeno 7 milioni di euro o l'1,4% del fatturato annuo mondiale totale, se superiore | | Obblighi di sicurezza (Articolo 21) | Si applicano tutte e dieci le misure | Si applicano tutte e dieci le misure (identiche) | | Tempistica di segnalazione | 24h / 72h / 1 mese (identica) | 24h / 72h / 1 mese (identica) | | Accountability del management | Esplicita; gli organi possono essere ritenuti responsabili, i singoli individui possono subire divieti temporanei di gestione | Esplicita; si applica la responsabilità individuale, i divieti di gestione sono generalmente riservati alle entità essenziali | Leggi la tabella come la leggerà un auditor: le misure e le scadenze non sono negoziabili per nessuno, quindi la categoria ti dice soprattutto quanto margine di errore hai prima che qualcuno venga a controllare. Le entità essenziali dovrebbero dare per scontato che un'ispezione possa avvenire in un tranquillo martedì. Le entità importanti dovrebbero dare per scontato che la prima vera prova sarà un incidente reale, ovvero il momento peggiore per scoprire che le proprie prove sono insufficienti. ## Le dieci misure dell'Articolo 21, e perché ISO 27001 è la risposta abituale L'Articolo 21(2) elenca dieci categorie di misure di gestione dei rischi di cybersecurity che ogni entità rientrante nell'ambito di applicazione deve implementare, in proporzione alla propria esposizione al rischio. La direttiva descrive risultati, non controlli, e ciò è deliberato: ti dice cosa deve essere coperto e lascia a te il come. 1. Politiche di analisi dei rischi e di sicurezza dei sistemi informativi. 1. Gestione degli incidenti (rilevamento, risposta e gli obblighi di segnalazione descritti di seguito). 1. Continuità operativa, comprese la gestione dei backup e il disaster recovery, e gestione delle crisi. 1. Sicurezza della catena di approvvigionamento, che copre la sicurezza dei rapporti con i fornitori diretti e i prestatori di servizi. 1. Sicurezza nell'acquisizione, sviluppo e manutenzione dei sistemi informativi e di rete, compresa la gestione e la divulgazione delle vulnerabilità. 1. Politiche e procedure per valutare l'efficacia delle misure. 1. Pratiche di igiene informatica di base e formazione sulla sicurezza. 1. Politiche e procedure in materia di crittografia e, ove appropriato, cifratura. 1. Sicurezza delle risorse umane, politiche di controllo degli accessi e gestione degli asset. 1. Autenticazione a più fattori, comunicazioni protette e comunicazioni di emergenza protette ove appropriato. Leggi quell'elenco accanto a un set di controlli dell'Annex A e la sovrapposizione è evidente. È per questo che, nella pratica, il percorso più comune verso una conformità dimostrabile è un sistema di gestione della sicurezza delle informazioni ISO 27001. NIS 2 nomina i risultati; ISO 27001 ti fornisce il sistema di gestione, la disciplina di trattamento del rischio e le prove documentate che si mappano su nove delle dieci categorie senza grandi traduzioni. Non hai strettamente bisogno di un certificato per soddisfare NIS 2, ma la struttura dell'ISMS è il modo più pulito per produrre i record che un'autorità si aspetta. Il modo più rapido per un team di interiorizzare sia l'obbligo sia la realizzazione è abbinare la prospettiva normativa a quella implementativa: il corso NIS 2 Directive Lead Implementer per il programma in sé, e il corso ISO 27001 Lead Implementer per costruire l'ISMS che sostiene gran parte del peso dell'Articolo 21. > **Mappa una volta, mantieni per sempre** Costruisci un'unica matrice controllo-requisito che allinei la tua Statement of Applicability ISO 27001 alle dieci categorie dell'Articolo 21. Quando un'autorità nazionale chiede come copri la sicurezza della catena di approvvigionamento o la crittografia, indichi una singola riga invece di ricostruire l'argomentazione sotto pressione. Mantienila come un documento vivo, non come un esercizio di mappatura una tantum. ## L'orologio della segnalazione: 24 ore, 72 ore, un mese L'obbligo di segnalazione si attiva in caso di incidente significativo, ovvero uno che ha causato o è in grado di causare gravi perturbazioni operative o perdite finanziarie, oppure che ha colpito altri attraverso un danno materiale o immateriale considerevole. L'orologio scorre poi in tre fasi verso il tuo CSIRT nazionale o l'autorità competente. - 24 ore: un preallarme. Indica se sospetti che l'incidente sia illecito o malevolo e se potrebbe avere un impatto transfrontaliero. Si tratta di una segnalazione, non di un rapporto forense. - 72 ore: una notifica dell'incidente. Aggiorna il preallarme con una valutazione iniziale, comprensiva di gravità, impatto e di eventuali indicatori di compromissione di cui disponi. - Un mese: una relazione finale. Un resoconto completo dell'incidente, della sua probabile causa profonda, della mitigazione applicata e di qualsiasi impatto transfrontaliero. Se l'incidente è ancora in corso al termine del mese, fornisci una relazione sullo stato di avanzamento e una relazione finale alla sua chiusura. Le scadenze sembrano generose finché non le confronti con un incidente reale. Il preallarme delle 24 ore arriva mentre stai ancora confermando cosa è successo, quindi il percorso deve essere definito in anticipo: chi decide che un incidente è "significativo", chi redige il preallarme, chi ha l'autorità per inviarlo e quale portale o contatto utilizzare in ciascuno Stato membro in cui operi. Esercitati. Un'esercitazione tabletop che si conclude con la bozza di un preallarme scritta contro il tempo vale più di qualsiasi documento di policy sulla segnalazione. ## La responsabilità del management e gli errori che emergono nella sala di audit NIS 2 sposta l'accountability verso l'alto. Gli organi di gestione devono approvare le misure di gestione dei rischi di cybersecurity, supervisionarne l'implementazione e seguire una formazione che permetta loro di individuare i rischi autonomamente. La non conformità può ricadere su singoli individui nominati, e per le entità essenziali le autorità possono imporre divieti temporanei alle persone fisiche che esercitano funzioni dirigenziali. Il consiglio di amministrazione è chiamato in causa, e "la sicurezza la gestisce il CISO" non è più una risposta completa per un regolatore. Gli errori ricorrenti che osserviamo sono raramente esotici. Sono prevedibili ed evitabili: - Trattare il recepimento come uniforme. La direttiva è recepita nel diritto nazionale e le tempistiche, le soglie, gli obblighi di registrazione e i portali di segnalazione variano da Paese a Paese. Verifica l'autorità nazionale per ogni Stato membro in cui operi prima di dare per scontato che il testo UE si applichi così com'è. - Ignorare l'obbligo di registrazione e auto-identificazione. Molti Stati membri richiedono alle entità rientranti nell'ambito di applicazione di registrarsi presso l'autorità competente. Rientrare nell'ambito di applicazione ed essere non registrati è di per sé un rilievo, distinto da qualsiasi lacuna di sicurezza. - Investire troppo poco nella sicurezza della catena di approvvigionamento. È una delle dieci misure, ed è il punto in cui le entità più grandi sono maggiormente esposte. Un processo di gestione del rischio fornitori insufficiente è una debolezza visibile. - Confondere le categorie con gli obblighi. Le entità importanti talvolta presumono che una vigilanza più leggera significhi obblighi più leggeri. Non è così: si applicano le stesse misure e lo stesso orologio di segnalazione. - Nessun percorso di segnalazione provato. Il preallarme delle 24 ore è l'obbligo più spesso mancato, perché nessuno si è assunto la responsabilità della decisione e della bozza finché l'incidente non lo ha imposto. Se il tuo team ha bisogno di orientarsi su ambito di applicazione, categorie e obblighi prima di impegnarsi in una realizzazione, il corso NIS 2 Directive Foundation è il punto di partenza giusto; passa ai percorsi Lead Implementer e ISO 27001 una volta che stai definendo l'ambito del programma stesso. NIS 2 interagisce con altri regimi UE (DORA disciplina la resilienza operativa del settore finanziario e generalmente prevale in tale ambito in quanto regola più specifica; l'AI Act aggiunge i propri obblighi per i sistemi di IA), quindi conferma quale regime è prevalente per un dato obbligo, invece di segnalare lo stesso incidente due volte o, peggio, di non segnalarlo affatto. Nel dubbio, la postura sicura è quella che la direttiva stessa premia: decisioni documentate, una mappatura dei controlli mantenuta aggiornata e un percorso di segnalazione che hai già provato prima di averne bisogno. ## FAQ ### Rientro nell'ambito di applicazione di NIS 2? Due filtri: settore e dimensione. Devi operare in uno dei 18 settori elencati (energia, trasporti, finanza, sanità, infrastrutture digitali, pubblica amministrazione, spazio, prodotti alimentari, sostanze chimiche, servizi postali, fabbricazione di prodotti critici, ricerca, gestione dei rifiuti, oltre ad alcuni altri). E devi soddisfare la soglia dimensionale: 50+ dipendenti o 10 milioni di euro di fatturato annuo. Al di sotto di tale soglia, sei fuori dall'ambito di applicazione per impostazione predefinita, con eccezioni nazionali per le entità critiche di qualsiasi dimensione. Due categorie nell'ambito di applicazione: le entità essenziali (energia, trasporti, settore bancario, infrastrutture dei mercati finanziari, sanità, acqua potabile, acque reflue, infrastrutture digitali, gestione dei servizi ICT B2B, pubblica amministrazione, spazio) sono soggette a una vigilanza più rigorosa e a sanzioni più elevate. Le entità importanti (servizi postali, rifiuti, sostanze chimiche, prodotti alimentari, fabbricazione, fornitori digitali, ricerca) sono soggette a una vigilanza più leggera ma agli stessi obblighi di controllo. ### Quali sono le dieci misure dell'Articolo 21? L'Articolo 21(2) elenca dieci misure di gestione dei rischi di cybersecurity: (a) politiche di analisi dei rischi e di sicurezza dei sistemi informativi; (b) gestione degli incidenti; (c) continuità operativa e gestione delle crisi; (d) sicurezza della catena di approvvigionamento; (e) sicurezza nell'acquisizione, sviluppo e manutenzione; (f) politiche e procedure per valutare l'efficacia delle misure di gestione dei rischi di cybersecurity; (g) igiene informatica di base e formazione in materia di cybersecurity; (h) politiche in materia di crittografia e cifratura; (i) sicurezza delle risorse umane, controllo degli accessi e gestione degli asset; (j) uso dell'autenticazione a più fattori, di comunicazioni voce/video/testo protette e di sistemi di comunicazione di emergenza protetti. La direttiva non specifica come implementare ciascuna misura. ISO 27001 si mappa con precisione su tutte e dieci; NIST CSF e CIS Controls ne coprono la maggior parte. Scegli un framework, documenta la mappatura e l'autorità di vigilanza sarà soddisfatta. ### Qual è la tempistica di segnalazione degli incidenti? In caso di incidente significativo, tre scadenze: preallarme entro 24 ore (valutazione iniziale, se si sospetta che l'incidente sia causato da atti illeciti o malevoli, potenziale impatto transfrontaliero); notifica entro 72 ore (valutazione più ampia, indicatori di compromissione); relazione finale entro un mese (descrizione dettagliata dell'incidente, gravità, impatto, misure di mitigazione adottate, analisi delle cause profonde ove disponibile). Un incidente significativo è quello che ha causato o è in grado di causare gravi perturbazioni operative o perdite finanziarie, oppure che colpisce altri causando un danno materiale o immateriale considerevole. Le soglie sono chiarite dalle autorità nazionali; verifica le tue. ### Quali sono le sanzioni? Le entità essenziali sono soggette a sanzioni amministrative fino a 10 milioni di euro o al 2% del fatturato annuo mondiale, se superiore. Le entità importanti sono soggette a sanzioni fino a 7 milioni di euro o all'1,4% del fatturato annuo mondiale. Le autorità nazionali possono inoltre imporre sanzioni non pecuniarie: ordini di conformità, divulgazione pubblica della non conformità, divieti temporanei per le persone con funzioni dirigenziali di ricoprire il proprio ruolo. Le sanzioni non sono l'unico strumento di enforcement. Il dialogo di vigilanza, gli audit e gli ordini di adottare una specifica azione correttiva si collocano tutti al di sotto della soglia sanzionatoria e sono più comuni nella pratica. ### Come interagisce NIS 2 con DORA e l'AI Act? Per le entità finanziarie, DORA è lex specialis sui temi ICT: laddove DORA si applica, prevale su NIS 2 per le disposizioni relative all'ICT. Le entità finanziarie applicano comunque NIS 2 per i temi non ICT coperti dalla direttiva. L'AI Act è parallelo: disciplina i sistemi di IA, non i programmi di cybersecurity. Se gestisci sistemi di IA ad alto rischio all'interno di un settore critico, sei soggetto a entrambi: NIS 2 per la baseline di cybersecurity, l'AI Act per il lavoro di conformità sull'IA. ## Official sources - [EUR-Lex, Directive (EU) 2022/2555 (NIS 2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) - [ENISA, NIS 2 hub](https://www.enisa.europa.eu/topics/cybersecurity-policy/nis-directive-new) - [ANSSI, Transposition NIS 2 (France)](https://cyber.gouv.fr/nis-2) --- # DORA: quello che il tuo RSSI non ti ha detto. **URL:** https://cyberacademy.net/it/resources/pillars/dora **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition DORA (Regolamento (UE) 2022/2554) è il regolamento dell'UE che impone un quadro unificato di resilienza operativa digitale alle entità finanziarie e ai loro fornitori terzi di servizi ICT critici. Applicabile dal 17 gennaio 2025. Cinque pilastri: gestione del rischio ICT, segnalazione degli incidenti, test di resilienza compresi i test di penetrazione guidati dalla minaccia, rischio ICT di terze parti, condivisione delle informazioni. Lex specialis rispetto a NIS 2 sui temi ICT. ## TL;DR - Si applica a circa 20 categorie di entità finanziarie più i fornitori terzi di servizi ICT designati come critici, dal 17 gennaio 2025. - Cinque pilastri. Il registro dei terzi (Pilastro 4) e i test di resilienza (Pilastro 3, compreso il TLPT per le entità significative) sono i più operativi e i più sottoposti ad audit. - Per le entità significative, test di penetrazione guidati dalla minaccia ogni tre anni, supervisionati dall'autorità nazionale nell'ambito di TIBER-EU. - I fornitori terzi di servizi ICT critici sono supervisionati direttamente dalle Autorità europee di vigilanza (ESA). Il loro rischio di concentrazione ora conta a livello UE. - Da abbinare a ISO 22301 per il BCMS, ISO 27001 per la gestione del rischio ICT, e a Lead Operational Resilience Manager per il livello rivolto al regolatore. ## Full content La maggior parte delle entità finanziarie non ha iniziato DORA da zero. Avevano un ISMS, un piano di continuità operativa, una politica di esternalizzazione e un inventario dei terzi che era per lo più costituito da contratti di approvvigionamento. DORA non butta via tutto questo. Lo riformula, alza l'asticella su due pilastri in particolare, e sposta la conversazione da "hai un controllo" a "puoi dimostrare che il tuo servizio continua a funzionare quando un fornitore ICT viene meno". Questa pagina parla proprio di quel divario: come i cinque pilastri si concretizzano nelle operazioni, cosa apre per primo un supervisore, e dove i team perdono tempo. ## I cinque pilastri, e chi viene sottoposto ad audit su ciascuno Il regolamento si basa su cinque pilastri. Nella pratica non hanno tutti lo stesso peso. Il Pilastro 1 è fondamentale ma familiare a chiunque gestisca un ISMS. I Pilastri 3 e 4 sono quelli su cui si concentra l'attenzione della vigilanza, perché producono prove difficili da falsificare e facili da verificare. La tabella seguente è la versione che usiamo per informare un consiglio di amministrazione: cosa richiede ciascun pilastro, e chi all'interno dell'entità risulta più esposto quando il regolatore chiede le prove. **I cinque pilastri di DORA: requisito e la funzione più sottoposta ad audit su ciascuno** | Pilastro | Cosa richiede | Più sottoposta ad audit | | --- | --- | --- | | 1. Gestione del rischio ICT | Un quadro di governance documentato: mappatura degli asset e delle dipendenze, identificazione del rischio, controlli di protezione e rilevamento, risposta e ripristino, con titolarità del consiglio di amministrazione e una funzione responsabile designata. | CISO / RSSI e l'organo di gestione, che deve dimostrare una supervisione attiva, non una delega. | | 2. Gestione e segnalazione degli incidenti ICT | Classificare gli incidenti connessi all'ICT secondo criteri armonizzati, quindi segnalare gli incidenti gravi all'autorità competente secondo le scadenze iniziale / intermedia / finale. | Risposta agli incidenti e SOC, oltre a chi è responsabile delle notifiche regolamentari. | | 3. Test di resilienza operativa digitale | Un programma di test basato sul rischio; per le entità significative, test di penetrazione guidati dalla minaccia (TLPT) su sistemi di produzione live almeno ogni tre anni. | Security testing, red team, e i responsabili aziendali dei sistemi inclusi nell'ambito. | | 4. Rischio ICT di terze parti | Un registro di tutti gli accordi con terzi ICT, clausole contrattuali su audit, uscita e subappalto, e analisi del rischio di concentrazione. | Approvvigionamento, gestione dei fornitori e ufficio legale, che devono produrre il registro e i contratti su richiesta. | | 5. Condivisione delle informazioni | Accordi volontari per lo scambio di cyber threat intelligence tra entità finanziarie. | Threat intelligence; il pilastro più leggero e raramente di per sé una non conformità. | ## Cosa fare per primo L'errore è iniziare dall'aggiornamento delle policy, perché è il lavoro più comodo. Inizia invece dai due artefatti che un supervisore può richiedere per iscritto e che richiedono più tempo per essere costruiti correttamente: il registro dei terzi ICT e la mappatura delle funzioni critiche o importanti rispetto agli asset e ai fornitori ICT che le sostengono. Tutto il resto dipende da quella mappatura. Non puoi definire l'ambito dei test di resilienza, non puoi classificare la gravità degli incidenti, e non puoi ragionare sul rischio di concentrazione finché non sai quali funzioni sono critiche e da cosa dipendono. Una sequenza praticabile per i primi 90 giorni: 1. Definisci le tue funzioni critiche o importanti. Questa è una decisione di business, non di sicurezza. Determina l'ambito di quasi ogni altro obbligo. 1. Mappa ogni funzione critica rispetto ai servizi ICT, interni ed esternalizzati, da cui dipende. Questo è il tuo grafo delle dipendenze. 1. Costruisci il registro dei terzi a partire da quel grafo, non dal foglio di calcolo dell'approvvigionamento. Il registro deve descrivere gli accordi che sostengono le funzioni, compresi i subappaltatori nella catena. 1. Colma le lacune contrattuali richieste da DORA (diritti di audit, strategie di uscita, trasparenza del subappalto, cooperazione in caso di incidenti) prima di tutto sugli accordi che sostengono le funzioni critiche. 1. Solo allora formalizza il quadro di gestione del rischio ICT e il programma di test, perché entrambi ora hanno un ambito definito su cui lavorare. > **Metti in sequenza il registro prima delle policy** Se hai capacità limitata, il registro e la mappatura delle funzioni critiche sono il lavoro portante. Sbloccano la classificazione degli incidenti, l'ambito dei test e l'analisi della concentrazione. Una policy di rischio ICT scritta magnificamente ma senza una mappa delle dipendenze sotto è la prima cosa che un esaminatore smaschera. ## Il registro dei terzi ICT (Pilastro 4) nella pratica Il registro non è un elenco di fornitori. È un insieme strutturato di registri delle informazioni che l'entità mantiene e che le autorità competenti raccolgono, secondo un modello definito, per osservare la concentrazione ICT nell'intero settore finanziario. Questo cambia il modo in cui lo costruisci. Un campo "abbastanza buono" per uso interno diventa un problema di qualità dei dati quando viene aggregato a livello nazionale e UE. Tre cose causano la maggior parte dei problemi. Primo, l'unità è l'accordo contrattuale, non il fornitore. Un singolo fornitore può stare dietro a più accordi, e un singolo accordo può sostenere più funzioni. Stai descrivendo un grafo molti-a-molti, e appiattirlo in una riga per fornitore non sopravviverà alla revisione. Secondo, devi seguire la catena. Il registro deve catturare i subappaltatori che di fatto sostengono una funzione critica o importante, il che significa che la tua visibilità sul fornitore deve spingersi oltre la tua controparte diretta. Se il tuo contratto non ti dà il diritto di sapere chi è la quarta parte, quella è una lacuna contrattuale da colmare, non un campo da lasciare in bianco. Terzo, il flag di criticità della funzione su ciascun accordo è il campo da cui dipende tutto il resto. Contrassegna troppe cose come critiche e affoghi i tuoi stessi test e la tua remediation contrattuale; contrassegnane troppo poche e sottostimi il rischio di concentrazione e inganni il supervisore. Fai bene la valutazione della criticità una volta sola, a livello di funzione, e lascia che si propaghi. > **Il rischio di concentrazione è ora una questione di livello UE** Quando un singolo fornitore di cloud o di core banking sostiene funzioni critiche presso molte entità, quel fornitore può essere designato come fornitore terzo di servizi ICT critico e supervisionato direttamente dalle ESA. Il tuo registro è uno degli input che fa emergere questo. Tratta la qualità dei dati nel registro come un'esposizione di vigilanza, non come un compito amministrativo. ## Test di penetrazione guidati dalla minaccia (Pilastro 3): com'è davvero la sala Il TLPT è il pilastro che sorprende, perché non assomiglia a un test di penetrazione di routine. È guidato dall'intelligence, eseguito su sistemi di produzione live, circoscritto alle funzioni critiche o importanti, e condotto secondo la metodologia TIBER-EU con il coinvolgimento dell'autorità nazionale. Le entità significative lo eseguono con un ciclo di almeno tre anni. È più vicino a un'esercitazione di red team supervisionata che a una scansione delle vulnerabilità, e il deliverable che conta non è l'elenco delle non conformità; è la prova che il rilevamento e la risposta hanno funzionato, oppure il resoconto onesto del perché non hanno funzionato. Tre realtà che i team sottovalutano: - L'ambito è determinato dalle funzioni critiche, non da ciò che è comodo testare. Se una funzione si estende a un fornitore esternalizzato, quel fornitore potrebbe dover rientrare nell'ambito, il che significa che la cooperazione del fornitore deve essere garantita contrattualmente in anticipo. - Il blue team in genere non viene informato. Il valore sta nel testare il rilevamento e la risposta reali, quindi un TLPT di cui i difensori erano stati avvisati ha perso gran parte del suo senso. Questo ha conseguenze organizzative che si pianificano, non si scoprono a metà esercitazione. - I tester e i fornitori di threat intelligence devono soddisfare requisiti di competenza e indipendenza, e l'autorità esamina il processo. Non puoi semplicemente rietichettare il pentest annuale dell'anno scorso come TLPT. Se la tua entità è al di sotto della soglia di significatività, non esegui il TLPT, ma devi comunque un programma di test basato sul rischio: valutazioni delle vulnerabilità, test basati su scenari, e test di resilienza del percorso di ripristino. Il corso Lead Operational Resilience Manager è costruito proprio attorno a questo livello di test ed evidenze rivolto al regolatore, e il corso DORA Lead Manager copre come l'intero programma è governato dall'inizio alla fine. ## DORA come lex specialis rispetto a NIS 2 per le banche Le banche, e la maggior parte delle altre entità finanziarie, rientrano nell'ambito sia di NIS 2 sia di DORA. I due si sovrappongono fortemente su rischio ICT, segnalazione degli incidenti e sicurezza della catena di fornitura, il che solleva l'ovvio timore di fare tutto due volte. DORA risolve la questione: sulle materie ICT che disciplina, DORA è lex specialis. La regola specifica prevale su quella generale. Laddove DORA fissa l'obbligo di gestione del rischio ICT e di segnalazione degli incidenti, un'entità finanziaria segue DORA, e le autorità competenti non dovrebbero applicare in aggiunta l'equivalente requisito NIS 2 per lo stesso tema ICT. Cosa questo non significa: non disattiva del tutto NIS 2 per un'entità finanziaria, e non cambia chi è la tua autorità competente per le materie non ICT. La decisione pratica per una banca è mappare ogni obbligo allo strumento che lo disciplina: resilienza operativa ICT, segnalazione degli incidenti e rischio ICT di terze parti rientrano in DORA; tutto ciò che è al di fuori di DORA è ambito che valuti separatamente. Documenta quella mappatura. È la risposta alla domanda "stai contando due volte o sotto-contando" che esaminatori e auditor pongono entrambi. > **La logica della lex specialis è uno strumento decisionale, non una scappatoia** Usala per evitare segnalazioni duplicate e scadenze in conflitto, non per eludere un obbligo. Se un tema ICT è disciplinato da DORA, soddisfi lo standard DORA; non puoi scegliere quale dei due regimi è meno esigente. ## Errori comuni e dove costruire la competenza Gli insuccessi ricorrenti non sono esotici. Il registro è costruito per fornitore invece che per accordo e si rompe nel momento in cui il subappalto conta. La criticità delle funzioni critiche è valutata dall'IT invece che dal business, quindi l'ambito di tutto ciò che ne discende è sbagliato. Le soglie di classificazione degli incidenti sono scritte ma mai testate rispetto a un incidente reale, quindi il primo evento grave diventa la prima prova generale della tempistica di segnalazione. E la continuità operativa è trattata come un progetto ISO 22301 separato anziché come il muscolo di ripristino che i test DORA dovrebbero esercitare. Quest'ultimo punto conta: DORA non sostituisce un sistema di gestione della continuità operativa, ne presuppone uno. Gli obiettivi di ripristino e il percorso di ripristino testato che un BCMS ti offre sono ciò che i test di resilienza convalidano. Costruisci il BCMS correttamente con il corso ISO 22301 Lead Implementer, e diventa il substrato su cui poggiano gli obblighi di resilienza operativa anziché un raccoglitore parallelo che nessuno apre. Se parti dal regolamento stesso, il corso DORA Foundation offre a tutto il team una lettura condivisa e accurata dei cinque pilastri e dell'ambito prima che chiunque tocchi il registro o il programma di test. Da lì, il corso DORA Lead Manager è il livello di attuazione e governance per le persone che saranno titolari del quadro, e il corso Lead Operational Resilience Manager è per la funzione che deve presentarsi davanti al supervisore e dimostrare che la resilienza è reale, non documentata. ## FAQ ### Chi rientra nell'ambito di applicazione di DORA? Circa 20 categorie di entità finanziarie: enti creditizi, istituti di pagamento, istituti di moneta elettronica, imprese di investimento, controparti centrali, sedi di negoziazione, depositari centrali di titoli, imprese di assicurazione e di riassicurazione, intermediari, prestatori di servizi per le cripto-attività, prestatori di servizi di informazione sui conti, gestori di fondi di investimento alternativi, società di gestione, prestatori di servizi di comunicazione dati, agenzie di rating del credito, amministratori di indici di riferimento critici, fornitori di servizi di crowdfunding, repertori di dati sulle cartolarizzazioni. Più un regime separato per i fornitori terzi di servizi ICT critici (CTPP) designati dalle ESA sulla base di una valutazione della criticità. I CTPP sono soggetti alla vigilanza diretta di un Joint Oversight Forum guidato da un'ESA. ### Cos'è il TLPT e chi ne ha bisogno? Il Threat-Led Penetration Testing è un'esercitazione di red team supervisionata dal regolatore, richiesta per le entità finanziarie significative ai sensi di DORA. Costruito sul quadro TIBER-EU (Threat Intelligence-Based Ethical Red Teaming). Almeno ogni tre anni. Il TLPT è guidato dall'intelligence (profilo di minaccia fornito da un team di intelligence separato), prende di mira funzioni critiche o importanti dell'entità ed è supervisionato dall'autorità nazionale. Dura mesi, è costoso ed è il test più rigoroso che un CISO finanziario dovrà affrontare. ### Come interagisce DORA con NIS 2 per le banche? DORA è lex specialis sui temi ICT. Laddove DORA si applica, prevale su NIS 2 per le disposizioni relative all'ICT. Per i temi NIS 2 non ICT (sicurezza fisica, alcuni aspetti di governance, ambito della formazione), NIS 2 continua ad applicarsi in parallelo. In pratica, una banca che rientra nell'ambito di entrambi attua pienamente DORA per il rischio ICT, la segnalazione degli incidenti, i test di resilienza e il rischio ICT di terze parti, mentre legge NIS 2 per il restante quadro di base della governance della cybersicurezza. ### Cosa va nel registro dei terzi ICT? L'articolo 28 più gli RTS dell'EBA sul subappalto e sul registro delle informazioni specificano i campi. Ogni accordo contrattuale con un fornitore di servizi ICT è registrato con: natura dei servizi, criticità, catena di subappalto visibile all'entità, ubicazione dei servizi, ubicazione dei dati, SLA prestazionali, strategia di uscita, assetti di governance. Il registro è il documento che l'autorità di vigilanza chiede per primo. La maggior parte delle entità finanziarie sottovaluta l'onere di manutenzione; un registro non aggiornato è trattato come una non conformità. ### Qual è il rapporto tra DORA e ISO 22301? DORA non impone la certificazione ISO 22301, ma gli obblighi di BCM e disaster recovery del regolamento (articoli 11-12) si mappano quasi uno a uno su un BCMS conforme a ISO 22301. La maggior parte delle entità che già gestiscono un BCMS 22301 vi innesta il livello di test e segnalazione specifico di DORA senza ricostruire le fondamenta. ## Official sources - [EUR-Lex, Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) - [European Banking Authority, DORA hub](https://www.eba.europa.eu/regulation-and-policy/digital-operational-resilience-act) - [ESMA, DORA implementation](https://www.esma.europa.eu/regulation/digital-operational-resilience) --- # ISO 27001: Foundation, Lead Implementer, Lead Auditor, quale scegliere? **URL:** https://cyberacademy.net/it/resources/pillars/iso-27001-foundation-li-la **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition ISO 27001 prevede tre livelli di certificazione: Foundation (2 giorni, vocabolario e struttura), Lead Implementer (5 giorni, costruire l'ISMS) e Lead Auditor (5 giorni, sottoporlo ad audit). Foundation è il prerequisito per le credenziali senior. Lead Implementer è adatto ai team di sicurezza e GRC che gestiscono l'ISMS; Lead Auditor è adatto agli auditor interni e ai professionisti degli organismi di certificazione. ## TL;DR - Foundation è il prerequisito. Fornisce il vocabolario e il modello mentale del sistema di gestione. Due giorni, esame di 1 ora. - Lead Implementer (5 giorni) ti insegna a costruire l'ISMS, redigere la SoA, condurre il trattamento del rischio e gestire il ciclo del riesame della direzione. - Lead Auditor (5 giorni) ti insegna a pianificare e guidare audit di terza parte o interni. Una mentalità diversa: evidenze, campionamento, tecnica di intervista, reportistica. - La maggior parte dei CISO e dei responsabili della sicurezza segue Lead Implementer. Gli auditor interni e i consulenti delle Big Four seguono Lead Auditor. È comune fare entrambi nell'arco di 12-18 mesi. - Tassi di superamento sulle nostre sessioni PECB con docente: 99,1% al primo tentativo nella nostra erogazione; la media di mercato è dell'80%-85% a seconda del partner. ## Full content ## La decisione che conta davvero: stai costruendo o facendo audit? Le tre credenziali ISO 27001 non sono un'unica scala da salire in ordine. Foundation è la base condivisa, ma al di sopra di essa il percorso si biforca in due lavori diversi. Un lavoro consiste nel progettare e gestire un sistema di gestione della sicurezza delle informazioni (ISMS) all'interno di un'organizzazione. L'altro consiste nell'esaminare l'ISMS di qualcun altro rispetto allo standard e formulare un giudizio indipendente. I titoli lo segnalano: Lead Implementer è un costruttore, Lead Auditor è un esaminatore. Scegliere quello sbagliato spreca una settimana di formazione e ti dà un certificato che non corrisponde al lavoro che hai davanti. Poniti una domanda prima di prenotare qualunque cosa: nei prossimi dodici mesi, sarai responsabile del fatto che un ISMS esista e funzioni, oppure responsabile di valutare se funziona? Se sei tu a possedere lo Statement of Applicability, il piano di trattamento del rischio e il riesame della direzione, stai costruendo. Se entri, campioni le evidenze e scrivi i rilievi, stai facendo audit. Il verbo che fai più spesso ogni giorno è l'intera decisione. In entrambi i casi parti dallo stesso punto. Il corso ISO 27001 Foundation ti fornisce il vocabolario, la struttura dei controlli dell'Annex A e la logica del sistema di gestione che entrambi i percorsi senior danno per scontato tu già possieda. ## Cosa valuta realmente ogni esame (oltre la brochure) Le descrizioni dei livelli ti dicono la durata. Non ti dicono cosa premia la valutazione, ed è proprio questo a determinare come dovresti prepararti. ### Foundation Foundation è un esame sulle conoscenze. Verifica che tu sappia leggere lo standard senza perderti: i punti da 4 a 10, il ciclo Plan-Do-Check-Act, la differenza tra un controllo e un obiettivo di controllo, e dove si colloca l'Annex A rispetto ai requisiti principali. Non ti chiede di applicare nulla sotto pressione. Se sai spiegare perché la SoA deve giustificare sia le inclusioni sia le esclusioni, sei pronto. ### Lead Implementer Lead Implementer è un esame sulle competenze costruito attorno a scenari. Ti viene data un'organizzazione fittizia e ti si chiede cosa faresti: come definiresti il campo di applicazione dell'ISMS, come condurresti la valutazione del rischio, cosa metteresti nel piano di trattamento del rischio, come gestiresti un controllo non conforme. Le domande premiano il giudizio, non la memoria. Il corso Lead Implementer è strutturato attorno all'intero progetto di implementazione, così gli scenari d'esame sembrano un lavoro che hai già svolto. ### Lead Auditor Lead Auditor mette alla prova un muscolo diverso: la metodologia di audit ISO 19011 applicata a ISO 27001. Gli scenari ti collocano nella sala di audit. Decidi quali evidenze dimostrano che un punto è soddisfatto, come campionare, come formulare un rilievo e come classificarlo come non conformità maggiore o minore. La trappola in cui cadono i candidati è fare audit nel modo in cui implementerebbero, dicendo all'auditato come sistemare le cose invece di dichiarare cosa non è conforme. Il corso Lead Auditor allena la disciplina dell'evidenza-prima, del giudizio-non-del-consiglio, che sia l'esame sia gli audit reali richiedono. ## I tre livelli a confronto **Livelli di certificazione ISO 27001 a confronto** | | Foundation | Lead Implementer | Lead Auditor | | --- | --- | --- | --- | | Lavoro principale | Comprendere lo standard | Costruire e gestire l'ISMS | Sottoporre a audit un ISMS | | Ruolo tipico | Chiunque sia nuovo a ISO 27001 | CISO, responsabile della sicurezza, owner GRC | Auditor interno, auditor di organismo di certificazione o di consulenza | | Durata | 2 giorni | 5 giorni | 5 giorni | | Tipo di esame | Conoscenze, esame breve | Basato su scenari, giudizio applicato | Metodologia di audit (ISO 19011), evidenze e rilievi | | Deliverable chiave che puoi produrre al termine | Leggere e orientarti nello standard | Campo di applicazione, SoA, piano di trattamento del rischio, riesame della direzione | Piano di audit, programma di audit, report dei rilievi | | Mentalità | Vocabolario e struttura | Progettare, gestire, migliorare | Evidenze, campionamento, giudizio indipendente | | Prerequisito | Nessuno | Conoscenze di livello Foundation | Conoscenze di livello Foundation | ## Prerequisiti e cosa ti offre realmente il passo successivo Foundation è il prerequisito per le credenziali senior, ma leggilo con precisione: la maggior parte degli schemi di accreditamento richiede conoscenze di livello Foundation, non necessariamente un certificato Foundation separato conseguito in anticipo. In pratica i corsi senior si aprono con un ripasso compresso dei fondamentali, poi li danno per acquisiti. Se arrivi senza quella base, passi il primo giorno a recuperare invece di imparare il metodo, e il lavoro sugli scenari nel resto della settimana poggia su un terreno fragile. Sostenere prima Foundation non è una formalità burocratica; è ciò che permette al corso di cinque giorni di insegnare alla massima profondità. Ciò che il passo successivo ti offre è leva, non solo una riga sul CV. Foundation ti dà la capacità di partecipare a una conversazione sull'ISMS senza perderti. Lead Implementer ti dà la capacità di essere responsabile dell'esistenza del sistema: sai definirne il campo di applicazione, difendere la SoA davanti a un auditor e gestire il ciclo. Lead Auditor ti dà l'indipendenza: puoi firmare rilievi su cui un organismo di certificazione o un consiglio di amministrazione faranno affidamento. Sono forme di autorità realmente diverse, ed è per questo che fare entrambi nell'arco di dodici-diciotto mesi è comune e utile. Un implementer che si è formato anche come auditor costruisce un ISMS che supera l'audit, perché sa cosa cercherà l'auditor. > **Prima costruisci, poi fai audit (di solito)** Se possiedi o possederai un ISMS, segui prima Lead Implementer. Avendo realizzato la costruzione, il corso di audit acquista senso immediato perché sai che aspetto hanno delle buone evidenze. L'ordine inverso funziona per i puri auditor interni che non possiederanno mai un controllo, ma è il caso minoritario. Scegli il percorso che corrisponde al tuo lavoro quotidiano, non quello che suona più senior. ## Errori comuni che costano una settimana Alcuni schemi ricorrono di frequente quando si scelgono o si sostengono questi corsi. Sono evitabili. 1. Trattare Lead Auditor come la versione di status più elevato di Lead Implementer. Non è al di sopra di esso; è di fianco. Prenotarlo per prestigio quando il tuo lavoro è costruire l'ISMS ti dà una competenza che userai raramente. 1. Saltare la base Foundation per risparmiare due giorni, poi perderne più di due all'interno del corso senior recuperando il vocabolario mentre tutti gli altri lo applicano. 1. Implementer che fanno audit dando consigli, e auditor che fanno audit scrivendo piani di miglioramento. L'auditor dichiara cosa non è conforme e indica il punto; la correzione spetta all'auditato. Oltrepassare quella linea fa fallire gli scenari d'esame e compromette gli audit reali. 1. Confondere lo standard con i controlli. L'Annex A è un insieme di riferimento da cui selezionare tramite la SoA. I requisiti certificabili risiedono nei punti da 4 a 10. I candidati che memorizzano i controlli ma non sanno spiegare i punti relativi al sistema di gestione faticano in entrambi gli esami senior. ## La realtà della sala di audit, e perché plasma entrambi i percorsi Per quale che sia il lato per cui ti formi, immagina l'audit di certificazione, perché è lì che i due ruoli si incontrano. L'auditor chiede le evidenze che un punto è soddisfatto e che un controllo selezionato opera come dichiara la SoA. L'implementer deve produrre quelle evidenze su richiesta: le registrazioni della valutazione del rischio, le decisioni di trattamento, i verbali del riesame della direzione, i risultati dell'audit interno, le azioni correttive. Nulla impressiona un auditor; solo le evidenze lo fanno. Un controllo che esiste ma non lascia traccia è, ai fini dell'audit, un controllo che non esiste. Ecco perché i professionisti più solidi comprendono entrambe le prospettive anche quando svolgono un solo lavoro. L'implementer progetta l'ISMS in modo che svolgere il lavoro crei anche la traccia. L'auditor legge quella traccia senza che gli venga raccontata una storia. Se stai scegliendo il tuo primo corso, scegli il ruolo in cui vivrai, poi pianifica il secondo corso per quando vorrai l'altra metà del quadro. Lo standard è un unico sistema visto da due sedie, e la credenziale che scegli dovrebbe corrispondere alla sedia su cui ti siedi. ## FAQ ### Dovrei seguire prima Lead Implementer o Lead Auditor? Scegli in base al tuo ruolo. Se costruisci, gestisci o mantieni l'ISMS (security manager, analista GRC, CISO di un'organizzazione più piccola), prima Lead Implementer. Il corso ti insegna a redigere la SoA, condurre il trattamento del rischio, stilare le politiche e gestire il riesame della direzione. Se fai audit (team di internal audit, consulente Big Four, auditor di organismo di certificazione), prima Lead Auditor. Il corso insegna il ciclo di audit, il campionamento delle evidenze, la tecnica di intervista e la disciplina nel redigere i rilievi. Fare entrambi è comune. In questo caso l'ordine conta poco; alcuni professionisti scelgono LI poi LA per acquisire la profondità operativa prima della prospettiva di audit, altri scelgono LA poi LI per interiorizzare ciò che gli auditor cercano prima di costruire. ### Foundation è davvero obbligatorio? Sì, formalmente. PECB richiede Foundation come prerequisito per l'ammissibilità agli esami Lead Implementer e Lead Auditor. La sessione in sé dura due giorni e copre il modello mentale del sistema di gestione, la struttura della ISO 27001:2022 e l'insieme dei controlli dell'Annex A. Per i professionisti senior con precedente esperienza su ISO 27001 o un'altra credenziale su sistemi di gestione ISO, il requisito Foundation può talvolta essere esentato tramite il riconoscimento PECB di una formazione equivalente. Verificalo prima di prenotare; valutiamo il tuo caso durante la call di scoperta. ### Com'è l'esame Lead Implementer? Tre ore, a libro aperto, online tramite la piattaforma PECB. Un mix di domande a scelta multipla e domande con scenario in stile saggio. È sulle domande con scenario che la maggior parte dei candidati perde punti: ricevi il contesto di un'organizzazione fittizia, poi devi applicare la metodologia ISMS dall'inizio alla fine, definire il campo di applicazione, identificare i rischi, proporre controlli, giustificare la struttura della SoA, pianificare il riesame della direzione. La preparazione sulla metodologia prima della sessione non è negoziabile. ### Quanto costa in Europa nel 2026? Prezzi standard PECB con docente in Europa a inizio 2026: Foundation intorno a 1.200 euro, Lead Implementer da 2.800 a 3.200 euro, Lead Auditor da 2.800 a 3.200 euro. Include il corso, i materiali ufficiali PECB, la quota di certificazione, l'esame, una ripetizione e la validità a vita della credenziale. La modalità self-paced costa in genere il 30%-40% in meno ma è più lenta nel completamento. Le sessioni in-house hanno un prezzo per team anziché per posto; aspettati da 12.000 a 18.000 euro per una sessione Lead Implementer di 5 giorni fino a 12 partecipanti, in presenza o virtuale. ### Le credenziali PECB e ISACA si sovrappongono? Coprono ambiti correlati ma diversi. PECB rilascia credenziali sugli standard ISO (ISO 27001, 27005, 31000, 22301, 42001…) e sulle normative UE (NIS 2, DORA). ISACA rilascia credenziali sulle discipline professionali (audit, gestione della sicurezza, rischio, governance, privacy) basate su COBIT e sui framework ISACA. La maggior parte dei professionisti senior possiede entrambe: un ISO 27001 Lead Implementer o Lead Auditor (PECB) più CISA o CISM (ISACA). Il percorso di audit (CISA → CRISC → ISO 27001 LA) è la sequenza canonica. ## Official sources - [PECB, ISO/IEC 27001 Lead Implementer](https://pecb.com/en/education-and-certification-for-individuals/iso-iec-27001) - [ISO, ISO/IEC 27001:2022](https://www.iso.org/standard/27001) --- # ISO 42001 e governance dell'IA: la mappa delle certificazioni e della formazione. **URL:** https://cyberacademy.net/it/resources/pillars/iso-42001-ai-governance **Author:** Christophe Mazzola **Published:** 2026-06-24 **Last reviewed:** 2026-06-24 ## Definition La governance dell'IA è la disciplina che consiste nel gestire i sistemi di IA sotto controllo: rischio, trasparenza, bias, validazione, sicurezza ed esposizione normativa. Il sistema di gestione di riferimento è ISO/IEC 42001, pubblicato a dicembre 2023, l'equivalente per l'IA dell'ISMS di ISO 27001. Il panorama delle credenziali si divide in due: ISO 42001 (PECB) per il livello del sistema di gestione, e le certificazioni ISACA Advanced in AI (AAIA per l'audit, AAIR per il rischio, AAISM per la sicurezza) per il livello della disciplina professionale. Entrambi si mappano sull'EU AI Act e sul NIST AI RMF. ## TL;DR - ISO/IEC 42001 è lo standard di sistema di gestione per l'IA (un sistema di gestione dell'IA, o AIMS), pubblicato a dicembre 2023. È l'equivalente AIMS dell'ISMS di ISO 27001. PECB rilascia il percorso Foundation, Lead Implementer e Lead Auditor. - Il percorso ISACA Advanced in AI è il livello della disciplina professionale: AAIA (audit), AAIR (rischio), AAISM (sicurezza). Ciascuno presuppone una certificazione ISACA esistente (CISA, CRISC, CISM). - L'EU AI Act dice cosa dimostrare per un sistema ad alto rischio. ISO 42001 dice come organizzare la prova. Il NIST AI RMF è il metodo operativo di gestione del rischio che lo popola. - Scegli in base al ruolo: costruire il sistema, ISO 42001 Lead Implementer. Auditare l'IA, AAIA. Gestire il rischio IA, AAIR o PECB AI Risk Manager. Mettere in sicurezza i modelli, AAISM. Guidare la delivery dell'IA, CAIP. - Non esiste un'unica 'certificazione di governance dell'IA'. Un professionista senior abbina la credenziale di sistema di gestione ISO 42001 a una credenziale di disciplina. ## Full content Chiedi a cinque fornitori della certificazione di governance dell'IA e ottieni cinque risposte diverse, perché il mercato non si è ancora consolidato. Non esiste un unico certificato di governance dell'IA come esiste un'unica CISM o un'unica CISA. Esistono due livelli distinti, rilasciati da due organismi diversi, che rispondono a due domande diverse: come governi l'IA come organizzazione, e come la auditi, ne valuti il rischio o la metti in sicurezza come professionista. Questa pagina mappa i due livelli sullo standard (ISO/IEC 42001), sulla regolamentazione (l'EU AI Act) e sul framework statunitense (NIST AI RMF), poi indica quale credenziale si adatta a quale ruolo e come formare un team senza mandare tutti allo stesso corso di cinque giorni. È scritta per il CISO, il responsabile GRC o l'auditor che deve prendere la decisione. ## I due livelli delle credenziali di governance dell'IA Ogni credenziale di governance dell'IA presente sul mercato si colloca in uno di due livelli. - Il livello del sistema di gestione risponde alla domanda "come governa l'organizzazione la propria IA?". Il riferimento è ISO/IEC 42001, lo standard internazionale di sistema di gestione dell'IA. PECB rilascia un percorso Foundation, Lead Implementer e Lead Auditor su di esso, esattamente come fa per ISO 27001. - Il livello della disciplina professionale risponde alla domanda "cosa fa questo professionista con l'IA?". Il riferimento è il percorso ISACA Advanced in AI: AAIA per gli auditor, AAIR per i risk manager, AAISM per i security manager. Ciascuno è di livello avanzato e presuppone che tu possieda già la corrispondente certificazione ISACA. I due livelli sono complementari. Una funzione di governance dell'IA matura possiede entrambi: una credenziale di sistema di gestione ISO 42001 per costruire e gestire il sistema, e una credenziale di disciplina ISACA per ogni funzione che opera al suo interno. ## ISO/IEC 42001: il sistema di gestione dell'IA ISO/IEC 42001:2023, pubblicato a dicembre 2023, è il primo standard internazionale per un sistema di gestione dell'IA (AIMS). È l'equivalente per l'IA dell'ISMS di ISO 27001: una politica, ruoli definiti, un processo di valutazione del rischio IA, controlli sul ciclo di vita del sistema di IA, un Annex A di controlli specifici per l'IA e un ciclo di riesame della direzione che mantiene il tutto coerente. Il percorso di certificazione PECB su di esso rispecchia ISO 27001: - ISO 42001 Foundation (2 giorni) fornisce il vocabolario e il modello di sistema di gestione. È il prerequisito per le credenziali senior. - ISO 42001 Lead Implementer (5 giorni) ti insegna a costruire l'AIMS: scope, valutazione del rischio IA, lo Statement of Applicability, i controlli, il ciclo operativo. È la credenziale per chi è responsabile della governance dell'IA. - ISO 42001 Lead Auditor (5 giorni) ti insegna ad auditare un AIMS: evidenze, campionamento, tecnica di intervista, rilievi. È la credenziale per l'internal audit e per gli auditor degli organismi di certificazione. > **Scegliere un solo corso ISO 42001?** È quasi sempre Lead Implementer. Costruisci il sistema molto più spesso di quanto audita quello di qualcun altro. ## Il percorso ISACA Advanced in AI: AAIA, AAIR, AAISM Le credenziali ISACA Advanced in AI sono il livello della disciplina professionale. Sono avanzate per concezione: ciascuna presuppone che tu possieda già la certificazione ISACA di base per quella disciplina, e ciascuna è mappata su ISO 42001 e sugli obblighi ad alto rischio dell'EU AI Act anziché insegnata nel vuoto. **Le tre credenziali ISACA Advanced in AI** | Credenziale | Disciplina | Presuppone | Concepita per | | --- | --- | --- | --- | | AAIA — Advanced in AI Audit | Auditare sistemi di IA, modelli e governance | CISA | Auditor IT senior, responsabili compliance | | AAIR — Advanced in AI Risk | Valutazione del rischio IA, quantificazione, trattamento, monitoraggio | CRISC | Risk manager IT, CRO | | AAISM — Advanced in AI Security Management | Modellazione delle minacce IA, ciclo di vita sicuro dei modelli, operazioni di sicurezza dell'IA | CISM | CISO, security architect | I tre corsi di Cyber Academy sono AAIA, AAIR e AAISM. Scegli in base a ciò che fai, non a quale sia il più recente. ## Dove si collocano PECB AI Risk Manager e CAIP Altre due credenziali PECB si affiancano al percorso ISO 42001. AI Risk Manager è una credenziale di rischio mirata per i professionisti che gestiscono programmi di rischio specifici per l'IA, rischio di modello, bias, drift, rischio di modelli di terze parti, senza il pieno scope di sistema di gestione di Lead Implementer. Certified Artificial Intelligence Professional (CAIP) è la credenziale di professionista più ampia, per chi costruisce e implementa l'IA in modo responsabile lungo il ciclo di vita, utile per i lead tecnici che hanno bisogno del vocabolario di governance senza essere responsabili dell'AIMS. Se gestisci già un programma di rischio ISO 27001 e vuoi estenderlo all'IA, AI Risk Manager è il ponte più breve. Se guidi la delivery dell'IA e ti serve l'alfabetizzazione di governance che l'AI Act ora ti richiede, CAIP è la scelta migliore. ## Come le credenziali si mappano sull'AI Act e sul NIST AI RMF Nessuna di queste credenziali esiste isolatamente. Sono insegnate a fronte della regolamentazione e dei framework che una funzione di governance dell'IA deve effettivamente soddisfare. **A cosa risponde ciascuno strumento** | Strumento | Cos'è | Certificabile? | Ruolo nel tuo programma | | --- | --- | --- | --- | | EU AI Act | Regulation (EU) 2024/1689 | No — valutazione di conformità, non certificazione | Cosa dimostrare per un sistema ad alto rischio | | ISO/IEC 42001 | Standard di sistema di gestione dell'IA | Sì — certificazione AIMS + credenziali PECB | Come organizzare la prova | | NIST AI RMF | Framework volontario di rischio statunitense (Govern, Map, Measure, Manage) | No | Metodo operativo di rischio che popola il sistema | | ISO/IEC 23894 | Guida alla gestione del rischio IA | No | Metodologia di rischio, allineata a ISO, all'interno dell'AIMS | Il percorso canonico per un'organizzazione europea: costruire l'AIMS con ISO 42001 Lead Implementer, mappare gli obblighi ad alto rischio dell'AI Act sui controlli dell'AIMS e usare il NIST AI RMF o ISO 23894 come metodologia di rischio. La credenziale ISACA Advanced equipaggia poi qualunque funzione, audit, rischio o sicurezza, debba operare all'interno di quel sistema. ## Come formare un team sulla governance dell'IA L'errore è mandare tutti allo stesso corso. La governance dell'IA è trasversale alle funzioni, e le funzioni hanno bisogno di profondità diverse. 1. Inizia con una base condivisa. ISO 42001 Foundation, o un briefing di alfabetizzazione sull'AI Act che soddisfi l'obbligo di alfabetizzazione sull'IA dell'Articolo 4 dell'Act, dà a tutti lo stesso vocabolario prima che si specializzino. 1. Invia i responsabili di governance e compliance a ISO 42001 Lead Implementer. Costruiscono e gestiscono l'AIMS. 1. Invia l'internal audit ad AAIA, la funzione di rischio ad AAIR e la funzione di sicurezza ad AAISM. Ciascuna opera all'interno dell'AIMS dalla propria angolazione. 1. Aggiungi ISO 42001 Lead Auditor solo se gestisci un programma di internal audit a fronte dell'AIMS o fai parte di un organismo di certificazione. > **Formare un intero team?** Una coorte interna è prezzata per coorte anziché per posto e mappa gli esercizi sul tuo parco IA effettivo. La call di discovery definisce quali ruoli necessitano di quale credenziale prima che chiunque prenoti: la maggior parte dei team acquista troppe iscrizioni a Lead Implementer e troppo poche alle credenziali di disciplina. ## La decisione, in una riga Costruire il sistema: ISO 42001 Lead Implementer. Auditare l'IA: AAIA. Gestire il rischio IA: AAIR o PECB AI Risk Manager. Mettere in sicurezza i modelli: AAISM. Guidare la delivery dell'IA e avere bisogno di alfabetizzazione di governance: CAIP. Non esiste un unico certificato di governance dell'IA, e chiunque te ne venda uno ti sta vendendo una fetta. ## FAQ ### Esiste una certificazione di governance dell'IA, e quale dovrei conseguire? Non esiste un'unica certificazione di governance dell'IA. Lo spazio si divide in due livelli. Il livello del sistema di gestione è ISO/IEC 42001: PECB rilascia Foundation (2 giorni), Lead Implementer (5 giorni, costruire l'AIMS) e Lead Auditor (5 giorni, auditarne uno). Il livello della disciplina professionale è il percorso ISACA Advanced in AI: AAIA per auditare l'IA, AAIR per il rischio IA, AAISM per la gestione della sicurezza dell'IA. Per chi governa l'IA a livello organizzativo, ISO 42001 Lead Implementer è la pietra angolare. Per chi audita, valuta il rischio o mette in sicurezza l'IA all'interno di un ruolo GRC esistente, la corrispondente credenziale ISACA Advanced è il segnale più forte. La maggior parte dei professionisti senior possiede una credenziale di ciascun tipo. ### Cos'è ISO/IEC 42001 e come si relaziona con l'EU AI Act? ISO/IEC 42001:2023 è lo standard internazionale per i sistemi di gestione dell'IA, pubblicato a dicembre 2023. Definisce come un'organizzazione stabilisce, opera e migliora la governance dei propri sistemi di IA: politica, ruoli, valutazione del rischio IA, il ciclo di vita del sistema di IA, un Annex A di controlli specifici per l'IA e il ciclo di riesame della direzione. È l'equivalente AIMS dell'ISMS di ISO 27001. Lo standard non soddisfa l'EU AI Act da solo: l'Act ha requisiti tecnici specifici per prodotto per i sistemi ad alto rischio. Ma ISO 42001 fornisce la base di sistema di gestione che auditor e organismi notificati riconoscono. Il percorso canonico è ISO 42001 per costruire l'AIMS, poi mappare gli obblighi ad alto rischio dell'AI Act sui controlli dell'AIMS. ### AAIA vs AAIR vs AAISM: quale certificazione ISACA AI? Tre prospettive sull'IA, tutte presupponendo una credenziale ISACA esistente. AAIA (Advanced in AI Audit) è per gli auditor: auditare sistemi di IA, modelli e governance, mappato su ISO 42001 e sull'AI Act. Tipicamente posseduta insieme a CISA. AAIR (Advanced in AI Risk) è per i professionisti del rischio: valutazione del rischio IA, quantificazione, trattamento e monitoraggio. Tipicamente posseduta insieme a CRISC. AAISM (Advanced in AI Security Management) è per i leader della sicurezza: modellazione delle minacce IA, ciclo di vita sicuro dei modelli e operazioni di sicurezza dell'IA. Tipicamente posseduta insieme a CISM. ### Come formo un intero team sulla governance dell'IA? Sequenziala per funzione. Inizia con una base condivisa (ISO 42001 Foundation o un briefing di alfabetizzazione sull'AI Act che soddisfi l'Articolo 4). Invia i responsabili di governance e compliance a ISO 42001 Lead Implementer; l'internal audit ad AAIA; la funzione di rischio ad AAIR; la funzione di sicurezza ad AAISM. Per un rollout su più team, una coorte interna è prezzata per coorte e mappa gli esercizi sul tuo parco IA. La call di discovery definisce quali ruoli necessitano per primi di quale credenziale: la maggior parte dei team acquista troppe iscrizioni a Lead Implementer e troppo poche alle credenziali di disciplina. ### Dove si colloca il NIST AI RMF rispetto a ISO 42001? Il NIST AI Risk Management Framework (AI RMF 1.0, gennaio 2023) è il framework volontario statunitense strutturato attorno a Govern, Map, Measure e Manage. Non è certificabile né è uno standard di sistema di gestione: è un playbook per la funzione di rischio. ISO 42001 e il NIST AI RMF sono complementari. ISO 42001 fornisce il sistema di gestione certificabile; il NIST AI RMF fornisce il metodo operativo di gestione del rischio che lo popola. Le organizzazioni esposte sia al contesto UE sia a quello statunitense gestiscono un AIMS ISO 42001 con il NIST AI RMF, e la relativa guida ISO/IEC 23894, come metodologia di rischio al suo interno. ## Official sources - [ISO, ISO/IEC 42001:2023 (AI management systems)](https://www.iso.org/standard/81230.html) - [EUR-Lex, Regulation (EU) 2024/1689 (AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - [NIST, AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [ISACA, Advanced in AI (AAIA / AAIR / AAISM)](https://www.isaca.org/credentialing) --- # AI Act: conformità senza l'astrazione. **URL:** https://cyberacademy.net/it/resources/pillars/ai-act **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition L'AI Act europeo (Regulation (EU) 2024/1689) è la prima regolamentazione organica al mondo sull'intelligenza artificiale. Quattro livelli di rischio: inaccettabile (vietato), alto (obblighi onerosi e valutazione di conformità), limitato (trasparenza), minimo. Regole dedicate ai modelli di IA per finalità generali. Si applica per fasi fino ad agosto 2027. La ISO 42001 è la risposta in termini di sistema di gestione ai requisiti organizzativi dell'AI Act. ## TL;DR - Basato sul rischio: pratiche inaccettabili vietate (da febbraio 2025), sistemi ad alto rischio fortemente regolamentati, il rischio limitato richiede trasparenza, il rischio minimo non è toccato. - I sistemi ad alto rischio (occupazione, infrastrutture critiche, istruzione, biometria, attività di contrasto, giustizia…) richiedono gestione del rischio, governance dei dati, documentazione tecnica, trasparenza, sorveglianza umana, accuratezza e cybersecurity. - Le regole sui modelli GPAI si applicano ai fornitori di IA per finalità generali, con obblighi più stringenti per i modelli a rischio sistemico. - Valutazione di conformità richiesta prima di immettere un sistema ad alto rischio sul mercato europeo. Si applica la marcatura CE. - Da abbinare alla ISO/IEC 42001 per il livello del sistema di gestione. L'AI Act ti dice cosa devi dimostrare; la ISO 42001 ti dice come organizzare le prove. ## Full content ## Classifica il sistema prima di fare qualsiasi altra cosa Ogni decisione legata all'AI Act parte da una domanda: in quale livello rientra questo sistema. Sbaglia la classificazione e finirai o per sovra-ingegnerizzare un chatbot oppure per sotto-proteggere uno strumento di screening dei CV che un regolatore tratterà come ad alto rischio. I quattro livelli non sono uno spettro su cui scorrere; sono compartimenti distinti con conseguenze giuridiche diverse, e un singolo prodotto può collocarsi in più di uno se raggruppa diverse funzioni. La classificazione è funzione della finalità prevista, non della sofisticazione tecnica. Una semplice regressione logistica che decide chi ottiene un prestito è ad alto rischio. Un grande modello multimodale che consiglia ricette non lo è. L'Act guarda a cosa serve il sistema e chi colpisce, quindi il lavoro di classificazione spetta congiuntamente a prodotto e conformità, non solo al team di data science. **I quattro livelli di rischio dell'AI Act europeo e cosa ti obbliga a fare ciascuno** | Livello di rischio | Esempi | Obbligo principale | Vincolo prima del mercato | | --- | --- | --- | --- | | Inaccettabile | Social scoring, scraping non mirato per il riconoscimento facciale, sistemi manipolativi o sfruttatori | Vietato. La pratica non può essere immessa sul mercato né utilizzata in alcun modo. | Vietato del tutto (i divieti si applicano da febbraio 2025) | | Alto | Occupazione e reclutamento, credit scoring, infrastrutture critiche, istruzione, biometria, attività di contrasto, giustizia | Set completo di obblighi: gestione del rischio, governance dei dati, documentazione tecnica, registrazione (logging), sorveglianza umana, accuratezza, robustezza, cybersecurity | Valutazione di conformità più marcatura CE e registrazione nella banca dati dell'Unione | | Limitato | Chatbot, riconoscimento delle emozioni, deepfake e altri contenuti generati | Solo trasparenza: comunicare alle persone che stanno interagendo con un'IA o che il contenuto è generato dall'IA | Nessuna valutazione di conformità; obblighi di informativa | | Minimo | Filtri antispam, motori di raccomandazione, la maggior parte delle funzionalità di IA di consumo | Nessun obbligo cogente ai sensi dell'Act; sono incoraggiati codici volontari | Nessuno | La maggior parte delle controversie nella sala di audit non riguarda il minimo contro l'alto; riguarda l'alto contro il limitato al confine. Se non riesci a difendere la classificazione per iscritto, trattala come il livello superiore finché non ci riesci. Il corso AI Risk Manager illustra la logica di classificazione e le prove di cui hai bisogno per sostenere una decisione. ## Cosa significa davvero "alto rischio" sul piano operativo Il TL;DR elenca le sette aree di obbligo. La realtà operativa è che ciascuna è un processo ricorrente, non un documento che scrivi una volta sola. La conformità per l'alto rischio è un sistema che gestisci per tutta la vita del prodotto, e l'Act si aspetta che tu dimostri che il sistema è attivo, non che esisteva il giorno del lancio. 1. La gestione del rischio è continua. Identifichi l'uso improprio e i danni prevedibili, li mitighi, testi il rischio residuo e ripeti a ogni modifica sostanziale. Un registro dei rischi congelato al lancio è un rilievo, non un controllo. 1. La governance dei dati copre i set di addestramento, validazione e test: rappresentatività, esame dei bias, lacune e provenienza dei dati. Devi mostrare cosa hai verificato e cosa hai riscontrato, non limitarti ad affermare che i dati erano "buoni". 1. La documentazione tecnica è la spina dorsale del fascicolo. Descrive il sistema, la sua finalità, le sue scelte progettuali, le sue metriche di prestazione e i suoi limiti con un livello di dettaglio sufficiente affinché un terzo possa valutarne la conformità. 1. La conservazione delle registrazioni significa logging automatico per tutta la vita del sistema, così che gli eventi siano tracciabili. Se qualcosa va storto, devi essere in grado di ricostruire cosa ha fatto il sistema. 1. La sorveglianza umana deve essere progettata sin dall'inizio, non aggiunta a posteriori: le persone che supervisionano il sistema devono poter comprendere, intervenire e annullare, e l'interfaccia deve renderlo possibile. 1. Accuratezza, robustezza e cybersecurity devono essere misurate e dichiarate, poi mantenute in condizioni reali, comprese quelle avversariali. "Funziona nella demo" non è un'affermazione di robustezza. Questi obblighi si mappano in modo pulito su un sistema di gestione, ed è per questo che i team abbinano l'Act alla ISO/IEC 42001. Il corso ISO 42001 Lead Implementer costruisce il modello operativo che trasforma queste sette aree in processi ripetibili con responsabili, prove e cicli di revisione. ## Il flusso di lavoro della valutazione di conformità La valutazione di conformità è il vincolo che un sistema ad alto rischio supera prima di essere immesso sul mercato europeo. Per la maggior parte delle categorie ad alto rischio si tratta di una valutazione basata sul controllo interno, condotta dal fornitore rispetto ai requisiti dell'Act; alcune categorie, in particolare certe applicazioni biometriche, passano attraverso un organismo notificato. In entrambi i casi la sequenza è la stessa, e conviene trattarla come un piano di progetto anziché come una checklist. 1. Conferma la classificazione e i requisiti applicabili per il tuo specifico caso d'uso e categoria. 1. Avvia i processi di gestione del rischio e di governance dei dati e mettili in atto, generando prove reali anziché segnaposto. 1. Assembla la documentazione tecnica in modo che sia completa e internamente coerente con i log, i risultati dei test e il registro dei rischi. 1. Esegui la valutazione di conformità (interna, oppure tramite un organismo notificato ove richiesto) e risolvi le lacune che emergono. 1. Redigi la dichiarazione di conformità dell'Unione, apponi la marcatura CE e registra il sistema nella banca dati dell'Unione prima di andare sul mercato. 1. Passa al monitoraggio post-commercializzazione dal primo giorno, perché l'obbligo non finisce con il lancio. > **La documentazione deve essere veritiera, non solo completa** Gli auditor effettuano verifiche incrociate. Se la documentazione tecnica dichiara un valore di accuratezza che i log dei test non supportano, oppure descrive un controllo di sorveglianza umana che l'interfaccia effettiva non fornisce, l'intero fascicolo perde credibilità. Costruisci la documentazione a partire dalle prove, mai il contrario, e riconcilia il fascicolo con il sistema prima che qualcuno esterno lo veda. ## Monitoraggio post-commercializzazione e la tempistica a fasi Immettere un sistema sul mercato è il punto intermedio dell'obbligo, non la fine. I fornitori devono attuare un piano di monitoraggio post-commercializzazione che raccolga attivamente dati su prestazioni e incidenti per tutta la vita di esercizio del sistema, e gli incidenti gravi devono essere segnalati alle autorità entro finestre temporali definite. Le modifiche sostanziali possono far scattare nuovamente la valutazione di conformità, quindi il tuo processo di change management e il tuo processo AI Act devono essere collegati tra loro. La tempistica è a fasi, cosa che mette in difficoltà i team che leggono "agosto 2027" e presumono di avere fino ad allora per tutto. I divieti sulle pratiche inaccettabili si applicano già. Gli obblighi GPAI e diverse disposizioni di governance si collocano prima nel calendario, e gli obblighi per l'alto rischio entrano in vigore progressivamente nel periodo fino ad agosto 2027 a seconda della categoria. L'atteggiamento corretto è mappare ciascuno dei tuoi sistemi alla sua data applicabile, anziché pianificare verso un'unica scadenza limite. Gestire il ciclo di monitoraggio e segnalazione degli incidenti è il punto in cui i ruoli di auditor e risk manager dell'IA si dimostrano preziosi. Il corso AI auditor (AAIA) tratta come auditare un sistema di gestione dell'IA rispetto a queste prove, e il corso advanced AI auditor (AAIR) approfondisce il lavoro di testing e assurance dietro un fascicolo post-commercializzazione difendibile. ## IA per finalità generali: un obbligo separato che puoi ereditare Le regole sui modelli GPAI si collocano accanto ai livelli di rischio, non al loro interno. Se costruisci o fai fine-tuning di un modello per finalità generali, ti assumi gli obblighi del fornitore: documentazione tecnica del modello, informazioni per i deployer a valle, una politica sul diritto d'autore e una sintesi pubblica dei contenuti di addestramento. I modelli giudicati portatori di rischio sistemico assumono doveri più stringenti, tra cui valutazione del modello, testing avversariale e segnalazione degli incidenti. La trappola per la maggior parte dei team è l'altro lato di quella relazione. Se integri un modello fondativo di terze parti nel tuo sistema ad alto rischio, non sfuggi all'Act puntando il dito verso il fornitore del modello. Erediti il rischio di integrazione e resti responsabile del raggiungimento della conformità del tuo sistema. Tratta la documentazione del fornitore del modello come un input al tuo fascicolo, non come un sostituto, e metti in atto i flow-down contrattuali prima di andare in produzione. ## Errori comuni e la decisione che hai davanti - Trattare la classificazione come un fatto isolato. Una funzionalità nata come motore di raccomandazione diventa ad alto rischio nel momento in cui condiziona una decisione di assunzione o di credito. Riclassifica a ogni cambiamento sostanziale di finalità. - Scrivere la documentazione come un artefatto di lancio. Il fascicolo deve restare sincronizzato con il sistema in esercizio; un fascicolo obsoleto è peggio di uno incompleto, perché induce attivamente in errore. - Confondere il sistema di gestione con la regolamentazione. La ISO 42001 organizza le tue prove, ma di per sé non rende un sistema conforme all'AI Act. Devi comunque classificare, valutare e registrare rispetto all'Act. - Presumere che gli obblighi del fornitore GPAI coprano la tua integrazione. Non è così. Il tuo sistema ad alto rischio ha bisogno di una propria storia di conformità. - Pianificare verso un'unica scadenza. Le date a fasi fanno sì che alcuni obblighi siano già attivi mentre altri sono lontani anni; pianifica per sistema, per categoria. La decisione che la maggior parte dei team ha davanti non è se conformarsi, ma come costruire la capacità di conformarsi ripetutamente. Se parti da zero, il corso ISO 42001 Foundation dà al team un vocabolario condiviso, e il corso AI security management (AAISM) collega gli obblighi di cybersecurity e robustezza dell'Act al programma di sicurezza che già gestisci. Scegli il ruolo più vicino alla tua lacuna e costruisci da lì verso l'esterno. > **Inizia da un inventario, non da una policy** Prima di redigere una singola procedura, elenca ogni sistema di IA e ogni funzionalità di IA sostanziale che produci o utilizzi, e classifica ciascuno. La maggior parte delle organizzazioni scopre di avere più sistemi nel perimetro di quanti si aspettasse e meno sistemi genuinamente ad alto rischio di quanti temesse. L'inventario trasforma una regolamentazione astratta in un elenco di lavoro finito e con priorità. ## FAQ ### Il mio sistema di IA è ad alto rischio? L'Annex III elenca otto categorie di sistemi di IA ad alto rischio: biometria, infrastrutture critiche, istruzione e formazione professionale, occupazione e gestione dei lavoratori, accesso a servizi pubblici e privati essenziali, attività di contrasto, migrazione e controllo delle frontiere, giustizia e processi democratici. Più i sistemi di IA che fungono da componente di sicurezza o da prodotto coperto dalla normativa di armonizzazione dell'Unione (Annex I). Se il tuo sistema rientra in una di queste categorie, è ad alto rischio. Esiste un'eccezione ristretta ai sensi dell'Article 6(3) quando il sistema svolge un compito procedurale ristretto, migliora il risultato di un'attività umana precedentemente completata, rileva schemi decisionali senza sostituire la valutazione umana, oppure è un compito preparatorio. Documenta l'eccezione; l'autorità di vigilanza la chiederà. ### Quando si applica l'AI Act? Applicazione per fasi. I divieti (Article 5) e gli obblighi di alfabetizzazione sull'IA si applicano dal 2 febbraio 2025. Gli obblighi GPAI si applicano dal 2 agosto 2025. La maggior parte degli obblighi per l'alto rischio si applica dal 2 agosto 2026. Obblighi specifici per l'alto rischio relativi ai sistemi già sul mercato e ai sistemi che rientrano nell'Annex I si applicano dal 2 agosto 2027. Implicazione pratica: se immetti un sistema ad alto rischio sul mercato europeo nel 2026, si applica la maggior parte degli obblighi del Chapter III. Avvia ora il lavoro di valutazione di conformità. ### Come si presenta la valutazione di conformità? Per la maggior parte dei sistemi ad alto rischio, valutazione di conformità basata sul controllo interno ai sensi dell'Annex VI. Il fornitore dichiara da sé la conformità, sulla base di: un sistema di gestione della qualità, documentazione tecnica conforme all'Annex IV, monitoraggio post-commercializzazione, registrazione nella banca dati dell'Unione. Per alcuni sistemi ad alto rischio (in particolare i sistemi di identificazione biometrica), deve essere coinvolto un organismo notificato terzo (Annex VII). Seguono la marcatura CE e una dichiarazione di conformità dell'Unione. ### Qual è il ruolo della ISO/IEC 42001? La ISO/IEC 42001 è la norma internazionale per i sistemi di gestione dell'IA (AIMS), pubblicata alla fine del 2023. È l'equivalente in termini di AIMS dell'ISMS della ISO 27001. La norma da sola non soddisfa l'AI Act, l'Act presenta requisiti tecnici specifici di prodotto, ma fornisce la base del sistema di gestione che auditor e organismi notificati riconosceranno. Un tipico percorso di readiness: ISO 42001 Lead Implementer per costruire l'AIMS, poi mappare gli obblighi per l'alto rischio dell'AI Act sui controlli dell'AIMS, poi eseguire la valutazione di conformità per ciascun sistema rientrante nel perimetro. ### E i modelli di IA per finalità generali? Gli Articles 51-56 disciplinano i fornitori di modelli di IA per finalità generali. Obblighi di base: documentazione tecnica, informazioni per i fornitori a valle, politica di conformità al diritto d'autore, sintesi dei dati di addestramento. I modelli GPAI a rischio sistemico (attualmente quelli con potenza di calcolo cumulativa di addestramento superiore a 10^25 FLOP) affrontano obblighi più stringenti, tra cui valutazione del modello, valutazione e mitigazione del rischio sistemico, segnalazione degli incidenti. L'AI Office presso la Commissione europea emana un codice di buone pratiche che chiarisce gli obblighi GPAI. La maggior parte dei fornitori non di frontiera aderisce al codice anziché negoziare la conformità a partire dai principi primi. ## Official sources - [EUR-Lex, Regulation (EU) 2024/1689 (AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - [European Commission, AI Office](https://digital-strategy.ec.europa.eu/en/policies/ai-office) - [ISO, ISO/IEC 42001:2023](https://www.iso.org/standard/81230.html) --- # Resilienza operativa: DORA, NIS 2 e ISO 22301 in un unico luogo. **URL:** https://cyberacademy.net/it/resources/pillars/operational-resilience-dora-nis-2-iso-22301 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition La resilienza operativa è la capacità di un'organizzazione di erogare servizi critici durante una disruption e di recuperare in seguito. In Europa la governano tre framework: ISO 22301 (lo standard per il BCMS, il livello operativo), NIS 2 (l'obbligo di continuità operativa dell'Articolo 21 per le entità in ambito), DORA (Articoli 11-12 per le entità finanziarie, oltre a test dedicati). Un unico programma può soddisfare tutti e tre; gestirli come flussi di lavoro separati duplica gli sforzi e crea incongruenze. ## TL;DR - ISO 22301 è la spina dorsale operativa: BIA, obiettivi di ripristino, BCP, runbook, esercitazioni tabletop, BCMS sottoposto a riesame della direzione. - NIS 2 aggiunge la notifica degli incidenti (preallarme entro 24 ore, notifica entro 72 ore, relazione entro un mese) e la continuità della catena di fornitura. - DORA aggiunge i test specifici per le entità finanziarie (threat-led penetration testing per le entità significative ogni tre anni), il registro dei terzi ICT e la vigilanza a livello delle ESA per i fornitori critici. - Il corso Lead Operational Resilience Manager (credenziale PECB) è concepito specificamente per integrare i tre. - Mappa una volta, audit tre volte: un unico BCMS allineato a 22301 con le mappature dei controlli NIS 2 e DORA soddisfa tutti e tre gli audit. ## Full content ## Perché un solo programma, non tre L'istinto, nella maggior parte delle organizzazioni, è trattare ISO 22301, NIS 2 e DORA come tre progetti di conformità separati, spesso di proprietà di tre team diversi: continuità operativa, security operations e una funzione di regolamentazione finanziaria o di rischio. È il modo più costoso di procedere. Si finisce con tre analisi di impatto sul business che non concordano su quali servizi siano critici, tre serie di obiettivi di ripristino che nessuno riconcilia e tre calendari di esercitazioni che sfiniscono le stesse persone. Gli auditor notano subito le cuciture. I framework non sono concorrenti. ISO 22301 fornisce il sistema di gestione: la business impact analysis (BIA), gli obiettivi di tempo di ripristino e di punto di ripristino, i piani di continuità e di ripristino, le esercitazioni e il ciclo di riesame della direzione. NIS 2 e DORA non sostituiscono nulla di tutto ciò. Aggiungono obblighi al di sopra, principalmente in materia di notifica degli incidenti, garanzia sulla catena di fornitura e (per DORA) un regime di test specifico. Se il BCMS è costruito bene, i livelli regolamentari si agganciano a esso anziché duplicarlo. Costruisci prima la spina dorsale. Il corso ISO 22301 Lead Implementer è quello che insegna a realizzare il sistema di gestione a cui tutto il resto si aggancia; se devi soltanto comprendere la struttura e il vocabolario, parti dal corso ISO 22301 Foundation. ## Cosa aggiunge realmente ciascun framework Il modo onesto di leggere i tre è come un unico nucleo operativo più due livelli regolamentari sovrapposti. ISO 22301 è il nucleo perché è l'unico dei tre a prescrivere come costruire e mantenere la capacità di continuità stessa. NIS 2 e DORA presumono che tale capacità esista e poi impongono doveri al di sopra: chi devi avvisare quando qualcosa si rompe, con quale rapidità e come devi dimostrare che la capacità funziona. **Come si incastrano ISO 22301, NIS 2 e DORA** | Framework | Cosa aggiunge sopra il nucleo | A chi si applica | | --- | --- | --- | | ISO 22301 | Il sistema di gestione della continuità operativa in sé: BIA, RTO/RPO, piani di continuità e di ripristino, runbook, esercitazioni, riesame della direzione. La spina dorsale operativa che gli altri due presuppongono. | Qualsiasi organizzazione, su base volontaria. Certificabile ma non obbligatorio per legge. | | NIS 2 | Le tempistiche di notifica degli incidenti (preallarme, notifica, relazione finale), i doveri di continuità operativa e di gestione delle crisi, la sicurezza della catena di fornitura e la responsabilità della direzione. | Entità essenziali e importanti in settori specifici in tutta l'UE (energia, trasporti, sanità, infrastrutture digitali, pubblica amministrazione e altri). | | DORA | Resilienza ICT del settore finanziario: un programma di test di resilienza operativa digitale che include il threat-led penetration testing per le entità significative, il registro dei terzi ICT e la supervisione diretta dei fornitori ICT critici. | Entità finanziarie nell'UE (banche, assicuratori, imprese di investimento, prestatori di servizi per le cripto-attività) e i loro terzi ICT critici. | Leggi la tabella dall'alto verso il basso e il disegno diventa evidente. Implementi ISO 22301 una volta sola. NIS 2 e DORA ti dicono poi quali evidenze il regolatore vuole vedere da quell'unico sistema, e DORA aggiunge una disciplina di test che va oltre le esercitazioni tabletop previste da ISO 22301. ## Come funziona nelle operazioni In termini quotidiani, l'integrazione vive in tre artefatti, e farli bene è gran parte del lavoro. Il primo è un unico catalogo dei servizi e una BIA autorevoli. Decidi una volta sola quali servizi siano critici, qual è la loro tolleranza alla disruption e da cosa dipendono. Ogni framework attinge poi da quell'unica fonte. Se il tuo scoping NIS 2 e il tuo elenco delle funzioni critiche o importanti DORA non concordano con la tua BIA ISO 22301, hai già perso la discussione di audit prima ancora che cominci. Il secondo è una pipeline unificata degli incidenti. ISO 22301 vuole che tu rilevi, risponda e attivi i piani di continuità. NIS 2 e DORA vogliono che tu notifichi, a tempo, a un'autorità competente. Costruisci un unico processo di rilevazione e triage il cui output alimenti sia la risposta interna di continuità sia il flusso di lavoro della notifica regolamentare. L'orologio della notifica parte dal momento della consapevolezza, quindi il collo di bottiglia raramente è il piano di continuità; è la decisione se un evento sia notificabile e la rapidità nel redigere la notifica iniziale. Modelli di notifica predisposti e un titolare dell'escalation chiaramente individuato valgono qui più di qualsiasi strumento. Il terzo artefatto è il programma di test ed esercitazioni, ed è qui che DORA spinge con più forza. Le esercitazioni ISO 22301 convalidano i piani; DORA richiede un programma di test documentato e, per le entità significative, threat-led penetration testing su un ciclo pluriennale. Il corso DORA Lead Manager copre il regime di test e il registro dei terzi ICT con la profondità che la regolamentazione richiede, mentre il corso Lead Operational Resilience Manager è quello concepito specificamente per gestire i tre framework come un unico programma. > **Mappa una volta, evidenzia tre volte** Mantieni un unico foglio di mappatura dei controlli che elenchi ogni controllo una sola volta e lo etichetti con le clausole che soddisfa (ISO 22301, NIS 2 Articolo 21, DORA Articoli 11-12). Quando un auditor di uno qualsiasi dei framework chiede evidenze, filtri per la loro etichetta e consegni gli stessi artefatti sottostanti. Questa singola abitudine è la differenza tra un audit sereno e tre frenetici. ## La decisione: certificare, allineare o entrambi Una domanda frequente è se serva la certificazione ISO 22301 per soddisfare NIS 2 o DORA. Non serve. Nessuna delle due regolamentazioni impone il certificato. Ma lo standard è il modello più ampiamente riconosciuto per la capacità che entrambe le regolamentazioni presuppongono, quindi la maggior parte dei team si allinea a ISO 22301 anche quando sceglie di non certificarsi. La decisione si divide nettamente: allinearsi a ISO 22301 per ottenere un BCMS coerente e difendibile; certificarsi in aggiunta solo se un cliente, una gara o un consiglio di amministrazione vuole una garanzia di terza parte su di esso. Se persegui il certificato, comprendi la prospettiva di audit da entrambi i lati del tavolo. Gli implementatori costruiscono il sistema; gli auditor verificano se regge. Per condurre l'audit di certificazione (interno o come organismo di certificazione), il corso ISO 22301 Lead Auditor insegna la metodologia di audit e come valutare un BCMS rispetto allo standard, che è anche il modo più rapido per imparare in base a quali evidenze sarà giudicato il tuo programma. ## Dove i programmi falliscono I fallimenti ricorrenti sono prevedibili, e quasi tutti derivano dal trattare i framework come separati anziché stratificati. 1. Tre BIA in disaccordo. Continuità, sicurezza e finanza valutano l'ambito della criticità ciascuna in modo diverso. Si risolve imponendo un'unica BIA che tutte e tre le funzioni sottoscrivano. 1. Piani che superano l'esercitazione ma falliscono nell'evento reale. Le esercitazioni tabletop che si limitano a scorrere una presentazione non dimostrano nulla. Testa l'attivazione, non la narrazione: esegui realmente il failover, ripristina realmente dal backup, raggiungi realmente le persone nella catena di chiamata. 1. Confondere le funzioni di continuità, ripristino e risposta agli incidenti. La continuità operativa mantiene il servizio in funzione, il disaster recovery ripristina la tecnologia e la risposta agli incidenti contiene la causa. Sono discipline distinte che devono passarsi il testimone in modo pulito. 1. Mancare l'orologio della notifica. Il piano di continuità ha funzionato ma nessuno ha presentato il preallarme in tempo. La notifica regolamentare è un obbligo separato e a tempo limitato e necessita di un proprio titolare. 1. Trattare la gestione delle crisi come un ripensamento. Quando un incidente degenera, il punto di fallimento è il processo decisionale, non il ripristino tecnico. Due di questi fallimenti hanno rimedi dedicati. Il corso Lead Disaster Recovery Manager separa il ripristino tecnologico dalla continuità operativa, così i due smettono di essere confusi, e il corso Certified Lead Crisis Manager costruisce la struttura di comando, comunicazione e decisione che regge quando un incidente diventa una crisi. ## La realtà della sala di audit Ciò che un valutatore di uno qualsiasi dei tre framework sta realmente sondando è se la tua resilienza sia reale o di carta. Chiederà la BIA e poi chiederà chi l'ha approvata e quando è stata riesaminata l'ultima volta. Chiederà la tua ultima esercitazione e poi chiederà cosa è fallito e cosa hai cambiato di conseguenza, perché un'esercitazione senza rilievi è un campanello d'allarme, non un certificato di buona salute. Per le entità DORA, chiederà il programma di test e il registro dei terzi e si aspetterà che entrambi siano aggiornati, non ricostruiti la settimana prima. I team che superano l'audit con serenità sono quelli che gestiscono un unico programma: una BIA, una pipeline degli incidenti che alimenta sia la risposta interna sia la notifica regolamentare, un calendario di esercitazioni che rompe davvero le cose e un'unica mappatura dei controlli che consente loro di rispondere a tre regolatori dalla stessa base di evidenze. Costruisci bene la spina dorsale ISO 22301, sovrapponi a essa con intenzionalità gli obblighi NIS 2 e DORA, e la frase che dovrebbe descrivere i tuoi audit è: mappa una volta, audit tre volte. ## FAQ ### Ho bisogno della certificazione ISO 22301 ai sensi di NIS 2 o DORA? No. Né NIS 2 né DORA impongono la certificazione ISO 22301. Entrambi richiedono che l'organizzazione operi capacità di continuità operativa e di resilienza che raggiungano determinati risultati (recuperare entro i tempi concordati, notificare gli incidenti entro le scadenze, testare i piani). Un BCMS conforme a ISO 22301 dimostra in modo chiaro tali capacità a un'autorità di vigilanza. Nella pratica, le entità finanziarie e gli operatori di importanza vitale perseguono spesso la certificazione ISO 22301 perché le evidenze di audit richieste da NIS 2 e DORA corrispondono quasi esattamente alle evidenze della certificazione. ### Qual è la relazione tra BCP, DR e risposta agli incidenti? Tre discipline che si sovrappongono. I Business Continuity Plan (BCP) riguardano come l'azienda continua a operare durante una disruption: personale, sedi alternative, soluzioni provvisorie, comunicazione. Il Disaster Recovery (DR) riguarda il ripristino specifico dei sistemi e dei dati IT. La Incident Response (IR) riguarda il ciclo dalla rilevazione al ripristino degli incidenti di sicurezza. Un programma maturo le gestisce come un'unica cosa. Lo stesso playbook procede dalla rilevazione dell'incidente (IR) al ripristino dei sistemi (DR) alla continuazione delle operazioni aziendali (BCP). Team diversi possono eseguire fasi diverse, ma il piano è integrato. ### Che cos'è il threat-led penetration testing ai sensi di DORA? Il TLPT è l'esercitazione di red team supervisionata dal regolatore richiesta per le entità finanziarie significative ai sensi di DORA, almeno ogni tre anni. Si basa su TIBER-EU. È guidato dall'intelligence (un team separato di threat intelligence produce il profilo dell'attaccante), prende di mira funzioni critiche o importanti ed è supervisionato dall'autorità nazionale. Il TLPT è un lavoro che dura più mesi e costa diverse centinaia di migliaia di euro. È il test di resilienza più rigoroso che un CISO del settore finanziario dovrà affrontare, e quello che espone il SOC, le regole di rilevazione e la catena di risposta agli incidenti per ciò che realmente sono. ### Come strutturo un unico programma di resilienza? Si parte dal BCMS (la spina dorsale ISO 22301): ambito, BIA, obiettivi di ripristino, piani, test, riesame della direzione. Si aggiungono le procedure di notifica degli incidenti NIS 2 e gli obblighi di continuità della catena di fornitura derivanti dall'Articolo 21. Si aggiunge il calendario di test specifico di DORA, il registro dei terzi ICT e la classificazione degli incidenti per le entità finanziarie. Si mappano i controlli in un unico documento di mappatura che indica quale clausola di quale framework ciascun controllo soddisfa. Gli auditor riconoscono la mappatura e smettono di porre domande duplicate. ## Official sources - [ISO, ISO 22301:2019 Business continuity management](https://www.iso.org/standard/75106.html) - [EUR-Lex, Directive (EU) 2022/2555 (NIS 2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) - [EUR-Lex, Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) --- # GDPR nel 2026: cosa è cambiato dal 2018. **URL:** https://cyberacademy.net/it/resources/pillars/gdpr-2026 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition Nel 2026 il GDPR resta il regolamento UE che disciplina i dati personali (Regulation (EU) 2016/679, in vigore da maggio 2018). Cosa è cambiato dal 2018: il quadro dei trasferimenti internazionali (Schrems II, nuove SCC, EU-US Data Privacy Framework), l'intensità dell'enforcement (CNIL, DPC, AEPD come autorità più attive), l'interazione con l'AI Act sul trattamento automatizzato e i chiarimenti della CJEU su consenso, legittimo interesse e diritto all'oblio. ## TL;DR - Il GDPR in sé non è stato modificato. Ciò che si è mosso è la giurisprudenza, le linee guida dell'EDPB, le SCC e il quadro dei trasferimenti internazionali. - Schrems II ha invalidato il Privacy Shield nel 2020. L'EU-US Data Privacy Framework (DPF) lo ha sostituito a luglio 2023; i trasferimenti verso importatori statunitensi certificati DPF non necessitano più di misure supplementari. - Le SCC del 2021 hanno sostituito le versioni del 2010. Ogni trasferimento al di fuori dello SEE senza una decisione di adeguatezza richiede un Transfer Impact Assessment documentato. - L'enforcement dell'EDPB e delle autorità nazionali è a un'intensità record. Casi principali 2023-2025: Meta (1,2 miliardi di euro, trasferimenti), LinkedIn (310 milioni di euro, pubblicità comportamentale), Clearview AI (più autorità). - Interazione con l'AI Act: i sistemi di IA ad alto rischio che trattano dati personali devono rispettare entrambi i regimi. DPIA + valutazione di conformità all'AI Act insieme. ## Full content ## Perché il testo è rimasto fermo e la pratica si è mossa Il GDPR non è stato riscritto. I numeri di articolo che hai imparato nel 2018 sono i numeri di articolo che applichi nel 2026. Ciò che è cambiato sta un livello più in basso: la giurisprudenza che interpreta il testo, le linee guida dell'EDPB che lo rendono operativo, le standard contractual clauses che formalizzano i tuoi trasferimenti e il meccanismo di adeguatezza che governa dove i dati possono legalmente atterrare. Un programma privacy costruito nel 2018 e mai più toccato non è sbagliato sulla carta. È obsoleto nella pratica, e l'obsoleto è ciò che l'enforcement ora individua. Questa pagina è per chi già comprende il regolamento e ha bisogno di sapere cosa aggiornare. Presuppone che tu sappia definire un dato personale, un titolare e una base giuridica. Si concentra sulle quattro parti in movimento che nel 2026 generano realmente rilievi: i trasferimenti internazionali, il Transfer Impact Assessment, la sovrapposizione con l'AI Act e la questione se sia obbligatorio o meno nominare un Data Protection Officer. ## Trasferimenti internazionali: l'albero decisionale, non il titolo di giornale La maggior parte dei team conosce i titoli. Schrems II ha invalidato il Privacy Shield nel 2020. L'EU-US Data Privacy Framework lo ha sostituito nel 2023. Le SCC del 2021 hanno sostituito le versioni del 2010. I titoli sono veri e quasi inutili presi da soli, perché il lavoro vero consiste nell'abbinare uno specifico trasferimento a uno specifico strumento e poi decidere se in aggiunta sia richiesto un Transfer Impact Assessment. È un albero decisionale, e lo percorri per ciascun flusso di dati, non una volta sola per l'intera azienda. Parti dalla destinazione. Se l'importatore si trova in un paese con una decisione di adeguatezza UE in vigore, trasferisci sulla base della decisione di adeguatezza e per quel flusso non ti servono SCC né una TIA. Se la destinazione sono gli Stati Uniti e l'importatore è auto-certificato nell'ambito del Data Privacy Framework per le categorie di dati pertinenti, quel flusso si appoggia al DPF come propria base di adeguatezza: niente SCC, niente misure supplementari. Nel momento in cui esci da entrambe queste ipotesi, ricadi nelle garanzie dell'Article 46, il che nella pratica significa le SCC del 2021, e le SCC comportano un obbligo di TIA che Schrems II ha reso non facoltativo. **Scenario di trasferimento, strumento richiesto e se si applica una TIA** | Scenario di trasferimento | Strumento necessario | TIA richiesta? | | --- | --- | --- | | Dallo SEE verso un paese con una decisione di adeguatezza in vigore | Decisione di adeguatezza (nessun contratto aggiuntivo) | No | | Dallo SEE verso un importatore statunitense auto-certificato DPF, per i dati coperti | Certificazione DPF (funge da adeguatezza) | No | | Dallo SEE verso un importatore statunitense NON aderente al DPF | SCC del 2021 | Sì | | Dallo SEE verso un paese terzo non adeguato (caso generale) | SCC del 2021 | Sì | | Trasferimenti infragruppo tra molte entità e paesi | Binding Corporate Rules (o SCC) | Sì (valutata per ciascuna destinazione) | | Trasferimento successivo del tuo responsabile verso un proprio sub-responsabile all'estero | SCC a cascata nella catena dei responsabili | Sì (la catena eredita l'obbligo) | > **Il DPF non è un lasciapassare generale per gli USA** Che un fornitore statunitense sia "presente nell'elenco DPF" non significa che ogni flusso verso di esso sia coperto. La certificazione è circoscritta a specifiche categorie di dati e alle organizzazioni presenti nell'elenco attivo. Verifica che l'importatore sia attualmente certificato per i dati che stai inviando e tieni pronto un fallback con SCC, perché una decisione di adeguatezza può essere contestata e sospesa, come è accaduto al Privacy Shield. Una contestazione in corso al DPF in stile Schrems è esattamente il rischio attorno al quale un programma resiliente si organizza. ## Il Transfer Impact Assessment nella pratica operativa Una TIA è il documento che risponde a una sola domanda: la legge e la prassi del paese di destinazione compromettono la protezione che le tue SCC promettono sulla carta? Non è una casella da spuntare. È una piccola analisi giuridico-tecnica che produci per ciascun trasferimento (o per ciascun gruppo di trasferimenti sostanzialmente identici) e che conservi agli atti per il giorno in cui un'autorità di controllo te la chiederà. Nella pratica, una TIA difendibile fa quattro cose. Descrive il trasferimento in modo concreto: chi esporta, chi importa, quali dati, quale volume, quale finalità. Valuta il regime giuridico di destinazione, con particolare attenzione ai poteri di accesso governativo e alla possibilità per un interessato di disporre di un rimedio effettivo. Individua le misure supplementari ove il regime giuridico sia debole, e la misura che sposta davvero l'ago della bilancia è la cifratura che controlli tu, dove l'importatore non detiene mai le chiavi. E registra una conclusione motivata: procedere, procedere con misure o non trasferire. 1. Mappa il flusso con precisione, inclusi gli eventuali trasferimenti successivi che il tuo responsabile effettua verso i sub-responsabili. I flussi che dimentichi sono quelli che riemergono in caso di violazione. 1. Valuta la legge di destinazione rispetto ai criteri dell'EDPB, non secondo la tua impressione istintiva sul paese. 1. Applica le misure supplementari dove necessario e tratta una cifratura robusta, con chiavi gestite da te, come misura tecnica predefinita anziché affidarti alle sole promesse contrattuali. 1. Documenta la conclusione e datala, poi imposta un trigger di revisione affinché non scada silenziosamente. > **Collega la TIA al tuo RoPA, non a una cartella** I team che superano gli audit sui trasferimenti senza intoppi sono quelli il cui Record of Processing Activities segnala ogni flusso che lascia lo SEE, e ciascun flusso segnalato rimanda a una TIA aggiornata. Quando il registro e le valutazioni sono collegati, "mostrami i tuoi trasferimenti" richiede minuti. Quando vivono in drive separati, richiede una settimana di panico e di solito fa emergere un flusso non documentato. ## Dove il GDPR incontra l'AI Act L'AI Act non sostituisce il GDPR e non lo allenta. Quando un sistema di IA tratta dati personali, si applicano entrambi pienamente e devi soddisfare entrambi. Il modo più chiaro per cogliere la sovrapposizione è ragionare per artefatto che ciascun regime si attende. Il GDPR richiede una Data Protection Impact Assessment quando il trattamento è suscettibile di presentare un rischio elevato per le persone. L'AI Act richiede una valutazione di conformità, la documentazione tecnica e (per alcuni sistemi) una valutazione d'impatto sui diritti fondamentali per l'IA ad alto rischio. Si tratta di documenti diversi che rispondono a domande diverse, e un sistema di IA ad alto rischio che tocca dati personali ne richiede entrambi, coerenti tra loro. I punti di attrito sono familiari problemi del GDPR in vesti nuove. Le decisioni automatizzate con effetti giuridici o analogamente significativi già facevano scattare gli obblighi dell'Article 22; l'AI Act vi sovrappone doveri di trasparenza e di sorveglianza umana. I dati di addestramento sollevano questioni di base giuridica e di limitazione delle finalità che non svaniscono perché l'output è un modello. La profilazione e l'inferenza sono sempre rientrate nell'ambito di applicazione. La regola pratica per il 2026: non gestire un flusso di lavoro sulla governance dell'IA che ignori il tuo DPO, e non gestire un programma privacy che finga che l'addestramento dei modelli sia un problema di qualcun altro. Le due valutazioni dovrebbero rimandare l'una all'altra. I privacy engineer che devono fare da ponte tra questi regimi nelle decisioni di realizzazione sono esattamente il pubblico della certificazione CDPSE, strutturata attorno a governance, architettura e ciclo di vita dei dati anziché al solo testo giuridico. Per rendere operativa la privacy come sistema di gestione che si affianca in modo pulito a un ISMS, il corso ISO 27701 Foundation copre il modello PIMS, e il corso ISO 27701 Lead Implementer ti guida nella sua costruzione e gestione. ## L'enforcement è un segnale, non solo un rischio Leggi l'enforcement recente come una mappa di dove guardano le autorità, perché ti indicano dove probabilmente si trova la tua stessa esposizione. Lo schema dal 2023 al 2025 è coerente. I trasferimenti internazionali hanno prodotto le singole sanzioni più elevate, con la decisione Meta (1,2 miliardi di euro) incentrata sui flussi di dati EU-US. La pubblicità comportamentale e la base giuridica per il targeting pubblicitario hanno determinato la decisione LinkedIn (310 milioni di euro). I dati biometrici raccolti tramite scraping hanno motivato azioni ripetute contro Clearview AI presso più autorità. Le autorità attive sono quelle che ci si aspetterebbe: la CNIL in Francia, la DPC in Irlanda per le grandi piattaforme, l'AEPD in Spagna. La conseguenza operativa è smettere di trattare l'enforcement come il titolo di giornale di qualcun altro. Se trasferimenti, consenso nell'ad-tech e trattamenti biometrici o contigui all'IA sono i terreni dove cadono le sanzioni, quelli sono i tre fascicoli su cui statisticamente è più probabile che un'autorità di controllo ti interroghi. Un programma in grado di produrre una TIA aggiornata, un registro del consenso difendibile e una DPIA per i suoi trattamenti più rischiosi è un programma che supera le domande effettivamente poste. ## Hai davvero bisogno di un DPO? La questione del DPO è quella a cui più spesso si risponde per riflesso anziché sulla base del testo. L'Article 37 rende un DPO obbligatorio in tre situazioni: sei un'autorità pubblica o un organismo pubblico; le tue attività principali consistono nel monitoraggio regolare e sistematico degli interessati su larga scala; oppure le tue attività principali consistono nel trattamento su larga scala di categorie particolari di dati o di dati relativi a condanne penali. Se nessuna di queste si applica, il GDPR non impone la nomina, sebbene alcune leggi nazionali aggiungano propri criteri di attivazione e un DPO volontario sia spesso la scelta più solida. L'espressione che decide la maggior parte dei casi concreti è "attività principali". Un ospedale monitora i dati sanitari come propria attività principale, quindi ha bisogno di un DPO. Un'azienda manifatturiera che gestisce le buste paga tratta dati personali, ma si tratta di una funzione di supporto, non di un'attività principale, quindi la sola gestione delle buste paga non fa scattare l'obbligo. Gli errori si concentrano ai margini: nominare qualcuno privo dell'indipendenza e della linea di riporto richieste dall'Article 38, designare un DPO che ha un conflitto di interessi perché possiede anche il trattamento che dovrebbe sorvegliare, oppure nominarlo sulla carta senza conferirgli alcuna autorità. Un DPO che non può raggiungere il consiglio di amministrazione e non può dire di no è un rilievo in attesa di essere scritto. Se il ruolo spetta a te ricoprirlo o sorvegliarlo, la profondità conta. Il corso GDPR Foundation è il giusto punto di partenza per il team attorno al ruolo, e il corso GDPR Certified Data Protection Officer è pensato per la persona che porta il titolo, coprendo l'indipendenza, i compiti e la responsabilità che il regolamento effettivamente richiede. ## Cosa aggiornare prima del prossimo audit Porta a giorno le parti in movimento e il resto del programma in gran parte si regge da solo. Verifica che ogni trasferimento sia sulle SCC del 2021 e non sul set ritirato del 2010, perché le clausole legacy sono un rilievo immediato. Controlla che ogni trasferimento non adeguato abbia una TIA datata, collegata dal tuo RoPA. Verifica che ogni fornitore statunitense su cui ti affidi sia attualmente certificato DPF per i dati che invii e che tu disponga di un fallback con SCC qualora non lo sia. Assicurati che i tuoi trattamenti a rischio più elevato abbiano una DPIA e che qualunque trattamento basato sull'IA abbia accanto gli artefatti dell'AI Act. Infine, riverifica la questione del DPO rispetto alle tue effettive attività principali, anziché rispetto alla risposta che hai dato nel 2018. > **La realtà della sala d'audit** Le autorità di controllo raramente contestano alle organizzazioni l'esistenza di un trasferimento o di un sistema di IA. Contestano l'assenza del documento che dimostra che la decisione è stata presa deliberatamente. La risposta difendibile a quasi ogni domanda difficile è "ecco la valutazione, ecco la data, ecco chi l'ha firmata." Un programma in grado di produrre queste tre cose su richiesta sta facendo il proprio lavoro; uno che non ci riesce è esposto, per quanto accurata sia la sua gestione quotidiana. ## FAQ ### Ho ancora bisogno delle SCC dopo l'adozione dell'EU-US DPF? Per i trasferimenti verso importatori statunitensi auto-certificati nell'ambito dell'EU-US Data Privacy Framework, no: la decisione di adeguatezza di luglio 2023 copre tali trasferimenti. Verifica la certificazione dell'importatore nell'elenco DPF del Department of Commerce. Per i trasferimenti verso importatori statunitensi non aderenti al DPF, o verso qualsiasi altro paese terzo privo di decisione di adeguatezza, sono necessarie le SCC del 2021 (o un altro strumento di trasferimento) più un Transfer Impact Assessment. ### Cos'è un Transfer Impact Assessment e quando ne ho bisogno? Una TIA è l'analisi documentata richiesta dopo Schrems II per ogni trasferimento di dati personali al di fuori dello SEE senza una decisione di adeguatezza. Valuta se le leggi del paese di destinazione garantiscano un livello di protezione sostanzialmente equivalente a quello assicurato all'interno dell'UE e, in caso contrario, individua le misure supplementari. Ti serve una TIA per ciascun trasferimento di questo tipo, su base di singolo flusso di trasferimento. Le Recommendations 01/2020 dell'EDPB ne forniscono la metodologia. La maggior parte delle organizzazioni che utilizzano fornitori SaaS extra-UE sottovaluta il lavoro della TIA e si affida al modello del fornitore, che da solo non è giuridicamente sufficiente. ### In che modo l'AI Act interagisce con il GDPR? L'AI Act è un livello aggiuntivo rispetto al GDPR, non un sostituto. Quando i sistemi di IA ad alto rischio trattano dati personali, si applicano entrambi i regolamenti: il GDPR per la base giuridica, i diritti degli interessati, la DPIA, il quadro dei trasferimenti internazionali; l'AI Act per la valutazione di conformità, la gestione del rischio, la documentazione tecnica, la sorveglianza umana. Nella pratica, le organizzazioni integrano la DPIA e la valutazione di conformità all'AI Act in un unico documento ove possibile, per evitare lavoro duplicato e trattamenti del rischio incoerenti. ### Quali tendenze di enforcement dovrei monitorare? Tre tendenze dal 2022: (1) le autorità di controllo cooperano sempre di più (decisioni one-stop-shop, indagini congiunte), con la DPC irlandese ancora in prima linea sui casi transfrontalieri contro le big tech statunitensi, ma con le decisioni vincolanti dell'EDPB che ne rafforzano la mano; (2) sanzioni rilevanti sulla pubblicità comportamentale e sui dark pattern (Meta, LinkedIn, Amazon, Google); (3) enforcement su cookie e tecnologie di tracciamento ai sensi della ePrivacy Directive (CNIL particolarmente attiva). Aspettati che la tendenza prosegua: più decisioni vincolanti transfrontaliere, un esame più severo del legittimo interesse come base per il trattamento comportamentale e una crescente attenzione ai trattamenti legati all'IA ai sensi dell'Article 22 del GDPR (decisioni automatizzate). ### La mia organizzazione ha bisogno di un DPO? Gli Articles 37 to 39 del GDPR richiedono un DPO quando: (a) il titolare o il responsabile è un'autorità pubblica o un organismo pubblico; (b) le attività principali richiedono un monitoraggio regolare e sistematico degli interessati su larga scala; (c) le attività principali consistono nel trattamento su larga scala di categorie particolari di dati o di dati personali relativi a condanne penali. Al di là dell'obbligo di legge, molte organizzazioni del settore privato nominano un DPO su base volontaria per ragioni di gestione del rischio. I DPO a livello di gruppo sono ammessi e diffusi nelle multinazionali; devono restare facilmente accessibili agli interessati e all'autorità di controllo. ## Official sources - [EUR-Lex, Regulation (EU) 2016/679 (GDPR)](https://eur-lex.europa.eu/eli/reg/2016/679/oj) - [European Data Protection Board](https://www.edpb.europa.eu/) - [CNIL, Guidance and decisions](https://www.cnil.fr/) --- # EBIOS RM e ISO 27005: il confronto. **URL:** https://cyberacademy.net/it/resources/pillars/ebios-rm-vs-iso-27005 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition EBIOS Risk Manager è il metodo nazionale francese di valutazione del rischio pubblicato da ANSSI, incentrato su scenari strategici di attacco cyber. ISO/IEC 27005 è lo standard internazionale di gestione del rischio per la sicurezza delle informazioni, allineato a ISO 31000 e usato come livello metodologico per il lavoro sull'ISMS di ISO 27001. Entrambe sono metodologie operative; sono complementari più che alternative. ## TL;DR - EBIOS RM è strategico e guidato dagli scenari. Mappa i processi di business sugli obiettivi degli attaccanti, poi ne deriva i controlli tecnici. È forte nel settore pubblico francese e tra gli operatori di importanza vitale. - ISO 27005 è indipendente dalla metodologia e si abbina nativamente all'Annex A di ISO 27001. È lo standard negli audit internazionali. - EBIOS RM produce un numero ridotto di scenari ad alto impatto con una narrativa ricca. ISO 27005 produce un registro dei rischi completo. - Entrambe sono credenziali PECB accreditate: EBIOS Risk Manager (5 giorni), ISO/IEC 27005 Risk Manager (5 giorni). Il livello Lead Risk Manager esiste solo per ISO 31000. - Nella pratica: ISO 27005 per il registro dei rischi dell'ISMS, EBIOS RM come complemento per individuare gli scenari strategici che meritano l'attenzione del consiglio di amministrazione. ## Full content ## Come funziona realmente ciascun metodo in un progetto La divisione tra i due metodi non è una questione di qualità; è una questione di punto di partenza. ISO 27005 parte dagli asset e dalle minacce e procede verso l'esterno fino a un registro dei rischi completo. EBIOS RM parte da ciò che l'organizzazione teme di perdere e procede a ritroso attraverso l'attaccante che causerebbe quella perdita. I due producono artefatti diversi perché pongono domande di partenza diverse, e quella differenza è ciò che percepiranno il tuo auditor, il tuo consiglio e il tuo piano di progetto. Il lavoro con ISO 27005 è iterativo ed esaustivo per progettazione. Stabilisci il contesto, identifichi i rischi su tutto il perimetro, analizzi probabilità e conseguenza, valuti rispetto ai criteri di accettazione, poi tratti. L'output è un registro vivo che riesegui a cadenza ciclica. È il motore di rischio naturale per un ISMS di ISO 27001 perché parla la stessa lingua del sistema di gestione: perimetro, criteri, piano di trattamento, rischio residuo, approvazione. EBIOS RM si svolge in cinque workshop con una sequenza definita: inquadramento e fondamenti di sicurezza, origini del rischio, scenari strategici, scenari operativi e trattamento del rischio. Il metodo ti obbliga a nominare prima gli eventi temuti, poi le fonti di rischio (chi attaccherebbe e perché), poi i percorsi di attacco ad alto livello, prima ancora di toccare un controllo. Il corso EBIOS Risk Manager percorre ogni workshop con deliverable reali, così esci capace di facilitare la sequenza, non solo di descriverla. ## EBIOS RM e ISO 27005 a colpo d'occhio La tabella seguente è il confronto di cui la maggior parte dei team ha bisogno nella stanza: non la filosofia, ma su cosa si concentra ciascun metodo, cosa ti consegna alla fine e dove è effettivamente atteso. **EBIOS RM e ISO 27005: focus, output e dove ciascuno è atteso** | Dimensione | EBIOS RM | ISO 27005 | | --- | --- | --- | | Origine | Metodo nazionale francese, pubblicato da ANSSI | Standard internazionale, ISO/IEC, allineato a ISO 31000 | | Focus | Scenari strategici di attacco; poste in gioco di business mappate sulle fonti di minaccia | Identificazione sistematica del rischio della sicurezza delle informazioni su tutto il perimetro | | Punto di partenza | Eventi temuti e origini del rischio (top-down) | Asset, minacce, vulnerabilità (bottom-up) | | Output | Un piccolo insieme di scenari narrativi ad alto impatto con strategia di trattamento | Un registro dei rischi completo e ripetibile con piano di trattamento | | Granularità | Pochi scenari, narrativa approfondita, leggibile dal consiglio | Molti rischi, strutturati, leggibili dall'ISMS | | Relazione con ISO 27001 | Complemento; alimenta i rischi strategici nell'ISMS | Livello metodologico nativo per il Clause 6.1.2 e l'Annex A | | Dove è atteso | Settore pubblico francese, OIV/OES, appalti di influenza ANSSI | Audit internazionali, ISMS multinazionali, assicurazione verso i clienti | | Credenziale accreditata | PECB EBIOS Risk Manager (5 giorni) | PECB ISO/IEC 27005 Risk Manager (5 giorni) | ## Come entrambi si raccordano a ISO 27001 ISO 27001 richiede un processo definito di valutazione e trattamento del rischio della sicurezza delle informazioni, ma non impone un metodo specifico. È proprio questo fatto a giustificare l'esistenza di questo confronto. Il Clause 6.1.2 ti dice di valutare il rischio e di produrre uno Statement of Applicability; non ti dice di usare ISO 27005 o altro. Gli auditor verificano che il tuo processo sia coerente, ripetibile e produca decisioni di trattamento difendibili. Il metodo è una tua scelta. ISO 27005 è qui la via di minor resistenza perché è stato scritto per essere il livello metodologico sotto lo standard. La sua terminologia, la sua logica dei criteri di accettazione e la sua struttura del piano di trattamento si inseriscono direttamente nell'ISMS senza traduzioni. Se stai costruendo o gestendo il sistema di gestione, impara il motore che gli si adatta: il corso ISO/IEC 27005 Risk Manager copre l'intero ciclo di valutazione e trattamento, mentre il corso ISO/IEC 27005 Foundation è il giusto punto d'ingresso se hai bisogno dei concetti prima di facilitare. EBIOS RM si raccorda allo stesso clause da un'angolazione diversa. Non sostituisce il registro; ne affina la parte superiore. Gli scenari strategici diventano il piccolo insieme di rischi che giustifica il massimo scrutinio nella SoA e nel dossier per il consiglio. I team che hanno bisogno di padroneggiare la metodologia dall'inizio alla fine, inclusi la governance della valutazione e il ruolo di lead a livello di organizzazione, seguono il corso ISO/IEC 27005 Lead Risk Manager. > **ISO 27001 non richiede ISO 27005** Il Clause 6.1.2 impone un processo di rischio, non un metodo nominato. Puoi usare EBIOS RM, ISO 27005, un metodo interno o una combinazione, purché sia documentato, ripetibile e produca decisioni di trattamento tracciabili. Gli auditor verificano il processo, non il marchio. ## La decisione: quale dei due, e quando entrambi La maggior parte dei team imposta la cosa come un aut-aut e poi se ne pente. La risposta onesta è che la domanda ha due livelli: cosa richiedono il tuo audit o il tuo settore, e cosa serve davvero al tuo quadro di rischio. Risolvili in quest'ordine. 1. Se è in gioco un acquirente di influenza ANSSI, un contratto pubblico francese o un obbligo OIV/OES, EBIOS RM è il linguaggio atteso. Mettilo in primo piano per il livello strategico. 1. Se la tua assicurazione deriva da un certificato ISO 27001 internazionale o da audit di clienti multinazionali, ISO 27005 è l'impostazione predefinita che l'auditor legge con scioltezza. 1. Se hai un problema reale di avversari (un bersaglio di alto valore, un servizio critico regolamentato, un rischio cyber a livello di consiglio), esegui EBIOS RM sopra il registro per far emergere gli scenari che meritano un'escalation. 1. Se non hai né un mandato del settore francese né un profilo di avversari acuto, ISO 27005 da sola è sufficiente e più economica da gestire. Eseguire entrambi non è ridondante se ne definisci correttamente il perimetro. ISO 27005 ti dà ampiezza: ogni rischio nel registro, trattato e monitorato. EBIOS RM ti dà profondità sui pochi scenari che farebbero davvero male. L'errore è eseguire entrambi alla stessa granularità, il che raddoppia il lavoro e produce due registri che nessuno riconcilia. Usa EBIOS RM per selezionare e narrare; usa ISO 27005 per enumerare e monitorare. > **Definisci di proposito un perimetro ristretto per EBIOS RM** EBIOS RM è più prezioso quando lo punti su un perimetro piccolo e ad alta posta in gioco: il servizio gioiello della corona, la funzione la cui perdita è un evento da consiglio. Puntato sull'intera organizzazione diventa lento e diluisce la propria forza. Lascia che ISO 27005 porti l'ampiezza e riserva EBIOS RM agli scenari che giustificano una narrativa. ## Errori comuni e la realtà della stanza dell'audit I fallimenti sono prevedibili, e raramente riguardano il metodo in sé. - Scegliere il metodo per preferenza anziché per pubblico. La domanda giusta è chi legge l'output: un acquirente pubblico francese si aspetta il vocabolario di EBIOS RM, un auditor di certificazione internazionale si aspetta un registro nella forma di ISO 27005. Scegli in base al lettore. - Trattare gli scenari di EBIOS RM come un sostituto di un registro completo. Gli scenari strategici sono volutamente pochi. Un auditor che verifica la copertura di ISO 27001 chiederà dove sia documentato il resto del panorama di rischio, e una manciata di narrazioni non è una risposta. - Eseguire ISO 27005 come un foglio di calcolo una tantum. Lo standard è iterativo. Un registro datato diciotto mesi fa senza una cadenza di revisione è un rilievo pronto a verificarsi. - Confondere le credenziali. Non esiste un Lead Auditor né un Lead Risk Manager per EBIOS RM, e l'unica credenziale Lead Risk Manager rientra sotto ISO 31000, non ISO 27005. Pianifica il percorso di certificazione del tuo team in base a ciò che esiste realmente. Nella stanza dell'audit, la realtà è più semplice di quanto suggerisca il dibattito. L'auditor di certificazione non valuta il tuo metodo contro un rivale; verifica se il processo che hai scelto è documentato, applicato in modo coerente e tracciabile dal rischio al trattamento fino all'accettazione del residuo. EBIOS RM ti aiuta a spiegare perché rischi specifici ad alto impatto hanno ricevuto un'attenzione specifica. ISO 27005 ti aiuta a dimostrare che nulla è sfuggito attraverso le falle. La postura più forte, per le organizzazioni che hanno genuinamente bisogno di entrambi, è un registro ISO 27005 come sistema di registrazione, con gli scenari di EBIOS RM stratificati sopra per giustificare le decisioni che hanno contato di più. ## FAQ ### Quale dei due si aspetta il mio auditor? Per un audit di certificazione ISO 27001, l'auditor si aspetta per impostazione predefinita una metodologia allineata a ISO/IEC 27005. La revisione 2022 di ISO 27005 crea esplicitamente un ponte verso il Clause 6 di ISO 27001 e verso i principi di ISO 31000. Per gli audit del settore pubblico francese (HFDS, ispezioni ANSSI degli operatori di importanza vitale ai sensi della LPM, vigilanza NIS 2 da parte di ANSSI), EBIOS RM è il linguaggio atteso. La mancata articolazione degli scenari strategici nel vocabolario di EBIOS RM verrà segnalata. ### Posso usarli entrambi contemporaneamente? Sì, e molte organizzazioni lo fanno. EBIOS RM produce da 5 a 10 scenari strategici di attacco con fonti di minaccia nominate, asset di business ed eventi temuti; questi diventano gli input per un registro dei rischi ISO 27005 che gestisce il livello operativo (combinazioni vulnerabilità-asset, valutazione probabilità-impatto, opzioni di trattamento). La combinazione funziona perché EBIOS RM opera a livello di scenario (adatto al consiglio) mentre ISO 27005 opera a livello di asset/controllo (adatto all'audit). Raccordare i due richiede disciplina ma è terreno ben battuto nelle entità francesi soggette sia alla vigilanza ANSSI sia alla certificazione ISO 27001. ### EBIOS RM è rilevante solo in Francia? Per lo più sì. Al di fuori della Francia, ISO 27005 è la lingua franca per la metodologia di rischio dell'ISMS. EBIOS RM è riconosciuto da ENISA in alcune pubblicazioni e usato da giurisdizioni di influenza francese, ma raramente lo incontrerai negli audit fuori dalla Francia o dall'Africa francofona. Se la tua impronta di audit è puramente internazionale, ISO 27005 è la scelta singola più sicura. Se operi in Francia, nel settore pubblico o vendi a enti statali francesi, la padronanza di EBIOS RM è attesa. ### Cosa copre la credenziale PECB EBIOS Risk Manager? Cinque giorni. Copre i cinque workshop di EBIOS RM: perimetro e fondamenti di sicurezza, origini del rischio, scenari strategici, scenari operativi, trattamento del rischio. L'esame è a libro aperto, dura tre ore, con un mix di domande a risposta multipla e domande su scenari. La credenziale è riconosciuta da ANSSI tramite il percorso di accreditamento PECB Gold Partner. Non sostituisce ISO/IEC 27005 Risk Manager se il tuo auditor si aspetta la metodologia ISO; la completa. ## Official sources - [ANSSI, EBIOS Risk Manager method](https://cyber.gouv.fr/la-methode-ebios-risk-manager) - [ISO, ISO/IEC 27005:2022](https://www.iso.org/standard/80585.html) --- # Il prezzo reale di un ISO 27001 Lead Implementer in Europa. **URL:** https://cyberacademy.net/it/resources/pillars/iso-27001-lead-implementer-price-europe **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition In Europa nel 2026, una sessione ISO 27001 Lead Implementer con docente ha un prezzo compreso tra 2.800 e 3.200 euro a posto per una formazione standard di 5 giorni, tutto incluso (corso, materiali PECB, costo di certificazione, esame, un ripasso d'esame). L'autoapprendimento costa dal 30% al 40% in meno. Le sessioni in-house hanno un prezzo da 12.000 a 18.000 euro per un massimo di 12 partecipanti. ## TL;DR - Standard con docente (sessione live online o in presenza), 5 giorni, tutto incluso: da 2.800 a 3.200 euro a posto. La variazione dipende dal livello del partner e dalla località, non dal programma. - Autoapprendimento (moduli registrati, materiali ufficiali PECB, esame incluso): da 1.700 a 2.200 euro. Completamento più lento, meno domande con risposta in tempo reale. - Sessione privata in-house, fino a 12 partecipanti, in presenza o virtuale: da 12.000 a 18.000 euro per i 5 giorni completi. Preventivo inviato entro un giorno lavorativo dalla pagina della formazione in-house. - I partner PECB Gold e Platinum hanno prezzi dal 5% al 15% superiori ai livelli inferiori, in cambio di una maggiore profondità di accreditamento e della garanzia di certificazione o rimborso, ove applicabile. - Attenzione al pacchetto: costo della formazione, costo di certificazione, costo dell'esame, ripasso d'esame, materiali, coaching post-sessione. Le offerte più economiche spesso escludono dal pacchetto il costo di certificazione. ## Full content ## Cosa stai realmente acquistando La cifra in evidenza su una pagina Lead Implementer è raramente la cifra che paghi. Il corso ti insegna a progettare e gestire un Information Security Management System rispetto ai controlli ISO 27001, ma la voce che determina il tuo costo reale è la credenziale di certificazione, non il posto in aula. Un preventivo credibile racchiude sei elementi: l'erogazione della formazione, i materiali ufficiali, il costo di certificazione, l'esame, almeno un ripasso d'esame e, idealmente, un supporto post-sessione. Quando un prezzo sembra basso, di solito uno di questi sei è stato spostato fuori dalla pagina e su una seconda fattura che ricevi in seguito. La credenziale che stai pagando si colloca un gradino sopra il livello foundation e un gradino sotto il percorso di audit. Se non hai mai lavorato all'interno di un ISMS, il corso ISO 27001 Foundation è il punto d'ingresso più economico e ti dice se il percorso implementer sia la spesa giusta. Se il tuo ruolo è valutare i sistemi di altri anziché costruire i tuoi, il percorso ISO 27001 Lead Auditor è quello da preventivare. ## Con docente, autoapprendimento o in-house: il vero compromesso Le tre modalità di erogazione non sono tre livelli di qualità. Sono tre risposte a una domanda diversa: di quanto accesso live a un docente hai bisogno e quante persone stai certificando contemporaneamente. La modalità con docente è adatta a un singolo partecipante che vuole le risposte alle domande in aula e una finestra fissa di cinque giorni che impone il completamento. L'autoapprendimento è adatto a un partecipante disciplinato disposto a rinunciare alle risposte live in cambio di un prezzo inferiore e di un calendario flessibile. L'in-house ha senso solo quando hai una sessione, perché il costo della sessione privata è fisso indipendentemente dal fatto che tu riempia quattro posti o dodici. **ISO 27001 Lead Implementer in Europa, 2026: modalità di erogazione, fascia di prezzo e cosa include la fascia** | Modalità di erogazione | Fascia di prezzo (EUR) | Cosa dovrebbe includere la fascia | Più indicato per | | --- | --- | --- | --- | | Con docente, 5 giorni (live online o in presenza) | Da 2.800 a 3.200 a posto | Corso, materiali ufficiali, costo di certificazione, esame, un ripasso d'esame | Un singolo partecipante che vuole risposte live e una finestra di completamento fissa | | Autoapprendimento (moduli registrati) | Da 1.700 a 2.200 a posto | Moduli registrati, materiali ufficiali, esame incluso; meno domande con risposta live | Un partecipante disciplinato che baratta l'accesso live con un prezzo inferiore | | Sessione privata in-house (fino a 12 partecipanti) | Da 12.000 a 18.000 totali | 5 giorni completi per il gruppo, quotati per sessione e non per posto | Team che certificano più persone sullo stesso standard contemporaneamente | Calcola il costo in-house a testa prima di decidere. Una sessione privata al limite inferiore, riempita con otto o più partecipanti, si attesta ben al di sotto della tariffa a posto con docente e mantiene la discussione ancorata ai tuoi sistemi e alla tua Statement of Applicability. Al di sotto di circa cinque partecipanti, la sessione pubblica a posto è di solito più economica. ## I trucchi di scorporo da individuare La maggior parte della confusione sui prezzi in questo mercato è deliberata. Un catalogo pubblicizza una cifra che copre solo la formazione, poi il costo di certificazione, l'esame e i materiali arrivano come addebiti separati una volta che ti sei impegnato. Il totale finisce vicino, o superiore, a una sessione tutto incluso che sembrava più costosa alla prima schermata. Queste sono le voci da confermare per iscritto prima di firmare: - Costo di certificazione: l'addebito per la credenziale stessa, distinto dall'esame. Questa è la voce più spesso spostata fuori dal prezzo in evidenza. - Costo dell'esame e ripasso: conferma che l'esame sia incluso e che almeno un ripasso sia coperto. Un ripasso acquistato separatamente è raramente economico. - Materiali ufficiali: il materiale didattico su licenza, non un'esportazione di slide. Se la pagina è vaga sulla fonte, chiedi. - Supporto post-sessione: coaching o accesso al docente dopo i cinque giorni. Spesso eliminato dalle offerte economiche, spesso la parte più utile per un implementer alle prime armi. > **Leggi la voce di certificazione prima della voce di prezzo** Se un preventivo non indica il costo di certificazione come voce separata e inclusa, presumi che sia escluso e chiedi. Il divario tra "corso" e "corso più certificazione" è la più grande singola fonte di fatture a sorpresa in questo mercato, ed è la più facile da risolvere prima di firmare. ## Come negoziare il preventivo aziendale I prezzi pubblici a posto hanno poco margine di movimento; il livello del partner e la località fissano la fascia, non la tua trattativa. La leva è nel preventivo in-house, dove il costo è fisso e il costo marginale di un partecipante in più è prossimo allo zero per il fornitore. Le mosse che spostano davvero un numero aziendale: 1. Riempi l'aula. Il costo della sessione è lo stesso per quattro posti o dodici, quindi ogni posto oltre il punto di pareggio abbassa il tuo costo effettivo a testa. Costruisci il gruppo prima di chiedere uno sconto. 1. Raggruppa i livelli. Se alcuni del team hanno bisogno del foundation e altri della credenziale implementer, chiedi entrambi in un unico preventivo. Le sessioni a livelli misti sono più facili da scontare rispetto a un singolo corso isolato. 1. Impegnati su una data. Un fornitore quota una data confermata in calendario in modo più conveniente rispetto a un forse. Portare una finestra fissa e un numero di partecipanti confermato vale più che chiedere una percentuale di sconto. 1. Chiedi cosa è rimovibile, non solo cosa è più economico. Se possiedi già i materiali o devi certificare solo una parte del team, un fornitore può ridefinire l'ambito del pacchetto anziché scontarlo. Quando la sessione è costruita e la data è fissata, la pagina in-house ISO 27001 Lead Implementer restituisce un preventivo per sessione entro un giorno lavorativo, che è la cifra contro cui negozi, non la tariffa pubblica a posto. ## Perché il livello del partner costa di più, e quando ne vale la pena I partner PECB Gold e Platinum hanno prezzi superiori ai livelli inferiori, e il sovrapprezzo non è arbitrario. Acquista profondità di accreditamento, docenti più esperti e, dove il fornitore la offre, una garanzia di certificazione o rimborso. Per un implementer alle prime armi che deve uscire con un ISMS funzionante e un esame superato, quel sovrapprezzo spesso si ripaga da solo con un singolo ripasso d'esame evitato e con l'accesso post-sessione che lo accompagna. Per un professionista esperto che aggiorna una credenziale, il livello inferiore è di solito sufficiente. > **Quota il risultato, non il posto** La sessione più economica è economica solo se superi l'esame e se riesci davvero a costruire l'ISMS dopo. Confronta il prezzo tutto incluso con docente con un'offerta autoapprendimento economica più un probabile ripasso d'esame più le ore di consulenza che acquisterai in seguito per compensare il supporto che non hai ricevuto. La cifra in evidenza più bassa perde spesso questo confronto. ## La decisione, in un passaggio Parti dal numero di partecipanti. Un partecipante che ha bisogno di risposte live: con docente, tutto incluso, da 2.800 a 3.200 euro, costo di certificazione confermato per iscritto. Un partecipante disciplinato con budget limitato: autoapprendimento da 1.700 a 2.200, accettando un completamento più lento e meno risposte live. Un team di cinque o più sullo stesso standard: in-house da 12.000 a 18.000 per la sessione, calcola la matematica a testa, riempi l'aula e negozia il pacchetto anziché il posto. In ogni caso, il numero che decide il tuo costo reale è se il costo di certificazione sia dentro il preventivo o in attesa su una seconda fattura. ## FAQ ### Perché il prezzo non è su ogni catalogo? La maggior parte dei fornitori di formazione si affida per impostazione predefinita a "a partire da" o "contattaci per un preventivo" per controllare la leva negoziale. Il compromesso è l'attrito: gli acquirenti individuali rinunciano, gli acquirenti aziendali aspettano giorni per un numero e i prezzi divergono per la stessa sessione. Cyber Academy pubblica il prezzo standard su ogni pagina di corso a catalogo; il flusso di preventivo è riservato agli ambiti in-house e multi-posto, dove una proposta su misura è davvero utile. ### Cosa dovrebbe includere il pacchetto? Un pacchetto ISO 27001 Lead Implementer pulito in Europa contiene: il costo della formazione di 5 giorni, i materiali ufficiali del corso PECB (digitali e cartacei), il costo di certificazione versato a PECB, il primo tentativo d'esame, un ripasso gratuito e la durata a vita della credenziale (nessun costo di rinnovo per la credenziale Lead Implementer stessa). Omissioni comuni nelle offerte più economiche: il costo di certificazione (aggiunto in seguito come "noi eroghiamo la formazione, PECB rilascia la credenziale separatamente"), il ripasso (addebitato da 200 a 400 euro) o i materiali ufficiali (venduti come kit separato). ### Come funziona il prezzo in-house? Le sessioni in-house hanno un prezzo per sessione anziché per posto. Una sessione standard di 5 giorni Lead Implementer per un massimo di 12 partecipanti va dai 12.000 ai 18.000 euro in Europa nel 2026. Il prezzo copre il tempo del docente, i materiali ufficiali PECB per ogni partecipante, il costo di certificazione per ogni partecipante e l'esame per ogni partecipante. Variabili che incidono sul prezzo: la località (trasferta in presenza), la pianificazione (blocco unico vs sessioni frazionate), la lingua (inglese di default, altre lingue su richiesta), l'adattamento settoriale (esempi ed esercizi mappati sul contesto dell'acquirente) e la seniority del docente richiesto. ### Vale la pena scegliere la sessione più economica? Spesso no. La fascia bassa del mercato europeo (da 1.500 a 2.200 euro con docente, esame incluso) è tipicamente: docente junior, sessione numerosa (da 15 a 25 partecipanti), coaching pre-esame ridotto, follow-up post-sessione limitato. La certificazione che si riceve è la stessa; la probabilità di superare l'esame al primo tentativo è sensibilmente inferiore e il trasferimento di conoscenza operativa è disomogeneo. Il nostro tasso di successo al primo tentativo del 99,1% sulle sessioni PECB con docente dipende in parte dal pool di docenti e in parte dalla dimensione della sessione (da 10 a 15, mai oltre). Entrambi hanno un costo. ## Official sources - [PECB, ISO/IEC 27001 Lead Implementer training course](https://pecb.com/en/education-and-certification-for-individuals/iso-iec-27001) --- # ISO 31000: Foundation → Risk Manager → Lead Risk Manager. **URL:** https://cyberacademy.net/it/resources/pillars/iso-31000-foundation-risk-manager-lead-risk-manager **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition ISO 31000 è lo standard internazionale di linee guida per la gestione del rischio: principi, framework, processo, applicabile a qualsiasi organizzazione e a qualsiasi tipo di rischio. Non è certificabile; il percorso PECB è Foundation, Risk Manager, poi Lead Risk Manager. Non esiste un ISO 31000 Lead Auditor: ISO 31000 è una linea guida, non uno standard di sistema di gestione, quindi non c'è nulla rispetto a cui condurre un audit. ## TL;DR - ISO 31000 è una linea guida, non un sistema di gestione certificabile. Non esiste alcun Lead Auditor. - Percorso PECB: Foundation (2 giorni), Risk Manager (5 giorni), Lead Risk Manager (5 giorni). La credenziale senior è Lead Risk Manager. - Foundation fornisce il vocabolario, i principi e il modello di processo. Prerequisito obbligatorio per le credenziali senior. - Risk Manager applica ISO 31000 a un ambito specifico. Lead Risk Manager guida il programma di rischio aziendale trasversalmente alle funzioni. - Si integra con ISO 27005 (rischio specifico per la sicurezza delle informazioni) ed EBIOS RM (scenari cyber strategici): prospettive diverse sulla stessa disciplina del rischio. ## Full content ## Come funziona davvero il percorso ISO 31000 in un'organizzazione ISO 31000 non è qualcosa che si implementa come si implementa un sistema di gestione. Non esiste uno Statement of Applicability, non ci sono clausole obbligatorie da soddisfare, non c'è un ciclo di audit di sorveglianza. Ciò che si costruisce invece è un framework di gestione del rischio: un modo per identificare, analizzare, trattare, monitorare e riportare il rischio in modo coerente in tutta l'organizzazione, e un processo che le persone nei ruoli operativi seguono effettivamente. Lo standard fornisce i principi e il vocabolario; il lavoro consiste nel renderli concreti nella vostra governance, nei vostri comitati e nei vostri punti decisionali. È per questo che il percorso si sviluppa nel modo in cui si sviluppa. Foundation fornisce il linguaggio condiviso affinché "probabilità", "criteri di rischio", "risk appetite" e "rischio residuo" significhino la stessa cosa per tutti i presenti. Risk Manager insegna a gestire il processo all'interno di un ambito definito: un dipartimento, un programma, una linea di prodotto. Lead Risk Manager insegna a progettare e governare il framework stesso trasversalmente alle funzioni, che è un lavoro di governance tanto quanto tecnico. Il percorso è sequenziale per progettazione. Foundation è il prerequisito per le credenziali senior, quindi la maggior parte dei professionisti inizia con il corso ISO 31000 Foundation prima di decidere se ha bisogno del livello Risk Manager o Lead Risk Manager. ## Scegliere il proprio livello: Risk Manager o Lead Risk Manager La decisione non riguarda l'anzianità sulla carta, riguarda ciò di cui sarete responsabili. Risk Manager è per chi gestisce il processo di rischio all'interno di un ambito e possiede un registro dei rischi: facilitate i workshop, valutate i rischi rispetto a criteri concordati, proponete il trattamento e mantenete il registro affidabile nel tempo. Lead Risk Manager è per chi deve rendere il tutto coerente in tutta l'organizzazione: definire i criteri di rischio e il risk appetite, progettare il framework, integrarlo con la strategia e con le altre funzioni di assurance, e riportare al consiglio di amministrazione. Un test utile: se il vostro compito è rispondere a "quali sono i nostri rischi principali in quest'area e cosa stiamo facendo al riguardo", Risk Manager è il livello giusto. Se il vostro compito è rispondere a "il nostro framework di gestione del rischio è idoneo allo scopo, e la leadership può affidarvisi per prendere decisioni", avete bisogno di Lead Risk Manager. Molte persone seguono prima Risk Manager, gestiscono un programma per uno o due anni, poi seguono Lead Risk Manager quando passano a un ruolo aziendale o adiacente a quello del CISO. **Percorso PECB ISO 31000: livello, ambito e a chi si adatta** | Livello | Durata | Ambito | A chi si adatta | | --- | --- | --- | --- | | Foundation | 2 giorni | Principi, framework e modello di processo; solo vocabolario, nessuna responsabilità di implementazione | Chiunque abbia bisogno del linguaggio condiviso: analisti, project manager, auditor di altri domini, neofiti del rischio | | Risk Manager | 5 giorni | Applicare il processo ISO 31000 all'interno di un ambito definito; possedere e gestire un registro dei rischi | Professionisti che facilitano le valutazioni e gestiscono il rischio per un dipartimento, un programma o un prodotto | | Lead Risk Manager | 5 giorni | Progettare e guidare il framework di rischio aziendale; definire criteri e risk appetite; riportare alla leadership | Head of risk, CISO e ruoli GRC senior responsabili dell'intero programma | ## Perché non esiste un ISO 31000 Lead Auditor Questa domanda emerge di continuo perché la maggior parte delle altre credenziali ISO arriva in coppia: Lead Implementer e Lead Auditor, a specchio dello standard certificabile che le sostiene. ISO 31000 non ha un Lead Auditor perché non c'è nulla rispetto a cui condurre un audit. Un audit verifica la conformità ai requisiti, le affermazioni "shall" di uno standard di sistema di gestione come ISO 27001 o ISO 9001. ISO 31000 contiene linee guida, i "should" della buona pratica, non requisiti. Non si può certificare un'organizzazione a ISO 31000, quindi non si può condurre un audit di certificazione rispetto ad esso, quindi non esiste una credenziale di auditor. Questo non significa che la gestione del rischio sfugga all'assurance. Viene valutata indirettamente. Quando un auditor ISO 27001 esamina il vostro processo di valutazione e trattamento del rischio, sta verificando la conformità alle clausole 6.1 e 8.2/8.3 di ISO 27001, e ISO 31000 (spesso tramite ISO 27005) è il riferimento riconosciuto per come quel processo dovrebbe presentarsi. Quindi il Lead Risk Manager costruisce il framework, e l'auditor del sistema di gestione verifica se il framework viene applicato dove uno standard certificabile lo richiede. Sono due lavori diversi, e confonderli è il malinteso più comune che le persone portano in aula. > **La realtà in sala di audit** In un audit ISO 27001, nessuno chiede "siete certificati a ISO 31000". Chiedono di vedere i vostri criteri di rischio, i risultati della valutazione del rischio, il piano di trattamento del rischio e le evidenze che lo avete riesaminato. Un framework pulito basato su ISO 31000 rende breve quella parte dell'audit. Un framework che esiste solo come documento di policy, con un registro che nessuno tocca da un anno, è da dove nascono i rilievi. ## Come ISO 31000 si integra con ISO 27005 ed EBIOS RM Non sono standard in concorrenza; sono prospettive diverse sulla stessa disciplina, e i professionisti senior li usano insieme. ISO 31000 è il quadro generico che si applica a qualsiasi rischio in qualsiasi organizzazione. ISO 27005 restringe quel quadro al rischio di sicurezza delle informazioni, con il dettaglio su asset, minacce e vulnerabilità di cui un ISMS ha bisogno. EBIOS Risk Manager, il metodo francese (ANSSI), affronta il problema a partire dagli scenari di attacco strategici e dall'ecosistema di attaccanti e stakeholder, il che è efficace per i rischi cyber ad alta posta in gioco ed è sempre più atteso nei settori pubblici e regolamentati dell'UE. Il modello pratico è a strati: ISO 31000 definisce i principi, il framework e il processo condivisi dall'intera organizzazione; ISO 27005 Risk Manager fornisce il metodo specifico per la sicurezza delle informazioni che si innesta in un ISMS conforme a ISO 27001; ed EBIOS Risk Manager fornisce la visione basata su scenari e incentrata sull'attaccante per i rischi cyber che contano di più. Non si contraddicono a vicenda, e il vocabolario di ISO 31000 è ciò che permette a un team di passare dall'uno all'altro senza confusione. **ISO 31000 vs ISO 27005 vs EBIOS RM** | | ISO 31000 | ISO 27005 | EBIOS RM | | --- | --- | --- | --- | | Ambito | Qualsiasi rischio, qualsiasi organizzazione | Rischio di sicurezza delle informazioni | Scenari di rischio cyber strategici | | Ruolo | Principi, framework, processo | Metodo di rischio specifico per l'IS in un ISMS | Analisi guidata da attaccanti ed ecosistema | | Si abbina a | Governance aziendale | Certificazione ISO 27001 | ANSSI / settore regolamentato e pubblico | | Approccio | Generico e top-down | Asset, minaccia, vulnerabilità | Guidato da scenari e stakeholder | ## Rilevanza oltre il cyber, e gli errori comuni Poiché ISO 31000 è agnostico rispetto al tipo di rischio, lo stesso framework copre il rischio operativo, finanziario, di supply chain, di progetto, di sicurezza, di conformità e strategico. È questo il suo vero valore per un CISO che vuole un posto al tavolo aziendale: parlare ISO 31000 significa parlare il linguaggio che il consiglio di amministrazione e la più ampia funzione di rischio già usano, non un dialetto cyber che devono tradurre. La credenziale viaggia bene anche al di fuori della sicurezza, ed è in parte per questo che si colloca al centro di una carriera GRC seria anziché ai suoi margini. Gli errori sono ricorrenti tra le organizzazioni. Le persone trattano il registro dei rischi come un artefatto di conformità da produrre una volta all'anno invece che come uno strumento decisionale vivo. Definiscono criteri di rischio su cui nessuno è d'accordo, così la valutazione diventa una messa in scena. Confondono il risk appetite (una decisione della leadership) con la risk tolerance (l'intervallo operativo), e non lasciano che nessuno dei due venga definito esplicitamente, il che significa che le decisioni di trattamento non hanno un ancoraggio. E saltano Foundation, gettando un intero team in un corso Risk Manager dove metà dell'aula sta ancora discutendo su cosa significhi "probabilità". Se state costruendo un programma anziché limitarvi a sostenere un esame, l'ordine che funziona è: far seguire al team ISO 31000 Foundation per il vocabolario condiviso, far seguire ai responsabili di ambito ISO 31000 Risk Manager, e far seguire a chi possiede il framework aziendale ISO 31000 Lead Risk Manager. Quella sequenza evita la modalità di fallimento più costosa, ovvero un framework che una sola persona comprende. > **Definite il risk appetite prima di valutare** Non iniziate a valutare i rischi finché la leadership non ha concordato i criteri di rischio e dichiarato un appetite, anche solo approssimativo. Senza quell'ancoraggio, ogni punteggio di rischio è un'opinione personale e le vostre decisioni di trattamento non possono essere difese. Lead Risk Manager esiste in gran parte per portare a buon fine questo passaggio. ## FAQ ### Perché non esiste un ISO 31000 Lead Auditor? ISO 31000 è una linea guida, non uno standard di sistema di gestione. Non esiste un sistema certificabile rispetto a cui condurre un audit. Alcuni cataloghi di formazione pubblicizzano un ISO 31000 Lead Auditor; questa credenziale non esiste all'interno del programma PECB. Chi la cerca di solito intende ISO 27001 Lead Auditor (che verifica l'ISMS utilizzando la metodologia di rischio ISO 27005) oppure ISO/IEC 27005 Risk Manager (che applica la metodologia alla sicurezza delle informazioni). Se il vostro auditor si aspetta un audit ISO 31000, opponetevi: non esiste un criterio di conformità certificabile. Probabilmente intende una valutazione di maturità del framework di gestione del rischio, che è un esercizio diverso. ### Risk Manager o Lead Risk Manager, qual è quello giusto per me? Risk Manager (5 giorni) è destinato ai professionisti che gestiscono un ambito di rischio definito: un dipartimento, un programma, una controllata. Il corso insegna a far funzionare ISO 31000 all'interno di quell'ambito. La maggior parte degli analisti GRC e dei risk officer si ferma qui. Lead Risk Manager (5 giorni) è destinato ai professionisti senior che gestiscono il programma di rischio aziendale: definizione del risk appetite, progettazione del framework, integrazione del rischio tra le unità di business, reporting al consiglio di amministrazione. Obbligatorio quando il titolo del ruolo è Head of Risk, Chief Risk Officer o equivalente. ### Come si colloca ISO 31000 rispetto a ISO 27005? Ambiti diversi. ISO 31000 è la linea guida generica per la gestione del rischio: si applica al rischio finanziario, operativo, strategico, di conformità, di sicurezza delle informazioni, a qualsiasi cosa. ISO 27005 è l'applicazione dei principi di ISO 31000 specificamente al rischio di sicurezza delle informazioni in un contesto ISMS conforme a ISO 27001. Un professionista del rischio con credenziali ISO 31000 opera a livello dell'intera organizzazione. Uno specialista del rischio di sicurezza delle informazioni con credenziali ISO 27005 opera all'interno dell'ambito dell'ISMS. I professionisti senior spesso possiedono entrambe. ### ISO 31000 è rilevante al di fuori della cybersecurity? Sì, molto. ISO 31000 è agnostico rispetto al settore. Viene utilizzato nella gestione del rischio finanziario (insieme ai framework Basel e Solvency), nella gestione del rischio aziendale (insieme a COSO ERM), nel rischio della supply chain, nel rischio ambientale, nel rischio di progetto e nel rischio operativo. I principi e il modello di processo sono identici in tutti i domini; cambiano solo le categorie di asset e di minacce. ## Official sources - [ISO, ISO 31000:2018 Risk management](https://www.iso.org/iso-31000-risk-management.html) - [PECB, ISO 31000 Risk Manager](https://pecb.com/en/education-and-certification-for-individuals/iso-31000) --- # CISO vs DPO vs RSSI: chi fa davvero cosa. **URL:** https://cyberacademy.net/it/resources/pillars/ciso-dpo-rssi **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition Il CISO (Chief Information Security Officer) è responsabile della strategia e del programma di sicurezza delle informazioni. Il DPO (Data Protection Officer) è responsabile della supervisione indipendente, imposta dal GDPR, dei trattamenti di dati personali. Il RSSI (Responsable de la Sécurité des Systèmes d'Information) è l'equivalente francese del CISO. I tre ruoli si sovrappongono sul perimetro della sicurezza dei dati ma rispondono a mandati diversi: CISO e RSSI all'organo esecutivo, DPO all'autorità di controllo. ## TL;DR - CISO e RSSI sono lo stesso ruolo con un vocabolario diverso. RSSI è il titolo francese; CISO è il titolo internazionale. Stesso ambito. - Il DPO è indipendente per impostazione del GDPR, riferisce al più alto livello dirigenziale, non può essere rimosso per lo svolgimento del ruolo ed è il punto di contatto per l'autorità di controllo. - Responsabilità del CISO/RSSI: strategia di sicurezza delle informazioni, registro dei rischi, risposta agli incidenti, reporting al consiglio. Mandato dall'organo esecutivo. - Responsabilità del DPO: supervisione della conformità al GDPR, revisione delle DPIA, diritti degli interessati, dialogo con l'autorità di controllo. Mandato dalla normativa. - Si sovrappongono sulla sicurezza dei dati (Article 32 del GDPR) e sulla risposta agli incidenti. Una sola persona non dovrebbe ricoprire entrambi i ruoli nelle organizzazioni di dimensioni significative: il DPO deve restare indipendente dalle decisioni di trattamento dei dati che il CISO gestisce. ## Full content ## Due responsabilità, un solo perimetro La confusione tra questi ruoli non riguarda i titoli professionali. Riguarda l'autorità a cui ciascuna persona risponde. Il CISO e il RSSI gestiscono un programma per conto dell'organo esecutivo: sono giudicati sul fatto che l'organizzazione sia abbastanza sicura da continuare a operare e sul fatto che il consiglio comprenda il rischio residuo che sta accettando. Il DPO risponde a un padrone del tutto diverso. Il ruolo esiste perché il GDPR ha collocato una funzione di conformità indipendente all'interno dell'organizzazione, e quella funzione riferisce al più alto livello dirigenziale pur restando fuori dalle decisioni operative che deve valutare. Una parte ottimizza per il business. L'altra deve poter dire al business che sta sbagliando. In termini operativi, il CISO e il RSSI costruiscono e difendono; il DPO esamina e contesta. Quando un team di marketing vuole arricchire un database clienti con dati di terze parti, il CISO chiede se possa essere fatto in modo sicuro e il DPO chiede se debba essere fatto del tutto, alla luce dei criteri di liceità, minimizzazione e limitazione delle finalità. Entrambe le domande sono legittime. Non sono la stessa domanda, e nel momento in cui le si fa convergere in una sola persona si perde la seconda. ## Il confronto che conta davvero La maggior parte dei confronti pubblicati si ferma alle definizioni. La distinzione che decide le contese sull'organigramma è la linea di riporto e la fonte del mandato, perché è ciò che determina chi può prevalere su chi e chi porta la responsabilità quando qualcosa va storto. **CISO vs DPO vs RSSI: mandato, linea di riporto e certificazioni di segnalazione** | Dimensione | CISO | DPO | RSSI | | --- | --- | --- | --- | | Mandato primario | Strategia e programma di sicurezza delle informazioni | Supervisione indipendente del trattamento dei dati personali | Come il CISO (titolo francese) | | Fonte dell'autorità | Delegata dall'organo esecutivo | Richiesta e tutelata dal GDPR | Delegata dall'organo esecutivo | | Riferisce a | CEO, consiglio o comitato rischi | Più alto livello dirigenziale, con indipendenza | Direction générale o DSI | | Responsabile di | Registro dei rischi, controlli, risposta agli incidenti, reporting al consiglio | Revisione delle DPIA, diritti degli interessati, registri dei trattamenti, dialogo con l'autorità di controllo | Stesso ambito del CISO, contesto normativo francese | | Può essere rimosso per aver svolto il proprio lavoro? | Sì, come qualsiasi dirigente | No, tutelato contro la rimozione per lo svolgimento del ruolo | Sì, come qualsiasi dirigente | | Certificazioni di segnalazione | CISM, PECB CCISO, Lead Cybersecurity Manager, CRISC | GDPR DPO, CDPSE, ISO 27701 Lead Implementer | Come il CISO, spesso più ISO 27001 per il mercato francese | La colonna delle certificazioni è il segnale pratico che un responsabile delle assunzioni legge. Un profilo di leader della sicurezza si costruisce su CISM per la credenziale di livello manageriale, sul PECB Certified CISO per l'inquadramento esecutivo e su Lead Cybersecurity Manager per la costruzione del programma. Un profilo di protezione dei dati si segnala attraverso la credenziale Certified Data Protection Officer e uno strato di privacy engineering come CDPSE. I due stack non sono intercambiabili, e un CV che li mescola senza un ruolo primario chiaro di solito segnala una persona che non ha fatto nessuno dei due in profondità. ## Dove si sovrappongono davvero: Article 32 e incidenti La sovrapposizione è reale, e fingere il contrario è il modo in cui le organizzazioni finiscono per avere lacune. L'Article 32 del GDPR richiede misure tecniche e organizzative adeguate per proteggere i dati personali: cifratura, resilienza, capacità di ripristinare la disponibilità e test regolari di tali misure. È lavoro di sicurezza. Il CISO è responsabile dei controlli che lo realizzano. Ma il DPO deve poter valutare se quelle misure siano adeguate al rischio per gli interessati, che è una lente diversa da adeguate al business. Il modo corretto di gestirlo: il CISO è responsabile dell'implementazione e dell'operatività delle misure dell'Article 32, e il DPO è responsabile di formarsi un'opinione indipendente sulla loro adeguatezza. Il CISO costruisce lo standard di cifratura dei dati a riposo; il DPO registra nella DPIA che è sufficiente per il trattamento in ambito, oppure segnala che non lo è. Nessuno dei due approva i propri compiti. ISO 27701 si colloca esattamente su questa cucitura. Estende un ISMS ISO 27001 in un sistema di gestione delle informazioni sulla privacy, dando al CISO e al DPO un framework di controllo condiviso anziché due vocabolari scollegati. Il corso ISO 27701 Lead Implementer è la singola qualificazione più utile per la persona che deve far dialogare il programma di sicurezza e il programma di privacy. La risposta agli incidenti è la seconda sovrapposizione ed è quella che cede sotto pressione. Il CISO gestisce la risposta tecnica: contenere, eradicare, ripristinare. Il DPO gestisce l'orologio normativo: il GDPR concede 72 ore per notificare all'autorità di controllo una violazione di dati personali, e quella valutazione (è una violazione, è notificabile, gli interessati sono a rischio) è una decisione del DPO, non del CISO. Se queste due persone non sono nella stessa stanza entro la prima ora di un incidente grave, finirete per notificare in eccesso bruciando credibilità con l'autorità, oppure per notificare in difetto violando la scadenza. > **Eseguire un solo playbook di incident response, non due** Il fallimento più comune è un piano di risposta agli incidenti di sicurezza che non menziona mai il DPO e una procedura per le violazioni di privacy che non menziona mai il contenimento. Unirli. Il trigger che allerta il CISO deve allertare anche il DPO, con un punto decisionale definito sulla notificabilità della violazione prima che inizi a scorrere la finestra delle 72 ore. ## Perché una sola persona non dovrebbe ricoprire CISO e DPO La ragione è strutturale, non di carico di lavoro. Il GDPR richiede che il DPO sia libero da qualsiasi conflitto di interessi: il DPO non può ricoprire una posizione che comporti la determinazione delle finalità e dei mezzi del trattamento di dati personali. Un CISO fa esattamente questo. Il CISO decide quali log vengono conservati, per quanto tempo vivono i backup, quale monitoraggio ispeziona il traffico dei dipendenti, quali fornitori trattano i dati. Quelle sono decisioni di trattamento. Una sola persona che le prende e dovrebbe al contempo verificarle in modo indipendente non può svolgere il secondo compito, perché l'autorità di controllo non accetterà l'auto-revisione come supervisione indipendente. Questa non è un'opinione di Cyber Academy. Le autorità di controllo europee hanno già sanzionato organizzazioni per aver nominato un DPO che ricopriva anche un ruolo operativo sui trattamenti che era incaricato di supervisionare. In una piccola organizzazione potreste davvero avere una persona capace in grado di fare entrambe le cose. La risposta in quel caso non è combinare i ruoli; è rendere quella persona il CISO e nominare il DPO esternamente, o viceversa. Un DPO esterno è una soluzione riconosciuta e spesso più pulita proprio perché l'indipendenza è integrata per costruzione. > **Lo schema per le piccole organizzazioni che regge** Al di sotto della soglia di organico in cui un DPO dedicato è giustificato, mantenere internamente la leadership della sicurezza e affidare il ruolo di DPO a un fornitore esterno. Si ottiene l'indipendenza tutelata che il GDPR richiede, il CISO mantiene piena autorità operativa e si dispone di una separazione documentata che resiste a un audit. ## La realtà nella sala di audit Quando un auditor ISO 27001 o un'autorità di controllo esamina questo aspetto, sta verificando una cosa sola: siete in grado di dimostrare che le decisioni di sicurezza e le decisioni di privacy sono state prese da persone con la giusta autorità e la giusta indipendenza. Le prove che vogliono sono banali e specifiche. 1. Una RACI o equivalente che indichi chi è responsabile del registro dei rischi rispetto ai registri dei trattamenti, senza che nessuna persona ricopra sia il ruolo di gestione sia quello di supervisione per lo stesso controllo. 1. Registri degli incidenti che dimostrino che il DPO è stato coinvolto sulla notificabilità e il CISO sul contenimento, con marcature temporali che rientrano nella finestra delle 72 ore. 1. DPIA che riportino un'opinione indipendente del DPO sulle misure di sicurezza, non un'approvazione di sicurezza rietichettata come revisione di privacy. Le competenze di audit e assurance che rendono tutto questo dimostrabile appartengono ancora una volta a un profilo distinto. CISA costruisce la disciplina dell'audit e delle prove, e CRISC costruisce il linguaggio di quantificazione del rischio che consente al CISO di presentare il rischio residuo al consiglio in termini su cui possa effettivamente decidere. Sono queste le credenziali che trasformano una struttura difendibile in una dimostrabile. ## Errori comuni da evitare - Trattare CISO e RSSI come due ruoli da coprire separatamente. Sono lo stesso ruolo; il titolo segue la lingua e il contesto normativo, non l'ambito. - Lasciare che il DPO riferisca al CISO o alla funzione IT. Questo distrugge l'indipendenza che il GDPR richiede ed è un rilievo facile per qualsiasi autorità. - Presumere che vinca la certificazione di rango più elevato. Chi possiede una CISM non è per ciò stesso qualificato come DPO, e una forte credenziale da DPO non rende qualcuno un leader della sicurezza. Abbinare la credenziale al mandato. - Scrivere un report al consiglio che fonde il rischio di sicurezza e il rischio di privacy in un unico numero. Il consiglio deve vedere entrambi, perché le conseguenze e le autorità coinvolte sono diverse. Le organizzazioni che gestiscono bene questo aspetto non hanno più organico di quelle che lo gestiscono male. Hanno una risposta chiara a una sola domanda: per qualsiasi decisione sui dati personali, chi la costruisce e chi la giudica in modo indipendente. Tenete queste due risposte in due persone diverse, date a ciascuna la credenziale che corrisponde al suo mandato, e l'organigramma smette di essere una fonte di rilievi di audit. ## FAQ ### La stessa persona può essere CISO e DPO? Tecnicamente sì nelle piccole organizzazioni, ma l'EDPB lo sconsiglia fortemente. Il DPO deve restare indipendente dalle decisioni di trattamento; il CISO gestisce quelle decisioni. In una piccola organizzazione in cui la stessa persona prende la decisione, l'indipendenza è fittizia. In qualsiasi organizzazione di dimensioni rilevanti (oltre 50 FTE che trattano dati personali in misura significativa), separare i ruoli. Il DPO può collocarsi nel team legale, nel team di gestione del rischio o riferire direttamente al CEO. Il CISO si colloca nell'organizzazione tecnologica o di sicurezza. ### Quali certificazioni segnalano un CISO? CISM (ISACA) è la credenziale più comune in un curriculum da CISO: circa il 60% degli annunci per CISO in Europa la richiede. ISO 27001 Lead Implementer o Lead Auditor (PECB) è la successiva più comune. CISSP è la tradizionale alternativa di stampo statunitense. Per i ruoli di RSSI francesi, le qualificazioni riconosciute da ANSSI (EBIOS Risk Manager, qualificazioni tramite i programmi SecNumCloud o PASSI) hanno peso in aggiunta o in alternativa alle credenziali internazionali. ### Quali certificazioni segnalano un DPO? Il Certified Data Protection Officer (CDPO, rilasciato da PECB, allineato al GDPR) è il riferimento europeo. Il CIPP/E (IAPP) è la credenziale internazionale alternativa in materia di privacy, particolarmente riconosciuta nelle aziende con presenza negli Stati Uniti. Per i DPO tecnici (privacy engineer che operano all'interno o a fianco del team di sicurezza), CDPSE (ISACA) è il complemento tecnico. ISO/IEC 27701 Lead Implementer (PECB) è la credenziale di sistema di gestione per le organizzazioni che gestiscono un ISMS orientato alla privacy. ### Come si confrontano i loro stipendi in Europa? Ampia variabilità per paese e settore. In Francia nel 2026, un CISO/RSSI esperto in un'azienda del CAC 40 guadagna da 130.000 a 220.000 euro di base. Un DPO esperto nella stessa azienda guadagna da 90.000 a 150.000 euro di base. Nei servizi finanziari, entrambi i ruoli tendono a essere dal 20% al 30% più alti. Nel mid-market, entrambi i ruoli tendono a essere dal 30% al 40% più bassi. La forbice salariale riflette l'ambito: il CISO/RSSI è responsabile di budget, organico e scelte tecnologiche. Il DPO è responsabile di supervisione, indipendenza e contatto con l'autorità di controllo. ## Official sources - [EDPB, Guidelines on Data Protection Officers](https://www.edpb.europa.eu/) - [ANSSI, Référentiel d'exigences pour les RSSI](https://cyber.gouv.fr/) --- # ENCYCLOPEDIA ## AI Risk Manager **URL:** https://cyberacademy.net/it/resources/encyclopedia/ai-risk-manager **Last reviewed:** 2026-06-24 AI Risk Manager è la credenziale (PECB / ISACA emerging) per i professionisti che gestiscono programmi di rischio specifici per l'IA: rischio del modello, bias, drift, trasparenza, rischio del modello da terze parti. Livello operativo che completa ISO/IEC 42001 (livello di sistema) e l'AI Act (livello regolatorio). Accompagnamento frequente al CISO o al Lead AI Auditor. AI Risk Manager è il ruolo operativo e la credenziale emergente per chi gestisce quotidianamente il programma di rischio IA di un'organizzazione. Laddove ISO 42001 imposta il sistema di gestione e l'EU AI Act fissa la base giuridica, l'AI Risk Manager è la persona che trasforma quei framework in un registro operativo: individuare dove un modello può fallire, decidere quali controlli mettere intorno ad esso e riferire il rischio residuo alla direzione. È il cugino specifico dell'IA del responsabile dei rischi della sicurezza delle informazioni, e mutua gran parte del proprio metodo dalla gestione classica del rischio, aggiungendo le modalità di guasto tipiche dell'apprendimento automatico. ## Cosa copre davvero il ruolo Il rischio IT tradizionale si chiede se un sistema sia disponibile, riservato e integro. Il rischio IA mantiene tutto questo e aggiunge uno strato di domande a cui i controlli convenzionali non hanno mai dovuto rispondere. Un AI Risk Manager opera lungo tutto il ciclo di vita del modello e tipicamente presidia le seguenti famiglie di rischio. - Rischio di modello: il modello sbaglia in modi difficili da vedere, si comporta bene nei test ma male sugli input reali, oppure fallisce silenziosamente sui casi limite. - Bias ed equità: il modello produce esiti sistematicamente peggiori per alcuni gruppi, spesso ereditati dai dati di addestramento. - Drift: i dati di input o il mondo reale cambiano dopo il rilascio, quindi l'accuratezza si degrada nel tempo e il modello richiede monitoraggio e trigger di riaddestramento. - Trasparenza e spiegabilità: gli stakeholder, gli auditor o i regolatori devono capire come è stata presa una decisione, soprattutto per i casi d'uso ad alto impatto. - Rischio di modelli di terze parti e della catena di fornitura: modelli di base, API e set di dati che non hai costruito tu ma di cui sei responsabile. ## Dove si colloca rispetto a ISO 42001 e all'AI Act Il modo più chiaro per collocare il ruolo è ragionare per livelli. L'AI Act è il livello normativo che indica quali obblighi si applicano a ciascuna fascia di rischio. ISO 42001 è il livello del sistema di gestione che fornisce la struttura di governance, la responsabilità e il ciclo di miglioramento continuo per soddisfare tali obblighi. L'AI Risk Manager è il livello operativo sottostante a entrambi, che svolge il lavoro ricorrente di valutazione che fornisce evidenze all'AIMS e dimostra che gli obblighi ad alto rischio sono rispettati nella pratica. Per questo il ruolo è di norma un complemento, e non un sostituto, di un CISO o di un Lead AI Auditor. **I livelli di governance dell'IA e il ruolo dell'AI Risk Manager** | Livello | Artefatto | Domanda a cui risponde | | --- | --- | --- | | Normativo | EU AI Act | Quali obblighi legali si applicano a questo sistema di IA? | | Sistema di gestione | ISO/IEC 42001 (AIMS) | Come governa l'organizzazione l'IA in modo responsabile? | | Operativo | Registro dei rischi IA e controlli | Dove può fallire questo modello e cosa riduce tale rischio? | | Assurance | Audit IA (ad esempio l'ambito AAIA) | Quanto sopra funziona come previsto? | ## Il panorama delle credenziali Il titolo è ancora in fase di consolidamento. PECB e ISACA sono i due enti più associati alla formalizzazione della competenza sul rischio IA, e il mercato delle certificazioni è più recente rispetto a discipline consolidate come il CISA o l'ISO 27001 Lead Implementer. In pratica, ai datori di lavoro interessa meno quale badge possiedi e più se sai condurre una valutazione del rischio IA difendibile, giustificare un insieme di controlli e mappare il tuo lavoro sulle clausole di ISO 42001 e sulle fasce dell'AI Act. Considera la credenziale come prova del metodo, non come il lavoro in sé. > **Nota del professionista** Se gestisci già il rischio della sicurezza delle informazioni, hai già fatto gran parte del percorso. Le competenze trasferibili sono il registro dei rischi, le decisioni di trattamento e il reporting agli stakeholder. Il nuovo muscolo da costruire è la comprensione del comportamento del modello: test di bias, monitoraggio del drift e spiegabilità, oltre all'esposizione della catena di fornitura che deriva dall'uso di modelli di base che non hai addestrato. --- ## Advanced in AI Audit (AAIA) **URL:** https://cyberacademy.net/it/resources/encyclopedia/aaia **Last reviewed:** 2026-06-24 AAIA è la credenziale ISACA avanzata per l'audit di sistemi, modelli e governance dell'IA. Di recente introduzione (dal 2024). Richiede una certificazione CISA in corso di validità o equivalente. Progettata per auditor senior che integrano competenze in ambito IA, mappata su ISO 42001 e sugli obblighi ad alto rischio dell'AI Act europeo. ## A cosa serve la certificazione AAIA Advanced in AI Audit (AAIA) è una certificazione ISACA pensata per auditor esperti che devono estendere la propria pratica all'intelligenza artificiale. È un'aggiunta recente al portafoglio ISACA, introdotta nel momento in cui l'IA è passata dai progetti pilota a sistemi in produzione che consigli di amministrazione, autorità di regolamentazione e clienti si aspettano ora di poter assicurare. La premessa è stretta e deliberata: presuppone che sappiate già fare auditing. AAIA non rinsegna il processo di audit. Vi insegna ad applicare la disciplina dell'audit ai sistemi di IA, ai modelli che li sottendono e alla governance che li avvolge. Questo focus è il motivo per cui AAIA si posiziona come avanzata e non di livello base. Si rivolge ad auditor che già possiedono una certificazione di audit e una padronanza operativa di controlli, evidenze e reporting, e che ora devono rispondere a domande che un audit IT tradizionale non è mai stato progettato per porre. I dati di addestramento sono adeguati allo scopo? Il comportamento del modello può essere spiegato? Esiste una supervisione umana significativa là dove il sistema prende decisioni di rilievo? L'IA è utilizzata solo per la finalità dichiarata? Sono queste le lacune che AAIA intende colmare. ## Prerequisiti e collocazione AAIA è progettata per poggiare su una base di audit esistente anziché reggersi da sola. ISACA la posiziona per auditor senior e, in pratica, ci si aspetta che i candidati possiedano CISA o una certificazione di audit riconosciuta equivalente prima di intraprenderla. La logica è la stessa che ISACA applica a tutta la sua offerta avanzata: la certificazione aggiunge una specializzazione sopra una base comprovata, non sostituisce quella base. Un auditor che non ha mai condotto un incarico trarrà poco da AAIA, mentre un titolare CISA esperto ottiene un metodo strutturato per rendere difendibili gli incarichi di IA. > **AAIA presuppone che sappiate già fare auditing** Considerate AAIA come una specializzazione sovrapposta a una certificazione di audit esistente come CISA, non come una prima certificazione. Estende l'auditor che siete già verso i sistemi di IA, i modelli e la governance. ## Come si rapporta a ISO 42001 e al Regolamento europeo sull'IA Ciò che rende AAIA pratica e non accademica è che è radicata nei framework che agli auditor viene ora chiesto di verificare. Si rapporta a ISO/IEC 42001, la norma di sistema di gestione dedicata all'IA, che offre all'auditor una struttura di controllo riconosciuta per la governance dell'IA: responsabilità, qualità dei dati, trasparenza, supervisione umana e valutazione d'impatto. Si allinea inoltre agli obblighi che l'EU AI Act impone ai sistemi ad alto rischio, dove i fornitori devono gestire un sistema di gestione dei rischi, mantenere la documentazione tecnica, garantire la supervisione umana e svolgere il monitoraggio post-commercializzazione. AAIA attrezza l'auditor a raccogliere evidenze esattamente a fronte di tali aspettative. È qui che AAIA si distingue da una qualifica generale in governance dell'IA. Un certificato di governance vi insegna a progettare e gestire un sistema di gestione dell'IA. AAIA vi insegna a valutarlo in modo indipendente: pianificare un audit di IA, definirne l'ambito attorno alla finalità prevista e al rischio, testare i controlli, valutare le evidenze e riferire constatazioni su cui un consiglio o un'autorità di regolamentazione possa agire. È la controparte di assurance rispetto alle competenze di costruzione e gestione che framework come ISO 42001 installano. ## Cosa fanno davvero i titolari di AAIA In pratica, un auditor con competenze AAIA tende a seguire una sequenza riconoscibile in un incarico di IA: 1. Definire l'ambito dell'audit attorno alla finalità prevista del sistema di IA, alla sua classificazione di rischio e al ruolo dell'organizzazione come sviluppatore, fornitore o deployer. 1. Valutare la governance: se la responsabilità è assegnata, se esistono valutazioni del rischio e dell'impatto dell'IA e se sono mantenute aggiornate. 1. Testare i controlli che contano per l'IA, inclusi la governance dei dati, la documentazione dei modelli, la trasparenza verso gli utenti interessati e la supervisione umana. 1. Valutare il monitoraggio post-implementazione, la gestione degli incidenti e il ciclo di feedback che mantiene il sistema entro i suoi limiti dichiarati. 1. Riferire le constatazioni in un linguaggio di audit che corrisponda con chiarezza ai controlli ISO 42001 e agli obblighi dell'AI Act, così che l'organizzazione possa colmare le lacune con evidenze. Il valore per un'organizzazione è l'indipendenza. Un team di governance dell'IA può attestare che i controlli esistono; un auditor dotato di AAIA può fornire l'assurance di tipo terza parte che quei controlli funzionano davvero, che è sempre più ciò che autorità di regolamentazione, acquirenti enterprise e funzioni acquisti chiedono di vedere. --- ## Agenzia dell'Unione Europea per la Cybersecurity (ENISA) **URL:** https://cyberacademy.net/it/resources/encyclopedia/enisa **Last reviewed:** 2026-06-24 ENISA è l'agenzia UE per la cybersecurity, con sede ad Atene. Supporta gli Stati membri e le istituzioni UE in materia di politica della cybersecurity, cooperazione operativa e quadro di certificazione europeo. È operativamente coinvolta nella cooperazione NIS 2, negli standard tecnici di attuazione DORA e nella baseline di sicurezza dell'AI Act. Il loro rapporto sul panorama delle minacce è la pubblicazione annuale più citata in assoluto. ## Cosa fa l'ENISA e cosa non fa L'ENISA è l'Agenzia dell'Unione europea per la cibersicurezza, l'organismo dell'UE il cui compito è innalzare il livello comune di cibersicurezza in tutta l'Unione. Con sede ad Atene, opera al fianco degli Stati membri, della Commissione europea e delle istituzioni dell'UE, sostenendo le politiche, la cooperazione operativa e lo sviluppo delle capacità, anziché gestire essa stessa la difesa nazionale. La distinzione conta nella pratica: l'ENISA non indaga sulle violazioni, non commina sanzioni vincolanti e non vigila sulle singole imprese. Lo fanno le autorità nazionali competenti e i regolatori di settore. L'ENISA produce gli orientamenti, l'intelligence sulle minacce e i riferimenti tecnici di base su cui si appoggiano tali autorità e le organizzazioni regolamentate che da esse dipendono. Un modo utile per collocare l'ENISA è metterla a confronto con un'agenzia nazionale come l'ANSSI francese. L'ANSSI è un'autorità di uno Stato membro dotata di poteri operativi e regolamentari all'interno di un solo paese. L'ENISA opera un livello al di sopra, coordinando tutti gli Stati membri e dando all'UE un unico punto di riferimento tecnico, affinché ventisette approcci nazionali non divergano. Quando si vede un CISO francese citarle entrambe, l'ANSSI è l'autorità a cui risponde e l'ENISA è la fonte a livello UE con cui si allinea. ## Dove l'ENISA tocca le regolamentazioni a cui dovete conformarvi Per un professionista GRC, l'ENISA non è un'astrazione. Compare direttamente all'interno dei testi rispetto ai quali rientrate nel perimetro. Ai sensi della NIS 2, l'ENISA sostiene i meccanismi di cooperazione tra gli Stati membri, mantiene una consapevolezza situazionale condivisa e contribuisce agli orientamenti tecnici che aiutano i soggetti essenziali e importanti a interpretare in modo coerente i loro obblighi di sicurezza e di notifica degli incidenti. Ai sensi del DORA, l'ENISA contribuisce alle norme tecniche di attuazione e di regolamentazione che traducono i requisiti di alto livello del regolamento per i soggetti finanziari in aspettative concrete. E man mano che le disposizioni di sicurezza dell'AI Act prendono forma, l'ENISA è in grado di contribuire a definire il livello di base di cibersicurezza atteso dai sistemi di IA ad alto rischio. - NIS 2: cooperazione transfrontaliera, consapevolezza situazionale e orientamenti tecnici per i soggetti essenziali e importanti. - DORA: contributo alle norme tecniche che rendono operativa la resilienza operativa digitale per i soggetti finanziari. - EU Cybersecurity Act: l'ENISA gestisce il quadro europeo di certificazione della cibersicurezza, sviluppando schemi che consentono di certificare una sola volta prodotti, servizi e processi e di farli riconoscere in tutta l'Unione. > **Il quadro di certificazione è la leva più concreta dell'ENISA** Il Cybersecurity Act ha conferito all'ENISA un mandato permanente e le ha affidato il compito di costruire schemi di certificazione a livello UE. Invece che un fornitore certifichi un prodotto separatamente in ciascun paese, un unico schema produce un certificato riconosciuto in tutti gli Stati membri. Questa è la parte del lavoro dell'ENISA che più probabilmente emerge in una conversazione di approvvigionamento o di assurance. ## Il prodotto che i professionisti leggono davvero L'ENISA pubblica ampiamente, ma il suo rapporto annuale Threat Landscape è il lavoro più citato, il documento di riferimento a cui i team ricorrono quando hanno bisogno di una visione autorevole, a livello UE, di come il quadro delle minacce sta evolvendo nei diversi settori. I professionisti lo usano per verificare la coerenza delle proprie valutazioni del rischio, per informare i consigli di amministrazione con una fonte indipendente e paneuropea e per giustificare le priorità di controllo presso auditor e regolatori. Accanto ad esso, l'ENISA pubblica orientamenti settoriali, guide alle buone pratiche e le basi tecniche alla base degli schemi di certificazione. Il messaggio pratico è trattare l'ENISA come una fonte di autorità anziché come un organismo a cui rendete conto. Non si deposita nulla presso l'ENISA. Allineate il vostro linguaggio del rischio, i vostri riferimenti di base per i controlli e le vostre ipotesi sulle minacce a ciò che essa pubblica, perché è il riferimento che leggono anche la vostra autorità nazionale, il vostro auditor e, sempre più, il vostro regolatore. --- ## Agenzia nazionale francese per la cybersicurezza (ANSSI) **URL:** https://cyberacademy.net/it/resources/encyclopedia/anssi **Last reviewed:** 2026-06-24 ANSSI è l'agenzia nazionale francese per la cybersicurezza, posta sotto l'autorità del Primo Ministro dal 2009. È l'autorità nazionale per la politica di cybersicurezza in Francia: qualifica prodotti e fornitori di servizi, pubblica EBIOS Risk Manager e agisce come autorità competente per il recepimento di NIS 2. Le sue qualificazioni (SecNumCloud, PVID, PASSI) rappresentano il riferimento di eccellenza nel settore pubblico francese. ## Cosa fa l'ANSSI L'ANSSI (Agence nationale de la securite des systemes d'information) e l'autorita nazionale francese per la cybersicurezza. Dipende dal Segretariato generale per la difesa e la sicurezza nazionale, posto sotto l'autorita del Primo ministro, il che la mantiene deliberatamente distinta dagli organismi di intelligence e dalle forze dell'ordine. Questa separazione conta nella pratica: l'ANSSI e difensiva per progettazione, quindi le organizzazioni possono condividere con essa i dettagli di un incidente senza temere che la stessa agenzia sia incaricata anche di operazioni offensive o di azioni giudiziarie. Il suo ambito e ampio. Definisce la politica e la dottrina nazionali di cybersicurezza, gestisce il CERT-FR operativo per la risposta agli incidenti e l'intelligence sulle minacce, vigila sugli operatori di importanza vitale e sulle entita essenziali, e pubblica linee guida e metodi che il resto dell'ecosistema francese tratta come materiale di riferimento. EBIOS Risk Manager, il metodo di analisi del rischio che molte organizzazioni francesi utilizzano per costruire gli scenari di minaccia alla base del loro programma di sicurezza, e mantenuto dall'ANSSI e non da un ente di normazione privato. ## Qualificazioni e visti La parte dell'ANSSI con cui i professionisti hanno a che fare piu direttamente e il suo schema di qualificazione. Anziche limitarsi a scrivere regole, l'ANSSI valuta prodotti e fornitori di servizi rispetto a requisiti pubblicati e concede una qualificazione o un visto di sicurezza. Queste etichette hanno un peso reale perche il settore pubblico e gli operatori regolamentati le richiedono spesso per politica. - SecNumCloud qualifica i fornitori di servizi cloud rispetto a una rigorosa base di sicurezza e sovranita, ed e sempre piu citata come riferimento per i carichi di lavoro sensibili del settore pubblico. - PASSI qualifica i fornitori di audit di sicurezza (penetration test, revisione delle configurazioni, audit dell'architettura) affinche un acquirente sappia che l'auditor e stato valutato rispetto a uno standard comune. - PVID copre i fornitori di verifica dell'identita a distanza, del tipo utilizzato nei flussi di onboarding che devono resistere ai deepfake e alle frodi documentali. > **Perche le etichette contano** Una qualificazione SecNumCloud o PASSI non e un distintivo di marketing. Per le amministrazioni francesi e gli operatori di importanza vitale e spesso una condizione di appalto, quindi perderla o non possederla puo escludere un fornitore da interi bandi. ## L'ANSSI rispetto all'ENISA e il quadro NIS 2 E facile confondere l'ANSSI con l'ENISA, ma si collocano a livelli diversi. L'ANSSI e l'autorita nazionale di uno Stato membro, la Francia. L'ENISA e l'agenzia dell'Unione europea che supporta tutti gli Stati membri e gestisce il quadro europeo di certificazione della cybersicurezza. Cooperano, ma l'ANSSI e l'organo che vigila effettivamente sulle entita francesi e puo agire come autorita competente quando le norme europee vengono recepite nel diritto francese. NIS 2 e l'esempio piu chiaro. La direttiva e europea, ma deve essere recepita e applicata a livello nazionale. In Francia, l'ANSSI e posizionata come l'autorita competente che definisce quali entita rientrano nell'ambito, fissa le aspettative in materia di gestione del rischio e di notifica degli incidenti, e vigila sulla conformita. Cosi, quando un'entita essenziale o importante francese si chiede chi deve notificare dopo un incidente significativo, la risposta operativa passa attraverso l'ANSSI e il CERT-FR, e non direttamente attraverso Bruxelles. Per un professionista della sicurezza o della GRC, l'indicazione pratica e considerare l'ANSSI come tre cose contemporaneamente: un'autorita di policy alle cui linee guida ci si allinea, un ente di qualificazione le cui etichette orientano le scelte di fornitori e strumenti, e un regolatore nazionale e partner di risposta agli incidenti con cui ci si confrontera nell'ambito di NIS 2. --- ## Audit stage 1 / stage 2 **URL:** https://cyberacademy.net/it/resources/encyclopedia/stage-1-2-audit **Last reviewed:** 2026-06-24 La certificazione ISO iniziale si articola in stage 1 (verifica della documentazione e della prontezza operativa, di norma 1-2 giorni) e stage 2 (audit delle evidenze operative, 2-5 giorni). Lo stage 1 conferma che il sistema di gestione esiste sulla carta; lo stage 2 verifica che funzioni concretamente. La maggior parte degli audit stage 2 "falliti" sono problemi di stage 1 che nessuno ha corretto nel frattempo. Una certificazione accreditata rispetto a una norma di sistema di gestione come ISO/IEC 27001 non è una singola visita. L'organismo di certificazione conduce un audit iniziale in due fasi distinte, che rispondono a due domande diverse. La fase 1 chiede se il sistema di gestione esiste ed è pronto per essere sottoposto ad audit. La fase 2 chiede se funziona davvero nella pratica. Trattarle come un unico esame continuo è il modo più comune in cui i team si fanno cogliere di sorpresa, perché le due fasi premiano tipi di preparazione completamente diversi. ## Cosa verifica realmente la fase 1 La fase 1 è un riesame dello stato di preparazione e della documentazione, di solito la più breve delle due. L'auditor legge i vostri documenti fondamentali, conferma che il campo di applicazione è coerente e cerca gli artefatti obbligatori richiesti dalla norma. Per un SGSI ciò significa la Dichiarazione di Applicabilità, il processo di valutazione e trattamento del rischio, la politica di sicurezza, le registrazioni di audit interno e di riesame della direzione, e l'evidenza che il sistema è operativo da abbastanza tempo da produrre dati. Il deliverable non è un certificato. È una sintesi scritta dei rilievi e delle aree di preoccupazione che vi si chiede di chiudere prima della fase 2. In pratica la fase 1 è il vostro sistema di allerta precoce. L'auditor segnala le lacune mentre c'è ancora tempo per correggerle. I team che leggono questi rilievi come un elenco di attività arrivano preparati alla fase 2. I team che li archiviano e tirano avanti sono quelli che poi faticano. ## Cosa verifica la fase 2 La fase 2 è l'audit delle evidenze operative, ed è solitamente più lunga. L'auditor passa dal «la politica dice che» al «mostratemi che è accaduto». Campiona registrazioni, intervista le persone che gestiscono i controlli, traccia gli incidenti e i riesami degli accessi fino alla chiusura, e verifica se il processo documentato corrisponde alla realtà quotidiana. È qui che la Dichiarazione di Applicabilità viene riscontrata con evidenze operative reali, ed è qui che i controlli deboli che sembravano a posto sulla carta si sgretolano. > **Lo schema dietro la maggior parte degli audit di fase 2 «falliti»** Un risultato scadente alla fase 2 è di solito un problema della fase 1 che nessuno ha corretto nel frattempo. L'auditor ve l'aveva detto alla fase 1, avevate settimane per agire, e la lacuna era ancora aperta alla seconda visita. Chiudete deliberatamente i rilievi della fase 1 e la fase 2 riserverà molte meno sorprese. ## Fase 1 e fase 2 a colpo d'occhio **Come differiscono le due fasi per focus ed esito** | Dimensione | Fase 1 | Fase 2 | | --- | --- | --- | | Domanda centrale | Il sistema esiste ed è pronto? | Il sistema opera davvero? | | Input principale | Documentazione e riesame della progettazione | Registrazioni operative, interviste, campionamento | | Durata tipica | Più breve (focalizzata sulla documentazione) | Più lunga (focalizzata sulle evidenze) | | Output principale | Rilievi e aree di preoccupazione da chiudere | Non conformità e decisione di certificazione | | Cosa premia | Documentazione completa e coerente | Disciplina ed evidenze tracciabili nel tempo | ## Cosa fanno i professionisti tra le due visite La finestra tra la fase 1 e la fase 2 è il vero lavoro. I rilievi della fase 1 non sono ancora non conformità, quindi non c'è un piano formale di azioni correttive, ma sono l'auditor che vi dice esattamente dove indagherà la fase 2. I team solidi convertono ogni osservazione della fase 1 in un responsabile, un'azione e una scadenza, poi si assicurano che l'evidenza che la chiude risieda nelle registrazioni che l'auditor campionerà. Mantengono inoltre il sistema in funzione normalmente anziché allestire una pulizia una tantum, perché la fase 2 cerca un'operatività sostenuta, non un'istantanea ordinata. Laddove la fase 2 sollevi effettivamente una non conformità, la risposta è la stessa disciplina che si attende da un audit di sorveglianza: classificarla onestamente come maggiore o minore, pianificare l'azione correttiva con una scadenza, e affrontare la causa radice anziché il sintomo. La decisione di certificazione segue una volta che l'organismo di certificazione è convinto che tali azioni tengano. --- ## Autenticazione a più fattori (MFA) **URL:** https://cyberacademy.net/it/resources/encyclopedia/mfa **Last reviewed:** 2026-06-24 MFA è il requisito per cui l'autenticazione utilizza due o più fattori appartenenti a categorie distinte (conoscenza, possesso, inerenza). Non tutte le MFA sono equivalenti: i codici via SMS e via e-mail sono soggetti a phishing, le notifiche push espongono a fenomeni di fatigue, i token hardware e le passkey rappresentano le forme più robuste. NIS 2 e DORA impongono entrambi una MFA "forte" sugli accessi critici. ## Cosa conta come fattore, e perché è importante L'autenticazione a più fattori richiede due o più prove di identità tratte da categorie diverse, così che compromettere una non consegni l'account a un aggressore. Le tre categorie classiche sono la conoscenza (qualcosa che sai, come una password o un PIN), il possesso (qualcosa che hai, come un telefono, una chiave di sicurezza o una smart card) e l'inerenza (qualcosa che sei, come un'impronta digitale o il volto). La parola decisiva qui è diverse. Due password non costituiscono autenticazione a più fattori, perché appartengono alla stessa categoria e cadono di fronte agli stessi attacchi. Una password più un codice da un dispositivo separato sì, perché ora un aggressore deve sconfiggere due controlli indipendenti contemporaneamente. È anche qui che la MFA e la gestione delle identità si incontrano. La MFA rafforza solo la fase di autenticazione, il momento in cui un utente dimostra chi è. Non dice nulla su ciò che quell'utente è poi autorizzato a fare, che è l'autorizzazione, né sul provisioning, sul deprovisioning o sulle revisioni degli accessi. Considerate la MFA come uno strato rafforzato all'interno di un programma IAM più ampio, non come un sostituto del privilegio minimo o della pulizia degli account orfani. ## Non tutte le MFA sono uguali L'intuizione più importante del professionista è che la MFA esiste lungo uno spettro di robustezza, e la differenza non è cosmetica. I codici monouso via SMS ed e-mail sono migliori di una password da sola, ma sono soggetti a phishing: una pagina di accesso falsa e convincente chiede semplicemente alla vittima di digitare il codice, e un aggressore lo ritrasmette in tempo reale. Il SIM swapping peggiora ulteriormente l'SMS. Le approvazioni tramite notifica push aggiungono un tocco, ma invitano alla fatica da MFA, in cui un aggressore che possiede già la password tempesta di richieste di approvazione finché un utente stanco ne accetta una. Le forme robuste sono fattori di possesso legati al sito legittimo: chiavi di sicurezza hardware e passkey costruite su FIDO2 e WebAuthn. Poiché la credenziale è legata crittograficamente al dominio reale, non rilascia nulla a una pagina che imita l'originale. È questa proprietà che si intende per MFA resistente al phishing. **Metodi di MFA in base alla resistenza agli attacchi comuni** | Metodo | Categoria | Resistente al phishing | Debolezza tipica | | --- | --- | --- | --- | | Codice via SMS o e-mail | Possesso (debole) | No | Ritrasmesso su pagine false, SIM swap | | App di autenticazione TOTP | Possesso | No | Il codice può essere sottratto via phishing in tempo reale | | Approvazione push | Possesso | No | Fatica da MFA e approvazione accidentale | | Chiave hardware (FIDO2) | Possesso | Sì | Costo e logistica di registrazione | | Passkey (WebAuthn) | Possesso più inerenza | Sì | Recupero e associazione al dispositivo | > **La MFA forte è il compito, non una casella da spuntare** I regolatori dicono sempre più spesso forte anziché semplicemente MFA. Distribuire codici SMS per spuntare una casella di conformità lascia spalancata la via del phishing. Date priorità ai metodi resistenti al phishing per gli amministratori, l'accesso remoto e tutto ciò che un aggressore colpirebbe per primo. ## Contesto normativo e degli standard La MFA è passata da raccomandazione ad aspettativa in tutta la regolamentazione europea sulla cibersicurezza. NIS 2 impone alle entità essenziali e importanti di adottare misure di igiene informatica e di controllo degli accessi, con l'autenticazione a più fattori o continua espressamente indicata per la sicurezza degli accessi. DORA impone aspettative comparabili al settore finanziario, dove l'autenticazione forte protegge le funzioni critiche e l'accesso remoto. Entrambi i quadri propendono verso l'estremità forte dello spettro anziché considerare sufficiente qualsiasi MFA. La stessa direzione emerge nelle linee guida del NIST, che privilegiano gli autenticatori resistenti al phishing per gli accessi ad alto valore, e in quadri di riferimento come ISO/IEC 27001 e i CIS Controls, che trattano la MFA come una salvaguardia fondamentale del controllo degli accessi. Ciò che i professionisti fanno realmente è scaglionare l'implementazione in base al rischio. Proteggono prima gli account privilegiati e amministrativi, poi l'accesso remoto ed esposto a Internet, quindi la popolazione generale degli utenti, e scelgono metodi resistenti al phishing ovunque l'impatto di una compromissione sia elevato. Pianificano con cura il recupero e la registrazione, poiché la perdita di fattori rappresenta un costo operativo reale, e monitorano gli schemi di fatica e di elusione. Fatta bene, la MFA toglie silenziosamente valore a una password rubata. Fatta come una casella da spuntare, dà un falso senso di sicurezza mentre il canale soggetto a phishing resta aperto. --- ## Business Continuity Management (BCM) **URL:** https://cyberacademy.net/it/resources/encyclopedia/bcm **Last reviewed:** 2026-06-24 BCM è la disciplina che identifica le minacce alle operazioni critiche e progetta piani e procedure per mantenerle operative durante una disruption. Non si tratta di un progetto una tantum. Il team BCM che performa durante un incidente reale è quello che ha condotto un esercizio tabletop quattro mesi prima e ha documentato i punti di fallimento. ## Che cosa copre realmente la gestione della continuità operativa La gestione della continuità operativa è la disciplina di gestione che mantiene in funzione le attività più importanti di un'organizzazione, o le ripristina rapidamente, quando qualcosa va storto. L'evento scatenante può essere un incidente informatico, il collasso di un fornitore, un'alluvione, un'interruzione di corrente o una pandemia. Non è necessario prevedere la minaccia per nome. Ciò che conta è che l'attività che essa metterebbe fuori uso sia stata identificata, classificata per priorità e dotata di un piano testato per ripristinarla entro un intervallo accettabile. Il perimetro è volutamente ampio. La gestione della continuità operativa considera le persone, le sedi, la tecnologia, i fornitori e le informazioni, non solo il patrimonio informatico. È questa la prima cosa che la distingue dal disaster recovery, il sottoinsieme incentrato sull'informatica che riguarda il ripristino dell'infrastruttura, delle applicazioni e dei dati. Una banca può ripristinare ogni server e comunque non riuscire a operare perché il call center non ha un posto dove insediarsi e il terzo che valorizza le sue operazioni è fuori servizio. La gestione della continuità operativa è responsabile di questo quadro complessivo. È inoltre un ciclo continuo, non un progetto con una data di scadenza. I piani diventano obsoleti nel momento in cui un'organizzazione si riorganizza, adotta un nuovo sistema o integra un nuovo fornitore critico. I team che sono all'altezza durante un incidente reale sono quelli che hanno provato di recente uno scenario e annotato ciò che non ha funzionato, per poi correggerlo prima del giro successivo. ## Il ciclo di vita fondamentale della gestione della continuità operativa La maggior parte dei programmi segue una sequenza riconoscibile, rispecchiata nella norma internazionale ISO 22301: 1. Analisi di impatto sul business. Lo studio strutturato che classifica ogni attività in base alla gravità con cui l'interruzione la danneggia nel tempo e produce gli obiettivi di ripristino. 1. Valutazione del rischio. Identificare le minacce e le vulnerabilità con maggiore probabilità di interrompere le attività prioritarie. 1. Strategia e soluzioni. Scegliere come mantenere in funzione le attività o ripristinarle: siti alternativi, soluzioni alternative, ridondanza, diversificazione dei fornitori. 1. Piani e procedure. Redigere il piano di continuità operativa, la struttura di risposta agli incidenti e i runbook di ripristino che le persone useranno effettivamente sotto pressione. 1. Esercitazioni e revisione. Esercitazioni teoriche e test dal vivo, revisioni post-incidente e audit che reimmettono le correzioni nel ciclo. > **I numeri vengono dal business, non dalla sala server** Gli obiettivi di tempo di ripristino e di punto di ripristino appartengono alle persone responsabili del processo, convalidati attraverso l'analisi di impatto sul business. Gli obiettivi di RTO e RPO che un team tecnico fissa isolatamente sono quelli che falliscono quando un'interruzione reale li mette alla prova. ## Il posto della gestione della continuità operativa nel panorama normativo La continuità è passata da buona pratica a obbligo vigilato in diversi settori. ISO 22301 specifica i requisiti di un sistema di gestione della continuità operativa certificabile ed è il riferimento a cui si allinea la maggior parte delle organizzazioni. Nell'Unione europea, il Digital Operational Resilience Act stabilisce aspettative di continuità e di test per le entità finanziarie, e la Direttiva NIS 2 richiede misure di continuità operativa, comprese le copie di backup e la gestione delle crisi, agli operatori dei settori essenziali e importanti. La certificazione non è obbligatoria per condurre bene la gestione della continuità operativa, ma fornisce ad auditor, autorità di regolamentazione e grandi clienti una base riconosciuta. Che un programma persegua o meno un certificato, si applicano le stesse discipline: conoscere le proprie attività critiche, fissare obiettivi di ripristino difendibili, redigere piani utilizzabili e dimostrare che funzionano testandoli. --- ## Business Email Compromise (BEC) **URL:** https://cyberacademy.net/it/resources/encyclopedia/bec **Last reviewed:** 2026-06-24 BEC è l'attacco di social engineering mirato che impersona un dirigente o un fornitore per dirottare un pagamento o indurre un dipendente ad approvarlo. Nessun malware richiesto: puro pretexting. La perdita media per incidente supera di gran lunga quella del ransomware. I controlli di processo (segregazione dei compiti, verifica tramite richiamata) lo individuano; la tecnologia da sola non basta. ## Cosa distingue il BEC dal phishing ordinario Il Business Email Compromise è una frode condotta tramite pretesto anziché tramite payload. L'attaccante non ha bisogno di un link malevolo né di un allegato che installa malware. Gli serve una storia plausibile, un senso di urgenza e una vittima con l'autorità di spostare denaro o dati. Un dominio falsificato o somigliante, una casella di posta compromessa o un indirizzo registrato di recente che assomiglia a un fornitore noto bastano a preparare la scena. Poiché nulla di tecnicamente malevolo transita sulla rete, i gateway di posta sicura, gli antivirus e le sandbox dei link lasciano spesso passare il messaggio. L'attacco vive interamente nella conversazione. Per questo il BEC si colloca accanto al phishing nella stessa famiglia, pur comportandosi diversamente nella pratica. Il phishing generico è una rete ampia lanciata per ottenere credenziali o clic. Il BEC è paziente e mirato: l'attaccante studia l'organigramma, individua chi approva le fatture, osserva il tono delle email interne e attende un momento credibile, come un'acquisizione, una compravendita immobiliare o un direttore finanziario in trasferta all'estero. Il guadagno è un singolo bonifico fraudolento o un accredito stipendiale dirottato, spesso di importo elevato, anziché una password sottratta. ## Le varianti comuni che incontrano i professionisti Il BEC è una categoria, non un singolo trucco. La stessa logica di pretesto viene riutilizzata contro qualunque processo che muove valore all'interno dell'organizzazione. - Frode del CEO: un attaccante impersona un alto dirigente e fa pressione su un dipendente della funzione finanziaria perché esegua un bonifico urgente e riservato, facendo leva sulla gerarchia e sulla discrezione per scoraggiare le domande. - Frode del fornitore, detta anche dirottamento delle fatture: un fornitore fidato sembra inviare via email nuove coordinate bancarie, così che la successiva fattura legittima venga pagata sul conto dell'attaccante. - Dirottamento dello stipendio: un dipendente sembra chiedere la modifica del conto di destinazione del proprio stipendio, reindirizzando di nascosto la propria retribuzione verso il truffatore. - Compromissione dell'account: una vera casella di posta interna viene compromessa, così che la richiesta fraudolenta arrivi da un indirizzo autentico con uno storico autentico, il che elimina la maggior parte dei consueti segnali d'allarme. - Impersonificazione di avvocato o consulente legale: il pretesto fa leva su un'operazione riservata e con tempi stretti, in cui ci si aspetta segretezza e la verifica appare sgarbata. ## Perché qui il processo batte la tecnologia L'autenticazione delle email aiuta. SPF, DKIM e DMARC aumentano il costo della falsificazione diretta del dominio e dovrebbero essere implementati. Ma non fanno nulla contro un dominio somigliante, un indirizzo di posta web gratuito o una casella di posta interna realmente compromessa, che sono i canali più usati dal BEC reale. I controlli decisivi sono procedurali, di competenza della funzione finanziaria e operativa anziché degli strumenti di sicurezza. - Separazione dei compiti, in modo che nessuna singola persona possa sia richiedere sia autorizzare un pagamento. - Verifica con richiamo fuori banda: confermare qualunque coordinata bancaria nuova o modificata, e qualunque bonifico insolito, utilizzando un numero di telefono già agli atti, mai un numero o un contatto fornito all'interno della richiesta stessa. - Una regola ferma secondo cui urgenza e riservatezza non aggirano mai il normale iter di approvazione; queste due emozioni sono gli strumenti dell'attaccante. - Soglie di doppia autorizzazione per i bonifici e per le modifiche delle coordinate bancarie dei fornitori. > **Verificare la richiesta, non la casella di posta** Il BEC più pericoloso arriva da un indirizzo reale e fidato perché la casella di posta è stata compromessa. Un mittente impeccabile, una firma valida e un blocco firma familiare non provano nulla. Verificate l'istruzione stessa tramite un canale separato prima che il denaro si muova. ## Dove si colloca il BEC nel quadro normativo Il BEC è una causa primaria di perdite finanziarie legate alla posta elettronica, il che lo colloca pienamente nell'ambito che un sistema di gestione della sicurezza delle informazioni è chiamato ad affrontare. Sotto un SGSI ISO 27001 il trattamento pertinente combina formazione di sensibilizzazione, controlli sulle relazioni con i fornitori e le procedure operative che disciplinano i pagamenti. Quando il BEC ha successo e vengono esposti dati personali, per esempio tramite una casella di posta compromessa piena di corrispondenza, può anche far scattare obblighi di violazione dei dati personali ai sensi del GDPR, ed è per questo che il piano di risposta deve coinvolgere l'ufficio legale e la funzione di protezione dei dati, non solo la finanza e l'IT. Per i professionisti, il messaggio è che la difesa dal BEC è una responsabilità condivisa. La sicurezza presidia l'autenticazione delle email, il monitoraggio e la sensibilizzazione. La finanza presidia i controlli sui pagamenti che fermano davvero la frode. Trattarlo come un problema puramente tecnico da risolvere con un gateway migliore è l'errore che tiene in vita le perdite. --- ## Business Impact Analysis (BIA) **URL:** https://cyberacademy.net/it/resources/encyclopedia/bia **Last reviewed:** 2026-06-24 Una BIA è l'analisi strutturata che quantifica l'impatto di un'interruzione su ciascuna attività critica nel tempo. Gli output includono il recovery time objective, il recovery point objective e il minimum business continuity objective. Input obbligatorio per ISO 22301 e DORA. Eseguita correttamente, diventa il documento che il board legge davvero. ## Cosa fa davvero una BIA Una Business Impact Analysis risponde a una domanda da cui dipende il resto del programma di continuità: se questa attività si ferma, quanto diventa grave la situazione, e quanto velocemente? Si prende ciascuna attività di business, la si proietta nel tempo e si descrivono le conseguenze della sua interruzione a ogni intervallo. Alcune attività fanno male nel giro di minuti, l'elaborazione dei pagamenti o lo sportello accettazioni di un ospedale. Altre possono restare ferme per giorni prima che qualcuno al di fuori del team se ne accorga. La BIA è ciò che distingue le due, in modo che le scarse risorse di ripristino vadano dove il danno si accumula più rapidamente e non dove siede il manager che alza di più la voce. L'impatto è valutato su più dimensioni, non solo la perdita di ricavi. La perdita finanziaria è quella più ovvia, ma una BIA seria cattura anche l'esposizione normativa e legale, le penali contrattuali, la sicurezza delle persone e il danno reputazionale. Una conseguenza banale in euro può essere esistenziale in termini di fiducia. Il senso di guardare attraverso le dimensioni è che l'attività in cima alla lista sul piano economico raramente è la stessa che è in cima alla lista sul piano legale o della sicurezza, e il consiglio deve vederle tutte prima di stabilire le priorità. ## Dall'impatto agli obiettivi La BIA non si ferma alla descrizione. Produce i numeri su cui si costruisce la strategia di ripristino. Man mano che l'impatto cresce nel tempo, si raggiunge il punto in cui diventa inaccettabile. Quella soglia fissa il recovery time objective, il periodo massimo tollerabile in cui l'attività può restare ferma. Il recovery point objective deriva dallo stesso esercizio sul versante dei dati: quanto lavoro recente, misurato in tempo, può essere perso prima che l'interruzione causi un danno inaccettabile. Il minimum business continuity objective descrive il livello operativo ridotto che si deve sostenere durante l'interruzione, non il servizio completo, ma abbastanza per restare vitali. Questi output sono l'input formale alla strategia di continuità. Un recovery time objective è un requisito imposto alla soluzione di ripristino, non un desiderio. Se la BIA dice che un'attività deve essere ripristinata entro una finestra stretta, la strategia e il budget devono garantirlo, oppure l'organizzazione deve accettare consapevolmente lo scarto. È per questo che la BIA è il documento che dovrebbe essere approvato dai responsabili di business e letto dal consiglio, anziché redatto dall'IT in isolamento. > **I numeri appartengono al business** Il fallimento più comune è una BIA in cui gli obiettivi di ripristino sono stati fissati dal personale tecnico senza i responsabili dell'attività nella stanza. Quei numeri sembrano precisi sulla carta e crollano davanti a un incidente reale, perché nessuno che porta la conseguenza li ha mai concordati. Convalidate ogni RTO e RPO con le persone responsabili dell'attività. ## Dove si colloca la BIA negli standard Secondo ISO 22301, la BIA è un passo obbligatorio per istituire un sistema di gestione della continuità operativa. Lo standard si aspetta che si determinino le attività che supportano la fornitura di prodotti e servizi, si valutino gli impatti nel tempo del loro mancato svolgimento e li si usi per fissare tempi prioritizzati di ripresa. La BIA alimenta direttamente la valutazione del rischio e la scelta della strategia di continuità. Secondo DORA, la stessa logica si applica alla resilienza operativa digitale: ci si aspetta che le entità finanziarie comprendano l'impatto di un'interruzione sulle loro funzioni critiche o importanti, e quella comprensione parte da un'analisi d'impatto. Una BIA non è una valutazione del rischio, e confondere le due indebolisce entrambe. La valutazione del rischio chiede cosa potrebbe causare un'interruzione e quanto è probabile. La BIA è deliberatamente agnostica rispetto alle minacce: chiede quanto fa male un'interruzione a prescindere dalla causa, che l'innesco sia un attacco informatico, un'alluvione o un fornitore inadempiente. Le si conduce come esercizi complementari. La BIA dice cosa deve essere protetto e quanto rapidamente deve riprendersi; la valutazione del rischio dice cosa è più probabile che lo minacci. Insieme giustificano dove va l'investimento in continuità. In pratica, una BIA si ripete secondo un ciclo e dopo un cambiamento rilevante, perché attività, dipendenze e tolleranze derivano. Il fornitore che l'anno scorso era periferico è ora sul vostro percorso critico; il processo che potevate perdere per due giorni è ora a contatto con il cliente. Una BIA vecchia di due ristrutturazioni è decorazione. --- ## CIS Controls **URL:** https://cyberacademy.net/it/resources/encyclopedia/cis-controls **Last reviewed:** 2026-06-24 I CIS Critical Security Controls sono un insieme prioritizzato di 18 categorie di controllo pubblicato dal Center for Internet Security. I gruppi di implementazione (IG1, IG2, IG3) corrispondono alla maturità dell'organizzazione. Il metodo più rapido per portare una piccola o media organizzazione da zero a un livello di difesa adeguato. Si mappa in modo preciso sull'Annex A di ISO 27001. ## Cosa sono realmente i CIS Controls I CIS Critical Security Controls sono una risposta ordinata e netta a una domanda che ogni difensore si pone: tra tutte le cose che potresti fare, quali dovresti fare per prime? Pubblicati e mantenuti dal Center for Internet Security, distillano dati di attacchi reali in un insieme prioritizzato di misure di salvaguardia raggruppate in 18 categorie di controlli, dall'inventario degli asset e del software aziendali alla protezione dei dati, al controllo degli accessi, alla gestione continua delle vulnerabilità, alla gestione dei log di audit e alla risposta agli incidenti. A differenza di un framework che ti dice di stabilire un processo, i Controls ti dicono concretamente cosa implementare e, grossomodo, in quale ordine, motivo per cui sono spesso la via più rapida per passare dall'assenza di un programma di sicurezza a uno difendibile. La caratteristica distintiva è la prioritizzazione. L'elenco non è alfabetico né teorico; i controlli iniziali sono quelli che bloccano gli attacchi più comuni. Sapere quale hardware e software possiedi, configurarlo in modo sicuro, controllare i privilegi amministrativi e applicare le patch alle vulnerabilità note previene una larga parte degli incidenti reali prima ancora di spendere un solo euro in strumenti avanzati. È questo ordine a costituire il valore: un piccolo team con tempo limitato può partire dall'alto e procedere verso il basso, certo di chiudere le falle che gli attaccanti sfruttano davvero. ## Gli Implementation Groups: IG1, IG2, IG3 I Controls si adattano alla scala grazie a tre Implementation Groups, così che lo stesso catalogo serva sia un'azienda di due persone sia una multinazionale. IG1 è definito come igiene cyber di base, l'insieme minimo che ogni organizzazione dovrebbe avere in atto, pensato per le imprese con competenze e risorse limitate per proteggersi da attacchi non sofisticati e opportunistici. IG2 aggiunge misure di salvaguardia per le organizzazioni che gestiscono dati più sensibili e affrontano avversari più capaci. IG3 è l'insieme completo, destinato alle organizzazioni mature che detengono asset critici e devono difendersi da attacchi mirati e sofisticati. Ogni gruppo è cumulativo: IG2 include tutto ciò che è in IG1, e IG3 include tutto ciò che è in IG1 e IG2. **CIS Implementation Groups** | Gruppo | A chi si adatta | Postura | | --- | --- | --- | | IG1 | Organizzazioni piccole e medie, risorse IT e di sicurezza limitate | Igiene cyber essenziale, difesa di base | | IG2 | Organizzazioni che detengono dati più sensibili, personale di sicurezza dedicato | Irrobustita contro attaccanti più capaci | | IG3 | Organizzazioni mature con asset critici ed elevata esposizione | Insieme completo di misure di salvaguardia contro attacchi mirati | In pratica ti autovaluti per collocarti in un Implementation Group, poi tratti le misure di salvaguardia di quel gruppo come il tuo piano di lavoro. La maggior parte delle organizzazioni piccole e medie dovrebbe puntare decisamente prima a IG1 e passare a IG2 solo una volta che questo è consolidato. È ciò che rende i Controls accessibili laddove un sistema di gestione completo può sembrare fuori portata: ti viene consegnata una checklist finita, verificabile e dimensionata sulla tua realtà. ## Dove si collocano accanto alla ISO 27001 e ad altri framework I CIS Controls sono un catalogo di controlli, non un sistema di gestione certificabile, e questa distinzione conta. La ISO 27001 certifica che gestisci un sistema di gestione della sicurezza delle informazioni con valutazione del rischio, una Dichiarazione di Applicabilità e miglioramento continuo; il CIS ti fornisce un insieme concreto e prioritizzato di misure di salvaguardia tecniche e operative da implementare al di sotto. Sono complementari piuttosto che concorrenti. Il CIS pubblica le corrispondenze tra le sue misure di salvaguardia e l'Annex A della ISO 27001 e altri riferimenti come i framework NIST, così che il lavoro di implementazione svolto per il CIS diventi una prova che puoi presentare a fronte di un insieme di controlli ISO. I team usano spesso il CIS per guidare l'irrobustimento pratico e poi mappare quello sforzo verso il framework richiesto dai loro auditor o clienti. > **Comincia dall'alto, non da ogni parte** I Controls sono ordinati per un motivo. Un piccolo team ottiene più protezione completando IG1 nell'ordine, partendo dall'inventario degli asset e del software e dalla configurazione sicura, che selezionando a piacere misure di salvaguardia avanzate mentre le basi restano scoperte. --- ## COBIT **URL:** https://cyberacademy.net/it/resources/encyclopedia/cobit **Last reviewed:** 2026-06-24 COBIT è il framework ISACA per la governance e la gestione dell'IT aziendale. L'edizione corrente è COBIT 2019. È il framework utilizzato dalle Big Four per valutare la maturità della governance IT e il riferimento per la certificazione CGEIT. Più strategico di ISO 27001; meno prescrittivo di NIST. ## Che cosa governa realmente COBIT COBIT è il framework di ISACA per la governance e la gestione dell'IT aziendale. La sua distinzione fondamentale, e quella su cui i professionisti inciampano più spesso, è la linea che traccia tra governance e gestione. La governance riguarda il consiglio di amministrazione e il livello esecutivo: definire la direzione, valutare le opzioni e monitorare i risultati. La gestione riguarda la pianificazione, la costruzione, l'esecuzione e il monitoraggio delle attività che realizzano tale direzione. COBIT mantiene queste due dimensioni come domini separati, affinché chi decide ciò che l'IT deve realizzare non coincida con chi rendiconta se è stato realizzato. Quella separazione è il motivo per cui gli auditor ricorrono a COBIT quando una norma di sicurezza delle informazioni non basta. ISO 27001 indica come far funzionare un sistema di gestione della sicurezza delle informazioni. NIST fornisce un catalogo di controlli e di risultati. COBIT si colloca al di sopra di entrambi: risponde alla domanda se l'IT nel suo complesso sia orientato verso gli obiettivi dell'azienda, se il rischio e le risorse siano gestiti in modo responsabile, e se gli stakeholder ottengano valore. È più ampio della sicurezza e deliberatamente meno prescrittivo di un elenco di controlli. ## La struttura di COBIT 2019 L'edizione attuale è COBIT 2019. Organizza il lavoro in obiettivi raggruppati sotto i domini di governance e di gestione, e associa a ciascuno i componenti necessari per farlo funzionare: processi, strutture organizzative, politiche, flussi informativi, cultura, competenze e servizi. Il punto è che un processo sulla carta non significa nulla se mancano le strutture, le competenze e la cultura che lo circondano, perciò COBIT vi obbliga a esaminarli tutti insieme. Due idee rendono COBIT 2019 utilizzabile nella pratica, e non semplicemente un poster appeso al muro: - I fattori di progettazione. La strategia aziendale, il profilo di rischio, i requisiti di conformità, il ruolo dell'IT e il modello di sourcing determinano insieme quali obiettivi meritano attenzione. COBIT non presuppone che ogni organizzazione abbia bisogno dello stesso sistema di governance, quindi si adatta il framework al contesto anziché adottarlo integralmente. - La capacità e la maturità. Ogni obiettivo di governance e di gestione può essere valutato su una scala di capacità, e il framework supporta anche una visione della maturità per aree di interesse. È così che le Big Four e i team di internal audit producono un quadro difendibile del «dove siamo, dove dovremmo essere» anziché un'opinione soggettiva. > **COBIT è una lente, non una checklist** Non si «implementa COBIT» nel modo in cui si implementa un SGSI. Lo si utilizza per valutare quanto bene l'IT sia governato, per progettare un sistema di governance adatto al proprio contesto, e per mappare e razionalizzare le norme già in uso, come ISO 27001, NIST o ITIL, in un insieme coerente. ## Dove si colloca COBIT rispetto agli altri framework I professionisti utilizzano quasi sempre COBIT accanto ad altri framework anziché al loro posto. Uno schema comune: COBIT definisce gli obiettivi di governance e la baseline di maturità, ISO 27001 rende operativa la sicurezza delle informazioni, ITIL gestisce i servizi, e un framework di rischio alimenta il quadro del rischio. COBIT diventa l'ombrello che mostra come questi elementi servono gli obiettivi aziendali e dove si trovano le lacune. **COBIT a confronto con framework affini** | Framework | Focus principale | Posizionamento | | --- | --- | --- | | COBIT | Governance e gestione dell'IT aziendale | Strategico, a livello di framework, adattato al contesto | | ISO 27001 | Sistema di gestione della sicurezza delle informazioni | Certificabile, operativo, ambito sicurezza | | Framework NIST | Risultati di cybersecurity e cataloghi di controlli | Dettagliato, prescrittivo, orientato ai controlli | | ITIL | Gestione dei servizi IT | Operativo, focalizzato sull'erogazione dei servizi | COBIT è anche il corpo di conoscenze alla base della certificazione CGEIT di ISACA, rivolta ai professionisti responsabili della governance dell'IT aziendale. Se il vostro ruolo è garantire o progettare il modo in cui l'IT viene guidato a livello di consiglio, COBIT è il framework di riferimento e CGEIT la certificazione corrispondente. --- ## Certificate of Cloud Auditing Knowledge (CCAK) **URL:** https://cyberacademy.net/it/resources/encyclopedia/ccak **Last reviewed:** 2026-06-24 CCAK è la credenziale congiunta ISACA / Cloud Security Alliance per i revisori cloud. Copre la governance cloud, il CCM, il programma STAR e le considerazioni di audit specifiche degli hyperscaler. L'estensione naturale per chi detiene il CISA e opera in ambienti cloud-first. ## Cosa certifica davvero il CCAK Il Certificate of Cloud Auditing Knowledge è una credenziale congiunta di ISACA e Cloud Security Alliance e risponde a una lacuna precisa. La formazione tradizionale in audit IT presuppone che tu possa percorrere il data center, esaminare i ticket di change e testare end to end i controlli che l'organizzazione possiede interamente. Nel cloud questo presupposto crolla. Il fornitore gestisce l'infrastruttura fisica, l'hypervisor e gran parte della piattaforma, e tu non li vedi mai. Il CCAK è costruito attorno a come auditare e dare assurance a questo assetto: come si ripartisce la responsabilità dei controlli tra cliente e fornitore, quali evidenze puoi ottenere davvero, e come ragionare sull'assurance quando non puoi eseguire tu stesso il test. È un certificato di conoscenze più che una certificazione vincolata all'esperienza, quindi non ha associato un requisito di esperienza pluriennale come accade per il CISA. Questo lo rende accessibile prima nella carriera, ma è posizionato come complemento di credenziali di audit più approfondite anziché come sostituto. Il lettore naturale è qualcuno che padroneggia già il metodo di audit e ora ha bisogno dello strato specifico del cloud al di sopra. ## Cosa copre il corpo di conoscenze Il CCAK è ancorato agli strumenti propri della CSA anziché alla documentazione di un singolo fornitore, ed è ciò che lo mantiene neutrale rispetto al vendor. I principali punti di riferimento con cui i professionisti imparano a lavorare includono: - La Cloud Controls Matrix (CCM), il framework di controlli della CSA mappato attraverso i domini del cloud e messo in corrispondenza con norme come ISO 27001 e i principali regimi regolatori. È il catalogo di controlli rispetto al quale valuti un ambiente cloud. - Il Consensus Assessments Initiative Questionnaire (CAIQ), l'insieme standardizzato di domande che un cliente pone a un fornitore per capire quali controlli della CCM il fornitore gestisce e come. - Il programma STAR (Security, Trust, Assurance and Risk), il registro di assurance della CSA. STAR ha livelli che vanno dall'autovalutazione del fornitore fino alla certificazione da parte di terzi, e il CCAK ti insegna a leggere cosa ciascun livello dimostra e cosa non dimostra. - La responsabilità condivisa, l'allocazione dei controlli e le considerazioni di audit specifiche di ciascun fornitore attraverso i principali hyperscaler, così da sapere quali controlli testi tu, quali il fornitore attesta e dove si trova la giunzione tra i due. > **Un certificato di conoscenze, non una certificazione di SGSI** Il CCAK certifica le conoscenze di una persona in materia di audit del cloud. È distinto da CSA STAR, che è il modo in cui un servizio cloud stesso ottiene assurance. Impari a valutare STAR; STAR non viene rilasciato a te. ## Dove si colloca il CCAK rispetto a CISA e CCSP I professionisti confondono regolarmente il CCAK con le due credenziali tra cui si trova, quindi vale la pena tracciare la distinzione in modo netto. Il CISA stabilisce che sei in grado di auditare i sistemi informativi, punto. Il CCSP, di (ISC)2, è una credenziale ampia di progettazione e architettura della sicurezza cloud. Il CCAK è più ristretto e più specifico di entrambi: riguarda l'assurance del cloud, non la sua costruzione e non l'audit dei sistemi in generale. **Il CCAK a confronto con le credenziali vicine** | Credenziale | Focus principale | Postura | | --- | --- | --- | | CCAK | Audit e assurance di ambienti cloud | Specifico del cloud, basato sulle conoscenze, neutrale rispetto al vendor | | CISA | Audit dei sistemi informativi in generale | Metodo di audit ampio, vincolato all'esperienza | | CCSP | Progettazione e messa in sicurezza dell'architettura cloud | Architettura di sicurezza, non incentrata sull'audit | In pratica l'abbinamento più solido è CISA più CCAK. Il CISA fornisce la disciplina di audit, gli standard di evidenza e la mentalità di indipendenza; il CCAK aggiunge lo strato cloud, così che un titolare del CISA il cui perimetro è diventato cloud-first possa valutare i confini della responsabilità condivisa e leggere le evidenze STAR senza riapprendere l'audit da zero. È la progressione che il CCAK è concepito per servire. --- ## Certificazione Cybersecurity Practitioner (CSX-P) **URL:** https://cyberacademy.net/it/resources/encyclopedia/csx-p **Last reviewed:** 2026-06-24 CSX-P è la certificazione pratica di cybersecurity di ISACA, basata sulla performance. Viene verificata in un ambiente cyber-range live sulle cinque funzioni del NIST CSF. Meno nota di CISM o CISA, ma tra le rare credenziali in cui l'esame valuta ciò che si sa fare concretamente, non ciò che si sa scrivere. Il CSX-P (Cybersecurity Practitioner) è la risposta di ISACA a una critica ricorrente rivolta alle certificazioni di sicurezza: che la maggior parte verifica se sai riconoscere la risposta giusta in un quesito a scelta multipla, non se sai fare il lavoro. Il CSX-P si sostiene in un ambiente cyber-range dal vivo, dove il candidato viene immerso in scenari realistici e deve operare con strumenti reali a fronte di condizioni reali. È costruito attorno alle funzioni del NIST Cybersecurity Framework, così che l'esame segue il ciclo di vita che vive un difensore anziché un elenco di definizioni memorizzate. ## Ciò che distingue il CSX-P: un esame basato sulla performance La maggior parte delle credenziali note, comprese le stesse CISM e CISA di ISACA, sono esami di conoscenza e giudizio. Rispondi a domande; la certificazione attesta che comprendi i concetti e sai ragionarci sopra. Il CSX-P ribalta questo approccio. Invece di chiederti cosa faresti, ti colloca in un ambiente e osserva cosa fai davvero. Il candidato svolge attività attraverso le funzioni del NIST CSF, usando sistemi e strumenti di sicurezza reali, in condizioni progettate per assomigliare al lavoro. Per questo la shortDefinition lo presenta come la rara credenziale che valuta ciò che fai anziché ciò che sai scriverne. - Identify: comprendere l'ambiente, i suoi asset e dove risiede l'esposizione. - Protect: applicare e configurare controlli per ridurre tale esposizione. - Detect: individuare attività anomale o malevole nella telemetria invece di attendere che vengano segnalate. - Respond: contenere un incidente e agire una volta riconosciuto. - Recover: ripristinare sistemi e servizi a uno stato integro noto dopo l'evento. > **Basato sulla performance, per progettazione** Il CSX-P è un esame pratico e guidato da scenari in un laboratorio virtuale. L'obiettivo è dimostrare capacità operativa in condizioni realistiche. Ciò lo avvicina, nello spirito, a una valutazione pratica di laboratorio più che a una certificazione scritta tradizionale. ## Il CSX-P accanto a CISM e CISA Il CSX-P è meno noto del CISM o del CISA, e questo divario riflette il pubblico di riferimento più che il rigore. Il CISM è per chi governa un programma di sicurezza, e il CISA per chi fornisce assurance indipendente sui controlli. Entrambi validano il giudizio e capacità di gestione o di audit. Il CSX-P valida l'esecuzione tecnica: sei davvero in grado di difendere un ambiente lungo l'intero ciclo di vita del NIST CSF. Sono segnali complementari, non concorrenti, e un team solido può detenere tutti e tre tra persone diverse. **Esame di conoscenza vs esame di performance** | Credenziale | Centro di gravità | Come viene valutata | | --- | --- | --- | | CSX-P | Pratica operativa di cybersecurity | Cyber-range dal vivo, basato sulla performance | | CISM | Governance di un programma di sicurezza | Conoscenza e giudizio, scritto | | CISA | Audit e assurance dei SI | Conoscenza e giudizio, scritto | Poiché il CSX-P dimostra il fare anziché il sapere, si adatta male a chi punta dritto all'audit o alla governance e molto bene a chi vuole vedere riconosciuta la propria capacità operativa di difesa. La decisione riguarda il ruolo, non l'anzianità: un professionista che lavora sul campo trae vantaggio da una credenziale che rispecchia il suo lavoro, mentre a un manager o a un auditor di solito conviene di più il CISM o il CISA. ## A chi è rivolto Il CSX-P ha più senso per i professionisti tecnici: analisti, difensori e ingegneri che già svolgono, o vogliono orientarsi verso, operazioni di sicurezza pratiche attraverso le funzioni del NIST CSF. Essendo ancorato a quel framework, si adatta a chi lavora in ambienti che già usano il CSF come riferimento, comprese le organizzazioni transatlantiche che lo abbinano alla ISO 27001. Come per qualsiasi certificazione, un datore di lavoro valuta in ultima analisi la capacità dimostrata. Il valore del CSX-P sta proprio nel fatto che offre un modo strutturato e indipendente dai fornitori per provare le competenze pratiche che il suo nome indica, invece di chiedere a un datore di lavoro di dare per scontata la competenza. --- ## Certified Cybersecurity Operations Analyst (CCOA) **URL:** https://cyberacademy.net/it/resources/encyclopedia/ccoa **Last reviewed:** 2026-06-24 CCOA è la certificazione operativa hands-on di ISACA per la cybersecurity, focalizzata sul lavoro in SOC: monitoraggio, rilevamento, risposta, ripristino. Il complemento tecnico al CISM. Indicata per analisti e incident responder, non per manager o auditor. Il Certified Cybersecurity Operations Analyst (CCOA) è la credenziale di ISACA rivolta a chi lavora nel centro operativo di sicurezza e svolge il lavoro tecnico, non a chi redige le policy al di sopra di loro. È costruita attorno alla realtà quotidiana di un SOC: monitorare la telemetria, separare i segnali reali dal rumore, investigare gli alert, contenere gli incidenti e riportare i sistemi a uno stato integro noto. Laddove la maggior parte delle certificazioni ISACA convalida la governance, l'audit o il giudizio gestionale, il CCOA convalida se sai effettivamente operare gli strumenti e rispondere a ciò che fanno emergere. ## Cosa convalida il CCOA Il CCOA si articola attorno al ciclo di vita operativo che un difensore vive in una settimana normale. Le competenze che certifica corrispondono al lavoro di monitorare un ambiente, riconoscere quando qualcosa non va, agire di conseguenza e ripristinare il servizio. In pratica, ciò significa padronanza in alcune aree connesse. - Monitoraggio e rilevamento: lavorare con log, telemetria di rete ed endpoint e strumenti di rilevamento per individuare attività anomale o malevole anziché attendere che vengano segnalate. - Triage e investigazione: decidere quali alert sono reali, delimitare il raggio d'impatto e ricostruire l'accaduto a partire dalle prove disponibili. - Risposta agli incidenti: contenere, eradicare e recuperare dagli incidenti, quindi documentare quanto appreso affinché la stessa lacuna non si riapra. - Padronanza tecnica di base: reti, sistemi operativi, tecniche di attacco comuni e i controlli di sicurezza che si frappongono tra un attaccante e l'asset. > **Una credenziale pratica, per progettazione** Il CCOA si posiziona come una certificazione pratica, orientata alle prestazioni. L'obiettivo è dimostrare che sai svolgere il lavoro in un ambiente reale, non solo descriverne la teoria. Questo le conferisce un carattere diverso dallo stile basato su conoscenza e giudizio delle certificazioni di gestione e audit di ISACA. ## Il CCOA accanto al CISM e al resto dello stack ISACA Il modo più chiaro per collocare il CCOA è pensare a chi è titolare di quale domanda. Il CISM, la credenziale di punta di gestione di ISACA, è per la persona responsabile del programma di sicurezza: strategia, governance, rischio e quadro di gestione degli incidenti. Il CCOA è per la persona che esegue all'interno di quel quadro quando scatta un alert alle 2 di notte. Sono complementari, non in concorrenza. Un team può sensatamente avere un manager titolare del CISM che imposta la direzione e analisti titolari del CCOA che svolgono la difesa operativa al di sotto. È esattamente per questo che la shortDefinition definisce il CCOA il complemento tecnico del CISM. **Dove si colloca il CCOA tra le credenziali ISACA** | Credenziale | Pubblico principale | Baricentro | | --- | --- | --- | | CCOA | Analisti SOC, responder agli incidenti | Rilevamento, risposta e ripristino pratici | | CISM | Manager e responsabili della sicurezza | Governance, strategia e rischio del programma | | CISA | Auditor dei SI | Assurance indipendente e test dei controlli | | CRISC | Professionisti del rischio e dei controlli | Gestione del rischio IT aziendale | Poiché il CCOA è incentrato sull'esecuzione, è poco adatto a chi vuole spostarsi verso l'audit o la governance e molto adatto a chi vuole vedersi riconoscere la propria capacità operativa. Gli analisti e i responder ottengono un segnale neutrale rispetto al fornitore del fatto che sanno difendere un ambiente; i manager e gli auditor sono di solito serviti meglio dal CISM, dal CISA o dal CRISC. Affronta la scelta come una questione di ruolo, non di anzianità. ## A chi è destinato Il CCOA ha più senso per professionisti già impegnati in un ruolo operativo di blue team o in transizione verso di esso: analisti SOC di livello uno e due, responder agli incidenti junior e ingegneri del rilevamento che vogliono una credenziale riconosciuta che rifletta ciò che realmente fanno. È anche un passo successivo coerente per chi è partito dal lato tecnico e vuole un badge sostenuto da ISACA senza passare alla gestione. Come per qualunque certificazione, i datori di lavoro valutano in ultima analisi la capacità dimostrata, perciò il valore del CCOA sta nel fornire un modo strutturato e neutrale rispetto al fornitore di dimostrare le competenze operative che il titolo nomina. --- ## Certified Data Privacy Solutions Engineer (CDPSE) **URL:** https://cyberacademy.net/it/resources/encyclopedia/cdpse **Last reviewed:** 2026-06-24 CDPSE è la certificazione tecnica sulla privacy di ISACA. Tre domini: governance della privacy, architettura della privacy, ciclo di vita del dato. È il complemento tecnico-ingegneristico delle certificazioni DPO/CDPO orientate alle policy. Adatta ai team di sicurezza responsabili dell'implementazione della privacy e agli architetti che operano nell'ambito del GDPR o dell'AI Act. ## A cosa serve CDPSE CDPSE è la risposta di ISACA a una lacuna apertasi quando la privacy ha smesso di essere un esercizio puramente giuridico. Redigere una politica sulla privacy, mappare le basi giuridiche e rispondere alle richieste degli interessati è il lavoro di un responsabile della protezione dei dati. Ma nulla di tutto ciò impedisce a un'API vulnerabile di esporre dati personali, garantisce che la pseudonimizzazione sia applicata correttamente o integra la logica di consenso e conservazione in un sistema prima del suo rilascio. CDPSE certifica le persone che svolgono questo lavoro tecnico: gli ingegneri, gli architetti e i professionisti della sicurezza che traducono gli obblighi di privacy in sistemi e controlli operativi. È questa la postura che definisce la credenziale. È la controparte sul versante ingegneristico delle credenziali DPO e CDPO, incentrate sulle politiche, non una loro concorrente. Un DPO decide cosa l'organizzazione deve fare per conformarsi; un titolare CDPSE costruisce i controlli che rendono la conformità reale e verificabile. Nei programmi maturi i due ruoli siedono ai due lati dello stesso tavolo, ed è per questo che CDPSE è posizionata come un ponte tra la governance della privacy e la tecnologia che la implementa. ## I tre domini CDPSE è costruita attorno a tre domini, e le proporzioni indicano dove ISACA pone l'accento. La maggior parte dell'esame riguarda i domini dell'architettura e del ciclo di vita, perché è lì che vengono effettivamente prese le decisioni ingegneristiche. - Governance della privacy. Il tessuto connettivo tra i requisiti giuridici e l'esecuzione tecnica: struttura del programma di privacy, governance e gestione del rischio privacy, nonché le politiche e gli standard su cui l'ingegneria deve costruire. È qui che un titolare CDPSE legge ciò che il DPO e il team legale hanno prodotto e lo trasforma in vincoli di progettazione. - Architettura della privacy. Infrastruttura, applicazioni e tecnologie nell'ottica della privacy. Comprende la privacy by design e by default come disciplina ingegneristica: progettazione dei flussi di dati, controlli tecnici di privacy, cifratura e pseudonimizzazione, identità e accesso, e le implicazioni per la privacy delle scelte architetturali. - Ciclo di vita dei dati. I dati personali dalla raccolta alla distruzione, passando per la conservazione. Limitazione della finalità, minimizzazione dei dati, qualità, calendari di conservazione e smaltimento sicuro, espressi come controlli che un sistema applica anziché come clausole in un'informativa che nessuno legge. > **Implementazione, non interpretazione** CDPSE presuppone che l'interpretazione giuridica esista già. Il suo valore consiste nel rendere operativa tale interpretazione: consenso raccolto correttamente, conservazione applicata automaticamente, accesso limitato alla finalità, dati cancellabili su richiesta. Se il vostro compito è discutere il significato di una norma, questo è territorio del DPO; se il vostro compito è far sì che il sistema vi si attenga, questo è territorio del CDPSE. ## Dove si colloca CDPSE rispetto a credenziali e standard contigui CDPSE è più utile quando la si legge rispetto a ciò che non è. La tabella seguente la colloca accanto alle credenziali e agli standard con cui i professionisti più spesso la confondono. **CDPSE a confronto con ruoli e standard di privacy contigui** | Riferimento | Obiettivo principale | Postura | | --- | --- | --- | | CDPSE | Implementazione tecnica della privacy nei sistemi | Ingegneria e architettura, controlli operativi | | DPO / CDPO | Conformità giuridica e di policy, responsabilità | Governance, interpretazione, consulenza | | ISO 27701 | Sistema di gestione delle informazioni sulla privacy (PIMS) | Sistema di gestione certificabile che estende ISO 27001 | | GDPR | Gli obblighi giuridici stessi | Regolamentazione, ciò che i controlli devono soddisfare | L'idoneità è massima per i team di sicurezza che hanno ereditato l'implementazione della privacy, e per gli architetti che progettano sotto il GDPR o l'AI Act, dove la minimizzazione dei dati e la limitazione della finalità devono essere ingegnerizzate nei modelli e nelle pipeline anziché promesse nella documentazione. Un titolare CDPSE diventa spesso la persona in grado di partecipare a una revisione progettuale e spiegare, concretamente, come una funzionalità soddisferà un requisito di privacy. ISO 27701 affianca frequentemente la credenziale: lo standard definisce il sistema di gestione della privacy, e gli ingegneri formati su CDPSE sono coloro che costruiscono i controlli tecnici da cui quel sistema dipende. CDPSE è una certificazione ISACA basata sull'esperienza, il che significa che è rivolta a persone che già lavorano nella privacy, nella sicurezza o nell'IT, anziché ai principianti. Come le altre credenziali ISACA, prevede requisiti di formazione professionale continua per mantenerla aggiornata, riflettendo la rapidità con cui evolvono sia la tecnologia sia il panorama normativo. --- ## Certified Information Security Manager (CISM) **URL:** https://cyberacademy.net/it/resources/encyclopedia/cism **Last reviewed:** 2026-06-24 CISM è la certificazione ISACA per i responsabili della sicurezza delle informazioni: governance, gestione dei programmi, gestione del rischio, gestione degli incidenti. È lo standard di riferimento per i ruoli di leadership nella sicurezza, richiesto in circa il 60% delle offerte per CISO. Prospettiva diversa rispetto al CISSP: orientata al management, meno tecnica. ## Cosa certifica il CISM Il CISM è la certificazione di ISACA destinata a chi gestisce la sicurezza delle informazioni anziché configurarla. Attesta che siete in grado di costruire e governare un programma di sicurezza, allinearlo agli obiettivi aziendali e renderne conto ai dirigenti e al consiglio di amministrazione. La credenziale è organizzata attorno a quattro domini professionali: governance della sicurezza delle informazioni, gestione del rischio di sicurezza delle informazioni, sviluppo e gestione del programma di sicurezza delle informazioni e gestione degli incidenti di sicurezza delle informazioni. Questi quattro ambiti descrivono il lavoro reale di un responsabile della sicurezza: definire la direzione, comprendere e trattare il rischio, realizzare il programma che svolge il lavoro e contenere gli incidenti quando i controlli falliscono. La shortDefinition fa bene a presentare il CISM come lo standard di riferimento per i ruoli di leadership nella sicurezza. In pratica, ciò significa che i responsabili delle assunzioni lo usano come indizio del fatto che una persona «può farsi carico di una funzione di sicurezza», non che «può rendere più sicuro un server». Da un titolare del CISM ci si aspetta che faccia da tramite tra due pubblici: i team tecnici che gestiscono i controlli e i dirigenti che finanziano il rischio e lo accettano. Questo strato di traduzione è il cuore del ruolo, ed è il motivo per cui il discorso sul CISM si fonda su governance, linee di reporting e accettazione del rischio più che sugli strumenti. ## CISM contro CISSP: la lente manageriale La domanda più frequente tra i professionisti riguarda la differenza tra CISM e CISSP. Entrambe sono credenziali senior ed entrambe toccano governance, rischio e operatività, ma il loro baricentro è diverso. Il CISSP, di (ISC)squared, è più ampio e più tecnico: otto domini che spaziano dall'architettura alla crittografia, alla sicurezza di rete, alla sicurezza del software e all'operatività. È la certificazione naturale per un professionista o un architetto della sicurezza. Il CISM è più ristretto e più manageriale: quattro domini, tutti visti dalla prospettiva di chi risponde di un programma e di un budget, non di chi implementa i controlli. **Il CISM a confronto con le credenziali affini** | Credenziale | Ente | Lente principale | | --- | --- | --- | | CISM | ISACA | Gestire un programma di sicurezza: governance, rischio, programma, incidenti | | CISSP | (ISC)squared | Professionista tecnico ad ampio spettro: otto domini, dall'architettura all'operatività | | CISA | ISACA | Audit e assurance dei sistemi informativi | | CRISC | ISACA | Identificazione, valutazione e risposta al rischio IT aziendale | Nella stessa famiglia di ISACA, il CISM si colloca accanto al CISA e al CRISC. Il CISA è la credenziale dell'auditor, incentrata sulla valutazione dei controlli e sul fornire assurance. Il CRISC è la credenziale dello specialista del rischio, incentrata sull'identificazione del rischio IT e sulla risposta a esso. Il CISM è la credenziale del manager, incentrata sull'assumersi la funzione che lega governance, rischio e operatività. Molti responsabili della sicurezza finiscono per detenerne più di una, perché i ruoli si sovrappongono man mano che si sale di livello. > **Una certificazione, non un framework** Il CISM non prescrive controlli come fanno ISO 27001 o NIST. Certifica la persona, non l'organizzazione. Un titolare del CISM gestirà tipicamente un SGSI ISO 27001 o un programma basato su NIST; la certificazione attesta che sa guidare quel lavoro, non quale standard scegliere. ## Cosa serve per ottenere il CISM Il CISM è una credenziale subordinata all'esperienza, non solo un esame. ISACA richiede ai candidati di superare l'esame e di documentare un'esperienza lavorativa pertinente nella gestione della sicurezza delle informazioni, con una parte di tale esperienza ricadente nei quattro domini. Esistono deroghe limitate per una parte del requisito di esperienza, e la certificazione deve essere poi mantenuta tramite formazione professionale continua e l'adesione al codice etico professionale di ISACA. Questo requisito di mantenimento è il motivo per cui il CISM resta aggiornato: i titolari accumulano ore di CPE a ogni ciclo, anziché superare l'esame una sola volta e adagiarsi sugli allori. Per i professionisti che valutano se intraprenderlo, l'inquadramento onesto è questo. Se la vostra traiettoria punta a guidare una funzione di sicurezza, a consigliare un consiglio di amministrazione o ad assumere un ruolo di CISO, il CISM è la credenziale che i responsabili delle assunzioni citano più spesso. Se il vostro lavoro è architettura e ingegneria sul campo, il CISSP o una specializzazione tecnica vi serviranno meglio. Le due sono complementari più che concorrenti, e i leader senior spesso le detengono entrambe. --- ## Certified Information Systems Auditor (CISA) **URL:** https://cyberacademy.net/it/resources/encyclopedia/cisa **Last reviewed:** 2026-06-24 CISA è la certificazione di riferimento per l'audit IT, rilasciata da ISACA dal 1978. Cinque domini che coprono il processo di audit, la governance, l'acquisizione, le operazioni e la protezione degli asset. La certificazione di riferimento nei mandati delle Big Four. Riconosciuta a livello globale; obbligatoria per molti ruoli di audit interno e compliance nei settori regolamentati. ## Cosa certifica realmente CISA CISA è la credenziale che attesta la capacità di auditare un sistema informativo e di difendere l'opinione a cui si giunge. È rilasciata da ISACA ed è da decenni la qualifica di riferimento nell'audit IT, motivo per cui rappresenta l'aspettativa predefinita negli incarichi delle Big Four e il requisito che molti datori di lavoro regolamentati inseriscono nelle descrizioni dei ruoli di audit interno e compliance. La certificazione non riguarda la gestione operativa dell'IT né la sua messa in sicurezza. Riguarda la valutazione indipendente dell'esistenza dei controlli, del loro funzionamento, e della capacità delle evidenze di sostenere tale conclusione. La distinzione professionale da tenere a mente è che CISA è una credenziale di assurance, non di implementazione. Chi possiede CISM gestisce un programma di sicurezza. Chi possiede CISA formula un'opinione indipendente sul fatto che tale programma, e l'ambiente IT più ampio che lo circonda, sia controllato. Questa indipendenza è il punto centrale: un auditor che ha costruito il controllo non può fornirne un'assurance credibile. CISA forma la mentalità basata su evidenze e campionamento che rende l'opinione difendibile. ## I cinque domini CISA L'esame e il corpo di conoscenze sono organizzati in cinque domini. Procedono dal modo in cui si effettua l'audit, attraverso il modo in cui l'IT è governato, fino alle tre aree del ciclo di vita che un auditor deve essere in grado di valutare: - Processo di audit dei sistemi informativi. Pianificazione, definizione dell'ambito basata sul rischio, raccolta delle evidenze, campionamento e reporting. La disciplina che rende auditabile ogni altro dominio. - Governance e gestione dell'IT. Strategia, policy, struttura organizzativa, e modalità con cui l'azienda indirizza e supervisiona la propria IT. - Acquisizione, sviluppo e implementazione dei sistemi informativi. Se progetti, modifiche e nuovi sistemi siano controllati dal business case fino al go-live. - Operatività dei sistemi informativi e resilienza del business. Operatività quotidiana, gestione dei servizi, backup, continuità e disaster recovery. - Protezione degli asset informativi. Sicurezza logica e fisica, identità e accessi, cifratura, e controlli di protezione dei dati. > **CISA verifica il giudizio, non la memorizzazione** L'esame è basato su scenari. Le domande chiedono quale azione un auditor debba intraprendere per prima, o quale rilievo sia più significativo, data una situazione. Si è valutati sul giudizio di audit e sulla prioritizzazione del rischio, non sulla recitazione di elenchi di controlli, motivo per cui l'esperienza pratica di audit conta tanto quanto lo studio. ## Dove si colloca CISA rispetto alle credenziali affini CISA non è isolata nel catalogo ISACA, e i professionisti la combinano abitualmente con altre. Le evoluzioni più comuni sono laterali verso il rischio con CRISC, o ascendenti verso la leadership nella sicurezza con CISM. Rispetto al mondo ISO, CISA e la credenziale PECB Lead Auditor certificano entrambe la competenza di audit, ma in ambiti diversi: CISA è una qualifica ampia di audit IT legata ai domini ISACA, mentre Lead Auditor si fonda su ISO 19011 ed è orientata all'audit di uno specifico sistema di gestione, come un SGSI ISO 27001, spesso come percorso per diventare auditor accreditato di un organismo di certificazione. **CISA a confronto con le credenziali affini** | Credenziale | Ente | Focus principale | | --- | --- | --- | | CISA | ISACA | Assurance ampia di audit IT su cinque domini | | CISM | ISACA | Gestione e governance di un programma di sicurezza delle informazioni | | CRISC | ISACA | Identificazione, valutazione e risposta al rischio IT | | Lead Auditor | PECB | Audit di uno specifico sistema di gestione secondo ISO 19011 | Ottenere la credenziale è più che superare l'esame. ISACA richiede un'esperienza professionale verificata in audit IT, l'adesione a un codice di etica professionale, e una formazione professionale continua per mantenere attiva la certificazione. Tale requisito di esperienza è ciò che conferisce peso a CISA: conferma che il titolare ha effettivamente svolto il lavoro, e non solo studiato la materia. --- ## Certified in Risk and Information Systems Control (CRISC) **URL:** https://cyberacademy.net/it/resources/encyclopedia/crisc **Last reviewed:** 2026-06-24 CRISC è la certificazione ISACA dedicata ai professionisti del rischio IT. Copre identificazione, valutazione, risposta e monitoraggio del rischio legato ai sistemi informativi. Collega il rischio di business a quello IT. È il complemento naturale al CISA per gli auditor che si spostano verso la gestione del rischio, e a ISO 27005 / 31000 per i professionisti con formazione ISO che integrano il vocabolario ISACA. ## Cosa certifica CRISC CRISC è la credenziale di ISACA per i professionisti che gestiscono il rischio IT e dei sistemi informativi, anziché auditarlo a posteriori. Attesta che il titolare sa condurre l'intero ciclo di vita del rischio sugli asset tecnologici: identificare l'esposizione, valutare probabilità e impatto, progettare e raccomandare una risposta, e monitorare la posizione residua nel tempo. L'aspetto distintivo di CRISC è il livello di traduzione. Si attende che il titolare esprima una vulnerabilità di database o una configurazione errata del cloud nei termini che il registro dei rischi del business e il consiglio di amministrazione utilizzano realmente, così che il rischio IT diventi un input del rischio aziendale, e non una conversazione parallela in un linguaggio distinto. Laddove molte certificazioni tecniche si fermano ai controlli, CRISC presenta i controlli come la conseguenza di una decisione sul rischio. Ci si attende che il titolare parta dallo scenario di rischio, dalla propensione e dalla tolleranza fissate dall'organizzazione, e dal costo del trattamento, e poi giustifichi perché esiste un dato controllo e cosa lascia non affrontato. Questo filo rischio-risposta-controllo è la spina dorsale della credenziale e la ragione per cui si colloca accanto al lavoro di governance anziché alla sicurezza puramente operativa. ## Dove si colloca CRISC tra le credenziali affini CRISC è il più delle volte interpretata come il passo naturale successivo per un titolare CISA. CISA dimostra che sai auditare i sistemi informativi e giudicare se i controlli sono progettati e operano in modo efficace; CRISC dimostra che sai gestire il rischio a cui quei controlli rispondono e decidere cosa farne. Gli auditor che passano dall'emettere rilievi al definire la strategia di rischio usano CRISC per rendere leggibile questo passaggio agli occhi dei datori di lavoro. Le due condividono il vocabolario e il quadro di governance di ISACA, ed è per questo che vengono abitualmente abbinate. Per i professionisti formati sull'ISO, CRISC aggiunge il dialetto ISACA a una metodologia che già applicano. Chi padroneggia ISO 27005 o ISO 31000 esegue già identificazione, analisi, valutazione, trattamento e accettazione. CRISC non sostituisce quel processo; fornisce alla stessa persona i termini di ISACA, l'inquadramento del rischio IT aziendale e una credenziale riconosciuta dai datori di lavoro che si standardizzano su ISACA anziché sull'ISO. Le metodologie sono compatibili, e possederle entrambe segnala che sai muoverti tra i due mondi di riferimento. > **CISA descrive, CRISC decide** Una lettura in ottica CISA di un rilievo si chiede se il controllo funziona. Una lettura in ottica CRISC si chiede se il rischio residuo è accettabile data la propensione, quale dovrebbe essere la risposta e chi ne è responsabile. Le stesse evidenze, una domanda diversa. **Come si confronta CRISC con le credenziali affini** | Credenziale | Domanda principale | Titolare tipico | | --- | --- | --- | | CRISC | Qual è il rischio IT e cosa facciamo al riguardo? | Risk manager IT, responsabile dei rischi | | CISA | I controlli sono progettati e operano in modo efficace? | Auditor IT, audit interno | | ISO 27005 | Come conduciamo il processo di rischio per la sicurezza delle informazioni? | Professionista SGSI, analista dei rischi | ## Cosa fanno realmente i titolari di CRISC In pratica, un titolare di CRISC lavora vicino al punto in cui si incontrano il rischio tecnologico e il processo decisionale del business. Le attività ricorrenti includono le seguenti. - Costruire e mantenere scenari di rischio IT e un registro dei rischi che la funzione di rischio aziendale nel suo complesso possa utilizzare. - Valutare probabilità e impatto, quindi confrontare il risultato con la propensione e la tolleranza dichiarate dall'organizzazione. - Raccomandare una risposta (accettare, mitigare, trasferire o evitare) e giustificare la scelta in base al costo e al rischio residuo, non a una mera preferenza tecnica. - Progettare o specificare i controlli dei sistemi informativi che attuano una risposta scelta, e definire gli indicatori che mostrano se reggono. - Monitorare gli indicatori chiave di rischio e riferire la posizione residua agli organi di governance in termini di business. Il filo che attraversa tutto questo è la responsabilità e la comunicazione. CRISC riguarda meno lo scoprire una nuova vulnerabilità e più il decidere cosa dovrebbe fare l'organizzazione, l'assicurarsi che qualcuno sia responsabile di quella decisione e il dimostrare nel tempo che il rischio residuo è rimasto entro il limite concordato. --- ## Certified in the Governance of Enterprise IT (CGEIT) **URL:** https://cyberacademy.net/it/resources/encyclopedia/cgeit **Last reviewed:** 2026-06-24 CGEIT è la certificazione ISACA per i professionisti senior che si occupano della governance dell'IT aziendale: allineamento strategico, creazione di valore, ottimizzazione dei rischi e delle risorse. Si basa su COBIT. Ha un mercato più ristretto rispetto a CISA / CISM, ma è la certificazione adatta a CIO, advisor IT a livello di board e consulenti senior. ## Cosa certifica CGEIT CGEIT è la credenziale di ISACA destinata ai professionisti senior che forniscono consulenza sul governo dell'IT aziendale o ne sono responsabili. L'accento è importante: si tratta di governo, non di operazioni di sicurezza né di esecuzione di progetti. Un titolare CGEIT deve saper ragionare sull'allineamento strategico tra l'IT e gli obiettivi di business, sulla creazione di valore degli investimenti IT, sull'ottimizzazione del rischio e sull'uso responsabile delle risorse. Sono temi da consiglio di amministrazione, ed è per questo che la credenziale è rivolta a CIO, responsabili del governo IT, consulenti a livello di consiglio e consulenti senior, piuttosto che a ingegneri o analisti operativi. La distinzione su cui i professionisti inciampano è la linea tra governo e gestione. Il governo è la responsabilità del consiglio e dei dirigenti di valutare le opzioni, definire la direzione e verificare se i risultati vengono conseguiti. La gestione pianifica, costruisce, esegue e monitora le attività che concretizzano quella direzione. CGEIT attesta che sai operare sul versante del governo, progettando e garantendo il sistema con cui l'IT viene guidato, anziché gestire l'IT in sé. ## La collocazione di CGEIT tra le credenziali ISACA CGEIT è la più ridotta delle certificazioni di punta di ISACA per numero di titolari, e questo è un pregio anziché un difetto. CISA convalida la capacità di svolgere audit dei sistemi informativi. CISM convalida la capacità di gestire un programma di sicurezza delle informazioni. CGEIT convalida la capacità di governare l'IT a livello aziendale. Rispondono a domande diverse e si adattano a fasi di carriera diverse: un auditor o un responsabile della sicurezza acquisisce profondità con CISA o CISM, mentre un leader che si avvicina a una responsabilità a livello di consiglio aggiunge CGEIT. In genere si persegue più avanti nella carriera, perché l'idoneità privilegia gli anni di reale esperienza di governo, non le ore d'aula. **CGEIT a confronto con le credenziali ISACA contigue** | Credenziale | Convalida | Titolare tipico | | --- | --- | --- | | CGEIT | Governo dell'IT aziendale a livello di consiglio di amministrazione | CIO, responsabile del governo IT, consulente del consiglio | | CISA | Audit dei sistemi informativi | Auditor SI, professionista dell'assurance | | CISM | Gestione di un programma di sicurezza delle informazioni | Responsabile della sicurezza, CISO | | CRISC | Gestione del rischio IT e del rischio aziendale | Risk manager, titolare dei controlli | > **CGEIT è una credenziale di leadership, non tecnica** L'esame e il requisito di esperienza verificano se sai progettare e garantire un sistema di governo, allineare l'IT alla strategia e ottimizzare valore, rischio e risorse. Presuppone che tu disponga già delle basi tecniche e che ora tu sia responsabile della direzione anziché dell'esecuzione. ## Come COBIT ne costituisce il fondamento CGEIT affonda le radici in COBIT, il framework di ISACA per il governo e la gestione dell'IT aziendale. COBIT fornisce la struttura entro cui opera un titolare CGEIT: la separazione tra obiettivi di governo e di gestione, i componenti che fanno funzionare un sistema di governo come i processi, le strutture organizzative, le politiche, le competenze e la cultura, e i fattori di progettazione che adattano quel sistema al contesto di un'organizzazione. In pratica un professionista certificato CGEIT usa COBIT come modello di riferimento per valutare a che punto si trova il governo, progettare dove dovrebbe essere e razionalizzare gli standard già in uso, come ISO 27001 o ITIL, in un insieme coerente al servizio degli obiettivi aziendali. È anche per questo che i due si apprendono di solito insieme. Studiare COBIT ti dà il framework; conseguire il CGEIT dimostra che sai applicare un pensiero di governo alla strategia, al valore, al rischio e alle risorse, al livello in cui il consiglio chiede conto all'IT. Come per le altre credenziali ISACA, CGEIT si mantiene attraverso la formazione professionale continua e l'aderenza al codice etico professionale di ISACA. --- ## Chief Information Security Officer (CISO) **URL:** https://cyberacademy.net/it/resources/encyclopedia/ciso **Last reviewed:** 2026-06-24 Il CISO è il dirigente responsabile della strategia di sicurezza delle informazioni. Gestisce il registro dei rischi, guida la risposta agli incidenti, informa il consiglio di amministrazione e approva il rischio residuo. Con NIS 2 e DORA, la responsabilità è ora esplicita e personale. Il ruolo riguarda la governance, non l'implementazione; la parte più difficile è la traduzione per il board. ## Di cosa risponde davvero un CISO Il CISO è il dirigente responsabile della strategia di sicurezza delle informazioni, e l'accento è sulla parola responsabile. Come dice la shortDefinition, il mestiere è governance, non implementazione. Un CISO non configura firewall né scrive regole di rilevamento; decide dove l'organizzazione spende il suo budget di sicurezza limitato, quali rischi tratta e quali accetta, e come risponde quando qualcosa va storto. I prodotti quotidiani del ruolo sono un registro dei rischi, una roadmap di programma, un piano di risposta agli incidenti e una serie di report destinati al consiglio di amministrazione, non un terminale. Questa distinzione conta perché la leadership della sicurezza viene spesso fraintesa come un ruolo di ingegneria senior. Non lo è. Il CISO si colloca al confine tra i team tecnici che gestiscono i controlli e i dirigenti che li finanziano e ne portano le conseguenze. La parte più difficile del lavoro, come nota la shortDefinition, è la traduzione verso il consiglio: trasformare una realtà tecnica sterminata in un piccolo numero di decisioni che un consiglio possa davvero prendere. Un CISO che non sa spiegare il rischio residuo in termini di business non può svolgere questo lavoro, per quanto solida sia la sua formazione tecnica. ## Responsabilità sotto NIS 2 e DORA Per anni il ruolo di CISO ha comportato responsabilità operativa senza molta responsabilità formale verso l'alto. Questo è cambiato. La shortDefinition è esplicita: sotto NIS 2 e DORA la responsabilità verso l'alto è ora personale. NIS 2, la direttiva europea sulla sicurezza delle reti e dei sistemi informativi, porta la supervisione della cybersicurezza fino all'organo di gestione delle entità rientranti nell'ambito e rende tale organo responsabile dell'approvazione e della supervisione delle misure di gestione del rischio di sicurezza. DORA, il Digital Operational Resilience Act, fa l'equivalente per il settore finanziario dell'UE, collocando saldamente la responsabilità sulla resilienza operativa in capo all'organo di gestione. L'effetto pratico è che «la funzione sicurezza fa del suo meglio» non è più una postura difendibile; una leadership designata per nome deve assumersi per iscritto le decisioni sul rischio. > **La responsabilità non può essere delegata** Sotto NIS 2 e DORA, l'organo di gestione può affidare il lavoro al CISO e al team di sicurezza, ma mantiene la responsabilità del risultato. Un CISO che approva un rischio residuo sta documentando una decisione che l'organizzazione ha formalmente accettato, non trasferendo la responsabilità lontano dal consiglio. Ecco perché un CISO moderno dedica così tanto tempo alla documentazione e alla cadenza di reporting. Approvare il rischio residuo, informare il consiglio sul panorama delle minacce e dimostrare che le misure di gestione del rischio sono state approvate al livello giusto non sono più extra di buona pratica. È così che l'organizzazione dimostra di aver soddisfatto i propri obblighi legali. Il ruolo è passato da «guidare il team di sicurezza» a «rendere la governance difendibile». ## In cosa il CISO differisce dai ruoli vicini Il CISO viene spesso confuso con le persone e le funzioni che lo circondano. Un security manager o un proprietario di programma certificato CISM gestisce il programma di sicurezza e può riportare al CISO; il CISO definisce la strategia e ne porta la responsabilità esecutiva. Un responsabile SOC è proprietario delle operazioni di rilevamento e risposta; il CISO è proprietario della decisione su quanta capacità di rilevamento l'organizzazione finanzierà e su cosa farà quando il SOC escala un incidente maggiore. E dove l'organizzazione gestisce un SGSI ISO 27001, il CISO ne è tipicamente lo sponsor esecutivo piuttosto che l'operatore quotidiano. **Il CISO confrontato con i ruoli adiacenti** | Ruolo | Prospettiva principale | Riporta a | | --- | --- | --- | | CISO | Strategia di sicurezza, accettazione del rischio, responsabilità verso il consiglio | CEO o consiglio di amministrazione | | Security manager | Gestione del programma e del team di sicurezza | Spesso il CISO | | Responsabile SOC | Rilevamento, monitoraggio, operazioni di risposta agli incidenti | CISO o security manager | | DPO | Conformità alla protezione dei dati e diritti delle persone | Indipendente, con accesso al consiglio | Un abbinamento che vale la pena separare con chiarezza è quello tra CISO e Responsabile della protezione dei dati. Si sovrappongono sugli incidenti che coinvolgono dati personali, ma sono lavori diversi. Il DPO è un ruolo di conformità e supervisione con un'indipendenza protetta per legge; il CISO è un dirigente che è proprietario della strategia di sicurezza ed è misurato su di essa. In molte organizzazioni collaborano costantemente e riportano attraverso linee diverse, proprio perché il DPO deve poter contestare il business, inclusa la funzione sicurezza. Per i professionisti in cammino verso questo ruolo, l'inquadramento onesto è che il ruolo di CISO premia il giudizio e la comunicazione più degli strumenti. Le fondamenta tecniche sono date per scontate; ciò che fa assumere le persone e le mantiene efficaci è la capacità di assumersi il rischio, informare un consiglio e rendere la responsabilità difendibile sotto quadri come NIS 2 e DORA. --- ## Clausole Contrattuali Standard (SCC) **URL:** https://cyberacademy.net/it/resources/encyclopedia/scc **Last reviewed:** 2026-06-24 Le SCC sono le clausole standard approvate dalla Commissione Europea per il trasferimento di dati personali verso paesi terzi in assenza di una decisione di adeguatezza. Le SCC del 2021 hanno sostituito le versioni precedenti e richiedono una Transfer Impact Assessment (TIA) a seguito della sentenza Schrems II. Documentazione obbligatoria per chiunque utilizzi provider SaaS non europei. ## Cosa fanno davvero le SCC Le clausole contrattuali tipo sono un contratto preredatto tra un esportatore di dati nell'UE e un importatore in un Paese privo di decisione di adeguatezza. Firmandole, l'importatore si impegna a rispettare obblighi di livello GDPR: limitazione della finalità, sicurezza, controlli sui trasferimenti successivi, diritti degli interessati e cooperazione con l'autorità di controllo. Poiché la Commissione europea ha già approvato la formulazione, non occorre negoziare né giustificare le clausole stesse, motivo per cui sono il meccanismo di trasferimento predefinito per quasi ogni relazione SaaS, cloud o di sub-responsabile al di fuori dell'UE. Le clausole sono modulari. Si sceglie il modulo che corrisponde alla relazione reale: titolare a titolare, titolare a responsabile, responsabile a responsabile, oppure responsabile a titolare. Sbagliare modulo è l'errore di redazione più comune, perché gli obblighi e i punti di aggancio per i sub-responsabili differiscono tra loro. Le SCC includono anche una clausola di aggancio che consente a nuove parti di unirsi a un insieme esistente, il che rende gestibili le lunghe catene di sub-responsabili. > **Firmare non è il traguardo** Le SCC del 2021 forniscono una base giuridica per il trasferimento solo se la protezione che promettono è realmente efficace sul campo. Per questo Schrems II ha innestato una valutazione d'impatto del trasferimento su ogni insieme di clausole che si firma. ## Perché la TIA ha cambiato le carte in tavola Prima della sentenza Schrems II del 2020, firmare le SCC era considerato sufficiente di per sé. La Corte di giustizia vi ha posto fine. Ha stabilito che gli impegni contrattuali non possono vincolare un governo straniero, per cui l'esportatore deve valutare se l'importatore possa onorare genuinamente le clausole alla luce della legislazione locale in materia di sorveglianza e accesso. Tale valutazione è la valutazione d'impatto del trasferimento. In pratica si documentano il Paese di destinazione, le leggi che potrebbero imporre la divulgazione, la natura e la sensibilità dei dati, e se misure supplementari come una cifratura robusta, la pseudonimizzazione o l'elaborazione frazionata colmino l'eventuale lacuna individuata. Se la TIA conclude che l'importatore non può soddisfare gli impegni delle SCC e nessuna misura supplementare lo risolve, il trasferimento non dovrebbe procedere sulla base delle SCC. È qui che le SCC differiscono nettamente da una decisione di adeguatezza: l'adeguatezza è un accertamento della Commissione che elimina l'onere caso per caso, mentre le SCC spostano tale onere su di voi per ogni trasferimento. L'EU-US Data Privacy Framework offre ora una via di adeguatezza per gli importatori statunitensi certificati, ma le SCC restano lo strumento di riferimento per ogni altro Paese terzo e per i fornitori statunitensi non certificati. ## Cosa fanno davvero i professionisti Un processo SCC che funziona è ripetibile, non un esercizio giuridico una tantum. Lo schema su cui la maggior parte dei team converge è il seguente. 1. Mappare il trasferimento: individuare l'esportatore, l'importatore, le categorie di dati e il modulo corretto prima di toccare il modello. 1. Completare gli allegati: le parti, la descrizione del trattamento e le misure di sicurezza tecniche e organizzative. Allegati vaghi sono la parte che i regolatori mettono in discussione per prima. 1. Eseguire e documentare la TIA, comprese le eventuali misure supplementari, e conservarla insieme alle clausole firmate. 1. Integrare le SCC nell'onboarding dei fornitori affinché siano firmate prima che i dati inizino a circolare, e non aggiunte a posteriori dopo che un audit ha rilevato la lacuna. 1. Riesaminare quando il fornitore cambia sub-responsabili, quando il Paese di destinazione o le sue leggi cambiano, oppure secondo una cadenza fissa. Le SCC si collocano all'interno della vostra più ampia narrazione di responsabilizzazione GDPR. Rinviano ai registri delle attività di trattamento, alla DPIA quando richiesta e ai controlli di sicurezza che vi siete già impegnati ad attuare. Trattate come documenti vivi anziché come una firma raccolta una volta sola, sono la differenza tra un trasferimento che potete difendere e uno che crolla nel momento in cui un regolatore o un interessato chiede come proteggete i dati che lasciano l'UE. --- ## Commission nationale de l'informatique et des libertés (CNIL) **URL:** https://cyberacademy.net/it/resources/encyclopedia/cnil **Last reviewed:** 2026-06-24 La CNIL è l'autorità francese per la protezione dei dati, istituita nel 1978. Applica il GDPR in Francia, emette decisioni vincolanti e sanzioni, pubblica linee guida (cookie, biometria, IA) e gestisce lo strumento PIA. È una delle autorità di controllo più attive nell'UE; le sue decisioni costituiscono spesso un precedente a livello europeo. La CNIL è l'autorità di controllo che trasforma il diritto europeo della protezione dei dati in conseguenze concrete all'interno della Francia. Precede il GDPR di decenni, ed è per questo che il suo mandato è più ampio della sola attività sanzionatoria: consiglia il governo sui progetti di legge, accredita e svolge audit, diffonde orientamenti rivolti al pubblico e funge da punto di contatto unico sia per gli interessati che presentano reclami sia per i titolari del trattamento che notificano violazioni. Per un'organizzazione francese, la CNIL è il volto pratico della conformità. È l'organismo che risponde alle vostre domande, quello che vi ispeziona e quello che decide se un problema si conclude con un avvertimento o con una sanzione. ## Che cosa fa davvero la CNIL Considerate la CNIL come quattro funzioni che si sovrappongono, più che come un unico regolatore. In primo luogo, produce orientamenti che diventano il riferimento operativo in Francia: le sue regole sui cookie, i suoi quadri su biometria e selezione del personale, e le sue prese di posizione sull'intelligenza artificiale sono letti come ciò che rappresenta una buona prassi, anche laddove il testo del GDPR rimane generale. In secondo luogo, conduce il dialogo di vigilanza, gestendo i reclami, controllando le organizzazioni mediante esame documentale e ispezione in loco, ed emettendo diffide formali a conformarsi. In terzo luogo, sanziona, con il potere di imporre misure correttive vincolanti e sanzioni amministrative. In quarto luogo, dota i professionisti di strumenti, il più visibile dei quali è il software PIA utilizzato per strutturare una valutazione d'impatto sulla protezione dei dati. La maggior parte dei titolari del trattamento non vede mai la versione della CNIL fatta di sanzioni da prima pagina. Vede la versione del dialogo: una richiesta di documenti, una domanda sulla base giuridica, una diffida formale che fissa un termine per correggere qualcosa. Mettere in ordine il vostro registro delle attività di trattamento, le vostre valutazioni d'impatto e le vostre disposizioni relative al DPO è ciò che mantiene l'interazione in quel registro più moderato. > **Gli orientamenti sono il pavimento, non il soffitto** Quando la CNIL pubblica un quadro, ci si aspetta che le organizzazioni francesi lo seguano o documentino una ragione difendibile per discostarsene. Leggere i suoi orientamenti attuali su cookie, biometria e IA costa meno che scoprire le aspettative della CNIL durante un'ispezione. ## CNIL, GDPR e lo sportello unico dell'UE La CNIL non scrive la legge che fa applicare. Il GDPR è il regolamento; la CNIL è una delle autorità di controllo nazionali che lo applicano. Questa distinzione conta per i trattamenti transfrontalieri. Nel quadro del meccanismo dello sportello unico, un'organizzazione con stabilimento principale in Francia tratta principalmente con la CNIL in quanto autorità capofila, e la CNIL si coordina con le altre autorità europee attraverso le procedure di cooperazione e coerenza anziché agire isolatamente. Per i trattamenti puramente nazionali, la CNIL agisce in autonomia. La CNIL è inoltre tra le autorità più attive dell'UE, sicché il suo ragionamento e le sue decisioni sanzionatorie sono studiati ben oltre la Francia come indicazione della direzione che sta prendendo l'attività sanzionatoria europea. È anche qui che i ruoli che le ruotano attorno trovano il loro posto. Il GDPR crea obblighi; il DPO è il ruolo interno all'organizzazione che vigila sulla conformità e funge da punto di contatto con l'autorità; la CNIL è l'autorità all'altro capo di tale contatto. Un professionista in grado di spiegare come questi tre elementi si relazionano è raramente quello colto in fallo durante un'ispezione. ## Che cosa fanno i professionisti con la CNIL In pratica, lavorare bene con la CNIL è soprattutto preparazione più che reazione. Le abitudini concrete sono costanti nelle organizzazioni francesi mature. - Mettete in corrispondenza gli orientamenti attuali della CNIL con i vostri trattamenti, in particolare cookie, biometria, selezione del personale e qualsiasi decisione guidata dall'IA, e tenete aggiornata tale corrispondenza. - Mantenete le prove di accountability che la CNIL chiede di vedere per prime: il registro delle attività di trattamento, le valutazioni d'impatto completate e la base documentata di ciascuna finalità del trattamento. - Utilizzate lo strumento PIA della CNIL per strutturare le valutazioni d'impatto, affinché il risultato parli il linguaggio stesso dell'autorità. - Conoscete in anticipo il vostro percorso di notifica delle violazioni, così che un incidente notificabile diventi un processo anziché un'improvvisazione affannosa. - Trattate una diffida formale come un progetto scandito da una scadenza, non come una negoziazione, e documentate ogni passo che compiete per conformarvi. Nulla di tutto ciò è esotico. È la stessa disciplina di accountability che il GDPR richiede, organizzata in modo che l'unico organismo più probabilmente destinato a chiederla possa ricevere una risposta rapida e credibile. --- ## Cyber Resilience Act (CRA) **URL:** https://cyberacademy.net/it/resources/encyclopedia/cra **Last reviewed:** 2026-06-24 Il Cyber Resilience Act è il regolamento UE che impone obblighi minimi di sicurezza ai prodotti hardware e software con elementi digitali commercializzati in Europa. Obblighi del fornitore lungo l'intero ciclo di vita: secure-by-design, gestione delle vulnerabilità, SBOM, cinque anni di patch. Adottato alla fine del 2024, si applica dal dicembre 2027. Da integrare con NIS 2 (prospettiva organizzativa) e AI Act (prospettiva dei modelli). ## Che cosa regolamenta davvero il Cyber Resilience Act Il Cyber Resilience Act impone obblighi di sicurezza al prodotto, non solo all'organizzazione che lo gestisce. Tutto ciò che viene venduto nell'UE e contiene elementi digitali, ossia hardware o software con una connessione dati, rientra nell'ambito di applicazione: dispositivi di consumo connessi, controllori industriali, sistemi operativi, librerie, app mobili e persino il firmware integrato in un componente. La parte regolamentata è l'operatore economico che immette il prodotto sul mercato, perciò i fabbricanti sostengono il carico principale, mentre gli importatori e i distributori sono soggetti a obblighi di verifica. Si tratta di uno spostamento della responsabilità. Per anni l'acquirente ereditava il rischio del software non sicuro; il CRA riporta una base definita di responsabilità su chi costruisce e vende il prodotto. Poiché regolamenta i prodotti anziché le entità, il CRA raggiunge piccoli fornitori e componenti aperti che nessuna legge di sicurezza organizzativa toccherebbe mai. Un produttore di firmware privo di sede nell'UE deve comunque conformarsi se il dispositivo arriva su uno scaffale europeo. Questo inquadramento per prodotto è la cosa più importante da cogliere prima di leggere qualsiasi altra cosa al riguardo. ## Gli obblighi che vincolano un fabbricante Il CRA è costruito attorno a un ciclo di vita. Un prodotto deve essere sicuro al momento della consegna e restare manutenibile per tutto il tempo in cui si prevede ragionevolmente che sia in uso, periodo che il regolamento fissa in un periodo di supporto di base di circa cinque anni per la gestione delle vulnerabilità. Gli obblighi concreti si raggruppano in due insiemi. - Sicurezza fin dalla progettazione e per impostazione predefinita: consegnare senza vulnerabilità sfruttabili note, ridurre al minimo la superficie di attacco, proteggere la riservatezza e l'integrità dei dati e fornire una configurazione predefinita sicura, in modo che il prodotto non sia insicuro appena estratto dalla confezione. - Gestione delle vulnerabilità lungo il periodo di supporto: mantenere un processo di divulgazione coordinata, fornire un Software Bill of Materials affinché i componenti presenti nel prodotto siano documentati, distribuire tempestivamente gli aggiornamenti di sicurezza e, ove possibile, in modo automatico, e segnalare le vulnerabilità sfruttate attivamente e gli incidenti gravi all'ENISA entro i termini previsti dal regolamento. La conformità si dimostra nel modo in cui l'UE tratta le altre normative sulla sicurezza dei prodotti: una valutazione proporzionata alla classe di rischio del prodotto, una documentazione tecnica e la marcatura CE che segnala il raggiungimento della base di sicurezza. Le categorie di prodotti a rischio più elevato, dette importanti o critiche, sono soggette a una valutazione più rigorosa, talvolta da parte di terzi, anziché a un'autodichiarazione. > **Il SBOM è ora un deliverable, non un di più** Il CRA trasforma il Software Bill of Materials, da aspirazione dei team di sicurezza, in un requisito normativo. I fabbricanti devono conoscere e documentare cosa c'è all'interno dei loro prodotti, perché sono responsabili delle vulnerabilità di quei componenti per l'intero periodo di supporto, comprese le dipendenze di terzi e open source. ## Come si colloca rispetto a NIS 2 e all'AI Act Questi tre strumenti dell'UE sono volutamente complementari e i professionisti non dovrebbero confonderne gli ambiti. Il CRA è l'angolo del prodotto: rende sicuro ciò che vendi. NIS 2 è l'angolo organizzativo: obbliga le entità essenziali e importanti a gestire il rischio cibernetico, governare la sicurezza e segnalare gli incidenti a livello aziendale. L'AI Act è l'angolo del modello: disciplina come i sistemi di IA, in particolare quelli ad alto rischio, vengono costruiti e immessi sul mercato. Un dispositivo industriale connesso venduto da un operatore regolamentato che incorpora un componente di IA può riguardare tutti e tre contemporaneamente, ciascuno da una direzione diversa. **Confronto tra gli strumenti europei di sicurezza digitale** | Strumento | Che cosa regolamenta | Chi vincola | | --- | --- | --- | | Cyber Resilience Act | Sicurezza dei prodotti con elementi digitali | Fabbricanti, importatori, distributori | | NIS 2 | Gestione e segnalazione del rischio cibernetico a livello organizzativo | Entità essenziali e importanti | | AI Act | Sviluppo e immissione sul mercato di sistemi di IA | Fornitori e deployer di IA | La conseguenza pratica è che la preparazione al CRA è in larga misura un programma di ingegneria e di governance del prodotto, non un adempimento documentale agganciato a un ISMS esistente. I team che già praticano la divulgazione coordinata delle vulnerabilità, mantengono inventari delle dipendenze e applicano le patch con una cadenza prevedibile hanno già percorso gran parte della strada. I team che consegnano e dimenticano hanno il maggior carico di lavoro davanti, perché l'obbligo di supportare e applicare patch per anni è esattamente ciò che una cultura del consegnare e passare ad altro cerca di evitare. Il regolamento è stato adottato alla fine del 2024 e i suoi obblighi principali si applicano a partire da dicembre 2027, il che lascia un margine definito per predisporre i processi di gestione delle vulnerabilità e di SBOM prima che diventino vincolanti. --- ## Cybersecurity Maturity Model Certification (CMMC) **URL:** https://cyberacademy.net/it/resources/encyclopedia/cmmc **Last reviewed:** 2026-06-24 CMMC è il modello di maturità della cybersecurity che il Dipartimento della Difesa statunitense impone ai propri appaltatori che trattano informazioni contrattuali federali e informazioni non classificate controllate. CMMC 2.0 si è ridotto a tre livelli (Foundational, Advanced, Expert) allineati con NIST SP 800-171 e 800-172. Se si vende al DoD o si fa parte della loro catena di fornitura, si è nel perimetro di applicazione. ## Cosa cambia davvero CMMC per un appaltatore Per anni il Department of Defense statunitense ha chiesto ai propri fornitori di proteggere le informazioni sensibili confidando che lo facessero. Gli appaltatori autocertificavano di rispettare le misure di protezione richieste, e il divario tra ciò che veniva dichiarato e ciò che era effettivamente implementato emergeva solo dopo una violazione. CMMC colma quel divario trasformando i requisiti di protezione esistenti in una certificazione verificabile. La sostanza dei controlli non è cambiata quanto l'onere della prova: dove un tempo firmavi una dichiarazione, ora detieni una certificazione che, a seguito di una valutazione, conferma che le tue pratiche sono realmente in essere. Se tratti Federal Contract Information o Controlled Unclassified Information in un qualsiasi anello della catena di approvvigionamento del DoD, è questo il meccanismo che decide se puoi continuare a partecipare alle gare. Il modello conta ben oltre i confini statunitensi. I fornitori europei che subappaltano a prime contractor americani, fabbricano componenti per la difesa o trattano CUI per conto di un programma del DoD ereditano lo stesso obbligo. CMMC non è un framework che si adotta volontariamente per buona igiene; è una porta contrattuale. Senza certificazione al livello richiesto dal contratto, niente aggiudicazione. È ciò che lo distingue da un modello di maturità volontario e lo colloca nella stessa categoria pratica di un requisito normativo: la conformità è il prezzo dell'accesso al mercato. ## I tre livelli e cosa comprendono CMMC 2.0 ha semplificato un precedente schema a cinque livelli in tre, ciascuno legato alla sensibilità dei dati che tratti e a una baseline NIST esistente. Il livello 1 (Foundational) copre la protezione di base delle Federal Contract Information ed è costruito sulle pratiche delle regole federali di acquisizione, verificate tramite autovalutazione annuale. Il livello 2 (Advanced) protegge le Controlled Unclassified Information e si allinea direttamente a NIST SP 800-171, il catalogo di controlli già richiesto agli appaltatori che trattano CUI; a seconda del contratto, è confermato da una valutazione di terze parti. Il livello 3 (Expert) riguarda i programmi più sensibili e vi aggiunge i requisiti rafforzati di NIST SP 800-172 per difendersi dalle minacce persistenti avanzate, valutato dal governo stesso. **Livelli CMMC 2.0** | Livello | Dati protetti | Baseline | Valutazione | | --- | --- | --- | --- | | Livello 1 — Foundational | Federal Contract Information (FCI) | Requisiti di protezione di base | Autovalutazione annuale | | Livello 2 — Advanced | Controlled Unclassified Information (CUI) | NIST SP 800-171 | Valutazione di terze parti (o autovalutazione) | | Livello 3 — Expert | CUI ad alto valore, esposizione ad APT | NIST SP 800-171 più 800-172 | Valutazione condotta dal governo | L'intuizione chiave è che CMMC non inventa tanto nuovi controlli quanto impone quelli che gli appaltatori erano già tenuti a rispettare. Un fornitore che ha realmente implementato NIST SP 800-171 ha già percorso gran parte della strada verso il livello 2; il lavoro che resta consiste nel produrre le prove, nel chiudere le pratiche date per scontate ma mai operazionalizzate e nel superare una valutazione condotta da qualcuno che non sei tu. ## Dove si colloca CMMC accanto a NIS 2 e ISO 27001 È facile archiviare CMMC, NIS 2 e ISO 27001 nello stesso cassetto, ma rispondono a domande diverse. ISO 27001 certifica che gestisci un sistema di gestione della sicurezza delle informazioni basato sul rischio; è volontario, internazionale e indifferente a chi appartengano i dati che detieni. NIS 2 è una legge europea che impone obblighi di sicurezza e di notifica degli incidenti ai soggetti essenziali e importanti dei settori critici. CMMC è più ristretto e più specifico: un requisito di appalto pubblico del governo statunitense rivolto a una sola catena di approvvigionamento, mappato su insiemi fissi di controlli NIST anziché sulla tua valutazione del rischio. Un'organizzazione già certificata ISO 27001 avrà costruito una disciplina gestionale che rende più semplice lo sforzo CMMC, ma le certificazioni non sono intercambiabili e l'una non soddisfa l'altra. > **L'autocertificazione è finita** Il punto di CMMC è che una firma non basta più ai livelli superiori. Se la tua offerta dipende dalla protezione di CUI, prevedi una valutazione esterna e costruisci la traccia delle prove fin dall'inizio, anziché ricostruirla la settimana prima. --- ## Data Protection Impact Assessment (DPIA) **URL:** https://cyberacademy.net/it/resources/encyclopedia/dpia **Last reviewed:** 2026-06-24 Un DPIA è l'analisi strutturata che il GDPR richiede prima di qualsiasi trattamento ad alto rischio. Documenta natura, portata, contesto e finalità; valuta necessità e proporzionalità; individua le misure di attenuazione. La CNIL mette a disposizione gratuitamente un tool PIA: è consigliabile utilizzarlo. Omettere un DPIA quando era obbligatorio è uno dei modi più diretti per attirare una visita dell'autorità di controllo. ## Quando è richiesta una DPIA, e quando non lo è Una Valutazione d'Impatto sulla Protezione dei Dati non è un adempimento formale che si produce per ogni progetto. Il GDPR la lega a un unico fattore scatenante: un trattamento che può presentare un rischio elevato per i diritti e le libertà delle persone fisiche. Il testo cita alcune situazioni in cui la valutazione è obbligatoria, come la profilazione sistematica e approfondita che produce effetti giuridici o effetti significativi analoghi, il trattamento su larga scala di categorie particolari di dati e la sorveglianza sistematica su larga scala di una zona accessibile al pubblico. Le autorità di controllo nazionali pubblicano poi i propri elenchi delle operazioni che richiedono sempre una DPIA, e elenchi di operazioni che non la richiedono. In pratica si parte da una verifica preliminare. Confrontate con il trattamento un breve elenco di criteri di rischio, del tipo pubblicato dal Comitato europeo per la protezione dei dati, e contate quanti si applicano. Combinazioni come la valutazione o l'attribuzione di un punteggio unite a un processo decisionale automatizzato, oppure i dati sensibili uniti a un trattamento su larga scala, vi fanno superare la soglia. Quando la risposta è incerta, la posizione difendibile consiste nel documentare perché avete concluso che una DPIA completa non era necessaria, e non nell'eludere silenziosamente la questione. > **L'errore meno costoso da evitare** Non effettuare una DPIA quando era richiesta, effettuarla in modo errato, oppure non consultare l'autorità di controllo quando il rischio residuo resta elevato, sono tutti inadempimenti espressamente nominati. Una DPIA mancante è una delle lacune più facili da individuare per un'autorità durante un'ispezione. ## Cosa contiene la valutazione Il GDPR fissa un contenuto minimo. Una DPIA deve contenere una descrizione sistematica delle operazioni di trattamento e delle finalità, una valutazione della necessità e della proporzionalità del trattamento in relazione a tali finalità, una valutazione dei rischi per i diritti e le libertà degli interessati, e le misure previste per affrontare tali rischi, comprese le garanzie e le misure di sicurezza. La CNIL mette a disposizione gratuitamente un software PIA che vi guida esattamente attraverso questa struttura, e non c'è motivo di ricostruirla da zero. La necessità e la proporzionalità sono il punto in cui la maggior parte delle valutazioni risulta carente. Si tratta di un test giuridico, non di sicurezza: ogni campo di dati è realmente necessario per la finalità dichiarata, il periodo di conservazione è giustificato, esiste una base giuridica, i diritti degli interessati sono garantiti. L'analisi del rischio è la parte di taglio più vicino alla sicurezza, e attinge direttamente alla pratica della gestione del rischio. È qui che ISO 27005 ed EBIOS Risk Manager vi forniscono il vocabolario delle minacce, degli eventi temuti, della probabilità e della gravità. Una DPIA valuta il rischio per le persone i cui dati sono trattati, non il rischio per l'organizzazione, ed è questa la distinzione su cui si inciampa. ## Chi la effettua, e come resta viva Il titolare del trattamento è responsabile dell'effettuazione della DPIA. Qualora sia designato un Responsabile della Protezione dei Dati, il titolare del trattamento deve consultarlo, e il DPO di norma riesamina la valutazione e ne monitora lo svolgimento. Dovreste inoltre raccogliere il parere degli interessati o dei loro rappresentanti, ove opportuno. I responsabili del trattamento hanno il dovere di assistere. Se, dopo la mitigazione, il rischio residuo resta elevato e non potete ridurlo, il GDPR impone la consultazione preventiva dell'autorità di controllo prima dell'avvio del trattamento. Una DPIA è un documento vivo. Il titolare del trattamento deve riesaminarla quando si verifica una variazione del rischio rappresentato dal trattamento, per esempio un nuovo flusso di dati, una nuova tecnologia, una nuova finalità o un nuovo sub-responsabile. Trattatela come un'attività continua: un ritmo utile consiste nel riesaminare le valutazioni secondo un ciclo definito e ogniqualvolta la progettazione cambia, anziché archiviarle una volta per tutte e dimenticarle. **La DPIA a confronto con una valutazione del rischio generale** | Dimensione | DPIA | Valutazione del rischio di sicurezza generale | | --- | --- | --- | | Fattore scatenante | Trattamento di dati personali a rischio elevato | Qualsiasi asset, sistema o processo rientrante nel perimetro | | Oggetto del rischio | Diritti e libertà delle persone fisiche | L'organizzazione e i suoi asset | | Status giuridico | Obbligatoria ai sensi del GDPR quando è attivata | Guidata da una politica o da standard come ISO 27001 | | Metodo tipico | Software PIA della CNIL, criteri dell'EDPB, test di necessità | ISO 27005, EBIOS Risk Manager | | Esito | Misure di mitigazione più un'eventuale consultazione preventiva | Piano di trattamento e accettazione del rischio residuo | --- ## Data Protection Officer (DPO) **URL:** https://cyberacademy.net/it/resources/encyclopedia/dpo **Last reviewed:** 2026-06-24 Il DPO è il ruolo previsto dal GDPR che monitora la conformità, consiglia il titolare del trattamento e funge da punto di contatto con l'autorità di controllo. Obbligatorio per le autorità pubbliche e per i trattamenti che richiedono un monitoraggio sistematico su larga scala o dati di categoria speciale. Indipendenza e accesso al management sono i due elementi che gli auditor verificano concretamente. ## A cosa serve il ruolo Il Data Protection Officer è la persona che un'organizzazione nomina per mantenere corretto il proprio trattamento dei dati personali ai sensi del GDPR. Il compito non è gestire progetti sulla privacy né approvare la conformità, ma verificare se l'organizzazione fa ciò che la legge e le sue stesse policy richiedono, fornire consulenza al titolare e al responsabile del trattamento, formare e sensibilizzare, ed essere il punto di contatto unico per l'autorità di controllo e per gli interessati che intendono esercitare i propri diritti. Il DPO informa e fornisce consulenza, ma la responsabilità del trattamento resta in capo al titolare. Un DPO è obbligatorio in tre situazioni: quando il trattamento è effettuato da un'autorità pubblica, quando le attività principali richiedono un monitoraggio regolare e sistematico delle persone su larga scala, e quando le attività principali comportano il trattamento su larga scala di categorie particolari di dati come dati sanitari, biometrici o relativi a condanne penali. Le organizzazioni che non rientrano in questi presupposti possono comunque nominare un DPO su base volontaria, e molte lo fanno perché offre loro un referente interno chiaro per le questioni relative alla privacy. ## Indipendenza e accesso, i due aspetti che gli auditor verificano Quando un regolatore o un auditor interno esamina la funzione del DPO, due aspetti decidono se sia reale o di facciata. Il primo è l'indipendenza. Il DPO non deve ricevere istruzioni sul modo di svolgere i propri compiti, non può essere rimosso o penalizzato per aver svolto correttamente il proprio lavoro e non deve essere posto in una posizione in cui controlli le proprie decisioni. Per questo un DPO di norma non dovrebbe essere anche il CISO, il responsabile IT o il responsabile marketing, perché tali ruoli definiscono le finalità e i mezzi del trattamento che il DPO deve esaminare. Il secondo è l'accesso. Il DPO deve riferire al più alto livello dirigenziale ed essere coinvolto, tempestivamente e in modo adeguato, in tutte le questioni relative alla protezione dei dati personali. > **Il conflitto di interessi è il rilievo classico** Nominare un DPO che è anche titolare dei sistemi che dovrebbe sorvegliare è uno dei motivi più frequenti per cui un'autorità di controllo conclude che il ruolo non è realmente indipendente. Tenete il DPO fuori dalle decisioni sulle finalità e sui mezzi del trattamento. - Verifica la conformità al GDPR e alle policy interne di protezione dei dati. - Fornisce consulenza sulle valutazioni d'impatto sulla protezione dei dati (DPIA) e contribuisce a riesaminarle. - Coopera con l'autorità di controllo e ne è il punto di contatto. - Gestisce la comunicazione con gli interessati in merito ai loro diritti. ## Come il DPO si rapporta ai concetti affini Il DPO è una persona e un dovere, non un framework di controllo. Il GDPR è il regolamento che istituisce il ruolo e ne fissa i compiti. La DPIA è uno degli strumenti su cui il DPO fornisce consulenza, una valutazione strutturata svolta prima dell'avvio di un trattamento ad alto rischio. ISO 27701 è lo standard di gestione delle informazioni sulla privacy rispetto al quale un'organizzazione può certificarsi, e una funzione di DPO ben gestita si allinea naturalmente ai suoi requisiti pur non coincidendo con essa. La CDPSE è una certificazione professionale che attesta che un ingegnere della privacy o un DPO sa integrare la privacy nei sistemi. Un DPO può essere un dipendente o un fornitore di servizi esterno, e un gruppo di imprese può nominare un unico DPO purché tale persona resti raggiungibile da ciascuno stabilimento e conservi indipendenza e risorse sufficienti a coprirli tutti. --- ## Defense in depth **URL:** https://cyberacademy.net/it/resources/encyclopedia/defense-in-depth **Last reviewed:** 2026-06-24 Defense in depth è il principio di stratificare i controlli in modo che nessun singolo punto di cedimento comprometta il sistema. Rete, endpoint, applicazione, dati, persone, fisico: ogni livello rallenta l'attaccante, aumenta il costo e guadagna tempo per il rilevamento. Principio fondante fin dagli anni Novanta. Gli auditor si aspettano di vederlo applicato; i vendor adorano vendere livelli aggiuntivi. ## Perché la stratificazione batte un unico muro robusto La difesa in profondità parte da un'ipotesi pessimista: qualsiasi controllo prima o poi finirà per cedere. Un firewall mal configurato, una patch in ritardo, un'email di phishing che va a segno, una credenziale che trapela. Se la vostra sicurezza poggia su un'unica barriera, quel singolo guasto segna la fine della partita. Stratificare i controlli significa che l'aggressore che supera il perimetro si trova comunque di fronte alla protezione degli endpoint, poi a reti segmentate, poi a controlli applicativi, poi a dati cifrati, poi a un monitoraggio che osserva l'intero percorso. Ogni livello è indipendente, quindi la probabilità che cedano tutti contemporaneamente è molto più bassa della probabilità che ne ceda uno solo. Il valore per il professionista non è solo la prevenzione, è il tempo e la visibilità. Ogni livello che l'aggressore deve superare gli costa fatica, genera rumore e crea un'opportunità per il vostro team di rilevamento e risposta di accorgersi dell'intrusione prima che raggiunga i dati che contano. La difesa in profondità riguarda tanto il guadagnare tempo di rilevamento quanto il bloccare del tutto la violazione. ## I livelli, e cosa risiede in ciascuno I professionisti di solito ragionano per livelli concentrici piuttosto che per un elenco piatto di prodotti. Il punto è la copertura di tutte le categorie, non l'acquisto di ogni strumento di una stessa categoria. Un modo comune di organizzare i livelli: - Fisico: locali chiusi a chiave, badge di accesso e controlli sulle apparecchiature, affinché un aggressore non possa semplicemente raggiungere a piedi l'hardware. - Persone: formazione di sensibilizzazione, simulazioni di phishing e processi chiari, perché gli utenti sono al tempo stesso un bersaglio e un controllo. - Rete: segmentazione, firewall e ispezione del traffico, affinché un punto d'appoggio in una zona non garantisca l'accesso all'intero parco. - Endpoint: irrobustimento, EDR e gestione delle patch sulle macchine dove gli attacchi vengono effettivamente eseguiti. - Applicazione: sviluppo sicuro, validazione degli input e controlli di autenticazione a livello software. - Dati: cifratura a riposo e in transito, classificazione e controlli di accesso, affinché l'asset stesso resti protetto anche se un livello superiore viene violato. > **Livelli, non duplicazione** La difesa in profondità significa controlli indipendenti distribuiti su categorie diverse, non tre firewall di tre fornitori. Impilare strumenti ridondanti in un livello lasciandone un altro scoperto è un errore comune e costoso. Mappate i vostri controlli rispetto ai livelli e cercate le lacune, non le sovrapposizioni. ## Come si collega allo zero trust e al privilegio minimo La difesa in profondità è il principio più antico e ampio. Lo zero trust e il privilegio minimo ne sono espressioni moderne più affinate, mosse dallo stesso istinto. Il privilegio minimo consiste nel concedere a ogni identità solo l'accesso di cui ha bisogno, il che limita quanto lontano possa arrivare un singolo account compromesso, aggiungendo di fatto un livello all'interno del sistema anziché attorno ad esso. Lo zero trust abbandona l'assunto che qualunque cosa si trovi all'interno del perimetro sia affidabile, verificando ogni richiesta in modo continuo. Laddove la difesa in profondità classica presupponeva spesso un guscio esterno duro con un interno più morbido, lo zero trust spinge la verifica fino a ogni confine. Sono complementari: un programma maturo utilizza la difesa in profondità come architettura e lo zero trust come modello operativo che rimuove il centro morbido e cedevole. Negli standard e negli audit, l'idea è ovunque anche quando l'espressione non lo è. L'Annex A di ISO/IEC 27001 distribuisce i controlli tra temi organizzativi, relativi alle persone, fisici e tecnologici, il che è difesa in profondità sotto un altro nome. I framework del NIST e i CIS Controls sono strutturati in modo che nessuna singola salvaguardia sostenga l'intero carico. Gli auditor si aspettano di vedere controlli stratificati con una motivazione documentata, e trattano un singolo punto di guasto come un rilievo, non come una scelta progettuale. --- ## Dichiarazione di Applicabilità (SoA) **URL:** https://cyberacademy.net/it/resources/encyclopedia/soa **Last reviewed:** 2026-06-24 La SoA è il documento controllato che indica all'auditor quali controlli dell'Annex A si applicano all'organizzazione, per quale motivo e dove si trova l'evidenza. Obbligatoria ai sensi di ISO 27001. L'incoerenza tra SoA, piano di trattamento del rischio e operazioni reali è la causa più frequente di non conformità nell'audit di stage 2. ## Perché ISO 27001 rende il SoA obbligatorio La dichiarazione di applicabilità è il ponte tra il vostro lavoro sui rischi e i controlli che un auditor ispezionerà effettivamente. ISO/IEC 27001 lascia deliberatamente aperto il corpo della norma su quali controlli dobbiate attuare, perché la risposta corretta dipende dal vostro contesto e dai vostri rischi. Il SoA è dove colmate quel divario: per ogni controllo di riferimento dell'Allegato A, registrate se si applica, la giustificazione per includerlo o escluderlo, se è già attuato e dove risiedono le evidenze a supporto. È uno dei pochi documenti che la norma indica esplicitamente come output richiesto, motivo per cui nessun audit di certificazione procede senza di esso. Un modo utile di pensarci è che il SoA trasforma un catalogo di controlli generico in una dichiarazione che riguarda specificamente la vostra organizzazione. Il set di riferimento dell'Allegato A è lo stesso per tutti. Il vostro SoA no. Due aziende certificate di dimensioni simili possono legittimamente escludere controlli diversi, perché le loro valutazioni del rischio e il loro contesto operativo differiscono. Il documento esiste per rendere quelle scelte visibili e difendibili anziché implicite. ## Come il SoA si collega alla valutazione del rischio e al trattamento del rischio Il SoA non sta in piedi da solo. È il prodotto a valle della valutazione del rischio e del piano di trattamento del rischio, e i tre devono concordare. La valutazione del rischio identifica cosa potrebbe andare storto. Il piano di trattamento del rischio decide cosa fare per ciascun rischio, compresi quali controlli applicare. Il SoA dichiara poi, controllo per controllo, cosa significa quella decisione rispetto al set di riferimento dell'Allegato A. Quando un auditor legge il SoA, in realtà sta verificando che la linea che va da un rischio documentato a una decisione di trattamento, poi a un controllo applicato, poi a un'evidenza reale, regga da un capo all'altro. > **Lo scostamento è il rilievo classico della fase 2** La non conformità più comune all'audit di fase 2 è l'incoerenza tra il SoA, il piano di trattamento del rischio e ciò che l'organizzazione fa realmente. Un controllo contrassegnato come applicabile e attuato nel SoA, senza alcuna evidenza né realtà operativa alle spalle, è peggio di un'esclusione onesta. Riconciliate i tre prima che lo faccia l'auditor al posto vostro. Le esclusioni meritano particolare attenzione. Contrassegnare un controllo come non applicabile è legittimo, ma solo con una motivazione dichiarata e legata al vostro contesto. «Non sviluppiamo software internamente» è una base difendibile per restringere certi controlli di sviluppo. «Non ci siamo arrivati» non è un'esclusione, è una lacuna. Gli auditor indagano le esclusioni proprio perché è lì che le organizzazioni a volte nascondono lavoro incompiuto. ## Ciò che i professionisti mantengono realmente Trattare il SoA come un registro vivo anziché come un foglio di calcolo una tantum è ciò che separa un audit di sorveglianza scorrevole da una corsa affannosa. In pratica, mantenerlo bene assomiglia a questo: 1. Tenete una riga per ogni controllo dell'Allegato A, con applicabilità, giustificazione, stato di attuazione e un riferimento all'evidenza che un auditor possa seguire senza di voi nella stanza. 1. Rigenerate il SoA ogni volta che cambiano la valutazione del rischio o il piano di trattamento, così che i tre documenti non divergano mai in silenzio. 1. Collegate ogni riferimento all'evidenza a qualcosa di reale e attuale: una politica, una configurazione, un ticket, un log, non una promessa di produrlo in seguito. 1. Riesaminate il documento a una cadenza fissa e in occasione del riesame della direzione, non solo nelle settimane precedenti un audit. 1. Nel passaggio tra versioni della norma, rimappate il SoA rispetto al set di controlli rivisto e confermate che nulla sia sfuggito tra controlli accorpati o di nuova introduzione. Fatto in questo modo, il SoA smette di essere scartoffie da audit e diventa l'indice dell'intero sistema di gestione della sicurezza delle informazioni. È il primo documento che un auditor esperto richiede, perché gli dice dove risiede tutto il resto. --- ## Digital Operational Resilience Act (DORA) **URL:** https://cyberacademy.net/it/resources/encyclopedia/dora **Last reviewed:** 2026-06-24 DORA è il regolamento UE che impone un framework di resilienza uniforme agli enti finanziari e ai loro fornitori ICT critici. Cinque pilastri: gestione del rischio ICT, segnalazione degli incidenti, test di resilienza incluso il TLPT, rischio ICT di terze parti, condivisione delle informazioni. Applicabile dal 17 gennaio 2025. Incide in modo più stringente di NIS 2 sul versante ICT; in quanto lex specialis, prevale per gli enti finanziari. ## Perché DORA esiste e chi vincola Prima di DORA, la resilienza operativa digitale delle entità finanziarie nell'UE era un mosaico. Le banche rispondevano a un insieme di aspettative di vigilanza, gli assicuratori a un altro, e le regole su incidenti ICT, esternalizzazione e test variavano per settore e per Stato membro. DORA sostituisce questa frammentazione con un unico regolamento che si applica direttamente in tutta l'Unione, senza necessità di recepimento nazionale. Il suo ambito è volutamente ampio: banche, assicuratori, imprese di investimento, istituti di pagamento e di moneta elettronica, prestatori di servizi per le cripto-attività, sedi di negoziazione e molti altri, oltre ai prestatori terzi critici di servizi ICT da cui tali entità dipendono. Quest'ultimo punto è ciò che rende DORA diverso da una normale regola finanziaria. Non regola soltanto le imprese vigilate; arriva fino alla loro catena di approvvigionamento. I fornitori cloud, gli operatori di data center e i fornitori di software ritenuti critici per il sistema finanziario possono essere posti sotto vigilanza diretta a livello UE. Per un professionista, la conseguenza pratica è che la resilienza non è più qualcosa che si può esternalizzare del tutto e dimenticare. Lei resta responsabile del rischio ICT che i suoi fornitori comportano, e deve dimostrarlo. ## I cinque pilastri nella pratica DORA si fonda su cinque pilastri, e ciascuno si traduce in lavoro concreto di programma anziché in scartoffie: - Gestione del rischio ICT. Un quadro di governance di competenza dell'organo di gestione, che copre identificazione, protezione, rilevamento, risposta e ripristino per gli asset ICT. È la spina dorsale a cui si agganciano gli altri quattro pilastri. - Gestione e segnalazione degli incidenti. Classificare gli incidenti connessi alle ICT per gravità e segnalare quelli gravi all'autorità competente entro tempi definiti. L'accento è posto su una tassonomia armonizzata affinché le autorità di vigilanza di tutta l'UE vedano dati comparabili. - Test di resilienza operativa digitale. Un programma di test regolare che spazia dalle valutazioni delle vulnerabilità fino ai test di penetrazione guidati dalla minaccia (TLPT) per le entità più significative, modellati sul comportamento reale degli avversari. - Gestione del rischio dei terzi ICT. Garanzie contrattuali, registri delle informazioni su tutti gli accordi ICT, strategie di uscita e il regime di vigilanza per i prestatori terzi critici. - Condivisione delle informazioni. Scambio volontario di intelligence sulle minacce informatiche tra entità finanziarie, incoraggiato anziché imposto, per rafforzare la difesa collettiva. > **Resilienza, non solo sicurezza** DORA riguarda il fatto che il sistema finanziario resti operativo sotto stress, non solo il tenere fuori gli aggressori. Per questo si appoggia così fortemente su test, ripristino e continuità con i terzi. Presuppone che le cose si rompano e chiede se lei sia in grado di continuare a erogare le funzioni critiche quando ciò accade, ed è qui che si sovrappone alla continuità operativa e a ISO 22301. ## DORA accanto a NIS 2 La domanda che i professionisti pongono più spesso è come DORA si rapporti a NIS 2, poiché entrambi sono strumenti dell'UE che toccano la cibersicurezza ed entrambi raggiungono all'incirca lo stesso livello di maturità. La risposta breve è lex specialis: dove DORA e NIS 2 si applicherebbero entrambi a un'entità finanziaria sull'angolo ICT, DORA prevale perché è la regola più specifica. NIS 2 fissa un'ampia base di cibersicurezza in molti settori; DORA approfondisce la resilienza ICT del settore finanziario e aggiunge il regime di vigilanza sui terzi che NIS 2 non ha. **DORA confrontato con NIS 2** | Dimensione | DORA | NIS 2 | | --- | --- | --- | | Tipo di strumento | Regolamento, direttamente applicabile | Direttiva, recepita dagli Stati membri | | Ambito primario | Entità finanziarie e i loro prestatori ICT critici | Soggetti essenziali e importanti in molti settori | | Focus | Resilienza operativa digitale del sistema finanziario | Gestione e segnalazione generale del rischio di cibersicurezza | | Vigilanza sui terzi | Vigilanza diretta dell'UE sui prestatori ICT critici | Attesa sicurezza della catena di approvvigionamento, nessun regime di vigilanza diretta | | Precedenza per la finanza | Prevale come lex specialis sull'angolo ICT | Cede a DORA dove entrambi si applicherebbero | In termini quotidiani, una banca non può sceglierne uno. Mappa i propri obblighi e constata che, per il rischio ICT, la segnalazione degli incidenti e i test di resilienza, DORA è il testo che governa, mentre NIS 2 può ancora rilevare per parti del gruppo che esulano dall'ambito finanziario di DORA. Il modo pulito di gestire questo è un unico quadro di controllo, spesso ancorato a ISO 27001 e ISO 22301, che soddisfi entrambi i regimi e consenta di evidenziare la conformità una sola volta. --- ## Direttiva NIS 1 (NIS 1) **URL:** https://cyberacademy.net/it/resources/encyclopedia/nis-1 **Last reviewed:** 2026-06-24 NIS 1 (Direttiva 2016/1148) è stata la prima direttiva europea di cybersecurity intersettoriale, applicabile agli operatori di servizi essenziali e ai fornitori di servizi digitali. Sostituita da NIS 2 nell'ottobre 2024, perché l'ambito di applicazione era troppo ristretto, il regime sanzionatorio disomogeneo e gli obblighi di notifica degli incidenti privi di efficacia reale. Citata qui principalmente per chiarire cosa fosse effettivamente il "vecchio regime" che i colleghi ricordano ancora vagamente. ## Cosa NIS 1 si proponeva di fare La Direttiva NIS 1 è stata il primo tentativo dell'Unione europea di porre un livello minimo comune di cybersicurezza sotto i settori che tengono in funzione un paese. Prima di essa, gli Stati membri affrontavano la sicurezza delle infrastrutture critiche secondo i propri criteri, senza una base condivisa e senza un modo coordinato di gestire gli incidenti transfrontalieri. NIS 1 ha cambiato tutto ciò chiedendo a ogni Stato membro di individuare gli operatori la cui interruzione avrebbe avuto un grave effetto a catena, di sottoporli a obblighi di sicurezza e di notifica degli incidenti, e di istituire la macchina nazionale incaricata di vigilarli. In Francia tale macchina era l'ANSSI, e gli operatori che essa ha designato conoscevano già il regime più pesante degli OIV, precedente alla direttiva. Essendo una direttiva e non un regolamento, NIS 1 non si applicava direttamente. Ogni Stato membro doveva recepirla nel diritto nazionale, ed è da qui che derivava gran parte della disomogeneità. Due Stati potevano leggere lo stesso testo e arrivare a elenchi diversi di soggetti regolamentati, a soglie di notifica diverse e a propensioni molto diverse verso l'applicazione. Questo mosaico è la principale ragione per cui il regime è stato infine ricostruito. ## Due categorie: servizi essenziali e fornitori di servizi digitali NIS 1 ha diviso il mondo regolamentato in due gruppi, e la distinzione conta perché gli obblighi e la vigilanza non erano simmetrici. **Categorie NIS 1** | Aspetto | Operatori di servizi essenziali | Fornitori di servizi digitali | | --- | --- | --- | | Chi erano | Energia, trasporti, settore bancario, infrastrutture dei mercati finanziari, sanità, acqua potabile, infrastrutture digitali | Mercati online, motori di ricerca, servizi di cloud computing | | Come venivano inclusi | Individuati caso per caso da ciascuno Stato membro in base a criteri | Inclusi automaticamente nell'ambito, con un approccio più leggero | | Vigilanza | Proattiva: le autorità potevano svolgere audit ed esigere prove | Per lo più reattiva: intervento dopo un incidente | | Aspettativa di sicurezza | Misure tecniche e organizzative adeguate e proporzionate | Misure simili, ma un regime regolamentare più leggero | Gli operatori di servizi essenziali erano il cuore della direttiva. Gli Stati membri dovevano nominarli, e una volta nominati portavano obblighi reali di gestire il rischio e di notificare gli incidenti significativi all'autorità nazionale o al CSIRT. I fornitori di servizi digitali venivano trattati in modo più leggero, sulla teoria che operassero già oltre i confini e competessero sulla resilienza, cosicché un regime armonizzato ma più leggero avrebbe evitato di frammentare il mercato unico. > **Perché si sente ancora parlare di NIS 1** Se un collega parla di essere un «operatore regolamentato» o del fatto che l'ANSSI ha designato la sua organizzazione, di solito sta ricordando l'era di NIS 1. Gli obblighi non sono scomparsi, sono stati assorbiti ed estesi da NIS 2, entrata in vigore nell'ottobre 2024. ## Perché è stata sostituita Il giudizio onesto su NIS 1 è che ha dimostrato il concetto ma ha mantenuto meno del promesso. Tre debolezze sono emerse ripetutamente. L'ambito era troppo ristretto, lasciando interi settori e la maggior parte delle organizzazioni di medie dimensioni al di fuori di qualsiasi obbligo, anche quando il loro fallimento avrebbe arrecato danno. L'applicazione era disomogenea, perché il recepimento lasciava a ciascuno Stato membro decidere chi rientrasse nell'ambito e con quanta fermezza spingere, cosicché un'azienda poteva essere regolamentata in un paese e intoccata appena oltre confine. E la notifica degli incidenti era di fatto innocua, con soglie e tempistiche che variavano così tanto che la visibilità transfrontaliera che la direttiva avrebbe dovuto creare non si è mai davvero concretizzata. NIS 2 è stata la risposta a tutti e tre. Ha ampliato l'ambito a molti più settori e a un criterio basato sulle dimensioni, ha sostituito la divisione OES/DSP con soggetti essenziali e importanti, ha irrigidito la notifica degli incidenti in fasi più chiare e ha posto una reale responsabilità della direzione e sanzioni dietro gli obblighi. Per un professionista di oggi, NIS 1 è soprattutto contesto: spiega la forma delle regole sotto cui ora vive e i riflessi che la sua organizzazione ha costruito prima della ricostruzione. --- ## Direttiva ePrivacy (ePrivacy) **URL:** https://cyberacademy.net/it/resources/encyclopedia/eprivacy **Last reviewed:** 2026-06-24 La Direttiva ePrivacy (2002/58/CE, modificata nel 2009) è la «cookie law» che tutti implementano a metà. Disciplina la riservatezza delle comunicazioni elettroniche e le tecnologie di tracciamento sui dispositivi degli utenti. Precedente al GDPR e tuttora in vigore; il Regolamento ePrivacy che avrebbe dovuto sostituirla è bloccato in sede negoziale dal 2017. Le autorità nazionali di protezione dei dati (CNIL, Garante, AEPD) la applicano nei rispettivi ambiti territoriali. ## Cosa disciplina davvero la Direttiva ePrivacy La Direttiva ePrivacy (2002/58/CE, modificata dalla 2009/136/CE) è nota soprattutto come «legge sui cookie», ma ridurla ai cookie ne fa perdere gran parte del peso. Il suo vero oggetto è la riservatezza delle comunicazioni elettroniche e la protezione dell'apparecchiatura terminale dell'utente. Stabilisce che le comunicazioni e i relativi dati sul traffico sono riservati, che l'intercettazione e la sorveglianza necessitano di una base giuridica, e che memorizzare o leggere informazioni sul dispositivo di una persona, che si tratti di un cookie, di un pixel di tracciamento, di un fingerprint o di un SDK, richiede generalmente un consenso preventivo. La parte relativa al consenso e al tracciamento è quella che la maggior parte dei team implementa; la parte sulla riservatezza è quella di cui la maggior parte dei team dimentica l'esistenza. È una direttiva, non un regolamento. Questa distinzione è all'origine di metà della confusione nella pratica. Una direttiva fissa l'obiettivo e lascia a ciascuno Stato membro il compito di recepirla nel diritto nazionale, sicché la formulazione esatta, la soglia di consenso e lo stile applicativo differiscono da un paese all'altro. In Francia le disposizioni pertinenti si trovano nel Code des postes et des communications électroniques, e la CNIL pubblica proprie linee guida e raccomandazioni su cookie e tracker. Non esiste un unico testo a livello di Unione che si possa citare come si cita il GDPR. ## ePrivacy accanto al GDPR I due strumenti sono complementari, non intercambiabili. La Direttiva ePrivacy è lex specialis: laddove pone una regola specifica, quella regola prevale sulla disposizione più generale del GDPR. L'esempio più chiaro sono i cookie e la memorizzazione sul dispositivo. Il GDPR disciplina il modo in cui tratti i dati personali che raccogli; ePrivacy disciplina l'atto di accedere a informazioni sul dispositivo o di memorizzarvele in primo luogo, e si applica anche quando non vi sono dati personali coinvolti. Così un tracker che deposita un identificativo puramente tecnico ricade comunque sotto ePrivacy, anche se sosterresti che non si tratta di un dato personale ai sensi del GDPR. Il consenso ai sensi di ePrivacy mutua la propria definizione dal GDPR. Quando ePrivacy richiede il consenso, questo deve rispettare lo standard del GDPR: libero, specifico, informato, inequivocabile e revocabile con la stessa facilità con cui è prestato. Per questo le caselle pre-spuntate, i banner del tipo «continuando a navigare accetti» e i cookie wall che non offrono una scelta reale continuano a non superare il controllo delle autorità di vigilanza. I due testi si leggono insieme. > **Più vecchia del GDPR, ancora in vigore** ePrivacy precede il GDPR di ben più di un decennio e resta pienamente in vigore. Il Regolamento ePrivacy che avrebbe dovuto sostituirla e allineare il calendario a quello del GDPR è bloccato in negoziazione dal 2017. Finché non vede la luce, la direttiva del 2002 come modificata nel 2009, più il recepimento di ciascun paese, è la legge a cui ti conformi. ## Cosa fanno davvero i professionisti Nel lavoro quotidiano, la conformità a ePrivacy riguarda soprattutto lo strato del consenso e l'inventario che vi sta dietro. Il programma pratico si presenta così: - Inventariare ogni cookie, tag, pixel, SDK e script che legge dal dispositivo o vi scrive, e classificare ciascuno come strettamente necessario o meno. Solo quelli strettamente necessari sono esenti dal consenso. - Bloccare i tracker non essenziali finché l'utente non ha prestato il consenso, anziché attivarli al caricamento della pagina e chiedere dopo. Una piattaforma di gestione del consenso di solito impone questo comportamento. - Rendere il rifiuto fluido quanto l'accettazione, registrare il consenso e il suo ambito, e offrire un modo semplice per revocarlo in seguito. - Tenere d'occhio anche gli obblighi di riservatezza: il marketing diretto via e-mail o SMS richiede generalmente un consenso preventivo (opt-in), con una stretta eccezione per i clienti esistenti su prodotti analoghi. L'applicazione è nazionale. Poiché non esiste un regolatore centrale dell'UE per ePrivacy, ciascuna autorità di protezione dei dati vigila sul proprio territorio. La CNIL in Francia, il Garante in Italia e l'AEPD in Spagna emanano ciascuna linee guida, conducono audit e irrogano sanzioni in base ai rispettivi recepimenti nazionali. Ciò significa che un sito paneuropeo non può presumere che un solo banner accontenti tutti; l'approccio prudente è soddisfare l'interpretazione più rigorosa tra i mercati che servi e documentare le scelte che hai fatto. --- ## Disaster Recovery (DR) **URL:** https://cyberacademy.net/it/resources/encyclopedia/disaster-recovery **Last reviewed:** 2026-06-24 Il disaster recovery è il sottoinsieme dell'BCM focalizzato sull'IT: ripristino di infrastrutture, applicazioni e dati dopo un'interruzione. RPO, RTO e runbook appartengono a questo ambito. Un piano di DR mai testato end-to-end è una finzione. ISO 24762 lo disciplinava in precedenza; la pratica attuale rimanda a ISO 22301 e ai runbook operativi. ## Dove si colloca il disaster recovery all'interno della continuità Il disaster recovery è la sala macchine tecnica della continuità operativa. La gestione della continuità operativa si chiede come l'organizzazione continui a erogare le proprie attività critiche durante un'interruzione, coprendo persone, sedi, fornitori e processi. Il disaster recovery risponde a una domanda più ristretta: come riportiamo in funzione l'IT. Server, reti, applicazioni, database e i dati stessi. Quando un data center si allaga, un ceppo di ransomware cifra la produzione o una regione cloud si spegne, il piano di disaster recovery è il documento e la memoria muscolare che rimettono in funzione i sistemi in un ordine noto, fino a un punto nel tempo noto. Questa distinzione è importante perché i due vengono spesso confusi. Un piano di continuità può descrivere soluzioni manuali che mantengono in vita un servizio mentre l'IT è fuori uso. Un piano di disaster recovery non ha questo lusso. Viene giudicato unicamente in base al fatto che i sistemi tornino, con quale rapidità e quanti dati siano andati persi. Trattare il disaster recovery come un sottoinsieme della continuità anziché come un sinonimo mantiene onesto il perimetro e impedisce ai team di presumere che un server ripristinato significhi un servizio di business ripristinato. ## RTO, RPO e il runbook Due numeri governano ogni decisione di disaster recovery. L'obiettivo del tempo di ripristino (RTO) è il tempo massimo tollerabile in cui un sistema può rimanere inattivo prima che l'impatto diventi inaccettabile. L'obiettivo del punto di ripristino (RPO) è la quantità massima tollerabile di perdita di dati, espressa come finestra temporale, che in pratica determina la frequenza con cui si replica o si esegue il backup. Un RTO di quattro ore con un RPO di quindici minuti è un'architettura molto diversa, e un budget molto diverso, da un RTO al giorno lavorativo successivo con un backup giornaliero. Questi obiettivi dovrebbero derivare da un'analisi di impatto sul business, non dal livello di comodità del team infrastrutturale. - L'RTO guida l'architettura di ripristino: standby a caldo e replica per obiettivi stringenti, ripristino da backup per quelli più rilassati. - L'RPO guida la strategia di protezione dei dati: replica sincrona, snapshot o backup periodici. - Il runbook trasforma quegli obiettivi in una procedura di ripristino testata, passo dopo passo, che qualcuno sotto pressione può effettivamente seguire. > **Un piano non testato è una finzione** Un piano di disaster recovery che non è mai stato esercitato end to end è un'ipotesi, non una capacità. I backup mai ripristinati, il failover mai attivato e i runbook che nessuno ha provato falliscono regolarmente nel momento peggiore. Pianificate test di ripristino, conducete simulazioni a tavolino del flusso decisionale e documentate le lacune che ogni esercizio rivela. ## Norme, minacce e prassi attuale Il panorama normativo è cambiato. ISO/IEC 24762 forniva un tempo indicazioni dedicate sui servizi di disaster recovery ICT, ma è stata ritirata, e la prassi attuale rimanda a ISO 22301 per il sistema di gestione della continuità operativa, con ISO/IEC 27031 che copre la preparazione ICT alla continuità operativa. In quel modello il disaster recovery non è una disciplina a sé stante; è il livello operativo che realizza la strategia di continuità, governato dallo stesso sistema di gestione e dalla stessa propensione al rischio. I settori regolamentati aggiungono la loro pressione: il regime di resilienza del settore finanziario dell'UE, per esempio, si aspetta che le imprese dimostrino che il ripristino e la continuità delle funzioni critiche siano testati, non solo documentati. Il disaster recovery moderno è inoltre plasmato dalle minacce che deve assorbire. Il ransomware in particolare ha riscritto il copione, perché se i vostri backup sono raggiungibili e scrivibili dall'ambiente di produzione, un attaccante cifra anche quelli. Gli operatori ora preferiscono backup immutabili e isolati, ambienti di ripristino segmentati e ricostruzioni in camera bianca affinché il ripristino non reinfetti semplicemente. Il cloud e l'infrastructure-as-code hanno reso alcuni ripristini più rapidi da automatizzare, ma introducono i propri singoli punti di guasto a livello di regione, account e identità. La disciplina è la stessa di sempre: conoscete i vostri obiettivi, proteggete i vostri dati affinché sopravvivano al disastro, scrivete un runbook che qualcuno possa seguire e dimostrate che funziona prima di averne bisogno. --- ## Distributed Denial of Service (DDoS) **URL:** https://cyberacademy.net/it/resources/encyclopedia/ddos **Last reviewed:** 2026-06-24 DDoS è l'attacco che inondata un servizio da molteplici sorgenti per esaurirne la capacità. Può operare a livello volumetrico, di protocollo o applicativo. La mitigazione è ormai una commodity (Cloudflare, Akamai, AWS Shield). La domanda di rischio non è più «riusciamo a bloccarlo» ma «i servizi critici sono instradati attraverso la protezione, incluse le API che non compaiono mai nei dashboard». ## Cosa fa davvero un attacco di tipo distributed denial of service Un attacco di tipo denial of service ha un unico obiettivo: rendere un servizio indisponibile per chi ne dipende. La versione distribuita, il DDoS, lo ottiene generando il traffico da molte macchine contemporaneamente, spesso una botnet di dispositivi compromessi, server dirottati o infrastrutture di attacco noleggiate. Poiché il carico arriva da migliaia di indirizzi distinti, non si può semplicemente bloccare un singolo responsabile, ed è l'enorme numero di sorgenti a permettere all'attaccante di sopraffare una capacità che una singola macchina non potrebbe mai raggiungere. Il bersaglio non deve essere violato né subire un furto di dati. Deve solo essere messo offline, il che fa del DDoS un attacco alla disponibilità anziché alla riservatezza o all'integrità. I professionisti di solito classificano il DDoS in tre livelli, perché il livello determina la difesa. Gli attacchi volumetrici cercano di saturare la banda del collegamento stesso, ricorrendo spesso all'amplificazione, in cui una piccola richiesta contraffatta innesca una risposta di grandi dimensioni diretta alla vittima. Gli attacchi di protocollo esauriscono lo stato negli apparati di rete e nei server, ad esempio lasciando connessioni semiaperte che non si completano mai. Gli attacchi al livello applicativo sono i più silenziosi: inviano richieste che sembrano legittime, come chiamate ripetute a un endpoint di ricerca o a una pagina di accesso, ed esauriscono l'applicazione anziché il canale. Quest'ultima categoria è la più difficile da separare dagli utenti reali. ## Perché la mitigazione non è più la parte difficile Fermare il traffico DDoS è diventato un servizio di base. Grandi fornitori come Cloudflare, Akamai e AWS Shield assorbono gli attacchi ai margini di reti enormi, incassando le ondate volumetriche molto a monte del cliente e filtrando gli abusi di protocollo e applicativi con scrubbing e limitazione della frequenza. Per la maggior parte delle organizzazioni, la domanda tecnica se un attacco possa essere bloccato ha un sì sicuro, a condizione che il traffico sia instradato attraverso quella protezione. La domanda più difficile, e quella che una funzione di gestione del rischio dovrebbe porsi, è di copertura più che di capacità. Il divario che fa male è l'asset che nessuno ha instradato attraverso lo scudo. Un sito di marketing pubblico si trova dietro la CDN, ma l'API chiamata dall'app mobile, l'indirizzo IP di origine ereditato che non è mai stato dismesso, l'endpoint di integrazione con un partner o il servizio regionale avviato da un altro team possono risolvere direttamente all'origine, aggirando del tutto la protezione. Gli attaccanti trovano questi percorsi diretti e li prendono di mira. Una difesa DDoS efficace è quindi anzitutto un problema di inventario e instradamento: conoscere ogni servizio esposto su internet, confermare che ciascuno sia effettivamente dietro la mitigazione e dimostrare che l'origine non può essere raggiunta aggirandola. > **L'API non protetta è la vera esposizione** La mitigazione funziona solo per il traffico che la attraversa. I servizi che mettono in ginocchio un'organizzazione sono di solito quelli che non si vedono mai in una dashboard: un indirizzo IP di origine diretto, un endpoint di API o un sottodominio dimenticato che risolve aggirando la protezione. Mappa ogni asset esposto su internet, poi dimostra che ciascuno è instradato attraverso lo scudo. ## Dove si colloca il DDoS nella continuità e negli standard Poiché il DDoS attacca la disponibilità, rientra nella stessa conversazione della gestione della continuità operativa. Un sistema di gestione della sicurezza delle informazioni allineato a ISO/IEC 27001 tratta la disponibilità come una delle tre proprietà che protegge, e uno scenario di denial of service è un input da manuale per un'analisi di impatto sul business: per quanto tempo ogni servizio può restare inattivo, cosa dipende da esso e qual è il ripiego. La risposta è raramente un singolo controllo. Combina la mitigazione a monte, un runbook di risposta agli incidenti con contatti nominativi presso il fornitore di mitigazione e accordi di continuità per il periodo in cui un attacco viene assorbito. Ciò che i professionisti fanno davvero, oltre ad acquistare la mitigazione, è provare e verificare. Mantengono un inventario accurato dei servizi esposti su internet, confermano che ciascuno sia dietro la protezione e verificano che l'origine sia irraggiungibile direttamente. Tarano i limiti di frequenza e le pagine di sfida per gli abusi del livello applicativo, poiché quegli attacchi imitano il traffico reale e non possono essere risolti con la sola banda. Scrivono il percorso di escalation prima di un incidente, così che durante un'ondata nessuno vada a caccia del numero di telefono giusto. E trattano un evento DDoS come un esercizio di continuità, con soglie chiare per attivare il piano, comunicare ai clienti e rimettere in funzione i servizi una volta che il traffico si attenua. --- ## EBIOS Risk Manager (EBIOS RM) **URL:** https://cyberacademy.net/it/resources/encyclopedia/ebios-rm **Last reviewed:** 2026-06-24 EBIOS Risk Manager è il metodo di gestione del rischio cyber di ANSSI, incentrato sugli scenari di attacco strategici. Mette in relazione i processi di business con gli obiettivi degli attaccanti, per poi derivare i controlli tecnici. È lo standard nel settore pubblico francese e tra gli operatori di importanza vitale. Particolarmente efficace per mostrare al board perché uno scenario specifico sia rilevante; meno diffuso negli audit multinazionali del settore privato. ## Cosa fa realmente EBIOS Risk Manager EBIOS Risk Manager è il metodo di valutazione del rischio cyber gestito da ANSSI, l'agenzia nazionale francese per la cybersicurezza. La sua mossa distintiva è partire dall'attaccante, non da un elenco di asset. Invece di catalogare ogni server e chiedersi cosa potrebbe andare storto per ciascuno, il metodo si chiede chi vorrebbe danneggiare l'organizzazione, cosa cercherebbe di ottenere e quali missioni di business prenderebbe di mira per arrivarci. I controlli tecnici vengono per ultimi, derivati dagli scenari, anziché costituire il punto di partenza. Questa logica inversa è ciò che rende EBIOS RM utile davanti a un consiglio di amministrazione. Un registro dei rischi tradizionale, costruito dal basso verso l'alto, produce centinaia di voci che significano poco per i dirigenti. EBIOS RM produce una manciata di scenari strategici, come un attore sponsorizzato da uno Stato che interrompe un servizio critico, o un concorrente che esfiltra dati di progettazione, ciascuno legato a una missione di business concreta. Questa impostazione risponde alla domanda che i dirigenti pongono davvero: perché questa specifica minaccia ci riguarda, e quanto ci costerebbe se si verificasse. ## I cinque workshop EBIOS RM è strutturato come una sequenza di workshop, ciascuno basato sul precedente. Il metodo è deliberatamente collaborativo: riunisce nella stessa stanza i responsabili di business, gli specialisti del rischio e i team di sicurezza, anziché lasciare l'analisi a un singolo analista. 1. Ambito e base di sicurezza. Definire il perimetro di business e tecnico, identificare le missioni e gli eventi temuti, e valutare la base di sicurezza esistente rispetto a quanto atteso. 1. Origini del rischio. Identificare le origini del rischio e i loro obiettivi mirati, l'abbinamento tra chi potrebbe attaccare e cosa cerca, quindi dare priorità a quelle più rilevanti. 1. Scenari strategici. Mappare l'ecosistema di partner, fornitori e parti interessate, valutare come un attaccante potrebbe raggiungere l'organizzazione attraverso di essi, e costruire percorsi di attacco di alto livello. 1. Scenari operativi. Tradurre gli scenari strategici in sequenze di attacco tecniche concrete, descrivendo come un avversario si muoverebbe realmente attraverso i sistemi. 1. Trattamento del rischio. Decidere le misure di sicurezza, costruire il piano di trattamento e documentare il rischio residuo che la direzione accetta formalmente. > **Guidata dagli scenari, non dagli asset** EBIOS RM deriva i controlli da scenari di attacco realistici anziché da un inventario esaustivo degli asset. Questo mantiene l'analisi concentrata sulle minacce che contano davvero per il business, e fornisce alla direzione una base difendibile per accettare o trattare il rischio residuo. ## Dove si applica e dove no EBIOS RM è il metodo di riferimento nel settore pubblico francese e tra gli operatori di importanza vitale, dove le aspettative normative rimandano alle linee guida di ANSSI. È anche ampiamente insegnato e utilizzato nelle organizzazioni francofone. Al di fuori di tale contesto, negli audit multinazionali del settore privato, è molto più probabile incontrare ISO 27005, che è la norma internazionale per la gestione del rischio di sicurezza delle informazioni ed è indipendente dal metodo per impostazione. I due sono complementari più che rivali. ISO 27005 descrive un processo generico di gestione del rischio allineato con ISO 27001 e ISO 31000, ma non prescrive un'unica tecnica. EBIOS RM è un modo concreto e riconosciuto di condurre tale processo, e ANSSI lo posiziona come compatibile con l'approccio ISO. Un team può condurre i workshop EBIOS RM e riportare comunque i risultati in termini ISO 27005. **EBIOS Risk Manager a confronto con ISO 27005** | Aspetto | EBIOS Risk Manager | ISO 27005 | | --- | --- | --- | | Origine | ANSSI (Francia) | Norma internazionale ISO/IEC | | Natura | Metodo prescrittivo con workshop definiti | Linee guida di gestione del rischio indipendenti dal metodo | | Punto di partenza | Obiettivi dell'attaccante e missioni di business | Asset, minacce e vulnerabilità | | Contesto tipico | Settore pubblico francese, operatori di importanza vitale | Audit internazionali di SGSI del settore privato | In pratica, conoscere EBIOS RM segnala dimestichezza con l'ecosistema ANSSI, e conoscere ISO 27005 segnala dimestichezza con il mondo delle norme internazionali. I professionisti del rischio che operano sui mercati europei e francese traggono vantaggio dal padroneggiare entrambi, perché il metodo a cui si ricorre dipende da chi leggerà il rapporto. --- ## EU AI Act (AI Act) **URL:** https://cyberacademy.net/it/resources/encyclopedia/ai-act **Last reviewed:** 2026-06-24 L'EU AI Act è la prima regolamentazione completa sull'intelligenza artificiale al mondo. Quattro livelli di rischio: inaccettabile (vietato), alto (obblighi sostanziali e valutazione di conformità), limitato (trasparenza), minimo. Si applica per fasi fino ad agosto 2027. Da abbinare a ISO 42001 per una risposta basata su sistema di gestione, non su checklist. Le regole sui modelli GPAI si aggiungono in cima. ## Una legge basata sul rischio, non un divieto tecnologico Il EU AI Act regola l'intelligenza artificiale in base a ciò che un sistema fa e a chi può colpire, non in base all'algoritmo che lo sottende. La stessa tecnica di machine learning può essere non regolamentata in un contesto e strettamente controllata in un altro. È questa l'idea centrale dei quattro livelli di rischio: le pratiche inaccettabili sono vietate del tutto, i sistemi ad alto rischio portano gli obblighi più pesanti, i sistemi a rischio limitato devono trasparenza alle persone che interagiscono con essi, e i sistemi a rischio minimo restano in gran parte intatti. La maggior parte dell'IA di uso quotidiano si colloca in quella fascia minima, ed è per questo che l'Act si comprende meglio come una regolamentazione mirata degli usi rilevanti piuttosto che come un regime di licenza generalizzato per tutta l'IA. L'Act è un regolamento, quindi si applica direttamente in ogni Stato membro senza che ciascun paese debba recepirlo nel diritto nazionale. La sua portata è anche extraterritoriale nello spirito: fornitori e deployer al di fuori dell'UE rientrano nell'ambito di applicazione quando il loro sistema di IA è immesso sul mercato dell'UE o i suoi output sono utilizzati nell'Unione. I professionisti dovrebbero mappare i propri sistemi rispetto ai livelli fin da subito, perché la classificazione determina tutto ciò che segue, dalla documentazione alla valutazione della conformità. ## Dove gli obblighi mordono davvero Quasi tutto il peso operativo ricade sui sistemi ad alto rischio. Si tratta tipicamente di IA utilizzata in prodotti regolamentati o in ambiti sensibili come le infrastrutture critiche, l'occupazione, l'accesso ai servizi essenziali, l'applicazione della legge e l'amministrazione della giustizia. Per questi, l'Act si attende un insieme di discipline operative anziché un modulo una tantum: un sistema di gestione del rischio mantenuto lungo l'intero ciclo di vita, una governance dei dati di addestramento e di test, documentazione tecnica, registrazione, trasparenza e istruzioni per l'uso, una sorveglianza umana che consenta a una persona di intervenire in modo significativo, e un livello adeguato di accuratezza, robustezza e cibersicurezza. Prima che un sistema ad alto rischio raggiunga il mercato deve superare una valutazione della conformità, e i fornitori effettuano un monitoraggio post-commercializzazione una volta che è operativo. > **Fornitore e deployer non sono lo stesso ruolo** L'Act ripartisce gli obblighi tra il fornitore che sviluppa o immette il sistema sul mercato e il deployer che lo utilizza sotto la propria autorità. Una banca che impiega un modello di credit scoring di terzi assume i doveri del deployer, come la sorveglianza umana e il monitoraggio, mentre il fornitore assume i doveri del fornitore. Sapere quale cappello indossi decide quali obblighi sono tuoi. ## GPAI, trasparenza e il calendario per fasi Al di sopra dei livelli si colloca un regime separato per i modelli di IA per finalità generali, i modelli di base che alimentano molte applicazioni a valle. I fornitori di GPAI affrontano doveri di trasparenza e documentazione, con requisiti più rigorosi per i modelli più capaci giudicati portatori di rischio sistemico. Questo livello è stato aggiunto proprio perché un singolo modello per finalità generali può confluire in innumerevoli usi ad alto rischio e a rischio limitato, cosicché regolamentare solo l'applicazione finale lascerebbe un vuoto. Gli obblighi a rischio limitato sono più leggeri ma reali. Si incentrano sulla trasparenza: le persone dovrebbero sapere quando stanno interagendo con un sistema di IA, e determinati contenuti sintetici o manipolati dovrebbero essere contrassegnati come generati artificialmente. L'Act entra in vigore e si applica per fasi, con i divieti, le regole GPAI e gli obblighi ad alto rischio che si attivano in momenti diversi fino al 2027, il che offre alle organizzazioni un margine ma anche una sequenza di scadenze tassative da pianificare. ## Come i professionisti lo rendono operativo In pratica l'Act è un elenco di obblighi legali, non un metodo di gestione, perciò i team lo abbinano a un sistema in grado di portare quegli obblighi giorno per giorno. ISO/IEC 42001 è la risposta comune: un sistema di gestione dell'IA ti fornisce le valutazioni del rischio, la governance dei dati, le routine di sorveglianza umana e di monitoraggio post-commercializzazione che l'Act si attende, condotte come un sistema ripetibile anziché improvvisate sotto la pressione delle scadenze. Il NIST AI Risk Management Framework è spesso utilizzato in parallelo come struttura volontaria per identificare e trattare il rischio legato all'IA. Nessuno di questi rende da solo un sistema legalmente conforme. Rendono la conformità raggiungibile e verificabile, che è la differenza tra dimostrare la dovuta diligenza e sperare che nessuno chieda. --- ## Endpoint Detection and Response (EDR) **URL:** https://cyberacademy.net/it/resources/encyclopedia/edr **Last reviewed:** 2026-06-24 EDR è la piattaforma basata su agente che registra l'attività degli endpoint, rileva comportamenti sospetti e consente agli analisti di isolare o rimediare gli host compromessi. XDR estende la visibilità su endpoint, rete e cloud; MDR è il servizio gestito che li racchiude. L'endpoint rimane il vettore d'ingresso più comune; EDR è oggi un requisito di base, non un elemento differenziante. ## Cosa fa davvero l'EDR sull'host Endpoint Detection and Response esegue un agente leggero su ogni postazione di lavoro, laptop e server a cui tieni. Quell'agente registra in continuazione ciò che fa il sistema operativo: i processi che si avviano, le righe di comando che eseguono, i file scritti, le chiavi di registro modificate, le connessioni di rete aperte e le sessioni utente avviate. Questo flusso di telemetria è il cuore dell'EDR. Dove l'antivirus tradizionale poneva una sola domanda, «questo file è noto come dannoso», l'EDR ne pone una più difficile, «questa sequenza di comportamenti è sospetta», il che gli consente di intercettare attacchi fileless, tecniche di living-off-the-land e l'abuso di strumenti legittimi che non rilasciano mai un campione di malware riconoscibile. La parte «response» è ciò che distingue l'EDR da un sensore passivo. Quando un host è compromesso, un analista può agire dalla console: isolare la macchina dalla rete mantenendo viva la connessione dell'agente, terminare un processo dannoso, mettere in quarantena un file, raccogliere artefatti forensi o annullare le modifiche. Questa capacità di contenere un singolo endpoint senza toccarlo fisicamente, nel pieno di un incidente in corso, è quella su cui i professionisti fanno più affidamento. La telemetria alimenta anche l'indagine, così chi risponde può ricostruire l'intera catena delle azioni di un attaccante invece di limitarsi a bloccare la prima fase. ## EDR, XDR e MDR: conoscere la differenza Questi tre acronimi vengono venduti fianco a fianco ed è facile confonderli. Non sono tanto prodotti concorrenti quanto ambiti e modelli di erogazione diversi costruiti attorno alla stessa idea centrale. **EDR vs XDR vs MDR** | Termine | Ambito | Che cos'è | | --- | --- | --- | | EDR | Solo endpoint | La piattaforma basata su agenti che registra, rileva e risponde sugli host. La gestisci tu stesso. | | XDR | Endpoint, rete, cloud, identità, posta elettronica | Estende e correla il rilevamento su più livelli, non solo l'endpoint, per individuare gli attacchi che attraversano più domini. | | MDR | Ciò che copre il fornitore | Un servizio gestito: un team esterno esegue il rilevamento e la risposta per conto tuo, spesso appoggiandosi a EDR o XDR. | La lettura pratica è semplice. L'EDR è la tecnologia sull'host. L'XDR è la stessa filosofia di rilevamento ampliata per acquisire segnali oltre l'endpoint e correlarli. L'MDR è una decisione di esternalizzazione: acquisti gli analisti e la copertura continua, non solo lo strumento. Un piccolo team senza un SOC 24/7 abbina spesso l'EDR a un fornitore di MDR affinché gli alert vengano vagliati alle tre del mattino. ## Dove si colloca l'EDR nelle tue operazioni e nel tuo SGSI L'EDR funziona raramente da solo. I suoi rilevamenti e la sua telemetria grezza vengono comunemente inoltrati a un SIEM per la correlazione con i log di firewall, provider di identità e applicazioni, e gli alert risultanti vengono lavorati da un SOC. In quel pipeline l'EDR è il sensore ad alta fedeltà più vicino al punto in cui ha inizio la maggior parte delle intrusioni, poiché l'endpoint resta il punto di ingresso più comune tramite phishing, credenziali rubate e software vulnerabile. Dal punto di vista della governance, l'EDR è ciò che rende reali, anziché aspirazionali, diversi obiettivi di controllo. Nell'ambito di un SGSI ISO/IEC 27001 supporta i controlli relativi alla protezione dal malware, alla registrazione dei log, al monitoraggio e al lato tecnico della gestione degli incidenti, e produce le evidenze che un auditor si aspetta di vedere. Sostiene inoltre la capacità di rilevamento e risposta che framework come il modello delle funzioni di cybersecurity del NIST e normative come NIS2 e DORA presuppongono che un'organizzazione mantenga. La shortDefinition lo dice chiaramente: l'EDR è ormai un requisito di base, non un fattore di differenziazione. > **Uno strumento non è una capacità** Distribuire l'EDR è la parte facile. Il valore nasce dalla copertura di ogni asset, da rilevamenti ottimizzati e da persone che vagliano e rispondono. Un agente installato sulla metà del parco macchine, che genera alert che nessuno legge, fornisce garanzia sulla carta e nessuna nella pratica. --- ## Gestione delle vulnerabilità **URL:** https://cyberacademy.net/it/resources/encyclopedia/vulnerability-management **Last reviewed:** 2026-06-24 La gestione delle vulnerabilità è il ciclo di individuazione, prioritizzazione, remediation e verifica delle vulnerabilità nel proprio ambiente. Gli scanner segnalano migliaia di problemi; la disciplina risiede nella prioritizzazione (criticità dell'asset + disponibilità dell'exploit + esposizione al business) piuttosto che nella scansione. CVE, CVSS e KEV sono il vocabolario di riferimento. ## Un ciclo, non una scansione La gestione delle vulnerabilità è spesso ridotta all'«avviare lo scanner», ma la scansione è la parte facile. La disciplina è un ciclo che si ripete: mantenere un inventario accurato di ciò che si possiede, individuare le debolezze su quegli asset, dare priorità alla manciata che conta davvero, porvi rimedio e verificare che la correzione abbia tenuto. Uno scanner moderno ti consegnerà migliaia di rilevamenti su un parco di medie dimensioni. Trattare quell'elenco come una coda di attività è il modo in cui i team si esauriscono mentre la loro esposizione reale resta aperta. Il valore sta nell'imbuto, dalle migliaia di rilevamenti grezzi fino al piccolo insieme su cui agisci questa settimana. Dipende anche da qualcosa che la maggior parte dei team sottovaluta: conoscere il proprio parco. Una vulnerabilità su un server esposto a Internet che esegue un'applicazione aziendale critica è un problema diverso dallo stesso difetto su una macchina di test isolata. Senza inventario degli asset e titolarità, la prioritizzazione non ha nulla su cui poggiare, ed è per questo che il ciclo inizia con la scoperta e l'identificazione piuttosto che con la scansione in sé. ## Il vocabolario: CVE, CVSS e KEV Tre punti di riferimento sostengono gran parte della conversazione sulla prioritizzazione, e i professionisti li usano in combinazione piuttosto che da soli. **Come vengono usati CVE, CVSS e KEV** | Termine | Che cos'è | Cosa ti indica | | --- | --- | --- | | CVE | Un identificatore univoco per una vulnerabilità divulgata pubblicamente | Un nome comune affinché tutti parlino dello stesso difetto attraverso strumenti e avvisi di sicurezza. | | CVSS | Un quadro di punteggio che valuta la gravità | Quanto è grave il difetto in teoria, in base all'impatto e alle caratteristiche di sfruttabilità. Un punto di partenza, non un verdetto. | | KEV | Un catalogo di vulnerabilità note per essere sfruttate in circolazione | Se gli attaccanti la stanno effettivamente usando ora, il che aumenta nettamente la priorità nel mondo reale. | L'errore comune è ordinare per punteggio CVSS e procedere dall'alto verso il basso. Un CVSS elevato su un asset che nessuno può raggiungere conta meno di un difetto di gravità media presente in un catalogo di vulnerabilità note per essere sfruttate su un sistema esposto. I programmi maturi combinano la gravità teorica con segnali reali: esiste un exploit funzionante, la vulnerabilità è attivamente sfruttata, e quanto è esposto e critico l'asset interessato. È quella combinazione, non il punteggio grezzo, a guidare la coda. ## La prioritizzazione è tutto il lavoro L'inquadramento onesto è che la prioritizzazione è il prodotto della gestione delle vulnerabilità. Gli input sono la criticità dell'asset, la disponibilità di un exploit e l'esposizione del business, e l'output è una decisione difendibile su cosa viene corretto per primo e cosa attende. È qui che la funzione si guadagna il proprio valore, perché nessun team può né dovrebbe porre rimedio a tutto in una volta. 1. Criticità dell'asset: cosa fa il sistema per il business e cosa può raggiungere se compromesso. 1. Disponibilità di un exploit: se esiste un exploit funzionante e se il difetto viene usato in circolazione. 1. Esposizione del business: l'asset è esposto a Internet, quali dati contiene, e quali controlli compensativi si trovano già a monte. > **Dove finisce la gestione delle vulnerabilità e dove inizia la gestione delle patch** La gestione delle vulnerabilità decide cosa correggere e in quale ordine. La gestione delle patch è il macchinario operativo che prende una correzione pubblicata e la distribuisce su tutto il parco secondo uno SLA, con verifica. Sono due metà di un unico risultato: la prima dà priorità, la seconda consegna, e il passaggio di verifica chiude il cerchio fino allo scanner. ## Dove si colloca nella governance La gestione delle vulnerabilità è raramente facoltativa una volta che ci si trova all'interno di un quadro riconosciuto. Un SGSI ISO/IEC 27001 prevede un processo definito per gestire le vulnerabilità tecniche, e gli auditor chiederanno di vedere il ciclo in funzione, non solo una licenza dello scanner. Il NIST Cybersecurity Framework considera l'identificazione e la gestione delle vulnerabilità come centrali per le funzioni Identify e Protect, e normative come NIS2 e DORA presuppongono che le organizzazioni individuino e correggano attivamente le debolezze invece di attendere che un incidente le riveli. In ogni caso, la prova che un valutatore desidera ha la stessa forma: come scopri, come dai priorità, gli SLA secondo cui poni rimedio, e le metriche che dimostrano che il ciclo si sta chiudendo. --- ## ISO 19011 (ISO 19011) **URL:** https://cyberacademy.net/it/resources/encyclopedia/iso-19011 **Last reviewed:** 2026-06-24 ISO 19011 è la norma di riferimento per le linee guida sull'audit dei sistemi di gestione. Generica, si applica indifferentemente agli audit ISO 27001, 9001 e 22301. Definisce i principi di audit, la gestione del programma di audit, il ciclo di audit e la competenza degli auditor. Il corso Lead Auditor la insegna; gli auditor che si incontrano sul campo sono stati formati su di essa. ## Che cosa copre davvero la ISO 19011 La ISO 19011 è il documento di riferimento per chiunque pianifichi, conduca o gestisca audit di sistemi di gestione. È volutamente generica, così gli stessi principi si applicano sia che si auditi un sistema di gestione della sicurezza delle informazioni rispetto alla ISO 27001, un sistema qualità rispetto alla ISO 9001 o la continuità operativa rispetto alla ISO 22301. Anziché indicarvi i requisiti che un'organizzazione deve soddisfare, vi spiega come osservare quei requisiti in qualità di auditor : come costruire un programma di audit, come condurre un singolo audit dalla riunione di apertura a quella di chiusura, e come giudicare se le persone che svolgono l'audit sono competenti. La norma organizza l'audit attorno a un piccolo insieme di principi. L'integrità e la presentazione imparziale mantengono onesti i rilievi. La dovuta diligenza professionale e la riservatezza tutelano le persone e le informazioni coinvolte. Un approccio basato sull'evidenza significa che le conclusioni si fondano su registrazioni e osservazioni verificabili, non su impressioni ; e il pensiero basato sul rischio aggiunto nelle revisioni recenti spinge gli auditor a concentrare l'impegno dove conta di più per gli obiettivi. ## Programma di audit, ciclo dell'audit e competenza Un modo utile di leggere la ISO 19011 è vederla come tre strati annidati. In cima si colloca il programma di audit, l'insieme degli audit pianificati in un periodo e la gestione di tale programma : definire gli obiettivi, assegnare le risorse, monitorare i risultati e migliorare nel tempo. Al suo interno si colloca il singolo audit e il suo ciclo : - Avviare l'audit e confermarne la fattibilità con l'organizzazione sottoposta ad audit. - Preparare le attività di audit, compresi il riesame documentale e il piano di audit. - Condurre l'audit in sede o da remoto : riunione di apertura, raccolta e verifica delle evidenze, generazione dei rilievi. - Redigere il rapporto, comprese le conclusioni e la riunione di chiusura. - Completare l'audit ed effettuare ogni eventuale follow-up sulle azioni correttive. Il terzo strato è la competenza dell'auditor. La ISO 19011 presenta la competenza come una combinazione di comportamento personale, conoscenze e abilità generiche di audit e conoscenze specifiche di una disciplina, quindi descrive come valutarla e mantenerla. Per questo un professionista della sicurezza non può limitarsi a leggere la norma una sola volta. La competenza è qualcosa che si costruisce attraverso la formazione, l'osservazione di audit e la pratica continua. > **Linee guida, non certificazione** La ISO 19011 è una norma di linee guida, quindi non ci si certifica rispetto ad essa nel modo in cui un'organizzazione si certifica rispetto alla ISO 27001. Quando si certifica un sistema di gestione, l'organismo di certificazione opera secondo la ISO/IEC 17021-1, che attinge agli stessi concetti di audit. ## Dove i professionisti la incontrano In pratica si incontra la ISO 19011 in due ruoli. Come organizzazione sottoposta ad audit, essa spiega ciò che un auditor competente farà e non farà, il che aiuta a preparare le evidenze e a contestare rilievi poco solidi. Come auditor, interno o rivolto ai fornitori, è il manuale che si segue per rendere gli audit ripetibili e difendibili. Il corso Lead Auditor insegna questa norma insieme ai requisiti del sistema sottoposto ad audit, e gli auditor esterni che si incontrano durante la certificazione sono stati formati sullo stesso materiale. --- ## ISO 22301 (ISO 22301) **URL:** https://cyberacademy.net/it/resources/encyclopedia/iso-22301 **Last reviewed:** 2026-06-24 ISO 22301 è lo standard internazionale per i sistemi di gestione della continuità operativa (BCMS). Specifica i requisiti per pianificare, gestire, monitorare e migliorare un BCMS che ripristina le operazioni critiche dopo un'interruzione. È richiesto con crescente frequenza dai regolatori finanziari in applicazione del DORA e dalle autorità di vigilanza NIS 2 per gli operatori di servizi essenziali. ## Che cosa richiede davvero ISO 22301 ISO 22301 è la norma di requisiti per un sistema di gestione della continuità operativa, un SGCO. La parola sistema conta. Non è un piano che si redige una volta e si archivia, ma un ciclo gestito: comprendi ciò che fa la tua organizzazione, decidi quali attività non puoi permetterti di perdere a lungo, costruisci la capacità di mantenerle operative o di ripristinarle rapidamente, e poi mantieni affidabile quella capacità attraverso esercitazioni, riesami e miglioramenti. Trattandosi di una norma di requisiti, un'organizzazione può essere sottoposta ad audit e certificata rispetto a essa da un organismo accreditato, ed è ciò che dà a un cliente o a un regolatore qualcosa di concreto su cui fare affidamento. Come ISO 27001 e le altre moderne norme ISO per i sistemi di gestione, ISO 22301 segue la High-Level Structure. Ciò significa che condivide lo stesso scheletro: contesto dell'organizzazione, leadership, pianificazione, supporto, attività operative, valutazione delle prestazioni e miglioramento, il tutto su un ciclo Plan-Do-Check-Act. In pratica questo è un vantaggio, perché se gestisci già un sistema di gestione della sicurezza delle informazioni riutilizzi la stessa governance, lo stesso linguaggio del rischio, la stessa macchina di audit interno, e innesti la continuità al di sopra anziché costruire una struttura parallela. ## Il lavoro dietro il certificato Tre attività si collocano al cuore di un programma ISO 22301, e un professionista vi dedica gran parte del proprio tempo anziché alla documentazione: - Analisi di impatto sul business. La BIA identifica le tue attività prioritarie e stabilisce con quale rapidità ciascuna debba essere ripristinata. È ciò che produce gli obiettivi di tempo di ripristino che guidano ogni decisione successiva. Senza una BIA difendibile, la tua strategia di continuità è una congettura. - Valutazione del rischio. Esamini ciò che potrebbe interrompere quelle attività prioritarie, da un'epidemia di ransomware al fallimento di un fornitore o a un data center allagato, così che la tua strategia affronti minacce reali anziché una lista di controllo generica. - Strategia e piani di continuità. Sulla base della BIA e del quadro dei rischi, scegli come proteggere e ripristinare ciascuna attività, poi redigi e doti di risorse le procedure che le persone seguono realmente quando tutto si spegne. > **La continuità è più ampia del ripristino IT** ISO 22301 copre l'intera organizzazione, non solo i sistemi. Persone, sedi, fornitori e processi contano tutti. Il disaster recovery IT è uno degli input della continuità, la parte che ripristina la tecnologia, ma il SGCO pone una domanda più ampia: l'azienda può continuare a erogare i propri prodotti e servizi critici, con qualsiasi mezzo, mentre il ripristino tecnico è in corso. ## Perché i regolatori vi rimandano sempre più ISO 22301 era un tempo una discreta norma di resilienza operativa che le organizzazioni mature adottavano per scelta. Questo è cambiato. Come osserva la shortDefinition, i regolatori finanziari che si appoggiano a DORA e le autorità di vigilanza che fanno rispettare NIS 2 si aspettano ora una capacità di continuità dimostrabile per le operazioni critiche, e ISO 22301 è il modo più riconosciuto per darne evidenza. La norma non menziona alcuna regolamentazione specifica, ma la sua disciplina, attività prioritarie, obiettivi di ripristino definiti, piani testati, dipendenze mappate, corrisponde con precisione a ciò che quei regimi richiedono. Certificarsi rispetto a essa consente a un'organizzazione di rispondere a un'autorità di vigilanza con un'attestazione indipendente anziché con un'autovalutazione. Una frequente fonte di confusione è la relazione con ISO 27001. Sono sorelle, non sostitute. ISO 27001 governa la sicurezza delle informazioni, proteggendo riservatezza, integrità e disponibilità delle informazioni. ISO 22301 governa la continuità, mantenendo l'azienda operativa attraverso la perturbazione. La disponibilità è il ponte: un'organizzazione seria in materia di resilienza spesso gestisce entrambe, le certifica insieme per condividere audit e riesami della direzione, e tratta la continuità come la risposta alla domanda che la sola sicurezza non può risolvere, ossia cosa accade quando la prevenzione fallisce e devi comunque erogare. **ISO 22301 accanto a ISO 27001** | Dimensione | ISO 22301 | ISO 27001 | | --- | --- | --- | | Oggetto | Sistema di gestione della continuità operativa | Sistema di gestione della sicurezza delle informazioni | | Domanda centrale | Possiamo continuare a erogare le attività critiche in caso di perturbazione | Stiamo proteggendo i nostri asset informativi | | Artefatti distintivi | Analisi di impatto sul business, strategia di continuità, piani testati | Trattamento del rischio, Dichiarazione di applicabilità, controlli | | Innesco a cui risponde | Si è verificata una perturbazione, ripristinare e proseguire | Una minaccia alle informazioni, prevenire e proteggere | | Terreno comune | High-Level Structure, PDCA, certificabile, spesso gestite insieme | High-Level Structure, PDCA, certificabile, spesso gestite insieme | --- ## ISO 31000 (ISO 31000) **URL:** https://cyberacademy.net/it/resources/encyclopedia/iso-31000 **Last reviewed:** 2026-06-24 ISO 31000 è lo standard generico per la gestione del rischio. Principi, framework e processo iterativo. NON è un sistema di gestione certificabile: non esiste un ISO 31000 Lead Auditor, nonostante quanto affermato da alcuni cataloghi. Il percorso PECB è Foundation → Risk Manager → Lead Risk Manager. Da utilizzare quando il rischio va oltre la sola sicurezza delle informazioni. ## Una norma generica, non un sistema di gestione ISO 31000 è il riferimento internazionale per gestire il rischio di qualsiasi natura, in qualsiasi organizzazione. È volutamente generica. Gli stessi principi, lo stesso quadro di riferimento e lo stesso processo si applicano sia che il rischio in questione sia finanziario, operativo, strategico, legato alla sicurezza, ambientale o cyber. Questa ampiezza è proprio l'obiettivo. Una decisione di acquisto, l'ingresso in un nuovo mercato e un'esposizione a un ransomware possono essere valutati tutti con lo stesso vocabolario e la stessa logica, il che consente a un consiglio di amministrazione di confrontare rischi che altrimenti resterebbero in silos separati con valutazioni incompatibili. L'equivoco più diffuso è trattare ISO 31000 come ISO 27001 o ISO 22301. Non è una norma di requisiti e non è certificabile. Non esiste alcun sistema di gestione ISO 31000 da sottoporre ad audit né alcuna qualifica di Lead Auditor ISO 31000, qualunque cosa pubblicizzino alcuni cataloghi di formazione. La norma offre linee guida da adattare, non requisiti a cui conformarsi. Le organizzazioni la integrano nel modo in cui già operano, anziché aggiungere un sistema certificato separato. ## Principi, quadro di riferimento e processo ISO 31000 si fonda su tre parti collegate che i professionisti imparano a tenere distinte. I principi enunciano come si presenta una buona gestione del rischio: è integrata nell'organizzazione, strutturata, adattata al contesto, inclusiva verso le parti interessate, dinamica, basata sulle migliori informazioni disponibili e orientata a creare e proteggere valore. Il quadro di riferimento riguarda la leadership e la governance, il modo in cui la gestione del rischio viene disposta, progettata, attuata, valutata e migliorata nel tempo affinché si radichi davvero. Il processo è il motore operativo che si esegue ripetutamente. 1. Stabilire il contesto. Definire l'ambito, gli obiettivi e l'ambiente interno ed esterno in cui vive il rischio. 1. L'identificazione, l'analisi e la ponderazione del rischio, che insieme formano la valutazione del rischio. 1. Il trattamento del rischio. Scegliere come modificare il rischio, quindi attuare e verificare i controlli. 1. La comunicazione, la consultazione, il monitoraggio e il riesame, che avvolgono l'intero ciclo e lo mantengono aggiornato. > **Usala quando il rischio è più ampio della sicurezza delle informazioni** ISO 31000 ti offre il linguaggio ombrello per il rischio a livello di intera organizzazione. Quando ti concentri specificamente sul rischio di sicurezza delle informazioni, ricorri a una norma settoriale come ISO 27005 o a un metodo come EBIOS Risk Manager, entrambi i quali si collocano comodamente al di sotto del processo ISO 31000. ## Come si rapporta alle norme vicine ISO 31000 è la norma madre. ISO 27005 applica la stessa logica di processo al rischio di sicurezza delle informazioni e si allinea a un sistema di gestione della sicurezza delle informazioni ISO 27001. EBIOS Risk Manager, il metodo francese pubblicato dall'ANSSI, è un modo concreto e basato su scenari di condurre una valutazione del rischio di sicurezza che si mappa sulle stesse fasi. Nessuna di queste contraddice ISO 31000; la specializzano. Un risk manager che comprende il processo generico può passare dall'una all'altra senza riapprendere i fondamenti, ed è per questo che la norma viene insegnata per prima. Il vocabolario è condiviso tramite la Guida ISO 73, il documento complementare che definisce i termini della gestione del rischio affinché «probabilità», «conseguenza» e «trattamento del rischio» significhino la stessa cosa in tutti i documenti e in tutti i team. Concordare presto su tali definizioni evita le dispute sulle valutazioni che fanno deragliare molti workshop sul rischio. ## Cosa ne fanno davvero i professionisti In pratica, ISO 31000 plasma il registro dei rischi, i workshop di valutazione e la linea di reporting verso la direzione. Un risk manager la usa per giustificare perché un rischio viene assegnato, valutato e trattato in un certo modo, e per dimostrare che l'approccio è coerente anziché improvvisato caso per caso. Poiché la norma non è certificabile, il modo riconosciuto per dimostrare la competenza è attraverso una credenziale personale. Il percorso PECB si articola in Foundation, poi Risk Manager, poi Lead Risk Manager, partendo dalla conoscenza dei concetti fino alla guida di un programma di gestione del rischio in tutta un'organizzazione. --- ## ISO/IEC 27001 (ISO 27001) **URL:** https://cyberacademy.net/it/resources/encyclopedia/iso-27001 **Last reviewed:** 2026-06-24 ISO 27001 è il framework certificabile che gli auditor utilizzano per valutare la sicurezza delle informazioni. La revisione del 2022 ha ridotto l'Annex A a 93 controlli distribuiti su quattro temi (organizzativo, persone, fisico, tecnologico). Il vostro ISMS si regge o cade sulla Statement of Applicability e sulle evidenze operative. Tutti lo citano; pochi lo gestiscono davvero. ## Che cosa certifica realmente la ISO/IEC 27001 La ISO/IEC 27001 è la norma internazionale che specifica i requisiti per un sistema di gestione della sicurezza delle informazioni, o SGSI. Il certificato non afferma che i vostri sistemi siano inviolabili. Afferma che un organismo accreditato ha esaminato come individuate i rischi relativi alle informazioni, decidete cosa farne e mantenete attiva tale decisione sotto la supervisione della direzione. La norma si fonda sul ciclo Plan-Do-Check-Act, perciò la certificazione non è mai un evento isolato: vi impegnate in un ritmo ricorrente di valutazione del rischio, trattamento, audit interno, riesame della direzione e azione correttiva. Una confusione frequente è considerare i controlli dell'Annex A come la norma stessa. Non lo sono. I requisiti certificabili risiedono nei punti numerati del sistema di gestione (contesto, leadership, pianificazione, supporto, attività operative, valutazione delle prestazioni, miglioramento). L'Annex A è un insieme di riferimento di controlli tra i quali operate una selezione. Potete superare un audit senza attuare ogni controllo, a condizione che la vostra Dichiarazione di applicabilità giustifichi ciò che avete escluso e le vostre evidenze sostengano ciò che avete mantenuto. ## La revisione del 2022 e i temi dei controlli La revisione del 2022 ha riorganizzato l'Annex A in quattro temi anziché nei precedenti quattordici domini. I temi raggruppano i controlli in base al tipo di elemento protetto o governato: - I controlli organizzativi riguardano le politiche, i rapporti con i fornitori, l'intelligence sulle minacce e la sicurezza delle informazioni nella gestione dei progetti. - I controlli relativi alle persone riguardano la verifica, le condizioni di impiego, la consapevolezza e il processo disciplinare. - I controlli fisici riguardano le aree sicure, le apparecchiature, la scrivania pulita e lo smaltimento dei supporti. - I controlli tecnologici riguardano la gestione degli accessi, la crittografia, la registrazione degli eventi, lo sviluppo sicuro e la gestione delle configurazioni. Se vi siete certificati secondo la versione precedente, il lavoro di transizione è per lo più un esercizio di rimappatura: ridefinire la vostra Dichiarazione di applicabilità rispetto al nuovo insieme di controlli, confermare che nulla sia sfuggito attraverso le lacune create da controlli fusi o di nuova introduzione, e aggiornare i riferimenti alle evidenze. I punti del sistema di gestione sono cambiati molto meno rispetto all'annex. > **La SoA è dove gli audit si vincono o si perdono** Le non conformità della fase 2 derivano più spesso dallo scostamento tra la Dichiarazione di applicabilità, il piano di trattamento del rischio e ciò che l'organizzazione fa realmente. Mantenete i tre documenti riconciliati e l'audit diventa un esercizio di verifica anziché un esercizio di scoperta. ## Come si colloca accanto alle norme vicine La ISO 27001 è l'ancora certificabile di una famiglia. La ISO 27002 fornisce indicazioni di attuazione per gli stessi controlli dell'Annex A ma non è certificabile da sola; gli auditor vi ricorrono quando vogliono mettere in discussione la qualità con cui gestite un controllo, non semplicemente se esiste. La ISO 27005 fornisce un metodo per la valutazione del rischio relativo alla sicurezza delle informazioni che il punto 6 richiede ma lascia deliberatamente aperto. Il SGSI è la macchina in funzione che la norma certifica, e la SoA ne è l'artefatto controllato centrale. Sul lato delle persone, il lavoro si divide in due discipline complementari. Gli implementatori costruiscono e gestiscono il sistema di gestione. Gli auditor pianificano e conducono gli audit che lo mettono alla prova, operando secondo le linee guida di audit della ISO 19011. La maggior parte delle funzioni di sicurezza mature ha bisogno di entrambe le mentalità, anche quando all'inizio una sola persona indossa entrambi i cappelli. ## Che cosa fanno realmente i professionisti Gestire bene la ISO 27001, anziché limitarsi a superare il certificato, nella pratica appare così: 1. Definire l'ambito con onestà. Un ambito troppo ampio vi sommerge di evidenze; uno troppo ristretto non inganna nessuno e mina il certificato. 1. Condurre una vera valutazione del rischio e un piano di trattamento, e mantenerli aggiornati man mano che il business e il panorama delle minacce cambiano. 1. Mantenere la Dichiarazione di applicabilità come un documento vivo collegato a evidenze reali, non come un foglio di calcolo compilato una sola volta per l'auditor. 1. Svolgere gli audit interni e i riesami della direzione secondo il calendario, e chiudere le azioni correttive con prove anziché con promesse. 1. Trattare gli audit di sorveglianza e il ciclo di ricertificazione come continuità, non come esercitazioni separate. --- ## ISO/IEC 27002 (ISO 27002) **URL:** https://cyberacademy.net/it/resources/encyclopedia/iso-27002 **Last reviewed:** 2026-06-24 ISO 27002 è la guida all'implementazione dei controlli dell'Annex A di ISO 27001. Non è certificabile da sola. Gli auditor la utilizzano quando vogliono verificare COME si opera un controllo, non solo se è "in essere". Va trattata come il manuale operativo a fianco dello standard di certificazione. ## Che cos'è realmente la norma ISO/IEC 27002 ISO/IEC 27002 è la guida all'implementazione che affianca ISO 27001. Mentre ISO 27001 è la norma certificabile del sistema di gestione che elenca i controlli dell'Allegato A e impone di giustificare quali si applicano, ISO 27002 spiega ciascuno di tali controlli in profondità: la sua finalità, come si presenta una buona pratica e le considerazioni concrete della sua messa in operazione. È un codice di buone pratiche, non un elenco di requisiti da spuntare. Non ci si certifica rispetto a ISO 27002 e un auditor non può emettere una non conformità direttamente nei suoi confronti. La utilizza per interpretare lo spirito di un controllo dell'Allegato A e per mettere in discussione se la vostra implementazione sia davvero adatta allo scopo. Questa distinzione conta negli audit reali. Una verifica superficiale chiede se un controllo sia "in essere". Un auditor che ricorre a ISO 27002 chiede come lo gestite: se la revisione degli accessi avvenga davvero con la cadenza che dichiarate, se la vostra registrazione catturi gli eventi che vi consentirebbero di rilevare un incidente, se le clausole con i fornitori reggano al contatto con una violazione reale. La norma fornisce a entrambe le parti un vocabolario comune per quella conversazione, ed è per questo che i professionisti la trattano come il manuale operativo anziché come una lettura di supporto. ## Come si relaziona con ISO 27001, la SoA e il SGSI I tre documenti formano una catena. Il vostro SGSI è il sistema di gestione che governa l'intero programma. ISO 27001 definisce cosa quel sistema deve fare e fornisce l'insieme dei controlli. La Dichiarazione di Applicabilità (SoA) registra, controllo per controllo, quali avete incluso, quali avete escluso e perché. ISO 27002 è ciò a cui vi rivolgete per la sostanza di ciascun controllo una volta che la SoA vi indica che si applica. In pratica, i team redigono la SoA con ISO 27001 aperta per il requisito e ISO 27002 aperta per la guida all'implementazione, poi progettano il controllo effettivo sulla base della guida. > **Si implementa secondo 27002, ci si certifica rispetto a 27001** Un modo chiaro per ricordare la suddivisione: ISO 27001 vi indica quali controlli considerare e vi obbliga a documentare le vostre decisioni nella SoA. ISO 27002 vi indica come ciascun controllo dovrebbe funzionare. La certificazione audita il sistema di gestione e i controlli che avete selezionato, usando ISO 27002 come riferimento di come si presenta un'implementazione competente. Le edizioni moderne di ISO 27002 organizzano i controlli in quattro temi, organizzativo, relativo alle persone, fisico e tecnologico, e associano a ciascuno attributi come il tipo di controllo, la proprietà di sicurezza che protegge e il concetto di cybersicurezza pertinente. Tali attributi vi permettono di suddividere l'insieme dei controlli in modi diversi, per esempio estraendo tutti i controlli preventivi o tutti quelli che supportano il rilevamento, il che aiuta quando stabilite corrispondenze con altri framework o costruite un piano di trattamento del rischio. ## Cosa ne fanno realmente i professionisti In un programma attivo, ISO 27002 compare in alcune attività ricorrenti: 1. Progettare i controlli: quando la SoA contrassegna un controllo come applicabile, la guida all'implementazione plasma la politica, la procedura o la configurazione tecnica che costruite. 1. Giustificare le decisioni: quando adattate o delimitate l'ambito di un controllo, la guida vi fornisce la motivazione da registrare affinché un auditor possa seguire il vostro ragionamento. 1. Prepararsi all'audit: i team usano la guida per mettere alla prova i propri controlli prima che lo faccia il valutatore, colmando il divario tra "documentato" e "operante con efficacia". 1. Stabilire corrispondenze tra framework: la struttura dei controlli e gli attributi fanno di ISO 27002 una spina dorsale utile per creare passerelle verso insiemi di controlli come i CIS Controls o le linee guida del NIST. Poiché ISO 27002 è una guida anziché un requisito rigido, il giudizio spetta a voi. La norma descrive l'intento e la buona pratica; voi decidete fino a che punto spingervi in base alla vostra valutazione del rischio. Quella libertà è il punto. Permette sia a una piccola società di consulenza sia a una multinazionale di rivendicare entrambe la conformità allo stesso controllo, pur implementandolo a profondità molto diverse, ciascuna appropriata al proprio rischio. --- ## ISO/IEC 27005 (ISO 27005) **URL:** https://cyberacademy.net/it/resources/encyclopedia/iso-27005 **Last reviewed:** 2026-06-24 ISO 27005 è la metodologia per la gestione del rischio di sicurezza delle informazioni che si integra con ISO 27001. Identificazione, analisi, valutazione, trattamento, accettazione. La revisione del 2022 si allinea ai principi di ISO 31000 e chiarisce il rapporto con il Clause 6 di ISO 27001. Meno prescrittivo di EBIOS RM, ma la lingua franca canonica con gli auditor. ## A cosa serve la ISO/IEC 27005 La ISO/IEC 27005 è la norma di orientamento per gestire il rischio relativo alla sicurezza delle informazioni. Non certifica nulla e non sostituisce la ISO/IEC 27001. Vi fornisce invece un metodo per svolgere la valutazione e il trattamento del rischio che il punto 6 della ISO 27001 richiede ma lascia deliberatamente aperti. La ISO 27001 vi dice che dovete identificare, analizzare, ponderare e trattare i rischi per la sicurezza delle informazioni ; la ISO 27005 vi mostra un modo difendibile per farlo. Questa ripartizione dei compiti è la cosa più importante da comprendere riguardo alla norma. Il metodo segue un percorso riconoscibile : stabilire il contesto, identificare i rischi, analizzarli, ponderarli rispetto ai vostri criteri e infine trattarli. Il trattamento si conclude con una decisione e una registrazione, non con un semplice elenco di controlli. Due output contano per gli auditor più di ogni altro. Il primo è il vostro insieme di criteri di accettazione del rischio, concordati prima di iniziare la valutazione affinché i risultati non possano essere ricondotti a posteriori a una risposta conveniente. Il secondo è l'approvazione documentata quando un rischio residuo viene accettato dal responsabile corretto. Sono questi artefatti a trasformare un foglio di calcolo di punteggi in un processo gestito. ## La revisione del 2022 e il legame con la ISO 31000 La revisione attuale allinea il vocabolario e la struttura alla ISO 31000, la norma di gestione del rischio a livello dell'intera organizzazione, affinché il rischio per la sicurezza delle informazioni parli la stessa lingua del rischio aziendale. Precisa inoltre il rapporto con la ISO 27001 mappando le sue attività sui punti della ISO 27001 anziché descrivere un universo parallelo. Laddove l'impostazione più datata si basava fortemente sull'enumerazione di asset, minacce e vulnerabilità, la revisione accoglie sia quella visione basata sugli eventi sia una visione basata sugli scenari, dando ai team lo spazio per valutare il rischio nel modo che si adatta davvero al loro ambiente. > **Raccomandazioni, non requisiti** La ISO 27005 usa la parola dovrebbe, non deve. Non potete essere certificati rispetto ad essa e un auditor non può rilevare una non conformità per essersi discostato dai suoi passi esatti. Ciò che verificherà è che la valutazione del rischio che alimenta il vostro SGSI ISO 27001 sia coerente, ripetibile e documentata. La ISO 27005 è il modo più comune per dimostrarlo. ## La ISO 27005 a confronto con EBIOS RM I professionisti in Francia confrontano costantemente la ISO 27005 con EBIOS Risk Manager, il metodo mantenuto dall'ANSSI. Non sono tanto rivali quanto strumenti diversi. La ISO 27005 è meno prescrittiva, riconosciuta a livello internazionale e costituisce la lingua comune con gli auditor di certificazione, il che la rende la scelta naturale quando il vostro obiettivo è un certificato ISO 27001 valido ovunque. EBIOS RM è più strutturata e orientata agli scenari, costruita attorno a scenari di attacco strategici e operativi e a origini di rischio esplicite, il che si adatta ai contesti francesi ad alto rischio o regolamentati. Molte organizzazioni applicano EBIOS RM per l'analisi e poi esprimono i risultati in termini ISO 27005 per il SGSI. **La ISO/IEC 27005 a confronto con EBIOS Risk Manager** | Dimensione | ISO/IEC 27005 | EBIOS Risk Manager | | --- | --- | --- | | Natura | Norma di orientamento internazionale | Metodo nazionale mantenuto dall'ANSSI | | Stile | Meno prescrittiva, flessibile | Strutturata, orientata a scenari e minacce | | Adattamento migliore | Certificazione ISO 27001, riconoscimento globale | Contesti francesi ad alto rischio e regolamentati | | Pubblico | Auditor di certificazione in tutto il mondo | Settore pubblico francese e operatori critici | ## Cosa fanno davvero i professionisti Usare bene la ISO 27005, anziché produrre un documento una tantum, nella pratica assomiglia a questo : 1. Stabilire prima il contesto : l'ambito, i criteri di impatto e probabilità e le soglie di accettazione del rischio, tutti concordati prima che inizi qualsiasi valutazione. 1. Identificare i rischi nel modo adatto all'ambiente, che si tratti di catene asset-minaccia-vulnerabilità o di scenari end-to-end, ed evitare di mescolare i metodi in modo incoerente all'interno della stessa valutazione. 1. Analizzare e ponderare rispetto ai criteri concordati in anticipo affinché l'elenco delle priorità sia riproducibile, quindi scegliere un'opzione di trattamento : modificare, mantenere, evitare o condividere. 1. Registrare il rischio residuo e ottenere un'accettazione esplicita dal responsabile del rischio designato, perché è questa approvazione a collegare la valutazione alla responsabilità della direzione ai sensi della ISO 27001. 1. Riesaminare la valutazione secondo una cadenza definita e dopo un cambiamento significativo, affinché il quadro del rischio resti aggiornato anziché invecchiare silenziosamente tra un ciclo di certificazione e l'altro. --- ## ISO/IEC 27017 (ISO 27017) **URL:** https://cyberacademy.net/it/resources/encyclopedia/iso-27017 **Last reviewed:** 2026-06-24 ISO 27017 è l'estensione dei controlli di sicurezza cloud a ISO 27001. Aggiunge controlli specifici per il cloud e chiarisce la ripartizione della responsabilità condivisa tra fornitore e cliente. Se lo scope del vostro ISMS include workload su hyperscaler (AWS, Azure, GCP, OVH), gli auditor chiederanno quali controlli 27017 avete mappato. ## Cosa aggiunge concretamente ISO/IEC 27017 ISO/IEC 27017 non è uno schema di certificazione a sé stante. È un codice di condotta che si colloca sopra ISO/IEC 27002, la guida all'implementazione dei controlli di ISO/IEC 27001. Dove 27002 descrive un controllo generico di sicurezza delle informazioni, 27017 aggiunge una guida all'implementazione specifica per il cloud per quello stesso controllo e, in alcuni punti, introduce controlli aggiuntivi che hanno senso solo nel momento in cui i tuoi dati risiedono su un'infrastruttura che non possiedi. Per questo, quando lo adotti, non stai gestendo un SGSI parallelo. Stai estendendo quello che già certifichi rispetto a ISO 27001 affinché parli il linguaggio del cloud. Il valore pratico è che obbliga entrambe le parti della relazione cloud a mettere le cose per iscritto. La norma è deliberatamente strutturata in modo che ogni elemento di guida abbia una versione per il fornitore di servizi cloud e una per il cliente di servizi cloud. Questa doppia impostazione è il punto centrale. Un controllo come la gestione degli accessi o il trattamento delle chiavi crittografiche significa qualcosa di diverso a seconda che tu sia l'hyperscaler che gestisce la piattaforma o il tenant che vi distribuisce i carichi di lavoro, e 27017 rende esplicita questa ripartizione invece di lasciarla all'ipotesi. ## Responsabilità condivisa, resa verificabile Ogni conversazione sulla sicurezza del cloud finisce prima o poi sulla responsabilità condivisa: il fornitore protegge l'infrastruttura, il cliente protegge ciò che vi colloca sopra. Il problema è che il confine si sposta a seconda del modello di servizio. Con l'infrastruttura come servizio il cliente è responsabile del sistema operativo, delle patch e della maggior parte della configurazione. Con il software come servizio quasi tutto ricade sul fornitore, e al cliente restano per lo più l'identità, gli accessi e la governance dei dati. ISO 27017 trasforma quel diagramma sfumato in qualcosa che un auditor può testare. - Chiede al fornitore di documentare quali responsabilità di sicurezza conserva e quali trasferisce al cliente, in modo che non vi sia alcuna lacuna silenziosa. - Chiede al cliente di confermare che comprende e che ha effettivamente implementato la propria parte, anziché presumere che il fornitore se ne occupi. - Aggiunge una guida specifica per gli ambienti multi-tenant, l'hardening delle macchine virtuali, le operazioni amministrative e la segregazione dei clienti che operano su hardware condiviso. - Affronta la rimozione e la restituzione degli asset al termine di un contratto, punto in cui molte uscite dal cloud falliscono. > **27017 è una guida, la certificazione passa per 27001** Non esiste un certificato ISO 27017 separato che regga da solo. In pratica un'organizzazione certifica il proprio SGSI rispetto a ISO/IEC 27001 includendo 27017 nel perimetro, e poi dimostra quali controlli cloud ha mappato. Gli auditor chiederanno quali controlli di 27017 si applicano ai tuoi carichi di lavoro presso gli hyperscaler e come hai implementato ciascun lato della ripartizione. ## Dove si colloca rispetto alle norme vicine 27017 si confonde facilmente con le norme che la circondano, perciò è utile tenere chiara la famiglia. ISO/IEC 27001 è il sistema di gestione certificabile. ISO/IEC 27002 è la guida generale dei controlli. ISO/IEC 27017 è l'estensione di quella guida alla sicurezza del cloud. ISO/IEC 27018 è la sorella che si concentra specificamente sulla protezione delle informazioni personali identificabili nel cloud pubblico, aspetto che conta quando i tuoi carichi di lavoro cloud trasportano anche dati personali e rispondi a obblighi di privacy oltre che di sicurezza. **ISO 27017 rispetto alle norme vicine** | Norma | Ruolo | Certificabile da sola | | --- | --- | --- | | ISO/IEC 27001 | Requisiti del sistema di gestione della sicurezza delle informazioni | Sì | | ISO/IEC 27002 | Guida generale all'implementazione dei controlli di sicurezza | No, guida | | ISO/IEC 27017 | Controlli di sicurezza specifici per il cloud e ripartizione fornitore/cliente | No, inclusa nel perimetro 27001 | | ISO/IEC 27018 | Protezione dei dati personali nel cloud pubblico | No, inclusa nel perimetro 27001 | Per un professionista il flusso di lavoro è coerente. Gestisci un SGSI ISO 27001, porti i carichi di lavoro cloud nel suo perimetro e usi 27017 per decidere quali controlli cloud mappare e come dimostrare entrambi i lati della linea di responsabilità. Se quei carichi di lavoro trattano anche dati personali, lo abbini a 27018. Nessuna di queste norme sostituisce la tua due diligence contrattuale sul fornitore; ti danno un modo strutturato per dimostrare di averla svolta. --- ## ISO/IEC 27018 (ISO 27018) **URL:** https://cyberacademy.net/it/resources/encyclopedia/iso-27018 **Last reviewed:** 2026-06-24 ISO 27018 è l'estensione dei controlli privacy di ISO 27001 per i cloud provider che agiscono come responsabili del trattamento di informazioni a carattere personale. Collega ISO 27001 agli obblighi del responsabile del trattamento previsti dal GDPR. Adottata principalmente dagli hyperscaler, viene utilizzata dai loro clienti come elemento di due diligence sui fornitori. ## Che cosa aggiunge la norma ISO/IEC 27018 rispetto a ISO 27001 ISO/IEC 27018 è un codice di condotta, non un sistema di gestione autonomo. Presuppone che tu gestisca già un sistema di gestione della sicurezza delle informazioni certificato secondo ISO/IEC 27001, e vi innesta sopra uno strato dedicato alla privacy. In particolare, si rivolge a un unico ruolo: un fornitore di servizi di cloud pubblico che agisce in qualità di responsabile del trattamento di informazioni di identificazione personale (PII) per conto dei propri clienti. La norma prende i controlli generici di ISO/IEC 27002 e li reinterpreta per quel contesto di responsabile del trattamento, poi aggiunge un insieme di controlli sulla privacy specifici per il cloud che ISO 27001 da sola non richiede. La conseguenza pratica è che ISO 27018 non si certifica da sola. Un fornitore è certificato ISO 27001 con ISO 27018 come insieme di controlli applicabile all'interno del perimetro. È per questo che la vedi espressa come «certificato ISO 27001, sottoposto ad audit rispetto a ISO 27018» anziché come un certificato a sé stante. I controlli riguardano aspetti che un cliente del cloud non può verificare facilmente da solo: se il fornitore utilizzerà le PII dei clienti per la propria pubblicità, se i sub-responsabili del trattamento vengono divulgati prima di essere coinvolti, come vengono gestiti i dati al termine di un contratto, e che cosa accade quando le autorità chiedono l'accesso ai dati. ## Dove si colloca tra ISO 27001, ISO 27017 e il GDPR Tre riferimenti vicini vengono confusi con ISO 27018, e le distinzioni contano quando si delimita un audit o si compila un questionario fornitore. ISO 27001 è il sistema di gestione che governa la sicurezza delle informazioni in generale. ISO 27017 è il codice di condotta per la sicurezza del cloud, più ampio della privacy e incentrato sulla sicurezza dei servizi cloud sia per il fornitore sia per il cliente. ISO 27018 è più ristretta di entrambe: è privacy, nel cloud pubblico, per il solo ruolo di responsabile del trattamento. **ISO 27018 a confronto con le norme vicine** | Riferimento | Perimetro | Che cosa disciplina | | --- | --- | --- | | ISO/IEC 27001 | Gestione della sicurezza delle informazioni | L'SGSI certificabile che le altre estendono | | ISO/IEC 27017 | Controlli di sicurezza del cloud | Sicurezza dei servizi cloud, fornitore e cliente | | ISO/IEC 27018 | Privacy nel cloud per i responsabili del trattamento | Protezione delle PII trattate da un responsabile del trattamento nel cloud | | GDPR | Diritto dell'UE in materia di protezione dei dati | Obblighi legali a carico di titolari e responsabili del trattamento | ISO 27018 è un ponte utile verso gli obblighi del responsabile del trattamento ai sensi del GDPR perché rende operative idee che il regolamento esprime in termini giuridici: limitazione delle finalità, trasparenza sul subappalto, assistenza al titolare del trattamento, e restituzione o cancellazione dei dati. Ma non ne è un sostituto. Un certificato rispetto a ISO 27018 è prova di buone pratiche del responsabile del trattamento, non un accertamento di conformità legale. Il GDPR ripartisce gli obblighi tramite norme vincolanti e contratti tra titolare e responsabile del trattamento; una norma non può farlo al posto tuo. > **È un elemento di due diligence sui fornitori, non una prova di conformità** ISO 27018 è detenuta soprattutto dai grandi hyperscaler ed è letta dai loro clienti come uno degli elementi della valutazione dei fornitori. Trattala come prova del fatto che un fornitore si è impegnato su pratiche di privacy specifiche, poi verifica nel contratto di trattamento effettivo gli impegni che contano per te. ## Che cosa ne fanno realmente i professionisti Per la maggior parte delle organizzazioni, ISO 27018 è qualcosa che si consuma più che qualcosa che si detiene. Quando selezioni un servizio cloud e la tua valutazione d'impatto sulla protezione dei dati o il tuo processo di rischio di terze parti pone la domanda «questo responsabile del trattamento è affidabile», l'audit ISO 27018 del fornitore è uno degli artefatti che raccogli, insieme alle dichiarazioni di perimetro ISO 27001, ai rapporti SOC e all'accordo sul trattamento. - Verifica che il certificato sia in corso di validità e che il servizio cloud che effettivamente utilizzi rientri nel perimetro sottoposto ad audit, e non solo nell'SGSI aziendale. - Leggila insieme a ISO 27001 e ISO 27017, poiché le tre sono progettate per essere stratificate, e un fornitore che le detiene tutte e tre ha coperto in modo più completo la sicurezza e la privacy nel cloud. - Mappa i controlli di ISO 27018 sui tuoi obblighi ai sensi del GDPR anziché presumere una sovrapposizione, perché la norma supporta il rapporto di responsabile del trattamento ma non libera il titolare del trattamento dai suoi doveri legali. - Mantieni il contratto di trattamento come documento vincolante. La norma segnala un'intenzione; l'accordo sul trattamento dei dati è ciò che fai rispettare. --- ## ISO/IEC 27034 (ISO 27034) **URL:** https://cyberacademy.net/it/resources/encyclopedia/iso-27034 **Last reviewed:** 2026-06-24 ISO 27034 è lo standard per la sicurezza delle applicazioni. Articolato in più parti. Copre l'intero ciclo di vita sicuro del software: requisiti, progettazione, sviluppo, test, distribuzione, manutenzione. Meno noto di ISO/IEC 27001 perché vive all'interno dell'SDLC, ma è l'unico standard ISO che parla la lingua dei team di sviluppo. Si abbina naturalmente alle pratiche OWASP e SBOM. ## Che cosa si propone di fare la norma ISO/IEC 27034 ISO/IEC 27034 è il membro dedicato alla sicurezza delle applicazioni della famiglia ISO/IEC 27000. Mentre ISO/IEC 27001 governa il sistema di gestione che guida l'intero programma di sicurezza delle informazioni, ISO/IEC 27034 restringe la prospettiva a una sola cosa: costruire e gestire applicazioni sicure lungo tutto il ciclo di vita del software, dai requisiti e dalla progettazione fino allo sviluppo, ai test, al rilascio e alla manutenzione. È una norma in più parti, il che significa che le indicazioni sono distribuite su diversi documenti anziché concentrate in un'unica specifica certificabile, e questa forma dice qualcosa sul suo intento. È pensata per orientare il modo in cui lo sviluppo viene condotto, non per consegnare a un auditor una lista di controllo da spuntare. Il motivo per cui resta sullo sfondo mentre ISO/IEC 27001 cattura l'attenzione è strutturale. La maggior parte di un'organizzazione parla di politiche, registri dei rischi e certificati; ISO/IEC 27034 parla alle persone che scrivono e rilasciano il codice. Vive all'interno del ciclo di vita di sviluppo del software (SDLC), quindi il suo pubblico è composto da sviluppatori, architetti e ingegneri della sicurezza applicativa piuttosto che dal team di conformità. Questo la rende la norma ISO più fluente nel linguaggio dei team di sviluppo, e quella con più probabilità di allinearsi in modo pulito al modo in cui un'organizzazione di ingegneria funziona realmente giorno per giorno. ## L'idea del controllo di sicurezza applicativa Il concetto portante in ISO/IEC 27034 è trattare la sicurezza delle applicazioni come un insieme di controlli verificabili intessuti nel ciclo di vita, anziché come una revisione di sicurezza aggiunta alla fine. La norma inquadra i requisiti di sicurezza come qualcosa che si deriva dal contesto dell'applicazione, dai dati che gestisce e dalle minacce che affronta, e che poi si porta avanti attraverso la progettazione, l'implementazione e la verifica, in modo che ogni controllo abbia un punto definito in cui viene integrato e un punto definito in cui viene verificato. L'effetto pratico è che la sicurezza smette di essere una barriera al rilascio e diventa una proprietà mantenuta in ogni fase, che è esattamente lo spostamento che la pratica moderna dello sviluppo sicuro spinge avanti da anni. Poiché la norma è orientata ai processi e modellata sul ciclo di vita, si colloca comodamente accanto al materiale prescrittivo e pratico che i team già utilizzano. Non sostituisce l'OWASP Application Security Verification Standard né l'OWASP Top 10; offre loro un quadro di governance a cui agganciarsi. Si abbina anche naturalmente alla pratica del software bill of materials (SBOM), dove sapere esattamente quali componenti vengono rilasciati in un'applicazione è il controllo della fase di manutenzione che mantiene onesto il ciclo di vita dopo il rilascio. Usate insieme, ISO/IEC 27034 fornisce la struttura, mentre OWASP e il SBOM forniscono le tecniche concrete e gli inventari. > **Un quadro, non una lista di controllo** ISO/IEC 27034 è più utile come la struttura del ciclo di vita che organizza lo sviluppo sicuro. Ricorrete a OWASP ASVS, all'OWASP Top 10 e agli strumenti SBOM per i test e gli inventari concreti, e lasciate che ISO/IEC 27034 definisca in quale punto del ciclo di vita ciascuno appartiene. ## Dove si colloca accanto a ISO/IEC 27001 Il modo più pulito di posizionare ISO/IEC 27034 è come il dettaglio del livello applicativo sotto un sistema di gestione ISO/IEC 27001. ISO/IEC 27001 certifica che gestite un sistema di gestione della sicurezza delle informazioni con valutazione del rischio e miglioramento continuo, e il suo insieme di controlli include aspettative di sviluppo sicuro enunciate a un livello elevato. ISO/IEC 27034 è dove si va per implementare effettivamente quelle aspettative nell'ingegneria: come si catturano i requisiti sicuri, come si verificano i controlli, come la sicurezza viaggia attraverso il SDLC. Un team certificato ISO/IEC 27001 può usare ISO/IEC 27034 per dare sostanza ai propri controlli di sviluppo sicuro, e un'organizzazione di sviluppo può usare ISO/IEC 27034 per assicurarsi che il codice che rilascia regga a quel sistema di gestione più ampio. Nella pratica, le organizzazioni si certificano raramente rispetto a ISO/IEC 27034 come si certificano rispetto a ISO/IEC 27001. La adottano come guida, trasferiscono la struttura del ciclo di vita nel proprio standard di sviluppo sicuro e la richiamano quando hanno bisogno di una base autorevole per giustificare il modo in cui viene gestita la sicurezza applicativa. Per un piccolo team, il valore è lo stesso che per una grande impresa: un modo riconosciuto e indipendente dal fornitore di descrivere un SDLC sicuro che auditor, clienti e sviluppatori accettano tutti. --- ## ISO/IEC 27037 (ISO 27037) **URL:** https://cyberacademy.net/it/resources/encyclopedia/iso-27037 **Last reviewed:** 2026-06-24 ISO 27037 è lo standard per la digital forensics relativo all'identificazione, raccolta, acquisizione e conservazione delle prove digitali. È il riferimento che un team forense interno, un CERT o un consulente di litigation support utilizza per mantenere integra la catena di custodia. Va trattato come il manuale operativo con cui auditor e legali confronteranno le azioni intraprese dopo un incidente. ## Che cosa disciplina la ISO/IEC 27037 La ISO/IEC 27037 è la linea guida internazionale per la prima fase, la più fragile, di ogni indagine digitale: impossessarsi della prova senza distruggerla. Si colloca all'interno della più ampia famiglia ISO/IEC 27000, accanto alla ISO/IEC 27001, ma mentre la 27001 indica come gestire un sistema di gestione, la 27037 indica ai vostri intervenenti esattamente come trattare un server in funzione, un portatile sequestrato, un telefono o un account cloud affinché ciò che viene acquisito possa in seguito resistere all'esame. Copre quattro attività in sequenza: identificare la potenziale prova digitale, raccogliere i dispositivi fisici, acquisirne i dati e preservare sia i dispositivi sia le copie fino alla consegna. La norma introduce due ruoli a cui i professionisti tornano di continuo. Il Digital Evidence First Responder (DEFR) è la persona presente sulla scena che decide cosa sequestrare e come. Il Digital Evidence Specialist (DES) possiede la competenza tecnica più approfondita per trattare i casi delicati, come i sistemi attivi, i volumi cifrati o l'hardware inusuale. Da entrambi ci si attende che documentino ogni decisione, perché il valore della prova digitale poggia meno sui byte in sé e più sulla capacità di dimostrare che non sono stati alterati. ## La catena di custodia e i principi che la sorreggono La 27037 poggia su una manciata di principi che ricompaiono in ogni metodo forense credibile. La prova acquisita deve essere pertinente, affidabile e sufficiente. Le azioni compiute sull'originale devono essere mantenute al minimo necessario e pienamente giustificate. Chiunque sia competente deve poter ripetere il processo e giungere allo stesso risultato, ed è per questo che gli strumenti di imaging, i blocchi in scrittura e gli hash di verifica contano così tanto. Il filo che lega il tutto è la catena di custodia: una registrazione continua e documentata di chi ha detenuto la prova, di che cosa ne ha fatto e quando, dal momento della raccolta fino alla sua presentazione. - Identificazione: riconoscere ciò che potrebbe costituire una prova, dai dischi e telefoni fino alla memoria volatile e alle catture di rete. - Raccolta: rimuovere i dispositivi dalla scena, con l'ordine di volatilità che decide cosa acquisire per primo. - Acquisizione: produrre una copia verificabile, di norma un'immagine forense validata da un hash crittografico. - Preservazione: proteggere l'originale e le copie da alterazioni, perdite o contaminazioni. > **Una linea guida, non una certificazione** Non si certifica un'organizzazione rispetto alla ISO/IEC 27037 come si fa rispetto alla ISO/IEC 27001. È un metodo che il vostro team forense, il vostro CERT o il vostro consulente di supporto al contenzioso segue, ed è il riferimento rispetto al quale auditor e avvocati misureranno il vostro trattamento dopo un incidente. Norme correlate la estendono: la ISO/IEC 27041 sull'assurance, la 27042 sull'analisi e l'interpretazione e la 27043 sull'intero processo investigativo. ## Dove si colloca nella risposta agli incidenti e nella famiglia più ampia In pratica la 27037 è il ponte tra il rilevamento di un incidente e la capacità di fare qualcosa di utile con gli artefatti in seguito. Un SOC interno che acquisisce un'immagine del disco nel modo sbagliato, o che cancella la memoria volatile riavviando un host compromesso, può rilevare perfettamente un attaccante e ritrovarsi comunque con una prova su cui nessun tribunale o autorità di regolamentazione farà affidamento. Ecco perché la si legge insieme agli orientamenti sulla gestione degli incidenti della ISO/IEC 27035 e ai controlli dell'Annex A della ISO/IEC 27001. La disciplina è la stessa, sia che l'obiettivo sia un'azione penale, una controversia di lavoro, una richiesta di indennizzo assicurativo o semplicemente un rapporto interno che regga alla contestazione. Per i professionisti l'insegnamento è procedurale, non teorico. Decidete in anticipo chi sono i vostri DEFR e DES, dotateli di strumenti validati, redigete il modulo di catena di custodia prima di averne bisogno e provate l'ordine di volatilità affinché nessuno riavvii l'unica macchina che contava. Quando un'indagine va male, non è quasi mai l'analisi a fallire. È la prima ora, esattamente l'ora di cui parla la 27037. --- ## ISO/IEC 27701 (ISO 27701) **URL:** https://cyberacademy.net/it/resources/encyclopedia/iso-27701 **Last reviewed:** 2026-06-24 ISO 27701 è l'estensione per la gestione delle informazioni sulla privacy di ISO 27001. Aggiunge gli obblighi del titolare e del responsabile del trattamento al di sopra dell'ISMS. Utile per le organizzazioni che desiderano un unico sistema di gestione certificabile che copra sia la sicurezza sia la privacy. Si ricollega al GDPR, ma non "sostituisce" il lavoro di conformità al GDPR. ## Un'estensione, non una norma autonoma ISO/IEC 27701 non si regge da sola. È concepita come un'estensione di ISO/IEC 27001 e ISO/IEC 27002, il che significa che non è possibile certificarsi rispetto a essa senza disporre prima di un sistema di gestione della sicurezza delle informazioni (SGSI) operativo. La norma prende i controlli di sicurezza che già gestite e vi sovrappone requisiti e linee guida specifici per la privacy, trasformando il SGSI in un Sistema di Gestione delle Informazioni sulla Privacy (PIMS). Per un'organizzazione che già opera ISO 27001, si tratta di una mossa efficiente: riutilizzate lo stesso governo, la stessa metodologia di rischio, lo stesso ciclo di audit, ed estendete il perimetro per coprire il trattamento dei dati personali identificativi (PII). Questa scelta architetturale è il punto centrale. Anziché gestire la privacy come un programma separato con i propri comitati e le proprie evidenze, ISO 27701 vi consente di certificare un unico sistema di gestione che copre sia la sicurezza sia la privacy. La Dichiarazione di Applicabilità viene ampliata, la valutazione del rischio considera ora il rischio per la privacy delle persone e non solo il rischio per l'organizzazione, e lo stesso organismo di certificazione verifica il tutto in un unico incarico. ## Obblighi del titolare e del responsabile del trattamento ISO 27701 ripartisce i suoi requisiti aggiuntivi lungo la stessa linea tracciata dalla normativa sulla protezione dei dati: tra l'organizzazione che agisce come titolare del trattamento (decidendo perché e come i PII vengono trattati) e l'organizzazione che agisce come responsabile del trattamento (trattando PII per conto di altri). Molte organizzazioni sono entrambe contemporaneamente, a seconda del set di dati, perciò la norma vi fornisce due insiemi di linee guida e vi chiede di applicare quello che si adatta a ciascuna attività di trattamento. - I temi dal lato del titolare del trattamento includono la base giuridica e la finalità, il consenso e la scelta, la trasparenza verso le persone, la gestione delle richieste degli interessati, i registri dei trattamenti, e gli obblighi quando condividete PII con terze parti. - I temi dal lato del responsabile del trattamento includono l'agire solo su istruzioni documentate, l'assistere il titolare nei suoi obblighi, la gestione dei sub-responsabili, e la restituzione o cancellazione dei PII al termine di un contratto. In pratica è ciò che un team privacy già fa nell'ambito dei regimi moderni di protezione dei dati, ma ISO 27701 lo organizza in controlli verificabili con evidenze documentate, che è esattamente ciò che trasforma una postura privacy in qualcosa che una terza parte può verificare. ## Dove si colloca accanto al GDPR L'errata interpretazione più comune è che la certificazione ISO 27701 vi renda conformi al GDPR. Non è così, e la norma sta attenta a non affermarlo. Il GDPR è legge e ISO 27701 è una norma di sistema di gestione volontaria. Ciò che 27701 vi offre è un quadro strutturato e certificabile i cui controlli si allineano strettamente ai principi di protezione dei dati, dunque costituisce una prova solida di responsabilizzazione (accountability) e una buona struttura portante operativa. Ma la conformità a uno specifico regime giuridico richiede comunque la vostra analisi legale, i vostri registri, e la vostra gestione dimostrabile dei diritti individuali ai sensi di tale legge. > **Un certificato è una prova, non una difesa** Un certificato ISO 27701 dimostra che un auditor ha verificato il vostro PIMS rispetto alla norma. Le autorità di regolamentazione possono trattarlo come un segnale credibile di responsabilizzazione, ma non sostituisce l'adempimento degli obblighi effettivi del GDPR o di qualsiasi altra legge sulla privacy applicabile. Consideratelo come lo strato di gestione che rende ripetibile la conformità legale, non come la conformità stessa. **ISO 27701 accanto al GDPR** | Dimensione | ISO/IEC 27701 | GDPR | | --- | --- | --- | | Natura | Norma di sistema di gestione volontaria | Legge vincolante dell'UE | | Cosa produce | Un PIMS certificabile | Obblighi legali e diritti individuali | | Costruita su | ISO 27001 / ISO 27002 | Principi di protezione dei dati | | Verificata da | Organismo di certificazione accreditato | Autorità di controllo e tribunali | | Relazione | Si allinea alla conformità e la supporta | L'obbligo che 27701 vi aiuta a soddisfare | Il modo pulito di gestirla consiste nell'ancorare la privacy allo stesso SGSI che usate per la sicurezza, certificare il sistema combinato a ISO 27001 più ISO 27701, e mantenere il vostro responsabile della protezione dei dati e il team legale titolari della legge stessa. La norma gestisce la disciplina operativa; loro gestiscono l'interpretazione. --- ## ISO/IEC 42001 (ISO 42001) **URL:** https://cyberacademy.net/it/resources/encyclopedia/iso-42001 **Last reviewed:** 2026-06-24 ISO 42001 è il primo standard internazionale per i sistemi di gestione dell'intelligenza artificiale, pubblicato a fine 2023. L'equivalente AIMS di ciò che ISO 27001 rappresenta per l'ISMS. Pensato per le organizzazioni che devono governare la progettazione, il deployment e l'operatività dell'AI: rischio, accountability, trasparenza, miglioramento continuo. Si allinea in modo diretto agli obblighi dell'AI Act per i sistemi ad alto rischio. ## Che cosa disciplina realmente la norma ISO/IEC 42001 ISO/IEC 42001 è la prima norma di sistema di gestione certificabile dedicata all'intelligenza artificiale. Non indica quale modello addestrare né come mettere a punto una rete neurale. Definisce invece un sistema di gestione dell'IA (AIMS): le politiche, i ruoli, i processi e i controlli che un'organizzazione predispone per sviluppare, fornire o utilizzare l'IA in modo responsabile. Se già conosci ISO 27001, il modello mentale si trasferisce direttamente. Laddove l'SGSI protegge le informazioni, l'AIMS governa il ciclo di vita dei sistemi di IA, dalla finalità prevista e dall'approvvigionamento dei dati fino alla messa in esercizio, al monitoraggio e alla dismissione. La norma segue la stessa struttura di alto livello (High-Level Structure) di ISO 27001 e ISO 9001: contesto dell'organizzazione, leadership, pianificazione, supporto, attività operative, valutazione delle prestazioni e miglioramento. Questa ossatura condivisa è deliberata. Consente di innestare l'AIMS su un sistema di gestione integrato esistente anziché gestire un silo di governance parallelo. La sostanza specifica dell'IA risiede negli allegati, che definiscono controlli di riferimento e linee guida di attuazione su temi quali la responsabilità, la qualità dei dati, la trasparenza verso gli utenti, la sorveglianza umana e la valutazione d'impatto. ## In che cosa differisce da ISO 27001 e da una politica di rischio generica I professionisti provenienti dalla sicurezza spesso presumono che un SGSI copra già l'IA. Non è così. ISO 27001 è costruita attorno a riservatezza, integrità e disponibilità delle informazioni. ISO 42001 aggiunge preoccupazioni che non trovano una collocazione naturale in un framework di sicurezza: se un sistema si comporta in modo equo, se i suoi output sono spiegabili, se un essere umano può intervenire in modo significativo e se l'IA è utilizzata solo per la finalità dichiarata. Anche il ragionamento sul rischio è più ampio. Una valutazione del rischio secondo 42001 pondera gli impatti sulle persone e sulla società, non soltanto sull'organizzazione, ed è per questo che una valutazione d'impatto dell'IA costituisce un'attività distinta e denominata all'interno della norma. > **AIMS e SGSI sono complementari, non ridondanti** Le organizzazioni che possiedono ISO 27001 in genere estendono la governance esistente anziché ricostruirla. I controlli di riferimento dell'Allegato A di ISO 42001 si collocano accanto ai controlli di sicurezza, non al loro interno, e le due certificazioni possono condividere audit, impegno della direzione e cicli di miglioramento. ## Perché è importante per il Regolamento europeo sull'IA (EU AI Act) ISO 42001 si allinea con precisione alle aspettative dell'AI Act per i sistemi ad alto rischio. Il regolamento impone ai fornitori di IA ad alto rischio di gestire un sistema di gestione dei rischi, mantenere una governance dei dati, conservare la documentazione tecnica, garantire la sorveglianza umana e condurre un monitoraggio successivo all'immissione sul mercato. Sono esattamente le discipline che un AIMS istituzionalizza. Un sistema di gestione certificato non sostituisce la conformità giuridica e la certificazione di per sé non rende conforme un sistema. Ciò che offre è una struttura verificabile e ripetibile che dimostra la dovuta diligenza e fa del rispetto degli obblighi dell'AI Act una questione di gestione di un sistema esistente anziché di improvvisazione sotto la pressione delle scadenze. ## Come si presenta l'attuazione nella pratica I team che adottano 42001 percorrono in genere una sequenza riconoscibile: 1. Definire il campo di applicazione: quali sistemi di IA, usati da chi, per quale finalità prevista e dove si colloca l'organizzazione nella catena di fornitura (sviluppatore, fornitore, deployer). 1. Condurre la valutazione del rischio dell'IA e la valutazione d'impatto, individuando i rischi per le persone e l'organizzazione e selezionando i controlli per trattarli. 1. Assegnare una chiara responsabilità affinché un titolare designato risponda di ciascun sistema di IA lungo tutto il suo ciclo di vita. 1. Stabilire una governance dei dati, meccanismi di trasparenza e una sorveglianza umana adeguati al livello di rischio. 1. Monitorare i sistemi in esercizio, raccogliere incidenti e riscontri e reimmetterli nel miglioramento continuo. La certificazione è facoltativa ma sempre più richiesta da acquirenti enterprise e team di approvvigionamento che desiderano una garanzia di terza parte sul fatto che un fornitore di IA governi i propri sistemi anziché consegnarli alla cieca. --- ## Identity and Access Management (IAM) **URL:** https://cyberacademy.net/it/resources/encyclopedia/iam **Last reviewed:** 2026-06-24 IAM è la disciplina che gestisce chi può accedere a cosa, quando, come e in quali condizioni. Provisioning, autenticazione, autorizzazione, deprovisioning. L'identità è il nuovo perimetro. Ogni architettura Zero Trust è, nella sostanza, un problema di IAM complesso mascherato da problema di rete. ## Cosa copre davvero l'IAM L'Identity and Access Management è la disciplina operativa che decide chi può accedere a cosa, quando, come e a quali condizioni. In pratica si costruisce a partire da un piccolo insieme di funzioni ripetibili: effettuare il provisioning di un'identità quando arriva una persona o un servizio, autenticare quell'identità nel momento dell'accesso, autorizzare le azioni e le risorse specifiche consentite, e deprovisionare l'identità quando il ruolo o la relazione termina. La parte difficile raramente è una singola schermata di login. Consiste nel mantenere onesto nel tempo il legame tra una persona reale, le sue identità digitali e i suoi diritti accumulati, attraverso decine di sistemi che hanno ciascuno una propria idea di cosa sia un account. Un modello mentale utile è il ciclo di vita dell'identità. Chi entra riceve account e un accesso di base. Chi cambia ruolo passa da un team all'altro e dovrebbe perdere i vecchi diritti man mano che ne acquisisce di nuovi. Chi esce deve essere disconnesso in modo netto. La maggior parte degli incidenti di accesso risale a un guasto in questo ciclo di vita: account orfani mai disabilitati, oppure privilegi accumulati perché l'accesso è stato concesso ma mai riesaminato. L'IAM è il sistema che rende affidabile il processo di ingresso, spostamento e uscita invece di un affannarsi manuale. ## L'identità come perimetro L'IAM conta di più oggi perché il confine di rete ha smesso di essere un controllo significativo. Gli utenti si connettono da ovunque, i carichi di lavoro vengono eseguiti su più provider cloud, e le identità macchina (account di servizio, chiavi API, token di carico di lavoro) spesso superano per numero quelle umane. Quando non c'è più un interno e un esterno da difendere, l'identità diventa la linea che decide l'accesso. È questa l'intuizione centrale alla base dello Zero Trust: non fidarsi mai per impostazione predefinita, verificare ogni richiesta rispetto a identità, postura del dispositivo e contesto. Un'architettura Zero Trust è, in fondo, un esigente problema di IAM travestito da problema di rete. L'IAM è anche il punto in cui si innestano diversi controlli adiacenti. L'autenticazione a più fattori rafforza la fase di autenticazione. La gestione degli accessi privilegiati protegge il piccolo numero di identità capaci di causare il danno maggiore. Il principio del privilegio minimo è la politica che l'IAM applica: concedere solo l'accesso di cui un ruolo ha davvero bisogno, e niente di più. Considerali come strati di uno stesso problema anziché come progetti separati. > **Il riesame degli accessi non è facoltativo** Concedere un accesso è facile e riesaminarlo è noioso, perciò i diritti tendono a salire nel tempo. La certificazione periodica degli accessi, in cui i responsabili riconfermano chi deve mantenere cosa, è il controllo che intercetta l'accumulo di privilegi prima che lo faccia un auditor o un attaccante. ## Contesto di governance e standard L'IAM si colloca al centro della maggior parte dei framework di sicurezza perché il controllo degli accessi è fondamentale. ISO/IEC 27001 tratta il controllo degli accessi e la gestione delle identità come aree di controllo centrali di un sistema di gestione della sicurezza delle informazioni, aspettandosi che le organizzazioni definiscano una politica di controllo degli accessi, gestiscano l'accesso degli utenti lungo l'intero ciclo di vita e riesaminino i diritti di accesso. Il NIST Cybersecurity Framework colloca la gestione delle identità e il controllo degli accessi tra le funzioni di protezione che ogni programma dovrebbe coprire. Per i dati regolamentati, la disciplina degli accessi sostiene anche gli obblighi di riservatezza ai sensi del GDPR, poiché limitare chi può raggiungere i dati personali fa parte della dimostrazione di misure tecniche adeguate. Ciò che i professionisti fanno realmente lo riflette. Costruiscono fonti di identità autorevoli, automatizzano il provisioning e il deprovisioning, centralizzano l'autenticazione tramite il single sign-on, modellano i diritti come ruoli ove possibile, eseguono riesami degli accessi ricorrenti e mantengono una pista di controllo su chi ha ricevuto cosa e perché. Fatta bene, l'IAM è invisibile agli utenti e dimostrabile agli auditor. Fatta male, è la causa profonda silenziosa dietro una larga parte delle violazioni. --- ## Information Security Management System (ISMS) **URL:** https://cyberacademy.net/it/resources/encyclopedia/isms **Last reviewed:** 2026-06-24 Un ISMS è il sistema documentato che si gestisce per proteire gli asset informativi: basato sul rischio, supportato da evidenze, sottoposto a riesame della direzione. Non è un raccoglitore di policy. Gli auditor non valutano le policy; valutano le evidenze operative. Ciclo Plan-Do-Check-Act, certificato secondo ISO 27001, con il SoA come artefatto centrale. ## Che cos'è realmente un SGSI Un sistema di gestione della sicurezza delle informazioni è il sistema operativo che mette in funzione per proteggere gli asset informativi in modo deliberato e ripetibile. La parola che conta di più è «sistema». Non sono gli strumenti di sicurezza, e non è una cartella di politiche approvate posata su un'unità condivisa. È l'insieme di processi, ruoli, decisioni e registrazioni attraverso cui un'organizzazione identifica quali informazioni deve proteggere, decide quanto rischio è disposta ad accettare, sceglie i controlli per trattare quel rischio e poi dimostra che quei controlli funzionano davvero nel tempo. Una politica dice ciò che dovrebbe accadere. Un SGSI è il meccanismo che lo fa accadere e che genera la prova che è accaduto. Le sue caratteristiche distintive sono che è basato sul rischio e supportato da evidenze, e che opera sotto riesame della direzione. Basato sul rischio significa che i controlli non sono scelti da una lista dei desideri ma giustificati da una valutazione documentata delle minacce a specifici asset. Supportato da evidenze significa che ogni controllo ha degli artefatti alle spalle: riesami degli accessi che sono stati eseguiti, log che sono stati monitorati, incidenti che sono stati gestiti, formazione che è stata erogata. Il riesame della direzione significa che la dirigenza è proprietaria del sistema, ne fissa gli obiettivi e verifica periodicamente se vengono raggiunti. Togliete uno qualunque di questi tre elementi e avrete un programma di sicurezza, non un sistema di gestione. ## Perché gli auditor valutano le evidenze, non le politiche Un fraintendimento comune e costoso è credere che la certificazione riguardi l'avere una buona documentazione. Non è così. Un auditor di certificazione presume che lei sappia scrivere una politica di controllo degli accessi competente. Ciò che è lì a verificare è se la sua realtà operativa corrisponde a quanto affermano i suoi documenti. Chiederà di vedere l'ultimo riesame degli accessi e verificherà che sia stato effettivamente completato, campionerà i ticket per confermare che le modifiche siano state autorizzate, e tracerà un incidente dalla rilevazione fino alle lezioni apprese. Politiche belle senza alcuna evidenza operativa alle spalle non superano gli audit. È per questo che i professionisti descrivono il SGSI come qualcosa che si mette in funzione, non qualcosa che si scrive. > **La SoA è l'artefatto centrale** La dichiarazione di applicabilità è il punto in cui il SGSI diventa verificabile. Elenca ogni controllo di riferimento, indica se si applica e giustifica ogni inclusione o esclusione rispetto ai risultati della valutazione del rischio. Un auditor legge per prima la SoA perché è la mappa tra i suoi rischi e i suoi controlli, e poi va a cercare la prova che ogni controllo applicabile stia operando davvero. ## Plan-Do-Check-Act: come il sistema resta vivo Un SGSI è costruito per migliorare di continuo anziché essere perfezionato una volta sola. La maggior parte delle implementazioni segue il ciclo Plan-Do-Check-Act, che mantiene onesto il sistema: 1. Plan: stabilire il campo di applicazione, valutare i rischi, fissare gli obiettivi di sicurezza e selezionare i controlli per trattare i rischi che ha individuato. 1. Do: attuare e gestire quei controlli e i processi di supporto nel quotidiano. 1. Check: monitorare, misurare, condurre audit interni ed eseguire riesami della direzione per vedere se i controlli funzionano e se gli obiettivi vengono raggiunti. 1. Act: correggere ciò che non funziona, affrontare le cause profonde delle non conformità e reimmettere i miglioramenti nel ciclo successivo. Quel ciclo è ciò che distingue un SGSI vivo da uno sforzo di conformità una tantum. Un registro dei rischi riesaminato una volta all'anno e poi mai più toccato non è un SGSI in alcun senso significativo, anche se a un certo punto ha prodotto un certificato. ## Dove si colloca tra i concetti vicini Il SGSI è il quadro di riferimento, certificato secondo la ISO/IEC 27001, la norma internazionale che specifica i requisiti che un sistema di gestione deve soddisfare. La ISO/IEC 27001 è la norma dei requisiti certificabile; guide di accompagnamento come la ISO/IEC 27005 supportano il lavoro di valutazione e trattamento del rischio che la alimenta. Spesso si confonde il SGSI con i controlli al suo interno, ma i controlli sono input che il sistema seleziona e gestisce. Non sono il sistema. La disciplina del SGSI sta proprio nel fatto che riconduce ogni controllo a un rischio e ogni rischio a una decisione documentata presa da persone che ne sono responsabili. --- ## Information Systems Audit and Control Association (ISACA) **URL:** https://cyberacademy.net/it/resources/encyclopedia/isaca **Last reviewed:** 2026-06-24 ISACA è l'associazione globale per i professionisti di audit IT, sicurezza, rischio e governance. Fondata nel 1969, con sede a Schaumburg, IL, conta oltre 165.000 membri in 188 paesi. Rilascia le certificazioni CISA, CISM, CRISC, CGEIT, CDPSE, AAIA, CCOA. Pubblica COBIT. Cyber Academy è un ISACA Accredited Premium Partner. ## Cos'è realmente ISACA ISACA nasce nel 1969 come Information Systems Audit and Control Association, un gruppo di auditor IT che avevano bisogno di un corpus di conoscenze comune e di un modo per certificare reciprocamente le proprie competenze. Il nome completo è oggi in gran parte storico; l'organizzazione opera come ISACA e si rivolge ai professionisti dell'audit IT, della sicurezza, del rischio, della governance e della privacy in oltre 180 paesi. Ciò che conta in pratica è che ISACA non è né un regolatore né un organismo di normazione nel senso dell'ISO. Non scrive leggi e non può certificare un'azienda. Certifica le persone e pubblica framework su cui si appoggia il resto della professione. Questa distinzione disorienta i nuovi arrivati. Non si può diventare un'azienda «certificata ISACA» nello stesso modo in cui si certifica un sistema di gestione ISO 27001. Le credenziali ISACA si fondano sugli individui. Un auditor consegue la CISA, un responsabile della sicurezza consegue la CISM, un professionista del rischio consegue la CRISC. Il valore della credenziale deriva dal rigore dell'esame, dal requisito documentato di esperienza lavorativa, dal codice etico professionale e dalla formazione professionale continua che la mantiene valida. I datori di lavoro e i comitati di audit le considerano la prova che la persona è stata valutata in modo indipendente rispetto a una pratica definita. ## La famiglia delle credenziali e ciò che ciascuna segnala Le certificazioni di ISACA sono deliberatamente legate a un ruolo specifico anziché a un'unica qualifica generale. Ognuna corrisponde a una distinta funzione lavorativa, motivo per cui i professionisti ne possiedono spesso più di una man mano che la loro carriera passa dall'esecuzione del lavoro alla sua governance. **Certificazioni ISACA per ruolo professionale** | Credenziale | Destinatari | Ambito | | --- | --- | --- | | CISA | Auditor SI | Audit, controllo e assurance dei sistemi informativi | | CISM | Responsabili della sicurezza | Governance e gestione di un programma di sicurezza delle informazioni | | CRISC | Professionisti del rischio | Identificazione e risposta al rischio IT e d'impresa | | CGEIT | Responsabili della governance | Governance dell'IT aziendale a livello di consiglio di amministrazione | | CDPSE | Ingegneri della privacy | Privacy by design nello stack tecnologico | | AAIA | Auditor di IA | Audit dei sistemi e dei controlli di intelligenza artificiale | | CCOA | Operazioni cyber | Operazioni e difesa pratiche di cybersicurezza | > **ISACA certifica le persone, ISO certifica i sistemi** Quando si dice che un'azienda è «accreditata ISACA», di solito si intende che il suo personale possiede credenziali ISACA o che è un partner di formazione ISACA riconosciuto. Un'azienda in sé non è certificata rispetto a uno standard ISACA. È proprio a questo che servono ISO 27001 e standard certificabili simili. ## COBIT e il posto di ISACA nel panorama degli standard Oltre a certificare gli individui, ISACA pubblica COBIT, il framework per la governance e la gestione dell'IT aziendale. COBIT è il punto in cui ISACA più si avvicina ad agire come un organismo di normazione, ma resta un framework che si adotta e si adatta anziché uno standard rispetto al quale ci si certifica. Gli auditor ricorrono a COBIT quando uno standard di sicurezza delle informazioni da solo è troppo ristretto, perché copre il modo in cui l'IT nel suo complesso è orientata verso gli obiettivi aziendali. Per questo ISACA, NIST e ISO vengono di solito menzionati insieme: NIST fornisce cataloghi di controlli ed esiti, ISO fornisce standard di gestione certificabili e ISACA fornisce la lente dell'audit e della governance oltre alle persone qualificate per applicarla. Per un'organizzazione di formazione, il programma partner di ISACA conta perché la preparazione all'esame deve seguire un programma accreditato per avere valore. Cyber Academy è un ISACA Accredited Premium Partner, ossia il riconoscimento che ISACA concede ai fornitori di formazione che soddisfano il suo livello qualitativo per erogare la preparazione ufficiale alle credenziali. Tale accreditamento riguarda il fornitore, non sostituisce il fatto che l'individuo superi l'esame ISACA e soddisfi il requisito di esperienza. --- ## Lead Auditor **URL:** https://cyberacademy.net/it/resources/encyclopedia/lead-auditor **Last reviewed:** 2026-06-24 Lead Auditor è la credenziale PECB per i professionisti in grado di pianificare e condurre audit di terza parte o interni di un sistema di gestione. Corso di cinque giorni basato su ISO 19011. Punto di ingresso per diventare auditor presso un organismo di certificazione accreditato. Impostazione diversa rispetto al Lead Implementer: prove, campionamento, reporting, tecnica di intervista. ## Cosa certifica la qualifica di Lead Auditor Lead Auditor è la certificazione PECB per i professionisti in grado di pianificare, condurre e rendicontare l'audit di un sistema di gestione, che si tratti di un audit di certificazione di terza parte, di un audit fornitori o di un audit interno di rilievo. Il corso si svolge in cinque giorni e si fonda direttamente su ISO 19011, la norma guida per l'audit dei sistemi di gestione. Ciò che certificate al termine non è di comprendere una norma come ISO 27001 in astratto, ma di saper guidare un gruppo di audit nei suoi confronti: definire il perimetro dell'incarico, campionare le evidenze, condurre le interviste, formulare rilievi che reggono alla contestazione e portare l'audit a una conclusione difendibile. La qualifica esiste per una precisa ragione di carriera. È il punto di accesso riconosciuto per diventare auditor accreditato di un organismo di certificazione, la persona che interviene per conto di un organismo di certificazione per decidere se un'organizzazione ottiene o mantiene il proprio certificato. Gli organismi di certificazione operano secondo ISO/IEC 17021-1 e hanno bisogno di auditor che abbiano dimostrato la competenza descritta da ISO 19011. Lead Auditor è il modo per segnalare che possedete tale competenza e le capacità di leadership per guidare il gruppo, non soltanto per parteciparvi. ## Una mentalità diversa da quella del Lead Implementer La confusione più comune è trattare Lead Auditor e Lead Implementer come due varianti della stessa qualifica. Sono posizioni opposte. L'implementatore costruisce il sistema di gestione: redige le politiche, progetta i controlli, conduce la valutazione del rischio e prepara l'organizzazione alla certificazione. L'auditor giudica in modo indipendente se ciò che è stato costruito esiste davvero e funziona. La stessa persona non dovrebbe fare entrambe le cose sullo stesso sistema, perché l'implementatore non può garantire in modo credibile il proprio lavoro. Quell'indipendenza è l'intera ragione per cui esiste il ruolo dell'auditor. In pratica la mentalità dell'auditor riguarda l'evidenza, non il consiglio. Dove l'implementatore si chiede come rendere efficace un controllo, l'auditor si chiede quale prova dimostri che il controllo opera come descritto, quanto sia rappresentativo il campione e se il rilievo regge se l'auditato lo contesta. Il corso Lead Auditor dedica la maggior parte della sua energia a queste competenze anziché alla norma stessa: - Campionamento: scegliere evidenze che rappresentino equamente l'insieme, e non le parti che per caso appaiono favorevoli. - Tecnica di intervista: far emergere come il lavoro viene realmente svolto senza condizionare il testimone. - Rilievi e rendicontazione: classificare le non conformità, redigerle in modo oggettivo e tracciabile, e giungere a una conclusione. - Leadership dell'audit: gestire un gruppo di audit, le riunioni di apertura e di chiusura, e il rapporto con l'auditato. > **L'etichetta della norma viaggia con il sistema** Un corso Lead Auditor è sempre ancorato a una norma specifica, per esempio ISO 27001 Lead Auditor o ISO 9001 Lead Auditor. Il metodo di audit proviene da ISO 19011 ed è comune a tutti, ma vi formate e vi certificate rispetto ai requisiti del sistema di gestione che intendete auditare. ## Dove si colloca il Lead Auditor tra le qualifiche affini Il Lead Auditor si comprende meglio accanto alle qualifiche con cui i professionisti lo confrontano. All'interno del mondo PECB e ISO fa coppia con Lead Implementer come controparte di assurance. Rispetto a ISACA, anche la qualifica CISA certifica competenza in materia di audit, ma è una qualifica ampia di audit IT legata ai domini ISACA, e non una qualifica per auditare un singolo sistema di gestione denominato sulla base di ISO 19011. **Lead Auditor a confronto con le qualifiche affini** | Qualifica | Posizione | Cosa certifica | | --- | --- | --- | | Lead Auditor | Assurance indipendente | Pianificare e condurre l'audit di un sistema di gestione su ISO 19011 | | Lead Implementer | Costruire e gestire | Progettare e gestire un sistema di gestione verso la certificazione | | CISA | Assurance di audit IT | Audit ampio dei sistemi informativi attraverso i domini ISACA | La scelta tra le due dipende dal lavoro che intendete svolgere. Se il vostro futuro è condurre audit di certificazione o audit fornitori, oppure guidare un programma di audit interno rigoroso, Lead Auditor è la via diretta. Se il vostro compito è realizzare e migliorare il sistema di gestione stesso, Lead Implementer è più adatto. Molti professionisti esperti possiedono entrambe, perché capire come è costruito un sistema vi rende un auditor più acuto, e capire come sarà auditato vi rende un implementatore migliore. --- ## Lead Ethical Hacker **URL:** https://cyberacademy.net/it/resources/encyclopedia/lead-ethical-hacker **Last reviewed:** 2026-06-24 Lead Ethical Hacker è la certificazione PECB per i professionisti della sicurezza offensiva. Copre metodologia, definizione del perimetro, ricognizione, sfruttamento delle vulnerabilità, reporting ed etica. Il complemento accademico a certificazioni pratiche come OSCP e CRTO. Si abbina a Lead Penetration Testing Professional per la gestione degli incarichi. Lead Ethical Hacker è la certificazione PECB rivolta ai professionisti della sicurezza offensiva: le persone autorizzate ad attaccare un sistema affinché un'organizzazione scopra dove cederebbe davvero. È costruita attorno all'intero ciclo di vita di un incarico, anziché attorno a una singola tecnica. Ci si aspetta che un titolare definisca il perimetro di un incarico, raccolga le informazioni di ricognizione, individui e sfrutti le debolezze, e poi trasformi quel lavoro in un report su cui i decisori possano agire, il tutto entro un quadro etico e legale chiaro. Laddove molte certificazioni offensive dimostrano che sai compromettere una macchina in laboratorio, Lead Ethical Hacker si posiziona come il complemento di accreditamento di quella capacità pratica: un segnale neutrale rispetto ai fornitori e allineato agli standard ISO, che attesta che sai condurre un incarico di hacking etico dall'inizio alla fine, e non solo sfruttarlo. ## Cosa copre la certificazione La certificazione segue l'arco di un incarico reale, così che le competenze che convalida corrispondono alle fasi che un tester attraversa durante una valutazione. - Definizione del perimetro e regole d'ingaggio: definire obiettivi, confini, autorizzazione e ciò che è esplicitamente fuori ambito prima che venga inviato un solo pacchetto. - Ricognizione ed enumerazione: costruire un'immagine della superficie di attacco a partire da fonti aperte e sondaggio attivo. - Sfruttamento: utilizzare le debolezze individuate per dimostrare un impatto concreto e supportato da prove, anziché un rischio teorico. - Post-sfruttamento e pivoting: mostrare fino a che punto un attaccante potrebbe ragionevolmente spingersi una volta stabilito un punto d'appoggio. - Reportistica: tradurre i risultati in indicazioni di remediation prioritizzate, riproducibili e leggibili dal business. - Etica e diritto: rimanere all'interno del mandato, gestire i risultati sensibili in modo responsabile e proteggere il cliente per l'intera durata dell'incarico. > **Un accreditamento, non un sostituto dei laboratori pratici** Lead Ethical Hacker è lo strato di metodologia e giudizio. Si abbina in modo naturale a certificazioni pratiche valutate in laboratorio come OSCP o CRTO. Consideralo la prova che sai condurre e documentare un incarico secondo uno standard riconosciuto, accanto a certificazioni pratiche che attestano la pura abilità di sfruttamento. ## In cosa si distingue da concetti affini L'hacking etico e il penetration test si sovrappongono ampiamente e i termini vengono spesso usati in modo intercambiabile, ma non sono identici. Un penetration test è un esercizio delimitato e a tempo, con un obiettivo definito e un report. L'hacking etico è la disciplina e la mentalità più ampia di attaccare i sistemi con il permesso di migliorarne la sicurezza, di cui un penetration test strutturato è una delle espressioni. Si distingue inoltre da un incarico di red team, che è una simulazione più lunga e orientata agli obiettivi, che mette alla prova tanto la rilevazione e la risposta quanto i controlli stessi, e dalla scansione automatizzata delle vulnerabilità, che privilegia l'ampiezza rispetto allo sfruttamento manuale e al ragionamento che un tester apporta. **Lead Ethical Hacker tra le certificazioni di sicurezza offensiva** | Certificazione | Baricentro | Da leggere soprattutto come | | --- | --- | --- | | Lead Ethical Hacker | Metodologia dell'incarico, definizione del perimetro, reportistica, etica | Accreditamento che attesta che sai condurre un incarico | | OSCP / CRTO | Sfruttamento pratico in laboratori valutati | Prova di abilità pratica di attacco | | Lead Penetration Testing Professional | Dirigere e gestire un programma di test | Complemento orientato alla guida dell'incarico | Come osserva la definizione breve, la certificazione si abbina a Lead Penetration Testing Professional per chi si orienta verso la guida degli incarichi: una si concentra sull'atto dell'hacking etico, l'altra sul presidiare il processo di test nell'intera organizzazione. ## A chi è rivolta Si adatta ai professionisti che già svolgono o si orientano verso il lavoro offensivo: penetration tester, membri di red team e consulenti di sicurezza che desiderano una certificazione riconosciuta e allineata agli standard, che rifletta il modo in cui conducono gli incarichi, e non solo la loro capacità di trovare una falla. Poiché le certificazioni PECB sono neutrali rispetto ai fornitori e allineate agli standard ISO, il loro valore risiede in un segnale di competenza strutturato e leggibile a livello internazionale. Come sempre, i datori di lavoro valutano la capacità dimostrata, quindi il profilo più solido combina questo accreditamento con certificazioni pratiche e una storia di test reali e autorizzati. --- ## Lead Implementer **URL:** https://cyberacademy.net/it/resources/encyclopedia/lead-implementer **Last reviewed:** 2026-06-24 Lead Implementer è la credenziale PECB per i professionisti in grado di pianificare, costruire e gestire un sistema di gestione basato su uno specifico standard ISO (nella maggior parte dei casi ISO 27001, ISO 42001, ISO 22301). Corso di cinque giorni, esame, certificato. Costituisce la componente implementativa della disciplina ISO; si affianca al Lead Auditor sul versante dell'audit. ## Cosa fa davvero un Lead Implementer Un Lead Implementer è la persona che prende una norma ISO di sistema di gestione e la trasforma in qualcosa che un'organizzazione reale fa funzionare ogni giorno. Dove la norma dice cosa deve essere presente, il Lead Implementer decide come arrivarci: definire il campo di applicazione del sistema, ottenere l'impegno della direzione, condurre la valutazione del rischio, selezionare e redigere i controlli e le procedure, formare le persone che li opereranno, e guidare l'intero sforzo fino al punto in cui un organismo di certificazione può auditarlo. La credenziale stessa, rilasciata da PECB dopo un corso di cinque giorni e un esame, certifica che sai guidare questo lavoro anziché limitarti a descriverlo. Nella pratica quotidiana il ruolo è in parte project manager, in parte esperto della materia, in parte diplomatico interno. La maggior parte delle implementazioni ISO non fallisce sui controlli tecnici ma sul lavoro che li circonda: ottenere che l'alta direzione sponsorizzi il progetto, concordare il campo di applicazione, definire i ruoli, e radicare le informazioni documentate affinché sopravvivano al primo audit e continuino a vivere in seguito. PECB struttura la sua formazione Lead Implementer attorno a un metodo di implementazione per fasi, così che i candidati escano con una sequenza ripetibile da seguire anziché con un cumulo di clausole da memorizzare. ## Lead Implementer rispetto al Lead Auditor Le due credenziali di punta di PECB descrivono le due facce della disciplina ISO. Un Lead Implementer costruisce e gestisce il sistema di gestione dall'interno dell'organizzazione. Un Lead Auditor valuta un sistema di gestione rispetto alla norma, di solito dall'esterno, e decide se è conforme. Condividono la stessa norma di base e gran parte delle stesse conoscenze, ma la mentalità è diversa: l'implementer è responsabile di far funzionare il sistema, l'auditor è responsabile di giudicarlo in modo imparziale. **Lead Implementer a confronto con Lead Auditor** | Aspetto | Lead Implementer | Lead Auditor | | --- | --- | --- | | Ruolo principale | Costruire, distribuire e gestire il sistema di gestione | Valutare la conformità rispetto alla norma | | Punto di osservazione | All'interno dell'organizzazione | Indipendente, spesso terza parte | | Deliverable centrale | Un sistema di gestione funzionante e certificabile | Un rapporto di audit e un giudizio di conformità | | Riferimento per il metodo | Un approccio di implementazione per fasi | Linee guida di audit ISO 19011 | Nella pratica le certificazioni si completano a vicenda e molti professionisti possiedono entrambe. Capire come un auditor metterà alla prova il sistema ti rende un implementer più acuto, e aver costruito tu stesso un sistema ti rende un auditor più credibile. Chi desidera una padronanza più solida del lato audit spesso abbina Lead Implementer al percorso Lead Auditor. > **Certifica la persona, non l'organizzazione** Lead Implementer è una credenziale personale. Attesta che sai costruire un sistema di gestione conforme a una determinata norma ISO. L'organizzazione viene certificata separatamente da un organismo di certificazione accreditato rispetto alla norma stessa, come ISO 27001 per la sicurezza delle informazioni. ## Quale norma, e dove si colloca Lead Implementer non è legato a una sola norma. La stessa competenza è offerta per diverse norme ISO di sistema di gestione, più comunemente ISO 27001 per la sicurezza delle informazioni, ISO 42001 per i sistemi di gestione dell'IA, e ISO 22301 per la continuità operativa, tra le altre. Poiché queste norme condividono la struttura comune di alto livello che ISO utilizza nei suoi sistemi di gestione, il metodo di implementazione si trasferisce bene: campo di applicazione, leadership, pianificazione, supporto, attività operative, valutazione delle prestazioni e miglioramento ricorrono in ciascuna. Una volta che hai guidato un'implementazione, la norma successiva è per lo più nuovo contenuto di dominio posato su uno scheletro familiare. Per i professionisti che decidono da dove cominciare, l'inquadramento onesto è questo. Se il tuo lavoro ruota attorno alla sicurezza delle informazioni, ISO 27001 Lead Implementer è l'ancora naturale e quella più spesso citata negli annunci di lavoro. Se la tua organizzazione si sta orientando verso un'IA governata, ISO 42001 Lead Implementer ne è l'equivalente emergente. In entrambi i casi ne esci capace di guidare il progetto, non solo di sostenere l'esame, che è ciò che il ruolo richiede una volta tornato alla tua scrivania di fronte a una vera scadenza di certificazione. --- ## Least privilege **URL:** https://cyberacademy.net/it/resources/encyclopedia/least-privilege **Last reviewed:** 2026-06-24 Least privilege è il principio secondo cui ogni identità (umana o di sistema) riceve i permessi minimi necessari per il proprio compito, e nient'altro. Concetto ovvio in teoria; raramente applicato in pratica. La maggior parte degli incidenti di esfiltrazione di dati ha origine da un account di servizio con privilegi eccessivi che nessuno sapeva giustificare quando messo alle strette. Da affiancare a revisioni periodiche degli accessi. ## Il principio, e perché continua a fallire nella pratica Il privilegio minimo è facile da enunciare e difficile da vivere. Ogni identità, che si tratti di una persona, di un account di servizio, di uno script di automazione o di una chiave API, dovrebbe detenere esattamente le autorizzazioni richieste dal suo compito e nient'altro. Il fallimento è raramente una decisione deliberata di concedere troppo. È accumulo. Qualcuno ha bisogno dei diritti di amministratore per una migrazione una tantum e la concessione non viene mai rimossa. Un account di servizio viene creato con ambiti ampi perché restringerli richiederebbe un pomeriggio di test che nessuno ha il tempo di svolgere. A un team viene assegnato un ruolo progettato per un altro team perché era il più simile disponibile. Nel corso dei mesi, le identità accumulano autorizzazioni come una scrivania accumula carte, e nessuno sa spiegare perché una qualsiasi di esse sia lì. Quell'accumulo è la superficie di attacco. Quando un account con autorizzazioni eccessive viene colpito da phishing, divulgato o abusato in silenzio, il raggio d'impatto è tutto ciò che quell'account poteva toccare, che di solito è molto più del suo compito effettivo. La disciplina del privilegio minimo non sta nella concessione iniziale, che è la parte facile. Sta nel lavoro continuo di rimuovere ciò che non serve più e di essere in grado di giustificare ciò che rimane. ## Come lo implementano davvero i professionisti Il privilegio minimo è un'abitudine operativa sostenuta da strumenti, non una configurazione una tantum. Il lavoro si concentra attorno a poche attività ricorrenti: - Progettazione di ruoli e autorizzazioni: costruire i ruoli attorno alle funzioni lavorative in modo che concedere l'accesso sia una corrispondenza deliberata, non una copia di ciò che aveva la persona precedente. - Accesso just-in-time e just-enough: concedere diritti elevati per la finestra in cui sono necessari e rimuoverli automaticamente in seguito, anziché lasciare in essere autorizzazioni di amministrazione permanenti. - Revisioni degli accessi: riesaminare periodicamente chi detiene cosa e richiedere a un responsabile di confermare che ogni concessione sia ancora giustificata. Tutto ciò per cui nessuno è disposto a garantire viene revocato. - Separazione dei compiti: suddividere le azioni sensibili in modo che nessuna singola identità possa sia avviare sia approvare un'operazione ad alto rischio, ovvero il privilegio minimo applicato ai flussi di lavoro anziché ai dati. - Identità macchina: trattare account di servizio, token e credenziali di pipeline con lo stesso rigore degli utenti umani, perché sono spesso i più dotati di autorizzazioni eccessive e i meno revisionati. > **L'account di servizio ingiustificabile** Quando una revisione degli accessi raggiunge un account e nessuno nella stanza sa dire a cosa serve né perché ha l'ambito che ha, quello è il segnale, non l'eccezione. La maggior parte degli incidenti di esfiltrazione di dati risale esattamente a questo tipo di identità dimenticata e con autorizzazioni eccessive. La risposta corretta è revocare e vedere cosa si rompe in modo controllato, non lasciarla perché la rimozione sembra rischiosa. ## Dove si colloca tra zero trust, IAM e PAM Il privilegio minimo è un principio. I termini vicini sono il meccanismo che lo realizza. La gestione delle identità e degli accessi (IAM) è il sistema che definisce le identità e ciò che possono fare, quindi il privilegio minimo è la regola che l'IAM dovrebbe far rispettare. La gestione degli accessi privilegiati (PAM) è la disciplina più rigorosa applicata agli account a maggior rischio, dove il privilegio minimo conta di più e dove di solito risiede l'elevazione just-in-time. Lo zero trust è l'architettura più ampia che presume che nessuna identità sia attendibile per impostazione predefinita e verifica ogni richiesta; il privilegio minimo è uno dei suoi meccanismi fondamentali, perché verificare una richiesta aiuta solo se l'accesso concesso è già minimo. Si può sostenere il principio senza gli strumenti, ma a qualsiasi scala reale il principio senza IAM, PAM e revisioni periodiche si degrada silenziosamente di nuovo in sovra-provisioning. L'idea è intrecciata negli standard anche dove la formulazione esatta varia. L'Annex A della ISO/IEC 27001 affronta il controllo degli accessi, i diritti di accesso privilegiato e la revisione periodica dei diritti di accesso degli utenti. La famiglia di controllo degli accessi del NIST è costruita attorno al privilegio minimo e alla separazione dei compiti come principi denominati. I CIS Controls richiedono un uso controllato dei privilegi amministrativi e la gestione degli account. Gli auditor non vogliono solo constatare che l'accesso sia stato concesso correttamente una volta. Si aspettano la prova di un ciclo di revisione continuo, e un account di amministrazione permanente che nessuno revisiona viene trattato come un rilievo, non come una comodità. --- ## MITRE ATT&CK **URL:** https://cyberacademy.net/it/resources/encyclopedia/mitre-attack **Last reviewed:** 2026-06-24 MITRE ATT&CK è la knowledge base aperta di tattiche, tecniche e procedure (TTP) degli avversari osservate in ambienti reali. Vocabolario standard per la difesa informata dalle minacce: regole di detection, scenari red-team, formazione degli analisti SOC. Aggiornata continuamente, gratuita. Se le regole del proprio SIEM non referenziano gli ID di tecnica ATT&CK, si sta lavorando con più sforzo del necessario. ## Un linguaggio comune per descrivere il comportamento degli attaccanti MITRE ATT&CK riorienta la threat intelligence intorno al comportamento anziché agli indicatori. Invece di catalogare gli indirizzi IP o gli hash dei file osservati in una singola campagna, che cambiano di continuo, cataloga ciò che gli avversari fanno davvero una volta dentro un ambiente: come ottengono l'accesso iniziale, scalano i privilegi, si muovono lateralmente, eludono le difese ed esfiltrano dati. Ciascuno di questi comportamenti è catturato come una tecnica dotata di un identificatore stabile, e le tecniche sono raggruppate sotto tattiche che descrivono l'obiettivo dell'attaccante a ogni passaggio. Il risultato è una mappa strutturata e basata sull'evidenza del manuale di gioco avversario, tratta da intrusioni reali osservate anziché dalla teoria. Il framework è organizzato come una matrice. Le colonne sono le tattiche, il perché dietro un passaggio, e le celle sotto ciascuna colonna sono le tecniche e le sotto-tecniche, il come. Matrici separate coprono gli ambienti Enterprise, mobile e i sistemi di controllo industriale, perché il comportamento avversario differisce a seconda di quei terreni. Poiché gli identificatori delle tecniche sono stabili e pubblici, diventano un riferimento comune che un analista di threat intelligence, un ingegnere SOC che scrive rilevamenti e un membro di un red team che pianifica un esercizio possono tutti citare senza ambiguità. Quel vocabolario condiviso è il superpotere silenzioso di ATT&CK: consente a team che non si parlano mai di descrivere lo stesso attacco nello stesso modo. ## Tattiche, tecniche e procedure Il modello TTP è al cuore di ATT&CK e conviene tenere distinti i tre livelli. Le tattiche sono gli obiettivi dell'avversario, le finalità ampie come ottenere un punto d'appoggio o mantenere la persistenza. Le tecniche sono i metodi generali usati per raggiungere una tattica, e molte tecniche si suddividono ulteriormente in sotto-tecniche che descrivono una variante più specifica. Le procedure sono le implementazioni concrete, osservate nel mondo reale, che un gruppo particolare ha usato per realizzare una tecnica. Risalire quella scala, dalla procedura alla tecnica alla tattica, è ciò che trasforma un cumulo di artefatti di incidente in uno schema contro cui ci si può difendere. **I livelli TTP in ATT&CK** | Livello | Domanda a cui risponde | Senso illustrato | | --- | --- | --- | | Tattica | Perché l'avversario fa questo? | L'obiettivo di un passaggio, come la persistenza o il movimento laterale | | Tecnica | Come, in generale, lo raggiungono? | Un metodo con nome e un identificatore ATT&CK stabile, talvolta suddiviso in sotto-tecniche | | Procedura | Come esattamente questo gruppo l'ha fatto? | L'implementazione specifica osservata in un'intrusione reale | La ragione per cui i professionisti apprezzano questa struttura è che le difese costruite a livello di tecnica sopravvivono più a lungo di quelle basate sugli indicatori. Un attaccante può cambiare un dominio malevolo o ricompilare un payload in pochi minuti, sconfiggendo il blocco basato sulle firme, ma modificare la tecnica sottostante richiede più sforzo e spesso più abilità. I rilevamenti ancorati alle tecniche invecchiano quindi più lentamente e catturano varianti che la prima firma non ha mai visto. ## Come i team mettono ATT&CK al lavoro La difesa informata dalle minacce è la pratica che ATT&CK abilita, e si manifesta in tutta la funzione di sicurezza. I team SOC etichettano le regole di rilevamento con identificatori di tecniche così da vedere, a colpo d'occhio, quali comportamenti avversari riescono a individuare e quali sfuggono loro. Quell'analisi delle lacune, spesso visualizzata come una mappa di calore sulla matrice, indirizza dove va il prossimo sforzo di rilevamento. I red team e i purple team usano la matrice per progettare e valutare esercizi, attraversando deliberatamente le tecniche per verificare se il blue team le nota. I team di threat intelligence descrivono i gruppi avversari in termini ATT&CK così che i report siano comparabili anziché prosa su misura. E i programmi di formazione vi si appoggiano perché offre agli analisti un modello unico e ben documentato del comportamento degli attaccanti da apprendere, anziché mille racconti di guerra slegati. > **Mappa la tua copertura, poi colma le lacune** La prima mossa a più alto valore è una mappa di copertura: etichetta i tuoi rilevamenti e controlli esistenti alle tecniche ATT&CK e osserva dove la matrice si illumina e dove resta buia. Le celle buie sono i tuoi punti ciechi in termini di attaccante, e quell'immagine è molto più azionabile di un elenco di strumenti che possiedi. ATT&CK è pubblicato apertamente, gratuito da usare e aggiornato di continuo man mano che si osserva nuovo comportamento avversario, ed è il motivo per cui è diventato il riferimento di fatto anziché un framework di un fornitore tra molti. Si abbina naturalmente ai cataloghi di controlli e ai sistemi di gestione: dove ISO/IEC 27001, il NIST Cybersecurity Framework o i CIS Controls ti dicono quali capacità di protezione e rilevamento costruire, ATT&CK ti dice quali comportamenti avversari quelle capacità devono affrontare, ed è sempre più usato per prioritizzare e validare quel lavoro. --- ## Mean Time to Detect / Recover (MTTD / MTTR) **URL:** https://cyberacademy.net/it/resources/encyclopedia/mttd-mttr **Last reviewed:** 2026-06-24 MTTD è il tempo medio che intercorre tra l'inizio di un incidente e la sua rilevazione. MTTR è il tempo medio dalla rilevazione al ripristino. Insieme costituiscono le metriche operative di riferimento per un SOC e un programma di incident response. I benchmark di settore si collocano nell'ordine di giorni o settimane; i programmi maturi puntano alle ore. ## Due metriche, un'unica linea temporale L'MTTD e l'MTTR descrivono due segmenti consecutivi della stessa linea temporale di un incidente. L'MTTD copre il periodo silenzioso tra il momento in cui un attaccante agisce per la prima volta e il momento in cui il vostro team si accorge che qualcosa non va. L'MTTR copre tutto ciò che segue quel punto, dal triage al contenimento e al ripristino, fino a un ritorno confermato alla normalità. Leggerli insieme è proprio il punto: un MTTD basso con un MTTR alto significa che individuate le minacce rapidamente ma faticate ad agirvi, mentre un MTTD alto con un MTTR basso significa che rispondete in fretta, ma solo quando il danno è già fatto. Nessuno dei due numeri è utile isolatamente, e migliorare l'uno a scapito dell'altro raramente aiuta. In pratica questi sono i numeri di punta che un SOC riferisce alla direzione, perché traducono l'attività tecnica in un linguaggio che il business comprende: per quanto tempo siamo stati esposti e quanto ci è voluto per chiudere la porta. Sono anche le metriche attorno a cui ruotano i regolatori e i framework, anche quando usano parole diverse. Una scadenza per la notifica di una violazione è essenzialmente un tetto legale su una parte del vostro MTTR, e l'obbligo di rilevare gli incidenti in tempo utile è l'obbligo di mantenere basso l'MTTD. ## Cosa muove davvero questi numeri L'MTTD è guidato dalla visibilità e dalla messa a punto. Non potete rilevare ciò che non raccogliete, quindi la copertura dei log su endpoint, rete, identità e cloud è la base. Oltre a questo, il contenuto di rilevamento va messo a punto: troppo permissivo e gli analisti annegano nei falsi positivi e perdono il segnale reale, troppo stretto e le intrusioni autentiche sfuggono. Per questo un SIEM, una buona ingegneria di rilevamento e la threat intelligence alimentano direttamente l'MTTD. L'MTTR è guidato dal processo e dall'autorità: playbook documentati, il potere di isolare un host o disabilitare un account senza attendere un comitato, backup testati e una comunicazione provata. Il miglioramento classico qui è l'automazione tramite un SOAR, che elimina i minuti persi nei passaggi manuali. **L'MTTD a confronto con l'MTTR in sintesi** | Aspetto | MTTD (Rilevare) | MTTR (Ripristinare) | | --- | --- | --- | | Finestra temporale | Dall'inizio dell'incidente al rilevamento | Dal rilevamento al ripristino completo | | Domanda principale | Per quanto tempo siamo stati ciechi? | Quanto tempo per contenere e ripristinare? | | Leve principali | Copertura dei log, messa a punto del rilevamento, threat intelligence | Playbook, automazione, autorità di agire, backup | | Strumenti | SIEM, EDR, rilevamento delle minacce | SOAR, runbook di risposta agli incidenti, strumenti di ripristino | | Focus del responsabile | Ingegneria di rilevamento e monitoraggio | Risposta agli incidenti e operazioni | > **Definite il cronometro prima di fidarvi del numero** L'MTTD e l'MTTR sono comparabili solo se tutti concordano sui punti di inizio e di arresto. L'MTTR termina al contenimento, all'eradicazione o a un ritorno al servizio verificato? L'MTTD inizia alla prima azione malevola o al primo evento di log che vi è capitato di catturare? Finché quelle definizioni non sono messe per iscritto, un numero che cala può semplicemente significare che avete cambiato il modo di misurare. ## Come le metriche compaiono negli standard e nei benchmark I framework di solito non impongono un obiettivo specifico di MTTD o MTTR, perché il numero giusto dipende dall'organizzazione e dalla minaccia. Ciò che richiedono è la capacità e la misurazione. La ISO/IEC 27035 definisce il ciclo di vita della gestione degli incidenti che queste metriche quantificano. Le linee guida del NIST sulla gestione degli incidenti inquadrano rilevamento, analisi, contenimento, eradicazione e ripristino come fasi distinte, che è esattamente la struttura su cui poggiano l'MTTD e l'MTTR. L'ENISA e le agenzie nazionali come l'ANSSI trasmettono lo stesso messaggio operativo: rilevare presto, rispondere in fretta ed essere in grado di dimostrarlo. I regimi normativi aggiungono scadenze esterne rigide, ad esempio le finestre di notifica delle violazioni previste dal GDPR e gli obblighi di segnalazione degli incidenti previsti da NIS2 e DORA, che trasformano una parte del vostro tempo di risposta in un requisito di conformità anziché in un obiettivo di prestazione. I benchmark per entrambe le metriche tendono a collocarsi scomodamente in alto in tutto il settore, spesso dell'ordine di giorni o settimane per il rilevamento, mentre i programmi maturi puntano a ore. Inseguire un benchmark pubblicato è però l'istinto sbagliato. Il valore dell'MTTD e dell'MTTR risiede nelle linee di tendenza che possedete: misuratele in modo coerente, osservate la direzione nei trimestri e collegate il movimento a investimenti specifici in visibilità, messa a punto e automazione. Un numero definito onestamente e in calo costante vale molto di più di una cifra lusinghiera e isolata. --- ## NIS 2 Directive (NIS 2) **URL:** https://cyberacademy.net/it/resources/encyclopedia/nis-2 **Last reviewed:** 2026-06-24 NIS 2 è la direttiva UE che rende i consigli di amministrazione direttamente responsabili della cybersecurity. Medie e grandi imprese, in uno qualsiasi dei 18 settori elencati, rientrano nel perimetro. Il cronometro parte al primo incidente significativo: allerta precoce entro 24 ore, notifica entro 72 ore, rapporto completo entro un mese. Le sanzioni sono severe (10 milioni di euro o il 2% del fatturato mondiale). Il recepimento varia da Stato membro a Stato membro. ## Cosa cambia davvero NIS 2 NIS 2 è la seconda iterazione della Direttiva europea sulla sicurezza delle reti e dei sistemi informativi, e amplia notevolmente il perimetro rispetto al regime NIS originario. Laddove la prima direttiva si affidava alle autorità nazionali per individuare gli operatori di servizi essenziali caso per caso, NIS 2 fissa criteri di autoidentificazione: se operi in uno dei settori elencati e superi la soglia dimensionale, rientri nell'ambito di applicazione e ci si aspetta che tu lo sappia. La direttiva suddivide le organizzazioni interessate in due livelli, soggetti "essenziali" e "importanti", il che incide soprattutto sul modo in cui vengono applicate la vigilanza e l'esecuzione piuttosto che sugli obblighi di base in sé. Il cambiamento principale è la responsabilità. NIS 2 rende gli organi di gestione responsabili dell'approvazione e della supervisione delle misure di gestione dei rischi di cybersicurezza, e si aspetta che seguano una formazione per poter esercitare concretamente tale supervisione. La sicurezza smette di essere qualcosa che il reparto IT gestisce in silenzio e diventa un tema di governance che il consiglio di amministrazione deve approvare. È la ragione pratica per cui la direttiva viene così spesso riassunta come "mettere i consigli di amministrazione in prima linea". ## Ambito di applicazione, settori e il test dimensionale L'ambito di applicazione si basa su due domande: operi in un settore elencato e sei abbastanza grande? La direttiva copre settori suddivisi tra le categorie "ad alta criticità" e "altri settori critici", che spaziano da energia, trasporti, banche, sanità, acqua, infrastrutture digitali, pubblica amministrazione, servizi postali, fabbricazione di determinati prodotti, alimentare e altro ancora. Il test dimensionale interessa generalmente le organizzazioni medie e grandi, con i soggetti più piccoli talvolta inclusi quando il loro ruolo è critico a prescindere dall'organico. Poiché gli Stati membri possono designare soggetti aggiuntivi, l'unico approccio sicuro è mappare le proprie attività rispetto agli allegati settoriali anziché presumere di essere troppo piccoli per contare. > **Una direttiva, non un regolamento** NIS 2 è una direttiva, quindi non si applica direttamente come fanno DORA o il GDPR. Ciascuno Stato membro la recepisce nel diritto nazionale, il che significa che l'autorità esatta, il processo di registrazione e il dettaglio della vigilanza variano da paese a paese. Verifica sempre il testo di recepimento nelle giurisdizioni in cui operi. ## Il conto alla rovescia della notifica degli incidenti Ciò che i professionisti percepiscono più direttamente è la tempistica di notifica, che scatta in caso di incidente significativo. Si articola in fasi: un preallarme entro 24 ore, una notifica più completa entro 72 ore e una relazione finale al traguardo di un mese, con l'autorità competente o il CSIRT come destinatario. Lo scopo del modello scaglionato è far emergere rapidamente gli incidenti senza imporre un quadro forense completo già dal primo giorno. Per rispettarlo servono una rilevazione che segnali rapidamente la significatività, un responsabile decisionale in grado di classificare un incidente e modelli di notifica predisposti in anticipo, in modo che il conto alla rovescia non ti colga a scrivere da zero. A sostegno della tempistica vi sono obblighi di gestione del rischio che si leggono come una base familiare: gestione degli incidenti, continuità operativa e backup, sicurezza della catena di approvvigionamento, sviluppo e manutenzione sicuri, gestione delle vulnerabilità, uso della crittografia, controllo degli accessi e autenticazione a più fattori, e politiche per verificare quanto bene tutto questo funzioni. Niente di tutto ciò è esotico. Un'organizzazione che gestisce un ISMS maturo, ad esempio allineato a ISO 27001, copre già gran parte del terreno; il lavoro consiste nel mappare i controlli esistenti rispetto alle aspettative di NIS 2 e nel colmare le lacune di governance e di notifica. ## Cosa significa nella pratica rientrare nell'ambito di applicazione Se concludi di rientrare nell'ambito di applicazione, il programma pratico è piuttosto coerente: registrarti presso la competente autorità nazionale ove richiesto, formalizzare la supervisione del rischio cyber a livello di consiglio, documentare le tue misure di gestione del rischio rispetto alle voci della direttiva, predisporre un processo di classificazione e notifica degli incidenti in grado di rispettare le finestre di 24/72 ore e un mese, ed estendere la due diligence alla catena di approvvigionamento perché i fornitori fanno esplicitamente parte del quadro di rischio. L'esecuzione ha i denti, con sanzioni che arrivano a decine di milioni di euro o a una percentuale del fatturato mondiale, oltre alla possibilità di responsabilità della dirigenza, che è esattamente il motivo per cui la direttiva spinge la responsabilità verso l'alto. --- ## NIST Cybersecurity Framework (NIST CSF) **URL:** https://cyberacademy.net/it/resources/encyclopedia/nist-csf **Last reviewed:** 2026-06-24 NIST CSF è il framework di cybersecurity pubblicato dal National Institute of Standards and Technology statunitense. La revisione 2.0 (2024) ha aggiunto la funzione "Govern" alle cinque funzioni esistenti (Identify, Protect, Detect, Respond, Recover). Non è certificabile; viene utilizzato come riferimento di maturità. Accompagna frequentemente ISO 27001 nelle organizzazioni transatlantiche. ## Cos'è il NIST CSF e cosa non è Il NIST Cybersecurity Framework è un modo strutturato di organizzare un programma di cybersicurezza attorno ai risultati anziché ai prodotti. Non vi dice quale firewall acquistare o quale controllo implementare. Descrive invece com'è fatto ciò che è buono, raggruppando l'attività di cybersicurezza in un piccolo insieme di funzioni e suddividendo ciascuna funzione in categorie e sottocategorie che si leggono come risultati in linguaggio chiaro: gli asset sono inventariati, gli accessi sono gestiti, le anomalie sono rilevate, i piani di risposta sono eseguiti. Questo orientamento ai risultati è il motivo per cui si adatta così bene a settori e dimensioni diverse. Un ospedale, un produttore e un fornitore di software possono usare tutti lo stesso vocabolario per descrivere dove si trovano e dove vogliono arrivare. La cosa più importante da capire è ciò che il framework non è. Non è una norma certificabile. Non esiste un certificato NIST CSF, nessun organismo accreditato che rilasci un esito positivo e nessun audit che si concluda con un marchio registrato sul vostro sito web. È un riferimento volontario che si utilizza per valutare la maturità, fissare obiettivi e comunicare la postura, sia internamente a un consiglio di amministrazione sia esternamente ai partner. Considerate l'affermazione di un fornitore di essere «certificato NIST CSF» come un segnale di allarme, perché tale certificazione non esiste. ## Le funzioni: da cinque a sei Il framework è costruito attorno a funzioni che insieme coprono l'intero ciclo di vita della gestione del rischio cyber. Le cinque originali erano Identify, Protect, Detect, Respond e Recover. La revisione 2.0 pubblicata nel 2024 ha aggiunto Govern, portando il totale a sei e collocando la governance al centro del modello anziché trattarla come un ripensamento. Govern copre il contesto organizzativo, la strategia di gestione del rischio, ruoli e responsabilità, la politica e la supervisione che dovrebbero plasmare il modo in cui le altre cinque funzioni vengono prioritizzate e dotate di risorse. La sua aggiunta ha formalizzato ciò che i programmi maturi già facevano: i controlli tecnici funzionano solo quando qualcuno è responsabile delle decisioni sul rischio che li sottendono. **Le sei funzioni del NIST CSF 2.0** | Funzione | Cosa copre | | --- | --- | | Govern | Strategia, ruoli, politica e supervisione del rischio cyber | | Identify | Comprendere gli asset, i fornitori e i rischi che li riguardano | | Protect | Misure di salvaguardia che limitano o contengono un incidente | | Detect | Individuare eventi e anomalie nel momento in cui si verificano | | Respond | Agire su un incidente rilevato per contenerlo | | Recover | Ripristinare le capacità e i servizi dopo un incidente | In pratica, un team valuta il proprio stato attuale rispetto a ciascuna categoria, definisce un profilo obiettivo che riflette la propria propensione al rischio e i propri obblighi, e lavora per colmare il divario tra i due. Il framework lascia deliberatamente il come a voi, ed è per questo che si abbina naturalmente a cataloghi prescrittivi come i CIS Controls o NIST 800-53 che forniscono le misure di salvaguardia concrete sotto ciascun risultato. ## Perché si colloca accanto a ISO 27001 Il NIST CSF e ISO 27001 non sono concorrenti, e molte organizzazioni transatlantiche utilizzano entrambi. ISO 27001 certifica che gestite un sistema di gestione della sicurezza delle informazioni, con una valutazione del rischio, una dichiarazione di applicabilità e un miglioramento continuo, e produce un certificato verificabile che i clienti riconoscono in tutto il mondo. Il NIST CSF vi offre un linguaggio di maturità flessibile e un modo per esprimere la postura a un pubblico di orientamento statunitense o per allinearvi alle aspettative federali statunitensi. Uno schema comune consiste nel certificare il sistema di gestione secondo ISO 27001 per ottenere la credenziale, quindi utilizzare il profilo CSF per comunicare la maturità e allinearsi con framework e clienti che si esprimono in termini NIST. NIST pubblica riferimenti informativi che mappano le sottocategorie del CSF a ISO 27001 e ad altre norme, così che il lavoro raramente debba essere svolto due volte. > **Nessun certificato, per scelta progettuale** Il NIST CSF è un riferimento di maturità volontario, non una norma certificabile. Se vi serve un marchio verificabile che i clienti riconoscano, è ISO 27001. Usate il CSF per valutare, definire obiettivi e comunicare, e abbinatelo a un catalogo di controlli per colmare effettivamente i divari. --- ## NIST SP 800-171 **URL:** https://cyberacademy.net/it/resources/encyclopedia/nist-800-171 **Last reviewed:** 2026-06-24 NIST SP 800-171 è lo standard statunitense che definisce i requisiti di sicurezza per la protezione delle informazioni non classificate controllate nei sistemi non federali. Costituisce la base tecnica del CMMC per i fornitori della difesa. La revisione 3 (2024) ha irrigidito i controlli. Se si vende al DoD statunitense, è obbligatorio; se si opera esclusivamente in Europa, ha valore informativo. ## Che cosa richiede realmente NIST SP 800-171 Quando il governo statunitense condivide dati sensibili ma non classificati con un appaltatore, un'università o un fornitore di servizi, ha bisogno della garanzia che tali dati saranno protetti anche se ora risiedono al di fuori dei sistemi federali. NIST SP 800-171 è il catalogo dei requisiti di sicurezza che risponde a questa esigenza. Indica a qualsiasi organizzazione non federale che tratta Controlled Unclassified Information come proteggerle: attraverso il controllo degli accessi, la sensibilizzazione e la formazione, l'audit e la responsabilità, la gestione della configurazione, l'identificazione e l'autenticazione, la risposta agli incidenti, la manutenzione, la protezione dei supporti, la protezione fisica, la sicurezza del personale, la valutazione dei rischi, la valutazione della sicurezza, la protezione dei sistemi e delle comunicazioni e l'integrità dei sistemi e delle informazioni. L'obiettivo è l'uniformità. Anziché lasciare che ogni agenzia inventi le proprie clausole, gli appaltatori soddisfano un'unica base coerente. I requisiti derivano dal catalogo di controlli molto più ampio NIST SP 800-53 utilizzato all'interno dei sistemi federali, ma adattati alla realtà di un'organizzazione privata. Sono formulati come risultati da raggiungere, non come un singolo prodotto o un'architettura prescritti, il che lascia a un'organizzazione margine per attuarli in un modo adatto ai propri sistemi. Ciò di cui non si dispone è la discrezionalità sul se soddisfarli. Quando il requisito compare nel contratto, attuarlo è una condizione per mantenere quel contratto. ## I CUI e perché la questione del perimetro conta più di ogni altra Tutto in NIST SP 800-171 ruota attorno a una domanda preliminare: dove risiedono realmente i Controlled Unclassified Information nel vostro ambiente? I CUI sono informazioni che il governo crea o detiene, o che un'organizzazione crea per il governo, che richiedono salvaguardia in base a una legge, a un regolamento o a una politica di portata governativa, ma che non sono classificate. Comprendono categorie come disegni tecnici, dati soggetti a controllo delle esportazioni, informazioni personali identificabili conservate per conto di un'agenzia e materiale sensibile analogo. La norma si applica solo ai sistemi che archiviano, elaborano o trasmettono tali dati. Ecco perché la definizione del perimetro è il lavoro che determina tutto il resto. Definite il confine troppo ampiamente e imporrete controlli di livello federale all'intera rete con un costo enorme. Definitelo troppo strettamente e lascerete CUI esposti in un sistema che avete dimenticato di considerare. La maggior parte di un programma 800-171 credibile è dedicata a individuare i CUI, isolare i sistemi che li toccano e ridurre quel perimetro affinché i controlli ricadano dove sono realmente necessari anziché ovunque. > **Il perimetro prima dei controlli** Non potete proteggere i Controlled Unclassified Information finché non sapete dove si trovano. Mappate prima i flussi di dati CUI e definite il confine del vostro sistema; i controlli sono molto meno costosi da attuare a fronte di un'enclave piccola e ben isolata che a fronte di un'intera rete aziendale. ## Dove finisce 800-171 e dove inizia CMMC NIST SP 800-171 è il catalogo dei controlli. La Cybersecurity Maturity Model Certification (CMMC) è il meccanismo di verifica che il Department of Defense statunitense ha costruito su di esso. Per anni gli appaltatori autocertificavano di soddisfare il 800-171, e il divario tra l'attestazione e la realtà emergeva solo dopo un incidente. CMMC Level 2 corrisponde direttamente a NIST SP 800-171 ma aggiunge una valutazione indipendente, così una firma non è più sufficiente. Se attuate davvero il 800-171, avete svolto la maggior parte del lavoro sostanziale per CMMC Level 2; ciò che resta è produrre prove e superare una valutazione condotta da qualcuno che non siete voi. La Revision 3, pubblicata nel 2024, ha ristrutturato e irrigidito i requisiti, riorganizzato le famiglie di controlli e spostato alcuni aspetti specifici in una pubblicazione di valutazione complementare. Per un fornitore europeo la rilevanza è interamente contrattuale. Se subappaltate a un prime statunitense, fabbricate componenti per la difesa o trattate CUI per un programma del DoD, il 800-171 vi vincola allo stesso modo in cui vincola un'azienda statunitense. Se il vostro mercato è puramente europeo, costituisce un contesto informativo che vi aiuta a leggere CMMC e i requisiti degli appalti pubblici statunitensi, e si combina naturalmente con la disciplina basata sul rischio del NIST Cybersecurity Framework anziché sostituirla. --- ## Non conformità (NC) **URL:** https://cyberacademy.net/it/resources/encyclopedia/non-conformity **Last reviewed:** 2026-06-24 Una non conformità è la constatazione, da parte del valutatore, che un requisito non è soddisfatto. Le NC maggiori mettono a rischio la certificazione; le NC minori richiedono un piano d'azione correttivo con scadenza definita. NC minori ripetute nella stessa area possono essere elevate a maggiori nel successivo audit di sorveglianza. L'obiettivo non è zero NC: è un'azione correttiva onesta e tracciabile. ## Cosa è davvero una non conformità Una non conformità registra uno scarto tra ciò che un requisito richiede e ciò che un auditor può constatare nella pratica. Il requisito può derivare dalla norma stessa (per esempio una clausola della ISO/IEC 27001), da un controllo che avete dichiarato applicabile nella vostra Dichiarazione di Applicabilità, o dalla vostra stessa politica documentata. Se l'avete scritto e vi siete impegnati a rispettarlo, un auditor può esigerne il rispetto. Quest'ultimo punto coglie i team di sorpresa: promettere troppo in una politica crea non conformità che la norma da sola non avrebbe mai generato. Una non conformità non è la stessa cosa di un'osservazione o di un'opportunità di miglioramento. Un'osservazione segnala qualcosa che l'auditor vuole mettere agli atti senza affermare che un requisito è violato. Una non conformità è un'affermazione definitiva che un requisito non è soddisfatto, supportata da evidenze oggettive come una registrazione, un colloquio o un artefatto mancante. La distinzione conta perché solo le non conformità impongono una risposta formale. ## Maggiore o minore, e come le minori si aggravano Gli auditor classificano i rilievi in base all'impatto sul sistema di gestione, non in base a quanto li infastidiscono. Una non conformità maggiore significa che un requisito è fondamentalmente assente, oppure che una carenza è abbastanza diffusa da minare la fiducia nel funzionamento del sistema. Le maggiori mettono a rischio la decisione di certificazione e di solito devono essere chiuse prima che la certificazione o la ricertificazione possa procedere. Una non conformità minore è una mancanza isolata in un processo per il resto funzionante: una singola revisione mancante, una registrazione non firmata. La trappola è considerare le minori come innocue. Lo stesso rilievo minore nella stessa area, audit dopo audit, dice all'auditor che la vostra azione correttiva non ha mai risolto la causa radice. All'audit di sorveglianza successivo quello schema può essere riclassificato come maggiore, perché un controllo che continua a fallire nello stesso modo non sta effettivamente operando. **Come gli auditor pesano tipicamente le non conformità** | Aspetto | NC minore | NC maggiore | | --- | --- | --- | | Ambito | Mancanza isolata e circoscritta | Assenza sistemica o totale di un requisito | | Effetto sul certificato | Il certificato di norma procede | Può bloccare o sospendere la certificazione | | Risposta richiesta | Piano di azione correttiva con una scadenza | Spesso correzione più riverifica in loco o tramite evidenze | | Se ripetuta | Può aggravarsi in maggiore la prossima volta | Già al vertice della scala | ## Cosa ne fanno davvero i professionisti Chiudere bene una non conformità è un processo, non una scusa. Lo schema riconosciuto è correzione, poi azione correttiva, poi verifica dell'efficacia. La correzione è il rimedio immediato al caso specifico che l'auditor ha trovato. L'azione correttiva è la mossa più profonda: un'analisi della causa radice che spiega perché lo scarto esisteva e un cambiamento che ne impedisce il ripetersi. La verifica conferma, con evidenze e dopo che è trascorso tempo sufficiente, che il cambiamento ha effettivamente tenuto. Ciascuno di questi elementi appartiene a un piano di azione correttiva con un responsabile e una scadenza realistica concordata con l'auditor. Le evidenze che presentate dovrebbero permettere a qualcuno che non era nella stanza di ricostruire ciò che è accaduto e confermare che è chiuso. È qui che l'onestà ripaga: un auditor preferisce vedere un piccolo numero di azioni correttive ben tracciate piuttosto che un report dall'aspetto pulito che non regge all'esame. > **Zero non è l'obiettivo** Un audit di sorveglianza che non rileva alcuna non conformità può essere letto come un sistema che nessuno sta mettendo alla prova. L'esito credibile è un elenco gestibile di rilievi, ciascuno con una causa radice documentata e un'azione correttiva tracciabile che si chiude nei tempi. --- ## PCI DSS **URL:** https://cyberacademy.net/it/resources/encyclopedia/pci-dss **Last reviewed:** 2026-06-24 PCI DSS è il Payment Card Industry Data Security Standard. Obbligatorio per chiunque memorizzi, elabori o trasmetta dati dei titolari di carta. La versione 4.0.1 è la revisione corrente, pienamente obbligatoria dal 31 marzo 2025. La riduzione dello scope (tokenizzazione, segmentazione) è la leva su cui puntare; la conformità è binaria, ma tutto dipende da quanto si riesce a ridurre lo scope. ## Cosa disciplina realmente PCI DSS PCI DSS è la base di sicurezza imposta dai principali circuiti di carte di pagamento a ogni organizzazione che memorizza, elabora o trasmette dati dei titolari di carta. Non è una legge né una regolamentazione governativa. È un requisito contrattuale, applicato attraverso le banche acquirer e i circuiti di carte che si collocano al di sopra di esse. Se gestisci un numero di conto primario, lo standard si applica a te, che tu sia un retailer globale o un piccolo negozio di e-commerce con un'unica pagina di checkout. Lo standard è organizzato attorno a un insieme di obiettivi di controllo che coprono persone, processi e tecnologie a contatto con i dati dei titolari di carta: costruire e mantenere una rete sicura, proteggere i dati di conto memorizzati, cifrare la trasmissione, gestire le vulnerabilità, limitare l'accesso secondo il principio della necessità di sapere, monitorare e registrare, e mantenere una politica scritta di sicurezza delle informazioni. Ciascun obiettivo si scompone in requisiti concreti e verificabili, ed è per questo che PCI DSS si legge più come una lista di controllo di audit che come un quadro basato su principi quale ISO 27001. ## Il perimetro è tutto La decisione più importante per il professionista non è come superare la valutazione, ma come ridurre ciò che viene valutato. Tutto ciò che memorizza, elabora o trasmette dati dei titolari di carta, oltre a qualsiasi elemento ad esso connesso, rientra nell'ambiente dei dati dei titolari di carta (CDE). Più ampio è il CDE, più sistemi devono soddisfare ogni requisito e più la valutazione diventa gravosa e costosa. È qui che la tokenizzazione, la segmentazione della rete e l'esternalizzazione verso fornitori di pagamento conformi dimostrano il loro valore. Sostituendo i numeri di carta con token, isolando il CDE dietro firewall e spostando l'effettiva acquisizione della carta su una pagina ospitata o su un processore di terze parti, rimuovi interamente i sistemi dal perimetro. Un ambiente ben segmentato può ridurre un parco sterminato a una manciata di componenti che richiedono una validazione completa. > **La conformità è binaria, il perimetro no** O soddisfi ogni requisito applicabile oppure no; non esiste un credito parziale. Ma quanto riduci l'ambiente dei dati dei titolari di carta determina quanto sforzo costa quel risultato binario. La riduzione del perimetro è la singola mossa a maggiore leva in qualsiasi programma PCI. ## Come funziona la validazione nella pratica Il modo in cui dimostri la conformità dipende dal volume delle transazioni e da come accetti i pagamenti. I commercianti più piccoli compilano in genere un questionario di autovalutazione (SAQ), scegliendo la versione corrispondente al proprio canale di accettazione. I commercianti e i fornitori di servizi di maggiori dimensioni si sottopongono a una valutazione formale da parte di un Qualified Security Assessor (QSA), che produce un Report on Compliance. La scansione della rete da parte di un Approved Scanning Vendor e la fornitura di evidenze trimestrali sono obblighi comuni a tutti i livelli. La revisione attuale, la versione 4.0.1, va oltre la semplice lista di controllo. Accanto all'«approccio definito» prescrittivo, introduce un «approccio personalizzato» che consente alle organizzazioni mature di soddisfare un obiettivo di controllo mediante controlli da esse progettati, a condizione che possano documentare e dimostrare che l'obiettivo è raggiunto. Riformula inoltre la conformità come uno stato continuo anziché un'istantanea annuale, con diversi requisiti che impongono esplicitamente un monitoraggio integrato nelle operazioni ordinarie. ## Come si colloca rispetto ad altri standard I team confondono spesso PCI DSS con ISO 27001. Si sovrappongono ma rispondono a domande diverse. ISO 27001 certifica che gestisci un sistema di gestione della sicurezza delle informazioni; PCI DSS convalida che un insieme di controlli specifico e prescritto protegge i dati dei titolari di carta. Uno è una certificazione di sistema di gestione il cui perimetro definisci tu stesso; l'altro è un insieme di controlli fisso imposto da un organismo di settore esterno. Gestire un SGSI ISO 27001 ti offre un'impalcatura di governance che facilita la produzione delle evidenze PCI, ma non sostituisce i requisiti specifici per i dati delle carte. **PCI DSS a confronto con ISO 27001** | Dimensione | PCI DSS | ISO 27001 | | --- | --- | --- | | Natura | Standard contrattuale di settore | Standard internazionale certificabile | | Imposto da | I circuiti di carte tramite le banche acquirer | Adottato volontariamente dall'organizzazione | | Perimetro | Ambiente dei dati dei titolari di carta (focus fisso) | Ciò che l'organizzazione definisce | | Insieme di controlli | Prescritto e verificabile | Guidato dal rischio, selezionato dall'organizzazione | | Esito | Attestation / Report on Compliance | Certificato accreditato | --- ## Patch management **URL:** https://cyberacademy.net/it/resources/encyclopedia/patch-management **Last reviewed:** 2026-06-24 Il patch management è il processo operativo che prende una correzione pubblicata e la applica sull'intero parco sistemi, entro un SLA definito, con verifica. Spesso è l'anello più debole: le patch di emergenza collidono con le finestre di cambiamento, la compatibilità dei vendor e le dipendenze da terze parti. L'audit chiede sempre l'SLA, l'elenco delle eccezioni e le metriche. ## Dalla correzione pubblicata al parco distribuito Il patch management è la disciplina operativa che colma il divario tra il momento in cui un fornitore pubblica una correzione e il momento in cui quella correzione viene effettivamente eseguita su ogni macchina interessata che possiede. Una patch può essere un aggiornamento di sicurezza, una correzione di bug o una revisione del firmware, e può applicarsi a sistemi operativi, applicazioni, hypervisor, apparati di rete, container o controllori industriali. Il processo raramente riguarda il singolo atto di installare un aggiornamento. Riguarda il farlo su scala, in un ordine controllato, senza compromettere i servizi che dipendono dai sistemi che vengono modificati. Per questo i team maturi lo trattano come un workflow definito anziché come una reazione improvvisata a ogni nuovo avviso. Un ciclo praticabile ha fasi riconoscibili. Si inventaria il parco per sapere di cosa si è responsabili, si acquisiscono e si classificano gli avvisi per capire quali patch contano, si testa in un ambiente rappresentativo, si distribuisce tramite la gestione dei cambiamenti secondo un accordo sul livello di servizio definito, e si verifica che la patch sia presente e che il sistema funzioni ancora. Ogni fase produce evidenze, e sono queste evidenze a trasformare un'intenzione ottimistica in un controllo verificabile. ## Perché è così spesso l'anello debole Sulla carta, il patch management sembra semplice. In pratica è il punto in cui i buoni programmi di sicurezza falliscono in silenzio. La shortDefinition nomina i soliti responsabili, e ognuno è una reale tensione operativa. Le patch d'emergenza arrivano fuori ciclo e si scontrano con le finestre di cambiamento che mantengono stabile la produzione, così la correzione urgente attende dietro al calendario. La compatibilità del fornitore significa che una patch per un componente può comprometterne un altro, ed è esattamente per questo che i test esistono e per cui i test richiedono un tempo di cui potrebbe non disporre durante un evento di sfruttamento attivo. Le dipendenze di terze parti e transitive nascondono codice interessato all'interno di prodotti che non ha scritto, così corregge una libreria solo per scoprire che una dozzina di applicazioni incorpora ancora la versione vulnerabile. Il risultato è un arretrato di sistemi che non possono essere corretti immediatamente e un insieme di scelte su quali rischi assumersi. È normale. Ciò che distingue un programma controllato da uno esposto è se quelle scelte sono deliberate, documentate e limitate nel tempo, oppure se sono semplicemente cose di cui nessuno si è occupato. La copertura degli asset conta quanto la rapidità di correzione: un server non corretto di cui aveva dimenticato il possesso è più pericoloso di uno noto che ha deciso di rinviare. > **L'eccezione è il controllo** Quando un sistema non può essere corretto nei tempi, la risposta non è il silenzio. È un'eccezione registrata con una giustificazione di business, un controllo compensativo, un responsabile e una data di scadenza. Un elenco di eccezioni che viene riesaminato è buona gestione del rischio. Un arretrato che nessuno traccia non è altro che esposizione non gestita che porta una scadenza già superata. ## Patch management contro vulnerability management Questi due termini viaggiano insieme e vengono spesso confusi, ma rispondono a domande diverse. Il vulnerability management riguarda il sapere: scoprire le debolezze in tutto il parco, valutarle e prioritizzarle per rischio, e decidere cosa fare. Il patch management riguarda l'agire: è una delle vie di remediation che chiude una vulnerabilità, accanto alle modifiche di configurazione, alle mitigazioni e al virtual patching. Non ogni vulnerabilità si corregge con una patch, e non ogni patch chiude una vulnerabilità di sicurezza, così i due processi si sovrappongono senza essere la stessa cosa. **Patch management vs vulnerability management** | Dimensione | Patch management | Vulnerability management | | --- | --- | --- | | Domanda centrale | La correzione è distribuita ovunque dovrebbe esserlo? | Quali debolezze abbiamo e quali contano di più? | | Input principale | Patch e aggiornamenti dei fornitori | Scansioni, avvisi, threat intelligence, contesto degli asset | | Output principale | Sistemi corretti e verificati secondo un SLA | Un arretrato di remediation prioritizzato e classificato per rischio | | Ambito | Remediation tramite l'applicazione di aggiornamenti | Scoperta, valutazione, prioritizzazione e supervisione della remediation | In un programma sano si alimentano a vicenda. Il vulnerability management le dice quali patch meritano di saltare la coda, e il patch management riferisce quali correzioni sono state effettivamente distribuite, così che la scansione successiva dovrebbe risultare pulita. Quando vengono eseguiti come silos separati, le vulnerabilità vengono classificate in report che nessun processo di distribuzione consuma. ## Cosa chiederanno un auditor e un regolatore Il patch management è uno dei controlli operativi più direttamente esaminati perché l'evidenza è concreta. Sostiene obiettivi di controllo nell'ambito di un sistema di gestione della sicurezza delle informazioni ISO/IEC 27001, in particolare quelli che coprono le vulnerabilità tecniche e la gestione dei cambiamenti, e sottende le aspettative di configurazione sicura e manutenzione integrate in framework come il NIST Cybersecurity Framework e in insiemi di controlli come i CIS Controls. Regolamenti tra cui NIS2 e DORA presuppongono che un'organizzazione possa dimostrare una remediation tempestiva delle debolezze note, e il patch management è il modo in cui tale dimostrazione viene fatta. Le domande sono prevedibili, ed è per questo che la shortDefinition le elenca. Si aspetti di mostrare la policy di patching e lo SLA che definisce con quale rapidità i diversi livelli di gravità devono essere distribuiti, l'elenco delle eccezioni con giustificazioni e responsabili, e le metriche che dimostrano che il processo funziona: percentuale di asset corretti entro lo SLA, tempo medio di correzione, anzianità dell'eccezione aperta più vecchia, e copertura dell'inventario degli asset. Se può produrle senza affannarsi, il suo programma è reale. Se non può, l'audit avrà trovato l'anello debole prima di qualsiasi attaccante. --- ## Penetration testing **URL:** https://cyberacademy.net/it/resources/encyclopedia/penetration-testing **Last reviewed:** 2026-06-24 Un penetration test è una simulazione di attacco autorizzata e perimetrata, finalizzata a individuare vulnerabilità sfruttabili prima che lo facciano attaccanti reali. Black box / grey box / white box, interno / esterno, applicativo / infrastrutturale. Da distinguere dalla vulnerability scan (automatizzata, in ampiezza) e dal red team (plurimensile, basato su obiettivi). I report alimentano il backlog di remediation. ## Che cos'è davvero un penetration test Un penetration test è un tentativo deliberato e autorizzato di introdursi in un sistema come farebbe un vero attaccante, condotto nell'ambito di un perimetro scritto e di regole di ingaggio. Lo scopo non è elencare debolezze teoriche, ma dimostrare quali possano essere realmente concatenate per raggiungere qualcosa che conta: un database, un account di amministrazione, un record cliente, un flusso di pagamento. Il tester segue lo stesso percorso di un intruso, ma con il permesso e un confine definito, così che l'organizzazione scopra dove cederebbe prima che lo faccia qualcuno di ostile. È l'autorizzazione a separare un penetration test da un reato; senza un perimetro firmato, le stesse azioni sono semplicemente un'intrusione. Le attività vengono inquadrate lungo alcuni assi che il perimetro deve fissare in anticipo. Il livello di conoscenza va dalla scatola nera, in cui il tester parte da nient'altro che un nome o un intervallo di indirizzi IP, attraverso la scatola grigia, in cui ottiene un account a privilegi ridotti o documentazione parziale, fino alla scatola bianca, in cui riceve il codice sorgente, i diagrammi di architettura e credenziali complete. Il punto di osservazione è esterno, simulando un attaccante su Internet, oppure interno, simulando qualcuno già penetrato nella rete o un insider malevolo. Il tipo di bersaglio distingue il test applicativo, che sonda un'applicazione web o mobile e la sua logica, dal test infrastrutturale, che si rivolge a host, servizi e configurazione di rete. La maggior parte dei programmi reali combina questi approcci per allinearsi alle minacce che realmente li preoccupano. ## In che cosa differisce da una scansione e da un red team La confusione più comune è tra un penetration test e una scansione delle vulnerabilità, e le due cose non sono uguali. Una scansione delle vulnerabilità è automatizzata e ottimizzata per l'ampiezza: uno strumento passa in rassegna ogni asset raggiungibile, confronta ciò che trova con un database di problemi noti e produce un lungo elenco. È veloce, ripetibile ed economica, ma non può dirti se un dato risultato sia realmente sfruttabile nel tuo ambiente o un falso positivo. Un penetration test è guidato da un essere umano e ottimizzato per la profondità: il tester convalida i risultati sfruttandoli davvero, concatena diversi problemi di gravità minore in una compromissione reale e mette alla prova la logica di business e le ipotesi di fiducia che nessuno scanner comprende. La scansione ti dice cosa potrebbe non andare; il penetration test ti dice cosa potrebbe davvero farne un attaccante. All'altro estremo si colloca il red team, anch'esso spesso confuso con il penetration test. Un'attività di red team è più lunga, spesso si protrae per mesi, ed è orientata all'obiettivo anziché alla copertura: la meta è raggiungere un risultato specifico, come esfiltrare un insieme di dati definito o arrivare a un determinato sistema, restando inosservati e verificando se i difensori se ne accorgono e reagiscono. Un penetration test punta alla copertura entro un perimetro ed è di solito noto ai team interessati; un red team punta a un singolo obiettivo in profondità e mette alla prova deliberatamente il rilevamento e la risposta quanto i controlli stessi. **Il penetration test a confronto con una scansione delle vulnerabilità e un red team** | Dimensione | Scansione delle vulnerabilità | Penetration test | Red team | | --- | --- | --- | --- | | Metodo | Strumenti automatizzati | Guidato da un essere umano, pratico | Guidato da un essere umano, emulazione dell'avversario | | Meta | Ampiezza: elencare i problemi noti | Profondità: dimostrare la sfruttabilità nel perimetro | Obiettivo: raggiungere un bersaglio definito | | Convalida | Nessuno sfruttamento | Risultati sfruttati e concatenati | Catena d'attacco completa fino all'obiettivo | | Rilevamento testato | No | Di solito no | Sì, mette alla prova direttamente i difensori | | Durata tipica | Da minuti a ore | Da giorni a settimane | Da settimane a mesi | ## Quale posto occupa in un programma di sicurezza Un penetration test è una verifica puntuale, non un controllo di per sé. Il suo vero valore si realizza dopo l'attività, quando il report alimenta la coda di remediation. Un buon report fa molto di più che elencare i risultati: li ordina per sfruttabilità e impatto sul business, fornisce prove riproducibili e raccomanda correzioni. Quei risultati diventano ticket, responsabili e scadenze all'interno del più ampio processo di gestione delle vulnerabilità, e un nuovo test conferma che le correzioni hanno davvero chiuso le falle anziché spostarle. Senza questo seguito, un test è solo un documento costoso. Il penetration test compare anche esplicitamente nelle norme e nella regolamentazione. Un sistema di gestione della sicurezza delle informazioni allineato a ISO/IEC 27001 considera i test tecnici come un modo per verificare che i controlli funzionino nella pratica, e i framework relativi ai pagamenti, alle infrastrutture critiche e ai servizi finanziari si aspettano sempre più test regolari e delimitati dei sistemi esposti a Internet e critici. ENISA e agenzie nazionali come ANSSI pubblicano linee guida su come commissionare i test in modo responsabile, e l'insieme delle competenze offensive è formalizzato in certificazioni per hacker etici. Ciò che i professionisti consegnano realmente è un ritmo ricorrente: delimitare l'attività, concordare le regole di ingaggio e un'autorizzazione scritta, testare, riferire, rimediare, ritestare e ripetere via via che l'ambiente cambia. > **Un test è l'inizio del lavoro, non la fine** Il deliverable che conta non è il report, ma ciò che accade dopo. I risultati ordinati e sfruttabili diventano ticket assegnati nella coda di remediation, e un nuovo test dimostra che sono stati davvero chiusi. Un penetration test senza un ciclo di remediation alle spalle infonde una fiducia che non si è guadagnata. --- ## Phishing **URL:** https://cyberacademy.net/it/resources/encyclopedia/phishing **Last reviewed:** 2026-06-24 Il phishing è l'attacco di social engineering che induce un utente a cliccare su un link malevolo, aprire un file malevolo o rivelare le proprie credenziali. Varianti: spear phishing (mirato), whaling (dirigenti), smishing (SMS), vishing (voce), BEC (business email compromise). La formazione è essenziale; l'MFA resistente al phishing lo è ancora di più. ## Perché il phishing resta il principale punto di ingresso Il phishing persiste perché attacca la persona, non il perimetro. Tutti gli altri controlli possono essere configurati alla perfezione e all'attaccante serve comunque solo un dipendente che clicchi su un link, apra un file o digiti una password in un falso convincente. Il messaggio arriva attraverso un canale fidato, di solito l'email ma sempre più SMS e voce, e prende l'aspetto e il tono di un marchio, di un collega o di un sistema interno da cui la vittima si aspetta già di ricevere notizie. Poiché il payload spesso risiede dietro un dominio appena registrato o una pagina di accesso cloud dall'aspetto legittimo, i filtri basati sulle firme e le liste di reputazione arrivano spesso troppo tardi. Anche l'economia favorisce l'attaccante: un singolo modello può essere diffuso a migliaia di destinatari a costo quasi nullo, e un singolo successo può fornire credenziali che sbloccano tutto il resto. Ciò che i professionisti osservano è il passaggio dal volume alla precisione. Il phishing di massa è una rete ampia, ma gli incidenti costosi di solito iniziano con un messaggio su misura che ha chiaramente fatto i compiti su bersaglio, organigramma e momento. ## Le varianti che contano nella pratica Il phishing è una famiglia, non un'unica tecnica. La logica dell'ingegneria sociale resta costante mentre il canale e il bersaglio cambiano. - Spear phishing: un messaggio mirato costruito per una persona o un team specifici, che usa nomi, progetti e contesto reali per abbassare il sospetto. - Whaling: spear phishing rivolto a dirigenti e altri approvatori di alto valore, dove un singolo account compromesso porta un'autorità sproporzionata. - Smishing: phishing veicolato via SMS, spesso un falso avviso di consegna, di banca o di reimpostazione MFA che sfrutta lo schermo più piccolo e l'abitudine di fidarsi dei messaggi di testo. - Vishing: phishing tramite chiamata vocale, dove un attaccante mette sotto pressione la vittima in tempo reale, sempre più aiutato da numeri falsificati e audio sintetico. - Business email compromise: un sottotipo di pretexting che colpisce direttamente i processi di pagamento e dei dati, di solito senza alcun link o allegato malevolo. ## Ciò che riduce davvero il rischio La formazione di sensibilizzazione è necessaria ma non sufficiente. Le persone cliccheranno sempre in una certa percentuale dei casi, quindi l'obiettivo è eliminare il valore di un clic piuttosto che esigere la perfezione dagli utenti. Il controllo tecnico decisivo è l'autenticazione a più fattori resistente al phishing, ovvero fattori legati al dominio legittimo, come le chiavi di sicurezza FIDO2 o le passkey, che una pagina di accesso falsa non può riprodurre. A valle si collocano, a strati, i controlli che intercettano ciò che sfugge. - MFA resistente al phishing su ogni account che conta, in modo che una password sottratta da sola non basti per accedere. - Autenticazione dell'email con SPF, DKIM e DMARC per aumentare il costo dello spoofing di dominio, abbinata a un gateway email sicuro e alla riscrittura dei link o al sandboxing. - Formazione di sensibilizzazione continua e basata su scenari, con phishing simulato, misurata per migliorare nel tempo anziché per punire i singoli. - Un pulsante di segnalazione senza attriti e un processo di risposta rapido, perché le persone che segnalano sono il sistema di allerta precoce per quelle che hanno cliccato. > **Forma l'essere umano, ma elimina il clic per progettazione** La sensibilizzazione abbassa il tasso di clic; non arriva mai a zero. La MFA resistente al phishing legata al dominio reale è ciò che impedisce a una credenziale rubata di trasformarsi in un'appropriazione dell'account. Tratta la formazione come uno strato, non come il controllo. ## Dove si colloca il phishing nelle norme e nella regolamentazione Il phishing rientra pienamente nell'ambito di un sistema di gestione della sicurezza delle informazioni. Nell'ambito di un SGSI ISO/IEC 27001 il trattamento pertinente combina formazione di sensibilizzazione, controllo degli accessi e i controlli tecnici di email e autenticazione, tutti selezionati attraverso la valutazione del rischio anziché aggiunti per riflesso. Gli orientamenti europei di ENISA e delle autorità nazionali come ANSSI collocano sistematicamente il phishing tra le principali tecniche di accesso iniziale e pubblicano contromisure pratiche. Quando un phishing riuscito espone dati personali, per esempio attraverso una casella di posta compromessa, può anche far scattare gli obblighi di violazione dei dati personali ai sensi del GDPR, il che significa che il legale e la funzione di protezione dei dati devono rientrare nel piano di risposta, accanto a IT e sicurezza. Per i professionisti la lezione è che la difesa dal phishing è stratificata e condivisa. Nessun singolo strumento o campagna di sensibilizzazione la chiude da solo. La postura duratura combina persone, processi e progettazione dell'autenticazione in modo che un clic, che prima o poi avverrà, non diventi una violazione. --- ## Privacy by design e by default **URL:** https://cyberacademy.net/it/resources/encyclopedia/privacy-by-design **Last reviewed:** 2026-06-24 La privacy by design (GDPR Articolo 25) è l'obbligo di integrare le misure di protezione dei dati nei sistemi fin dalla fase dei requisiti. La privacy by default è l'obbligo di rendere l'opzione con il livello di protezione più elevato quella standard. Gli auditor cercano prove documentate (DPIA, design review, impostazioni di conservazione predefinite) piuttosto che uno slogan in una policy. ## Due obblighi, non uno La privacy by design e la privacy by default sono formulate come un unico obbligo del GDPR, ma richiedono due cose diverse, e i professionisti finiscono nei guai quando le confondono. By design significa che i controlli sulla privacy vengono integrati in un sistema fin dalla fase dei requisiti, prima che venga scritta una riga di codice o che venga scelto un fornitore, anziché aggiunti una volta che cominciano ad arrivare le richieste di accesso degli interessati. By default significa che quando un utente non fa nulla, il sistema si trova già nella sua impostazione più protettiva: la raccolta dei dati più ridotta, la conservazione più breve, la condivisione più rigorosa. Uno riguarda come costruisci; l'altro ciò che il sistema fa il primo giorno, senza alcuna configurazione. La distinzione conta perché un team può soddisfare l'uno e mancare l'altro. Puoi condurre una revisione di progettazione approfondita, documentare una DPIA, e comunque rilasciare un prodotto i cui interruttori predefiniti sono tutti impostati sulla massima condivisione perché è ciò che ha chiesto il team di crescita. Quel prodotto è privacy by design ma non by default, e non è conforme. Accade anche il contrario: un'impostazione predefinita prudente aggiunta a un sistema che non è mai stato valutato lascia il titolare del trattamento incapace di dimostrare come sia stata fatta la scelta. ## Cosa cambia davvero nella pratica Il cambiamento pratico consiste nello spostare la privacy a monte. Anziché far esaminare al legale una funzionalità finita, i requisiti di privacy diventano vincoli di progettazione che ingegneria e prodotto portano avanti fin dal primo sprint. La minimizzazione dei dati smette di essere uno slogan e diventa una domanda posta per ogni campo di ogni modulo: ci serve questo per erogare il servizio, e se no, perché è qui. La limitazione della finalità diventa un vincolo su ciò per cui un insieme di dati potrà essere successivamente riutilizzato. La conservazione diventa un calendario predefinito che il sistema impone, non una pulizia manuale che nessuno si ricorda di eseguire. - Raccogli il minimo dei campi di cui il servizio ha realmente bisogno, e giustifica ciascuno di essi. - Imposta i periodi di conservazione come valori predefiniti imposti, con cancellazione o anonimizzazione automatica alla loro scadenza. - Imposta i valori predefiniti di condivisione, visibilità e profilazione sull'opzione meno permissiva, lasciando che l'utente scelga di autorizzarne di più. - Applica la pseudonimizzazione e la cifratura come scelte architetturali standard anziché come eccezioni. - Delimita l'accesso ai dati personali per finalità, così che un sistema esponga solo ciò che una determinata funzione richiede. > **Gli auditor vogliono prove, non uno slogan** Una riga in un'informativa sulla privacy che afferma che pratichi la privacy by design non prova nulla. Ciò che regge all'esame sono prove documentate che l'obbligo è stato adempiuto: una DPIA per i trattamenti a rischio più elevato, verbali di revisione della progettazione che mostrano che la privacy è stata considerata prima della costruzione, e l'effettiva configurazione predefinita del sistema in produzione. Se non puoi mostrare l'artefatto, l'auditor considera il controllo come assente. ## Come si colloca rispetto ai concetti vicini La privacy by design si comprende più facilmente per contrasto con ciò con cui le persone la confondono. Non è la stessa cosa di una DPIA, che è un elemento di prova del fatto che l'obbligo più ampio è stato adempiuto per una specifica attività di trattamento a rischio più elevato. Non è la security by design, che protegge i dati dagli attaccanti indipendentemente dal fatto che quei dati avrebbero dovuto essere raccolti; la privacy by design parte un passo prima, mettendo in discussione la raccolta stessa. E non è un controllo una tantum. Poiché i sistemi evolvono, l'obbligo è continuo: ogni nuova funzionalità, integrazione o flusso di dati riapre le stesse domande su minimizzazione, finalità e impostazioni predefinite. In un programma maturo la privacy by design diventa un'abitudine radicata nel ciclo di vita dello sviluppo anziché un checkpoint in capo al legale. Prodotto e ingegneria sollevano le domande da soli, la DPIA viene attivata automaticamente quando il trattamento supera una soglia di rischio, e la configurazione predefinita viene esaminata come parte del rilascio anziché scoperta in produzione. Questa è la differenza tra un'organizzazione che può dimostrare il principio e una che si limita ad affermarlo. --- ## Privileged Access Management (PAM) **URL:** https://cyberacademy.net/it/resources/encyclopedia/pam **Last reviewed:** 2026-06-24 PAM è il sottoinsieme di IAM focalizzato sugli account privilegiati: amministratori, root, account di servizio, break-glass. Conserva le credenziali in vault, intermedia le sessioni, registra l'attività. È il primo obiettivo dell'attaccante dopo l'accesso iniziale, e il controllo che gli auditor verificano con maggiore rigore nell'ambito di NIS 2 e DORA. ## Perché gli account privilegiati sono un problema a sé Ogni programma di gestione delle identità inizia dagli utenti ordinari: chi sono, cosa possono aprire, come si autenticano. La gestione degli accessi privilegiati (PAM) si occupa degli account che si collocano al di sopra di quel livello. Amministratori di dominio, account root e di amministratore locale, proprietari di database, console di hypervisor, identità root nel cloud, account di servizio che vengono eseguiti senza supervisione e gli account di emergenza tenuti per le situazioni critiche. Queste identità possono modificare la configurazione, leggere o distruggere dati, disabilitare la registrazione e creare nuovi account. Il raggio d'impatto di una singola credenziale di amministratore compromessa è l'intero ambiente, ed è per questo che il PAM è trattato come una disciplina a sé stante anziché come una funzionalità dell'IAM generale. Il gesto distintivo del PAM consiste nello smettere di considerare le credenziali privilegiate come qualcosa che una persona semplicemente conosce. Al contrario, il segreto risiede in una cassaforte, l'accesso viene richiesto e approvato, la sessione viene mediata attraverso un gateway controllato e tutto ciò che l'utente privilegiato fa viene registrato. L'essere umano spesso non vede mai la password. Questa separazione tra l'operatore e il segreto è ciò che rende l'attività privilegiata verificabile e revocabile. ## Cosa controlla davvero un programma PAM In pratica, un'implementazione PAM matura combina diversi meccanismi che corrispondono direttamente a ciò che gli auditor si aspettano di vedere: - Custodia delle credenziali in cassaforte: le password privilegiate, le chiavi SSH e i segreti API sono archiviati in modo centralizzato, ruotati automaticamente e mai incorporati in script o file di configurazione. - Mediazione e registrazione delle sessioni: gli amministratori si connettono tramite un proxy che inietta la credenziale, in modo che la sessione possa essere monitorata, registrata e terminata senza che l'operatore detenga mai il segreto. - Elevazione just-in-time: i diritti vengono concessi per un compito definito e una finestra definita, poi revocati, anziché lasciati assegnati all'account in modo permanente. - Procedure di emergenza (break-glass): gli account di emergenza sono sigillati, dotati di allarme e riesaminati dopo ogni utilizzo, in modo da esistere per i guasti reali senza diventare una backdoor silenziosa. - Individuazione e responsabilità: lo strumento individua gli account privilegiati e di servizio in tutto il parco e ricollega ogni azione privilegiata a una persona identificata per nome. > **Il PAM è un controllo, non un prodotto** Acquistare una cassaforte non significa realizzare il PAM. Il controllo è la combinazione di un inventario pulito degli account privilegiati, un flusso di approvazione, la rotazione, la registrazione delle sessioni e il riesame. Lo strumento applica una policy che dovete comunque scrivere. **Il PAM a confronto con l'IAM generale** | Dimensione | IAM generale | PAM | | --- | --- | --- | | Ambito | Tutte le identità e tutti gli accessi | Solo account privilegiati (admin, root, servizio, break-glass) | | Domanda centrale | Questa persona dovrebbe avere accesso? | Come viene custodito in cassaforte, mediato e registrato questo accesso elevato? | | Gestione delle credenziali | L'utente si autentica con la propria credenziale | Il segreto viene custodito in cassaforte e iniettato; l'operatore può non vederlo mai | | Postura predefinita | Autorizzazioni persistenti gestite nel tempo | Just-in-time, limitato nel tempo, revocato dopo l'uso | | Focus dell'audit | Riesami degli accessi e processo di ingresso-trasferimento-uscita | Registrazione delle sessioni, rotazione, riesame degli account di emergenza | ## Dove si colloca il PAM nell'IAM e nel quadro normativo Il PAM è un sottoinsieme della gestione delle identità e degli accessi, ristretto agli account che comportano il rischio maggiore, ed è la punta avanzata del principio del privilegio minimo. L'IAM generale si chiede se una persona dovrebbe avere accesso del tutto. Il PAM presuppone che l'accesso sia legittimo, ma insiste affinché sia temporaneo, mediato, registrato e reversibile. Gli aggressori comprendono questa gerarchia: dopo un primo punto d'appoggio tramite phishing o un servizio esposto, l'obiettivo successivo è scalare verso un account privilegiato, perché è ciò che trasforma un singolo host nel controllo del dominio. Anche le autorità di vigilanza lo sanno. Ai sensi della Direttiva NIS 2, il controllo degli accessi e la gestione degli account privilegiati rientrano pienamente nelle misure di gestione del rischio di cybersicurezza che i soggetti essenziali e importanti devono attuare. Il Regolamento sulla resilienza operativa digitale (DORA) fissa aspettative analoghe per il settore finanziario, dove l'autenticazione forte e il controllo rigoroso degli accessi privilegiati fanno parte del quadro di gestione del rischio ICT. L'Allegato A della norma ISO/IEC 27001 affronta i diritti di accesso privilegiato e la gestione delle informazioni segrete di autenticazione come controlli nominati. In un audit, l'accesso privilegiato è costantemente una delle aree esaminate con maggiore severità, perché un controllo debole in questo punto compromette ogni altra salvaguardia. ## Modalità di fallimento comuni I programmi PAM falliscono in modi prevedibili. Account di servizio con password senza scadenza codificate direttamente nell'automazione. Account amministratore condivisi in cui nessuno può dire chi ha agito. Diritti di amministratore locale permanenti su ogni postazione di lavoro. Un'adozione della cassaforte che copre gli amministratori interattivi ma lascia intatte le identità macchina. La disciplina vale solo quanto la sua copertura, perciò il lavoro concreto è l'individuazione continua e la costante rimozione del privilegio permanente, non un singolo rilascio. --- ## Professional Evaluation and Certification Board (PECB) **URL:** https://cyberacademy.net/it/resources/encyclopedia/pecb **Last reviewed:** 2026-06-24 PECB è l'organismo di certificazione accreditato con sede a Montreal che rilascia credenziali professionali su 30+ standard ISO in 150+ paesi. Sicurezza delle informazioni, rischio, BCM, governance dell'IA, privacy, qualità. Cyber Academy è PECB Gold Partner. Le credenziali recano il marchio PECB; i corsi si svolgono tramite partner accreditati. ## Che cos'è realmente PECB PECB (il Professional Evaluation and Certification Board) è un organismo di certificazione delle persone. Non certifica la vostra azienda rispetto a ISO 27001; questo è il compito di un organismo di certificazione accreditato che audita il vostro sistema di gestione. PECB certifica le persone. Quando un professionista completa un corso e supera l'esame, PECB rilascia una credenziale individuale che attesta che quella persona ha dimostrato competenza rispetto a uno schema definito su una norma specifica. Il catalogo è ampio perché il portafoglio ISO è ampio. Gli schemi PECB coprono la sicurezza delle informazioni, la gestione del rischio, la continuità operativa, la privacy e la protezione dei dati, la governance dell'IA e la qualità, tra gli altri. Questa ampiezza è proprio l'obiettivo: un professionista può costruire un percorso di credenziali coerente all'interno di un unico organismo emittente anziché collezionare badge da una dozzina di fonti. > **Organismo contro partner** PECB è proprietario dello schema, dell'esame e del certificato. La formazione è erogata da partner accreditati che gestiscono le edizioni. La credenziale porta il marchio PECB; l'esperienza in aula porta quella del partner. Cyber Academy è PECB Gold Partner, ovvero il lato erogazione di questo accordo. ## Come sono strutturate le credenziali Gli schemi PECB sono solitamente legati a una norma specifica e a un ruolo specifico. Le combinazioni più note sono Lead Implementer, per la persona che costruisce e gestisce un sistema di gestione, e Lead Auditor, per la persona che lo audita. Entrambe esistono per ISO 27001 e per altre norme certificabili come ISO 22301 per la continuità operativa e ISO 42001 per i sistemi di gestione dell'IA. Al di sotto si collocano le credenziali di livello Foundation, che stabiliscono il vocabolario e i principi prima che un professionista si impegni nel percorso completo di implementatore o auditor. La distinzione tra i due percorsi senior conta più di quanto suggerisca l'etichetta comune «Lead». Un Lead Implementer pianifica il perimetro, redige le politiche, guida la Dichiarazione di applicabilità e gestisce i controlli. Un Lead Auditor lavora dall'altro lato: pianificare gli audit, campionare le evidenze, condurre interviste e riferire i rilievi rispetto a una norma. Sono discipline complementari, e molti professionisti possiedono entrambe perché gestire bene un sistema di gestione e auditarlo richiedono capacità diverse. Una credenziale non è la stessa cosa della norma sottostante. ISO 27001 è il quadro rispetto al quale un'organizzazione viene certificata. La credenziale PECB è la prova che una persona specifica è stata valutata rispetto a uno schema di competenza costruito su quel quadro. Confondere le due cose è l'errore più comune che commettono i nuovi arrivati. ## Dove si colloca PECB tra gli organismi di certificazione Diverse organizzazioni rilasciano credenziali per le persone allineate a ISO, e un datore di lavoro raramente si preoccupa dell'organismo emittente in astratto. Ciò che conta è la norma dietro la credenziale e se lo schema di certificazione è accreditato. PECB si posiziona come un organismo accreditato che opera a livello internazionale, il che conferisce al certificato la portabilità oltre confine e il riconoscimento da parte di datori di lavoro che non conoscono il fornitore di formazione. Per un professionista che sceglie un percorso, le domande pratiche sono: con quale norma devo lavorare, questo schema copre il ruolo che voglio, e la credenziale è riconosciuta dove intendo esercitare. Il marchio emittente è la risposta al riconoscimento; la norma e il ruolo rispondono al resto. --- ## Propensione al rischio **URL:** https://cyberacademy.net/it/resources/encyclopedia/risk-appetite **Last reviewed:** 2026-06-24 La propensione al rischio è la quantità e la tipologia di rischio che l'organizzazione è disposta ad accettare per raggiungere i propri obiettivi. Definita a livello esecutivo o dal consiglio di amministrazione, per iscritto. In sua assenza, ogni decisione di trattamento del rischio diventa un giudizio personale del team di rischio, e l'audit la smonta pezzo per pezzo. Da abbinare alla tolleranza al rischio (lo scostamento tollerato rispetto alla propensione). ## A cosa serve la propensione al rischio La propensione al rischio esiste per dirimere una discussione prima che si verifichi. Ogni decisione di trattamento, ogni « lo correggiamo o ci conviviamo », è in realtà una domanda su quanto rischio l'organizzazione è disposta a sostenere a fronte del beneficio di perseguire i propri obiettivi. Se quel confine risiede solo nella testa di chi guida il programma, allora ogni decisione diventa un giudizio privato che nessun altro ha sottoscritto, ed è esattamente ciò che un auditor o una contestazione del consiglio andrà a smontare. Una propensione scritta, assunta a livello dirigenziale o del consiglio, trasforma quei giudizi sparsi in una posizione organizzativa dichiarata. È uno strumento di governo, non scartoffie: indica al team di rischio dove può procedere di propria autorità e dove un rischio deve essere escalato. Punto cruciale: la propensione si definisce nel linguaggio degli obiettivi, non come un numero unico. Un'organizzazione che insegue una crescita aggressiva in un nuovo mercato accetterà razionalmente più rischio strategico e operativo di un'altra il cui mandato è proteggere un servizio regolamentato e critico per la vita. Il consiglio decide quanta esposizione è disposto a consentire per raggiungere ciò che intende ottenere. Per questo la propensione non può essere delegata alla funzione sicurezza o rischio perché la inventi da sola: è una dichiarazione di intenti che solo coloro che rispondono degli obiettivi possono formulare legittimamente. ## Propensione, tolleranza e capacità Questi tre concetti vengono costantemente confusi, e la confusione costa cara. La propensione è quanto rischio vuoi assumere nel perseguimento degli obiettivi. La tolleranza è lo scostamento che sei disposto ad accettare attorno a quella propensione prima di agire, la banda pratica su entrambi i lati dell'obiettivo. La capacità è il massimo assoluto che l'organizzazione potrebbe assorbire prima che la sua sopravvivenza sia minacciata, indipendentemente da ciò che vuole. Fissi la propensione al di sotto della capacità di proposito, lasciando margine, ed esprimi la tolleranza affinché la variazione quotidiana non scateni una riunione di crisi ogni volta. **Propensione, tolleranza e capacità in sintesi** | Concetto | Domanda a cui risponde | Chi ne è responsabile | | --- | --- | --- | | Propensione al rischio | Quanto rischio vogliamo assumere per raggiungere i nostri obiettivi? | Consiglio / dirigenza | | Tolleranza al rischio | Quanto scostamento attorno a quella propensione accetteremo prima di agire? | Dirigenza / titolari del rischio | | Capacità di rischio | Qual è il massimo che potremmo assorbire prima che la sopravvivenza sia in gioco? | Consiglio (un limite rigido) | > **Una propensione senza tolleranza è inattuabile** Una dichiarazione di propensione nuda, senza banda di tolleranza, costringe il team a trattare ogni minimo scostamento come una violazione. Abbina la propensione a una tolleranza dichiarata affinché la normale fluttuazione venga assorbita e solo una deriva reale venga escalata. Senza di essa, la dichiarazione viene o ignorata o genera rumore. ## Come si manifesta negli standard Nella ISO 31000, la propensione al rischio fa parte del quadro di riferimento che la leadership stabilisce quando si impegna a gestire il rischio: l'alta direzione e gli organi di vigilanza sono tenuti a definire e comunicare quanto rischio l'organizzazione è disposta ad assumere. ISO 27005 e il sistema di gestione della sicurezza delle informazioni ISO 27001 poggiano sulla stessa idea attraverso i criteri di rischio: prima di poter valutare un rischio, servono criteri concordati su ciò che è accettabile, e quei criteri sono la propensione resa operativa. La propensione è a monte della valutazione, e i criteri sono il modo in cui essa viene applicata in modo coerente a ogni rischio. La propensione non è un poster appeso al muro. Si guadagna il suo posto solo quando è integrata nel resto del ciclo. La fase di valutazione del rischio confronta ogni rischio analizzato con i criteri derivati dalla propensione per decidere se è necessaria un'azione. La decisione di trattamento del rischio, evitare, ridurre, trasferire o accettare, si giustifica con riferimento ad essa: un rischio accettato entro la propensione richiede solo un'accettazione documentata e autorizzata, mentre un rischio al di sopra della propensione esige un trattamento o un'approvazione formale ed escalata. Il registro dei rischi annota dove si colloca ciascuna voce rispetto alla propensione e chi ha accettato cosa. Quando gli auditor trovano decisioni di trattamento che nessuno riesce a ricondurre a una propensione dichiarata, è quella la lacuna che fa crollare l'intera valutazione. In pratica, la propensione si rivede, non è scolpita nella pietra. Viene riesaminata man mano che gli obiettivi cambiano, dopo incidenti rilevanti e attraverso il riesame della direzione, perché una propensione fissata per la strategia dell'anno scorso indirizza silenziosamente in modo errato le decisioni di quest'anno. La disciplina consiste nel tenerla esplicita, tenerla assunta ai vertici e tenerla connessa ai criteri che il team utilizza davvero. --- ## Pseudonimizzazione **URL:** https://cyberacademy.net/it/resources/encyclopedia/pseudonymisation **Last reviewed:** 2026-06-24 La pseudonimizzazione è la tecnica definita dall'articolo 4(5) del GDPR che consiste nel sostituire gli identificatori diretti con token reversibili, conservando la chiave separatamente. Riduce il rischio e favorisce un atteggiamento positivo da parte delle autorità di controllo, ma il dato rimane un dato personale. L'anonimizzazione è la tecnica che consente di uscire completamente dal perimetro del GDPR; la pseudonimizzazione no. Attenzione alla confusione tra i due concetti. ## Cosa fa davvero la pseudonimizzazione La pseudonimizzazione è una tecnica di protezione dei dati, non uno stato che il dato raggiunge. Si prendono i campi che indicano direttamente una persona, il nome, l'indirizzo e-mail, il numero nazionale di identità, e li si sostituisce con un token: un identificativo casuale, un riferimento codificato, un valore cifrato. La corrispondenza che riconverte il token nell'identità reale, la chiave, è conservata separatamente e protetta con misure tecniche e organizzative proprie. Chiunque lavori con il set di dati pseudonimizzato può analizzarlo, condividerlo o eseguire test su di esso senza vedere a chi appartengono i record, mentre l'organizzazione conserva la capacità di reidentificare quando ha un motivo legittimo per farlo. Il GDPR nomina esplicitamente questa tecnica e la tratta come una garanzia raccomandata. Compare come modo per soddisfare la protezione dei dati fin dalla progettazione e per impostazione predefinita, come misura in grado di ridurre il rischio residuo di un trattamento, e come fattore che le autorità di controllo valutano favorevolmente quando stabiliscono se hai fatto abbastanza. Usarla è un segnale che hai preso sul serio la sicurezza e la minimizzazione. È la buona disposizione a cui rimanda la definizione breve, ed è reale, ma non cambia la natura giuridica del dato. ## La pseudonimizzazione non è anonimizzazione Questa è la confusione che mette nei guai le organizzazioni. Poiché un record pseudonimizzato non porta più un nome visibile, si presume che sia uscito dall'ambito del regolamento. Non lo è. La pseudonimizzazione è reversibile per progettazione: la chiave esiste, quindi il dato può essere ricollegato a una persona identificabile, quindi resta un dato personale e ogni obbligo continua ad applicarsi. L'anonimizzazione è il patto opposto. È irreversibile, il collegamento con l'individuo è distrutto in modo così completo che la reidentificazione non è più ragionevolmente possibile con alcun mezzo che si possa verosimilmente utilizzare, e solo allora il dato esce del tutto dal GDPR. **Pseudonimizzazione contro anonimizzazione** | Aspetto | Pseudonimizzazione | Anonimizzazione | | --- | --- | --- | | Reversibile | Sì, tramite la chiave conservata separatamente | No, il collegamento è distrutto | | Resta un dato personale | Sì | No | | Si applica il GDPR | Sì, integralmente | No | | Finalità tipica | Ridurre il rischio mantenendo utilità e reidentificazione | Far uscire il dato dall'ambito, spesso per la pubblicazione aperta | > **È la chiave a renderlo un dato personale** Finché la chiave o il metodo di reidentificazione esiste in qualche luogo a portata ragionevole, il dato è pseudonimizzato, non anonimizzato. È l'eliminazione della chiave, non il mascheramento del nome, a far superare la soglia verso l'anonimizzazione. Tratta con sospetto qualsiasi affermazione di anonimizzazione finché non puoi dimostrare che non esiste alcun percorso ragionevole di ritorno all'individuo. ## Cosa fanno davvero i professionisti In pratica la pseudonimizzazione è una disciplina di ingegneria e di governance più che un singolo interruttore. Lo scopo di separare la chiave è vanificato se lo stesso team, sistema o backup detiene sia i token sia la corrispondenza, quindi i controlli attorno alla chiave contano quanto la tokenizzazione stessa. - Sostituire gli identificatori diretti con token, usando metodi come l'hashing con chiave, la cifratura o una tabella di consultazione di riferimenti casuali. - Conservare la chiave di reidentificazione separatamente, sotto un controllo degli accessi più rigoroso rispetto al set di dati di lavoro, idealmente in capo a un team diverso. - Premunirsi contro la reidentificazione indiretta, in cui combinazioni rare dei campi restanti (un codice postale, più una data di nascita, più una qualifica professionale) permettono di isolare qualcuno anche senza nome. - Documentare la tecnica nel registro dei trattamenti e nella DPIA, e trattare il dato pseudonimizzato come dato personale ai fini della valutazione delle violazioni, della conservazione e dei diritti degli interessati. Fatta bene, la pseudonimizzazione consente ad analisi, ricerca e test software di operare su dati realistici riducendo al contempo il raggio d'impatto di una violazione, perché un attaccante che ottiene i token senza la chiave dispone di molto meno. Fatta con noncuranza, con la chiave raggiungibile o gli identificatori indiretti ignorati, offre l'apparenza della protezione senza la sostanza, e l'organizzazione si fa comunque carico di ogni obbligo che credeva di aver eluso. --- ## Ransomware **URL:** https://cyberacademy.net/it/resources/encyclopedia/ransomware **Last reviewed:** 2026-06-24 Il ransomware è la classe di malware che cifra i dati e richiede un pagamento per la chiave, spesso abbinata al furto di dati e all'estorsione (double extortion). Vettori di attacco: phishing, esposizione su sistemi internet-facing, supply chain. Le assicurazioni coprono meno, i regolatori controllano di più. L'esito dipende dal lavoro svolto prima dell'incidente (backup, segmentazione, piano IR), non dalla negoziazione. ## Cos'è davvero un ransomware, e perché la cifratura è la parte facile Un ransomware è un software malevolo che si impossessa di qualcosa di cui hai bisogno e ti costringe a pagare per riaverlo. Il meccanismo classico è la cifratura: il malware codifica i file sui sistemi che raggiunge e offre la chiave di decifratura in cambio di un pagamento, di solito in criptovaluta. Ma trattare il ransomware come un problema di cifratura ignora ciò che lo rende così dannoso. La cifratura è il sintomo visibile di un'intrusione che spesso è in corso da giorni o settimane. Prima che un solo file venga bloccato, un attaccante ha tipicamente ottenuto un accesso iniziale, elevato i privilegi, si è spostato lateralmente nella rete, ha individuato i sistemi che contano e, di frequente, ha copiato i dati all'esterno. Il blocco finale è semplicemente il momento in cui l'operatore decide di convertire quell'accesso in denaro. Questa sequenza spiega perché i peggiori incidenti ransomware non riguardano più soltanto file cifrati. Gli operatori hanno capito che una vittima con buoni backup poteva rifiutarsi di pagare e ripristinare, perciò hanno aggiunto una seconda leva: rubare prima i dati e poi minacciare di pubblicarli. Questa è la doppia estorsione, e cambia completamente il calcolo. Persino un'organizzazione che ripristina in modo pulito da un backup affronta comunque la prospettiva che dati riservati, archivi clienti o contratti vengano divulgati su un sito pubblico. Alcuni gruppi si spingono oltre con pressioni aggiuntive, contattando direttamente clienti o autorità di regolamentazione, oppure aggiungendo un attacco denial of service. La trattativa, quando c'è, non riguarda davvero una chiave di decifratura. Riguarda se i dati rubati restino riservati. ## Come entra, e perché ora il regolatore se ne preoccupa La via d'ingresso è raramente esotica. I vettori dominanti sono quelli più banali: un'e-mail di phishing che recapita un loader o raccoglie credenziali, un servizio esposto su Internet lasciato senza protezione o non aggiornato, una password di accesso remoto debole o riutilizzata, e la catena di fornitura, dove un fornitore o un software fidato diventa la via d'accesso alla tua rete. Niente di tutto ciò richiede un exploit inedito. Basta una porta aperta, ed è per questo che la gestione dell'esposizione e l'igiene delle identità riducono il rischio ransomware più di qualsiasi singolo prodotto. Un incidente ransomware è ormai un evento normativo, non solo tecnico. Poiché l'attacco comporta quasi sempre un furto di dati, di norma fa scattare gli obblighi relativi alle violazioni di dati personali ai sensi del GDPR, il che implica una valutazione di notifica all'autorità di controllo e, nei casi gravi, alle persone interessate. Gli operatori di servizi essenziali e importanti sono soggetti a obblighi di segnalazione degli incidenti che si sovrappongono ai sensi della direttiva NIS2. Agenzie nazionali come ANSSI ed ENISA pubblicano linee guida proprio perché lo stesso modus operandi continua a funzionare. La conseguenza pratica per una funzione di rischio è che il piano di risposta deve includere il binario giuridico e di notifica fin dalla prima ora, condotto in parallelo al ripristino tecnico e non aggiunto in un secondo momento. > **Pagare non chiude il caso** Un pagamento può produrre una chiave di decifratura, ma non annulla una violazione di dati. Il termine di notifica ai sensi del GDPR continua a decorrere, i dati rubati possono comunque essere divulgati e i regolatori esaminano con attenzione i pagamenti a entità sanzionate. Tratta qualsiasi decisione di pagamento come una decisione giuridica e di rischio presa con un consulente legale, mai come la soluzione tecnica. ## L'esito si decide prima dell'attacco, non durante la richiesta di riscatto L'idea più importante per i professionisti è che il risultato di un incidente ransomware è in gran parte determinato dal lavoro svolto molto prima che accada. Un'organizzazione in grado di ripristinare rapidamente da backup puliti, testati, offline o immutabili può rifiutarsi di pagare per una chiave. Quella i cui backup erano raggiungibili dalla stessa rete, e quindi cifrati insieme a tutto il resto, non ha questa opzione. La segmentazione della rete limita la distanza che un'intrusione può percorrere prima di raggiungere i sistemi che contano. Un'autenticazione forte sull'accesso remoto e sulla posta chiude le porte d'ingresso più comuni. Una rilevazione che intercetta il movimento laterale guadagna le ore che separano un incidente contenuto da un evento di cifratura su scala aziendale. Ciò che fanno realmente i team competenti, dunque, è investire nella postura precedente all'incidente piuttosto che nell'abilità di negoziazione. Mantengono backup isolati dal dominio di produzione, cifrati a riposo e ripristinati secondo un calendario, in modo che il ripristino sia dimostrato anziché presunto. Segmentano le reti affinché una postazione di lavoro compromessa non possa raggiungere senza ostacoli il server di backup o i controller di dominio. Mantengono un piano di risposta agli incidenti che nomina ruoli, decisori, esperti forensi esterni e consulenza legale, oltre al percorso di notifica, e lo provano. È qui che il ransomware si collega direttamente alla gestione della continuità operativa e al ripristino in caso di disastro: il tempo di ripristino e il punto di ripristino che un'organizzazione può effettivamente raggiungere, testati rispetto a uno scenario realistico, fanno la differenza tra una brutta settimana e una crisi esistenziale. --- ## Recovery Time Objective e Recovery Point Objective (RTO / RPO) **URL:** https://cyberacademy.net/it/resources/encyclopedia/rto-rpo **Last reviewed:** 2026-06-24 L'RTO è la durata massima accettabile durante la quale un processo di business può rimanere inoperativo prima che si verifichino danni inaccettabili. L'RPO è la perdita massima di dati, misurata in tempo, precedente all'interruzione. Entrambi derivano dalla BIA. I valori che il CIO inserisce nel BCP senza consultare il business sono quelli che cedono sotto pressione. ## Due orologi che misurano cose diverse L'RTO e l'RPO sono i due obiettivi di ripristino che trasformano una vaga promessa di resilienza in numeri verificabili. È facile confonderli perché entrambi si esprimono in unità di tempo, ma misurano cose diverse e indicano soluzioni diverse. Il recovery time objective riguarda per quanto tempo puoi rimanere fermo. Il recovery point objective riguarda quanti dati puoi permetterti di perdere. Confondili e acquisterai l'architettura di ripristino sbagliata. Immagina l'interruzione come un singolo istante su una linea temporale. L'RTO guarda in avanti da quell'istante: è la finestra massima tra il disservizio e il momento in cui il processo torna utilizzabile, prima che il danno diventi inaccettabile. L'RPO guarda indietro da quell'istante: è l'età massima dell'ultima copia valida dei dati a cui puoi ripristinare, che equivale ai dati più recenti che sei disposto a perdere. Un RTO di quattro ore con un RPO di quindici minuti significa che il servizio deve tornare attivo entro quattro ore e non può perdere più di quindici minuti di transazioni. **RTO confrontato con RPO** | | RTO | RPO | | --- | --- | --- | | Misura | Tempo di inattività accettabile | Perdita di dati accettabile | | Direzione sulla linea temporale | In avanti dall'interruzione | Indietro dall'interruzione | | Domanda a cui risponde | Quanto rapidamente dobbiamo tornare operativi? | Quanti dati possiamo perdere? | | Principalmente determinato da | Processo di ripristino, failover, personale | Frequenza di backup e replica | | Fonte | Analisi di impatto sul business | Analisi di impatto sul business | ## Da dove vengono i numeri e perché conta la responsabilità Entrambi gli obiettivi sono risultati dell'analisi di impatto sul business, non ipotesi formulate nella sala server. La BIA studia ogni attività critica, misura come il danno di un disservizio cresce nel tempo e produce obiettivi di ripristino che il responsabile del processo convalida. Quella responsabilità è esattamente il punto. Un RTO e un RPO che un team tecnico fissa in modo isolato descrivono ciò che l'infrastruttura può fare, non ciò di cui il business ha bisogno, e il divario tra i due emerge solo durante un incidente reale, che è il momento peggiore per scoprirlo. Gli obiettivi devono anche essere conciliati con il costo. Spingere un RPO verso zero significa replica continua o sincrona. Spingere un RTO verso pochi minuti significa capacità di standby a caldo che resta inattiva. Entrambi sono costosi, quindi la BIA impone una conversazione onesta su quali processi giustificano davvero quella spesa e quali possono tollerare una finestra più lunga. Stratificare le attività per livelli è normale: il motore dei pagamenti e il sito di marketing raramente meritano gli stessi obiettivi. > **L'RTO non coincide con la durata effettiva del ripristino** L'RTO è l'obiettivo che il business può tollerare. Il tempo effettivo di cui il tuo team ha bisogno per ripristinare il servizio è il recovery time achieved, misurato in un test. Se il tempo raggiunto è più lungo dell'obiettivo, hai un divario da colmare, non un numero da allentare in silenzio. ## Come l'RTO e l'RPO si inseriscono negli standard Questi obiettivi sono vocabolario fondamentale nei framework di continuità e resilienza. ISO 22301, lo standard internazionale per i sistemi di gestione della continuità operativa, tratta i recovery time e recovery point objectives come risultati dell'analisi di impatto che guidano la strategia e le soluzioni di continuità. Confluiscono direttamente nella progettazione del disaster recovery, nei piani di backup e nella scelta dei siti di ripristino. Nei settori regolamentati sono sempre più esaminati anziché dati per scontati: il regolamento europeo DORA fissa aspettative di continuità e di test per le entità finanziarie, e la Direttiva NIS 2 richiede misure di continuità operativa e di backup alle entità essenziali e importanti. I professionisti fanno tre cose con questi numeri. Li derivano dalla BIA insieme ai responsabili del business. Progettano backup, replica e failover affinché l'architettura possa effettivamente rispettarli. Poi lo dimostrano con i test, perché un RTO non testato è un'aspirazione. L'obiettivo guadagna fiducia solo dopo che un'esercitazione di ripristino ha mostrato che il team può raggiungerlo in condizioni realistiche. --- ## Registro dei rischi **URL:** https://cyberacademy.net/it/resources/encyclopedia/risk-register **Last reviewed:** 2026-06-24 Il registro dei rischi è l'elenco canonico e dinamico dei rischi identificati, con relativa analisi, valutazione, trattamento e titolarità. Non è un foglio di calcolo una tantum. Gli auditor si aspettano voci datate, responsabili nominati, modifiche tracciabili e cicli di revisione collegati al riesame della direzione. La versione per il board è più sintetica; quella operativa contiene tutto. ## Cos'è realmente il registro Il registro dei rischi è l'unico luogo in cui l'organizzazione tiene traccia di ciò che la preoccupa e di ciò che sta facendo al riguardo. Le persone immaginano un foglio di calcolo, e spesso inizia proprio così, ma l'artefatto che conta è la disciplina che lo sostiene : ogni rischio identificato, analizzato, valutato rispetto alla propensione, assegnato a un responsabile, dotato di una decisione di trattamento e riesaminato secondo un ciclo. Un registro compilato una sola volta per una certificazione e mai più toccato non è un registro dei rischi, è un pezzo da museo. La prova consiste nel verificare se puoi guardare una qualsiasi riga e vedere quando è stata riesaminata l'ultima volta, chi ne è responsabile e cosa è cambiato da allora. Ogni voce riporta in genere una descrizione del rischio, l'asset o l'obiettivo che minaccia, l'analisi (probabilità e impatto, comunque tu li valuti), la valutazione rispetto ai tuoi criteri, il trattamento scelto, il responsabile designato, il rischio residuo dopo il trattamento e una data di riesame. Il livello di dettaglio è deliberato : quando un auditor o un incidente tira un filo, la voce deve reggere. Le voci vaghe, senza responsabile e senza data, sono la prima cosa che un auditor competente individua, e minano la credibilità dell'intero programma. ## Come si collega a tutto il resto Il registro non è un documento a sé stante, è il fulcro a cui si aggancia il resto del programma di gestione dei rischi. L'identificazione e l'analisi seguono una metodologia come ISO 27005 o EBIOS RM, e il loro risultato confluisce qui. La colonna del trattamento è il punto in cui ogni rischio incontra la decisione di evitare, ridurre, trasferire o accettare, e in un contesto ISO 27001 quella decisione prosegue fino alla Dichiarazione di Applicabilità e ai controlli che la attuano. La colonna della valutazione ha senso solo se esiste una propensione al rischio scritta rispetto alla quale valutare, altrimenti ogni giudizio è soltanto l'opinione di un analista. Il registro si colloca quindi a valle della metodologia e della propensione, e a monte del trattamento e dell'evidenza dei controlli. È anche per questo che il registro è un documento vivo legato al riesame della direzione e non un deliverable una tantum. Compaiono nuovi rischi, i rischi trattati cambiano la loro valutazione residua, i responsabili cambiano ruolo, e la propensione stessa può mutare. Un programma maturo riesamina il registro con una cadenza definita e fa confluire i movimenti significativi nel riesame della direzione, così che il vertice prenda decisioni su un'immagine attuale e non su quella dell'anno scorso. > **Due destinatari, due versioni** Il registro operativo contiene tutto : ogni voce, ogni campo, ogni responsabile. La versione che arriva al consiglio è una sintesi deliberata dei rischi che contano alla loro altezza. Cercare di far servire un unico documento a entrambi è un errore comune. Il consiglio annega in un dettaglio su cui non può agire, e il team operativo perde il proprio strumento di lavoro. Tieni entrambi, e tienili allineati. ## Cosa mantengono realmente i professionisti In pratica il registro è il punto in cui le buone intenzioni incontrano la manutenzione. La parte difficile non è il primo passaggio, è mantenerlo onesto negli anni. Le voci datate contano perché un auditor si aspetta di vedere un cambiamento tracciabile : quando un rischio è stato sollevato, quando la sua valutazione si è spostata, quando il trattamento si è concluso. I responsabili designati contano perché un rischio senza responsabile è un rischio che in realtà nessuno gestisce. I cicli di riesame contano perché le tolleranze e le dipendenze si spostano, e un registro vecchio di due riorganizzazioni darà priorità alle cose sbagliate. I campi sono facili da elencare e difficili da sostenere, ed è esattamente per questo che il registro, e non la politica, è il punto in cui si vede se un programma di gestione dei rischi è vivo. Una confusione frequente è tra il registro e il piano di trattamento. Il registro è l'inventario dei rischi e del loro stato attuale. Il piano di trattamento è l'insieme delle azioni a cui ti sei impegnato, con scadenze e responsabilità, per portare i rischi verso livelli accettabili. Si rimandano a vicenda ma non sono lo stesso documento, e quando divergono l'audit se ne accorge. Tieni il registro come fonte di verità per lo stato, e lascia che il piano di trattamento sia la fonte di verità per il lavoro in corso. --- ## Registro delle Attività di Trattamento (ROPA) **URL:** https://cyberacademy.net/it/resources/encyclopedia/ropa **Last reviewed:** 2026-06-24 Il ROPA è l'inventario documentato delle attività di trattamento richiesto dall'articolo 30 del GDPR. I titolari elencano finalità, categorie, destinatari, conservazione e trasferimenti; i responsabili elencano i titolari serviti, le categorie e i trasferimenti. La maggior parte delle organizzazioni sottovaluta il lavoro di manutenzione. L'autorità di controllo richiede il ROPA come prima cosa all'avvio di un'indagine. ## Che cos'è davvero il ROPA (registro delle attività di trattamento) Il registro delle attività di trattamento è la mappa di tutto ciò che un'organizzazione fa con i dati personali. Non è una policy né una promessa; è un inventario, mantenuto aggiornato, che consente di rispondere a una domanda semplice per qualsiasi operazione di trattamento: quali dati, per quale finalità, su quale base giuridica, chi vi accede, dove finiscono e per quanto tempo vengono conservati. Il GDPR rende questo registro un obbligo ai sensi dell'articolo 30 e ripartisce il dovere in base al ruolo. Un titolare del trattamento documenta le proprie attività di trattamento; un responsabile del trattamento documenta le categorie di trattamento che svolge per conto dei titolari che serve. I due registri si sovrappongono ma non sono identici, e un'organizzazione che agisce sia come titolare sia come responsabile deve tenerli entrambi. In pratica il ROPA è la base su cui poggia il resto di un programma sulla privacy. Non è possibile condurre una DPIA significativa, rispondere a una richiesta di accesso di un interessato, delimitare una violazione o negoziare un contratto con un responsabile del trattamento senza sapere prima che il trattamento esiste e dove si trovano i dati. È per questo che l'autorità di controllo chiede per primo il ROPA quando si apre un'indagine. È il modo più rapido per un regolatore di valutare se un'organizzazione comprende davvero i propri dati, e un registro povero o non aggiornato segnala che probabilmente anche il resto del programma lo è. ## Cosa contiene: titolare rispetto a responsabile Le due versioni del registro contengono campi diversi perché i due ruoli rispondono a domande diverse. Un titolare del trattamento decide perché e come i dati vengono trattati, quindi il suo registro deve giustificare ogni finalità. Un responsabile agisce solo su istruzioni, quindi il suo registro descrive il servizio che fornisce, non la logica che vi sta dietro. **Registro del titolare rispetto al registro del responsabile** | Elemento | Registro del titolare | Registro del responsabile | | --- | --- | --- | | Identità e contatto | Titolare, eventuali contitolari, rappresentante, DPO | Responsabile, rappresentante, DPO, e ogni titolare servito | | Finalità | Finalità di ciascuna attività di trattamento | Non richiesta; il responsabile agisce su istruzioni | | Interessati e categorie | Categorie di persone e di dati personali | Categorie di trattamento svolte per ciascun titolare | | Destinatari | A chi sono comunicati i dati | Idem, ove pertinente per il servizio | | Trasferimenti | Trasferimenti al di fuori dell'UE e garanzie utilizzate | Trasferimenti al di fuori dell'UE e garanzie utilizzate | | Conservazione | Termini previsti per la cancellazione ove possibile | Non richiesta separatamente | | Sicurezza | Descrizione generale delle misure tecniche e organizzative | Descrizione generale delle misure tecniche e organizzative | I campi sembrano amministrativi, ma ciascuno è portante. I periodi di conservazione guidano i flussi di cancellazione. Gli elenchi dei destinatari alimentano l'inventario dei responsabili e le valutazioni d'impatto dei trasferimenti. Le categorie di dati segnalano dove un trattamento di categorie particolari fa scattare l'obbligo di un DPO o di una DPIA. Compilato onestamente, il ROPA è uno strumento diagnostico operativo; compilato come un mero adempimento da spuntare, è peggio che inutile perché dà una falsa sicurezza. > **La manutenzione è la parte difficile** La maggior parte delle organizzazioni sottovaluta la manutenzione. Costruire il primo ROPA è un progetto con una fine chiara; mantenerlo accurato è un processo senza fine. Nuovi strumenti, nuovi fornitori, nuove campagne di marketing e riorganizzazioni cambiano tutti il panorama dei trattamenti, e un registro completo al momento dell'audit si disallinea nel giro di mesi. La soluzione consiste nel legare gli aggiornamenti del ROPA a eventi di cambiamento esistenti, l'inserimento di un fornitore, il lancio di una funzionalità, la firma di un contratto di trattamento, anziché affidarsi a una revisione annuale che nessuno presidia. ## Chi deve tenerlo e come si collega Il GDPR formula il dovere dell'articolo 30 con un'esenzione per le organizzazioni con meno di 250 dipendenti, ma l'esenzione è abbastanza ristretta da far sì che la maggior parte abbia comunque bisogno di un registro. Decade non appena il trattamento non è occasionale, è probabile che presenti un rischio per le persone, oppure riguarda dati di categorie particolari o relativi a reati, il che copre il trattamento ordinario di quasi ogni azienda operativa. Le autorità di controllo, tra cui la CNIL, considerano il ROPA come una prassi attesa anziché come un obbligo raro, e la CNIL pubblica un modello gratuito per abbassare la barriera d'ingresso. Il registro non vive da solo. È la spina dorsale a cui si agganciano la DPIA, la funzione di DPO e il processo di risposta alle violazioni. Il DPO lo usa per monitorare la conformità e consigliare sul rischio; una DPIA inizia estraendo la voce pertinente; una valutazione della violazione lo usa per delimitare quali dati e quali persone sono coinvolti. Le organizzazioni che procedono verso ISO 27701 riconosceranno nel ROPA, in sostanza, il sistema di gestione delle informazioni sulla privacy che richiede lo stesso inventario, ed è per questo che i team maturi tengono un unico registro e lo lasciano servire più regimi anziché mantenere elenchi paralleli. --- ## Regolamento Generale sulla Protezione dei Dati (GDPR) **URL:** https://cyberacademy.net/it/resources/encyclopedia/gdpr **Last reviewed:** 2026-06-24 Il GDPR disciplina i dati personali nell'UE e ovunque si servano residenti europei. Base giuridica, diritti degli interessati, responsabilizzazione, notifica delle violazioni, applicazione da parte delle autorità di controllo. Le sanzioni massime (20 milioni di euro o il 4% del fatturato mondiale) fanno notizia; nella pratica, la maggior parte delle azioni esecutive passa attraverso il dialogo con le autorità di controllo, non attraverso il massimo edittale. ## Un regolamento sulla responsabilizzazione, non solo sul consenso Il GDPR viene spesso ridotto, nelle conversazioni, ai banner sui cookie e ai pop-up di consenso, ma questa immagine trascura dove risieda davvero il suo peso. Il consenso è solo una delle diverse basi giuridiche per il trattamento dei dati personali e, per la maggior parte delle attività di un'organizzazione, non è nemmeno quella su cui essa fa affidamento. L'esecuzione di un contratto, l'obbligo legale e il legittimo interesse reggono, nella pratica, molti più trattamenti. Il cambiamento più profondo introdotto dal GDPR è la responsabilizzazione (accountability): non basta essere conformi, occorre essere in grado di dimostrare la conformità. Questo singolo principio è ciò che trasforma la protezione dei dati, che passa da un parere giuridico a una disciplina operativa, con registri, valutazioni e prove dietro ogni affermazione. Poiché si tratta di un regolamento e non di una direttiva, il GDPR si applica direttamente in tutta l'UE e, più ampiamente, nel SEE, senza che ciascun Paese debba recepirlo nel proprio diritto nazionale, motivo per cui i suoi obblighi fondamentali sono identici in Francia, Germania e Irlanda. La sua portata si estende anche oltre l'Europa. Un'organizzazione stabilita al di fuori dell'UE rientra comunque nel suo ambito di applicazione quando offre beni o servizi a persone che si trovano nell'Unione o ne monitora il comportamento in tale territorio. Questa portata territoriale spiega perché un'azienda priva di un ufficio europeo possa comunque dover rispondere a un'autorità di controllo europea. ## Base giuridica, diritti degli interessati e obblighi che ne conseguono Ogni trattamento di dati personali necessita di una base giuridica scelta prima dell'inizio del trattamento, e la base prescelta determina i diritti che le persone possono esercitare. Gli interessati possono chiedere di accedere ai propri dati, di farli rettificare o cancellare, di limitare il trattamento o di opporvisi e, in alcuni casi, di riceverli in un formato portatile. Nessuno di questi diritti è assoluto; ciascuno è soggetto a condizioni ed esenzioni. Intorno ai diritti si collocano gli obblighi del titolare e del responsabile del trattamento: protezione dei dati fin dalla progettazione e per impostazione predefinita, tenuta di un registro delle attività di trattamento, messa in sicurezza dei dati mediante misure tecniche e organizzative adeguate, e stipula di contratti scritti ogniqualvolta un responsabile tratti dati per conto di un titolare. Due obblighi meritano di essere evidenziati perché orientano il lavoro quotidiano. Quando un trattamento può comportare un rischio elevato per le persone, il titolare effettua una valutazione d'impatto sulla protezione dei dati prima di procedere, documentando il rischio e il modo in cui viene mitigato. E quando si verifica una violazione dei dati personali, il titolare è soggetto a un obbligo di notifica nei confronti dell'autorità di controllo entro un termine breve e definito, informando anche le persone interessate quando il rischio per esse è elevato. Non sono rituali burocratici. Sono i momenti in cui il principio di responsabilizzazione diventa un obbligo concreto e vincolato a una scadenza. > **Il GDPR fissa la legge, ISO 27701 ti aiuta a metterla in pratica** Il GDPR ti dice cosa raggiungere, ma non come gestirlo come un sistema. ISO/IEC 27701 estende un sistema di gestione della sicurezza delle informazioni ISO 27001 in un sistema di gestione delle informazioni sulla privacy, fornendoti routine ripetibili per i registri, le valutazioni e i controlli che il regolamento si attende. La certificazione non equivale alla conformità legale, ma rende tale conformità verificabile anziché improvvisata. ## Dove si colloca il GDPR tra i concetti vicini È utile distinguere il GDPR dai ruoli e dagli strumenti che gli orbitano attorno. Un DPO è una persona o una funzione che alcune organizzazioni devono nominare per vigilare sulla conformità; una DPIA è il processo di valutazione per i trattamenti ad alto rischio; un ROPA è l'inventario delle attività di trattamento; le clausole contrattuali tipo sono uno dei meccanismi per trasferire lecitamente i dati al di fuori dell'UE. Il GDPR è il regolamento che impone o consente ciascuno di questi elementi. Le autorità di controllo nazionali, come la CNIL in Francia, lo applicano ed emanano linee guida, e il Comitato europeo per la protezione dei dati le coordina affinché un'unica interpretazione valga oltre i confini. Come rileva la shortDefinition, le cifre di primo piano fino a 20 milioni di euro o al 4 percento del fatturato annuo mondiale dominano la copertura mediatica, eppure la maggior parte dell'attività di applicazione passa attraverso il dialogo con l'autorità di controllo anziché attraverso sanzioni massime. Le autorità indagano, pongono domande, richiedono interventi correttivi e spesso risolvono le questioni mediante misure correttive ben al di sotto del massimale. Per i professionisti la lezione pratica è che una buona fede dimostrabile e una postura di conformità supportata da prove cambiano l'andamento di quel dialogo. Le organizzazioni che ne escono peggio sono di solito quelle che non riescono a dimostrare cosa stessero facendo con i dati, non quelle che hanno preso una decisione onesta e documentata. ## Come i professionisti lo rendono operativo Trasformare il regolamento in lavoro di routine inizia di solito dalla mappatura. Si costruisce e si mantiene un registro delle attività di trattamento per sapere quali dati si detengono, perché, su quale base giuridica e dove fluiscono. Da lì i team integrano la privacy fin dalla progettazione nei nuovi progetti, effettuano DPIA dove il rischio è elevato, rafforzano i contratti con i responsabili e provano il percorso di notifica delle violazioni affinché il conto alla rovescia non li colga impreparati. Molti ancorano tutto questo a un sistema di gestione anziché a un raccoglitore di politiche, ed è qui che standard come ISO 27701 e le linee guida di supporto delle autorità di controllo si guadagnano il loro posto. L'obiettivo è una prova a regime permanente: in qualsiasi momento si può dimostrare una base giuridica, un registro e un controllo per i dati personali che si trattano. --- ## Rischio inerente vs rischio residuo **URL:** https://cyberacademy.net/it/resources/encyclopedia/inherent-residual-risk **Last reviewed:** 2026-06-24 Il rischio inerente è l'esposizione prima dei controlli. Il rischio residuo è ciò che rimane dopo l'applicazione dei controlli. Gli auditor esaminano il divario: deve essere giustificato, accettato (o ulteriormente trattato) da un responsabile nominato, e coerente con la propensione al rischio. Un valore "residuo = zero" nel registro è un segnale d'allarme, non un risultato. ## Lo stesso rischio visto in due momenti Il rischio inerente e il rischio residuo non sono due rischi diversi. Sono lo stesso scenario misurato in due punti: prima che i tuoi controlli svolgano il loro lavoro e dopo che lo hanno svolto. Il rischio inerente è l'esposizione grezza, il livello di probabilità e impatto che affronteresti se i controlli pertinenti fossero assenti o fallissero del tutto. Il rischio residuo è ciò che rimane una volta che i controlli sono in atto e operano come previsto. Leggerli fianco a fianco è tutto il senso dell'esercizio, perché lo scarto tra i due è il valore visibile del tuo sistema di controllo. Uno scarto ampio indica che i controlli stanno facendo la loro parte; uno scarto sottile indica che stai impiegando sforzo per una riduzione modesta e dovresti chiederti il perché. Trattare questi livelli come una coppia cambia il modo in cui spendi. Se due scenari condividono un livello residuo simile ma uno partiva da un livello inerente molto più alto, l'insieme di controlli che lo tiene basso svolge un lavoro considerevole e merita protezione nel budget. Lo scenario che si è appena spostato dall'inerente al residuo è quello da riesaminare: o il controllo è debole, o è il controllo sbagliato, o il rischio non è mai stato tanto esposto quanto sosteneva la valutazione. **Rischio inerente e rischio residuo** | Dimensione | Rischio inerente | Rischio residuo | | --- | --- | --- | | Quando si misura | Prima dei controlli | Dopo che i controlli operano | | Cosa mostra | Esposizione grezza dello scenario | Esposizione che effettivamente rimane | | Uso principale | Dare priorità a dove servono i controlli | Decidere se accettare, trattare ulteriormente o trasferire | | Confrontato con | Altri scenari non trattati | La propensione e la tolleranza al rischio | | Azione del titolare | Progettare il trattamento | Accettare e firmare, oppure escalare lo scarto | ## Cosa si aspettano auditor e standard Lo scarto tra l'inerente e il residuo è dove risiede l'assurance, quindi deve essere giustificato anziché asserito. Un auditor legge il registro e chiede tre cose a ogni valore residuo: quali controlli lo hanno ridotto, se quei controlli operano davvero anziché essere solo documentati, e chi ha accettato ciò che rimane. Quest'ultimo punto conta. Il rischio residuo è accettato da un titolare nominato con l'autorità di assumerlo, e tale accettazione deve collocarsi all'interno della propensione al rischio dell'organizzazione. Un livello residuo che supera la propensione non è una voce conclusa; è un punto aperto che richiede un ulteriore trattamento, un trasferimento, o un'eccezione deliberata e documentata. Questa logica è radicata nei principali framework. ISO 31000 inquadra la gestione del rischio come un ciclo iterativo in cui il trattamento modifica il rischio e il rischio modificato viene poi rivalutato, che è esattamente il passaggio dall'inerente al residuo. ISO/IEC 27005 applica lo stesso ragionamento al rischio della sicurezza delle informazioni ed è esplicita nel richiedere che il rischio residuo sia valutato e formalmente accettato dalla direzione prima che un sistema entri in esercizio o resti in produzione. Le linee guida del NIST sulla valutazione del rischio mantengono la distinzione identica tra il rischio che un'organizzazione affronta e la porzione che rimane dopo l'applicazione delle risposte. Nessuno di questi standard tratta il residuo come un numero che si calcola una volta e si archivia. > **Un residuo a zero è un campanello d'allarme, non un trofeo** Un registro che mostra il rischio residuo ridotto a zero è quasi sempre errato, perché nessun insieme di controlli è perfetto e i controlli stessi falliscono. Zero di solito significa che qualcuno ha confuso l'obiettivo con la realtà, o ha smesso silenziosamente di tenere conto del fallimento dei controlli. Gli auditor lo leggono come un problema di maturità, non come un successo. ## Farlo bene nella pratica In un registro operativo, ogni riga dovrebbe consentire a un lettore di ricostruire la valutazione inerente, i controlli applicati, la valutazione residua, e il titolare nominato che l'ha accettata. Mantieni coerente il metodo di valutazione tra l'inerente e il residuo affinché i due siano davvero comparabili; se valuti impatto e probabilità in modo diverso a ogni fase, lo scarto non significa nulla. Rivaluta il residuo ogni volta che un controllo cambia, si degrada, o si rivela inefficace durante i test, perché il rischio residuo è aggiornato solo quanto i controlli che lo sostengono. Un valore residuo fissato due audit fa e mai riesaminato è decorazione, non assurance. Il giudizio che vale davvero consiste nel collegare il rischio residuo alla propensione e al trattamento. Una volta che il residuo si colloca al livello della propensione o al di sotto, l'accettazione è ragionevole e il titolare firma. Quando si colloca al di sopra, la voce onesta registra lo scarto e il piano per colmarlo, anziché arrotondare il numero verso il basso per far apparire la pagina ordinata. Questa disciplina è ciò che trasforma un registro, da artefatto di conformità, in uno strumento che il consiglio può davvero usare per allocare l'attenzione. --- ## SOC 2 **URL:** https://cyberacademy.net/it/resources/encyclopedia/soc-2 **Last reviewed:** 2026-06-24 SOC 2 è il report di attestazione AICPA sui controlli di un'organizzazione di servizi, che copre cinque criteri di fiducia (sicurezza, disponibilità, integrità del trattamento, riservatezza, privacy). Riferimento canonico nordamericano per i vendor SaaS; ISO 27001 è l'equivalente europeo. Type I = valutazione puntuale; Type II = efficacia operativa su un periodo di 6-12 mesi. Spesso richiesto nei processi di procurement enterprise. ## Cosa attesta realmente SOC 2 SOC 2 non è una certificazione che si supera o non si supera. È un rapporto di attestazione prodotto da uno studio di CPA abilitato secondo gli standard di attestazione dell'AICPA, in cui un revisore indipendente esprime un'opinione sul fatto che i controlli di un'organizzazione di servizi siano progettati in modo adeguato e, per il Tipo II, operino efficacemente per un periodo. L'ambito si costruisce intorno ai Trust Services Criteria: sicurezza (l'unica categoria obbligatoria, detta anche common criteria), disponibilità, integrità di elaborazione, riservatezza e privacy. Si sceglie quali dei cinque si applicano al servizio offerto, e il rapporto è dimensionato in base a tale scelta. Poiché si tratta di un'opinione su una descrizione redatta dal management, due rapporti SOC 2 sono raramente identici. Un fornitore può circoscrivere l'ambito alla sola sicurezza; un altro può aggiungere disponibilità e riservatezza. Leggere il rapporto significa leggere la descrizione del sistema, i criteri inclusi nell'ambito, i test eseguiti e, soprattutto, eventuali eccezioni rilevate dal revisore. Un rapporto senza rilievi con un ambito ristretto può costituire una prova più debole di un rapporto con eccezioni minori su un ambito ampio. ## Tipo I rispetto al Tipo II La distinzione a cui i professionisti tengono di più è quella tra Tipo I e Tipo II. Il Tipo I è un'istantanea: il revisore esprime l'opinione che i controlli siano progettati in modo adeguato a una singola data. Dimostra che i controlli esistono sulla carta ed erano in essere quel giorno. Il Tipo II è quello che gli acquirenti enterprise desiderano davvero, perché il revisore verifica se tali controlli abbiano operato efficacemente nell'arco di un periodo di esame che copre solitamente da sei a dodici mesi, campionando le prove lungo tutto il periodo. Un Tipo II risponde alla vera domanda degli approvvigionamenti: il fornitore lo ha fatto in modo costante, e non solo il giorno dell'audit? **SOC 2 Tipo I vs Tipo II** | Dimensione | Tipo I | Tipo II | | --- | --- | --- | | Cosa viene testato | Progettazione dei controlli | Progettazione ed efficacia operativa | | Arco temporale | Un singolo momento nel tempo | Un periodo di esame (comunemente da 6 a 12 mesi) | | Prove | Controlli in essere alla data | Prove campionate lungo il periodo | | Uso tipico | Primo rapporto, fornitori in fase iniziale | Ciò che si aspettano gli approvvigionamenti enterprise | ## SOC 2 accanto a ISO 27001 SOC 2 e ISO 27001 rispondono alla stessa preoccupazione dell'acquirente da due tradizioni diverse. SOC 2 è il segnale canonico nordamericano, un'attestazione del revisore legata ai Trust Services Criteria e rinnovata secondo un periodo ricorrente. ISO 27001 è lo standard internazionale e certificabile costruito intorno a un sistema di gestione (l'SGSI), con la certificazione rilasciata da un organismo accreditato e mantenuta tramite audit di sorveglianza. SOC 2 riferisce sui controlli a fronte di criteri; ISO 27001 certifica che si gestisce un sistema funzionante con una Dichiarazione di Applicabilità e un miglioramento continuo. Molti fornitori che vendono su entrambe le sponde dell'Atlantico finiscono per possederli entrambi, e le prove di controllo si sovrappongono ampiamente anche se i deliverable differiscono. In pratica, i team GRC trattano i due come complementari anziché concorrenti. Gli stessi controlli di accesso, la gestione dei cambiamenti, il trattamento delle vulnerabilità e la risposta agli incidenti alimentano sia l'insieme di controlli dell'Annex A di ISO 27001 sia i common criteria di SOC 2. Il lavoro consiste nel mappare una volta e presentare due volte. > **Leggi il rapporto, non il logo** Un badge SOC 2 da solo non dice quasi nulla. Richiedi sempre il rapporto completo e verifica i criteri inclusi nell'ambito, se si tratta di Tipo I o Tipo II, il periodo coperto, le organizzazioni di sottoservizi escluse e qualsiasi eccezione rilevata. --- ## Schrems II **URL:** https://cyberacademy.net/it/resources/encyclopedia/schrems-ii **Last reviewed:** 2026-06-24 Schrems II è la sentenza della CGUE del 2020 che ha invalidato l'EU-US Privacy Shield e ha introdotto il requisito della Transfer Impact Assessment. Ogni trasferimento verso un paese terzo richiede ora un'analisi documentata della normativa locale in materia di sorveglianza e delle misure supplementari. Sostituito nella pratica dall'EU-US Data Privacy Framework (2023), ma la disciplina della TIA è rimasta in vigore. ## Cosa ha deciso davvero la sentenza Schrems II è la sentenza della Corte di giustizia dell'Unione europea, pronunciata nel luglio 2020 nella causa Data Protection Commissioner v Facebook Ireland e Maximillian Schrems, che ha ridisegnato il modo in cui i dati personali lasciano lo Spazio economico europeo. Sono accadute due cose contemporaneamente. In primo luogo, la Corte ha invalidato il Privacy Shield UE-USA, l'accordo di adeguatezza che aveva consentito a migliaia di imprese di trasferire dati verso importatori statunitensi certificati, perché il diritto statunitense in materia di sorveglianza non offriva alle persone dell'Unione una protezione sostanzialmente equivalente a quella garantita all'interno dell'Unione e non concedeva loro alcun ricorso giurisdizionale effettivo. In secondo luogo, ed è la parte che resta, la Corte non ha annullato le clausole contrattuali tipo. Le ha mantenute valide ma vi ha aggiunto una condizione: l'esportatore non può limitarsi a firmare le clausole e disinteressarsene. Quella condizione è il cuore della questione. La Corte ha affermato che gli esportatori di dati devono verificare, caso per caso, se il diritto e la prassi del paese di destinazione consentano effettivamente all'importatore di rispettare le garanzie contrattuali. Quando non è così, l'esportatore deve aggiungere misure supplementari o interrompere il trasferimento. Il contratto da solo non basta se un governo straniero può imporre l'accesso in un modo che le clausole non possono impedire. ## La valutazione d'impatto del trasferimento nella pratica La disciplina creata da Schrems II è la valutazione d'impatto del trasferimento, o TIA. È l'analisi documentata che trasforma la sentenza in un controllo ripetibile. Un professionista che svolge una TIA segue una sequenza riconoscibile anziché un parere giuridico estemporaneo. - Mappare il trasferimento. Individuare quali dati vanno dove, le categorie di persone interessate, l'importatore, eventuali trasferimenti successivi e il meccanismo giuridico su cui ci si basa, di solito le SCC. - Valutare il diritto e la prassi di destinazione. Esaminare il regime di sorveglianza e di accesso governativo nel paese importatore e giudicare se compromette la protezione che lo strumento di trasferimento dovrebbe fornire. È l'analisi del diritto in materia di sorveglianza che la Corte ha richiesto. - Individuare le misure supplementari. Quando il diritto locale è problematico, decidere quali garanzie tecniche, contrattuali od organizzative aggiuntive colmino il divario. La crittografia robusta con chiavi detenute soltanto nel SEE, la pseudonimizzazione e il trattamento frazionato sono le misure tecniche che le autorità di controllo indicano più spesso. - Documentare e decidere. Registrare il ragionamento, concludere se il trasferimento può proseguire e fissare un fattore scatenante di revisione affinché la valutazione sia riesaminata quando il diritto o l'accordo cambia. > **La TIA è sopravvissuta alla causa che l'ha creata** Schrems II è spesso descritta come una causa sul Privacy Shield, ma la sua eredità duratura è l'abitudine alla valutazione. Anche ora che il Data Privacy Framework UE-USA offre una nuova via di adeguatezza per gli Stati Uniti, l'obbligo di valutare la destinazione, scegliere un meccanismo lecito e documentare le misure supplementari si applica a ogni paese terzo. La TIA è ormai una voce standard in qualsiasi programma sulla privacy, non una reazione una tantum. ## Dove si colloca oggi Nel 2023 la Commissione europea ha adottato il Data Privacy Framework UE-USA, una nuova decisione di adeguatezza che, per le organizzazioni statunitensi certificate, ripristina una via per trasferire dati senza TIA per quello specifico corridoio. È stato concepito per rispondere alle preoccupazioni sul ricorso e sulla proporzionalità che hanno fatto cadere il Privacy Shield, compreso un meccanismo di riesame indipendente per le persone dell'Unione. Così, in termini quotidiani, la lacuna del Privacy Shield aperta da Schrems II è stata colmata per gli Stati Uniti, a condizione che l'importatore sia certificato secondo il nuovo quadro e che il trasferimento resti nel suo ambito. Ciò che non è scomparso è il metodo più ampio. I trasferimenti verso paesi privi di decisione di adeguatezza si basano ancora sulle SCC o su altri strumenti dell'articolo 46, e ciascuno di essi necessita ancora di una TIA. Gli orientamenti del Comitato europeo per la protezione dei dati sulle misure supplementari restano il manuale pratico. Il modo corretto di leggere Schrems II nel 2026 non è dunque come una storia morta del Privacy Shield, ma come il momento in cui il rischio di trasferimento è diventato qualcosa che si valuta e si documenta, trasferimento per trasferimento, anziché eliminare spuntando una casella di adeguatezza. Due concetti vicini meritano di essere tenuti distinti. Una decisione di adeguatezza è la Commissione che afferma che un intero paese offre una protezione equivalente, il che elimina la necessità di garanzie aggiuntive. Le SCC sono uno strumento contrattuale che si usa quando non c'è una decisione di adeguatezza, e Schrems II è precisamente la sentenza che ha detto che le SCC vengono con il compito di una TIA in allegato. --- ## Security Information and Event Management (SIEM) **URL:** https://cyberacademy.net/it/resources/encyclopedia/siem **Last reviewed:** 2026-06-24 Un SIEM aggrega i log, normalizza gli eventi ed esegue regole di rilevamento sull'intero stack. È il livello di visibilità da cui dipende il SOC. I principali vendor SIEM (Splunk, Sentinel, Elastic, Sumo) integrano sempre più spesso funzionalità SOAR e UEBA. La parte difficile non è acquistare il SIEM; è il data engineering e la pipeline di detection-as-code che ne consegue. ## Cosa fa realmente un SIEM Un SIEM si colloca al centro delle operazioni di sicurezza come motore di raccolta e correlazione. Acquisisce log ed eventi da tutto il parco: firewall, endpoint, provider di identità, piattaforme cloud, server, applicazioni e dispositivi di rete. Normalizza poi quegli eventi in uno schema comune, così che un errore di autenticazione Windows, un accesso VPN e una chiamata a un'API cloud possano essere analizzati insieme, ed esegue regole di rilevamento su quel flusso unificato per generare allarmi. Il punto è la visibilità. Senza un SIEM, i segnali di sicurezza restano intrappolati in decine di console che nessuno correla, e un attacco che tocca cinque sistemi appare come cinque eventi non correlati. Due funzioni rendono un SIEM molto più di uno strumento di ricerca nei log. La prima è la correlazione: regole che si attivano solo quando si verifica una sequenza, per esempio un tentativo di forza bruta seguito da un accesso riuscito e poi da un'escalation di privilegi, qualcosa che nessuna singola fonte segnalerebbe da sola. La seconda è la conservazione e la ricerca, che trasformano il SIEM nel sistema di riferimento per le indagini e nel luogo a cui un analista si rivolge per ricostruire ciò che è accaduto. Come nota la shortDefinition, le piattaforme moderne come Splunk, Microsoft Sentinel, Elastic e Sumo Logic integrano sempre più il SOAR per la risposta automatizzata e l'UEBA per l'analisi comportamentale, così che i confini tra queste categorie si sfumano. ## SIEM, SOC, SOAR ed EDR: chi fa cosa Questi termini viaggiano spesso insieme ed è facile confonderli, ma descrivono cose diverse: uno strumento, un team, un livello di automazione e un sensore. **Come si incastrano i pezzi** | Termine | Che cos'è | Relazione con il SIEM | | --- | --- | --- | | SIEM | La piattaforma di aggregazione, normalizzazione e rilevamento | Il livello di visibilità stesso. | | SOC | Il team e il processo che monitorano e rispondono | Consuma gli allarmi del SIEM; il SIEM è la sua console principale. | | SOAR | Orchestrazione e playbook di risposta automatizzata | Agisce sugli allarmi del SIEM per arricchirli, classificarli e contenerli. | | EDR | Sensore su endpoint con telemetria approfondita dell'host | Una fonte ad alta fedeltà che alimenta il SIEM. | La lettura pratica: il SIEM è la tecnologia che vede tutto, il SOC è l'insieme delle persone che lavorano gli allarmi, il SOAR è l'automazione che riduce il loro lavoro manuale, e l'EDR è una delle fonti di dati più ricche che vi affluiscono. Un SIEM senza un SOC alle spalle genera allarmi che nessuno legge. Un SOC senza un SIEM è cieco. Si acquistano separatamente ma offrono valore solo insieme. ## Perché il SIEM è la parte difficile Acquistare un SIEM è un esercizio di approvvigionamento. Renderlo utile è ingegneria dei dati. Il lavoro che determina davvero il successo consiste nel collegare le giuste fonti di log con una copertura completa, nell'analizzare correttamente ogni fonte affinché i campi finiscano nel posto giusto, e nel mettere a punto i contenuti di rilevamento affinché gli analisti ottengano veri positivi anziché un diluvio di rumore che li abitua a ignorare gli allarmi. È per questo che i team maturi trattano i rilevamenti come codice: le regole vivono in un controllo di versione, sono testate, sono riviste tra pari e vengono distribuite tramite una pipeline, esattamente come il software applicativo. La shortDefinition è netta in proposito. Il lavoro difficile non è acquistare il SIEM; è la pipeline di detection-as-code che ne consegue. Dal punto di vista della governance, il SIEM è ciò che impedisce a diversi obiettivi di controllo di restare aspirazioni. Nell'ambito di un SGSI ISO/IEC 27001 sostiene i controlli su registrazione, monitoraggio e sul versante di rilevamento della gestione degli incidenti, e produce le evidenze che un auditor si aspetta di vedere a dimostrazione che gli eventi vengono effettivamente acquisiti ed esaminati. Operativizza inoltre la capacità di rilevamento e risposta che il NIST Cybersecurity Framework presuppone, e che normative come NIS2 e DORA si aspettano che le organizzazioni mantengano e siano in grado di dimostrare durante un incidente. > **Il costo sta nell'ingestione** La maggior parte delle piattaforme SIEM applica tariffe in base al volume di dati, quindi ciò che si sceglie di raccogliere è tanto una decisione di budget quanto di sicurezza. I team che inviano tutto senza una strategia dei dati ottengono una fattura elevata e ricerche lente. Decidere cosa vale la pena acquisire, cosa riassumere e cosa scartare fa parte di una buona gestione di un SIEM. --- ## Security Operations Center (SOC) **URL:** https://cyberacademy.net/it/resources/encyclopedia/soc **Last reviewed:** 2026-06-24 Un SOC è il team e l'insieme di strumenti che monitora, rileva, analizza e risponde agli eventi di sicurezza in tempo reale. Analisti su livelli (T1 rilevamento, T2 investigazione, T3 threat hunting), 8x5 o 24x7. Interno, esternalizzato (MSSP) o ibrido. Senza un SOC il SIEM è un archivio di log; con uno diventa un sistema di allerta precoce. ## Cosa fa davvero un SOC Un Security Operations Center è la funzione che trasforma la telemetria grezza in decisioni e azioni. La shortDefinition lo presenta come il team più il set di strumenti; in pratica, il valore risiede nel modello operativo che li collega. Il SIEM raccoglie e correla i log, l'EDR registra il comportamento degli endpoint e il SOAR esegue i playbook, ma nulla di tutto ciò produce sicurezza da solo. Il SOC è ciò che legge l'allerta alle 02:00, decide se si tratta di un falso positivo o del primo segno di un'intrusione, e aziona la leva giusta per contenerla. Nel quotidiano, un SOC esegue quattro cicli: monitorare (osservare le console e i flussi), rilevare (confermare che un segnale sia reale), rispondere (contenere, eradicare, ripristinare) e migliorare (affinare le rilevazioni affinché lo stesso rumore non si ripresenti). L'ultimo ciclo è quello che i SOC immaturi saltano, ed è per questo che annegano nelle allerte. Un SOC sano si misura su risultati come il tempo medio di rilevamento e il tempo medio di risposta, non su quante allerte ha chiuso. ## Livelli, organico e copertura Il modello classico suddivide gli analisti in livelli. Il Tier 1 effettua il triage della coda di allerte e decide cosa merita un esame più approfondito. Il Tier 2 indaga sugli incidenti confermati, costruisce la cronologia e guida il contenimento. Il Tier 3 svolge una caccia alle minacce proattiva e sviluppa nuovi contenuti di rilevamento anziché attendere che scatti un'allerta. Intorno a loro si trovano ingegneri del rilevamento, addetti alla risposta agli incidenti e un responsabile del SOC che gestisce processo e metriche. La copertura è una scelta deliberata con un costo reale. Un SOC 8x5 vigila durante l'orario lavorativo; un SOC 24x7 segue il sole oppure organizza turni notturni affinché un attaccante non possa contare su un fine settimana tranquillo. La risposta giusta dipende dalla vostra esposizione alle minacce, dai vostri obblighi normativi e da ciò che potete sostenere senza esaurire il team. > **Un SIEM senza un SOC è solo archiviazione** Un SIEM che nessuno sorveglia è un archivio di log che pagate per riempire. Il SOC è ciò che rende quella stessa piattaforma un sistema di allerta precoce. Investite negli analisti e nel processo prima di acquistare altri strumenti. ## Costruire, esternalizzare o combinare Esistono tre modelli di approvvigionamento, e la maggior parte delle organizzazioni finisce in una posizione intermedia. **Confronto dei modelli di approvvigionamento del SOC** | Modello | Chi lo gestisce | Adatto a | | --- | --- | --- | | Interno | I vostri analisti e i vostri strumenti | Ambienti ad alta sensibilità che desiderano controllo e contesto completi | | Esternalizzato (MSSP) | Un Managed Security Service Provider | Team che necessitano rapidamente di una copertura 24x7 senza assumere un organico completo | | Ibrido | Responsabili interni più un MSSP o un MDR per le ore non lavorative | La maggior parte delle organizzazioni di medie dimensioni che bilanciano costo, copertura e controllo | Esternalizzare la sorveglianza non esternalizza la responsabilità. Un MSSP può coprire il turno di notte, ma il vostro team resta titolare dell'inventario degli asset, delle decisioni di risposta che toccano il vostro business e del rapporto con il resto dell'IT. La modalità di fallimento più comune consiste nel trattare un MSSP come qualcosa da impostare e dimenticare, per poi scoprire durante un incidente che nessuno ha mappato i vostri sistemi più critici né concordato chi possa isolare un host. ## Dove si colloca il SOC nella governance Il SOC è una capacità operativa, ma non vive nel vuoto. Esegue la parte di rilevamento e risposta di framework come l'insieme delle funzioni del NIST Cybersecurity Framework (identificare, proteggere, rilevare, rispondere, ripristinare) e fornisce prove a supporto dei controlli ISO/IEC 27001 relativi a logging, monitoraggio e gestione degli incidenti. In base a normative come NIS2 e DORA, la capacità di rilevare e segnalare rapidamente gli incidenti non è più facoltativa, e il SOC è di solito il luogo in cui tale capacità viene resa operativa. Per i professionisti, ciò significa che un SOC è valutato non solo sul tasso tecnico di rilevamento, ma anche sulla sua capacità di produrre la cronologia, le prove e le notifiche che auditor e regolatori si aspettano. --- ## Security Orchestration, Automation and Response (SOAR) **URL:** https://cyberacademy.net/it/resources/encyclopedia/soar **Last reviewed:** 2026-06-24 SOAR è lo strato che recepisce gli alert del SIEM ed esegue i playbook: arricchimento, triage, contenimento, ticketing. Obiettivo: ridurre l'MTTR e liberare gli analisti dal lavoro di copia-incolla. Attenzione alle promesse eccessive dei vendor: un SOAR vale quanto i playbook che si scrivono e si mantengono. La maggior parte dei progetti SOAR falliti ha esaurito gli autori di playbook. ## Cosa aggiunge il SOAR rispetto al SIEM Security Orchestration, Automation and Response è il livello di azione che si colloca dietro la rilevazione. Un SIEM è bravo a raccogliere i log, a correlarli e a generare avvisi, ma si ferma all'avviso. Il SOAR prende il testimone da lì e svolge il lavoro che altrimenti un analista farebbe a mano: arricchisce l'avviso con ricerche di reputazione e contesto sugli asset, decide quanto è urgente, apre o aggiorna un ticket e, dove la policy lo consente, intraprende azioni di contenimento come isolare un host, disabilitare un account o bloccare un indicatore a livello di firewall. L'unità di lavoro in un SOAR è il playbook, una sequenza di passaggi codificata che trasforma una procedura ripetibile di gestione degli incidenti in qualcosa che la piattaforma può eseguire da sola. L'orchestrazione e l'automazione sono due idee distinte che l'acronimo raggruppa. L'orchestrazione è il cablaggio: collegare il SIEM, l'EDR, il sistema di ticketing, il provider di identità, i feed di threat intelligence e il firewall affinché possano scambiarsi dati e comandi tramite un'unica console. L'automazione è ciò che viene eseguito attraverso quel cablaggio senza un essere umano nel ciclo. La maggior parte dei team maturi mantiene un punto di approvazione umana sui passaggi distruttivi, così la piattaforma arricchisce e classifica automaticamente, ma attende che un analista confermi prima di mettere in quarantena un server di produzione. Quel mix, il lavoro ripetitivo automatizzato con il giudizio umano sulle azioni di maggiore impatto, è ciò che i professionisti effettivamente implementano. ## SIEM, SOAR e il SOC Questi tre termini viaggiano insieme ed è facile confonderli. Non sono prodotti concorrenti. Descrivono ruoli diversi all'interno della stessa operazione di rilevazione e risposta. **SIEM vs SOAR vs SOC** | Termine | Cos'è | Il suo ruolo | | --- | --- | --- | | SIEM | Una piattaforma | Raccoglie e correla log e telemetria, quindi genera avvisi quando qualcosa sembra anomalo. | | SOAR | Una piattaforma | Prende quegli avvisi ed esegue i playbook: arricchimento, triage, contenimento, ticketing. | | SOC | Un team e una funzione | Gli analisti e il processo che gestiscono entrambi, indagano ciò che gli strumenti fanno emergere e decidono cosa fare. | Leggilo come una pipeline. Il SIEM trova il segnale, il SOAR svolge il lavoro di risposta ripetibile attorno a quel segnale, e il SOC sono le persone che possiedono l'intero ciclo e gestiscono tutto ciò che i playbook non possono. Il valore più evidente del SOAR è sul volume: segnalazioni di phishing, avvisi di malware comune, accessi sospetti. Tutto ciò che arriva in massa e segue uno schema di gestione prevedibile è candidato a un playbook, ed è da qui che proviene la riduzione del tempo medio di risposta e il motivo per cui gli analisti smettono di passare il turno su arricchimenti in copia-incolla. ## Perché i progetti SOAR riescono o falliscono La shortDefinition è schietta sulla trappola, e corrisponde a ciò che si vede sul campo: un SOAR vale solo quanto valgono i playbook che scrivi e mantieni, e la maggior parte dei progetti SOAR falliti è rimasta senza autori di playbook. La piattaforma viene fornita con connettori e un motore di workflow, ma viene fornita senza alcuna conoscenza del tuo ambiente. Ogni playbook deve essere progettato, costruito, testato contro avvisi reali e poi mantenuto man mano che i tuoi strumenti, la tua rete e i tuoi attaccanti cambiano. Un playbook che chiama un'API deprecata lo scorso trimestre è peggio di nessun playbook, perché fallisce silenziosamente nel mezzo di un incidente. Dal punto di vista della governance, il SOAR è il modo in cui diversi obiettivi di controllo smettono di essere aspirazionali. Nell'ambito di un sistema di gestione della sicurezza delle informazioni ISO/IEC 27001, supporta il lato tecnico della gestione degli incidenti, della registrazione e del monitoraggio, e produce un registro coerente e con marca temporale di come è stato gestito ogni incidente, che è esattamente la prova che un auditor desidera. Sostiene inoltre la capacità di risposta che il NIST Cybersecurity Framework presuppone e che normative come NIS2 e DORA si aspettano che le organizzazioni mantengano, in particolare riguardo alla gestione e segnalazione tempestiva degli incidenti significativi. Considera il SOAR come un moltiplicatore di forza per un processo che funziona, non come un sostituto dell'averne uno. > **Automatizza la procedura di cui ti fidi già** Un playbook codifica una procedura di risposta. Se la procedura manuale è poco chiara o non concordata, automatizzarla fa solo accadere la cosa sbagliata più velocemente. Scrivi e convalida prima il runbook con i tuoi analisti, poi codificalo, e mantieni un punto di approvazione umana su qualsiasi passaggio che possa mettere offline un sistema o un account. --- ## Tabletop exercise **URL:** https://cyberacademy.net/it/resources/encyclopedia/tabletop **Last reviewed:** 2026-06-24 Un tabletop exercise è una simulazione discussione-based di uno scenario disruptivo con il team di risposta attorno a un tavolo. Economico, rapido, rivela le lacune che nessuna revisione documentale individuerà. Pratica richiesta da ISO 22301, NIS 2 e DORA, e l'attività con il ROI più elevato in un programma BCM. Pianificarlo con cadenza trimestrale, non annuale. ## Che cos'è davvero un'esercitazione a tavolino Un'esercitazione a tavolino riunisce in una stessa sala le persone che dovrebbero rispondere a una perturbazione, le guida attraverso uno scenario realistico e chiede loro di spiegare cosa farebbero, passo dopo passo. Nessuno tocca i sistemi di produzione. Nessuno effettua il failover verso un sito di ripristino. Tutto il senso sta nella conversazione: chi decide, chi viene chiamato, cosa dice il piano rispetto a ciò che il team farebbe davvero, e dove il documento tace proprio nel momento in cui serve una decisione. È basata sulla discussione per impostazione, ed è per questo che è economica e rapida da condurre. Quel basso costo è la ragione per cui è l'attività a più alto rendimento di un programma di continuità o di risposta agli incidenti. Un facilitatore presenta una situazione iniziale, poi inietta nuove informazioni man mano che la discussione procede: anche il backup è cifrato, la stampa ha la notizia, il responsabile di reperibilità è irraggiungibile. Il team ragiona ad alta voce e le lacune emergono davanti alle persone in grado di correggerle. Una revisione documentale non produce mai questo. Leggere un piano conferma che esiste. Percorrere uno scenario rivela se qualcuno lo comprende, se l'elenco dei contatti è aggiornato e se due team danno entrambi per scontato che sia l'altro a dichiarare l'incidente. ## In cosa si distingue dagli altri tipi di esercitazione Le esercitazioni a tavolino si collocano a un'estremità di uno spettro di rigore. Sono volutamente il formato più leggero, il che le rende adatte a essere condotte spesso. Le esercitazioni più pesanti convalidano i meccanismi di cui un'esercitazione a tavolino si limita a parlare, a costi e disagi molto più elevati. **Confronto tra i tipi di esercitazione** | Tipo di esercitazione | Cosa fa | Costo e disagio | | --- | --- | --- | | Esercitazione a tavolino | Percorso di uno scenario basato sulla discussione, attorno a un tavolo; fa emergere le lacune di decisione e di piano | Basso | | Walkthrough / drill | Prova passo dopo passo di una singola procedura, come un albero delle chiamate o un ripristino | Da basso a moderato | | Esercitazione funzionale | Attivazione reale di specifiche funzioni di risposta senza incidere sulla produzione | Da moderato ad alto | | Test su vasta scala / in condizioni reali | Failover o ripristino reale in condizioni vicine a un incidente effettivo | Alto | L'errore comune è trattare l'esercitazione a tavolino come un sostituto del test in condizioni reali. Non lo è. Un'esercitazione a tavolino dimostra che le persone conoscono il piano e sanno prendere decisioni; solo un test funzionale o su vasta scala dimostra che i backup si ripristinano davvero e che gli obiettivi di ripristino sono raggiungibili. Un programma maturo usa entrambi: esercitazioni a tavolino frequenti che alimentano le lezioni che rendono utili i rari e costosi test reali. > **Pianificatele ogni trimestre, non ogni anno** I piani si disallineano nel momento in cui un'organizzazione si riorganizza, cambia un fornitore o adotta un nuovo sistema. Un'esercitazione a tavolino condotta una volta all'anno mette alla prova un piano già obsoleto. Condurle ogni trimestre mantiene attendibili gli elenchi dei contatti, i diritti decisionali e le ipotesi di ripristino, e tiene il team di risposta allenato anziché arrugginito. ## Il posto delle esercitazioni a tavolino nelle norme e nella regolamentazione Condurre esercitazioni non è facoltativo secondo i quadri che governano la resilienza. ISO 22301, lo standard internazionale per i sistemi di gestione della continuità operativa, richiede che le disposizioni di continuità siano esercitate e testate, e l'esercitazione a tavolino è il modo più comune con cui le organizzazioni soddisfano tale requisito tra un test reale e l'altro. Nell'Unione europea, la Direttiva NIS 2 si attende misure di continuità operativa e di gestione delle crisi da parte degli operatori dei settori essenziali e importanti, e il Digital Operational Resilience Act fissa aspettative di test esplicite per le entità finanziarie, dove le esercitazioni basate su scenari fanno parte del programma di test di resilienza. Ciò che cercano gli auditor e i regolatori non è solo che un'esercitazione sia avvenuta, ma che sia stata documentata e seguita da azioni. Un'esercitazione a tavolino che non produce alcun verbale né alcuna azione correttiva è teatro. Il valore si concretizza nel rapporto post-azione: cosa si è rotto, chi è responsabile della correzione e quando sarà ritestata. È questo ciclo, dallo scenario al rilievo, poi alla correzione e all'esercitazione successiva, a trasformare un'esercitazione a tavolino da semplice casella da spuntare nel motore che mantiene aggiornato un programma di continuità. --- ## Third-Party Risk Management (TPRM) **URL:** https://cyberacademy.net/it/resources/encyclopedia/tprm **Last reviewed:** 2026-06-24 Il TPRM è la disciplina che governa il rischio introdotto da fornitori, subappaltatori e service provider. Due diligence in fase di onboarding, clausole contrattuali, assurance continuativa, offboarding. Obbligatorio ai sensi di NIS 2 (sicurezza della supply chain) e DORA (rischio ICT da terze parti). Il blackout Crowdstrike e l'incidente SolarWinds hanno entrambi portato il TPRM all'attenzione dei board. Il Third-Party Risk Management (TPRM) tratta i vostri fornitori, subappaltatori e prestatori di servizi come un'estensione della vostra stessa superficie di attacco. La logica è semplice: se un fornitore tratta i vostri dati, gestisce la vostra infrastruttura o si inserisce nella vostra catena di fornitura, allora le sue debolezze diventano i vostri incidenti. Il TPRM è la disciplina che rende tale esposizione visibile, contrattuale e monitorata in modo continuo, anziché scoperta nel momento della violazione. ## Le quattro fasi che i professionisti eseguono realmente Il TPRM non è un questionario una tantum. È un ciclo di vita che va dal primo contatto con un fornitore al giorno in cui lo si disattiva. La maggior parte dei programmi maturi lo struttura in quattro fasi: - Due diligence di onboarding. Prima di firmare, si valuta il fornitore in base al rischio che introduce. Un provider SaaS che ospita dati personali e un fornitore di cancelleria non ricevono lo stesso livello di scrutinio. La classificazione per criticità è ciò che impedisce al programma di affogare. - Clausole contrattuali. Il contratto è il luogo in cui la garanzia diventa esigibile: obblighi di sicurezza, diritti di audit, tempistiche di notifica delle violazioni, divulgazione dei sub-responsabili, ubicazione dei dati e condizioni di uscita. Se non è nel contratto, non potrete pretenderlo in seguito. - Garanzia continua. Il rischio non si congela alla firma. La cadenza di rivalutazione, il monitoraggio dei certificati (ISO 27001, SOC 2), il monitoraggio continuo della postura di sicurezza del fornitore e la revisione delle dipendenze di quarta parte mantengono il quadro aggiornato. - Off-boarding. Quando il rapporto termina, si recuperano o si conferma la distruzione dei dati, si revocano gli accessi e si chiude l'esposizione residua. È la fase che i team saltano più spesso, e quella che lascia dietro di sé credenziali orfane. ## Perché è diventato un tema da consiglio di amministrazione Il TPRM risiedeva un tempo negli acquisti. È passato al consiglio di amministrazione perché i fallimenti più eclatanti dell'ultimo decennio sono arrivati attraverso la catena di fornitura, non dalla porta principale. L'incidente SolarWinds ha mostrato un attaccante in grado di raggiungere migliaia di organizzazioni compromettendo un singolo aggiornamento software affidabile. Il blackout CrowdStrike ha dimostrato che un aggiornamento difettoso di un singolo fornitore critico poteva bloccare le operazioni di interi settori contemporaneamente. Entrambi hanno ridefinito le terze parti come rischio sistemico, non come una casella da spuntare negli acquisti. La regolamentazione è seguita. La NIS 2 rende la sicurezza della catena di fornitura un dovere esplicito per i soggetti rientranti nel suo ambito e responsabilizza gli organi di gestione in caso di inadempienze. DORA si spinge oltre per i soggetti finanziari, dedicando uno dei suoi cinque pilastri al rischio derivante da terzi fornitori di TIC, imponendo requisiti contrattuali specifici e sottoponendo a vigilanza gli stessi fornitori critici di TIC. Per un'impresa regolamentata, il TPRM non è più una buona prassi, è un obbligo documentato. > **Una terza parte non è una quarta parte** Il vostro fornitore diretto è la terza parte. I loro fornitori sono le vostre quarte parti, e raramente li vedete. Il rischio di concentrazione si nasconde qui: molti dei vostri fornitori potrebbero dipendere dalla stessa regione cloud o dalla stessa libreria a monte. Mappare questa catena di dipendenze è ciò che distingue un programma di mera facciata da uno reale. ## In cosa il TPRM si differenzia dalle discipline affini Il TPRM convive con la gestione dei fornitori e la gestione dei rischi in generale, ma è più ristretto e più affilato di entrambe. La gestione dei fornitori ottimizza costo, prestazioni e rapporto commerciale. Il TPRM si occupa specificamente del rischio di sicurezza, resilienza, privacy e conformità che una terza parte introduce. Si differenzia anche dal lavoro interno sull'ISMS: i vostri controlli si fermano al vostro perimetro, ma la vostra responsabilità no. Potete esternalizzare l'attività, non potete esternalizzare il rischio. Questa asimmetria è la ragione stessa per cui la disciplina esiste. --- ## Threat-Led Penetration Testing (TLPT) **URL:** https://cyberacademy.net/it/resources/encyclopedia/tlpt **Last reviewed:** 2026-06-24 TLPT è l'esercizio di red team supervisionato dal regolatore, richiesto da DORA per le entità finanziarie significative. Basato sul framework TIBER-EU (Threat Intelligence-Based Ethical Red Teaming). Si estende su più mesi, è guidato dall'intelligence e supervisionato dall'autorità nazionale. Il test più rigoroso che un CISO si troverà ad affrontare, e quello che mette a nudo il SOC per quello che è realmente. ## Che cos'è davvero il penetration test guidato dalla minaccia Il penetration test guidato dalla minaccia è un esercizio di red team controllato condotto contro un'organizzazione in piena produzione, guidato da intelligence sulle minacce reale e supervisionato da un'autorità finanziaria. Il Digital Operational Resilience Act, DORA, ne fa un obbligo periodico per le entità finanziarie che un regolatore giudica sufficientemente significative da giustificarlo, e l'esercizio si fonda su TIBER-EU, il framework pubblicato dalla Banca Centrale Europea per il Threat Intelligence-Based Ethical Red Teaming. La parola decisiva è guidato: il test non è un elenco generico di vulnerabilità, ma una campagna plasmata da chi attaccherebbe realisticamente questa azienda e in che modo. Un fornitore di intelligence sulle minacce profila l'entità, individua gli avversari plausibili e i loro metodi, e consegna al red team una serie di scenari. Il red team tenta quindi di compromettere funzioni critiche in produzione usando quegli scenari, esattamente come farebbe un attaccante reale. Due proprietà separano il TLPT dal penetration test ordinario. Primo, prende di mira il parco in produzione reale e le persone e i processi che lo circondano, non una copia né una porzione delimitata, ragione per cui viene condotto secondo regole rigorose e da un piccolo team di controllo fidato. Secondo, è supervisionato. L'autorità nazionale competente e, ove pertinente, un team TIBER dedicato sono coinvolti nell'incarico, convalidando il perimetro, accreditando i tester e supervisionando come l'esercizio viene condotto. È questa supervisione a rendere il risultato credibile per un regolatore e non solo per l'azienda che lo ha commissionato. ## Come si svolge un incarico TLPT Un TLPT è un programma che si estende su più mesi, non una valutazione di una settimana, e si articola in fasi definite che il framework TIBER-EU stabilisce. Nella fase di preparazione, l'entità, il team di controllo e l'autorità concordano il perimetro, confermano quali funzioni critiche entrano in gioco e ingaggiano fornitori accreditati di intelligence sulle minacce e di red team. Nella fase di test, il fornitore di intelligence produce un rapporto di targeting sull'entità, e il red team lo usa per eseguire scenari di attacco realistici contro le funzioni in produzione, spesso nell'arco di molte settimane, tentando di raggiungere obiettivi definiti senza essere fermato. Nella fase di chiusura, il red team, il blue team e il team di controllo si riuniscono per ricostruire quanto accaduto, concordare le risultanze e costruire un piano di rimedio. Il dettaglio cruciale è che quasi nessuno all'interno dell'organizzazione sa che il test è in corso. I difensori, il centro operativo di sicurezza e i responder agli incidenti non vengono avvisati, perché tutto il senso è osservare come si comportano di fronte a una vera intrusione anziché a un'esercitazione programmata. Solo un team di controllo minuscolo ne è a conoscenza. È questo che fa del TLPT la misura più onesta di resilienza operativa che un CISO commissionerà, e quella che più affidabilmente espone il divario tra ciò che si crede faccia il SOC e ciò che esso realmente rileva sotto pressione. > **Il SOC è il vero soggetto del test** Poiché i difensori non vengono avvisati, un TLPT misura il rilevamento e la risposta così come sono davvero, non come li descrivono i runbook. Gli allarmi mai messi a punto, i percorsi di escalation che nessuno ha provato e i punti ciechi nella copertura emergono tutti qui. Considerate la fase di chiusura in purple teaming, in cui red e blue ricostruiscono insieme la campagna, come l'output più prezioso, non la violazione in sé. ## TLPT, TIBER-EU e penetration test ordinario **Dove si colloca il TLPT rispetto agli esercizi affini** | Dimensione | Penetration test standard | Penetration test guidato dalla minaccia (TLPT) | | --- | --- | --- | | Motore | Perimetro predefinito e una checklist del tester | Intelligence sulle minacce su misura per l'entità specifica | | Bersaglio | Spesso una copia di staging o un'applicazione delimitata | Funzioni critiche in produzione reale e le persone attorno a esse | | Consapevolezza dei difensori | Di solito informati, a volte di supporto | Non informati, solo un piccolo team di controllo sa | | Durata | Da giorni a poche settimane | Più mesi distribuiti su fasi definite | | Supervisione | Interna, commissionata dall'azienda | Supervisionato dall'autorità nazionale secondo TIBER-EU | | Innesco | Discrezionale o contrattuale | Un obbligo DORA per le entità significative designate | È utile tenere chiara la relazione tra i termini. TIBER-EU è il framework, la metodologia e le fasi. Il TLPT è l'obbligo regolamentare ai sensi di DORA che adotta e richiama quel framework per le entità finanziarie rientranti nel perimetro. Un penetration test standard resta un'attività preziosa e assai più frequente, ma risponde a una domanda più ristretta: esistono debolezze sfruttabili in questo sistema? Un TLPT risponde a una più difficile: se un avversario realistico puntasse oggi alle nostre funzioni più importanti, ce ne accorgeremmo soltanto, e sapremmo rispondere? I due sono complementari, e un'organizzazione che si attende un TLPT non smette di condurre test ordinari: li usa per chiudere le lacune evidenti affinché l'esercizio guidato dalla minaccia possa sondare quelle sottili. Ciò che i professionisti fanno davvero per prepararsi raramente riguarda l'acquisto di un altro strumento. Costruiscono un inventario accurato delle funzioni critiche e dei sistemi che le sostengono, in modo che il perimetro possa essere concordato onestamente. Si assicurano che i casi d'uso di rilevamento siano messi a punto e che il SOC abbia provato l'escalation contro scenari realistici anziché esercitazioni da tavolo. Confermano la struttura del team di controllo e le approvazioni legali e di rischio necessarie per condurre in sicurezza un'intrusione contro la produzione. E trattano le risultanze come input per la resilienza operativa e la pianificazione della continuità, perché ai sensi di DORA il rimedio non è un rapporto privato: è evidenza su cui il regolatore si aspetta che si agisca. --- ## Trattamento del rischio **URL:** https://cyberacademy.net/it/resources/encyclopedia/risk-treatment **Last reviewed:** 2026-06-24 Il trattamento del rischio è ciò che si fa una volta che il rischio è noto: evitarlo, ridurlo, trasferirlo, accettarlo. Ogni decisione è documentata, giustificata dalla propensione al rischio e tracciata attraverso il SoA fino ai controlli e alle evidenze operative. La maggior parte degli audit falliti si riduce a un unico problema: il piano di trattamento e la realtà si sono discostati, e nessuno ha aggiornato il SoA. ## Le quattro opzioni di trattamento Il trattamento del rischio è la fase in cui la valutazione si traduce in azione. Una volta che un rischio è stato identificato, analizzato e valutato rispetto ai tuoi criteri, devi decidere come affrontarlo. Il vocabolario convenzionale, condiviso da ISO 31000 e ISO/IEC 27005, ti offre quattro famiglie di risposta. Non sono ordinate dalla migliore alla peggiore; la scelta giusta dipende dal rischio, dal costo del controllo e dalla propensione approvata dai vertici. - Evitare: interrompere l'attività che genera il rischio, oppure svolgerla in modo diverso. Dismetti il servizio esposto, elimini la funzionalità o esci dal mercato che innesca l'esposizione. - Ridurre (modificare): applicare controlli che abbassino la probabilità, l'impatto, o entrambi. È la via più comune e quella che si collega direttamente al tuo insieme di controlli. - Trasferire (condividere): spostare parte della conseguenza finanziaria o operativa verso una terza parte, di norma tramite un'assicurazione o una clausola contrattuale. Il trasferimento sposta raramente l'intero rischio; ti resta il residuo reputazionale e regolamentare. - Accettare (mantenere): decidere che il rischio residuo è tollerabile e conviverci, mettendolo agli atti. L'accettazione è una decisione legittima, non un'omissione, purché la firmi l'autorità competente. > **L'accettazione è una decisione, non uno stato predefinito** Un rischio che non hai mai trattato non equivale a un rischio che hai formalmente accettato. L'accettazione deve essere esplicita, datata e firmata da qualcuno con l'autorità che la tua propensione al rischio gli attribuisce. Un rischio non trattato che giace silenziosamente nel registro è esattamente ciò che un auditor segnala. ## Dalla decisione alla prova: la catena che gli auditor seguono La parte difficile del trattamento del rischio non è scegliere un'opzione, è mantenere coerente la tracciabilità documentale. Ogni decisione dovrebbe essere giustificata con riferimento alla propensione al rischio documentata, registrata in un piano di trattamento del rischio e poi tracciata fino ai controlli che la attuano e alle prove che essi operano. In un sistema di gestione della sicurezza delle informazioni ISO/IEC 27001 è qui che risiede la Dichiarazione di Applicabilità (SoA): registra quali controlli dell'Annex A si applicano, perché, e dove si trovano le prove. Il rilievo di audit più frequente in quest'area è lo scostamento. Il piano di trattamento diceva una cosa, la SoA ne diceva un'altra, e l'operatività sul campo era andata oltre entrambe. Un controllo viene dismesso, un progetto cambia ambito, un fornitore viene sostituito, e nessuno aggiorna i documenti. Le decisioni possono essere state tutte ragionevoli prese singolarmente, ma la catena non si riconcilia più, e quell'incoerenza è ciò che produce una non conformità. ### Rischio residuo e rivalutazione Il trattamento non fa sparire un rischio. Ciò che resta dopo l'applicazione dei controlli è il rischio residuo, ed è il valore che il proprietario del rischio accetta effettivamente. La buona pratica consiste nel rieseguire l'analisi sul rischio trattato in modo che il livello residuo sia esplicito, per poi reindirizzarlo alla stessa autorità di accettazione. ISO/IEC 27005, allineata fin dalla revisione del 2022 ai principi di ISO 31000, lo inquadra come un ciclo iterativo anziché un esercizio una tantum: tratti, misuri ciò che resta, accetti o tratti di nuovo. ## Ciò che i professionisti fanno davvero Nel lavoro GRC quotidiano, il trattamento del rischio viene gestito come un piano vivo anziché come un deliverable di progetto. Un ritmo praticabile assomiglia a questo: 1. Collega ogni decisione di trattamento a un rischio denominato nel registro e all'enunciato di propensione che la giustifica, così che la motivazione sopravviva al ricambio del personale. 1. Assegna un unico responsabile rendicontabile e una data obiettivo a ogni azione di «ridurre», e monitorali come qualsiasi altro impegno. 1. Mantieni riconciliati la SoA, il piano di trattamento e le prove dei controlli con una cadenza fissa, non solo prima di un audit. 1. Registra il rischio residuo e la firma di accettazione per tutto ciò che non mitighi completamente, compresi i rischi che trasferisci. Fatto così, il piano di trattamento smette di essere teatro per l'audit e diventa il luogo in cui l'organizzazione può dire onestamente a cosa è esposta e chi ha deciso che ciò fosse accettabile. --- ## Zero Trust **URL:** https://cyberacademy.net/it/resources/encyclopedia/zero-trust **Last reviewed:** 2026-06-24 Zero Trust è il modello di sicurezza in cui si smette di fidarsi del perimetro di rete. Ogni decisione di accesso viene autenticata, autorizzata e valutata contestualmente, ogni volta. L'identità diventa il perimetro. Nato in Forrester, diffuso da BeyondCorp di Google, codificato da NIST SP 800-207. Oltre i pitch deck dei vendor: è un'architettura, non un prodotto. ## Dalla fiducia perimetrale alla verifica di ogni richiesta Il modello tradizionale trattava la rete aziendale come una zona affidabile. Una volta dentro il firewall, attraverso la VPN, dietro il perimetro, eri implicitamente autorizzato a muoverti lateralmente. Lo Zero Trust rifiuta questo presupposto. Non esiste un interno affidabile. Una richiesta da un portatile connesso alla rete locale dell'ufficio è trattata con la stessa diffidenza di una richiesta proveniente da un bar, perché la posizione non basta più a guadagnare fiducia. Ogni decisione di accesso viene presa da capo: chi chiede, da quale dispositivo, con quale postura, per quale risorsa, in quale contesto, e se quella combinazione è autorizzata in questo preciso momento. Questo conta perché il perimetro si è dissolto nella pratica già da anni. Il personale lavora da casa, le applicazioni risiedono nel SaaS di terzi, e una sola credenziale carpita tramite phishing significava un tempo libertà di movimento in tutto il parco. Lo Zero Trust riduce questo raggio d'impatto. L'attaccante che ruba una password si scontra ancora con i controlli del dispositivo, l'autorizzazione continua e la segmentazione a ogni passaggio, così che una singola compromissione non degenera più in una violazione completa. ## Ciò che i professionisti costruiscono davvero Guarda oltre le presentazioni commerciali dei fornitori. Lo Zero Trust è un'architettura e un modello operativo, non una scatola che si acquista. NIST SP 800-207 lo descrive in termini di un motore di policy che prende le decisioni, un amministratore di policy che le applica, e punti di applicazione delle policy posti davanti alle risorse. Il lavoro pratico consiste nel rendere l'identità il piano di controllo e nel verificare ogni richiesta rispetto alla policy. I mattoni ricorrenti sono: - Identità e autenticazione forti, con l'MFA come base anziché come aggiunta, affinché l'identità all'origine di una richiesta sia realmente verificata. - Postura e stato di salute del dispositivo, perché un utente verificato su un dispositivo compromesso o non gestito resta un rischio da valutare. - Privilegio minimo e accesso just-in-time, concedendo i diritti più ristretti necessari e rimuovendo gli accessi permanenti che gli attaccanti amano ereditare. - Micro-segmentazione, affinché un punto d'appoggio in un carico di lavoro non apra un percorso piatto verso tutto il resto. - Valutazione e registrazione continue, perché la fiducia viene rivalutata man mano che il contesto cambia, e non concessa una volta sola all'accesso e poi dimenticata. > **È un percorso, non un interruttore** Nessuna organizzazione cambia una singola impostazione e diventa Zero Trust. La maturità è incrementale: parti dall'identità e dall'MFA, restringi i privilegi, segmenta la rete, poi aggiungi uno strato di monitoraggio continuo. Accogli con sano scetticismo qualsiasi prodotto venduto come Zero Trust chiavi in mano: è nel migliore dei casi un punto di applicazione all'interno di un'architettura molto più ampia. ## In cosa si distingue dalle idee affini Lo Zero Trust è facile da confondere con i principi su cui si fonda. Il privilegio minimo è uno dei suoi ingredienti: limita ciò che un'identità può raggiungere, ma da solo presuppone ancora che la rete sia affidabile. La difesa in profondità è l'istinto più antico e più ampio di sovrapporre controlli indipendenti; lo Zero Trust è un modo specifico di rimuovere quell'interno morbido e affidabile che le difese a strati classiche lasciavano spesso al loro posto. La gestione delle identità e degli accessi fornisce la meccanica, le directory, l'autenticazione e l'autorizzazione, che lo Zero Trust utilizza come fondamento. In sintesi, IAM, MFA e privilegio minimo sono componenti, mentre lo Zero Trust è la filosofia di progettazione che li orchestra in una verifica continua e contestuale. Nel panorama degli standard e delle politiche l'idea è ormai consolidata. NIST SP 800-207 è la definizione di riferimento, e il NIST ha pubblicato linee guida di implementazione complementari. Negli Stati Uniti i mandati governativi hanno spinto le agenzie verso architetture Zero Trust, e organismi europei come l'ENISA lo citano come direzione di marcia per una sicurezza resiliente e incentrata sull'identità. Gli auditor si aspettano sempre più di vedere i principi riflessi nella progettazione degli accessi, anche quando un framework non nomina esplicitamente lo Zero Trust. --- # COURSES CATALOGUE ## CISA: Certified Information Systems Auditor **URL:** https://cyberacademy.net/it/courses/cisa **Issuer:** ISACA **Level:** practitioner **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 La certificazione di riferimento ISACA per l'audit IT. Cinque domini, esame di quattro ore, la credenziale di audit predefinita per gli incarichi Big Four. Corso di quattro giorni con un re-sit incluso. **You will learn how to:** - Pianificare ed eseguire un audit IS risk-based allineato agli standard ISACA. - Valutare la governance e la gestione dell'IT rispetto a COBIT e ISO 27001. - Verificare i controlli nell'acquisizione, sviluppo e implementazione dei sistemi informativi. - Eseguire l'audit delle operazioni IS, della resilienza aziendale e della protezione degli asset. - Produrre report di audit che reggano a una revisione Big Four. **For:** - IT auditor che passano dall'internal audit a un ruolo specializzato in audit IS. - Responsabili della compliance in settori regolamentati (bancario, assicurativo, sanitario). - Security analyst in transizione verso l'audit o il GRC. - Consulenti Big Four orientati a incarichi a contatto con i clienti. **NOT for (when you should not take this certification):** - Aspiranti CISO senza interesse per l'audit. CISM è l'alternativa orientata al management. - Risk manager senza una componente di audit. CRISC è più indicato. - Professionisti con meno di tre anni di esperienza. ISACA riconosce solo l'esperienza maturata nei dieci anni precedenti la domanda. --- ## CISM: Certified Information Security Manager **URL:** https://cyberacademy.net/it/courses/cism **Issuer:** ISACA **Level:** manager **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 La certificazione di riferimento ISACA per la gestione della sicurezza. Quattro domini, richiesta in circa il 60% delle offerte per CISO. Corso di quattro giorni con un esame di recupero incluso. **You will learn how to:** - Progettare e governare un programma di sicurezza delle informazioni allineato alla strategia aziendale. - Gestire un processo di information risk management a supporto delle decisioni del consiglio di amministrazione. - Costruire e operare il programma di sicurezza (risorse, architettura, awareness, rischio dei fornitori). - Guidare la gestione degli incidenti, dalla preparazione alle lezioni apprese. - Tradurre la postura tecnica di sicurezza in una narrativa per il board senza perdere precisione. **For:** - Aspiranti CISO e vice CISO. - Security architect in transizione verso ruoli di gestione del personale. - Direttori IT che assumono la responsabilità del portafoglio sicurezza. - Consulenti che supportano la progettazione di programmi di sicurezza. **NOT for (when you should not take this certification):** - Ingegneri della sicurezza operativa senza ambizioni manageriali. CISSP o certificazioni tecniche specializzate sono più adatte. - Auditor IS senza interesse operativo. CISA rimane la certificazione primaria. - Analisti della sicurezza junior con meno di tre anni di esperienza. --- ## CRISC: Certified in Risk and Information Systems Control **URL:** https://cyberacademy.net/it/courses/crisc **Issuer:** ISACA **Level:** risk-manager **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 La certificazione di riferimento ISACA per il rischio IT. Quattro domini che collegano il rischio di business ai controlli dei sistemi informativi. Il complemento naturale a CISA e a ISO 31000 / 27005 per il vocabolario ISACA. **You will learn how to:** - Integrare la gestione del rischio IT nella governance aziendale. - Identificare, valutare e classificare il rischio IT rispetto agli obiettivi di business. - Progettare opzioni di risposta al rischio allineate all'appetito e alla tolleranza al rischio. - Monitorare il rischio IT e riferire al board con un linguaggio che generi decisioni concrete. - Mappare il vocabolario CRISC su ISO 31000 / 27005 / NIST RMF in contesti di audit misti. **For:** - IT risk manager, analisti GRC e consulenti di rischio. - Business analyst in transizione verso il rischio IT. - Auditor IS che estendono il proprio ruolo dal testing dei controlli alla consulenza sul rischio. - CISO e vice CISO che necessitano del vocabolario di quantificazione del rischio riconosciuto dal board. **NOT for (when you should not take this certification):** - Professionisti tecnici del rischio puro (vulnerability management, threat hunting). Considerare CISSP o credenziali specializzate. - Professionisti del rischio formati su ISO che non operano in contesti IT o IS. ISO 31000 Lead Risk Manager ha una portata più ampia. - Professionisti con meno di tre anni di esperienza rilevante. --- ## AAIA: Advanced in AI Audit **URL:** https://cyberacademy.net/it/courses/aaia **Issuer:** ISACA **Level:** expert **Duration:** 3 days **Price:** Live €2500 · Self-paced €490 La credenziale avanzata ISACA per i revisori che si avvicinano all'intelligenza artificiale. Metodologia di audit per i sistemi AI, valutazione del rischio AI, framework di governance AI. Tre giorni intensivi; CISA raccomandato come base. **You will learn how to:** - Pianificare ed eseguire un audit dei sistemi AI rispetto all'ISO 42001 AIMS e agli obblighi dell'AI Act. - Valutare i controlli del ciclo di vita del modello (governance dei dati, addestramento, validazione, monitoraggio, dismissione). - Verificare i controlli di fairness, spiegabilità e monitoraggio dei bias dell'AI rispetto alle aspettative normative e di audit. - Effettuare l'audit del rischio dei fornitori AI e delle dipendenze da modelli di terze parti. - Produrre rapporti di audit AI in grado di superare la revisione degli organismi notificati e delle autorità di vigilanza. **For:** - Senior IT auditor che si avvicinano all'assurance sull'AI. - GRC manager che sviluppano un programma di audit AI. - Responsabili della conformità in settori regolamentati che adottano l'AI (banche, assicurazioni, sanità, settore pubblico). - Senior manager e director delle Big Four che assumono la leadership su engagement AI. **NOT for (when you should not take this certification):** - Professionisti senza background di audit. Prima CISA, poi AAIA. - Ingegneri AI che desiderano apprendere l'audit. L'AAIA presuppone padronanza dell'audit; ISO 42001 Lead Auditor è un punto di partenza più adeguato. - Revisori junior con meno di due anni di esperienza. --- ## AAIR: Advanced in AI Risk **URL:** https://cyberacademy.net/it/courses/aair **Issuer:** ISACA **Level:** expert **Duration:** 3 days **Price:** Live €2500 · Self-paced €490 La credenziale avanzata ISACA per i risk manager che costruiscono un programma di AI risk. Valutazione del rischio AI, trattamento del rischio, governance del rischio AI. Tre giorni intensivi; CRISC raccomandato come base. **You will learn how to:** - Integrare il rischio AI nel framework di enterprise risk management insieme al rischio cyber, operativo e strategico. - Valutare il rischio AI lungo l'intero ciclo di vita del modello (acquisizione, progettazione, deployment, monitoraggio, dismissione) con metodologia allineata agli AIMS. - Quantificare i rischi specifici dell'AI (bias, allucinazioni, deriva del modello, esposizione normativa ai sensi dell'AI Act) per la reportistica al board. - Progettare opzioni di trattamento del rischio AI bilanciando la velocità di innovazione con l'esposizione normativa e reputazionale. - Costruire la telemetria di monitoraggio e reportistica del rischio AI per la supervisione continuativa. **For:** - IT risk manager che estendono il portafoglio all'AI. - CRO e vice CRO che aggiungono l'AI alla tassonomia del rischio enterprise. - GRC manager che costruiscono il workstream di AI risk. - Compliance officer in settori regolamentati che quantificano l'esposizione AI per l'approvazione del board. **NOT for (when you should not take this certification):** - Professionisti privi di background in risk management. Prima CRISC o ISO 31000 Lead Risk Manager. - Ingegneri AI che vogliono apprendere il risk management. AAIR presuppone padronanza da risk practitioner. - Risk analyst junior con meno di due anni di esperienza. --- ## AAISM: Advanced in AI Security Management **URL:** https://cyberacademy.net/it/courses/aaism **Issuer:** ISACA **Level:** expert **Duration:** 3 days **Price:** Live €2500 · Self-paced €490 La credenziale avanzata ISACA per i security manager che costruiscono un programma di sicurezza AI. Threat modelling AI, ciclo di vita sicuro dei modelli, operazioni di sicurezza AI. Tre giorni intensivi; CISM raccomandato come base. **You will learn how to:** - Progettare e governare un programma di sicurezza AI allineato a ISO 42001 e all'AI Act. - Condurre il threat modelling AI (prompt injection, model poisoning, adversarial examples, esfiltrazione di dati tramite inferenza). - Gestire la sicurezza AI in produzione: monitoraggio, risposta agli incidenti, model drift, rischio supply-chain per le dipendenze dai foundation model. - Integrare la sicurezza AI nei programmi ISMS (ISO 27001) e AIMS (ISO 42001) più ampi. - Tradurre la postura di sicurezza AI per il consiglio di amministrazione e il comitato di audit. **For:** - CISO e vice CISO che assumono la supervisione della sicurezza AI. - Security programme manager che costruiscono il workstream di sicurezza AI. - Security architect che progettano i controlli di sicurezza per sistemi AI. - GRC manager che integrano il rischio AI nel programma di sicurezza. **NOT for (when you should not take this certification):** - Specialisti esclusivamente red-team o di AI offensiva. AAISM tratta governance e management, non pentesting. - ML engineer operativi che desiderano apprendere la sicurezza. CISSP o un corso tecnico specializzato in AI security è più indicato. - Security manager privi di esperienza gestionale pregressa (meno di tre anni). --- ## CGEIT: Certified in the Governance of Enterprise IT **URL:** https://cyberacademy.net/it/courses/cgeit **Issuer:** ISACA **Level:** manager **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 La credenziale di riferimento ISACA per la governance IT a livello esecutivo. Cinque domini che coprono framework, gestione strategica, realizzazione dei benefici, ottimizzazione del rischio e ottimizzazione delle risorse. Pensata per CIO, responsabili della governance e dirigenti IT con interlocuzione diretta con il board. **You will learn how to:** - Progettare e gestire un framework di governance IT aziendale allineato a COBIT e alla strategia di business. - Guidare i cicli di gestione strategica IT approvati dal board e validati dagli audit. - Quantificare e rendicontare la realizzazione dei benefici degli investimenti IT. - Integrare il rischio IT nel framework di gestione del rischio aziendale. - Ottimizzare le risorse IT (persone, tecnologia, partnership con i fornitori) rispetto agli obiettivi di governance. **For:** - CIO e vice CIO con portafoglio di governance. - Responsabili della governance IT in settori regolamentati (banca, assicurazioni, utilities, settore pubblico). - Senior manager delle Big Four che conducono revisioni di governance. - Membri del board in comitati tecnologici o di audit. **NOT for (when you should not take this certification):** - Manager IT operativi senza esposizione esecutiva. CISM o CRISC sono più adatti. - Auditor IS in cerca di una credenziale di audit. CISA rimane la credenziale primaria. - Professionisti con meno di cinque anni di esperienza a livello di governance. --- ## CDPSE: Certified Data Privacy Solutions Engineer **URL:** https://cyberacademy.net/it/courses/cdpse **Issuer:** ISACA **Level:** practitioner **Duration:** 3 days **Price:** Live €2900 · Self-paced €790 La certificazione ISACA all'intersezione tra privacy e tecnologia. Tre domini che coprono governance della privacy, architettura della privacy e ciclo di vita dei dati. La certificazione per i privacy engineer che costruiscono sistemi conformi al GDPR, non semplici policy. **You will learn how to:** - Progettare architetture di dati che soddisfino il GDPR e i regimi di privacy equivalenti per costruzione. - Implementare controlli di privacy lungo l'intero ciclo di vita dei dati (raccolta, trattamento, conservazione, condivisione, cancellazione). - Condurre valutazioni d'impatto sulla privacy affiancate a revisioni dei controlli tecnici. - Tradurre i requisiti legali in materia di privacy in specifiche di ingegneria utilizzabili dai team di prodotto. - Gestire il monitoraggio della privacy e la risposta agli incidenti specifici ai diritti degli interessati e alle violazioni dei dati. **For:** - Privacy engineer e DPO con solide competenze tecniche. - Data architect e software architect che costruiscono sistemi conformi al GDPR. - Security engineer che ampliano le proprie competenze verso la privacy-by-design. - CDPO che integrano la propria competenza legale con credenziali ingegneristiche. **NOT for (when you should not take this certification):** - DPO esclusivamente giuridici senza esposizione all'ingegneria. PECB CDPO è più adatto. - Privacy analyst junior con meno di tre anni di esperienza trasversale ai domini. --- ## CCOA: Certified Cybersecurity Operations Analyst **URL:** https://cyberacademy.net/it/courses/ccoa **Issuer:** ISACA **Level:** practitioner **Duration:** 3 days **Price:** Live €2200 · Self-paced €690 La credenziale pratica ISACA per analisti SOC e operatori di cyber-defence. Cinque domini che coprono monitoraggio, risposta agli incidenti, threat hunting e threat intelligence. Livello practitioner; l'esame combina scenari e domande a risposta multipla. **You will learn how to:** - Gestire uno stack di security monitoring (SIEM, EDR, telemetria di rete) a livello SOC tier-2. - Condurre un ciclo completo di risposta agli incidenti dal triage alle lessons learned, con la documentazione richiesta dagli auditor. - Eseguire threat hunt basati su ipotesi utilizzando MITRE ATT&CK come griglia di navigazione. - Consumare e produrre threat intelligence actionable in formati standard (STIX/TAXII). - Collegare il piano operativo cyber al programma GRC più ampio: incidenti tradotti in rischio, controlli tradotti in telemetria. **For:** - Analisti SOC tier-1 che avanzano al tier-2. - Professionisti della risposta agli incidenti che aggiungono una credenziale riconosciuta. - Threat hunter che formalizzano la propria metodologia. - Cyber engineer in transizione verso un ruolo di defence operations. **NOT for (when you should not take this certification):** - Professionisti GRC senza background operativo. CISA o CISM è più adatto. - CISO in divenire. Valutare CISM. - Principianti senza alcuna esperienza pratica di sicurezza difensiva. --- ## COBIT 2019 Foundation **URL:** https://cyberacademy.net/it/courses/cobit-foundation **Issuer:** ISACA **Level:** foundation **Duration:** 2 days **Price:** Live €1250 La certificazione entry-level per il framework di governance COBIT 2019. Corso di due giorni che copre la struttura del framework, i principi, i fattori di progettazione e i componenti del sistema di governance. Sessione live con esame ISACA incluso. **You will learn how to:** - Orientarsi nel framework COBIT 2019: obiettivi di governance, obiettivi di gestione, fattori di progettazione. - Applicare il processo di progettazione del sistema di governance a un contesto aziendale reale. - Mappare COBIT sui framework adiacenti (ITIL, ISO 27001, ISO 38500, NIST CSF). - Posizionare COBIT come livello di integrazione al di sopra degli standard operativi in un programma multi-framework. **For:** - IT manager e analisti GRC che si avvicinano alla governance IT aziendale. - Auditor che intendono ampliare il proprio vocabolario di framework oltre ISO 27001. - Consulenti che propongono progetti di progettazione di sistemi di governance. **NOT for (when you should not take this certification):** - Tecnici operativi senza esposizione alla governance. - Futuri CISO in cerca di una certificazione di leadership. CISM è più indicato. --- ## COBIT 2019 Design & Implementation **URL:** https://cyberacademy.net/it/courses/cobit-design-implementation **Issuer:** ISACA **Level:** practitioner **Duration:** 3 days **Price:** Live €1900 La credenziale COBIT avanzata. Tre giorni di formazione in gruppo, incentrati sull'applicazione dei fattori di progettazione per costruire un sistema di governance su misura, poi sulla definizione della roadmap di implementazione. Sessione live con esame ISACA incluso. Foundation è un prerequisito. **You will learn how to:** - Eseguire il workflow di progettazione COBIT 2019 dall'inizio alla fine per un'azienda reale. - Valutare e applicare i fattori di progettazione per orientare il sistema di governance. - Costruire la roadmap di implementazione con la cascata degli obiettivi prioritizzati e i target di capability. - Guidare il change management per l'adozione della governance nei team IT e di business. **For:** - Responsabili IT governance che implementano il design system nella propria organizzazione. - Consulenti GRC che propongono engagement di governance design. - Auditor interni che validano le scelte di progettazione del sistema di governance. **NOT for (when you should not take this certification):** - Professionisti privi della COBIT Foundation. Seguire prima il corso Foundation. --- ## Cybersecurity Audit Certificate (ISACA) **URL:** https://cyberacademy.net/it/courses/cybersecurity-audit-certificate **Issuer:** ISACA **Level:** practitioner **Duration:** 2 days **Price:** Live €1450 Il certificato ISACA dedicato all'audit della cybersecurity. Percorso in due giorni, a coorti, basato su scenari reali, progettato per collegare il classico audit IS (CISA) alle moderne operazioni di cyber-defence. Utile per auditor che valutano programmi SOC, IR e threat intelligence. **You will learn how to:** - Pianificare ed eseguire un audit di cybersecurity che copra monitoring, incident response e threat intelligence. - Valutare i controlli di cyber-defence rispetto ai framework di settore (NIST CSF, ISO 27001, CIS Controls). - Auditare un SOC: ruoli, runbook, telemetria e metriche degli incidenti. - Verificare gli esercizi di breach-readiness e i risultati dei tabletop rispetto al playbook. **For:** - Auditor IS che ampliano le proprie competenze nella valutazione della cybersecurity. - Team di internal audit che integrano il cyber nella tassonomia dell'audit universe. - Auditor delle Big Four che coprono i controlli cyber nell'ambito di engagement di assurance più ampi. **NOT for (when you should not take this certification):** - Operatori SOC hands-on. Il CCOA è più adatto. --- ## IT Audit Fundamentals (ISACA) **URL:** https://cyberacademy.net/it/courses/it-audit-fundamentals **Issuer:** ISACA **Level:** foundation **Duration:** 2 days **Price:** Live €1100 Il certificato ISACA di livello base sull'audit IT. Corso di due giorni in formato cohort che copre pianificazione dell'audit, fieldwork, prove e reporting attraverso il vocabolario ISACA. Un percorso di avvicinamento solido prima del CISA. **You will learn how to:** - Applicare un ciclo di vita dell'audit ai controlli in ambito IT. - Pianificare gli incarichi, raccogliere le prove e redigere i rilievi in modo da resistere alla revisione. - Distinguere le attività di prima, seconda e terza linea in una tipica impresa. - Collocare l'audit IT all'interno del programma di assurance più ampio. **For:** - Professionisti IT che esplorano un percorso di carriera nell'audit. - Analisti GRC agli inizi della loro specializzazione in audit. - Consulenti che si preparano al CISA e desiderano un riscaldamento strutturato. **NOT for (when you should not take this certification):** - Professionisti che gestiscono già programmi di audit. Procedere direttamente al CISA. --- ## IT Risk Fundamentals (ISACA) **URL:** https://cyberacademy.net/it/courses/it-risk-fundamentals **Issuer:** ISACA **Level:** foundation **Duration:** 2 days **Price:** Live €1100 Il certificato ISACA entry-level sul rischio IT. Un percorso di due giorni in coorte che introduce l'identificazione, la valutazione, la risposta e il monitoraggio del rischio attraverso il vocabolario ISACA. Un punto di ingresso solido prima di affrontare CRISC. **You will learn how to:** - Applicare un ciclo di vita della gestione del rischio ai rischi del dominio IT. - Costruire un registro dei rischi correlato all'impatto sul business, non solo ai risultati tecnici. - Distinguere le attività di identificazione, valutazione, risposta e monitoraggio del rischio. - Collocare il rischio IT all'interno del più ampio programma di rischio aziendale. **For:** - Professionisti IT che si avvicinano per la prima volta alla gestione del rischio. - Analisti GRC all'inizio del loro percorso di specializzazione nel rischio. - Auditor che si preparano per CRISC e desiderano un riscaldamento strutturato. **NOT for (when you should not take this certification):** - Professionisti che gestiscono già un programma di rischio aziendale. Passare direttamente a CRISC. --- ## ISO27001 - Foundation **URL:** https://cyberacademy.net/it/courses/iso27001-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formazione certificata ISO27001 - Foundation accreditata PECB. Corso online in diretta con istruttori esperti e garanzia certificazione-o-rimborso. Iscriviti... --- ## AI Risk Manager **URL:** https://cyberacademy.net/it/courses/ai-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione PECB AI Risk Manager. Formazione live online con garanzia certificato o rimborso. --- ## Certified Artificial Intelligence Professional (CAIP) **URL:** https://cyberacademy.net/it/courses/certified-artificial-intelligence-professional-caip **Issuer:** PECB **Level:** expert **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione PECB Certified Artificial Intelligence Professional (CAIP). Formazione live online con garanzia certificato o rimborso. --- ## Certified CISO by PECB **URL:** https://cyberacademy.net/it/courses/certified-ciso-by-pecb **Issuer:** PECB **Level:** expert **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formazione ufficiale PECB per la certificazione Certified CISO by PECB. Corso live online con istruttori esperti e garanzia certificazione-o-rimborso. Iscriviti... --- ## Certified Lead Crisis Manager **URL:** https://cyberacademy.net/it/courses/certified-lead-crisis-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione PECB Certified Lead Crisis Manager. Formazione live online con garanzia certificato o rimborsato. --- ## PECB CMMC Foundations **URL:** https://cyberacademy.net/it/courses/cmmc-foundations **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formazione certificante PECB CMMC Foundations ufficialmente accreditata PECB. Corso live online con istruttori esperti e garanzia certificazione o rimborso. Iscriviti... --- ## Cyber Threat Analyst **URL:** https://cyberacademy.net/it/courses/cyber-threat-analyst **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione Cyber Threat Analyst accreditata PECB. Formazione live online con garanzia certificato o rimborsato. --- ## Cybersecurity Foundation **URL:** https://cyberacademy.net/it/courses/cybersecurity-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificazione Cybersecurity Foundation accreditata PECB. Formazione live online con garanzia certificato o rimborso. --- ## DORA Foundation **URL:** https://cyberacademy.net/it/courses/dora-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 DORA Foundation per il settore finanziario. Gestione del rischio ICT e segnalazione degli incidenti. Accreditato PECB. --- ## DORA Lead Manager **URL:** https://cyberacademy.net/it/courses/dora-lead-manager **Issuer:** PECB **Level:** manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Diventi un DORA Lead Manager certificato. Implementi la resilienza operativa digitale per le istituzioni finanziarie. Corso accreditato PECB con esame incluso. --- ## EBIOS Risk Manager **URL:** https://cyberacademy.net/it/courses/ebios-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Formazione ufficiale per la certificazione EBIOS RM. Apprendere la metodologia di valutazione del rischio ANSSI in 5 workshop. Corso accreditato PECB con esercizi pratici ed esame. --- ## GDPR - Certified Data Protection Officer **URL:** https://cyberacademy.net/it/courses/gdpr-certified-data-protection-officer **Issuer:** PECB **Level:** expert **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione GDPR - Certified Data Protection Officer accreditata PECB. Formazione live online con garanzia soddisfatti o rimborsati. --- ## GDPR Foundation **URL:** https://cyberacademy.net/it/courses/gdpr-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificazione GDPR Foundation accreditata PECB. Formazione online in diretta con garanzia certificato o rimborso. --- ## ISO 22301 Foundation **URL:** https://cyberacademy.net/it/courses/iso-22301-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificazione ISO 22301 Foundation accreditata PECB. Formazione online in diretta con garanzia certificato o rimborso. --- ## ISO 22301 Lead Auditor **URL:** https://cyberacademy.net/it/courses/iso-22301-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione ISO 22301 Lead Auditor accreditata PECB. Formazione live online con garanzia certificato o rimborso. --- ## ISO 22301 Lead Implementer **URL:** https://cyberacademy.net/it/courses/iso-22301-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione ISO 22301 Lead Implementer accreditata PECB. Formazione live online con garanzia certificato o rimborso. --- ## ISO 27005 Foundation **URL:** https://cyberacademy.net/it/courses/iso-27005-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formazione certificata ISO 27005 Foundation accreditata PECB. Corso live online con istruttori esperti e garanzia certificazione-o-rimborso. Iscriviti ... --- ## ISO 27005 Lead Risk Manager **URL:** https://cyberacademy.net/it/courses/iso-27005-lead-risk-manager **Issuer:** PECB **Level:** lead-risk-manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formazione certificata PECB per ISO 27005 Lead Risk Manager. Corso online in diretta con istruttori esperti e garanzia certificazione o rimborso. ... --- ## ISO 27005 Risk Manager **URL:** https://cyberacademy.net/it/courses/iso-27005-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Formazione certificata PECB ISO 27005 Risk Manager. Padroneggia la valutazione, il trattamento e il monitoraggio del rischio per la sicurezza delle informazioni. Metodologia pratica con esame incluso... --- ## ISO 27033 Lead Network Security Manager **URL:** https://cyberacademy.net/it/courses/iso-27033-lead-network-security-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione ISO 27033 Lead Network Security Manager accreditata PECB. Formazione live online con garanzia certificato o rimborso. --- ## ISO 27034 Lead Application Security Auditor **URL:** https://cyberacademy.net/it/courses/iso-27034-lead-application-security-auditor **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione ISO 27034 Lead Application Security Auditor accreditata PECB. Formazione live online con garanzia certificato o rimborso. --- ## ISO 27034 Lead Application Security Implementer **URL:** https://cyberacademy.net/it/courses/iso-27034-lead-application-security-implementer **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione PECB ISO 27034 Lead Application Security Implementer. Formazione live online con garanzia certificato o rimborso. --- ## ISO 27035 Foundation **URL:** https://cyberacademy.net/it/courses/iso-27035-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formazione ufficiale per la certificazione ISO 27035 Foundation accreditata PECB. Corso online in diretta con istruttori esperti e garanzia certificazione-o-rimborso. Iscriviti ... --- ## ISO 27035 Lead Incident Manager **URL:** https://cyberacademy.net/it/courses/iso-27035-lead-incident-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione PECB ISO 27035 Lead Incident Manager. Formazione online in diretta con garanzia certificato o rimborso. --- ## ISO 27701 Foundation **URL:** https://cyberacademy.net/it/courses/iso-27701-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificazione ISO 27701 Foundation accreditata PECB. Formazione online in diretta con garanzia certificato o rimborso. --- ## ISO 27701 Lead Auditor **URL:** https://cyberacademy.net/it/courses/iso-27701-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione ISO 27701 Lead Auditor accreditata PECB. Formazione online in diretta con garanzia certificato o rimborso. --- ## ISO 27701 Lead Implementer **URL:** https://cyberacademy.net/it/courses/iso-27701-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione ISO 27701 Lead Implementer accreditata PECB. Formazione online in diretta con garanzia certificato o rimborso. --- ## ISO 31000 Foundation **URL:** https://cyberacademy.net/it/courses/iso-31000-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificazione ISO 31000 Foundation accreditata PECB. Formazione live online con garanzia certificato o rimborso. --- ## ISO 31000 Lead Risk Manager **URL:** https://cyberacademy.net/it/courses/iso-31000-lead-risk-manager **Issuer:** PECB **Level:** lead-risk-manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione ISO 31000 Lead Risk Manager accreditata PECB. Formazione live online con garanzia certificato o rimborso. --- ## ISO 31000 Risk Manager **URL:** https://cyberacademy.net/it/courses/iso-31000-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Certificazione PECB ISO 31000 Risk Manager. Formazione live online con garanzia certificazione o rimborso. --- ## ISO 42001 Foundation **URL:** https://cyberacademy.net/it/courses/iso-42001-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificazione ISO 42001 Foundation accreditata PECB. Formazione online in diretta con garanzia certificato o rimborso. --- ## ISO 42001 Lead Auditor **URL:** https://cyberacademy.net/it/courses/iso-42001-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione ISO 42001 Lead Auditor accreditata PECB. Formazione live online con garanzia certificato o rimborso. --- ## ISO 42001 Lead Implementer **URL:** https://cyberacademy.net/it/courses/iso-42001-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione ISO 42001 Lead Implementer accreditata PECB. Formazione live online con garanzia certificato o rimborsato. --- ## ISO 9001 Foundation **URL:** https://cyberacademy.net/it/courses/iso-9001-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificazione ISO 9001 Foundation accreditata PECB. Formazione online in diretta con garanzia certificato o rimborso. --- ## ISO 9001 Lead Auditor **URL:** https://cyberacademy.net/it/courses/iso-9001-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione ISO 9001 Lead Auditor accreditata PECB. Formazione online in diretta con garanzia certificato o rimborso. --- ## ISO 9001 Lead Implementer **URL:** https://cyberacademy.net/it/courses/iso-9001-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione ISO 9001 Lead Implementer accreditata PECB. Formazione online in diretta con garanzia certificato o rimborso. --- ## ISO27001 - Lead Auditor **URL:** https://cyberacademy.net/it/courses/iso27001-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formazione certificante ISO27001 - Lead Auditor, ufficialmente accreditata PECB. Corso live online con istruttori esperti e garanzia certificazione o rimborso. Iscri... --- ## ISO27001 - Lead Implementer **URL:** https://cyberacademy.net/it/courses/iso27001-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formazione certificante ufficiale PECB ISO27001 - Lead Implementer. Corso live online con istruttori esperti e garanzia certificato-o-rimborsato. ... --- ## ISO27002 Foundation **URL:** https://cyberacademy.net/it/courses/iso27002-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formazione certificata PECB-accreditata ISO27002 Foundation. Corso online in diretta con istruttori esperti e garanzia certificazione o rimborso. Iscriviti s... --- ## ISO27002 Lead Manager **URL:** https://cyberacademy.net/it/courses/iso27002-lead-manager **Issuer:** PECB **Level:** manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formazione certificata PECB ISO27002 Lead Manager. Corso live online con istruttori esperti e garanzia certificazione-o-rimborso. Iscriviti... --- ## ISO27002 Manager **URL:** https://cyberacademy.net/it/courses/iso27002-manager **Issuer:** PECB **Level:** manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Formazione ufficiale PECB-accreditata per la certificazione ISO27002 Manager. Corso live online con istruttori esperti e garanzia certificazione-o-rimborso. Iscriviti oggi. --- ## Lead Cloud Security Manager **URL:** https://cyberacademy.net/it/courses/lead-cloud-security-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione Lead Cloud Security Manager accreditata PECB. Formazione live online con garanzia certificato o rimborso. --- ## Lead Cybersecurity Manager **URL:** https://cyberacademy.net/it/courses/lead-cybersecurity-manager **Issuer:** PECB **Level:** manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione PECB Lead Cybersecurity Manager. Formazione live online con garanzia certificato o rimborso. --- ## Lead Disaster Recovery Manager **URL:** https://cyberacademy.net/it/courses/lead-disaster-recovery-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione PECB Lead Disaster Recovery Manager. Formazione online in diretta con garanzia certificato o rimborso. --- ## Lead Ethical Hacker **URL:** https://cyberacademy.net/it/courses/lead-ethical-hacker **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione Lead Ethical Hacker accreditata PECB. Formazione online in diretta con garanzia certificato o rimborso. --- ## Lead Operational Resilience Manager **URL:** https://cyberacademy.net/it/courses/lead-operational-resilience-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione PECB Lead Operational Resilience Manager. Formazione live online con garanzia certificato o rimborso. --- ## Lead SOC 2 Analyst **URL:** https://cyberacademy.net/it/courses/lead-soc-2-analyst **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione Lead SOC 2 Analyst accreditata PECB. Formazione online in diretta con garanzia certificato o rimborso. --- ## NIS 2 Directive Foundation **URL:** https://cyberacademy.net/it/courses/nis-2-directive-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificazione NIS 2 Directive Foundation accreditata PECB. Formazione online live con garanzia certificato o rimborso. --- ## NIS 2 Directive Lead Implementer **URL:** https://cyberacademy.net/it/courses/nis-2-directive-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione PECB NIS 2 Directive Lead Implementer. Formazione online in diretta con garanzia certificato o rimborso. --- ## NIST Cybersecurity Consultant **URL:** https://cyberacademy.net/it/courses/nist-cybersecurity-consultant **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificazione NIST Cybersecurity Consultant accreditata PECB. Formazione live online con garanzia certificato o rimborso. ---