Valutazione del rischio ISO 27001 pronta per l'audit per NIS2 e DORA

Il caffè sulla scrivania di Sarah era ormai freddo.

In qualità di Responsabile della sicurezza delle informazioni di una fintech in rapida crescita, era abituata alla pressione. L’azienda aveva appena acquisito un importante partner bancario e il questionario di due diligence aperto sullo schermo avrebbe dovuto essere una formalità. Le prime domande erano familiari: fornire la Dichiarazione di Applicabilità ISO/IEC 27001:2022, condividere l’ultimo registro dei rischi, spiegare la metodologia di valutazione del rischio.

Poi il questionario cambiò direzione.

Dimostrare in che modo il programma di gestione del rischio affronta DORA. Spiegare la preparazione rispetto a NIS2, incluse la responsabilità della direzione e le misure relative al rischio della catena di fornitura. Fornire evidenze che i fornitori ICT critici siano valutati, monitorati e coperti da piani di risposta agli incidenti e di continuità operativa.

Entro lunedì mattina, lo stesso tema era all’ordine del giorno del comitato rischi del consiglio di amministrazione. Audit di certificazione ISO 27001 tra otto settimane. Pressione DORA da parte dei clienti del settore finanziario. Domande di classificazione NIS2 per una linea di servizi ospitati in cloud in espansione nell’UE. La funzione Acquisti affermava che i riesami dei fornitori esistevano, ma le evidenze erano distribuite tra e-mail, cartelle contrattuali e un foglio di calcolo dei fornitori. La funzione Legale diceva che la mappatura normativa era ancora in corso. Il team Ingegneria diceva che il registro dei rischi era quasi completo.

Il consiglio di amministrazione fece l’unica domanda che contava:

Possiamo dimostrare che la nostra valutazione del rischio e il nostro piano di trattamento del rischio sono adeguati?

Questo è il vero problema per le aziende SaaS, fintech, di servizi gestiti, cloud e piattaforme digitali. Non se esista un registro dei rischi. Non se i controlli dell’Allegato A siano stati copiati in un foglio di calcolo. Il punto è se l’organizzazione possa dimostrare, sotto la pressione di audit e clienti, che il proprio processo di valutazione del rischio ISO 27001 è ripetibile, basato sul rischio, approvato dai titolari del rischio, collegato alle azioni di trattamento, mappato agli obblighi legali e realmente operativo.

Se eseguiti correttamente, una valutazione del rischio ISO 27001 e un piano di trattamento del rischio possono supportare la certificazione ISO/IEC 27001:2022, le misure di gestione del rischio di cibersicurezza di NIS2 Article 21, i requisiti DORA di gestione del rischio ICT, la responsabilizzazione prevista dal GDPR, l’assurance dei fornitori, la preparazione alla gestione degli incidenti e la reportistica al consiglio di amministrazione.

Se eseguiti male, diventano un foglio di calcolo che gli auditor smonteranno in trenta minuti.

Questa guida mostra come Clarysec costruisce evidenze di valutazione e trattamento del rischio ISO 27001 pronte per l’audit utilizzando Zenith Blueprint: la roadmap in 30 passi per gli audit, le politiche Clarysec e Zenith Controls: la guida alla conformità trasversale.

Perché la valutazione del rischio ISO 27001 è ora un hub di conformità

Il panorama normativo dell’UE sta convergendo attorno a un principio semplice: il rischio di cibersicurezza deve essere governato, documentato, testato e assegnato a un responsabile.

ISO/IEC 27001:2022 funziona già in questo modo. Le clausole 4.1-4.4 richiedono all’organizzazione di comprendere il proprio contesto, le parti interessate, il campo di applicazione del SGSI e le interazioni tra processi prima di valutare il rischio. Le clausole 6.1.2 e 6.1.3 richiedono un processo definito di valutazione e trattamento del rischio per la sicurezza delle informazioni. Le clausole 8.2 e 8.3 richiedono all’organizzazione di eseguire valutazioni del rischio e attuare il piano di trattamento, conservando informazioni documentate.

NIS2 e DORA rendono più urgente la stessa logica basata sul rischio.

NIS2 Article 20 richiede agli organi di gestione dei soggetti essenziali e importanti di approvare le misure di gestione del rischio di cibersicurezza, sovrintenderne l’attuazione e seguire la formazione in materia di cibersicurezza. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi per le reti e i sistemi informativi. Tali misure includono analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, gestione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset e autenticazione a più fattori o comunicazioni sicure, ove opportuno.

DORA esercita una pressione analoga sugli enti finanziari. Articles 5 e 6 richiedono all’organo di gestione di definire, approvare, sovrintendere e rimanere responsabile degli assetti di gestione del rischio ICT. DORA richiede un quadro documentato di gestione del rischio ICT integrato nella gestione complessiva del rischio, supportato da politiche, procedure, protocolli, strumenti, audit interno, azioni correttive, continuità operativa, test, gestione degli incidenti e governance delle terze parti ICT.

La conclusione è pratica e inevitabile: il registro dei rischi non è più un foglio di lavoro del team tecnico. È un’evidenza di governance.

La Politica di gestione del rischio Enterprise di Clarysec rende esplicita questa aspettativa:

Deve essere mantenuto un processo formale di gestione del rischio in conformità a ISO/IEC 27005 e ISO 31000, che copra identificazione, analisi, valutazione, trattamento, monitoraggio e comunicazione del rischio.

Dalla Politica di gestione del rischio Enterprise, sezione “Requisiti di governance”, clausola di politica 5.1.

La stessa politica definisce il risultato atteso pronto per l’audit:

Mantenere un Registro dei rischi e un Piano di trattamento del rischio centralizzati e soggetti a controllo delle versioni, che riflettano lo stato attuale del rischio, la copertura dei controlli e l’avanzamento della mitigazione.

Dalla Politica di gestione del rischio Enterprise, sezione “Obiettivi”, clausola di politica 3.3.

Quell’espressione, “stato attuale del rischio, copertura dei controlli e avanzamento della mitigazione”, è la differenza tra un fascicolo statico di conformità e un programma di rischio difendibile.

Parti da ambito, obblighi e criteri di rischio

Molte valutazioni del rischio ISO 27001 deboli iniziano da una checklist di controlli. È l’approccio opposto a quello corretto.

ISO 27001 richiede all’organizzazione di determinare contesto, requisiti delle parti interessate, campo di applicazione del SGSI, responsabilità della leadership e pianificazione del rischio prima di selezionare i controlli. ISO/IEC 27005:2022 rafforza questo punto raccomandando alle organizzazioni di identificare i requisiti di base delle parti interessate prima di valutare il rischio. Tali requisiti possono derivare da standard ISO, normative settoriali, leggi nazionali, contratti con i clienti, politiche interne, precedenti attività di trattamento e obblighi dei fornitori.

Per una società SaaS o fintech che opera verso l’UE, il processo di rischio dovrebbe iniziare con un inventario degli obblighi e della conformità.

Per le PMI, la Politica di conformità legale e normativa - SME di Clarysec definisce il punto di partenza:

Il GM deve mantenere un Registro di conformità semplice e strutturato che elenchi:

Dalla Politica di conformità legale e normativa SME, sezione “Requisiti di governance”, clausola di politica 5.1.1.

Quel semplice registro è un ponte tra conformità e gestione del rischio. Se indica che il GDPR si applica perché sono trattati dati personali dell’UE, che NIS2 può applicarsi perché l’organizzazione fornisce servizi digitali o gestiti, o che DORA è rilevante tramite clienti del settore finanziario, tali obblighi devono influenzare i criteri di rischio e le priorità di trattamento.

Il Zenith Blueprint è diretto su questo punto nella fase di gestione del rischio, passo 10, “Definizione dei criteri di rischio e della matrice di impatto”:

Considera anche i requisiti legali/regolamentari nei tuoi criteri di accettazione. Alcuni rischi potrebbero essere inaccettabili indipendentemente dalla probabilità a causa della legge.

Da Zenith Blueprint, fase di gestione del rischio, passo 10.

Fornisce anche una regola pratica per i workshop:

“Qualsiasi rischio che possa comportare una non conformità alle leggi applicabili (GDPR, ecc.) non è accettabile e deve essere mitigato.”

Da Zenith Blueprint, fase di gestione del rischio, passo 10.

Per la fintech di Sarah, questo cambia il modello di scoring. Una vulnerabilità dell’API di un fornitore può avere bassa probabilità, ma se il suo sfruttamento potesse generare un grave incidente ICT connesso a DORA, un incidente significativo NIS2, una valutazione di violazione GDPR, un mancato rispetto degli SLA del cliente o un’escalation al consiglio di amministrazione, l’impatto è elevato o critico. L’esposizione alla conformità diventa parte della logica di rischio, non un foglio di calcolo separato.

Costruire un registro dei rischi che gli auditor possano testare

Gli auditor non chiedono soltanto quali siano i principali rischi. Verificano se il metodo sia definito, ripetibile, tracciabile e seguito.

Chiederanno:

• Come avete identificato questi rischi?
• Quali asset, servizi, fornitori, tipi di dati e processi erano nel campo di applicazione?
• Quali criteri sono stati usati per probabilità e impatto?
• Chi è titolare di ciascun rischio?
• Quali controlli esistenti riducono il rischio?
• Perché è stata selezionata quella decisione di trattamento?
• Dove si trova l’evidenza che il trattamento è stato eseguito?
• Chi ha approvato il rischio residuo?
• Quando sarà rivalutato il rischio?

La Politica di gestione del rischio - SME di Clarysec definisce la voce minima di rischio pronta per l’audit:

Ogni voce di rischio deve includere: descrizione, probabilità, impatto, punteggio, proprietario e piano di trattamento del rischio.

Dalla Politica di gestione del rischio SME, sezione “Requisiti di governance”, clausola di politica 5.1.2.

Per i programmi enterprise, la fase di gestione del rischio del Zenith Blueprint, passo 11, “Costruzione e documentazione del Registro dei rischi”, amplia la struttura. Raccomanda colonne quali ID del rischio, asset, minaccia, vulnerabilità, descrizione del rischio, probabilità, impatto, livello di rischio, controlli attuali, titolare del rischio, decisione di trattamento, piano di trattamento del rischio o controlli e stato.

Una voce di rischio robusta si presenta così:

Questo è materialmente diverso da “Rischio di terze parti, Alto, mitigare”. La versione pronta per l’audit collega asset, minaccia, vulnerabilità, conseguenza, controlli attuali, titolare, regolamentazione, evidenze e governance.

Trasformare il trattamento del rischio in un piano di evidenze

Un piano di trattamento del rischio deve rispondere a quattro domande operative:

1. Che cosa faremo?
2. Chi ne è responsabile?
3. Entro quando sarà completato?
4. Come dimostreremo che ha ridotto il rischio?

La clausola 6.1.3 di ISO/IEC 27001:2022 richiede all’organizzazione di selezionare le opzioni di trattamento, determinare i controlli necessari, confrontarli con l’Allegato A per evitare omissioni, produrre una Dichiarazione di Applicabilità, formulare un piano di trattamento e ottenere l’approvazione dei titolari del rischio per il piano e per i rischi residui. La clausola 8.3 richiede poi l’attuazione del piano di trattamento e la conservazione di informazioni documentate sui risultati.

La Politica di gestione del rischio Enterprise rende questo aspetto operativo:

Il Responsabile del rischio deve assicurare che i trattamenti siano realistici, vincolati nel tempo e mappati ai controlli dell’Annex A ISO/IEC 27001.

Dalla Politica di gestione del rischio Enterprise, sezione “Requisiti di applicazione della politica”, clausola di politica 6.4.2.

La politica SME chiarisce inoltre che l’accettazione non è una scorciatoia:

Accettare: giustificare perché non sono richieste ulteriori azioni e registrare il rischio residuo.

Dalla Politica di gestione del rischio SME, sezione “Requisiti di applicazione della politica”, clausola di politica 6.1.1.

L’accettazione deve essere giustificata rispetto ai criteri, approvata dal titolare corretto e monitorata. Ai sensi di NIS2 e DORA, un rischio residuo non approvato può diventare una carenza di governance.

Un piano di trattamento completo dovrebbe contenere questi campi:

Per il rischio R-042 di Sarah, il piano di trattamento diventa un elenco di azioni di conformità trasversale.

Questo piano è efficace perché crea una linea diretta da uno scenario di rischio ai controlli ISO 27001, agli obblighi NIS2, agli articoli DORA, ai responsabili e alle evidenze.

Far lavorare di più la Dichiarazione di Applicabilità

La Dichiarazione di Applicabilità è spesso trattata come un artefatto di certificazione. Dovrebbe essere più di questo.

La clausola 6.1.3 di ISO/IEC 27001:2022 richiede che la SoA includa i controlli necessari, la giustificazione dell’inclusione, lo stato di attuazione e la giustificazione delle esclusioni. Le linee guida ISO/IEC 27005:2022 rafforzano la necessità di confrontare i controlli selezionati con l’Allegato A ISO/IEC 27001 per evitare omissioni.

In un programma pronto per l’audit, la SoA diventa il ponte tra trattamento del rischio ed evidenze di conformità trasversale. Se un piano di trattamento richiede MFA, logging, monitoraggio dei fornitori, ripristino dei backup, sviluppo sicuro, escalation degli incidenti o pianificazione dell’uscita dal cloud, la SoA dovrebbe mostrare che i controlli dell’Allegato A pertinenti sono inclusi, giustificati, attuati o pianificati e supportati da evidenze.

Questo aiuta anche a evitare una comune carenza di audit: il registro dei rischi dice una cosa, il piano di trattamento ne dice un’altra e la SoA tace. Quando questi documenti non sono allineati, gli auditor perdono rapidamente fiducia.

Mappare il trattamento del rischio ISO 27001 su NIS2, DORA e GDPR

ISO 27001 non sostituisce NIS2, DORA o GDPR. Fornisce un meccanismo strutturato per produrre evidenze a loro supporto.

La chiave è integrare la mappatura nel processo di rischio, invece di aggiungerla successivamente.

Questa mappatura è particolarmente importante dove le normative si sovrappongono. DORA è il regime settoriale di resilienza ICT per molti enti finanziari, mentre NIS2 può rimanere direttamente rilevante per determinati fornitori, coordinamenti o soggetti fuori dal campo di applicazione di DORA. Una fintech può avere bisogno di DORA come principale quadro di riferimento per la resilienza ICT, mentre un fornitore di servizi gestiti che supporta quella fintech può essere soggetto direttamente a obblighi NIS2.

Il registro dei rischi deve poter mostrare entrambi i lati di questa dipendenza.

Usare Zenith Controls come bussola della conformità trasversale

Clarysec utilizza Zenith Controls come guida di conformità trasversale per evitare la criticità ricorrente in cui controlli ISO, articoli normativi e domande di audit vivono in universi separati. Non crea un quadro di controlli separato. Mappa le aree di controllo ISO/IEC 27001:2022 e ISO/IEC 27002:2022 ad altri standard, aspettative di audit e prospettive di conformità.

Per la valutazione e il trattamento del rischio ISO 27001, questi riferimenti sono particolarmente importanti:

La lezione di conformità trasversale è semplice. Se gli obblighi legali non sono nel metodo di valutazione del rischio, il punteggio è incompleto. Se il punteggio è incompleto, le priorità di trattamento possono essere errate. Se le priorità sono errate, la SoA e la reportistica al consiglio di amministrazione diventano inaffidabili.

Il Zenith Blueprint afferma lo stesso concetto nella fase di gestione del rischio, passo 14, “Politiche di trattamento del rischio e riferimenti normativi incrociati”. Raccomanda alle organizzazioni di creare una tabella di mappatura che elenchi i principali requisiti normativi di sicurezza e i corrispondenti controlli o politiche nel SGSI. Non è obbligatoria per la certificazione ISO 27001, ma è molto utile per dimostrare che la sicurezza viene gestita nel contesto legale e contrattuale.

Che cosa chiederanno auditor diversi

Un auditor di certificazione, un revisore orientato a NIS2, un cliente orientato a DORA, un revisore GDPR, un valutatore NIST o un professionista COBIT possono esaminare le stesse evidenze ma porre domande diverse.

Per questo l’architettura delle evidenze è importante. La stessa voce di rischio dovrebbe essere tracciabile dall’obiettivo aziendale ad asset, minaccia, vulnerabilità, controllo, titolare, driver normativo, azione di trattamento, risultato del test e decisione della direzione.

Le politiche Clarysec sono progettate per supportare questa architettura. La Politica di gestione del rischio Enterprise afferma nella sezione “Standard e quadri di riferimento”:

Article 5: richiede un quadro documentato di gestione del rischio ICT, completamente coperto dalla struttura di questa politica, inclusa la mappatura SoA e i KRI.

Questo trasforma la politica da documento statico a evidenza di audit che dimostra che la governance del rischio ICT è stata progettata intenzionalmente tenendo presente DORA.

Risultanze comuni che rompono i programmi di rischio

Quando Clarysec riesamina le evidenze di valutazione e trattamento del rischio ISO 27001, ricorrono sempre le stesse risultanze.

Primo, i criteri di rischio ignorano l’impatto legale, regolamentare, contrattuale, dei fornitori e privacy. Questo produce punteggi deboli. Una violazione dei dati personali o un fallimento di un fornitore critico può essere valutato Medio perché la probabilità è bassa, anche se l’impatto su GDPR, NIS2, DORA o cliente dovrebbe renderlo Alto o Critico.

Secondo, i titolari dei rischi sono generici. “IT” non è un titolare del rischio. Un titolare del rischio dovrebbe essere un ruolo o una persona responsabile delle decisioni di trattamento, del budget, delle tempistiche e del rischio residuo.

Terzo, i piani di trattamento non sono vincolati nel tempo. “Migliorare il monitoraggio” non è un piano. “Distribuire allerte sulle sessioni privilegiate nel SIEM per gli account amministrativi di produzione entro il 30 giugno, con titolarità del SOC Manager, testate tramite accesso amministrativo simulato, con evidenza dell’allerta allegata” è un piano.

Quarto, la SoA è scollegata dal trattamento. Se il piano di trattamento richiede monitoraggio dei fornitori, test dei backup, escalation degli incidenti, MFA o logging, la SoA dovrebbe riflettere i controlli pertinenti e lo stato di attuazione.

Quinto, il rischio residuo non è approvato. ISO 27001 richiede l’approvazione del titolare del rischio per il piano di trattamento e per i rischi residui. NIS2 e DORA rendono questo aspetto ancora più importante perché la responsabilità della direzione è esplicita.

Sesto, il rischio dei fornitori è trattato come amministrazione degli acquisti. Ai sensi di NIS2 Article 21(2)(d) e DORA Articles 28 e 30, il rischio dei fornitori e delle terze parti ICT deve far parte della gestione del rischio, non essere un questionario annuale archiviato in isolamento.

Settimo, non esiste evidenza di efficacia. La clausola 6.1.1 di ISO 27001 richiede che le azioni pianificate siano valutate per efficacia. NIS2 include la valutazione dell’efficacia in Article 21(2)(f). DORA richiede test e azioni correttive. Un controllo che esiste ma non viene mai testato è un’evidenza debole.

La Politica di gestione del rischio - SME definisce chiaramente l’aspettativa:

Il Direttore generale e il Coordinatore del rischio devono assicurare che le attività di gestione del rischio siano pronte per l’audit. Il Registro dei rischi e le azioni correlate sono soggetti ad audit interno ed esterno.

Dalla Politica di gestione del rischio SME, sezione “Applicazione e conformità”, clausola di politica 8.2.1.

Reportistica al consiglio di amministrazione senza sommergere i dirigenti

NIS2, DORA e ISO 27001 puntano tutte alla responsabilità della direzione, ma i consigli di amministrazione non hanno bisogno di ogni riga del registro dei rischi. Hanno bisogno di report utili alle decisioni.

Un buon pacchetto rischi per il consiglio di amministrazione dovrebbe mostrare:

• Rischi alti e critici per dominio
• Azioni di trattamento in ritardo
• Rischi normativi che coinvolgono NIS2, DORA, GDPR o contratti
• Rischi dei fornitori che impattano servizi critici o importanti
• Tendenze degli incidenti e dei quasi incidenti
• Rischi residui in attesa di accettazione
• Risultati dei test di efficacia dei controlli
• Cambiamenti significativi di ambito, fornitori, tecnologia o normativa
• Risultanze dell’audit interno e azioni correttive

Clarysec raccomanda generalmente riesami operativi del rischio mensili e riesami della direzione trimestrali. I riesami mensili si concentrano sull’esecuzione del trattamento. I riesami trimestrali si concentrano su accettazione, finanziamento, prioritizzazione, esposizione normativa e decisioni strategiche di rischio.

Questo ritmo supporta anche il miglioramento continuo. Le valutazioni del rischio dovrebbero essere aggiornate quando si verificano incidenti, emergono vulnerabilità, vengono introdotti nuovi asset, cambia la tecnologia, cambiano i fornitori, cambiano le leggi, cambiano gli obblighi verso i clienti o cambia la propensione al rischio.

Il percorso di applicazione Clarysec

Un programma di rischio unificato evita fogli di calcolo scollegati per ISO, NIS2, DORA, GDPR e assurance dei clienti. Il percorso pratico è:

1. Confermare campo di applicazione del SGSI, servizi, asset, fornitori, giurisdizioni e obblighi verso i clienti.
2. Creare o aggiornare il Registro di conformità utilizzando la Politica di conformità legale e normativa - SME, ove opportuno.
3. Definire metodologia di rischio, criteri di accettazione, scale di probabilità, scale di impatto e regole di impatto regolamentare.
4. Creare il registro dei rischi utilizzando la fase di gestione del rischio del Zenith Blueprint e l’approccio Risk Register and SoA Builder di Clarysec.
5. Identificare rischi basati sugli asset e basati su scenari, inclusi scenari relativi a fornitori, cloud, privacy, continuità operativa, incidenti, vulnerabilità, sviluppo sicuro e accessi.
6. Assegnare punteggi ai rischi utilizzando criteri che includono impatto legale, regolamentare, contrattuale, operativo, privacy, dei fornitori e finanziario.
7. Selezionare le opzioni di trattamento: mitigare, evitare, trasferire o accettare.
8. Mappare i controlli necessari all’Allegato A ISO/IEC 27001:2022 e alle linee guida ISO/IEC 27002:2022.
9. Creare o aggiornare la Dichiarazione di Applicabilità.
10. Mappare i trattamenti a NIS2 Article 21, alla gestione del rischio ICT DORA e alle aspettative sulle terze parti, alla responsabilizzazione GDPR e agli obblighi contrattuali dei clienti.
11. Raccogliere evidenze, validare l’efficacia dei controlli e ottenere l’approvazione del rischio residuo.
12. Preparare un pacchetto di audit organizzato per rischio, controllo, regolamentazione ed evidenza.
13. Alimentare i risultati in riesame della direzione, audit interno, azione correttiva e miglioramento continuo.

Non è documentazione fine a se stessa. È il sistema operativo di una cyber governance difendibile.

Costruire un pacchetto di trattamento del rischio pronto per l’audit

La storia di Sarah finisce bene perché ha smesso di trattare ISO 27001, NIS2 e DORA come progetti di conformità separati. Ha usato la valutazione del rischio ISO 27001 come motore centrale, ha integrato gli obblighi normativi nei criteri di rischio, ha mappato le azioni di trattamento all’Allegato A e ai requisiti UE e ha raccolto evidenze comprensibili per clienti, auditor e consiglio di amministrazione.

La tua organizzazione può fare lo stesso.

Usa Zenith Blueprint: la roadmap in 30 passi per gli audit per definire i criteri di rischio, costruire il registro dei rischi, creare il piano di trattamento del rischio e incrociare i requisiti normativi.

Usa Zenith Controls: la guida alla conformità trasversale per collegare le aree di controllo dell’Allegato A ISO/IEC 27001:2022 con prospettive di governance, conformità legale, assurance e audit.

Usa la Politica di gestione del rischio, la Politica di gestione del rischio - SME e la Politica di conformità legale e normativa - SME di Clarysec per standardizzare titolarità, registri, decisioni di trattamento ed evidenze pronte per l’audit.

Il prossimo passo pratico più rapido è prendere i dieci rischi principali e testarli rispetto a cinque domande:

1. L’impatto regolamentare è visibile?
2. Il piano di trattamento è vincolato nel tempo e assegnato a un titolare?
3. Ogni trattamento è mappato all’Allegato A e alla SoA?
4. La rilevanza per NIS2, DORA, GDPR o cliente è documentata ove applicabile?
5. Esiste evidenza che il controllo funzioni?

Se la risposta è no, Clarysec può aiutare a trasformare il tuo registro dei rischi in un programma di trattamento del rischio difendibile e orientato alla conformità trasversale, su cui auditor, autorità di regolamentazione, clienti e consigli di amministrazione possano fare affidamento.