Evidenze della certificazione cloud EUCS per gli audit del 2026
Il bagliore del proiettore della sala riunioni illuminava il volto di Amelia mentre osservava una slide intitolata “Orizzonte di conformità 2026”. In qualità di CISO di una fintech in rapida crescita, aveva tre acronimi sullo schermo e un problema operativo ricorrente dietro ciascuno di essi: NIS2, DORA e GDPR rimandavano tutti alle stesse piattaforme cloud.
L’auditor DORA richiedeva evidenze sulla gestione del rischio ICT di terze parti per i servizi cloud che ospitavano le applicazioni di pagamento. L’autorità competente NIS2 aveva classificato la società come entità importante e chiedeva come fosse governata la sicurezza della catena di fornitura. Il Responsabile della protezione dei dati stava preparando un riesame GDPR focalizzato sulla sicurezza dei responsabili del trattamento, sulla localizzazione dei dati e sulla preparazione alla gestione delle violazioni. La funzione Acquisti inoltrò quindi una breve e-mail da un fornitore di cloud analytics:
“Ci stiamo preparando per la certificazione EUCS. Può sostituire il vostro riesame di sicurezza dei fornitori?”
Per un CISO, un responsabile della conformità o un founder con poco tempo a disposizione, la risposta più allettante è sì. Una certificazione europea di cibersicurezza cloud sembra esattamente l’evidenza utile a ridurre i questionari, rassicurare gli auditor e soddisfare i clienti.
La risposta corretta è più precisa: la certificazione cloud EUCS può diventare una potente evidenza di affidabilità per i fornitori cloud, ma solo quando viene mappata nella propria valutazione del rischio ISO/IEC 27001:2022, nella Dichiarazione di Applicabilità, nel Registro dei fornitori, nel Registro dei servizi cloud, nei controlli contrattuali, nei playbook di risposta agli incidenti e nelle registrazioni di accountability GDPR.
Questa distinzione è rilevante. NIS2 rende la sicurezza della catena di fornitura e la resilienza dell’infrastruttura digitale un tema di vigilanza. DORA mantiene gli enti finanziari responsabili del rischio ICT di terze parti anche quando i servizi cloud sono esternalizzati. GDPR richiede a titolari e responsabili del trattamento di dimostrare un trattamento responsabile, lecito e sicuro. ISO/IEC 27001:2022 richiede un sistema di gestione con ambito definito, basato sul rischio, che tenga conto delle dipendenze legali, normative, contrattuali e di terze parti.
EUCS non elimina tali obblighi. Fornisce un elemento di evidenza strutturato da valutare, normalizzare, verificare criticamente e riutilizzare.
L’approccio di Clarysec è semplice: trattare EUCS come un input di affidabilità dei fornitori ad alto valore, non come una scorciatoia per la conformità. In Zenith Controls: la guida alla conformità trasversale, il cluster di affidabilità cloud parte dal controllo ISO/IEC 27002:2022 5.23, Sicurezza delle informazioni per l’utilizzo dei servizi cloud, e lo collega al 5.20, Gestione della sicurezza delle informazioni negli accordi con i fornitori, e al 5.22, Monitoraggio, riesame e gestione dei cambiamenti dei servizi dei fornitori. Questi tre controlli costituiscono la spina dorsale di un riesame difendibile delle evidenze EUCS.
Perché l’affidabilità delle evidenze cloud è sotto pressione con NIS2, DORA e GDPR
Entro il 2026, l’affidabilità delle evidenze cloud non è più solo un flusso di lavoro di approvvigionamento. È un tema da consiglio di amministrazione, autorità di regolamentazione e audit.
La Direttiva NIS2, Direttiva (UE) 2022/2555, amplia gli obblighi di cibersicurezza delle entità essenziali e importanti. Il suo ambito include molti settori che dipendono fortemente dal cloud computing, e il panorama delle infrastrutture digitali comprende fornitori di cloud computing, prestatori di servizi di data center, reti di distribuzione dei contenuti, prestatori di servizi fiduciari, fornitori di servizi DNS e registri dei nomi di dominio di primo livello. Anche i prestatori di servizi gestiti e i prestatori di servizi di sicurezza gestiti sono al centro dell’attenzione.
Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, tra cui analisi dei rischi, trattamento degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e sviluppo sicuri, processo di trattamento delle vulnerabilità, valutazione dell’efficacia, igiene informatica, crittografia, controllo degli accessi, gestione degli asset e autenticazione. Article 23 definisce aspettative di segnalazione degli incidenti per fasi, tra cui un preallarme entro 24 ore e la notifica dell’incidente entro 72 ore, secondo quanto previsto dalla Direttiva e dal recepimento nazionale. Article 24 consente agli Stati membri, in determinate circostanze, di richiedere l’uso di prodotti, servizi o processi ICT certificati nell’ambito di schemi europei di certificazione della cibersicurezza. Article 25 incoraggia l’uso di norme europee e internazionali pertinenti.
DORA, Regolamento (UE) 2022/2554, è ancora più diretto per gli enti finanziari. Dal 17 gennaio 2025 richiede alle organizzazioni finanziarie di gestire il rischio ICT, segnalare gli incidenti rilevanti connessi all’ICT, testare la resilienza operativa digitale e governare il rischio ICT di terze parti. Per le entità rientranti nel suo ambito, DORA opera come atto giuridico dell’Unione settoriale per i corrispondenti obblighi di cibersicurezza che si sovrappongono alle norme nazionali NIS2.
DORA non consente di esternalizzare l’accountability. Articles 28 to 30 richiedono agli enti finanziari di svolgere due diligence, valutare il rischio di concentrazione, mantenere registri degli accordi contrattuali, includere misure di sicurezza contrattuali obbligatorie, preservare i diritti di audit e di accesso, garantire assistenza in caso di incidente, cooperare con le autorità competenti e mantenere strategie di uscita per i servizi ICT a supporto di funzioni critiche o importanti.
GDPR, Regolamento (UE) 2016/679, aggiunge il livello di accountability e protezione dei dati. Article 5 richiede ai titolari del trattamento di rispettare i principi di protezione dei dati e di poter dimostrare la conformità. Article 28 disciplina i rapporti con i responsabili del trattamento e richiede garanzie sufficienti da parte dei responsabili. Article 32 richiede misure tecniche e organizzative adeguate per garantire la sicurezza del trattamento.
Il risultato è un problema di convergenza. Un singolo fornitore cloud può essere una terza parte ICT critica ai sensi di DORA, un fornitore diretto in una catena di fornitura NIS2 e un responsabile o sub-responsabile del trattamento ai sensi del GDPR. Se l’affidabilità delle evidenze è gestita tramite questionari, PDF di certificazione e cartelle contrattuali scollegati, ogni audit diventa un esercizio di ricostruzione.
EUCS può ridurre questo disordine, ma solo quando viene integrato in un modello di evidenze governato.
Cosa può dimostrare EUCS e cosa non può dimostrare
Lo schema dell’UE di certificazione della cibersicurezza per i servizi cloud, comunemente indicato come EUCS, è progettato per fornire un meccanismo europeo di affidabilità cloud nell’ambito del più ampio quadro di certificazione della cibersicurezza dell’UE. Il suo valore pratico non risiede nella sola etichetta. Il valore risiede nell’ambito del certificato sottostante, nel livello di affidabilità, nei servizi valutati, nelle regioni, nelle entità giuridiche, nei confini della valutazione, nel periodo di validità e nel modello di sorveglianza.
La domanda corretta sull’affidabilità cloud non è semplicemente: “Questo fornitore ha EUCS?”. È:
- Quali servizi cloud esatti sono coperti?
- Quali regioni, localizzazioni dei dati ed entità giuridiche sono coperte?
- Quale livello di affidabilità si applica?
- Quale metodo di valutazione è stato utilizzato?
- Quali assunzioni di responsabilità condivisa restano in capo al cliente?
- Quali evidenze possono essere comunicate a clienti, autorità di regolamentazione e auditor?
- In che modo il certificato incide su diritti di audit, notifica degli incidenti, trasparenza sui subappaltatori e pianificazione dell’uscita?
Un certificato cloud raramente copre la tua configurazione. Se l’organizzazione disabilita MFA, espone lo storage, concede privilegi amministrativi eccessivi, non registra gli accessi privilegiati o configura in modo errato le regioni, la certificazione del fornitore non salverà l’audit.
Per questo EUCS deve stare in una matrice delle evidenze, non su un piedistallo. Può supportare l’affidabilità delle evidenze lato fornitore, ma l’organizzazione deve comunque dimostrare i propri controlli di governance, configurazione, contrattuali e di monitoraggio.
Zenith Blueprint: roadmap in 30 passaggi per auditor lo chiarisce nella fase di Gestione del rischio, Passaggio 13, Pianificazione del trattamento del rischio e Dichiarazione di Applicabilità:
La SoA è di fatto un documento ponte: collega la tua valutazione/trattamento del rischio ai controlli effettivamente presenti. Completandola, verifichi anche se hai tralasciato qualche controllo.
Questo è il modello mentale corretto per EUCS. Il certificato è evidenza del fornitore. La Dichiarazione di Applicabilità spiega perché i controlli correlati sono applicabili, come l’organizzazione ha implementato la propria parte della responsabilità condivisa, quali evidenze del fornitore sono state accettate e quali rischi residui rimangono.
La dorsale ISO 27001 per le evidenze EUCS
ISO/IEC 27001:2022 offre a EUCS una collocazione. Le sue clausole richiedono alle organizzazioni di comprendere i fattori interni ed esterni, identificare le parti interessate e i requisiti, definire il campo di applicazione del SGSI, assegnare responsabilità di leadership, valutare i rischi, selezionare i controlli, mantenere una Dichiarazione di Applicabilità e migliorare continuamente.
Per l’affidabilità delle evidenze cloud, EUCS dovrebbe confluire in almeno sei artefatti del SGSI.
| Artefatto del SGSI | Come utilizzare EUCS | Domanda dell’auditor |
|---|---|---|
| Campo di applicazione del SGSI | Identificare servizi cloud, regioni, entità giuridiche, dati dei clienti e dipendenze esternalizzate | Il SGSI include le dipendenze cloud materiali e i servizi esternalizzati? |
| Registro dei rischi | Registrare rischi di indisponibilità del fornitore, configurazioni errate, localizzazione dei dati, subappaltatori e segnalazione degli incidenti | I rischi cloud sono valutati rispetto all’impatto aziendale e alla responsabilità condivisa? |
| Due diligence sui fornitori | Utilizzare EUCS come evidenza, quindi verificare ambito, livello di affidabilità, validità e lacune | Il certificato copre il servizio esatto utilizzato? |
| Dichiarazione di Applicabilità | Collegare i controlli cloud, fornitore, accesso, logging, incidenti e continuità a rischi e normative | La selezione dei controlli è giustificata e tracciabile? |
| Registro dei servizi cloud | Registrare fornitore, finalità, tipi di dati, localizzazioni, accessi e dettagli contrattuali | L’organizzazione può identificare tutti i servizi cloud approvati? |
| Fascicolo contrattuale e di audit | Conservare certificazioni, accordi, diritti di audit, termini di notifica, termini sui subappaltatori e disposizioni di uscita | L’organizzazione può dimostrare obblighi vincolanti dei fornitori? |
La libreria di policy Clarysec trasforma questi requisiti in disciplina operativa.
La Politica di utilizzo del cloud - PMI, sezione Requisiti di governance, clausola 5.2, definisce una baseline per i servizi cloud approvati:
I servizi cloud approvati devono soddisfare i seguenti criteri di baseline: 5.2.1 Il fornitore mantiene una solida reputazione in termini di disponibilità e sicurezza 5.2.2 L’autenticazione a più fattori (MFA) è supportata e può essere abilitata 5.2.3 Le pratiche di localizzazione dei dati e tutela della privacy rispettano i requisiti legali applicabili (ad es., GDPR) 5.2.4 Il servizio fornisce controlli di accesso sicuri, registrazione e capacità di protezione dei dati
Un certificato EUCS può supportare 5.2.1 ed elementi di 5.2.3 e 5.2.4. Non dimostra che nel tuo tenant MFA sia abilitata, il logging sia configurato, la localizzazione dei dati sia applicata o gli accessi amministrativi siano stati riesaminati.
Per le organizzazioni più grandi, la Politica di utilizzo del cloud Enterprise, sezione Requisiti di governance, clausola 5.2, innalza l’asticella:
Ogni utilizzo del cloud deve essere sottoposto a due diligence basata sul rischio prima dell’attivazione, includendo valutazione del fornitore, validazione della conformità legale e riesami di convalida dei controlli.
Questa frase è la posizione di policy che ogni riesame EUCS deve seguire: valutazione del fornitore, validazione della conformità legale e convalida dei controlli, non accettazione cieca.
Mappare EUCS a ISO 27001, NIS2, DORA e GDPR
EUCS diventa audit-ready quando i fatti del certificato sono mappati agli obblighi. Un CISO dovrebbe costruire una matrice di affidabilità cloud per la conformità trasversale che traduca le evidenze del fornitore in evidenze di controllo riutilizzabili.
| Elemento di evidenza EUCS | Rilevanza per ISO 27001 e ISO 27002 | Rilevanza per NIS2 | Rilevanza per DORA | Rilevanza per GDPR |
|---|---|---|---|---|
| Ambito del certificato e servizi coperti | Supporta la valutazione del rischio dei fornitori e i controlli 5.19, 5.20, 5.22 e 5.23 | Supporta la sicurezza della catena di fornitura e le evidenze di certificazione | Supporta la due diligence sul fornitore ICT e l’accuratezza del registro | Supporta la valutazione di responsabili e sub-responsabili del trattamento |
| Livello di affidabilità e metodo di valutazione | Supporta la convalida dei controlli e la giustificazione della SoA | Dimostra proporzionalità rispetto al rischio e alla criticità del servizio | Supporta la valutazione delle funzioni critiche o importanti | Supporta l’accountability per i dati personali ospitati |
| Evidenze su localizzazione dei dati e giurisdizione | Supporta la mappatura dei requisiti legali, normativi e contrattuali | Supporta la continuità del servizio e l’analisi del rischio della catena di fornitura | Supporta la valutazione del rischio di concentrazione e di subappalto | Supporta l’analisi del rischio di localizzazione e trasferimento dei dati |
| Impegni di notifica degli incidenti | Supporta la pianificazione degli incidenti e i controlli negli accordi con i fornitori | Supporta la preparazione alla segnalazione degli incidenti significativi | Supporta le dipendenze di segnalazione degli incidenti ICT rilevanti | Supporta la preparazione alla risposta alle violazioni dei dati personali |
| Evidenze su subappaltatori e catena di fornitura | Supporta il monitoraggio dei fornitori e la gestione dei cambiamenti | Supporta la valutazione delle vulnerabilità specifiche dei fornitori | Supporta l’analisi della catena di subappalto e del rischio di concentrazione | Supporta l’accountability della catena di responsabili del trattamento |
| Evidenze di uscita e restituzione dei dati | Supporta continuità, cessazione e gestione sicura dei dati | Supporta la resilienza all-hazards e la continuità | Supporta strategie di uscita testate per servizi ICT critici | Supporta evidenze di cancellazione, conservazione e limitazione del trattamento |
Questa tabella non serve solo alla documentazione di conformità. È il ponte tra l’affidabilità delle evidenze del fornitore e l’accountability dell’organizzazione.
NIS2 chiede se l’entità abbia adottato misure adeguate e proporzionate. DORA chiede se l’ente finanziario governi il rischio ICT di terze parti mediante due diligence, contratti, monitoraggio e pianificazione dell’uscita. GDPR chiede se il trattamento dei dati personali sia lecito, sicuro e dimostrabile. ISO/IEC 27001:2022 chiede se tutto questo sia integrato in un sistema di gestione basato sul rischio.
Un esempio pratico: riesaminare EUCS per un fornitore di cloud analytics
Torniamo alla fintech di Amelia, Northstar Pay. La società vuole effettuare l’onboarding di una piattaforma di cloud analytics per il rilevamento delle frodi e la reportistica sulle transazioni. Il fornitore presenta un certificato EUCS e sostiene che dovrebbe soddisfare il riesame di sicurezza.
Clarysec strutturerebbe il riesame delle evidenze in sei passaggi.
Passaggio 1: aggiornare il Registro dei servizi cloud
La Politica di utilizzo del cloud - PMI, sezione Requisiti di governance, clausola 5.3, richiede un registro che riporti nome del servizio cloud, finalità, proprietario responsabile, tipi di dati, paese o regione, autorizzazioni di accesso, account amministrativi, dettagli contrattuali, date di rinnovo e contatti di supporto.
Per le imprese, la Politica di utilizzo del cloud, sezione Requisiti di governance, clausola 5.1, parte dalla titolarità:
L’organizzazione deve mantenere un Registro dei servizi cloud centralizzato, di responsabilità del CISO, contenente:
Northstar Pay registra il servizio prima dell’approvazione, non dopo la messa in esercizio.
| Campo del registro | Voce di esempio |
|---|---|
| Servizio cloud | Piattaforma di analytics del fornitore |
| Finalità aziendale | Analisi antifrode e reportistica sui trend delle transazioni |
| Proprietario dell’applicazione | Responsabile delle piattaforme dati |
| Tipi di dati | Identificativi dei clienti, metadati delle transazioni, eventi di analytics pseudonimizzati |
| Localizzazione dei dati | Solo regione UE, con restrizione contrattuale |
| Accesso | SSO, MFA, account amministrativi nominativi, ruoli secondo il principio del privilegio minimo |
| Evidenze | Certificato EUCS, certificato ISO 27001, security whitepaper, DPA, contratto, elenco dei sub-responsabili |
| Data di riesame | Riesame annuale più riesame in caso di modifica materiale del servizio |
Passaggio 2: validare l’ambito del certificato
Il team verifica se il certificato EUCS copre l’esatto servizio di analytics, il modello di deployment, la regione e l’entità giuridica che Northstar Pay utilizzerà. Se il certificato copre servizi infrastrutturali ma esclude il modulo di analytics, il valore dell’evidenza è limitato.
È qui che molti audit falliscono. Il fornitore afferma di essere “certificato”, ma il cliente non può dimostrare che il certificato si applichi al servizio che tratta dati regolamentati.
Passaggio 3: mappare EUCS al trattamento del rischio e alla SoA
Utilizzando Zenith Blueprint, Passaggio 13, Northstar Pay mappa il certificato nel Registro dei rischi e nella Dichiarazione di Applicabilità.
| Scenario di rischio | Valore dell’evidenza EUCS | Controllo lato cliente ancora richiesto |
|---|---|---|
| Accesso non autorizzato ai dati di analytics | Supporta l’affidabilità delle evidenze sulla sicurezza dell’infrastruttura del fornitore | Applicare SSO, MFA, RBAC, riesame degli amministratori e logging |
| Dati archiviati fuori dalla regione approvata | Può supportare i controlli di localizzazione del fornitore | Archiviazione solo UE contrattualizzata, configurazione del tenant e verifica periodica |
| Ritardo del fornitore nella segnalazione degli incidenti | Può supportare l’affidabilità delle evidenze sul processo di gestione degli incidenti | Tempi contrattuali di notifica, contatti di escalation e playbook di risposta agli incidenti |
| Modifica di un sub-responsabile che incide sul rischio | Può supportare la governance della catena di fornitura | Diritti di approvazione contrattuale, monitoraggio dei sub-responsabili e rivalutazione |
| Indisponibilità cloud che incide sulla reportistica | Può supportare i controlli di disponibilità | Piano di continuità operativa, analisi RTO e RPO, strategia di backup o esportazione |
La SoA registra quindi i controlli ISO/IEC 27002:2022 5.20, 5.22 e 5.23 come applicabili perché l’organizzazione utilizza servizi cloud per trattamenti regolamentati e flussi di lavoro di analytics importanti.
Passaggio 4: confermare clausole contrattuali e diritti di audit
La Politica di sicurezza di terze parti e fornitori - PMI, sezione Requisiti di governance, clausola 5.3, richiede clausole contrattuali obbligatorie:
I contratti devono includere clausole obbligatorie che coprano: 5.3.1 Riservatezza e non divulgazione 5.3.2 Obblighi di sicurezza delle informazioni 5.3.3 Tempistiche di notifica delle violazioni dei dati (ad es., entro 24–72 ore) 5.3.4 Diritto di audit o disponibilità delle evidenze di conformità 5.3.5 Restrizioni sull’ulteriore subappalto senza approvazione 5.3.6 Termini di cessazione, inclusa la restituzione o distruzione sicura dei dati
Le evidenze EUCS e i diritti contrattuali hanno finalità diverse. Il certificato supporta l’affidabilità delle evidenze. Il contratto crea vincolatività.
La Politica di sicurezza di terze parti e fornitori Enterprise, sezione Requisiti di applicazione della policy, clausola 6.1.2.2, include esplicitamente:
Riesame dei rapporti di audit (ad es., SOC 2, ISO 27001, ISAE 3402)
EUCS appartiene a questa famiglia di evidenze, insieme ad altri rapporti di assurance. Non deve sostituire il riesame contrattuale, i diritti di audit, l’assistenza in caso di incidente o le clausole di strategia di uscita richieste da DORA.
Passaggio 5: applicare la localizzazione dei dati per i dati regolamentati
La Politica di utilizzo del cloud, sezione Requisiti di applicazione della policy, clausola 6.6.2, stabilisce:
I requisiti di localizzazione dei dati devono essere applicati contrattualmente (ad es., archiviazione solo UE per dati regolamentati dal GDPR).
Per l’accountability GDPR, un certificato che descrive controlli regionali è utile. Non è comunque sufficiente. Northstar Pay necessita dell’accordo sul trattamento dei dati, del testo contrattuale sull’archiviazione solo UE, delle evidenze di configurazione del tenant e di un metodo per monitorare le modifiche.
Se la piattaforma di analytics consente agli amministratori di selezionare le regioni, il fascicolo di audit dovrebbe includere screenshot di configurazione, impostazioni esportate o altre registrazioni che dimostrino la regione UE approvata.
Passaggio 6: pianificare riesami annuali e basati su eventi
La Politica di sicurezza di terze parti e fornitori - PMI, sezione Requisiti di applicazione della policy, clausola 6.3.1, richiede il riesame annuale dei fornitori critici o ad alto rischio per verificare metodi di accesso sicuri, certificazioni di sicurezza valide o evidenze aggiornate dei controlli, storico degli incidenti e conformità contrattuale.
Il riesame deve essere attivato anche quando il fornitore modifica subappaltatori, regioni, servizi, architettura delle identità, modello di cifratura, storico degli incidenti o stato del certificato. Le evidenze di affidabilità invecchiano e il rischio dei fornitori non è statico.
Il pacchetto di evidenze EUCS di Clarysec
Un pacchetto maturo di affidabilità EUCS contiene più del PDF del certificato. Clarysec struttura le evidenze in sette sezioni.
| Sezione delle evidenze | Contenuti | Perché è importante |
|---|---|---|
| 1. Approvazione cloud | Giustificazione aziendale, proprietario, classificazione del rischio, decisione di approvazione | Dimostra acquisizione e utilizzo controllati dei servizi cloud |
| 2. Affidabilità del fornitore | Certificato EUCS, altre certificazioni, panoramica di sicurezza, modello di responsabilità condivisa | Dimostra evidenze di sicurezza del fornitore e ambito |
| 3. Aspetti legali e privacy | DPA, termini di localizzazione dei dati, elenco dei sub-responsabili, mappatura del trattamento lecito | Supporta accountability GDPR e requisiti contrattuali |
| 4. Configurazione tecnica | MFA, SSO, RBAC, cifratura, logging, backup, restrizioni di rete | Dimostra la parte cliente della responsabilità condivisa |
| 5. Contratto del fornitore | Obblighi di sicurezza, diritti sulle evidenze di audit, notifica degli incidenti, subappalto, cessazione | Supporta la governance dei fornitori per ISO, NIS2 e DORA |
| 6. Incidenti e resilienza | Percorso di escalation del fornitore, integrazione dei playbook, RTO e RPO, registrazioni dei test | Supporta la segnalazione NIS2 e la resilienza operativa DORA |
| 7. Monitoraggio e riesame | Riesame annuale, validità del certificato, incidenti, modifiche del servizio, eccezioni | Supporta il monitoraggio continuo dei fornitori e il miglioramento continuo |
La Politica di conformità legale e normativa, sezione Requisiti di applicazione della policy, clausola 6.2.1, sintetizza il principio operativo:
Tutti gli obblighi legali e normativi devono essere mappati a politiche, controlli e proprietari specifici all’interno del Sistema di gestione della sicurezza delle informazioni (SGSI).
Questa è la differenza tra raccogliere certificati e costruire un modello operativo di conformità difendibile.
Evidenze su incidenti e resilienza: dove EUCS non basta
NIS2 e DORA rendono entrambe la preparazione a incidenti e resilienza un test serio della governance cloud.
Il certificato EUCS di un fornitore cloud può dimostrare che il fornitore dispone di controlli di gestione degli incidenti. L’organizzazione deve comunque sapere chi riceve le notifiche, come vengono triagiate le allerte, come vengono preservate le evidenze, come viene valutato l’impatto sui dati personali e chi comunica con autorità di regolamentazione, clienti e leadership interna.
Per NIS2, i termini di notifica del fornitore devono supportare gli obblighi di preallarme e notifica dell’incidente. Per DORA, gli incidenti cloud devono alimentare i processi di classificazione, escalation, segnalazione e comunicazione ai clienti relativi agli incidenti ICT. Per GDPR, il workflow di violazione deve supportare la valutazione dell’eventuale violazione dei dati personali e dell’eventuale obbligo di notifica all’autorità di controllo o agli interessati.
NIST CSF 2.0 è utile come linguaggio di integrazione in questo contesto. Le sue funzioni GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER aiutano le organizzazioni a tradurre obblighi legali e controlli tecnici in risultati operativi. I suoi outcome relativi alla catena di fornitura richiedono che i fornitori siano noti, prioritizzati, governati contrattualmente, monitorati, inclusi nella pianificazione degli incidenti e gestiti alla cessazione. Gli outcome di risposta e ripristino coprono triage, escalation, coordinamento con terze parti, notifica alle parti interessate, esecuzione del ripristino e verifica del ripristino.
Il certificato finisce nel fascicolo. Il playbook dimostra la preparazione.
Come gli auditor testeranno le evidenze EUCS
Auditor diversi affrontano l’affidabilità delle evidenze cloud da angolazioni diverse. Un modello di evidenze per la conformità trasversale evita di dover riassemblare gli stessi fatti per ogni riesame.
| Prospettiva di audit | Su cosa si concentrerà l’auditor | Evidenze attese |
|---|---|---|
| Auditor ISO 27001 | Campo di applicazione del SGSI, valutazione del rischio, SoA, controlli dei fornitori, governance cloud, miglioramento continuo | Registro dei servizi cloud, Registro dei rischi, SoA, valutazione del fornitore, contratto, registrazioni di configurazione, evidenze di riesame |
| Supervisore o valutatore NIS2 | Approvazione della direzione, misure Article 21, sicurezza della catena di fornitura, preparazione alla segnalazione degli incidenti | Reportistica al Consiglio di amministrazione, analisi del rischio dei fornitori, playbook di risposta agli incidenti, evidenze di continuità operativa, workflow di notifica |
| Auditor DORA | Registro ICT delle terze parti, valutazione delle funzioni critiche o importanti, contratti, diritti di audit, piani di uscita, test di resilienza | Registro dei contratti ICT, due diligence, analisi del rischio di concentrazione, clausole contrattuali Article 30, registrazioni dei test, strategia di uscita |
| Revisore GDPR | Accountability, finalità del trattamento, categorie di dati, localizzazione dei dati, sicurezza, preparazione alla gestione delle violazioni | Input RoPA, DPA, termini di localizzazione dei dati, controlli di accesso, workflow di valutazione della violazione, evidenze del responsabile del trattamento |
| Valutatore NIST CSF | Current and Target Profiles, governance, gestione del rischio della catena di fornitura, monitoraggio, risposta e ripristino | Analisi delle lacune dei profili, registrazioni del ciclo di vita dei fornitori, report di monitoraggio, esercitazioni sugli incidenti, convalida del ripristino |
| Auditor COBIT 2019 o ISACA | Obiettivi di governance, responsabilità della direzione, vigilanza sui prestatori di servizi, ottimizzazione del rischio, monitoraggio della conformità | Verbali di governance, titolarità dei controlli, metriche di prestazione, registrazioni di vigilanza sulle terze parti, dashboard di conformità |
Zenith Blueprint, fase Controls in Action, Passaggio 23, avverte che i controlli cloud sono esaminati con particolare attenzione:
Questo controllo è spesso oggetto di un esame approfondito. Gli auditor chiederanno:
✓ “Quali servizi cloud utilizzate?” ✓ “Chi li ha approvati?” ✓ “Come garantite la protezione dei dati?”
Queste domande sono l’essenza dell’affidabilità delle evidenze EUCS. Un certificato può aiutare a rispondere a come viene evidenziata la protezione lato fornitore, ma non può rispondere a quali servizi vengono utilizzati o chi li ha approvati se il Registro dei servizi cloud e il workflow di approvazione non sono aggiornati.
Errori comuni di affidabilità EUCS da evitare
Il primo errore è trattare EUCS come un lasciapassare universale. È un’evidenza con ambito definito. Se il certificato non copre il servizio acquistato, la regione, il modello di deployment o l’entità giuridica, il suo valore di affidabilità può essere limitato.
Il secondo errore è confondere i controlli del fornitore con i controlli del cliente. La certificazione del fornitore non dimostra MFA del tenant, RBAC, logging, impostazioni di cifratura, backup, riesami degli accessi amministrativi o monitoraggio.
Il terzo errore è trascurare i requisiti contrattuali DORA. Gli enti finanziari necessitano di diritti e obblighi scritti, inclusi descrizioni dei servizi, localizzazioni dei dati, requisiti di sicurezza delle informazioni, diritti di accesso e audit, livelli di servizio, assistenza in caso di incidente, cooperazione con le autorità, diritti di cessazione e strategie di uscita per funzioni critiche o importanti.
Il quarto errore è ignorare le evidenze GDPR. Linguaggio sulla localizzazione dei dati, trasparenza sui sub-responsabili, gestione delle violazioni, trattamento lecito e registrazioni di accountability restano necessari. EUCS può supportare le evidenze di sicurezza Article 32, ma non definisce la base giuridica, la finalità del trattamento o le regole di conservazione.
Il quinto errore è non monitorare lo stato del certificato. Se la certificazione scade, l’ambito cambia, emergono risultanze di sorveglianza o il fornitore modifica l’architettura, il riesame del rischio dei fornitori deve registrare il cambiamento.
Checklist pratica per il riesame EUCS 2026
Utilizza questa checklist prima di accettare EUCS come evidenza di affidabilità del fornitore cloud:
- Conferma lo schema di certificazione, il livello di affidabilità, il titolare del certificato e il periodo di validità.
- Conferma i servizi, le regioni, i modelli di deployment e le entità giuridiche esatti inclusi nell’ambito.
- Confronta l’ambito del certificato con la voce del Registro dei servizi cloud.
- Mappa le evidenze ai controlli ISO/IEC 27002:2022 5.20, 5.22 e 5.23.
- Aggiorna il Registro dei rischi e la SoA con le evidenze del certificato e il rischio residuo.
- Convalida i controlli lato cliente, in particolare identità, MFA, logging, cifratura, backup e accessi amministrativi.
- Conferma localizzazione dei dati, sub-responsabili, notifica delle violazioni, evidenze di audit e clausole di cessazione.
- Collega i percorsi di notifica degli incidenti alle tempistiche NIS2, DORA e GDPR.
- Riesamina il rischio di concentrazione e la strategia di uscita per i servizi critici o importanti.
- Pianifica il riesame annuale e la rivalutazione basata su eventi.
Rendere operative le evidenze EUCS nel tuo SGSI
La certificazione cloud EUCS può migliorare in modo significativo l’affidabilità delle evidenze sui fornitori cloud nel 2026. Può ridurre l’affaticamento da questionari, rafforzare la due diligence sui fornitori e supportare le evidenze ISO 27001, NIS2, DORA e GDPR. Tuttavia diventa difendibile solo quando viene mappata nel sistema di governance dell’organizzazione.
Clarysec aiuta le organizzazioni a trasformare le evidenze di certificazione cloud in operazioni di conformità pronte per l’audit tramite Zenith Blueprint, Zenith Controls, Politica di utilizzo del cloud, Politica di utilizzo del cloud - PMI, Politica di sicurezza di terze parti e fornitori - PMI, Politica di sicurezza di terze parti e fornitori e Politica di conformità legale e normativa.
Se la tua roadmap 2026 include EUCS, preparazione a NIS2, rischio ICT di terze parti DORA, trattamento cloud GDPR o certificazione ISO/IEC 27001:2022, inizia da un’azione pratica: crea il Registro dei servizi cloud, allega le evidenze di affidabilità del fornitore e mappa ogni servizio cloud critico a rischi, contratti, controlli e proprietari. È qui che l’affidabilità delle evidenze cloud diventa difendibile.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
