Matrice delle responsabilità condivise nel cloud per ISO, NIS2 e DORA

Il COO di una fintech chiama il CISO alle 07:15 di lunedì.

Un cliente bancario europeo chiede evidenze che la piattaforma SaaS dell’azienda sia in grado di soddisfare i requisiti DORA sul rischio ICT di terze parti. Il team commerciale ha già inviato il consueto pacchetto di sicurezza del fornitore: certificato ISO, sintesi esecutiva del penetration test, certificato di assicurazione cyber, informativa privacy e report di assurance del fornitore cloud.

La banca torna con una domanda più puntuale:

“Mostrateci chi è titolare di ciascun controllo nel vostro ambiente cloud. Voi, il vostro fornitore cloud, il vostro fornitore di database gestito, il vostro provider di identità, il vostro fornitore di logging e gli eventuali sub-responsabili. Poi mostrate le evidenze.”

Più tardi, quella mattina, il CISO partecipa a una riunione del Consiglio di amministrazione. Il CEO porrà la stessa domanda in termini aziendali: “Siamo certi che questa piattaforma sia sicura e chi è responsabile se qualcosa va storto?”

È qui che molti programmi di conformità cloud si bloccano.

L’organizzazione può avere un fornitore cloud solido, strumenti adeguati, policy ragionevoli e un registro dei rischi. Ma quando le viene chiesto di dimostrare i confini di responsabilità, le evidenze risultano disperse. Gli Acquisti hanno i contratti. La funzione Legale ha il DPA. L’Engineering ha i diagrammi architetturali. La Sicurezza ha log e configurazioni cloud. La Privacy ha l’elenco dei sub-responsabili. La Compliance ha la Dichiarazione di applicabilità. Nessuno dispone di un unico artefatto controllato che indichi, controllo per controllo, cosa fa il fornitore, cosa deve configurare il cliente, quale sub-responsabile è coinvolto, quale clausola rende l’obbligo azionabile e quali evidenze un auditor dovrebbe aspettarsi.

Quell’artefatto è la matrice delle responsabilità condivise nel cloud.

Non la slide generica dell’hyperscaler secondo cui il fornitore protegge il cloud e il cliente protegge ciò che si trova nel cloud. Una vera matrice delle responsabilità condivise nel cloud per ISO/IEC 27001:2022, NIS2, DORA e GDPR è una registrazione di governance. Regge alla due diligence dei clienti, a un audit ISO, a un riesame DORA, a una contestazione in materia di responsabilizzazione GDPR e a un’indagine su un incidente.

Perché la responsabilità condivisa nel cloud diventa un tema di audit

Il modello di responsabilità condivisa viene solitamente presentato come un confine tecnico. In IaaS, il fornitore gestisce strutture fisiche, hardware, virtualizzazione e infrastruttura core. Il cliente gestisce identità, dati, workload, regole di rete, scelte di cifratura e configurazioni. In SaaS, il fornitore assume una maggiore responsabilità operativa, ma il cliente mantiene la responsabilità su accessi utente, governance dei dati, base giuridica, configurazione, aspettative di monitoraggio ed escalation degli incidenti.

Questa spiegazione è utile, ma incompleta.

Auditor, autorità di regolamentazione e clienti enterprise chiedono più di “chi gestisce il controllo?”. Vogliono sapere:

• Chi è responsabile del rischio?
• Quale clausola contrattuale rende tale responsabilità azionabile?
• Quale policy richiede il controllo?
• Quale servizio cloud, piattaforma SaaS o sub-responsabile rientra nel campo di applicazione?
• Quale evidenza dimostra che il controllo ha funzionato durante il periodo di riesame?
• Quale requisito del quadro di riferimento è soddisfatto dall’evidenza?
• Cosa accade se il fornitore modifica il servizio, la sede, il subappaltatore o il proprio livello di controllo?

ISO/IEC 27001:2022 ISO/IEC 27001:2022 rende questo un tema del sistema di gestione. Le clausole da 4.1 a 4.4 richiedono all’organizzazione di comprendere questioni interne ed esterne, parti interessate, obblighi legali e contrattuali, campo di applicazione del SGSI, interfacce e dipendenze. Le clausole da 6.1.1 a 6.1.3 richiedono valutazione del rischio, trattamento del rischio, approvazione da parte del risk owner, accettazione del rischio residuo e Dichiarazione di applicabilità. La clausola 8.1 richiede pianificazione e controllo operativi, compreso il controllo di processi, prodotti e servizi forniti dall’esterno e rilevanti per il SGSI.

In termini semplici, se un fornitore cloud, un fornitore SaaS o un sub-responsabile supporta un processo aziendale compreso nel campo di applicazione, non può restare fuori dal SGSI. Deve essere visibile nell’ambito, nel rischio, nel trattamento, nel controllo contrattuale e nelle evidenze.

NIS2 alza il livello di attenzione. Article 21 richiede ai soggetti essenziali e importanti di attuare misure tecniche, operative e organizzative adeguate e proporzionate, incluse analisi dei rischi, gestione degli incidenti, continuità, sicurezza della catena di fornitura, acquisizione sicura, sviluppo sicuro, processo di gestione delle vulnerabilità, valutazione dell’efficacia, igiene cyber, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset e autenticazione a più fattori o autenticazione continua ove opportuno. Article 20 attribuisce agli organi di gestione la responsabilità di governance.

DORA è ancora più esplicito per gli enti finanziari. Si applica dal 17 gennaio 2025 e richiede agli enti finanziari di gestire il rischio ICT, la segnalazione degli incidenti ICT gravi, i test di resilienza operativa digitale e il rischio ICT di terze parti. Articles 28 to 30 richiedono gestione del rischio ICT di terze parti, valutazione preliminare del rischio di concentrazione, misure di sicurezza contrattuali, diritti di audit e di accesso, visibilità sul subappalto, diritti di risoluzione e strategie di uscita.

Il GDPR aggiunge il test di responsabilizzazione. Article 5 richiede che i dati personali siano trattati con integrità e riservatezza, e Article 5(2) richiede al titolare del trattamento di essere in grado di dimostrare la conformità. Article 28 disciplina i contratti con i responsabili del trattamento e i sub-responsabili. Article 32 richiede la sicurezza del trattamento. Articles 33 and 34 richiedono la notifica della violazione dei dati personali ove applicabile.

La matrice delle responsabilità condivise nel cloud diventa il collegamento tra questi obblighi.

La definizione Clarysec: un artefatto di governance, non un diagramma

Negli incarichi Clarysec, una matrice delle responsabilità condivise nel cloud è una registrazione controllata del SGSI che collega servizi cloud, fornitori, sub-responsabili, controlli, policy, obblighi contrattuali, evidenze e aspettative di audit.

La spiegazione più efficace si trova in Zenith Blueprint Zenith Blueprint, nella fase Controls in Action, Step 23:

“I fornitori cloud proteggono l’infrastruttura, ma voi restate responsabili dei vostri dati, delle vostre configurazioni, delle vostre politiche di accesso e della vostra prontezza alla risposta agli incidenti.”

Lo stesso step spiega che l’uso del cloud deve essere trattato come parte del SGSI, includendo la classificazione dei servizi cloud, la comprensione dei dati trattati o archiviati, la valutazione del fornitore, le clausole contrattuali e la gestione delle modifiche del servizio. Questo trasforma la responsabilità condivisa da concetto a struttura di controllo tracciabile.

Zenith Controls Zenith Controls considera i controlli dell’Annex A di ISO/IEC 27001:2022 e le linee guida ISO/IEC 27002:2022 5.20, 5.21 e 5.23 come ancoraggi centrali:

• 5.20, gestione della sicurezza delle informazioni negli accordi con i fornitori.
• 5.21, gestione della sicurezza delle informazioni nella catena di fornitura ICT.
• 5.23, sicurezza delle informazioni per l’uso dei servizi cloud.

Non si tratta di voci isolate di una checklist. Definiscono la spina dorsale della matrice.

Gli standard di supporto possono rafforzare la matrice. ISO/IEC 27017 aiuta con le pratiche di sicurezza specifiche per il cloud. ISO/IEC 27018 e ISO/IEC 27701 supportano la governance dei dati personali identificabili e della privacy. ISO/IEC 27005 supporta la valutazione del rischio. ISO 22301 supporta continuità e resilienza. ISO/IEC 27035 supporta la gestione degli incidenti. ISO/IEC 20000-1 può essere utile quando i servizi cloud fanno parte dell’erogazione di servizi gestiti.

La matrice minima sostenibile delle responsabilità condivise

Una matrice matura non parte da 200 righe. Parte dai servizi cloud più rilevanti.

Per una SaaS, una fintech o una PMI regolamentata, Clarysec inizia di solito da:

1. Ambiente cloud di produzione rivolto ai clienti.
2. Provider di identità.
3. Database gestito o servizio di storage.
4. Piattaforma di logging, monitoraggio e SIEM.
5. SaaS per pagamenti, KYC, analytics o assistenza clienti.
6. Servizio di backup e disaster recovery.
7. Fornitore di servizi gestiti o fornitore di servizi di sicurezza gestiti.
8. Sub-responsabili che accedono, archiviano o trattano dati dei clienti.

La prima matrice dovrebbe includere le seguenti colonne.

Una riga pratica relativa al logging potrebbe essere questa.

Quella riga non è semplice documentazione. Indica alla Sicurezza cosa configurare, agli Acquisti quale linguaggio contrattuale verificare, alla Privacy quale flusso di dati registrare e agli auditor quali evidenze richiedere.

Fondamento di policy: trasformare la matrice in un requisito azionabile

Una matrice delle responsabilità condivise nel cloud senza supporto nelle policy è solo un foglio di calcolo. Le policy Clarysec la rendono azionabile.

Per le PMI, Policy di utilizzo del cloud - PMI Cloud Usage Policy - SME, sezione “Requisiti di governance”, clausola 5.3 richiede:

“Un Registro dei servizi cloud deve essere mantenuto dal fornitore IT o dal GM. Deve registrare:”

La stessa policy per PMI, clausola 5.2.3, collega la governance del cloud al rischio privacy e di localizzazione:

“La localizzazione dei dati e le pratiche privacy sono conformi ai requisiti legali applicabili (ad es., GDPR)”

Per gli ambienti enterprise, Policy di utilizzo del cloud Cloud Usage Policy, sezione “Requisiti di governance”, clausola 5.1 stabilisce:

“L’organizzazione deve mantenere un Registro dei servizi cloud centralizzato, di titolarità del CISO, contenente:”

La clausola 5.4 rende poi le responsabilità cloud contrattualmente azionabili:

“Tutti i contratti CSP (fornitore di servizi cloud) devono includere disposizioni azionabili per:”

La governance dei fornitori estende la matrice oltre il fornitore immediato. Policy di sicurezza delle terze parti e dei fornitori - PMI Third-Party and Supplier Security Policy - SME, sezione “Requisiti di governance”, clausola 5.3.5 richiede:

“Restrizioni su ulteriori subappalti senza approvazione”

La stessa policy fornitori per PMI, sezione “Requisiti di applicazione della policy”, clausola 6.3.1 aggiunge il riesame periodico:

“I fornitori critici o ad alto rischio devono essere riesaminati almeno annualmente. Il riesame deve verificare:”

A livello enterprise, Policy di sicurezza delle terze parti e dei fornitori Third party and supplier security policy, sezione “Requisiti di governance”, clausola 5.3 stabilisce:

“I contratti con i fornitori devono includere:”

Per i dati personali, Policy di protezione dei dati e privacy Data Protection and Privacy Policy, sezione “Applicazione e conformità”, clausola 8.5.1 richiede:

“I contratti con i responsabili del trattamento devono includere:”

Per la visibilità delle dipendenze, Policy di gestione del rischio di dipendenza dai fornitori Supplier Dependency Risk Management Policy, clausola 6.5.4 richiede:

“Sfruttare il rapporto con il fornitore per ottenere aggiornamenti sui subappaltatori o sulle dipendenze della catena di fornitura a un livello a valle, laddove possano incidere su di noi (ad esempio, se un fornitore software critico dipende in modo rilevante da una libreria di terze parti, ciò deve essere registrato).”

Per i log, Policy di logging e monitoraggio - PMI Logging and Monitoring Policy - SME, sezione “Requisiti di governance”, clausola 5.5.1.3 fornisce un requisito contrattuale concreto:

“I contratti devono richiedere ai fornitori di conservare i log per almeno 12 mesi e di fornire accesso su richiesta”

Nel complesso, queste policy rendono la matrice una registrazione di governance obbligatoria che supporta approvazione dei fornitori, onboarding cloud, responsabilizzazione privacy, riesame annuale ed evidenze di audit.

Mappare la matrice su ISO/IEC 27001:2022, NIS2, DORA e GDPR

L’errore classico è creare quattro cartelle di lavoro separate per la conformità. Un controllo può soddisfare più obblighi se responsabilità ed evidenze sono tracciabili.

ISO/IEC 27001:2022 fornisce il motore del SGSI: contesto, parti interessate, campo di applicazione, leadership, trattamento del rischio, obiettivi, controllo operativo, valutazione delle prestazioni e miglioramento. L’Annex A fornisce la struttura pratica dei controlli.

NIS2 Article 21 si mappa naturalmente sulla stessa matrice attraverso sicurezza della catena di fornitura, gestione degli incidenti, continuità, controllo degli accessi, gestione degli asset e acquisizione sicura. Article 20 rende la matrice rilevante per il Consiglio di amministrazione perché gli organi di gestione devono approvare e supervisionare le misure di gestione del rischio di cibersicurezza.

DORA trasforma la matrice in uno strumento di rischio ICT di terze parti. Articles 5, 6 and 8 richiedono governance, gestione del rischio ICT documentata e identificazione di asset, funzioni e dipendenze. Articles 17 to 19 richiedono rilevazione, classificazione, escalation, comunicazione e segnalazione degli incidenti. Articles 28 to 30 richiedono gestione del rischio di terze parti, analisi del rischio di concentrazione, clausole contrattuali, controlli sul subappalto, diritti di audit, diritti di risoluzione e strategie di uscita.

Il GDPR aggiunge la prospettiva dei dati personali. Ogni riga relativa a un servizio cloud dovrebbe indicare se vengono trattati dati personali, se il fornitore è un responsabile del trattamento o un sub-responsabile, se la localizzazione dei dati è rilevante e quali evidenze contrattuali o DPA esistono.

NIST CSF 2.0 aiuta a comunicare la stessa matrice in termini di risultati. La funzione GOVERN copre contesto organizzativo, requisiti legali e normativi, dipendenze, gestione del rischio, ruoli, policy e supervisione. Gli outcome GV.SC sono particolarmente utili per il rischio cyber dei fornitori, inclusi ruoli dei fornitori, criticità, requisiti contrattuali, due diligence, monitoraggio, coordinamento degli incidenti e pianificazione della risoluzione.

COBIT 2019 aggiunge una prospettiva di assurance e governance. Chiede se responsabilizzazione, pratiche di gestione, titolarità, monitoraggio e remediation degli issue siano ripetibili e supportati da evidenze.

Costruire la matrice dal registro alla prova

Immagina una società SaaS che utilizza una piattaforma IaaS hyperscale, un database gestito, un provider di identità di terze parti, una piattaforma SaaS di assistenza clienti e un SIEM esterno. Il flusso di implementazione è lineare.

Step 1: partire dal Registro dei servizi cloud

Utilizza Policy di utilizzo del cloud o Policy di utilizzo del cloud - PMI come trigger. Registra ciascun servizio cloud, proprietario, finalità, categorie di dati, localizzazione, funzione aziendale, livello del fornitore, custode del contratto e data di riesame.

Se il servizio archivia registrazioni dei clienti, log di autenticazione o ticket di supporto, contrassegnalo come rilevante per la privacy. Se supporta la disponibilità della produzione, contrassegnalo come critico dal punto di vista operativo. Se supporta una funzione critica o importante di un cliente finanziario, contrassegnalo come rilevante DORA.

Step 2: aggiungere i domini di responsabilità condivisa

Per ciascun servizio, definisci le responsabilità nei domini core.

Step 3: collegare i controlli al rischio e alla Dichiarazione di applicabilità

Zenith Blueprint, fase Risk Management, Step 13, spiega il requisito di tracciabilità:

“Riferimenti incrociati alle normative: se determinati controlli sono implementati specificamente per conformarsi a GDPR, NIS2 o DORA, è possibile annotarlo nel Registro dei rischi (come parte della giustificazione dell’impatto del rischio) oppure nelle note della SoA.”

Ad esempio, il rischio “accesso non autorizzato ai dati di produzione dei clienti tramite configurazione cloud errata” può mappare controllo degli accessi, uso del cloud, logging, crittografia, gestione delle vulnerabilità e accordi con i fornitori. La SoA può fare riferimento a ISO/IEC 27001:2022 Annex A 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 e 8.24, con note per GDPR Article 32, NIS2 Article 21 e gestione del rischio ICT DORA ove applicabile.

Step 4: allegare le evidenze prima della stagione di audit

Le evidenze devono essere progettate nella matrice, non raccolte nel panico.

L’elenco delle evidenze trasforma la responsabilità in prova. Aiuta anche i team commerciali a rispondere più rapidamente alla due diligence enterprise, perché possono mostrare non solo certificazioni, ma anche titolarità dei controlli ed evidenze operative.

Sub-responsabili: il punto cieco della maggior parte delle matrici

I sub-responsabili sono il punto in cui la responsabilità condivisa diventa rischio reale della catena di fornitura.

Un fornitore SaaS può essere il vostro responsabile del trattamento ai sensi del GDPR. Quel fornitore può affidarsi a un provider di hosting cloud, CDN, servizio di analytics, piattaforma di supporto, servizio di invio e-mail, database gestito, provider di osservabilità e processore di pagamenti. Alcuni possono accedere a dati personali. Alcuni possono supportare l’erogazione di servizi critici senza visualizzare direttamente i dati. Alcuni possono trovarsi fuori dall’UE. Alcuni possono essere sostituibili. Altri possono generare rischio di concentrazione.

DORA Article 29 richiede una valutazione del rischio di concentrazione per i servizi ICT critici o importanti, inclusi sostituibilità, accordi multipli con lo stesso fornitore o con fornitori collegati, catene di subappalto, subappaltatori di paesi terzi, diritto fallimentare, vincoli di recupero dei dati e azionabilità della protezione dei dati dell’Unione. DORA Article 30 richiede disposizioni contrattuali relative a condizioni di subappalto, sedi, trattamento e archiviazione dei dati, accesso e recupero, assistenza sugli incidenti, cooperazione con le autorità, diritti di audit, risoluzione e uscita.

NIS2 Article 21 richiede analogamente sicurezza della catena di fornitura per fornitori diretti e prestatori di servizi, oltre alla considerazione delle vulnerabilità specifiche dei fornitori, delle pratiche di cibersicurezza dei fornitori e delle procedure di sviluppo sicuro.

Per questo Clarysec tratta la mappatura dei sub-responsabili come un’estensione obbligatoria della governance dei fornitori, non come un semplice elenco privacy. Il registro dei sub-responsabili dovrebbe indicare quale fornitore utilizza il sub-responsabile, da quale servizio dipende, se vengono trattati dati personali, se supporta una funzione critica, la regione di trattamento ove rilevante, gli obblighi contrattuali a cascata, i diritti di approvazione o opposizione, l’assurance disponibile, il metodo di monitoraggio e l’opzione di uscita.

Zenith Blueprint, fase Controls in Action, Step 23 afferma:

“Per ogni fornitore critico, identificare se utilizza subappaltatori (sub-responsabili) che possono accedere ai vostri dati o sistemi. Documentare come i requisiti di sicurezza delle informazioni vengono trasferiti a tali parti, tramite le condizioni contrattuali del vostro fornitore o tramite vostre clausole dirette.”

Questo è il livello di prova che gli auditor si aspettano quando chiedono se le responsabilità cloud siano controllate a valle.

Come gli auditor testano la stessa matrice

Una matrice delle responsabilità condivise nel cloud solida regge a più stili di audit perché è costruita intorno a titolarità, azionabilità ed evidenze.

La matrice non è l’obiettivo finale. È la mappa che gli auditor utilizzano per verificare se il sistema di governance è reale.

Un auditor ISO può selezionare un rischio di accesso cloud ad alto impatto e tracciarlo dal registro dei rischi alla SoA, quindi ai riesami degli accessi, alle evidenze MFA e agli alert di monitoraggio. Un valutatore DORA può selezionare un fornitore ICT critico e chiedere il test di uscita, l’analisi del subappalto e i diritti contrattuali di audit. Un revisore GDPR può concentrarsi su cancellazione, localizzazione dei dati, notifica delle violazioni e trasparenza dei sub-responsabili.

Schemi di fallimento comuni

I fallimenti più frequenti della responsabilità condivisa non sono esotici.

Primo, le organizzazioni si affidano ai report di assurance del fornitore senza mapparli alle responsabilità del cliente. Un fornitore cloud può dimostrare sicurezza fisica, resilienza dell’infrastruttura e controlli di piattaforma, ma non se il vostro bucket di storage fosse privato, se i ruoli IAM rispettassero il principio del privilegio minimo o se i log fossero abilitati.

Secondo, i contratti contengono un linguaggio di sicurezza generico ma non prevedono tempistiche degli incidenti, diritti di accesso ai log, diritti di audit, limiti al subappalto, disposizioni sulla restituzione dei dati o supporto all’uscita. Zenith Blueprint, fase Controls in Action, Step 23 evidenzia aree tipiche degli accordi con i fornitori, quali riservatezza, controllo degli accessi, misure tecniche e organizzative, tempistiche degli incidenti, diritto di audit, controlli sui subappaltatori e disposizioni di fine contratto.

Terzo, i sub-responsabili sono elencati per finalità privacy ma non collegati a sicurezza, continuità o rischio di concentrazione. Un provider a valle di osservabilità o supporto potrebbe non comparire mai nel registro dei rischi, anche se una sua indisponibilità o violazione potrebbe incidere sull’erogazione del servizio al cliente.

Quarto, la SoA dichiara un controllo applicabile, ma nessuno è in grado di produrre evidenze operative. Il logging cloud può essere indicato come implementato, ma l’organizzazione può non essere in grado di dimostrare impostazioni di conservazione, riesami degli accessi, gestione degli alert o impegni del fornitore sull’accesso ai log.

Quinto, i piani di risposta agli incidenti non riflettono la dipendenza dal fornitore. Se il fornitore notifica un incidente di piattaforma, chi valuta l’impatto sui clienti? Chi determina se è richiesta una notifica NIS2, DORA o GDPR? Chi contatta i clienti interessati? E se la causa radice è presso un sub-responsabile?

Responsabilizzazione della direzione: perché il Consiglio di amministrazione dovrebbe interessarsene

NIS2 Article 20 richiede agli organi di gestione di approvare le misure di gestione del rischio di cibersicurezza, supervisionarne l’attuazione e ricevere formazione. DORA Article 5 richiede all’organo di gestione di definire, approvare, supervisionare ed essere responsabile degli assetti di gestione del rischio ICT, incluse policy ICT di terze parti, piani di continuità e ripristino, piani di audit, formazione e canali di segnalazione.

Questo cambia lo scopo della matrice. Non è più solo un foglio di lavoro della Sicurezza. Diventa evidenza che la direzione conosce:

• Quali servizi cloud supportano operazioni critiche.
• Quali terze parti e sub-responsabili sono rilevanti.
• Quali obblighi si applicano in base ai contratti con i clienti, al GDPR, a NIS2 e a DORA.
• Quali responsabilità restano in capo all’organizzazione.
• Quali impegni del fornitore sono contrattualmente azionabili.
• Quali lacune richiedono finanziamento, remediation o accettazione del rischio.

Per le PMI, conta la proporzionalità. Un’entità più piccola non ha bisogno di una burocrazia pesante, ma ha comunque bisogno di documentazione, monitoraggio, sistemi resilienti, rilevazione delle fonti di rischio ICT, identificazione delle dipendenze chiave da terze parti, misure di continuità, test, lezioni apprese e riesame periodico dove rientra nel campo di applicazione.

La matrice è uno degli strumenti proporzionati più efficienti perché consolida gli obblighi invece di moltiplicarli.

Uno sprint di 30 giorni per rendere il modello cloud pronto per l’audit

Se non sai rispondere a chi è titolare di ciascun controllo cloud, quale evidenza lo dimostra e quale sub-responsabile potrebbe inciderci, il tuo modello di responsabilità condivisa è ancora un diagramma, non un artefatto di governance.

Uno sprint pratico di 30 giorni si presenta così:

1. Creare o aggiornare il Registro dei servizi cloud utilizzando Policy di utilizzo del cloud o Policy di utilizzo del cloud - PMI.
2. Identificare servizi critici, trattamenti di dati personali, sistemi rivolti ai clienti e rilevanza DORA o NIS2.
3. Costruire la prima matrice attorno ai controlli ISO/IEC 27001:2022 Annex A 5.20, 5.21 e 5.23 utilizzando Zenith Controls.
4. Collegare ogni riga al registro dei rischi e alla Dichiarazione di applicabilità utilizzando lo Step 13 di Zenith Blueprint.
5. Validare le clausole di fornitori e responsabili del trattamento utilizzando Policy di sicurezza delle terze parti e dei fornitori, Policy di sicurezza delle terze parti e dei fornitori - PMI e Policy di protezione dei dati e privacy.
6. Aggiungere conservazione dei log, escalation degli incidenti, approvazione dei sub-responsabili, diritti di audit ed evidenze di uscita.
7. Riesaminare i fornitori critici annualmente e dopo modifiche rilevanti, incidenti, nuovi sub-responsabili o risultanze di audit.

L’obiettivo è semplice. Quando cliente, auditor, autorità di regolamentazione o Consiglio di amministrazione chiedono “chi è titolare di questo controllo?”, non devi cercare tra contratti, ticket e cartelle. Apri la matrice, mostri il titolare, mostri la clausola, mostri le evidenze e mostri la traccia a valle.

Clarysec può aiutarti a trasformare i pacchetti di assurance dei fornitori cloud in una matrice integrata delle responsabilità condivise per audit ISO/IEC 27001:2022, preparazione NIS2, rischio ICT di terze parti DORA, responsabilizzazione GDPR e due diligence dei clienti enterprise.

Parti dal registro. Costruisci la matrice. Allega le evidenze. Poi usala come prova pronta per il Consiglio di amministrazione che il rischio cloud non è esternalizzato: è governato.