Architettura zero trust 2026: evidenze pronte per l’audit

L’audit zero trust del lunedì mattina che nessuno aveva pianificato

Alle 08:12 di lunedì, il CISO di una fintech SaaS europea riceve tre messaggi nell’arco di cinque minuti.

Il primo arriva da un cliente bancario: “Vi chiediamo di fornirci il pacchetto di evidenze sulla vostra architettura zero trust per il nostro riesame annuale ICT delle terze parti.”

Il secondo arriva dalla funzione legale: “Potremmo essere classificati come entità importante ai sensi di NIS2 in uno Stato membro e alcuni clienti chiedono se DORA si applichi a noi in qualità di fornitore di servizi ICT.”

Il terzo arriva dal responsabile dell’ingegneria: “Abbiamo MFA, SSO, EDR, policy di rete Kubernetes e alert SIEM. Questo è zero trust?”

È qui che molte organizzazioni si bloccano. Dispongono di strumenti di sicurezza, ma non di un modello operativo di conformità zero trust. Possono mostrare screenshot MFA, ma non spiegare come identità, postura di sicurezza del dispositivo, principio del privilegio minimo, segmentazione, monitoraggio, segnalazione degli incidenti, misure di protezione della privacy e dipendenze dai fornitori siano integrati tra loro. Possono mostrare controlli, ma non tracciabilità.

Nel 2026, un’architettura zero trust basata su NIST SP 800-207 deve andare oltre “never trust, always verify”. Per CISO, responsabili compliance, auditor e titolari dei processi aziendali, la domanda pratica è più precisa:

Come trasformare lo zero trust in evidenze che soddisfino ISO/IEC 27001:2022, le aspettative NIS2 di igiene cyber, la gestione del rischio ICT di DORA, la sicurezza del trattamento prevista dal GDPR Article 32, la due diligence dei clienti e la supervisione del consiglio di amministrazione?

La risposta non è un altro strumento. È un modello di evidenze basato sul rischio che collega policy, controlli, attuazione tecnica, monitoraggio e accountability della direzione.

Zero trust nel 2026: dalla strategia di sicurezza alle evidenze di conformità

NIST SP 800-207 definisce lo zero trust come un insieme di principi per progettare e gestire sistemi sicuri in cui la fiducia non è mai implicita. L’accesso è concesso in base a identità, contesto, policy, postura dell’asset e valutazione continua.

I sette principi zero trust di NIST sono particolarmente utili perché trasformano uno slogan di sicurezza generico in qualcosa che può essere mappato, testato e sottoposto ad audit:

1. Tutte le fonti di dati e tutti i servizi informatici sono considerati risorse.
2. Tutte le comunicazioni sono protette indipendentemente dalla posizione di rete.
3. L’accesso alle singole risorse aziendali è concesso per singola sessione.
4. L’accesso alle risorse è determinato da policy dinamiche, che includono attributi di identità, dispositivo, applicazione e comportamento.
5. L’organizzazione monitora e misura integrità e postura di sicurezza di tutti gli asset di proprietà e associati.
6. Autenticazione e autorizzazione per tutte le risorse sono dinamiche e applicate rigorosamente prima che l’accesso sia consentito.
7. L’organizzazione raccoglie informazioni su asset, infrastruttura e comunicazioni e le utilizza per migliorare il livello di sicurezza.

Per un moderno provider SaaS, una banca digitale, un prestatore di servizi gestiti o una piattaforma cloud-native, questi principi si traducono in domini di controllo operativi:

• L’identità è verificata e governata.
• I dispositivi sono valutati prima che l’accesso sia concesso.
• L’accesso privilegiato è ridotto al minimo e riesaminato.
• I percorsi di rete sono segmentati e controllati.
• Applicazioni, API e archivi dati applicano l’autorizzazione.
• Log e telemetria supportano il monitoraggio continuo.
• Gli incidenti attivano contenimento, segnalazione e ripristino.
• Le evidenze dimostrano che i controlli sono operativi, non solo progettati.

È su quest’ultimo punto che entra in gioco la conformità.

ISO/IEC 27001:2022 richiede alle organizzazioni di definire contesto, parti interessate, requisiti legali e contrattuali applicabili, ambito di applicazione, interfacce e dipendenze. Richiede inoltre valutazione del rischio, trattamento del rischio, Dichiarazione di Applicabilità, accountability della leadership, audit interno, riesame della direzione e miglioramento continuo.

Lo zero trust si inserisce naturalmente in questa struttura quando viene trattato come sistema di controllo. Non deve rimanere fuori dal SGSI come iniziativa dell’ingegneria. Deve far parte della valutazione del rischio, della selezione dei controlli, della governance delle policy, della gestione dei fornitori, della protezione della privacy, della risposta agli incidenti e della reportistica al consiglio di amministrazione.

La pressione normativa dietro le evidenze zero trust

La pressione per produrre evidenze zero trust deriva normalmente da obblighi sovrapposti, non da un singolo standard.

NIS2 può applicarsi a entità pubbliche o private operanti nei settori dell’Annex I o dell’Annex II che soddisfano soglie dimensionali e di attività, e può applicarsi anche a determinate entità più piccole ma critiche. L’Annex I include fornitori di servizi di cloud computing, fornitori di data center, fornitori di reti per la distribuzione di contenuti, prestatori di servizi fiduciari, prestatori di servizi gestiti, prestatori di servizi di sicurezza gestiti, banche ed entità delle infrastrutture dei mercati finanziari. L’Annex II include fornitori digitali quali marketplace online, motori di ricerca e piattaforme di social networking.

NIS2 Article 20 attribuisce all’organo di gestione la responsabilità della cibersicurezza. Il consiglio di amministrazione deve approvare le misure di gestione dei rischi di cibersicurezza, supervisionarne l’attuazione e ricevere formazione in materia di cibersicurezza. Article 21 richiede misure tecniche, operative e organizzative appropriate e proporzionate che coprano analisi dei rischi, trattamento degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, processo di gestione delle vulnerabilità, valutazione dell’efficacia, igiene cyber, formazione, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset e, ove appropriato, MFA o autenticazione continua. Article 23 introduce la segnalazione a fasi degli incidenti significativi, inclusi preallarme entro 24 ore, notifica entro 72 ore e relazione finale.

DORA si applica dal 17 gennaio 2025 e istituisce un regime uniforme di resilienza operativa digitale per le entità finanziarie. Copre la gestione del rischio ICT, la segnalazione degli incidenti gravi connessi all’ICT, i test di resilienza operativa, la condivisione di informazioni sulle minacce e il rischio ICT di terze parti. DORA Articles 5 e 6 richiedono governance e un quadro documentato per la gestione del rischio ICT. Article 9 tratta protezione e prevenzione, incluse politiche, procedure, protocolli e strumenti per proteggere i sistemi ICT. Article 17 richiede un processo di gestione degli incidenti connessi all’ICT.

GDPR si applica al trattamento effettuato nel contesto di uno stabilimento nell’UE e anche a titolari o responsabili del trattamento non UE che offrono beni o servizi a persone nell’UE o ne monitorano il comportamento. GDPR Article 5 richiede accountability. Article 32 richiede misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio. Article 33 richiede la notifica della violazione dei dati personali all’autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui se ne viene a conoscenza.

Un modello di evidenze zero trust è utile perché lo stesso controllo può supportare più quadri di riferimento. MFA può supportare il controllo degli accessi di ISO/IEC 27001:2022, le misure di autenticazione NIS2, i requisiti di protezione DORA e la sicurezza del trattamento ai sensi del GDPR. Ma solo se l’organizzazione può dimostrarne ambito, titolarità, attuazione, monitoraggio e riesame.

Mappare i principi zero trust NIST sui controlli ISO/IEC 27001:2022

I controlli dell’Annex A di ISO/IEC 27001:2022, supportati dalla guida di attuazione ISO/IEC 27002:2022, forniscono il linguaggio di audit necessario alla maggior parte delle organizzazioni. La tabella seguente traduce i principi zero trust NIST in aree di controllo ISO riconoscibili dagli auditor.

Questa mappatura non è solo un esercizio di progettazione tecnica. Diventa la struttura del registro dei rischi, della Dichiarazione di Applicabilità, del pacchetto di evidenze e dell’agenda del riesame della direzione.

Ad esempio, uno scenario di rischio come “un account sviluppatore compromesso modifica il codice di produzione e accede ai dati dei clienti” dovrebbe essere mappato su gestione delle identità, MFA, accesso privilegiato, segregazione delle reti, logging, monitoraggio, sviluppo sicuro, gestione delle modifiche e risposta agli incidenti. Un singolo scenario può supportare ISO/IEC 27001:2022, NIS2 Article 21, gestione del rischio ICT DORA e GDPR Article 32.

Lo stack di controlli zero trust di Clarysec

Clarysec costruisce lo zero trust intorno a cinque domini di evidenza: identità, dispositivo, rete, applicazione e dati, con monitoraggio e governance trasversali a tutti e cinque.

La base è il controllo degli accessi e la gestione delle identità. In Zenith Controls: guida di conformità multi-framework, il controllo 5.15 di ISO/IEC 27002:2022, controllo degli accessi, è classificato come controllo preventivo a supporto di riservatezza, integrità e disponibilità, allineato al concetto di cibersicurezza Protect e alla capacità Gestione delle identità e degli accessi. Il controllo 5.16, Gestione delle identità, è anch’esso preventivo e collegato alle stesse proprietà CIA e alla capacità IAM. Il controllo 8.16, Attività di monitoraggio, è classificato come controllo di rilevamento e correttivo, a supporto di Detect e Respond attraverso la gestione degli eventi di sicurezza delle informazioni.

Questa combinazione è essenziale. Lo zero trust non è solo controllo degli accessi. È controllo degli accessi più ciclo di vita dell’identità, più postura di sicurezza del dispositivo, più segregazione delle reti, più monitoraggio, più risposta.

Le clausole delle policy Clarysec trasformano questo modello in governance applicabile.

Dalla Politica aziendale di controllo degli accessi, sezione Obiettivi, clausola 3.4:

Supportare i principi zero trust negando l’accesso per impostazione predefinita, salvo approvazione e giustificazione esplicite.

Dalla Politica aziendale di gestione degli account utente e dei privilegi, sezione Requisiti di applicazione della policy, clausola 6.2.1:

A tutti gli utenti deve essere assegnato il livello minimo di accesso necessario per svolgere le proprie mansioni lavorative.

Dalla Politica aziendale di sicurezza della rete, sezione Requisiti di governance, clausola 5.2:

Tutto il traffico tra zone deve essere controllato da firewall o da soluzioni di perimetro definito dal software, con configurazioni esplicite di negazione predefinita.

Dalla Politica aziendale di registrazione e monitoraggio, sezione Obiettivi, clausola 3.4:

Istituire sistemi centralizzati di registrazione e alerting (ad es. SIEM) per aggregare, correlare ed effettuare l’escalation delle attività sospette quasi in tempo reale.

Dalla Politica aziendale per la sicurezza delle informazioni, sezione Requisiti di applicazione della policy, clausola 6.6.1:

Tutti i controlli implementati devono essere verificabili, supportati da procedure documentate ed evidenze conservate del loro funzionamento.

Per le PMI, lo stesso intento di governance può essere attuato con documentazione di policy più snella. La Politica di gestione degli account utente e dei privilegi - PMI, sezione Obiettivi, clausola 3.2, stabilisce:

Applicare il principio del privilegio minimo, assicurando che agli utenti sia concesso solo il livello minimo di accesso necessario per svolgere le proprie mansioni.

La Politica di controllo degli accessi - PMI, sezione Requisiti di governance, clausola 5.4.3, aggiunge:

Gli account privilegiati devono utilizzare l’autenticazione a più fattori (MFA), ove supportata.

La Politica di sicurezza della rete - PMI, sezione Requisiti di applicazione della policy, clausola 6.2.3, stabilisce:

Il traffico tra segmenti deve essere filtrato e l’accesso inter-segmento deve seguire il principio del privilegio minimo.

La Politica di registrazione e monitoraggio - PMI, sezione Finalità, clausola 1.3, spiega:

Logging e monitoraggio supportano rilevamento delle minacce, conformità normativa, segnalazione e gestione degli incidenti e analisi forense.

Per uno zero trust guidato dalla privacy, la Politica di protezione dei dati e privacy - PMI, sezione Requisiti di governance, clausola 5.3.2, stabilisce:

L’accesso degli utenti ai dati personali deve essere limitato ai ruoli con una necessità aziendale documentata.

Queste clausole creano punti di ancoraggio per l’audit. Un auditor può verificare se l’accesso è negato per impostazione predefinita, se i privilegi sono ridotti al minimo, se il traffico tra zone è controllato, se i log sono centralizzati e se le evidenze sono conservate.

Mappa multi-framework delle evidenze zero trust

Un solido modello di evidenze zero trust deve evitare screenshot frammentati. Le evidenze devono mostrare governance, progettazione, attuazione, monitoraggio e riesame.

Questa tabella è il nucleo di un programma zero trust pronto per il consiglio di amministrazione. Mostra come un unico ambiente di controllo possa supportare molteplici esigenze di assurance senza creare pacchetti di evidenze separati per ogni quadro di riferimento.

Usare Zenith Blueprint per creare tracciabilità

Zenith Blueprint: roadmap in 30 passi per auditor di Clarysec è progettato per impedire che lo zero trust diventi una filosofia dell’ingegneria non documentata. Nella fase di gestione del rischio, Step 13, Pianificazione del trattamento del rischio e Dichiarazione di Applicabilità, spiega:

La SoA è, di fatto, un documento ponte: collega la valutazione/trattamento del rischio ai
controlli effettivamente presenti. Completandola, si verifica anche se sono stati omessi controlli.

Lo stesso passaggio raccomanda di mappare i controlli sui rischi, aggiungere riferimenti ai controlli dell’Annex A nelle voci del trattamento del rischio e inserire riferimenti incrociati a regolamenti come GDPR, NIS2 o DORA quando i controlli sono implementati per soddisfare tali obblighi.

Per lo zero trust, questo è il ponte mancante. Se un auditor chiede perché è stato implementato l’accesso condizionale, la risposta non dovrebbe essere “perché lo dice lo zero trust”. Una risposta migliore è:

• Lo scenario di rischio è l’accesso non autorizzato ai dati dei clienti tramite credenziali compromesse.
• Il proprietario del rischio è il CTO o il responsabile dell’ingegneria.
• Il trattamento include SSO, MFA, accesso condizionale, validazione della postura degli endpoint, principio del privilegio minimo, segmentazione e monitoraggio.
• La SoA mappa il trattamento su controllo degli accessi, gestione delle identità, logging, monitoraggio, crittografia, gestione delle vulnerabilità e gestione dei servizi cloud.
• Lo stesso trattamento supporta NIS2 Article 21, la gestione del rischio ICT DORA e GDPR Article 32.
• Le evidenze includono clausole di policy, riesami degli accessi, alert SIEM, report sulla postura EDR, regole firewall, esportazioni IAM, esercitazioni sugli incidenti e verbali del riesame della direzione.

È così che l’architettura zero trust diventa pronta per l’audit.

Fiducia negli endpoint, API e segregazione della rete nella pratica

Lo zero trust spesso fallisce perché le organizzazioni si concentrano sull’identità ignorando il contesto di dispositivo, workload, dati e rete.

Lo Step 19 di Zenith Blueprint, Controlli tecnologici I, spiega chiaramente il requisito relativo alla postura degli endpoint:

L’accesso alle informazioni tramite endpoint deve essere contestuale. Ad esempio, il dispositivo
soddisfa gli standard minimi di sicurezza prima di accedere alle risorse aziendali? Ha superato di recente
una scansione malware? Si connette da una posizione o da una rete insolita? Integrandosi con i principi
zero trust, la postura dell’endpoint può alimentare l’accesso condizionale, negando l’ingresso fino a quando
il dispositivo non dimostra di essere sicuro.

Questo rende il dispositivo parte della decisione di autorizzazione. Una password valida proveniente da un laptop non gestito non deve essere trattata come un accesso valido da un dispositivo endpoint aziendale conforme, cifrato e monitorato.

Lo stesso passaggio evidenzia che le restrizioni di accesso si applicano ad applicazioni, servizi e API, non solo agli utenti:

Le restrizioni di accesso dovrebbero essere applicate anche ad applicazioni, servizi e API, non solo alle persone.
Ad esempio, un microservizio potrebbe richiedere solo accesso in lettura a una tabella di database, non diritti CRUD completi.
Uno strumento di backup potrebbe avere necessità di accesso solo a specifici bucket di archiviazione, non a tutte le risorse del tenant.

Queste indicazioni sono critiche per gli ambienti cloud-native. Ambiti API, account di servizio, identità dei workload, ruoli Kubernetes e policy cloud IAM devono tutti seguire il principio del privilegio minimo. L’accesso umano è solo una parte della superficie di controllo.

Lo Step 20 di Zenith Blueprint tratta la segregazione delle reti:

La segregazione è uno dei principi più antichi ed efficaci della cibersicurezza: limitare la
propagazione, ridurre il rischio e contenere il danno. Il controllo 8.22 si concentra sulla segregazione
delle reti, ossia la pratica di separare sistemi, servizi e utenti in zone logiche o fisiche diverse
per prevenire accessi non autorizzati e limitare il movimento laterale in caso di compromissione.

Questo è fondamentale per la resilienza DORA e NIS2. Una rete zero trust deve assumere che un account, un workload o un endpoint possano essere compromessi. La segmentazione impedisce che un evento locale diventi un incidente sistemico.

Un pacchetto di evidenze zero trust in 10 giorni

Immaginiamo una fintech SaaS che fornisce analisi antifrode alle banche. Tratta dati personali, utilizza infrastruttura cloud, si basa su Kubernetes gestito, si integra con API dei clienti e utilizza un provider di identità terzo. Un cliente richiede evidenze zero trust e l’azienda ha dieci giorni lavorativi.

Uno sprint pratico Clarysec per le evidenze sarebbe strutturato così.

L’obiettivo non è fingere che l’organizzazione abbia raggiunto uno zero trust perfetto in dieci giorni. L’obiettivo è creare una catena di evidenze difendibile per i rischi più importanti e dimostrare che il programma è governato, misurabile e in miglioramento.

Come auditor diversi testeranno lo zero trust

Un errore comune è preparare un’unica narrazione tecnica e presumere che ogni auditor ponga le stesse domande. Non sarà così.

Un auditor ISO/IEC 27001:2022 cercherà il sistema di gestione. Chiederà se i rischi zero trust sono inclusi nella valutazione del rischio, se i trattamenti sono approvati, se la SoA è completa, se le policy sono documenti controllati, se si svolgono riesami degli accessi, se gli audit interni testano i controlli e se i riesami della direzione monitorano le prestazioni.

Un revisore DORA chiederà se i controlli zero trust fanno parte del quadro documentato di gestione del rischio ICT. Si aspetterà inventari di asset e dipendenze, mappatura delle funzioni critiche o importanti, classificazione degli incidenti, escalation verso il consiglio di amministrazione, test, requisiti contrattuali per terze parti, diritto di audit, strategie di uscita e tracciamento delle azioni correttive.

Un valutatore NIS2 si concentrerà sull’accountability dell’organo di gestione, sulle misure di gestione dei rischi di cibersicurezza di Article 21 e sulla preparazione alla segnalazione degli incidenti di Article 23. Si aspetterà inoltre evidenze della gestione della sicurezza della catena di fornitura, continuità operativa, gestione delle vulnerabilità, controllo degli accessi e igiene cyber.

Un revisore GDPR o auditor privacy chiederà se l’accesso ai dati personali è necessario, documentato, limitato, monitorato e allineato alle finalità del trattamento. Esaminerà i ruoli di titolare e responsabile del trattamento, il rilevamento delle violazioni dei dati personali, l’accesso basato sui ruoli, la cifratura, la pseudonimizzazione ove appropriata, la conservazione e l’accountability.

Lo stesso controllo può soddisfare più domande, ma solo se le evidenze sono organizzate.

Fornitori, cloud e rischio ICT di terze parti

Lo zero trust non si ferma al firewall e, negli ambienti cloud, potrebbe non esistere alcun perimetro firewall tradizionale. Provider di identità, piattaforme cloud, strumenti CI/CD, fornitori di rilevamento gestito, responsabili dei pagamenti, gateway API e team di sviluppo esternalizzati diventano tutti parte del tessuto di fiducia.

NIS2 Article 21 include esplicitamente la sicurezza della catena di fornitura per fornitori diretti e prestatori di servizi, incluse vulnerabilità dei fornitori, resilienza di prodotti e servizi, pratiche di cibersicurezza dei fornitori e procedure di sviluppo sicuro.

DORA richiede che il rischio ICT di terze parti sia gestito come parte del quadro di gestione del rischio ICT, con un registro dei contratti di servizi ICT, due diligence precontrattuale, valutazione della criticità, rischio di concentrazione, requisiti contrattuali di sicurezza, assistenza in caso di incidente, cooperazione con le autorità, diritto di audit, diritti di risoluzione, strategie di uscita e piani di transizione.

Per lo zero trust, la regola pratica è semplice: non fidarsi di una connessione con un fornitore solo perché è contrattuale. Occorre richiedere controlli tecnici ed evidenze.

Un’integrazione API cliente dovrebbe prevedere token con ambito definito, limitazione della frequenza delle richieste, monitoraggio, rotazione, titolarità e revoca. Un prestatore di servizi gestiti dovrebbe utilizzare MFA, account utente nominativi, principio del privilegio minimo, registrazione delle sessioni e accesso limitato nel tempo. Un rapporto con un provider cloud dovrebbe prevedere mappatura delle responsabilità condivise, configurazione della cifratura, conservazione dei log, test dei backup e pianificazione dell’uscita.

Per questo motivo le evidenze su fornitori e cloud appartengono al modello zero trust, non a una cartella acquisti separata.

Metriche che dimostrano che lo zero trust è operativo

Consigli di amministrazione e auditor non vogliono solo diagrammi architetturali. Vogliono evidenze operative e tendenze di miglioramento.

Metriche zero trust utili includono:

• Percentuale di account privilegiati protetti da MFA.
• Percentuale di utenti coperti da accesso condizionale.
• Numero di account privilegiati permanenti rispetto agli account just-in-time.
• Numero di riesami degli accessi scaduti.
• Percentuale di endpoint conformi ai requisiti di postura.
• Copertura EDR sugli asset critici.
• Numero di tentativi di accesso negati per rischio legato a dispositivo o posizione.
• Tempo medio di rilevamento delle attività privilegiate sospette.
• Tempo medio di revoca degli accessi dopo la cessazione.
• Percentuale di regole firewall tra zone riesaminate nell’ultimo trimestre.
• Numero di fornitori critici con evidenze di sicurezza aggiornate.
• Numero di eccezioni zero trust oltre la data di rimedio.
• Percentuale di applicazioni critiche che inviano log al SIEM.
• Risultati delle simulazioni di incidente per compromissione delle credenziali.

Queste metriche supportano il miglioramento continuo ISO/IEC 27001:2022, la valutazione dell’efficacia NIS2, le aspettative DORA su test e azioni correttive e l’accountability GDPR.

Errori comuni nelle evidenze zero trust

Gli errori più frequenti non dipendono dalla mancanza di strumenti. Dipendono da una tracciabilità debole.

Primo, le organizzazioni implementano MFA ma non riescono a dimostrare che gli account privilegiati siano coperti integralmente. Account di servizio, account break-glass e account amministratore locali spesso restano fuori dal controllo.

Secondo, i riesami degli accessi sono svolti manualmente ma non collegati a ruoli aziendali, sensibilità dei dati o proprietari del rischio. L’evidenza mostra che qualcuno ha cliccato “riesaminato”, non che gli accessi non necessari siano stati rimossi.

Terzo, la segmentazione della rete esiste nei diagrammi ma non nelle regole testate. Gli auditor chiederanno se l’accesso inter-segmento è negato per impostazione predefinita e se le eccezioni sono approvate.

Quarto, i log sono raccolti ma non sono azionabili. Un SIEM senza casi d’uso definiti, triage degli alert e procedure di risposta non dimostra il monitoraggio continuo.

Quinto, l’accesso dei fornitori non è gestito. I fornitori possono utilizzare account condivisi, accesso VPN persistente o ruoli cloud ampi senza monitoraggio delle sessioni.

Sesto, le evidenze privacy sono separate dalle evidenze di sicurezza. GDPR richiede la protezione dimostrabile dei dati personali; pertanto, i controlli di identità e accesso devono collegarsi alle categorie di dati e alle finalità del trattamento.

Infine, le eccezioni non sono documentate. Lo zero trust può tollerare eccezioni se sono valutate in base al rischio, approvate, limitate nel tempo e monitorate. Non può tollerare eccezioni invisibili.

Crea il tuo pacchetto di evidenze zero trust con Clarysec

L’architettura zero trust nel 2026 non è uno slogan. È un modello operativo di conformità che collega identità, dispositivi, applicazioni, segmentazione della rete, principio del privilegio minimo, monitoraggio continuo, controllo dei fornitori e misure di protezione della privacy in un unico sistema verificabile.

Se ti stai preparando alla certificazione ISO/IEC 27001:2022, rispondi a richieste clienti NIS2, ti stai allineando alla gestione del rischio ICT DORA o devi dimostrare la sicurezza del trattamento ai sensi del GDPR Article 32, inizia dalla tracciabilità.

Usa Zenith Blueprint: roadmap in 30 passi per auditor per mappare i rischi zero trust nel registro dei rischi, nel piano di trattamento del rischio e nella SoA. Usa Zenith Controls: guida di conformità multi-framework per allineare controllo degli accessi, gestione delle identità e monitoraggio alle aspettative multi-framework. Usa la libreria di policy Clarysec, inclusa la Politica aziendale di controllo degli accessi, la Politica aziendale di gestione degli account utente e dei privilegi, la Politica aziendale di sicurezza della rete, la Politica aziendale di registrazione e monitoraggio, la Politica aziendale per la sicurezza delle informazioni e la Politica di protezione dei dati e privacy - PMI, per trasformare l’architettura in governance applicabile.

Il prossimo passo operativo consiste nel selezionare uno scenario ad alto rischio, ad esempio l’accesso privilegiato compromesso ai dati dei clienti, e costruire attorno a esso una catena completa di evidenze zero trust. Se puoi dimostrare quello scenario end to end, hai la base per un programma zero trust scalabile, verificabile e pronto per le autorità di regolamentazione.

Scarica i bundle di policy Clarysec o pianifica una call strategica per vedere come Zenith Blueprint e Zenith Controls possono trasformare lo zero trust da rischio di audit a vantaggio di conformità.