Mappa delle evidenze di conformità per l’EU Digital Identity Wallet 2026

Un team di prodotto fintech è a due settimane dal lancio dell’onboarding basato su wallet. Il nuovo flusso consentirà ai clienti dell’UE di dimostrare attributi di identità selezionati tramite l’EU Digital Identity Wallet, invece di caricare manualmente i documenti di identità. Il CISO ne apprezza il vantaggio in termini di sicurezza. Il DPO ne apprezza la promessa di minimizzazione dei dati. Il responsabile della conformità vede meno percorsi di onboarding abbandonati e un’esperienza cliente più lineare.

Poi il comitato di audit pone la domanda che cambia la discussione:

“Se un’autorità di regolamentazione, un partner bancario, un auditor del cliente o un’autorità di controllo chiede come è governata questa integrazione con il wallet, quali evidenze mostriamo?”

Questo è il vero problema del 2026.

L’EU Digital Identity Wallet, spesso abbreviato in EUDI Wallet, non è semplicemente un’altra funzionalità di prodotto. Per i servizi digitali regolamentati, i prestatori di servizi di pagamento, gli ecosistemi dei servizi fiduciari, le interfacce con il settore pubblico e i percorsi di onboarding ad alto livello di garanzia, diventa parte della catena di garanzia dell’identità dell’organizzazione. Incide sui dati personali, sugli eventi di autenticazione, sulle dipendenze dai fornitori, sulla governance degli accessi, sulla registrazione, sulla crittografia, sulla segnalazione degli incidenti e sulla responsabilità del consiglio di amministrazione.

L’errore è trattare eIDAS2 e l’EUDI Wallet come un adempimento legale autonomo. La risposta operativa è diversa: integrare l’adozione del wallet da parte delle parti facenti affidamento nello stesso sistema di evidenze utilizzato per ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST CSF 2.0 e COBIT 2019.

È qui che l’approccio di Clarysec è più efficace. Non trasformiamo ogni nuova regolamentazione in un ulteriore foglio di calcolo. Mappiamo gli obblighi a politiche, controlli, responsabili, tracce di audit ed evidenze ripetibili.

Questo articolo mostra come costruire tale dorsale di evidenze utilizzando Zenith Blueprint: roadmap in 30 passi per auditor, Zenith Controls: guida alla conformità trasversale e i modelli di politiche Clarysec per privacy, identità, registrazione, governance dei fornitori e conformità normativa.

Il problema delle evidenze del wallet nel 2026 va oltre eIDAS2

La maggior parte delle discussioni sull’EU Digital Identity Wallet si concentra su fiducia, interoperabilità ed esperienza utente. Sono aspetti importanti. Tuttavia, un CISO, un responsabile della conformità, un DPO o un auditor ha una domanda più operativa: quali controlli dimostrano che gli attributi di identità derivati dal wallet sono utilizzati in modo sicuro, lecito e proporzionato?

Una parte facente affidamento che accetta asserzioni del wallet dovrebbe essere in grado di rispondere a queste domande:

• Quali attributi del wallet vengono richiesti e perché?
• Quale base giuridica supporta il trattamento?
• Utenti, amministratori e account di servizio sono identificabili in modo univoco?
• I servizi di verifica del wallet, i broker di identità, i gateway API e i componenti cloud sono presenti nel registro dei fornitori?
• Gli eventi di autenticazione e verifica sono registrati in modo da supportare le indagini senza raccogliere dati personali in eccesso?
• Esiste un processo di gestione degli incidenti se l’onboarding tramite wallet viene abusato, non è disponibile o viene compromesso?
• Per le entità finanziarie, l’integrazione con il wallet è coperta dalla gestione del rischio ICT DORA, dal rischio di terze parti e dalla classificazione degli incidenti?
• Per i soggetti NIS2, la dipendenza dal wallet incide sull’erogazione di servizi essenziali o importanti, sul controllo degli accessi, sulla continuità operativa o sulle comunicazioni con i clienti?

NIS2 è particolarmente rilevante perché il suo ambito include molti fornitori di infrastrutture digitali, servizi cloud, fornitori di servizi gestiti, fornitori di servizi di sicurezza gestiti e prestatori di servizi fiduciari. La direttiva classifica inoltre come essenziali, in specifiche circostanze, i prestatori qualificati di servizi fiduciari, i provider DNS, i registri TLD e diversi altri soggetti. Entro il 2026, molte organizzazioni non si chiederanno più se la legge stia arrivando. Dovranno rispondere a domande di vigilanza, dei clienti e di audit interno sull’attuazione.

Per i servizi finanziari, DORA aggiunge un ulteriore livello. Si applica dal 17 gennaio 2025 e stabilisce un quadro uniforme per rischio ICT, incidenti, test e rischio di terze parti per le entità finanziarie. NIS2 riconosce DORA come atto giuridico dell’Unione settoriale per molti obblighi di cibersicurezza sovrapposti nel settore finanziario. In pratica, ciò significa che una funzionalità di onboarding basata su wallet presso un istituto di pagamento, un prestatore di servizi per cripto-attività, un’impresa di investimento o un prestatore di servizi di informazione sui conti deve essere supportata da evidenze di governance del rischio ICT in stile DORA, anche se NIS2 resta rilevante per il coordinamento e le dipendenze dell’ecosistema.

La risposta sbagliata è creare un pacchetto di evidenze per eIDAS2, uno per GDPR, uno per NIS2, uno per DORA e uno per la certificazione ISO. La risposta corretta è utilizzare il SGSI come modello operativo delle evidenze.

Utilizzare ISO 27001 come dorsale delle evidenze

ISO/IEC 27001:2022 è utile perché non si limita a una checklist tecnologica. Richiede alle organizzazioni di definire contesto, parti interessate, obblighi legali e contrattuali, ambito di applicazione, interfacce, dipendenze, responsabilità della direzione, valutazione del rischio, trattamento del rischio, Dichiarazione di Applicabilità e miglioramento continuo.

Questo è rilevante per l’adozione del wallet perché il rischio non risiede solo in una chiamata API. Il rischio riguarda il processo aziendale end-to-end.

Un’implementazione del wallet da parte di una parte facente affidamento incide su:

• onboarding dei clienti e accesso agli account;
• informative privacy, voci RoPA e registrazioni della base giuridica;
• modelli di verifica dell’identità e autenticazione;
• contratti con i fornitori e attestazioni di affidabilità;
• registrazione, monitoraggio e conservazione delle evidenze;
• classificazione e segnalazione degli incidenti;
• conservazione, cancellazione e rettifica dei dati;
• audit e monitoraggio continuo della conformità;
• reporting del rischio al consiglio di amministrazione.

La politica di conformità aziendale di Clarysec rende esplicito questo modello operativo:

“Tutti gli obblighi legali e normativi devono essere mappati a politiche, controlli e proprietari specifici all’interno del Sistema di gestione della sicurezza delle informazioni (SGSI).”
Da Politica di conformità legale e normativa, sezione “Requisiti di applicazione della politica”, clausola della politica 6.2.1.

Per le PMI, lo stesso principio viene adattato a un registro di conformità pratico:

“Quando una normativa si applica a più aree (ad esempio, GDPR si applica a conservazione, sicurezza e privacy), ciò deve essere chiaramente mappato nel Registro di conformità e nei materiali formativi.”
Da Politica di conformità legale e normativa - PMI, sezione “Requisiti di governance”, clausola della politica 5.2.2.

L’organizzazione non dovrebbe chiedersi: “Quale dipartimento è titolare di eIDAS2?” Dovrebbe chiedersi: “Quali rischi, controlli, politiche, responsabili e registrazioni delle evidenze del SGSI sono interessati dalla dipendenza dal wallet?”

In Zenith Blueprint, nella fase Gestione del rischio, Passo 14, si afferma:

“Per ciascuna normativa, se applicabile, è possibile creare una semplice tabella di mappatura (ad esempio un’appendice a un report) che elenchi i principali requisiti di sicurezza della normativa e i controlli/le politiche corrispondenti nel SGSI. Non è obbligatorio in ISO 27001, ma è un utile esercizio interno per assicurarsi che nulla sia stato trascurato. Dimostra inoltre agli auditor/valutatori che la sicurezza non viene gestita nel vuoto, ma con consapevolezza del contesto legale.”

Questa è la base: costruire un’unica tabella di mappatura che colleghi gli obblighi della parte facente affidamento sul wallet a GDPR, NIS2, DORA, ai controlli dell’Allegato A di ISO/IEC 27001:2022, alle politiche Clarysec e alle registrazioni delle evidenze.

Una mappa pratica delle evidenze per le parti facenti affidamento sull’EU Digital Identity Wallet

L’EUDI Wallet diventa gestibile quando viene trattato come un processo aziendale definito all’interno del SGSI, con dati, identità, fornitori, log, incidenti e responsabili mappati.

Questa tabella non è un parere legale. È un modello di controlli ed evidenze che CISO, team di conformità e auditor possono utilizzare per strutturare le prove.

La gestione delle identità è il punto da cui inizieranno gli auditor

Per una parte facente affidamento sul wallet, l’identità è la famiglia di controlli più evidente. Ma la gestione delle identità non coincide con l’autenticazione. La gestione delle identità risponde alla domanda “chi esiste nel sistema e come viene governata tale identità?” L’autenticazione risponde alla domanda “come viene verificata, al momento dell’accesso, l’identità dichiarata?”

In Zenith Controls, il controllo ISO/IEC 27002:2022 5.16, Gestione delle identità, è trattato come controllo preventivo a supporto di riservatezza, integrità e disponibilità. È direttamente collegato a controllo degli accessi, informazioni di autenticazione, diritti di accesso, relazioni con i fornitori, monitoraggio della conformità e accesso privilegiato. La mappatura trasversale di conformità collega quest’area alla sicurezza e all’accountability GDPR, al controllo degli accessi e alla gestione degli asset NIS2, alla governance dell’identità e degli accessi DORA, alla gestione degli identificativi NIST SP 800-53 e alla governance del ciclo di vita dell’identità COBIT 2019.

Per le evidenze del wallet, l’organizzazione dovrebbe poter dimostrare che:

• le identità dei clienti e della forza lavoro non sono confuse;
• le identità amministrative sono univoche e tracciabili;
• le identità dei fornitori sono governate con la stessa disciplina applicata ai dipendenti;
• le identità non umane, come client API e account di servizio, hanno responsabili assegnati;
• le identità sono deprovisionate quando non più necessarie;
• eccezioni, account break-glass e identità privilegiate sono controllati.

La politica per gli account Clarysec per le PMI esprime il principio in modo diretto:

“Ogni account deve essere univoco, tracciabile a una specifica persona e collegato a un ruolo aziendale.”
Da Politica di gestione degli account utente e dei privilegi - PMI, sezione “Requisiti di applicazione della politica”, clausola della politica 6.1.2.

Per gli ambienti aziendali, il requisito sugli account condivisi è più rigoroso:

“Tutte le identità utente devono essere associate a un identificativo univoco. L’utilizzo di account condivisi o generici è vietato, salvo account break-glass o di emergenza approvati e soggetti a controlli rigorosi.”
Da Politica di gestione degli account utente e dei privilegi, sezione “Requisiti di governance”, clausola della politica 5.3.

Gli standard di supporto rafforzano la stessa logica delle evidenze. ISO/IEC 24760-1:2019 fornisce concetti del ciclo di vita dell’identità quali registrazione, associazione, uso e deregistrazione. ISO/IEC 29115:2013 supporta il livello di garanzia dell’identità basato sul rischio. ISO/IEC 27005:2024 tratta le debolezze di identità e accesso come temi di trattamento del rischio. ISO/IEC 27018:2020 estende le aspettative di gestione delle identità al trattamento di PII nel cloud pubblico. ISO/IEC 29100:2011 aggiunge la prospettiva privacy collegando l’identificabilità alla gestione delle informazioni personali.

Per l’adozione dell’EUDI Wallet, la domanda di audit è semplice: è possibile ricondurre ogni azione privilegiata, modifica di configurazione, modifica dell’integrazione di verifica del wallet ed evento di accesso del fornitore a un’identità univoca con un ruolo approvato?

Se la risposta è no, il progetto wallet non è pronto ai fini dell’audit.

Autenticazione sicura: la fiducia nel wallet non elimina i doveri di controllo

Un equivoco frequente è che la verifica dell’identità basata su wallet elimini gli obblighi di autenticazione della parte facente affidamento. Può migliorare il livello di garanzia per specifici attributi di identità, ma non elimina il dovere di proteggere sistemi, sessioni, API, interfacce amministrative e percorsi cliente.

In Zenith Blueprint, fase Controlli in azione, Passo 19, Clarysec afferma:

“L’autenticazione è la prima e più critica linea di difesa tra un attore della minaccia e i vostri sistemi, dati e servizi. Se l’autenticazione è debole, tutto il resto — cifratura, monitoraggio, segmentazione — può essere aggirato.”

Lo stesso passo spiega che l’autenticazione moderna deve essere basata sul rischio, più forte per gli obiettivi di maggior valore e supportata da MFA, archiviazione sicura delle credenziali, TLS, protezione dei token, gestione dei segreti, gestione sicura delle sessioni e riesame dei log di autenticazione.

In Zenith Controls, il controllo ISO/IEC 27002:2022 8.5, Autenticazione sicura, è mappato come controllo preventivo nella capacità di gestione delle identità e degli accessi. È collegato a gestione delle identità, informazioni di autenticazione, accesso privilegiato, restrizione dell’accesso alle informazioni, attività di monitoraggio, gestione degli incidenti e protezione della privacy delle PII. È inoltre mappato trasversalmente alla sicurezza GDPR e alla protezione dei dati fin dalla progettazione, alla gestione dei rischi di cibersicurezza NIS2 e a MFA o autenticazione continua ove appropriato, alla governance del rischio ICT DORA, alle famiglie IA e AC di NIST SP 800-53 e alla governance dell’accesso logico COBIT 2019.

Per una parte facente affidamento sul wallet, le evidenze di autenticazione sicura dovrebbero includere:

• autenticazione e autorizzazione degli endpoint di verifica del wallet;
• MFA degli amministratori per i pannelli di configurazione del wallet;
• autenticazione sicura delle API tra servizi di onboarding;
• conservazione in vault dei segreti per chiavi o certificati di integrazione del wallet;
• timeout di sessione e protezione dei token ove appropriato;
• allerte sui fallimenti di autenticazione e protezioni contro i tentativi di forza bruta;
• controlli distinti per login dei clienti, accesso dei dipendenti e accesso machine-to-machine.

La politica di registrazione Clarysec per le PMI fornisce un requisito pratico di evidenza:

“Log di autenticazione: tentativi di accesso riusciti e non riusciti, durata della sessione, utilizzo della MFA”
Da Politica di registrazione e monitoraggio - PMI, sezione “Requisiti di governance”, clausola della politica 5.4.2.

Per gli ambienti aziendali, l’affidabilità ai fini dell’audit diventa centrale:

“I file di log devono essere immutabili o soggetti a controllo delle versioni, con accesso concesso solo al personale autorizzato.”
Da Politica di registrazione e monitoraggio, sezione “Requisiti di applicazione della politica”, clausola della politica 6.5.1.

Questo è il collegamento tra garanzia dell’identità e risposta agli incidenti. Se l’onboarding tramite wallet viene attaccato mediante credential stuffing, attacchi di replay sui token, compromissione amministrativa o uso improprio da parte di fornitori, i log di autenticazione diventano la traccia evidenziale.

GDPR: la promessa del wallet è la minimizzazione, ma deve essere dimostrata

L’EU Digital Identity Wallet può supportare un onboarding orientato alla tutela della privacy perché una parte facente affidamento può richiedere attributi specifici invece di raccogliere documenti di identità completi. Tuttavia, l’accountability GDPR non si basa sulle buone intenzioni. Richiede conformità dimostrabile.

Gli attributi derivati dal wallet sono dati personali quando riguardano una persona identificata o identificabile. Alcuni casi d’uso possono inoltre riguardare dati biometrici, dati di verifica dell’identità, screening sanzionatori, rischio di frode o altri contesti di trattamento sensibili.

I principi GDPR richiedono trattamento lecito, corretto e trasparente, finalità determinate, minimizzazione dei dati, esattezza, limitazione della conservazione, integrità e riservatezza, oltre all’accountability. Una parte facente affidamento dovrebbe poter dimostrare perché ogni attributo del wallet viene richiesto, per quanto tempo viene conservato, chi può accedervi, come viene protetto e come viene controllato il riutilizzo.

La politica privacy aziendale di Clarysec stabilisce:

“Possono essere raccolti e trattati solo i dati necessari per una specifica finalità aziendale legittima.”
Da Politica di protezione dei dati e privacy, sezione “Requisiti di applicazione della politica”, clausola della politica 6.2.1.

La versione PMI è volutamente concisa:

“Devono essere raccolti e conservati solo i dati personali minimi necessari”
Da Politica di protezione dei dati e privacy - PMI, sezione “Requisiti di applicazione della politica”, clausola della politica 6.2.1.

In Zenith Controls, il controllo ISO/IEC 27002:2022 5.34, Privacy e protezione delle PII, è mappato a inventario degli asset, mascheramento dei dati, governance dei servizi cloud, classificazione delle informazioni, trasferimento sicuro, controllo degli accessi, gestione delle identità e riesame delle modifiche di progetto. È inoltre collegato a ISO/IEC 27701:2021 per la gestione della privacy, a ISO/IEC 27018 per il trattamento di PII nel cloud e ai principi privacy ISO/IEC 29100.

Per l’adozione del wallet, il pacchetto di evidenze privacy dovrebbe includere:

• diagramma dei flussi di dati per gli attributi del wallet;
• voce nel registro della base giuridica;
• registrazione della decisione di minimizzazione degli attributi;
• piano di conservazione per i dati derivati dal wallet;
• aggiornamento dell’informativa privacy;
• DPIA o valutazione del rischio privacy quando il caso d’uso è ad alto rischio;
• matrice del controllo degli accessi per i dati del wallet;
• processo di cancellazione e rettifica dei dati;
• evidenze di monitoraggio che dimostrino il controllo degli accessi alle PII derivate dal wallet.

Molte organizzazioni raccolgono troppo perché il wallet rende più semplice ottenere dati verificati. È l’approccio opposto a quello corretto. Il beneficio in termini di sicurezza e privacy deriva dal richiedere meno, non dal conservare più dati di identità verificati di quanti ne servano all’attività.

NIS2 e DORA: la responsabilità del consiglio incontra la resilienza del wallet

NIS2 e DORA portano entrambe la cibersicurezza nella governance. Richiedono agli organi di gestione di approvare, sorvegliare e assumersi la responsabilità delle misure di rischio. Prevedono inoltre controlli tecnici, operativi e organizzativi proporzionati.

NIS2 Article 21 richiede misure di gestione del rischio relative a politiche, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e sviluppo sicuri, gestione delle vulnerabilità, efficacia dei controlli, igiene informatica, formazione, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset e, ove appropriato, MFA o autenticazione continua. Per le parti facenti affidamento sul wallet nei settori NIS2, l’integrazione con il wallet dovrebbe comparire nella valutazione del rischio, nell’inventario degli asset, nel registro dei fornitori, nel piano degli incidenti e nel quadro di controllo degli accessi.

NIS2 Article 23 aggiunge la segnalazione per fasi degli incidenti significativi. I soggetti essenziali e importanti devono fornire un preavviso entro 24 ore, una notifica entro 72 ore e un rapporto finale entro un mese, con comunicazioni ai destinatari ove applicabile. Se un guasto dell’integrazione con il wallet può causare interruzione operativa, perdita finanziaria o danno materiale o immateriale ai destinatari del servizio, deve essere incluso nella logica di classificazione degli incidenti.

DORA è più specifico per le entità finanziarie. Richiede un quadro interno di governance e controllo per il rischio ICT, una strategia di resilienza approvata dal consiglio, politiche ICT, piani di continuità operativa e risposta, piani di audit, politiche per le terze parti, canali di segnalazione degli incidenti e un quadro documentato di gestione del rischio ICT. Richiede inoltre la gestione degli incidenti connessi all’ICT, la classificazione secondo criteri quali clienti interessati, indisponibilità, diffusione geografica, perdita di dati, criticità e impatto economico, oltre alla segnalazione degli incidenti ICT rilevanti.

Per l’onboarding basato su wallet nei servizi finanziari, le evidenze dovrebbero dimostrare che:

• l’integrazione con il wallet è presente nell’inventario degli asset e dei processi ICT;
• i rischi sono valutati e accettati dal responsabile corretto;
• la criticità è valutata per l’onboarding del cliente o l’accesso all’account;
• esistono opzioni di resilienza e fallback;
• gli incidenti possono essere classificati secondo i criteri DORA;
• sono pianificate notifiche ai clienti quando sono interessati interessi finanziari;
• la segnalazione esternalizzata, se utilizzata, non elimina l’accountability.

Il criterio chiave è la proporzionalità. Una piccola fintech e una grande banca non produrranno lo stesso volume di evidenze, ma entrambe devono disporre di una governance tracciabile.

Dipendenze da fornitori e cloud: il flusso wallet è forte quanto la sua catena

La maggior parte delle implementazioni wallet delle parti facenti affidamento coinvolge servizi esterni: hosting cloud, gateway API, librerie di verifica, broker di identità, fornitori KYC, motori antifrode, piattaforme di registrazione, provider di managed detection and response o strumenti di supporto clienti. Questo rende centrale la governance dei fornitori.

NIS2 richiede ai soggetti di considerare le vulnerabilità specifiche dei fornitori e la qualità complessiva e le pratiche di cibersicurezza dei fornitori e dei prestatori di servizi. DORA va oltre per le entità finanziarie, richiedendo un registro degli accordi contrattuali per servizi ICT, valutazioni precontrattuali, analisi del rischio di concentrazione, due diligence, approcci di audit e ispezione, diritti di risoluzione e strategie di uscita testate per i servizi ICT a supporto di funzioni critiche o importanti.

In Zenith Blueprint, fase Controlli in azione, Passo 23, Clarysec indica ai team di compilare un elenco completo dei fornitori, classificare i provider in base all’accesso a sistemi, dati o controllo operativo, inserire le aspettative nei contratti, identificare i subappaltatori, definire i trigger di modifica e costruire un processo di valutazione dei servizi cloud. Lo stesso passo raccomanda di valutare localizzazione dei dati, modello di accesso, registrazione e cifratura prima di approvare futuri servizi cloud.

La politica Clarysec per fornitori PMI fornisce una chiara regola di accesso minimo:

“Ai fornitori deve essere concesso accesso solo ai sistemi e ai dati minimi necessari per svolgere la propria funzione.”
Da Politica di sicurezza delle terze parti e dei fornitori - PMI, sezione “Requisiti di applicazione della politica”, clausola della politica 6.2.1.

NIST CSF 2.0 supporta questa visione integrata. La funzione GOVERN include obblighi legali, regolamentari, contrattuali e privacy, propensione al rischio, accountability, politiche, risorse e supervisione. I relativi esiti per la catena di fornitura richiedono ruoli dei fornitori, prioritizzazione della criticità, requisiti contrattuali di cibersicurezza, due diligence, monitoraggio, pianificazione degli incidenti e disposizioni post-rapporto.

Gli auditor COBIT 2019 cercheranno la maturità della governance. Chiederanno se responsabilità dei fornitori, ciclo di vita dell’identità, controlli privacy e monitoraggio sono integrati nei processi aziendali, non solo nelle checklist del team di sicurezza. Per identità e accesso logico, COBIT 2019 DSS05.04, Manage user identity and logical access, è particolarmente rilevante per valutare se titolarità degli account, approvazioni, assegnazione e rimozione dei privilegi sono controllate.

Costruire un pacchetto di evidenze per una parte facente affidamento sul wallet in un pomeriggio

Un esercizio pratico in stile Clarysec inizia da un caso d’uso specifico, non da una dichiarazione di programma generale. Utilizzare “onboarding del cliente con nome legale, data di nascita e indirizzo forniti dal wallet” come prima registrazione. Aggiungere responsabile dell’attività, proprietario del sistema, proprietario delle informazioni e responsabile del rischio.

Registrare:

• finalità del trattamento;
• attributi del wallet richiesti;
• se gli attributi sono archiviati, memorizzati in cache o solo verificati;
• sistemi e API coinvolti;
• fornitori e sub-responsabili;
• paesi o regioni cloud coinvolti;
• processo di fallback se la verifica del wallet fallisce;
• punti di contatto per la comunicazione con il cliente.

Aggiungere quindi il caso d’uso al registro di conformità.

Successivamente, riesaminare la Dichiarazione di Applicabilità e il Piano di trattamento del rischio. Per i casi d’uso EUDI Wallet, le seguenti aree di controllo ISO/IEC 27002:2022 sono comunemente rilevanti.

Infine, eseguire un mini-audit. Selezionare una transazione di onboarding tramite wallet e tracciare:

1. la giustificazione della richiesta degli attributi;
2. il passaggio di trasparenza o la registrazione del consenso ove applicabile;
3. il log degli eventi di sistema;
4. le evidenze di autenticazione API;
5. la registrazione del controllo degli accessi per il personale che visualizza l’esito dell’onboarding;
6. il fornitore coinvolto;
7. la regola di conservazione;
8. il percorso di classificazione dell’incidente se quella transazione fosse fraudolenta o esposta.

Se non è possibile tracciare il percorso, il processo non è ancora pronto a produrre evidenze.

Come auditor diversi testeranno lo stesso flusso wallet

Auditor diversi affrontano l’EU Digital Identity Wallet attraverso prospettive professionali diverse. Le stesse evidenze possono soddisfare più domande se sono strutturate correttamente.

Zenith Controls fornisce dettagli utili sulla metodologia di audit per queste aree. Per la gestione delle identità, gli auditor tracciano comunemente le identità utente attraverso onboarding, modifica e cessazione, riconciliano le registrazioni HR con gli elenchi degli account, ispezionano account non dipendenti e account di servizio e cercano utilizzi condivisi degli amministratori. Per l’autenticazione sicura, gli auditor confrontano le politiche con le configurazioni tecniche, riesaminano la copertura MFA, esaminano i controlli su password e sessioni e ispezionano i log di accesso riusciti e non riusciti. Per privacy e protezione delle PII, gli auditor campionano DPIA, processi per richieste degli interessati, formazione privacy, inventari PII, cifratura, log di accesso e controlli di conservazione.

La Politica di audit e monitoraggio della conformità di Clarysec spiega chiaramente l’obiettivo delle evidenze:

“Generare evidenze difendibili e una traccia di audit a supporto di richieste delle autorità di regolamentazione, procedimenti legali o richieste di assurance dei clienti.”
Da Politica di audit e monitoraggio della conformità, sezione “Obiettivi”, clausola della politica 3.4.

Quell’espressione, evidenze difendibili, segna la differenza tra una libreria di politiche e un sistema di conformità pronto ai fini dell’audit.

Errori comuni nei progetti di preparazione al wallet

Il primo errore è raccogliere troppi dati. I wallet possono rendere più semplice ottenere attributi verificati, ma GDPR spinge nella direzione opposta: raccogliere e conservare solo ciò che è necessario. Se il team di prodotto richiede informazioni di identità complete quando è richiesta solo la conferma dell’età, la progettazione dei controlli privacy è già carente.

Il secondo errore è ignorare le identità non umane. Le integrazioni wallet spesso si basano su client API, certificati, account di servizio, script di automazione e segreti. Se tali identità non hanno un responsabile, non sono ruotate, monitorate e dismesse, l’ambiente della parte facente affidamento è debole anche se l’ecosistema wallet è solido.

Il terzo errore è trattare i fornitori come documentazione di procurement. In base a NIS2 e DORA, la sicurezza dei fornitori è operativa. Servono due diligence, clausole contrattuali, monitoraggio, cooperazione sugli incidenti, diritti di audit e piani di uscita. Per le entità regolamentate da DORA, il registro delle terze parti ICT è un’evidenza di conformità centrale.

Il quarto errore è registrare senza governance. Un eccesso di registrazione può creare rischio privacy. Una registrazione insufficiente distrugge la capacità di indagine. Definire eventi di autenticazione, verifica, amministrativi e rilevanti per gli incidenti, proteggere i log da alterazioni, limitare l’accesso e allineare la conservazione alle esigenze legali e aziendali.

Il quinto errore è non provare il processo di segnalazione. NIS2 prevede aspettative di segnalazione entro 24 ore, 72 ore e un mese per gli incidenti significativi. DORA prevede report iniziali, intermedi e finali per gli incidenti ICT rilevanti. Se la prima volta che l’organizzazione mappa un incidente relativo al wallet a queste tempistiche è durante un evento reale, la governance ha fallito.

Trasformare l’adozione dell’EUDI Wallet in evidenze pronte ai fini dell’audit

L’EU Digital Identity Wallet cambierà onboarding e fiducia digitale in tutta Europa. Tuttavia, per CISO, DPO, responsabili della conformità, auditor e responsabili dell’attività, la scelta vincente non è creare un altro programma di conformità isolato. La scelta vincente è integrare l’adozione del wallet nel SGSI e mapparla su privacy, identità, autenticazione, fornitori, registrazione, resilienza e risposta agli incidenti.

Clarysec può aiutarti a farlo in modo strutturato:

1. Usa Zenith Blueprint per collocare l’adozione del wallet nella fase Gestione del rischio, Passo 14 per i riferimenti normativi incrociati, Passo 19 per l’autenticazione sicura e Passo 23 per l’applicazione dei controlli su fornitori, privacy e aspetti legali.
2. Usa Zenith Controls per mappare i controlli ISO/IEC 27002:2022 su gestione delle identità, autenticazione sicura e privacy alle evidenze GDPR, NIS2, DORA, NIST e COBIT 2019.
3. Usa i modelli di politiche Clarysec, come Politica di conformità legale e normativa, Politica di protezione dei dati e privacy, Politica di gestione degli account utente e dei privilegi, Politica di registrazione e monitoraggio, Politica di sicurezza delle terze parti e dei fornitori - PMI e Politica di audit e monitoraggio della conformità, per convertire gli obblighi in pratiche assegnate, verificabili e testabili.
4. Costruisci un pacchetto di evidenze per la parte facente affidamento sul wallet prima del lancio, non dopo la prima richiesta di audit.

Se la tua organizzazione prevede di fare affidamento sull’EU Digital Identity Wallet nel 2026, questo è il momento di porsi una domanda: possiamo dimostrare, con evidenze difendibili, che questo flusso di identità è sicuro, lecito, resiliente e governato?

La risposta di Clarysec è pratica: mappalo, assegnane la titolarità, testalo e mantieni le evidenze pronte.