Procedura di valutazione dei rischi cloud: guida per responsabili IT

La procedura di valutazione dei rischi cloud si articola in diversi passaggi operativi che includono definire ambito e appetito di rischio, classificare servizi e dati, identificare minacce e vulnerabilità, analizzare probabilità e impatto, eseguire la due diligence sul fornitore cloud (CSP), definire misure di trattamento e mappare i controlli ai framework, documentare il registro dei rischi, la BIA e le evidenze, e monitorare e rivedere periodicamente. Seguire questa sequenza consente a un responsabile IT di produrre un risk assessment ripetibile, difendibile in audit e conforme a ISO 27001, ISO 27017, ISO 27018, NIST SP 800-53, CIS Benchmarks e CSA CAIQ. Per la Pubblica Amministrazione italiana, il processo si integra con i requisiti AgID e con gli orientamenti ESMA/CONSOB.

I deliverable attesi per ogni passaggio:

• Ambito e appetito di rischio: charter dell’assessment, elenco asset in-scope, nomina dei proprietari del rischio
• Classificazione servizi/dati: tabella di mapping servizio → livello di criticità (Ordinari/Critici/Strategici), output BIA preliminare
• Identificazione rischi: registro delle minacce, threat model, elenco dipendenze critiche
• Analisi probabilità/impatto: risk matrix con score inerente e residuo, soglie di escalation
• Due diligence CSP: checklist CSP compilata, certificazioni verificate (ISO 27001/27017/27018, SOC), report DR, DPA firmato
• Trattamento e mapping controlli: tabella rischio → controllo standard → azione → owner → KPI
• Documentazione: registro dei rischi completo, BIA, evidenze tecniche (audit, vulnerability scan, post-mortem)
• Monitoraggio: calendario di revisione, metriche RTO/RPO, piano di testing periodico

Punti chiave

Una procedura di valutazione dei rischi cloud efficace richiede ambito definito, classificazione dei dati per livello di criticità, scoring probabilità × impatto, due diligence documentale sul CSP e monitoraggio continuo con owner nominati.

Indice

• Come si definisce l’ambito della valutazione dei rischi cloud?
• Come classificare servizi e dati per livello di criticità
• Come identificare i rischi: minacce, vulnerabilità e dipendenze
• Come si analizzano probabilità e impatto nel risk assessment cloud?
• Come eseguire la due diligence sul fornitore cloud (CSP)
• Come mappare le misure di trattamento ai controlli standard
• Quali documenti servono per il registro dei rischi e la BIA?
• Con quale frequenza rivedere e monitorare i rischi cloud?
• Catalogo dei rischi cloud più frequenti e contromisure pratiche
• Quali strumenti e template accelerano la valutazione dei rischi cloud?
• Qualificazione AgID: cosa deve fare la PA italiana?
• Lezioni dal campo: cosa non funziona nella valutazione dei rischi cloud
• Securityhub supporta la valutazione dei rischi cloud e le certificazioni ISO
• Fonti

Come si definisce l’ambito della valutazione dei rischi cloud?

Prima di raccogliere un solo dato, occorre delimitare con precisione il perimetro dell’assessment. Un ambito mal definito produce un registro dei rischi incompleto e, in fase di audit, lacune difficili da giustificare.

Lo scope deve specificare: quali servizi cloud sono inclusi (IaaS, PaaS, SaaS), le regioni geografiche di elaborazione e archiviazione dei dati, le tipologie di dato trattate (personali, sanitari, finanziari, segreti industriali) e i modelli di deployment (pubblico, privato, ibrido). Un servizio SaaS di posta elettronica e un’infrastruttura IaaS che ospita un sistema ERP hanno profili di rischio radicalmente diversi e richiedono scope separati o sezioni distinte all’interno dello stesso assessment.

Gli stakeholder da coinvolgere fin dall’avvio:

• Sicurezza e IT: responsabile della valutazione tecnica e della raccolta delle evidenze
• Compliance e legale: verifica dei requisiti normativi, trasferimenti internazionali di dati, clausole contrattuali
• Business owner: definisce il valore degli asset e le soglie di impatto accettabili
• Procurement: gestisce i rapporti contrattuali con i CSP e le clausole di portabilità
• Direzione: approva l’appetito di rischio e le soglie di escalation

L’appetito di rischio deve essere quantificabile. Non basta dichiarare «tolleranza bassa»: occorre stabilire soglie numeriche, ad esempio uno score rischio superiore a 15 su 25 richiede approvazione del CDA, mentre uno score superiore a 20 blocca il progetto fino a trattamento. Queste soglie guidano poi la priorizzazione nella risk matrix.

Un consiglio: Prima del kickoff formale, raccogliere l’inventario degli asset cloud già esistente dal team IT e dal registro dei contratti con i fornitori. Iniziare da zero richiede settimane; aggiornare un inventario esistente richiede giorni.

Come classificare servizi e dati per livello di criticità

La classificazione è il filtro che determina quali rischi meritano trattamento prioritario e quali requisiti tecnici e contrattuali applicare a ciascun fornitore. Senza di essa, ogni rischio sembra ugualmente urgente e le risorse vengono distribuite in modo inefficace.

Il modello a tre livelli adottato dalla PA italiana, e applicabile anche al settore privato, valuta ogni servizio in base all’impatto su confidenzialità, integrità e disponibilità (CIA), alla rilevanza normativa e al valore per il business.

La Business Impact Analysis (BIA) alimenta direttamente questa classificazione: per ogni servizio, la BIA quantifica il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO) accettabili, il costo orario di indisponibilità e le conseguenze normative di una violazione. Un sistema di gestione documentale con dati sanitari classificato come «Critico» richiederà un CSP con certificazione ISO 27017 e residenza dei dati in territorio UE, mentre un sistema di videoconferenza interno potrà rimanere su un servizio SaaS standard.

Per la PA, il modello a tre livelli utilizza un questionario algoritmico che assegna punteggi in base alla natura del dato e alla criticità del servizio, producendo automaticamente il livello di qualificazione richiesto al CSP.

Come identificare i rischi: minacce, vulnerabilità e dipendenze

L’identificazione dei rischi cloud richiede un approccio strutturato al threat modeling. Il processo descritto da OWASP parte dagli asset, identifica gli attaccanti plausibili e i loro vettori, quindi verifica i controlli esistenti per determinare le lacune.

Le categorie di rischio da coprire sistematicamente:

• Errata configurazione (misconfiguration): bucket di storage pubblicamente accessibili, regole di firewall permissive, logging disabilitato. È la causa più frequente di incidenti cloud.
• Gestione delle identità e degli accessi (IAM): credenziali deboli o condivise, assenza di autenticazione a più fattori, privilegi eccessivi, account di servizio non monitorati.
• Perdita o esfiltrazione di dati: trasferimenti non autorizzati, cifratura assente o inadeguata, accessi da paesi terzi non autorizzati.
• Elevazione di privilegi: vulnerabilità nei servizi gestiti, configurazioni errate dei ruoli IAM, accesso non controllato alle API di gestione.
• Availability e concentration risk: dipendenza da una singola regione o da un unico CSP, assenza di architetture multi-region, SLA insufficienti per i livelli di criticità richiesti.
• Sub-fornitura e dipendenze di terze parti: il CSP utilizza a sua volta fornitori (CDN, DNS, storage) che possono introdurre rischi non visibili al cliente.
• Compliance e trasferimenti internazionali: dati che transitano o vengono elaborati fuori dall’UE senza adeguate garanzie (clausole contrattuali standard, decisioni di adeguatezza).

Per ogni servizio in scope, mappare le dipendenze tecniche: quali regioni cloud, quali servizi gestiti (database, code, funzioni serverless), quali integrazioni con sistemi on-premise. I punti singoli di fallimento emergono proprio da questa mappatura, non dall’analisi delle minacce in astratto.

Esempio applicato a un servizio SaaS per la PA: un’applicazione di gestione delle pratiche amministrative dipende da un database gestito in una singola regione cloud, da un servizio di autenticazione federata e da un provider CDN esterno. Se il CDN non è coperto dal contratto principale, la sua indisponibilità non è coperta dagli SLA del CSP primario. Questo è un rischio di availability non immediatamente visibile senza la mappatura delle dipendenze.

Come si analizzano probabilità e impatto nel risk assessment cloud?

Il metodo più diffuso e verificabile è lo scoring probabilità × impatto su scale numeriche. Una scala 1–5 per entrambe le dimensioni produce score da 1 a 25, sufficientemente granulare per priorizzare senza creare false precisioni.

Scale di riferimento consigliate

La BIA traduce l’impatto in termini economici, normativi e operativi. Per la PA, l’impatto normativo e di servizio pubblico deve avere peso maggiore rispetto al solo costo economico diretto: un’interruzione di un servizio anagrafico ha conseguenze sui cittadini che vanno ben oltre il costo IT.

Il rischio inerente è lo score prima dell’applicazione dei controlli. Il rischio residuo è lo score dopo. La differenza misura l’efficacia dei controlli esistenti. Se un rischio di configurazione errata ha score inerente 20 (probabilità 4, impatto 5) e i controlli attuali lo riducono a 12 (probabilità 3, impatto 4), il rischio residuo rimane sopra la soglia di escalation e richiede trattamento aggiuntivo.

Per ogni rischio nel registro, raccogliere: identificativo univoco, descrizione, asset coinvolto, probabilità (con giustificazione), impatto (con giustificazione), score inerente, controlli esistenti, score residuo, owner del rischio, piano di trattamento, evidenze a supporto, stato e data di revisione.

Come eseguire la due diligence sul fornitore cloud (CSP)

La due diligence sul CSP non si esaurisce nella verifica delle certificazioni. Gli orientamenti ESMA raccomandano una valutazione proporzionata alla criticità della funzione esternalizzata, che include rischi operativi, normativi, di trasferimento dei dati e di concentrazione.

Checklist di verifica documentale da richiedere al CSP:

• Certificazioni attive: ISO 27001 (obbligatoria), ISO 27017 (per servizi cloud), ISO 27018 (per dati personali nel cloud); verificare la data di scadenza e l’ente di certificazione
• Report di audit esterni: SOC 2 Type II o equivalenti; richiedere il report completo, non solo la lettera di attestazione
• Test DR documentati: frequenza, scenari testati, RTO/RPO effettivamente raggiunti, post-mortem degli ultimi 12 mesi
• Data Processing Agreement (DPA): conforme al GDPR, con indicazione esplicita delle sub-elaborazioni e dei paesi di trasferimento
• SLA dettagliati: uptime garantito per livello di servizio, penali per mancato rispetto, procedure di escalation
• Politiche di sub-contracting: elenco dei sub-fornitori, meccanismi di notifica in caso di variazioni, responsabilità contrattuali a cascata
• Portabilità dei dati: formati di esportazione supportati, tempi di consegna, costi di uscita, procedure di cancellazione certificata
• Gestione degli incidenti: tempi di notifica (GDPR richiede 72 ore), procedure di comunicazione, accesso ai log per il cliente

Il concentration risk merita attenzione specifica: dipendere da un unico CSP per servizi critici espone l’organizzazione a rischi di discontinuità che nessun SLA può eliminare completamente. Valutare strategie multi-cloud o architetture ibride per i servizi classificati come Critici o Strategici.

Un consiglio: Richiedere sempre il post-mortem dell’ultimo incidente significativo e i risultati del test DR più recente con i valori effettivi di RTO e RPO raggiunti. Un CSP che non fornisce questi documenti o li fornisce solo in forma aggregata e anonimizzata non offre garanzie verificabili sulla propria capacità di recovery.

Come mappare le misure di trattamento ai controlli standard

Una volta priorizzati i rischi, ogni trattamento deve essere collegato a un controllo specifico di un framework riconosciuto. Questo collegamento rende il risk assessment verificabile in audit e dimostra la conformità agli standard dichiarati.

I framework di riferimento e il loro utilizzo pratico:

• ISO 27001 Annex A: fornisce i controlli di base per un ISMS; ogni rischio identificato deve trovare corrispondenza in uno o più controlli dell’Annex A
• ISO 27017: aggiunge controlli specifici per il cloud, sia per i CSP sia per i clienti; particolarmente rilevante per la gestione delle responsabilità condivise
• ISO 27018: controlli per la protezione dei dati personali nel cloud; obbligatorio per servizi che trattano dati di persone fisiche
• NIST SP 800-53: catalogo esteso di controlli tecnici e procedurali; utile per mapping dettagliato in contesti enterprise e per la PA
• CIS Benchmarks: configurazioni di hardening specifiche per piattaforme cloud (AWS, Azure, GCP); traducono i controlli in impostazioni tecniche verificabili
• CSA Cloud Controls Matrix: framework specifico per il cloud con mapping incrociato a ISO, NIST e altri standard; il CAIQ è lo strumento di self-assessment corrispondente

Tabella di mapping rischio → controllo → azione → owner → KPI:

Quando il CSP implementa un controllo in modo diverso da quanto previsto dallo standard (ad esempio, la gestione delle chiavi crittografiche è delegata al CSP anziché al cliente), documentare il controllo compensativo e verificare che il livello di protezione equivalente sia dimostrabile con evidenze.

Quali documenti servono per il registro dei rischi e la BIA?

Il registro dei rischi è il documento centrale dell’assessment: dev’essere strutturato in modo da rispondere alle domande di un auditor senza richiedere spiegazioni aggiuntive. I campi minimi per ogni voce:

• ID univoco del rischio (es. CR-001, CR-002)
• Descrizione del rischio in linguaggio chiaro e non ambiguo
• Asset coinvolto (servizio cloud, tipologia di dato, sistema)
• Probabilità (valore 1–5 con giustificazione)
• Impatto (valore 1–5 con giustificazione per dimensione CIA)
• Score inerente (probabilità × impatto)
• Controlli esistenti con riferimento al framework
• Score residuo dopo i controlli
• Owner del rischio (persona nominata, non solo ruolo)
• Piano di trattamento con azioni, scadenze e responsabili
• Evidenze a supporto (link o riferimento al documento)
• Stato (aperto, in trattamento, accettato, chiuso)
• Data di ultima revisione e prossima revisione pianificata

La BIA produce output distinti ma collegati al registro: per ogni servizio critico, documenta RTO e RPO accettabili, il costo orario di indisponibilità, le dipendenze tecniche e le procedure di ripristino. La BIA deve essere aggiornata ogni volta che un servizio cambia classificazione o che le dipendenze tecniche si modificano significativamente.

Le evidenze tecniche da raccogliere e conservare:

• Certificati ISO attivi con data di scadenza e ente certificatore
• Report SOC 2 Type II degli ultimi 12 mesi
• Risultati dei test DR con valori effettivi di RTO/RPO
• Post-mortem degli incidenti rilevanti degli ultimi 24 mesi
• Report di vulnerability scan con data, scope e stato delle remediation
• Log di accesso ai sistemi critici (conservazione minima 12 mesi per GDPR)
• Verbali di audit interno e relative azioni correttive

Per la PA e per le organizzazioni soggette a verifica AgID, conservare le evidenze in formato non modificabile e con marca temporale. Le richieste di verifica possono arrivare con preavviso breve: un archivio ordinato per categoria e per data riduce significativamente i tempi di risposta.

Con quale frequenza rivedere e monitorare i rischi cloud?

Il monitoraggio continuo non è un’attività opzionale: i rischi cloud cambiano ogni volta che un CSP aggiorna la propria infrastruttura, ogni volta che si aggiunge un nuovo servizio e ogni volta che il contesto normativo evolve. Un registro dei rischi aggiornato una volta all’anno è già obsoleto.

Attività di monitoraggio e frequenze consigliate:

• Vulnerability scan automatici: settimanali per ambienti di produzione, mensili per ambienti di sviluppo
• Penetration test: almeno annuale, con scope che include le interfacce cloud e le API esposte
• Tabletop DR: semestrale per servizi Critici, annuale per servizi Ordinari; documentare sempre i risultati e le azioni correttive
• Revisione BIA: annuale o a ogni cambiamento critico (nuovo servizio, cambio CSP, modifica normativa)
• Verifica SLA e report di controllo esterni: trimestrale; confrontare i valori effettivi con quelli contrattuali
• Revisione del registro dei rischi: trimestrale a livello operativo, annuale a livello strategico con approvazione della direzione

Metriche e KPI da tracciare:

• RTO effettivo vs. RTO contrattuale: misura la capacità reale di recovery
• Percentuale di controlli efficaci: numero di controlli verificati come attivi / totale controlli pianificati
• Numero di incidenti rilevanti per trimestre: trend in diminuzione indica miglioramento del profilo di rischio
• Tempo medio di chiusura delle remediation: obiettivo ≤ 5 giorni lavorativi per vulnerabilità critiche

La valutazione del rischio cloud secondo il Cloud Adoption Framework di Microsoft raccomanda di integrare il monitoraggio dei rischi nel ciclo di governance continua, non come attività separata dall’operatività quotidiana.

Ogni rischio nel registro deve avere un owner nominato con responsabilità esplicita sul monitoraggio. La mancanza di owner è la causa più comune di rischi che rimangono aperti indefinitamente senza trattamento.

Catalogo dei rischi cloud più frequenti e contromisure pratiche

I rischi elencati di seguito coprono la grande maggioranza degli incidenti cloud documentati. Per ciascuno, il controllo raccomandato e l’azione di mitigazione immediata.

• Errata configurazione (misconfiguration): bucket di storage con accesso pubblico non intenzionale, porte aperte non necessarie, logging disabilitato. Controllo: CIS Benchmark per la piattaforma specifica. Azione: scansione automatica con strumenti come Microsoft Defender for Cloud o equivalenti; remediation entro 24 ore per configurazioni critiche. Verifica: report settimanale di conformità alle baseline CIS.

• Credenziali compromesse: password deboli, assenza di MFA, credenziali hard-coded nel codice sorgente. Controllo: ISO 27001 A.9 / NIST AC-2. Azione: MFA obbligatorio per tutti gli account, rotazione automatica delle credenziali di servizio, scansione del codice sorgente per secret esposti. Verifica: alert automatico su accessi anomali.

• Controllo accessi debole (IAM): privilegi eccessivi, account di servizio con permessi amministrativi, assenza di revisione periodica dei diritti. Controllo: principio del minimo privilegio (ISO 27001 A.9.2). Azione: revisione trimestrale dei diritti IAM, implementazione di ruoli granulari, eliminazione degli account inattivi. Verifica: report di accesso mensile.

• Esfiltrazione dati: trasferimento non autorizzato verso destinazioni esterne, accesso da paesi terzi senza garanzie adeguate. Controllo: ISO 27018 / NIST SC-28. Azione: cifratura at-rest e in-transit, Data Loss Prevention (DLP), monitoraggio dei trasferimenti verso destinazioni non autorizzate. Verifica: alert su trasferimenti anomali.

• Interruzione del servizio (availability): indisponibilità del CSP, guasto di una singola regione, attacco DDoS. Controllo: ISO 27001 / NIST CP-9. Azione: architettura multi-region per servizi Critici, test DR semestrale, SLA con penali verificabili. Verifica: RTO effettivo misurato in ogni test DR.

• Esposizione API non protette: API di gestione accessibili senza autenticazione forte, endpoint non documentati, assenza di rate limiting. Controllo: NIST SC-8 / CIS API Security. Azione: autenticazione OAuth 2.0 o equivalente, inventario completo delle API esposte, test di sicurezza API trimestrale. Verifica: nessun endpoint non autenticato in produzione.

• Errori di configurazione dello storage: versioning disabilitato, assenza di backup automatico, policy di retention non configurate. Controllo: ISO 27001 A.12.3. Azione: abilitare versioning e backup automatico, definire policy di retention per tipologia di dato, test di ripristino mensile. Verifica: log di backup con esito positivo.

Quali strumenti e template accelerano la valutazione dei rischi cloud?

Gli strumenti disponibili riducono il lavoro di mapping e raccolta dati, ma non sostituiscono la verifica manuale delle evidenze. Ogni output automatico va validato contro la documentazione reale del CSP.

• Microsoft Purview Compliance Manager: fornisce una valutazione della conformità rispetto a framework come ISO 27001, NIST e GDPR per ambienti Microsoft Azure. Genera automaticamente un punteggio di conformità e suggerisce azioni di miglioramento. Limite: copre solo l’ecosistema Microsoft; richiede integrazione manuale per CSP diversi. La guida di assurance Microsoft descrive come utilizzarlo nel contesto di un risk assessment strutturato.

• CSA CAIQ (Consensus Assessments Initiative Questionnaire): questionario standardizzato da sottoporre al CSP per raccogliere informazioni sui controlli implementati, mappato alla Cloud Controls Matrix. Accelera la due diligence perché molti CSP hanno già una risposta CAIQ disponibile. Verificare sempre che le risposte siano aggiornate e supportate da evidenze.

• NIST SP 800-53 mapping tools: il NIST fornisce strumenti di ricerca e mapping dei controlli che permettono di collegare i rischi identificati ai controlli specifici del catalogo. Utile per costruire la tabella di mapping rischio → controllo.

• CIS Benchmarks: disponibili per le principali piattaforme cloud (Azure, AWS, GCP); forniscono configurazioni di hardening specifiche e verificabili. Usarli come baseline per la scansione delle configurazioni e come riferimento per i controlli compensativi.

• Template BIA e checklist AgID: AgID mette a disposizione modelli e linee guida per la classificazione dei servizi e la preparazione della documentazione di qualificazione. La checklist ISO 27017 di Securityhub offre un riferimento pratico per la verifica dei controlli cloud.

• Modelli di registro dei rischi: disponibili nei framework ISO e NIST; adattarli aggiungendo i campi specifici per il cloud (regione, modello di servizio, dipendenze CSP, SLA applicabile).

Un consiglio: Usare il CAIQ come punto di partenza per la due diligence, ma richiedere sempre le evidenze documentali a supporto delle risposte. Un CAIQ compilato senza allegati non è verificabile e non soddisfa i requisiti di audit.

Qualificazione AgID: cosa deve fare la PA italiana?

Per la Pubblica Amministrazione italiana, la procedura di valutazione dei rischi cloud si integra direttamente con il processo di qualificazione AgID. Le Circolari AgID definiscono tre fasi: richiesta di qualificazione, conseguimento e mantenimento. Ogni fase richiede documentazione specifica inviata telematicamente sul portale di qualificazione.

Il modello a tre livelli (Ordinari, Critici, Strategici) determina i requisiti tecnici minimi che il CSP deve soddisfare per ospitare i dati e i servizi della PA. La classificazione avviene tramite un questionario algoritmico che assegna punteggi in base alla natura del dato e alla criticità del servizio per la continuità dell’azione amministrativa.

Requisiti tecnici frequentemente richiesti per la qualificazione:

• ISO 27001 estesa a ISO 27017 e ISO 27018 per servizi che trattano dati personali
• Test DR documentati con valori effettivi di RTO e RPO
• Processi formali di change management, configuration management, incident management e problem management
• Residenza dei dati in territorio UE per dati Critici e Strategici
• Audit trail completo degli accessi ai dati della PA

Tabella dei requisiti per livello di qualificazione AgID:

Checklist operativa per la sottomissione AgID:

• Compilare il questionario di classificazione per ogni servizio da qualificare
• Allegare certificati ISO attivi con data di scadenza e ente certificatore
• Fornire il report del test DR più recente con valori effettivi
• Allegare il DPA e l’elenco dei sub-fornitori
• Documentare i processi di change, incident e problem management con evidenze operative
• Indicare le procedure di portabilità e cancellazione dei dati

Le evidenze che accelerano la valutazione sono quelle operative: un post-mortem dettagliato di un incidente gestito correttamente dimostra la maturità dei processi meglio di qualsiasi dichiarazione formale.

Lezioni dal campo: cosa non funziona nella valutazione dei rischi cloud

La maggior parte dei risk assessment cloud fallisce non per mancanza di metodologia, ma per tre errori ricorrenti che si ripetono indipendentemente dalla dimensione dell’organizzazione.

Il primo è lo scope troppo ampio. Includere tutti i servizi cloud dell’organizzazione in un unico assessment produce un documento di centinaia di pagine che nessuno legge e che diventa obsoleto prima di essere completato. La soluzione è segmentare per livello di criticità e completare prima l’assessment dei servizi Critici e Strategici, poi estendere agli Ordinari.

Un rischio senza un proprietario identificato per nome rimane aperto indefinitamente. Nominare il ruolo non basta: occorre una persona specifica con responsabilità documentata e con obiettivi di performance collegati alla chiusura dei rischi aperti. Coinvolgere il management nella nomina degli owner prima del kickoff, non dopo.

Il terzo è ignorare la portabilità dei dati e la sub-fornitura. Molte organizzazioni verificano le certificazioni del CSP primario e si fermano lì. I dati critici spesso transitano attraverso sub-fornitori non nominati esplicitamente nel contratto principale. Richiedere l’elenco completo dei sub-fornitori e verificare che le garanzie contrattuali si estendano a cascata è un passaggio che la maggior parte degli assessment salta.

Sul fronte delle tempistiche: un assessment completo per un’organizzazione di medie dimensioni con 5–10 servizi cloud richiede 6–10 settimane con un team di 3–4 persone (un responsabile della sicurezza, un esperto tecnico cloud, un referente legale/compliance e un business owner). Presentare i risultati al board richiede un executive summary di non più di 3 pagine con i rischi priorizzati, i costi stimati del trattamento e le scadenze. I dettagli tecnici appartengono agli allegati, non alla presentazione principale.

Securityhub supporta la valutazione dei rischi cloud e le certificazioni ISO

Securityhub affianca le organizzazioni italiane nell’intera procedura di valutazione dei rischi cloud: dalla gap analysis iniziale rispetto a ISO 27001, ISO 27017 e ISO 27018, fino alla redazione del registro dei rischi, della BIA e delle evidenze richieste per la qualificazione AgID. Il vantaggio concreto rispetto a un approccio interno è la disponibilità immediata di template validati, metodologie testate e competenza specifica sulle richieste degli enti di certificazione italiani.

I deliverable tipici di un engagement con Securityhub includono: il registro dei rischi completo con scoring e owner, la tabella di mapping ai controlli ISO/NIST/CIS, la checklist CSP compilata con le evidenze raccolte, e il piano di trattamento con scadenze e KPI. Per le PA, il supporto copre anche la preparazione della documentazione per il portale di qualificazione AgID.

Per avviare il percorso di certificazione ISO 27001 o per approfondire i requisiti specifici di ISO 27017 per i servizi cloud, contattare Securityhub direttamente tramite il sito per ricevere una valutazione preliminare del contesto e un’indicazione dei tempi e dei costi.

Fonti

Le fonti elencate di seguito sono quelle citate nel testo e rappresentano i riferimenti primari per approfondire la procedura di valutazione dei rischi cloud.

• Guida alla qualificazione dei servizi cloud (AgID)
• La classificazione dei dati e dei servizi della PA e la qualificazione dei servizi cloud
• Assurance and risk assessment guide – Microsoft Learn
• NIST SP 800-53 controls release search
• Cloud Controls Matrix (CSA)
• OWASP Threat Modeling Process
• Valutare i rischi per il cloud – Cloud Adoption Framework (Microsoft)

Raccomandati

• Processo policy sicurezza cloud: guida completa alla gestione – Security Hub
• Step by step ISO 27017: guida pratica per aziende cloud – Security Hub
• Checklist certificazione ISO 27017: guida pratica completa – Security Hub
• Checklist sicurezza dati cloud: guida operativa per PMI italiane – Security Hub