Modellazione delle minacce per ISO 27001, NIS2 e DORA

Anya, Responsabile della sicurezza delle informazioni (CISO) di una fintech in rapida crescita, ricevette la richiesta di approvare il piano di lancio di una nuova piattaforma B2B per il rischio nei pagamenti. Il Consiglio di amministrazione voleva l’ingresso sul mercato entro la fine del trimestre. Le vendite avevano già coinvolto clienti bancari. Il team di ingegneria aveva delineato un’architettura nativa cloud con attributi di identità, segnali dei dispositivi, metadati delle transazioni, punteggi di rischio comportamentale, un database gestito e un fornitore terzo di servizi di analisi.

Sulla carta, la piattaforma sembrava una svolta commerciale. Per Anya, invece, rappresentava cinque conversazioni di conformità che arrivavano contemporaneamente.

In quanto fornitore di tecnologia finanziaria, l’azienda era soggetta alla pressione di DORA. In quanto fornitore di servizi cloud e piattaforme digitali, doveva comprendere la propria esposizione a NIS2. Poiché la piattaforma trattava dati personali relativi a interessati nell’UE, si applicava il GDPR. I clienti enterprise si aspettavano la certificazione ISO/IEC 27001:2022. Se il servizio fosse diventato parte di un prodotto software connesso, le aspettative del Cyber Resilience Act avrebbero aggiunto evidenze di prodotto relative alla sicurezza fin dalla progettazione.

Il team di sviluppo propose il consueto piano di sicurezza: analizzare le dipendenze, eseguire una scansione delle vulnerabilità, pianificare un test di penetrazione e correggere le risultanze critiche prima della messa in esercizio. Anya sapeva che non bastava. Quelle attività verificano ciò che è già stato realizzato. Non dimostrano che l’architettura sia stata progettata in modo sicuro, che i confini di fiducia siano stati compresi, che i flussi di dati personali siano stati minimizzati, che le ipotesi sui fornitori siano state riesaminate o che gli scenari di interruzione del servizio siano stati considerati prima del lancio.

Per questo rallentò la riunione con quattro domande:

1. Dove sono i confini di fiducia?
2. Quali casi di abuso potrebbero portare a frodi, esposizione dei dati o interruzione del servizio?
3. Quali decisioni di progettazione riducono il rischio prima che venga scritto il codice?
4. Quali evidenze soddisferanno i revisori ISO 27001, NIS2, DORA, CRA e GDPR tra sei mesi?

La quarta domanda è il punto in cui molte organizzazioni falliscono. La modellazione delle minacce viene spesso trattata come un workshop tecnico utile e poi sepolta in una pagina wiki. Nel 2026 non è sufficiente. Per fornitori SaaS, fintech, piattaforme cloud, MSP, MSSP, operatori di infrastrutture digitali e produttori software, la modellazione delle minacce è diventata un motore di evidenze di conformità.

Un processo maturo di modellazione delle minacce trasforma risultanze STRIDE, casi di abuso e decisioni architetturali in voci del registro dei rischi, requisiti di sicurezza, piani di trattamento del rischio, casi di test, attività di assurance sui fornitori, evidenze di protezione dei dati fin dalla progettazione e tracciabilità rispetto alla Dichiarazione di applicabilità.

Perché oggi le evidenze di sicurezza fin dalla progettazione sono essenziali

Le normative moderne stanno convergendo sulla stessa aspettativa: le organizzazioni devono identificare tempestivamente i rischi di sicurezza e privacy, assegnarne la titolarità, applicare controlli proporzionati e conservare le evidenze.

ISO/IEC 27001:2022 richiede un Sistema di gestione della sicurezza delle informazioni basato sul rischio. Le clausole 6.1.2 e 6.1.3 richiedono la valutazione e il trattamento dei rischi per la sicurezza delle informazioni. La clausola 8.1 richiede pianificazione operativa e controllo. L’Appendice A fornisce controlli che devono essere selezionati tramite la Dichiarazione di applicabilità in base al rischio, ai requisiti legali e alle esigenze aziendali.

NIS2 porta lo stesso principio nella governance della cibersicurezza. Article 20 richiede agli organi di gestione di approvare le misure di gestione del rischio di cibersicurezza e di supervisionarne l’attuazione. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, tra cui analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sicurezza nell’acquisizione, nello sviluppo e nella manutenzione, gestione delle vulnerabilità, igiene informatica, cifratura, controllo degli accessi, gestione degli asset e MFA ove appropriato.

DORA applica la prospettiva della resilienza operativa del settore finanziario a partire dal 17 gennaio 2025. Richiede alle entità finanziarie soggette al regolamento di mantenere un quadro solido, completo e documentato per la gestione dei rischi ICT, identificare asset e dipendenze ICT, applicare misure protettive e preventive, rilevare attività anomale, testare la resilienza operativa digitale, gestire il rischio delle terze parti ICT e predisporre capacità di risposta e ripristino. Per le entità finanziarie rientranti nel suo ambito, DORA è l’atto giuridico settoriale dell’Unione per gli obblighi NIS2 sovrapposti.

Il GDPR aggiunge responsabilizzazione e protezione dei dati fin dalla progettazione e per impostazione predefinita. Qualsiasi sistema che tratta dati personali deve poter dimostrare un trattamento lecito, corretto, trasparente, limitato alle finalità, minimizzato, limitato nella conservazione e sicuro. Un modello delle minacce che mappa flussi di dati personali, percorsi di accesso, log, conservazione, cancellazione e trasferimenti a terze parti è direttamente rilevante per gli articoli 5, 25, 32 e 35 del GDPR.

Il Cyber Resilience Act aumenta la pressione per i prodotti con elementi digitali. I team di prodotto devono disporre di evidenze lungo il ciclo di vita che dimostrino che rischi di cibersicurezza, uso improprio prevedibile, interfacce, meccanismi di aggiornamento, flussi di autenticazione e ipotesi sulla gestione delle vulnerabilità sono stati considerati tempestivamente.

La lezione è chiara: se un riesame dell’architettura non può essere tracciato a rischi, controlli, titolari, mitigazioni e test, sarà difficile difenderlo in un audit o in un riesame normativo nel 2026.

Il modello Clarysec: un modello delle minacce, molti output

L’approccio di Clarysec parte da un principio pratico: un modello delle minacce non è completo finché non produce decisioni verificabili in sede di audit.

In Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB], la fase di Gestione del rischio, Step 9, fornisce ai team un formato semplice per convertire osservazioni tecniche in linguaggio di rischio:

“Ora combina Asset + Minaccia + Vulnerabilità in una descrizione concisa dello scenario di rischio. In sostanza, descrivi il potenziale incidente. In seguito diventerà una voce del Registro dei rischi. Usa un formato semplice: ‘[Minaccia] sfrutta [vulnerabilità] su [asset], con conseguente [impatto].’”

Quella frase è il ponte tra ingegneria e conformità.

Una nota su lavagna come “rischio di spoofing dell’API del partner” diventa:

“Un attaccante sfrutta un’autenticazione debole dell’API del partner sull’API per il rischio delle transazioni, con conseguente accesso non autorizzato alle decisioni sul rischio di pagamento ed esposizione dei dati personali.”

Ora la risultanza ha un asset, una minaccia, una vulnerabilità e un impatto. Può essere valutata, assegnata, trattata, testata e accettata.

Il livello delle politiche rende il processo ripetibile. La P24 Secure Development Policy [P24] stabilisce:

“Tutte le nuove applicazioni e le modifiche rilevanti devono essere sottoposte a riesame dell’architettura sicura e a modellazione delle minacce prima dell’inizio dello sviluppo.”
Dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.1.1.

Richiede inoltre:

“I riesami della progettazione devono documentare diagrammi dei flussi di dati, confini di fiducia e misure di mitigazione per i rischi identificati.”
Dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.1.2.

Queste due clausole sono solidi ancoraggi di audit. Dimostrano che la modellazione delle minacce non è facoltativa e che le evidenze di progettazione devono includere diagrammi, confini e decisioni di mitigazione.

La P06 Risk Management Policy [P06] collega la modellazione delle minacce alla gestione del rischio aziendale:

“Tutte le unità aziendali devono identificare proattivamente i rischi utilizzando tecniche strutturate derivate da ISO/IEC 27005:2024, incluse la modellazione delle minacce, la mappatura delle dipendenze degli asset e l’identificazione basata su scenari.”
Dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.1.1.

Stabilisce inoltre:

“I rischi identificati devono essere documentati con riferimento al proprietario dell’asset, all’attore della minaccia, alla vulnerabilità e al potenziale impatto su Riservatezza, Integrità e Disponibilità (CIA).”
Dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.1.4.

Questa è la catena di evidenze che gli auditor vogliono vedere: requisito di policy, attività di progettazione, scenario di rischio, selezione dei controlli, attuazione, test e approvazione.

STRIDE rende sistematica la copertura, i casi di abuso la rendono concreta

STRIDE rimane uno dei metodi più utili per la modellazione delle minacce in fase di progettazione perché obbliga i team a considerare sei modalità di guasto comuni:

• Spoofing
• Manomissione
• Ripudio
• Divulgazione di informazioni
• Denial of service
• Elevazione dei privilegi

Per la piattaforma di rischio nei pagamenti di Anya, il team utilizzò STRIDE su ciascun componente, flusso di dati e confine di fiducia.

Lo spoofing sollevò la questione se un client API partner potesse impersonare un cliente bancario in presenza di autenticazione reciproca debole. La manomissione evidenziò il rischio che segnali dei dispositivi o importi delle transazioni potessero essere manipolati prima dell’acquisizione. Il ripudio mise in evidenza la necessità di log di audit per amministratori e transazioni. La divulgazione di informazioni si concentrò sulle perdite attraverso log, esportazioni verso servizi di analisi, strumenti di supporto e API di reportistica. Il denial of service costrinse il team a considerare finestre di picco delle transazioni e flood di richieste malformate. L’elevazione dei privilegi evidenziò rischi nei ruoli di supporto, nei token di sessione e nelle funzioni amministrative.

I casi di abuso convertirono quelle categorie in storie realistiche:

• Un frodatore carica segnali dei dispositivi manipolati per influenzare un punteggio di rischio.
• Una credenziale partner compromessa inonda l’API di richieste fraudolente.
• Uno sviluppatore usa dati personali di produzione in un ambiente di test.
• Un insider malevolo esporta identificativi dei clienti e logica di scoring.
• L’indisponibilità di un fornitore cloud di servizi di analisi blocca le decisioni di rischio durante una finestra di pagamento.
• Una configurazione errata dello storage espone documenti di identità caricati.
• Un workflow di cancellazione rimuove la registrazione applicativa ma lascia backup e copie presso il fornitore.

Ogni caso di abuso diventò una registrazione di rischio di progettazione con asset interessato, attore della minaccia, vulnerabilità, impatto, ipotesi esistenti, mitigazione richiesta, titolare del rischio residuo, evidenze di test e rilevanza normativa.

Questa struttura evita risultanze vaghe come “rischio di sicurezza API”. Produce dichiarazioni di rischio utilizzabili come evidenze, ad esempio:

“Un attaccante usa credenziali partner rubate per inviare richieste fraudolente di scoring tramite l’API per il rischio delle transazioni, con conseguente compromissione dell’integrità delle decisioni di rischio, possibile perdita finanziaria per i clienti e trattamento non autorizzato di dati personali.”

Mappare la modellazione delle minacce a ISO/IEC 27001:2022 e ISO/IEC 27002:2022

ISO/IEC 27001:2022 non richiede espressamente la modellazione delle minacce. Richiede una valutazione del rischio e un trattamento del rischio coerenti e documentati. La modellazione delle minacce è uno dei metodi più solidi per generare tali evidenze in ambienti software, cloud e di prodotto.

La chiave è la tracciabilità. In ZB, la fase di Gestione del rischio, Step 13, raccomanda di mappare i controlli a rischi e clausole, includendo i riferimenti dell’Appendice A nei piani di trattamento del rischio e indicando dove i controlli supportano GDPR, NIS2 o DORA.

Zenith Controls: The Cross-Compliance Guide [ZC] aiuta a strutturare tale tracciabilità mappando i controlli ISO/IEC 27002:2022 a controlli correlati, aspettative di audit e quadri di riferimento esterni.

Per la modellazione delle minacce, il controllo ISO/IEC 27002:2022 5.8, sicurezza delle informazioni nella gestione dei progetti, è l’ancoraggio di governance del progetto. Dimostra che la sicurezza è integrata nell’avvio, nella pianificazione, nell’esecuzione e nell’accettazione del progetto.

Il controllo 8.25, ciclo di vita sicuro dello sviluppo, è l’ancoraggio SDLC. ZC collega 8.25 a controlli di supporto come 8.26 requisiti di sicurezza delle applicazioni, 8.27 architettura sicura dei sistemi e principi di ingegneria, 8.28 programmazione sicura, 8.29 test di sicurezza nello sviluppo e nell’accettazione, 8.30 sviluppo esternalizzato e 8.31 separazione degli ambienti di sviluppo, test e produzione.

Questa mappatura aiuta a trasformare un workshop di progettazione in evidenza per la Dichiarazione di applicabilità. Supporta inoltre le clausole da 4 a 6 di ISO/IEC 27001:2022 perché requisiti delle parti interessate, campo di applicazione del SGSI, impegni della leadership e decisioni di trattamento del rischio risultano visibili.

Una mappa di conformità trasversale per NIS2, DORA, CRA, GDPR e NIST CSF

Un modello delle minacce ben condotto non dovrebbe produrre cinque flussi di lavoro di conformità scollegati. Dovrebbe produrre un unico pacchetto di evidenze sui rischi di progettazione, riutilizzabile tra diversi quadri di riferimento.

NIST CSF 2.0 è particolarmente utile per la comunicazione verso la direzione esecutiva. La sua funzione GOVERN supporta obblighi legali, normativi, contrattuali e privacy, mentre gli esiti relativi alla catena di fornitura aiutano a collegare criticità dei fornitori, requisiti contrattuali, due diligence, monitoraggio e pianificazione degli incidenti alle stesse evidenze del modello delle minacce.

Il GDPR richiede particolare attenzione perché modellazione delle minacce e DPIA dovrebbero rafforzarsi reciprocamente. La P17 Data Protection and Privacy Policy [P17] stabilisce:

“La modellazione delle minacce e le valutazioni d’impatto sulla protezione dei dati (DPIA) sono obbligatorie per i sistemi di trattamento ad alto rischio.”
Dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.3.4.

Per i team più piccoli, la P17S Data Protection and Privacy Policy - SME [P17S] stabilisce:

“La protezione dei dati fin dalla progettazione e per impostazione predefinita deve essere applicata in tutti i nuovi sistemi e servizi”
Dalla sezione “Requisiti di governance”, clausola di policy 5.3.1.

Il risultato è un modello operativo pratico: usare gli stessi diagrammi dei flussi di dati, confini di fiducia e casi di abuso per il rischio di sicurezza, il rischio privacy, il riesame dei fornitori e le evidenze normative.

Uno sprint di 90 minuti sui rischi di progettazione per funzionalità ad alto rischio

La modellazione delle minacce non deve iniziare come un programma pesante. Per una nuova API di pagamento, un workflow di onboarding, una funzionalità abilitata dall’AI, un servizio di identità, una migrazione cloud o un’integrazione esterna, uno sprint di 90 minuti sui rischi di progettazione può produrre evidenze di valore.

1. Aprire un checkpoint di sicurezza del progetto

Usa la clausola 6.1.1 di P24 come trigger. Per ogni nuova applicazione o modifica rilevante, crea una cartella di evidenze con:

• Diagramma architetturale
• Diagramma dei flussi di dati
• Mappa dei confini di fiducia
• Elenco degli asset
• Note sui dati personali
• Elenco dei fornitori e delle dipendenze ICT
• Requisiti iniziali di sicurezza
• Foglio di lavoro del modello delle minacce
• Voci del registro dei rischi
• Tracciabilità di mitigazioni e test
• Registrazione dell’approvazione

Per le organizzazioni più piccole, P24S Secure Development Policy - SME [P24S] supporta la stessa disciplina collegando i processi di sviluppo sicuro al controllo degli accessi degli sviluppatori, ai test, alla modellazione delle minacce e alla documentazione. Richiede inoltre la conservazione centralizzata di checklist, approvazioni dei riesami, report di test e inventari dei componenti ai fini di audit. La clausola 11.3.1 richiama da SA-3 a SA-15 per definire processi di sviluppo sicuro, inclusa la modellazione delle minacce.

2. Disegnare il flusso di dati minimo praticabile

Non iniziare da un diagramma rifinito. Parti dai flussi che generano rischio:

• L’utente carica documenti di identità o dati di transazione.
• L’applicazione web invia richieste all’API.
• L’API scrive su storage gestito o su un database.
• Il fornitore riceve dati di verifica o di analisi.
• Il portale interno degli analisti visualizza i risultati.
• Il sistema del cliente recupera stati o decisioni.
• Log, strumenti di monitoraggio e backup ricevono copie.

Contrassegna ogni confine di fiducia: da Internet all’applicazione, dall’applicazione all’API, dal servizio interno al fornitore, dal sistema di produzione ai servizi di analisi, dall’amministratore alla funzione privilegiata e dall’ambiente di produzione all’ambiente non di produzione.

3. Eseguire insieme STRIDE e casi di abuso

Per ogni confine, poni le domande STRIDE e scrivi casi di abuso in linguaggio aziendale semplice. L’obiettivo non è elencare ogni attacco immaginabile. L’obiettivo è identificare scenari plausibili e rilevanti che incidono su riservatezza, integrità, disponibilità, privacy, resilienza o sicurezza delle persone.

4. Convertire le risultanze in scenari di rischio

Usa la formula dello Step 9 di ZB:

“[Minaccia] sfrutta [vulnerabilità] su [asset], con conseguente [impatto].”

Ad esempio:

“Un attaccante sfrutta controlli deboli degli accessi allo storage a oggetti sul repository dei documenti di identità, con conseguente divulgazione non autorizzata di dati personali ed esposizione a obblighi di notifica normativa.”

Aggiungi quindi titolare, probabilità, impatto, rischio inerente, opzione di trattamento, controllo target, rischio residuo ed evidenze.

5. Derivare requisiti e test

Un modello delle minacce non è concluso quando i rischi sono elencati. È concluso quando le mitigazioni sono implementate, testate o formalmente accettate.

La Change Management Policy - SME fornisce un trigger pratico:

“Se una modifica riguarda dati sensibili, diritti di accesso ai sistemi o integrazioni esterne, è richiesto un riesame dell’impatto sulla sicurezza. Il referente designato per la sicurezza o la conformità deve valutare se la modifica introduce rischi aggiuntivi e raccomandare misure di sicurezza aggiuntive.”
Dalla sezione “Trattamento del rischio ed eccezioni”, clausola di policy 7.5.1.

Dati sensibili, diritti di accesso e integrazioni esterne sono esattamente le modifiche che richiedono un riesame dei rischi di progettazione.

Che cosa chiederanno i diversi auditor

Un auditor ISO/IEC 27001:2022 chiederà se la modellazione delle minacce fa parte di un processo definito di valutazione del rischio, se i criteri sono coerenti, se i titolari del rischio hanno approvato i rischi residui, se i piani di trattamento del rischio sono collegati alla SoA e se le evidenze sono conservate. Cercherà ripetibilità, cronologia delle versioni, visibilità nel riesame della direzione e copertura da parte dell’audit interno.

Per l’Appendice A, collegherà le evidenze a 5.8, 8.25, 8.26, 8.27 e 8.29. Lo Step 21 di ZB, Controls in Action, evidenzia l’architettura sicura dei sistemi e i principi di ingegneria chiedendo quali principi guidano l’architettura sicura. Gli auditor possono chiedere se la modellazione delle minacce viene svolta durante la progettazione usando metodi come STRIDE o alberi di attacco, e se le decisioni architetturali sono riesaminate prima dell’implementazione.

Un revisore NIS2 si concentrerà su governance e proporzionalità. Potrà chiedere se la direzione ha approvato l’approccio alla gestione del rischio di cibersicurezza, se sono coperte acquisizione, sviluppo e manutenzione sicuri, se le vulnerabilità dei fornitori sono considerate, se gli scenari di incidente sono collegati ai workflow di segnalazione e se gli scenari di continuità sono analizzati. La segnalazione a fasi degli incidenti significativi prevista da NIS2 Article 23, inclusi preallarme entro 24 ore, notifica entro 72 ore e relazione finale entro un mese, rende particolarmente preziosa la chiarezza degli scenari.

Un esaminatore DORA si concentrerà su governance del rischio ICT, funzioni critiche, asset ICT, dipendenze esterne, test di resilienza e servizi ICT di terze parti. Se il sistema supporta una funzione critica o importante, si aspetterà evidenze più solide che colleghino gli scenari di minaccia a inventari degli asset, mappe delle dipendenze, piani di test, contratti con terze parti e misure di ripristino.

Un revisore privacy esaminerà i flussi di dati e chiederà se il trattamento dei dati personali è necessario, lecito, minimizzato e protetto. Chiederà se sono coinvolte categorie particolari di dati, se viene usata pseudonimizzazione o cifratura, se la conservazione è giustificata e se è richiesta una DPIA. Modellazione delle minacce e DPIA sono attività diverse, ma dovrebbero condividere diagrammi, scenari e mitigazioni.

Un revisore orientato a NIST CSF o COBIT 2019 cercherà governance, titolarità dei processi, prestazioni, responsabilizzazione e miglioramento continuo. Potrebbe attribuire meno importanza al foglio di lavoro STRIDE in sé e più al fatto che il processo sia affidabile, misurato, approvato e migliorato.

Errori comuni nelle evidenze della modellazione delle minacce

Gli errori più comuni non sono tecnici. Sono errori di evidenza.

I team eseguono la modellazione delle minacce troppo tardi, dopo che il sistema è già stato realizzato. A quel punto il workshop diventa un briefing preliminare al test di penetrazione invece di un controllo di progettazione.

Le risultanze non vengono convertite in linguaggio di rischio. “Aggiungere auth” o “problema di logging” possono aiutare gli ingegneri, ma gli auditor hanno bisogno di asset, minaccia, vulnerabilità, impatto, titolare, trattamento e rischio residuo.

Privacy e sicurezza vengono separate. Un team documenta rischi di spoofing e injection mentre un altro documenta conservazione e base giuridica. La responsabilizzazione richiesta dal GDPR funziona meglio quando flussi di dati, casi di abuso e trigger DPIA sono collegati.

Le ipotesi sui fornitori restano non documentate. NIS2, DORA e NIST CSF innalzano tutte le aspettative sul rischio ICT della catena di fornitura. Se una mitigazione dipende dalla cifratura, dalla registrazione, dalla cancellazione, dalla resilienza o dalla risposta agli incidenti di un fornitore, raccogli le evidenze.

I test non sono mappati alle minacce. Un report di test di penetrazione può essere utile, ma potrebbe non dimostrare che gli specifici rischi di progettazione siano stati mitigati. Ogni risultanza rilevante relativa alle minacce dovrebbe avere evidenze di validazione.

L’accettazione del rischio residuo è informale. “Lo accettiamo per l’MVP” non è sufficiente. ISO/IEC 27001:2022 richiede l’accettazione del rischio residuo da parte dei titolari del rischio appropriati come informazione documentata.

Il tuo pacchetto di evidenze 2026 per la modellazione delle minacce

Per ogni sistema rilevante o modifica significativa, mantieni un pacchetto standard di evidenze in grado di supportare ISO 27001, NIS2, DORA, CRA, GDPR e assurance verso i clienti.

La Risk Management Policy - SME descrive bene il modello operativo:

“Assicura che la gestione del rischio sia una componente attiva della pianificazione, dell’esecuzione dei progetti, della selezione dei fornitori e della risposta agli incidenti, in allineamento con ISO 27001, ISO 31000 e i requisiti normativi applicabili.”
Dalla sezione “Finalità”, clausola di policy 1.2.

Questo è l’obiettivo corretto. La modellazione delle minacce dovrebbe influenzare pianificazione, ingegneria, selezione dei fornitori, risposta agli incidenti e capacità di dimostrare la conformità in sede di audit.

Rendi la modellazione delle minacce pronta per l’audit prima del prossimo rilascio

Le organizzazioni che gestiranno meglio la pressione di conformità del 2026 non saranno quelle con più diagrammi. Saranno quelle in grado di dimostrare una catena semplice:

Il rischio di progettazione è stato identificato. Il rischio è stato valutato. I controlli sono stati selezionati. Le mitigazioni sono state implementate. I test hanno validato le mitigazioni. Il rischio residuo è stato approvato. Le evidenze sono mappate ai quadri di riferimento rilevanti.

Inizia da una modifica ad alto rischio: un’integrazione di pagamento, una nuova API, un workflow abilitato dall’AI, una funzionalità di identità, una migrazione cloud, un rilascio di prodotto rivolto ai clienti o un servizio connesso a fornitori. Esegui uno sprint di 90 minuti sui rischi di progettazione. Usa ZB per convertire le risultanze in scenari di rischio, piani di trattamento del rischio e tracciabilità SoA. Usa ZC per mappare controlli ISO/IEC 27002:2022 come 5.8, 8.25, 8.26, 8.27 e 8.29 a controlli di supporto, rischio dei fornitori, privacy, test ed evidenze di audit. Allinea P24, P06, P17, P24S e la tua procedura di gestione dei cambiamenti affinché la modellazione delle minacce diventi obbligatoria, ripetibile e riesaminabile.

Se vuoi che Clarysec ti supporti, inizia con un riesame delle evidenze di modellazione delle minacce. Valuteremo un progetto reale, identificheremo le lacune rispetto alle aspettative di ISO/IEC 27001:2022, NIS2, DORA, CRA e GDPR, e ti forniremo una roadmap pratica di rimedio comprensibile per ingegneri, auditor e Consiglio di amministrazione.