SoA ISO 27001 per la preparazione a NIS2 e DORA

Sono le 08:30 di un lunedì mattina ed Elena, Responsabile della sicurezza delle informazioni di un fornitore SaaS FinTech B2B in forte crescita, apre una richiesta urgente del Consiglio di amministrazione. L’azienda ha appena ottenuto la certificazione ISO/IEC 27001:2022, ma un importante potenziale cliente bancario dell’UE sta ponendo domande più stringenti del consueto questionario di sicurezza.

Non chiede soltanto se l’azienda cifra i dati, utilizza l’autenticazione a più fattori (MFA) o dispone di un rapporto di penetration test. Vuole sapere se la piattaforma SaaS supporta i suoi obblighi DORA, se il fornitore potrebbe rientrare nel campo di applicazione di NIS2 come servizio ICT o dipendenza di infrastruttura digitale, e se la Dichiarazione di Applicabilità ISO 27001 può motivare ogni controllo incluso, ogni controllo escluso e ogni evidenza.

Il Consiglio di amministrazione pone la domanda che ogni Responsabile della sicurezza delle informazioni, Compliance Manager e fondatore SaaS sente sempre più spesso:

La nostra SoA ISO 27001 può dimostrare la preparazione a NIS2 e DORA?

Elena sa che la risposta sbagliata sarebbe avviare tre programmi di conformità separati: uno per ISO 27001, uno per NIS2 e uno per DORA. Questo creerebbe evidenze duplicate, responsabili dei controlli in conflitto e una rincorsa continua prima di ogni valutazione da parte dei clienti. La risposta migliore è utilizzare il SGSI esistente come sistema operativo della conformità, con la Dichiarazione di Applicabilità, o SoA, come documento master di tracciabilità.

La SoA non è solo un foglio di calcolo per la certificazione ISO. In un contesto europeo di cibersicurezza e resilienza operativa, è il punto in cui un’organizzazione dimostra perché i controlli esistono, perché le esclusioni sono sostenibili, chi è responsabile di ciascun controllo, quali evidenze supportano l’attuazione e in che modo l’insieme dei controlli affronta NIS2, DORA, GDPR, i contratti con i clienti e il trattamento del rischio interno.

La Politica per la sicurezza delle informazioni per le imprese di Clarysec Politica per la sicurezza delle informazioni stabilisce:

Il SGSI deve includere confini del campo di applicazione definiti, una metodologia di valutazione del rischio, obiettivi misurabili e controlli documentati motivati nella Dichiarazione di Applicabilità (SoA).

Questo requisito, previsto dalla clausola 6.1.2 della Politica per la sicurezza delle informazioni, costituisce la base di un approccio pronto per l’audit. La SoA dovrebbe diventare il ponte tra obblighi, rischi, controlli, evidenze e decisioni della direzione.

Perché NIS2 e DORA hanno cambiato il significato di “applicabile”

Una SoA ISO/IEC 27001:2022 tradizionale spesso parte da una domanda semplice: “Quali controlli dell’Allegato A si applicano al nostro Piano di trattamento del rischio?” È ancora corretto, ma non è più sufficiente per fornitori SaaS, cloud, servizi gestiti, fintech, tecnologie finanziarie e fornitori critici della catena di fornitura.

NIS2 innalza il livello di riferimento per la gestione del rischio di cibersicurezza delle entità essenziali e importanti nell’UE. Copre settori come infrastruttura digitale, fornitori di servizi cloud, fornitori di servizi di data centre, reti di distribuzione dei contenuti, fornitori di servizi gestiti, fornitori di servizi di sicurezza gestiti, banche e infrastrutture dei mercati finanziari. Gli Stati membri devono identificare le entità essenziali e importanti e i fornitori di servizi di registrazione dei nomi di dominio; molti fornitori tecnologici che in passato consideravano la regolamentazione in materia di cibersicurezza come un tema dei clienti oggi rientrano direttamente nel campo di applicazione oppure sono esposti tramite requisiti contrattuali a cascata.

NIS2 Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate in materia di analisi dei rischi, politiche di sicurezza, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e sviluppo sicuri, valutazione dell’efficacia dei controlli, igiene informatica, formazione, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset e autenticazione, ove appropriato. NIS2 Article 23 aggiunge aspettative di segnalazione degli incidenti significativi articolate per fasi, inclusi preallarme, notifica, aggiornamenti e rapporto finale.

DORA, il Digital Operational Resilience Act, si applica dal 17 gennaio 2025 e si concentra sulle entità finanziarie e sul loro ecosistema di rischio ICT. Copre la gestione del rischio ICT, la segnalazione degli incidenti connessi all’ICT, la segnalazione degli incidenti operativi o di sicurezza relativi ai pagamenti per determinate entità, i test di resilienza operativa digitale, la condivisione di informazioni sulle minacce informatiche, la gestione del rischio ICT di terze parti, gli accordi contrattuali e la vigilanza sui fornitori terzi critici di servizi ICT.

Per le entità finanziarie che sono anche entità essenziali o importanti ai sensi di NIS2, DORA opera come regime settoriale specifico per obblighi equivalenti di gestione del rischio ICT e di segnalazione degli incidenti. Tuttavia, per fornitori SaaS, fornitori cloud, MSP e fornitori MDR che servono clienti finanziari, la realtà operativa è che le aspettative DORA arrivano attraverso approvvigionamento, contratti, diritto di audit, obblighi di supporto agli incidenti, pianificazione dell’uscita, trasparenza sui subappaltatori ed evidenze di resilienza.

Questo cambia la conversazione sulla SoA. La domanda non è più: “L’Allegato A contiene questo controllo?” La domanda migliore è:

Possiamo dimostrare che la selezione dei controlli è basata sul rischio, tiene conto degli obblighi, è proporzionata, ha responsabili definiti, è attuata, monitorata, supportata da evidenze e approvata?

ISO 27001 è il traduttore universale per NIS2 e DORA

ISO/IEC 27001:2022 è preziosa perché è uno standard di sistema di gestione, non una checklist ristretta. Richiede che il SGSI sia integrato nei processi dell’organizzazione e dimensionato sulle sue esigenze. Questo la rende un efficace traduttore universale per richieste di conformità sovrapposte.

Le clausole da 4.1 a 4.4 richiedono all’organizzazione di comprendere il proprio contesto, identificare le parti interessate, determinare i requisiti pertinenti e definire il campo di applicazione del SGSI. Per un fornitore SaaS FinTech come l’azienda di Elena, tali requisiti delle parti interessate possono includere clienti UE, clienti finanziari interessati da DORA, esposizione settoriale a NIS2, obblighi GDPR di titolare e responsabile del trattamento, dipendenze cloud esternalizzate, interfacce con fornitori e aspettative del Consiglio di amministrazione.

Le clausole da 6.1.1 a 6.1.3 richiedono la pianificazione per rischi e opportunità, un processo ripetibile di valutazione del rischio per la sicurezza delle informazioni, un processo di trattamento del rischio, il confronto con l’Allegato A e una Dichiarazione di Applicabilità che identifichi i controlli inclusi, lo stato di attuazione e le giustificazioni delle esclusioni.

È qui che la SoA diventa una registrazione delle decisioni sui controlli. Un controllo può essere incluso perché tratta un rischio, soddisfa un requisito legale, adempie a un contratto con un cliente, supporta un obiettivo aziendale o rappresenta un requisito minimo di igiene della sicurezza. Un controllo può essere escluso solo dopo che l’organizzazione lo ha valutato consapevolmente, lo ha ritenuto non pertinente al campo di applicazione del SGSI, ne ha documentato la motivazione e ha ottenuto l’approvazione appropriata.

La Politica di gestione del rischio per le imprese di Clarysec Politica di gestione del rischio stabilisce:

Una Dichiarazione di Applicabilità (SoA) deve riflettere tutte le decisioni di trattamento e deve essere aggiornata ogni volta che la copertura dei controlli viene modificata.

Questo requisito, previsto dalla clausola 5.4 della Politica di gestione del rischio, è critico per la preparazione a NIS2 e DORA. Un nuovo cliente regolamentato, una nuova dipendenza cloud, un nuovo obbligo di segnalazione degli incidenti o un nuovo rischio di concentrazione dei fornitori possono tutti modificare l’applicabilità dei controlli.

Parti dal Registro di conformità, non dall’elenco dei controlli

Una SoA debole parte dall’Allegato A e chiede: “Quali controlli abbiamo già?” Una SoA solida parte dalla realtà operativa dell’organizzazione e chiede: “Quali obblighi, servizi, rischi, dati, fornitori e clienti deve coprire il SGSI?”

ISO/IEC 27005:2022 supporta questo approccio enfatizzando i requisiti delle parti interessate, i criteri di rischio e la necessità di considerare standard, regole interne, leggi, regolamenti, contratti e controlli esistenti. Sottolinea inoltre che la non applicabilità o la non conformità dovrebbero essere spiegate e giustificate.

La Politica di conformità legale e normativa per PMI di Clarysec Politica di conformità legale e normativa per PMI recepisce lo stesso principio operativo:

Il Direttore generale (GM) deve mantenere un Registro di conformità semplice e strutturato che elenchi:

Questo requisito deriva dalla clausola 5.1.1 della Politica di conformità legale e normativa per PMI. Per un’organizzazione più piccola, il registro può essere semplice. Per un’impresa, dovrebbe essere più dettagliato. La logica è la stessa: gli obblighi devono essere visibili prima di poter essere mappati.

La Politica di conformità legale e normativa per le imprese di Clarysec Politica di conformità legale e normativa è esplicita:

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

Questa è la clausola 6.2.1 della Politica di conformità legale e normativa. È la struttura portante di governance per utilizzare una Dichiarazione di Applicabilità ISO 27001 ai fini della preparazione alla conformità a NIS2 e DORA.

Definisci criteri di rischio che riflettano resilienza, privacy, fornitori e regolamentazione

Molte giustificazioni della SoA falliscono perché il modello di scoring del rischio è troppo ristretto. Misura probabilità e impatto tecnici, ma non considera esposizione normativa, criticità del servizio, danno ai clienti, dipendenza dai fornitori, impatto privacy o interruzione operativa sistemica.

NIS2 non riguarda solo la riservatezza. Si concentra sulla prevenzione e sulla minimizzazione dell’impatto degli incidenti sui servizi e sui destinatari dei servizi. DORA definisce le funzioni critiche o importanti in base al fatto che un’interruzione possa compromettere in modo sostanziale la performance finanziaria, la continuità del servizio o la conformità normativa. GDPR aggiunge responsabilizzazione, integrità, riservatezza, preparazione alla gestione delle violazioni e danno agli interessati.

La Politica di gestione del rischio per PMI di Clarysec Politica di gestione del rischio per PMI fornisce un minimo pratico:

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

Questa è la clausola 5.1.2 della Politica di gestione del rischio per PMI. Per la preparazione a NIS2 e DORA, Clarysec estende quel minimo con campi quali fonte dell’obbligo, servizio interessato, categoria di dati, dipendenza dal fornitore, responsabile dell’attività, impatto normativo, rischio residuo, stato del trattamento e fonte delle evidenze.

Osserva il linguaggio. Una giustificazione solida non dice soltanto “attuato”. Spiega perché il controllo è applicabile nel contesto aziendale, normativo e di rischio dell’organizzazione.

Mappa i domini NIS2 e DORA sui controlli ISO 27001:2022

Una volta definiti il Registro di conformità e i criteri di rischio, il lavoro pratico consiste nel mappare i domini normativi sui controlli dell’Allegato A. Questa mappatura non dimostra di per sé la conformità, ma fornisce ad auditor e clienti un indice chiaro per verificare le evidenze.

Per Elena, questa mappatura ha cambiato la discussione con il Consiglio di amministrazione. Invece di presentare NIS2 e DORA come progetti separati, ha potuto mostrare la sovrapposizione: governance, gestione del rischio, incidenti, continuità, fornitori, test, controllo degli accessi e crittografia.

I tre controlli ISO da cui dipende ogni SoA NIS2 e DORA

In Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec considera tre controlli ISO/IEC 27002:2022 centrali per una governance della SoA pronta per l’audit in ottica NIS2 e DORA. Si tratta di controlli ISO, arricchiti con attributi di cross-compliance nella guida Zenith Controls.

Questi controlli non sono isolati. Si collegano direttamente ai controlli sui rapporti con i fornitori da A.5.19 a A.5.23, ai controlli di gestione degli incidenti da A.5.24 a A.5.28, ai controlli di continuità A.5.29 e A.5.30, al controllo privacy A.5.34, alla gestione delle vulnerabilità A.8.8, alla gestione della configurazione A.8.9, al backup delle informazioni A.8.13, al logging A.8.15, alle attività di monitoraggio A.8.16, alla crittografia A.8.24, ai controlli di sviluppo sicuro da A.8.25 a A.8.29 e alla gestione dei cambiamenti A.8.32.

Il valore di Zenith Controls è che aiuta i team a evitare di trattare la SoA come un documento riferito a un solo standard. Il controllo 5.31 supporta la mappatura legale e contrattuale. Il controllo 5.35 supporta audit interno, riesame indipendente e assurance della direzione. Il controllo 5.36 supporta la conformità operativa a politiche, procedure, standard e requisiti di controllo.

Usa Zenith Blueprint per costruire, testare e difendere la SoA

In Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Clarysec colloca la costruzione della SoA nella fase di gestione del rischio, Passaggio 13: pianificazione del trattamento del rischio e Dichiarazione di Applicabilità. Il Blueprint istruisce le organizzazioni a utilizzare il foglio SoA nel template “Risk Register and SoA Builder.xlsx”, decidere se ciascuno dei 93 controlli dell’Allegato A è applicabile e basare la decisione su trattamento del rischio, requisiti legali e contrattuali, rilevanza del campo di applicazione e contesto organizzativo.

Il Blueprint afferma:

La SoA è di fatto un documento ponte: collega la valutazione/trattamento del rischio ai controlli effettivamente presenti.

Questa frase sintetizza il modello operativo. La SoA collega obblighi, rischi, politiche, controlli, evidenze e conclusioni di audit.

Lo Zenith Blueprint istruisce inoltre i team a inserire riferimenti incrociati alle normative nelle note della SoA, ove appropriato. Se un controllo è attuato per GDPR, NIS2 o DORA, questo dovrebbe risultare nel Registro dei rischi o nelle note della SoA. Successivamente, nel Passaggio 24, il Blueprint indica alle organizzazioni di aggiornare la SoA dopo l’attuazione e verificarla in modo incrociato con il Piano di trattamento del rischio. Nel Passaggio 30, preparazione alla certificazione, riesame finale e simulazione di audit, il Blueprint indirizza i team a confermare che ciascun controllo applicabile dell’Allegato A disponga di evidenze quali una politica, una procedura, un report, un piano o una registrazione di attuazione.

Questa sequenza rende la SoA uno strumento vivo di conformità:

1. Il Passaggio 13 la costruisce a partire dal trattamento del rischio e dagli obblighi.
2. Il Passaggio 24 la verifica rispetto alla realtà dell’attuazione.
3. Il Passaggio 30 la difende attraverso il riesame finale delle evidenze e una simulazione di audit.

Come scrivere giustificazioni di inclusione comprensibili per gli auditor

Un controllo dovrebbe essere incluso quando esiste almeno un driver sostenibile: trattamento del rischio, requisito legale, requisito contrattuale, rilevanza per il campo di applicazione, requisito minimo di igiene della sicurezza, aspettativa di assurance del cliente o obiettivo di resilienza approvato dalla direzione.

Una formula utile è:

Applicabile perché [rischio o obbligo] riguarda [servizio, asset, dati o processo] e questo controllo fornisce [esito preventivo, di rilevamento, correttivo o di resilienza], comprovato da [politica, registrazione, test, report o output di sistema].

Per un fornitore SaaS fintech, una riga della SoA potrebbe apparire così:

Questo è pronto per l’audit perché collega il controllo a contesto, rischio, obbligo, attuazione, responsabilità ed evidenze.

Come giustificare le esclusioni senza creare esposizione in sede di audit

Le esclusioni non sono fallimenti. Le esclusioni giustificate male sono fallimenti.

ISO/IEC 27001:2022 richiede che la SoA giustifichi i controlli esclusi dell’Allegato A. ISO/IEC 27005:2022 rafforza il principio secondo cui la non applicabilità deve essere spiegata e giustificata. La Politica per la sicurezza delle informazioni per le imprese di Clarysec stabilisce:

Il livello di riferimento può essere adattato; tuttavia, le esclusioni devono essere documentate nella SoA con approvazione formale e giustificazione.

Questa è la clausola 7.2.2 della Politica per la sicurezza delle informazioni.

La Politica per la sicurezza delle informazioni per PMI di Clarysec Politica per la sicurezza delle informazioni per PMI stabilisce:

Qualsiasi deviazione da questa politica deve essere documentata, spiegando chiaramente perché la deviazione è necessaria, quali misure di protezione alternative sono in atto e la data definita per il riesame.

Questo requisito deriva dalla clausola 7.2.1 della Politica per la sicurezza delle informazioni per PMI.

Per NIS2 e DORA, le esclusioni richiedono attenzione ulteriore. Un’azienda SaaS dovrebbe raramente escludere logging, monitoraggio, backup, gestione degli incidenti, controllo degli accessi, sicurezza dei fornitori o gestione delle vulnerabilità. Anche quando un controllo non è collegato a uno specifico rischio, può comunque essere necessario come requisito minimo di sicurezza, assurance del cliente, aspettativa contrattuale o obbligo legale.

La Politica di gestione del rischio per PMI di Clarysec ricorda inoltre ai team come deve essere gestito il rischio accettato:

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

Quella clausola, 6.1.1 della Politica di gestione del rischio per PMI, esprime esattamente l’impostazione necessaria per le esclusioni e le decisioni sul rischio residuo.

Segnalazione degli incidenti: dimostrare il flusso di lavoro, non l’esistenza della politica

NIS2 Article 23 richiede la segnalazione per fasi degli incidenti significativi, incluso un preallarme entro 24 ore dalla conoscenza, una notifica entro 72 ore, aggiornamenti ove richiesti e un rapporto finale entro un mese dalla notifica delle 72 ore. DORA richiede alle entità finanziarie di rilevare, gestire, classificare, segnalare tempestivamente, comunicare e notificare i gravi incidenti connessi all’ICT, informare i clienti interessati ove richiesto, eseguire l’analisi della causa radice e migliorare i controlli.

Un fornitore SaaS potrebbe non segnalare sempre direttamente a un’autorità DORA, ma potrebbe dover supportare le tempistiche di segnalazione dei clienti finanziari. Questo rende i controlli sugli incidenti altamente rilevanti nella SoA.

Una SoA debole afferma: “Esiste la politica di risposta agli incidenti.”

Una SoA solida afferma: “Applicabile perché l’organizzazione deve rilevare, valutare, classificare, segnalare tempestivamente, comunicare, preservare le evidenze, supportare le tempistiche di segnalazione normativa, notificare i clienti interessati ove contrattualmente richiesto e apprendere dagli incidenti che interessano servizi, dati o clienti regolamentati.”

Le evidenze dovrebbero includere:

• Piano di risposta agli incidenti e matrice di escalation.
• Criteri di classificazione della gravità.
• Flusso di notifica ai clienti.
• Albero decisionale per la notifica normativa, ove applicabile.
• Ticket e cronologie degli incidenti.
• Log e allerte di monitoraggio.
• Registrazioni delle esercitazioni tabletop.
• Riesame post-incidente e azioni correttive.
• Procedure di conservazione delle evidenze.

La Politica di audit e monitoraggio della conformità per le imprese di Clarysec Politica di audit e monitoraggio della conformità spiega perché questo è importante:

Generare evidenze sostenibili e una traccia di audit a supporto di richieste dell’autorità di regolamentazione, procedimenti legali o richieste di assurance dei clienti.

Questo obiettivo deriva dalla clausola 3.4 della Politica di audit e monitoraggio della conformità.

Per le organizzazioni più piccole, anche la conservazione delle evidenze deve essere esplicita. La Politica di audit e monitoraggio della conformità per PMI di Clarysec Politica di audit e monitoraggio della conformità per PMI stabilisce:

Le evidenze devono essere conservate per almeno due anni, o più a lungo ove richiesto da certificazioni o accordi con i clienti.

Questa è la clausola 6.2.4 della Politica di audit e monitoraggio della conformità per PMI.

Una sola SoA, più conversazioni di audit

La migliore SoA non duplica i framework. Crea una narrazione tracciabile dei controlli che auditor diversi possono comprendere.

Un auditor ISO 27001 di solito parte dalla logica delle clausole: campo di applicazione, parti interessate, valutazione del rischio, trattamento del rischio, SoA, obiettivi, audit interno, riesame della direzione e miglioramento. Un valutatore orientato a NIS2 si concentra su proporzionalità, responsabilità della direzione, formazione, catena di fornitura, tempistiche degli incidenti e impatto sul servizio. Un valutatore cliente orientato a DORA si concentra su rischio ICT, funzioni critiche o importanti, gravi incidenti ICT, test di resilienza, clausole contrattuali, diritto di audit, piani di uscita, subappalto e rischio di concentrazione. Un valutatore privacy si concentra su responsabilizzazione GDPR e preparazione alle violazioni. Un auditor in stile COBIT 2019 o ISACA verifica governance, metriche, responsabilità, assurance e azione correttiva.

Per questo la SoA non può essere mantenuta solo dal team di sicurezza. Richiede responsabilità da parte di legale, privacy, approvvigionamento, engineering, operations, HR e direzione esecutiva.

Errori comuni della SoA nei progetti di preparazione a NIS2 e DORA

Clarysec riscontra ripetutamente gli stessi problemi nei progetti di preparazione:

1. La SoA indica i controlli come applicabili, ma non registra alcun rischio, obbligo o motivo aziendale.
2. NIS2 e DORA sono menzionate nelle politiche, ma non mappate a controlli, responsabili o evidenze.
3. I controlli sui fornitori sono indicati come attuati, ma non esistono Registro dei fornitori, classificazione della criticità, riesame contrattuale o piano di uscita.
4. I controlli sugli incidenti esistono, ma il processo non supporta flussi di segnalazione a 24 ore, 72 ore, verso il cliente o finale.
5. L’approvazione della direzione è implicita, ma non esiste alcuna registrazione dell’accettazione del rischio, dell’approvazione della SoA o della decisione sul rischio residuo.
6. Le esclusioni sono copiate da un template e non corrispondono al modello operativo effettivo cloud, remoto, SaaS o fintech.
7. Le evidenze esistono in diversi strumenti, ma nessuna traccia di audit collega le evidenze alla SoA.
8. Il trattamento dei dati personali GDPR non è collegato ai controlli di sicurezza, alla risposta alle violazioni, ai contratti con i fornitori o alla conservazione.
9. L’audit interno controlla i documenti, ma non verifica se la SoA rifletta la reale attuazione.
10. La SoA viene aggiornata solo prima della certificazione, non dopo nuovi clienti, fornitori, incidenti, risultanze dell’audit o modifiche normative.

Questi non sono problemi documentali. Sono problemi di governance.

Checklist pratica per una SoA ISO 27001 pronta per l’audit

Utilizza questa checklist prima di un audit di certificazione ISO 27001, un riesame di preparazione NIS2, una valutazione cliente DORA, una riunione del Consiglio di amministrazione o un processo di due diligence degli investitori.

Trasforma la SoA in un ponte di conformità sostenibile

La presentazione di Elena al Consiglio di amministrazione ha avuto successo perché non ha presentato tre progetti di conformità scollegati. Ha presentato un unico modello operativo controllato e basato su evidenze, costruito su ISO/IEC 27001:2022, con la SoA come ponte tra regolamentazione, rischio, attuazione dei controlli, evidenze e vigilanza della direzione.

NIS2 e DORA non rendono ISO 27001 obsoleta. Rendono più preziosa una Dichiarazione di Applicabilità ISO 27001 ben costruita. La SoA può diventare il punto unico in cui la tua organizzazione spiega perché i controlli esistono, perché le esclusioni sono sostenibili, come vengono conservate le evidenze, come sono governati i fornitori, come vengono segnalati tempestivamente gli incidenti e come la direzione sa che il SGSI sta funzionando.

La tua azione immediata è semplice:

1. Apri la tua SoA attuale.
2. Scegli cinque controlli contrassegnati come applicabili e chiedi: “Quale rischio, obbligo o contratto lo giustifica?”
3. Scegli cinque esclusioni e chiedi: “Avrebbe ancora senso per un auditor NIS2, DORA, GDPR o ISO/IEC 27001:2022?”
4. Verifica se ogni controllo applicabile dispone di evidenze aggiornate.
5. Conferma che la direzione abbia approvato i rischi residui e le decisioni SoA.
6. Aggiorna il Registro di conformità, il Registro dei rischi e la SoA ogni volta che cambiano servizi, fornitori, clienti, regolamenti o incidenti.

Clarysec aiuta le organizzazioni a farlo attraverso Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, set di politiche per imprese e PMI, strumenti per il Registro dei rischi, template SoA, preparazione agli audit e mappatura cross-compliance per NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 e assurance dei clienti.

Se la tua SoA non sa rispondere a perché, chi ne è responsabile, quale evidenza lo dimostra e quale obbligo supporta, non è ancora pronta. Usa Clarysec per trasformarla in un ponte di conformità pronto per l’audit prima che un’autorità di regolamentazione, un auditor o un cliente ponga per primo le stesse domande.