Governance del ciclo di vita delle politiche per ISO 27001, NIS2 e DORA

L’e-mail arrivò nella casella di posta della Chief Information Security Officer (CISO), Maria Petrova, con un tonfo discreto che suonò come una sirena. Proveniva dall’auditor esterno: un elenco preliminare di richieste per un audit di sorveglianza ISO/IEC 27001:2022 combinato con una valutazione di preparazione a DORA. La prima voce sembrava semplice:

“Fornire la Politica per la sicurezza delle informazioni vigente, la cronologia completa delle versioni, le evidenze dell’approvazione della direzione per ciascuna versione e le registrazioni della comunicazione al personale interessato negli ultimi 24 mesi.”

L’azienda di Maria, una piattaforma fintech di medie dimensioni, aveva politiche. Decine. Aveva una Politica per la sicurezza delle informazioni, un Piano di risposta agli incidenti (IRP), un questionario di sicurezza dei fornitori, un Registro dei rischi, una procedura di controllo degli accessi, un Piano di continuità operativa (BCP) e una cartella piena di evidenze di audit. Ma i file erano dispersi tra siti SharePoint, spazi Confluence legacy, thread e-mail, allegati di ticket e unità condivise appartenenti a persone che avevano già lasciato l’azienda.

Il vero problema emerse quando arrivarono le domande di approfondimento dell’auditor.

Chi ha approvato la procedura vigente per gli incidenti? Perché la politica di sicurezza dei fornitori in SharePoint indica la versione 2.1 mentre la funzione acquisti usa la versione 1.8? Quale politica è mappata alle misure di gestione del rischio di NIS2 Article 21? Dov’è la registrazione che dimostra che il personale è stato informato dell’ultimo aggiornamento della politica? Perché è stata concessa un’eccezione per l’accesso privilegiato, chi ha accettato il rischio residuo e quando scade? I documenti obsoleti sono rimossi dall’uso operativo? Per quanto tempo sono conservati i rapporti di audit? L’azienda può dimostrare che la libreria delle politiche è stata riesaminata dopo l’ultima modifica rilevante dei sistemi?

Maria aveva controlli, ma non aveva controllo sui controlli.

Questo è il problema della governance del ciclo di vita delle politiche nel 2026. Le organizzazioni non falliscono più gli audit solo perché una regola del firewall è errata o manca un test dei backup. Falliscono perché le informazioni documentate sono frammentate, non verificabili, duplicate, obsolete, non controllate o scollegate dagli obblighi legali. Ai sensi della clausola 7.5 di ISO/IEC 27001:2022, le informazioni documentate non sono semplice amministrazione documentale. Sono la memoria operativa del SGSI. In NIS2 supportano l’approvazione e la supervisione dell’organo di gestione. In DORA diventano parte del quadro per la gestione del rischio ICT e della traccia delle evidenze di resilienza. In GDPR dimostrano l’accountability.

La posizione di Clarysec è chiara: una libreria di politiche non è un deposito di documenti. È un sistema governato di evidenze.

Perché la governance del ciclo di vita delle politiche è ormai un tema da consiglio di amministrazione

La governance del ciclo di vita delle politiche è la disciplina che regola creazione, approvazione, pubblicazione, comunicazione, riesame, modifica, dismissione, conservazione e dimostrazione tramite evidenze delle politiche e delle registrazioni correlate. Risponde alle domande che auditor, autorità di regolamentazione, clienti e consigli di amministrazione pongono ormai sistematicamente:

1. Chi è il titolare di ciascuna politica?
2. Chi la approva?
3. Quali requisiti legali, contrattuali e di rischio soddisfa?
4. Quali controlli e procedure la attuano?
5. Quale versione è vigente?
6. Chi è stato informato, formato o tenuto a prenderne atto?
7. Quali eccezioni sono collegate alla politica?
8. Quali registrazioni dimostrano che la politica è operativa?
9. Che cosa accade quando diventa obsoleta?

ISO/IEC 27001:2022 supporta questa disciplina attraverso la clausola 7.5 sulle informazioni documentate, la clausola 5 sulla leadership, la clausola 6 sulla pianificazione e sul trattamento del rischio, la clausola 8 sul controllo operativo e i controlli dell’Allegato A relativi a politiche, registrazioni, requisiti legali, fornitori, incidenti, continuità, privacy, logging, monitoraggio e gestione delle modifiche.

La pressione normativa è altrettanto diretta.

NIS2 Article 20 richiede agli organi di gestione di approvare le misure di gestione del rischio di cibersicurezza, supervisionarne l’attuazione e ricevere una formazione adeguata. Article 21 richiede misure tecniche, operative e organizzative basate sul rischio, incluse politiche di sicurezza, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, valutazione dell’efficacia, igiene informatica, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset e autenticazione. Un corpus di politiche privo di evidenze su titolarità, approvazione e riesame indebolisce la dimostrazione dell’accountability della direzione.

DORA si applica dal 17 gennaio 2025 e istituisce un quadro uniforme dell’UE per gestione del rischio ICT, segnalazione degli incidenti, test di resilienza operativa digitale, rischio ICT di terze parti e requisiti contrattuali. Per le entità finanziarie che sono anche entità essenziali o importanti ai sensi di NIS2, DORA è considerato l’atto giuridico settoriale dell’Unione per gli obblighi di cibersicurezza corrispondenti. Article 5 richiede la responsabilità dell’organo di gestione per il quadro per la gestione del rischio ICT, le politiche, le responsabilità, i piani di continuità, gli audit, le politiche sulle terze parti ICT, i canali di segnalazione e la formazione. Article 6 richiede un quadro per la gestione del rischio ICT ben documentato, riesaminato almeno annualmente per le entità finanziarie non microimprese e migliorato sulla base delle lezioni apprese.

GDPR aggiunge il requisito di accountability. Article 5 richiede che i dati personali siano trattati in modo lecito, corretto e trasparente, per finalità specifiche, con minimizzazione, accuratezza, limitazione della conservazione e sicurezza. Article 5(2) rende il titolare del trattamento responsabile della dimostrazione della conformità. Tale dimostrazione dipende da registrazioni controllate: decisioni sulla base giuridica, piani di conservazione, valutazioni d’impatto sulla protezione dei dati (DPIA) ove applicabili, due diligence sui responsabili del trattamento, registrazioni delle violazioni, riesami degli accessi, registrazioni della formazione e approvazioni delle politiche.

Il filo conduttore è l’evidenza. Un auditor non chiederà soltanto se una politica esiste. Chiederà il suo certificato di nascita, la cronologia delle versioni, la traccia di approvazione, la registrazione della comunicazione, le procedure correlate e le registrazioni operative che dimostrano che funziona.

La spina dorsale delle informazioni documentate in ISO/IEC 27001:2022

La base della documentazione difendibile è la clausola 7.5 di ISO/IEC 27001:2022, Informazioni documentate. La clausola richiede alle organizzazioni di creare, aggiornare e controllare le informazioni documentate necessarie al SGSI e richieste dalla norma.

Un modo pratico per comprenderla è separare le informazioni documentate in tre livelli:

Il Zenith Blueprint: roadmap in 30 passi per auditor di Clarysec tratta esplicitamente questo aspetto nella fase Fondazione e leadership del SGSI, Step 6: Informazioni documentate e costruzione della libreria SGSI. Spiega che la clausola 7.5 copre la documentazione in generale, la creazione e l’aggiornamento, e il controllo delle informazioni documentate.

Il Zenith Blueprint traduce questo principio in indicazioni pratiche di attuazione:

“I documenti dovrebbero avere un’identificazione corretta (un titolo, eventualmente un numero di documento o un identificativo univoco, un autore), un formato appropriato … e un riesame e un’approvazione di adeguatezza prima dell’uso.”

Fornisce inoltre la regola operativa che molte organizzazioni trascurano:

“Assicurare che sia facilmente reperibile solo la versione corrente (archiviare le versioni obsolete o contrassegnarle chiaramente come sostituite).”

È qui che molte implementazioni del SGSI si rompono senza fare rumore. Una politica può essere stata approvata una volta, ma se le vecchie versioni restano disponibili, il personale utilizza procedure superate o gli auditor non riescono a tracciare le modifiche, il documento non è più controllato in modo significativo.

Il Zenith Blueprint raccomanda di istituire una “libreria documentale del SGSI” con cartelle per politiche e procedure, valutazione del rischio e SoA, registrazioni della formazione, audit e riesami, registrazioni degli incidenti, asset e inventario, e una libreria dei controlli dell’Allegato A. Indica inoltre che il repository deve essere “accessibile ma sicuro”, con politiche leggibili dai dipendenti e cartelle riservate, quali valutazione del rischio e registrazioni degli incidenti, ad accesso limitato.

Questo non è solo un modello di archiviazione. È un’architettura di governance.

Il modello Clarysec per il ciclo di vita delle politiche

Clarysec struttura la governance del ciclo di vita delle politiche ISO 27001 intorno a un ciclo chiuso: requisito, titolare, documento, approvazione, pubblicazione, comunicazione, evidenza, riesame, modifica, conservazione e dismissione. Questo ciclo previene il classico fallimento in audit: l’azienda possiede documenti, ma non può dimostrarne autorità, attualità o controllo.

Questo ciclo di vita è più robusto di un’approvazione una tantum perché collega i documenti a controlli, titolari ed evidenze. Supporta inoltre la conformità trasversale. Una singola politica di risposta agli incidenti può essere mappata ai controlli sugli incidenti dell’Allegato A di ISO/IEC 27001:2022, alla preparazione alla notifica di NIS2 Article 23, ai processi di classificazione e segnalazione degli incidenti DORA, alla gestione delle violazioni dei dati personali GDPR, agli esiti Respond del NIST CSF 2.0 e alle aspettative di governance di COBIT 2019.

Cosa richiedono le politiche Clarysec per riesame, versionamento ed evidenze

La libreria di politiche Clarysec è progettata affinché i requisiti del ciclo di vita delle politiche non siano lasciati all’interpretazione.

Per le PMI, la Politica per la sicurezza delle informazioni - PMI stabilisce un evento di riesame chiaro:

“Questa politica deve essere riesaminata dal Direttore generale (GM) almeno annualmente per garantire la conformità continua ai requisiti di certificazione ISO/IEC 27001, alle modifiche normative (quali GDPR, NIS2 e DORA) e all’evoluzione delle esigenze aziendali.”

Richiede inoltre registrazioni documentate delle modifiche:

“Tutti i riesami e le modifiche della politica devono essere formalmente documentati, indicando chiaramente la data, la natura delle revisioni e l’approvazione del GM.”

E preserva la tracciabilità storica:

“Una registrazione storica delle versioni della politica deve essere mantenuta in modo sicuro per dimostrare l’evoluzione della politica e la conformità durante gli audit.”

Queste tre clausole risolvono un problema comune nelle PMI. L’organizzazione può non avere un grande ufficio di governance, ma necessita comunque della prova di riesame, approvazione e cronologia delle versioni.

La Politica sui ruoli e sulle responsabilità di governance - PMI per PMI aggiunge il requisito di tracciabilità per le decisioni di governance:

“Tutte le decisioni di sicurezza significative, le eccezioni e le escalation devono essere registrate e tracciabili.”

Questa clausola è critica per le eccezioni alle politiche. Una deviazione temporanea dall’MFA, un riesame ritardato di un fornitore o una modifica di emergenza alla conservazione dei log non dovrebbero esistere solo nei thread e-mail. Devono essere collegati alla politica pertinente, al controllo, al titolare del rischio, alla decisione sul rischio residuo e alla data di scadenza.

Per la centralizzazione delle evidenze, la Politica di audit e monitoraggio della conformità - PMI afferma:

“Tutte le evidenze devono essere conservate in una cartella di audit centralizzata.”

Negli ambienti enterprise, la Politica per la sicurezza delle informazioni di Clarysec richiede che le politiche siano:

“Soggette a controllo delle versioni e documentate”

e:

“Comunicate a tutte le parti interessate attraverso canali di comunicazione ufficiali”

La Politica sui ruoli e sulle responsabilità di governance enterprise incorpora il concetto di:

“Titolare e approvatore della politica”

La Politica di audit e monitoraggio della conformità enterprise aggiunge aspettative di conservazione:

“I rapporti devono essere conservati per non meno di sei anni (o più a lungo ove legalmente richiesto), archiviati in modo sicuro e soggetti a controllo delle versioni ai sensi della Politica di gestione dei documenti e delle registrazioni (P6).”

Infine, la Politica di conformità legale e normativa enterprise collega gli obblighi legali al SGSI:

“Tutti gli obblighi legali e normativi devono essere mappati a politiche, controlli e titolari specifici all’interno del Sistema di gestione della sicurezza delle informazioni (SGSI).”

Questo requisito è il ponte tra governance del ciclo di vita delle politiche ed evidenze NIS2, DORA e GDPR. Senza mappatura degli obblighi, un’azienda può possedere documenti, ma non può dimostrare che tali documenti soddisfino specifici requisiti legali, contrattuali o di rischio.

Il triangolo dei controlli: politiche, registrazioni e procedure operative

La Zenith Controls: guida alla conformità trasversale di Clarysec fornisce la bussola di conformità trasversale per questo tema. Per il controllo 5.1 di ISO/IEC 27002:2022, Politiche per la sicurezza delle informazioni, Zenith Controls lo identifica come un controllo preventivo a supporto di Riservatezza, Integrità e Disponibilità, allineato ai concetti di governance e identificazione della cibersicurezza, e collegato alle capacità operative di governance e gestione delle politiche.

Questo è importante perché la governance delle politiche non è soltanto un artefatto di conformità. È preventiva. Una Politica di controllo degli accessi chiaramente attribuita e comunicata riduce il rischio di accesso non autorizzato prima che si verifichino incidenti. Una politica dei fornitori correttamente approvata previene il rischio di outsourcing non governato. Una procedura di gestione degli incidenti controllata migliora la coerenza della risposta prima che inizi il primo conto alla rovescia per la notifica regolatoria.

Zenith Controls evidenzia inoltre il controllo 5.33 di ISO/IEC 27002:2022, Protezione delle registrazioni, come preventivo e allineato a requisiti legali e di conformità, gestione degli asset e protezione delle informazioni. Questo è centrale per le evidenze di audit. Il Zenith Blueprint amplia lo stesso concetto nella fase Controlli in azione, Step 23:

“Le registrazioni non sono semplici reliquie di decisioni passate. Sono evidenze: di conformità, di azione, di accountability.”

E prosegue:

“Le registrazioni sono protette adeguatamente da perdita, Accesso non autorizzato, manomissione e distruzione prematura”

Anche il controllo 5.37 di ISO/IEC 27002:2022, Procedure operative documentate, è rilevante. Zenith Controls lo classifica come preventivo e correttivo, a supporto di protezione e ripristino. Per DORA e NIS2, le procedure operative documentate sono il modo in cui la politica diventa azione ripetibile: triage degli incidenti, ripristino dei backup, qualifica dei fornitori, trattamento delle vulnerabilità, sviluppo sicuro, gestione delle modifiche, raccolta delle evidenze e comunicazione di crisi.

Insieme, 5.1, 5.33 e 5.37 creano il triangolo dei controlli del ciclo di vita delle politiche:

Un SGSI maturo necessita di tutti e tre. Politiche senza registrazioni sono dichiarazioni. Registrazioni senza procedure sono incoerenti. Procedure senza indirizzo di policy diventano abitudini locali anziché controlli governati.

Mappatura di conformità trasversale per ISO 27001, NIS2, DORA, GDPR, NIST e COBIT

Gestire politiche separate per ISO 27001, NIS2, DORA e GDPR crea duplicazioni, contraddizioni e affaticamento nella gestione delle evidenze. Un modello migliore consiste nel mantenere una sola libreria SGSI controllata con metadati di mappatura. Questo consente a un unico corpus di evidenze di soddisfare più destinatari di assurance.

NIST CSF 2.0 è particolarmente utile come livello di comunicazione. La sua Funzione GOVERN richiede che gli obblighi legali, normativi e contrattuali siano compresi, che obiettivi e responsabilità di gestione del rischio siano definiti, che le politiche siano stabilite e aggiornate e che gli esiti siano valutati. Il metodo del Profilo organizzativo fornisce inoltre un processo pratico: definire l’ambito del profilo, raccogliere input quali politiche, priorità di rischio e requisiti, creare profili corrente e target, analizzare le lacune e attuare un piano d’azione prioritizzato.

Questo si allinea strettamente all’approccio di Clarysec: costruire un modello operativo basato su evidenze e poi mapparlo verso NIS2, DORA, GDPR, NIST e COBIT, anziché mantenere silos di conformità separati.

Uno sprint di una settimana per costruire un pacchetto di controllo delle evidenze delle politiche

Una trasformazione completa della governance delle politiche richiede tempo, ma uno sprint mirato di una settimana può esporre le lacune e creare una base difendibile.

Giorno 1: creare il registro dei documenti

Inizia con un foglio di calcolo, un sistema GRC o un elenco SharePoint strutturato. Il Registro dei documenti è l’indice che consente agli auditor di navigare nel corpus di evidenze.

Non complicarlo eccessivamente. Se il registro mostra in modo affidabile titolare, approvatore, versione, data di riesame, mappatura e ubicazione delle evidenze, risolve già molti problemi di reperimento in audit.

Giorno 2: istituire il repository

Segui la struttura dello Step 6 del Zenith Blueprint: Politiche e procedure, Valutazione del rischio e SoA, Registrazioni di formazione e sensibilizzazione, Audit e riesami, Registrazioni degli incidenti, Asset e inventario, e Libreria dei controlli.

Applica regole di accesso. Le politiche possono essere lette da tutti i dipendenti. Le registrazioni della valutazione del rischio devono essere limitate al gruppo SGSI e alla direzione. Le registrazioni degli incidenti devono seguire il principio della necessità di sapere. I contratti con i fornitori devono essere limitati ad acquisti, legale, finanza e sicurezza. I documenti obsoleti devono essere inaccessibili per l’uso quotidiano, ma conservati per la tracciabilità in audit.

Giorno 3: standardizzare intestazioni e registri delle modifiche

Ogni politica deve includere nome del documento, titolare, approvatore, versione, data di entrata in vigore, data del prossimo riesame, classificazione, controlli correlati, obblighi legali correlati e cronologia delle modifiche.

Questo supporta il controllo delle informazioni documentate ISO/IEC 27001:2022, la supervisione della direzione NIS2, le aspettative di riesame DORA e l’accountability GDPR.

Giorno 4: collegare le eccezioni alle politiche

Crea un Registro delle eccezioni con ID eccezione, politica interessata, controllo interessato, giustificazione aziendale, controlli compensativi, titolare del rischio, approvazione, data di scadenza e stato del riesame.

Ad esempio, un sistema legacy non può supportare l’MFA per 60 giorni. L’eccezione si collega alla Politica di controllo degli accessi, all’inventario degli asset, al Registro dei rischi e al Piano di rientro. Il titolare del rischio approva il rischio residuo e l’eccezione scade automaticamente salvo rinnovo. Questo attua il requisito di governance Clarysec per PMI secondo cui decisioni significative, eccezioni ed escalation devono essere registrate e tracciabili.

Giorno 5: costruire il pacchetto di evidenze di audit

Per ciascuna politica di livello superiore, crea una sottocartella di evidenze contenente la versione corrente approvata, la versione precedente e il registro delle modifiche, le evidenze di approvazione, le evidenze di comunicazione, la registrazione della formazione o della presa d’atto, la procedura correlata, la registrazione operativa correlata, le eccezioni, la registrazione dell’ultimo riesame, la data del prossimo riesame e la mappatura agli obblighi legali e ai controlli.

Per la risposta agli incidenti, includi registrazioni di esercitazioni tabletop, criteri di classificazione degli incidenti, liste di contatto, modelli di riesame post-incidente e registrazioni delle decisioni di notifica. Questo supporta la preparazione alla segnalazione per fasi di NIS2 Article 23, la classificazione degli incidenti DORA e l’accountability GDPR sulle violazioni.

Giorno 6: testare il reperimento

Chiedi a un auditor interno o a un responsabile della conformità di recuperare evidenze per tre domande:

1. Dimostrare che la Politica per la sicurezza delle informazioni è stata approvata, comunicata e riesaminata.
2. Dimostrare che gli obblighi di sicurezza dei fornitori sono mappati ai requisiti DORA e NIS2.
3. Dimostrare che le evidenze di accountability GDPR sono conservate e protette.

Se il reperimento richiede più di 30 minuti per domanda, il repository deve essere migliorato.

Giorno 7: presentare alla direzione

Sintetizza lo stato del ciclo di vita delle politiche nel riesame della direzione:

• Politiche correnti, scadute o in scadenza entro 90 giorni
• Eccezioni aperte e scadute
• Lacune nelle evidenze
• Aggiornamenti della mappatura normativa
• Risultanze dell’audit
• Azioni correttive
• Fabbisogno di risorse

Questo chiude il ciclo con le aspettative di leadership di ISO/IEC 27001:2022, l’accountability del consiglio di amministrazione NIS2 e la supervisione dell’organo di gestione DORA.

Come gli auditor esamineranno il ciclo di vita delle politiche

Auditor diversi osservano le stesse evidenze con lenti diverse.

Un auditor ISO/IEC 27001:2022 parte dal controllo delle informazioni documentate. Verificherà se i documenti richiesti esistono, se sono approvati prima dell’uso, se le versioni sono controllate, se i documenti sono disponibili dove necessario, se le registrazioni riservate sono protette e se i documenti obsoleti sono impediti dall’uso non intenzionale. Collegherà il ciclo di vita delle politiche a leadership, trattamento del rischio, controllo operativo, audit interno e riesame della direzione.

Un revisore focalizzato su DORA avrà un orientamento alla resilienza. Esaminerà se il quadro per la gestione del rischio ICT è ben documentato, approvato dalla direzione, riesaminato almeno annualmente ove applicabile, sottoposto ad audit regolari, migliorato sulla base delle lezioni apprese e collegato a segnalazione degli incidenti, test, rischio di terze parti, continuità e ripristino.

Un’autorità NIS2 vorrà vedere una catena ininterrotta di evidenze: dall’identificazione del rischio alle misure di gestione del rischio di cibersicurezza, dall’approvazione dell’organo di gestione all’attuazione e al monitoraggio. Qualsiasi interruzione in questa catena può apparire come una mancanza di dovuta diligenza.

Un auditor GDPR o un revisore privacy chiederà se le registrazioni di governance dei dati personali dimostrano accountability: finalità del trattamento, base giuridica, conservazione, misure tecniche e organizzative, controlli sui responsabili del trattamento, registrazioni delle violazioni ed evidenze del rispetto della politica.

Un auditor in stile COBIT 2019 o ISACA si concentrerà sui componenti del sistema di governance: processi, strutture organizzative, flussi informativi, politiche, ruoli, cultura, competenze e servizi. Chiederà se la titolarità è definita, se la direzione monitora le prestazioni, se le eccezioni sono oggetto di escalation e se le evidenze supportano l’operatività dei controlli e la supervisione della direzione.

Lo stesso repository controllato di evidenze può soddisfarli tutti, ma solo se i documenti sono mappati, correnti, protetti e tracciabili.

Errori comuni nel ciclo di vita delle politiche da correggere prima dell’arrivo dell’auditor

La maggior parte dei fallimenti nel ciclo di vita delle politiche deriva da debolezze di governance di base ripetute nei diversi ambienti:

• Le politiche esistono, ma non hanno un titolare nominato.
• Gli approvatori sono poco chiari, obsoleti o troppo junior rispetto al rischio.
• Le politiche sono approvate, ma non comunicate.
• Le date di riesame sono mancate senza escalation.
• Le versioni obsolete restano disponibili nelle cartelle condivise.
• Le procedure sono in conflitto con le politiche.
• Le eccezioni sono approvate informalmente via e-mail.
• Gli obblighi legali sono mappati ai framework, ma non ai controlli o ai titolari effettivi.
• Le evidenze di audit sono distribuite tra unità personali, strumenti di ticketing e messaggi chat.
• I periodi di conservazione sono indefiniti o applicati in modo incoerente.
• Le registrazioni sono conservate, ma non protette da alterazioni non autorizzate.
• Le politiche sui fornitori non sono collegate a registri dei contratti, due diligence o piani di uscita.
• Le procedure sugli incidenti non sono allineate ai punti decisionali di notifica NIS2, DORA o GDPR.

Questi problemi creano attrito in audit perché minano la fiducia. Se un auditor non può fidarsi del corpus delle politiche, approfondirà l’operatività dei controlli.

Il piano di rientro di Maria non consisteva nello scrivere un’altra politica. Consisteva nel creare un’unica fonte di verità. Ha designato una libreria ufficiale della documentazione SGSI, vi ha migrato le politiche correnti, ha archiviato le ubicazioni non controllate, ha standardizzato i campi titolare e approvatore, ha costruito flussi di approvazione, ha mappato le politiche agli obblighi NIS2 e DORA e ha concesso agli auditor un accesso in sola lettura a evidenze strutturate. Quello che era stato fonte di ansia è diventato una dimostrazione di controllo.

Il percorso Clarysec

La governance del ciclo di vita delle politiche non è burocrazia accessoria. È la disciplina operativa che rende difendibili le informazioni documentate ISO 27001, l’accountability della direzione NIS2, la governance del rischio ICT DORA e l’accountability GDPR.

Usa il Zenith Blueprint: roadmap in 30 passi per auditor per costruire la libreria SGSI nella fase e nella sequenza corrette, in particolare lo Step 6 per le informazioni documentate e lo Step 22 per la governance delle politiche. Usa le politiche Clarysec per PMI ed enterprise per definire requisiti di riesame, approvazione, controllo delle versioni, comunicazione, tracciabilità, centralizzazione delle evidenze e conservazione. Usa Zenith Controls: guida alla conformità trasversale per mappare i controlli ISO/IEC 27002:2022, come 5.1, 5.33 e 5.37, alle aspettative di conformità trasversale, agli attributi dei controlli e alle prospettive di audit.

Prima di acquistare un altro strumento o scrivere un’altra politica, rispondi a una domanda:

Puoi dimostrare che ogni politica importante ha un titolare, è approvata, corrente, comunicata, mappata, supportata da evidenze, riesaminata, protetta e dismessa correttamente?

Se la risposta è non ancora, Clarysec può aiutarti a costruire la libreria SGSI pronta per le evidenze, il flusso del ciclo di vita delle politiche e la mappatura di conformità trasversale che auditor, consigli di amministrazione e clienti si aspettano nel 2026. Scarica il Zenith Blueprint, esplora i pacchetti di politiche Clarysec per PMI ed enterprise, oppure prenota una valutazione di preparazione per trasformare la tua libreria di politiche in un asset di conformità difendibile.