Servizi cloud secondo ISO 27001: criteri di selezione e controlli per l'integrazione nell'ISMS

Molte imprese oggi si trovano nella stessa tensione: i servizi cloud promettono velocità e scalabilità, l’ISMS richiede tracciabilità, esercizio controllato e responsabilità chiare. È proprio qui che il tema centrale Cloud-Services sotto ISO 27001 diventa rilevante nella pratica. Non perché la norma renda la „cloud“ di per sé più difficile, ma perché richiede di identificare sistematicamente i rischi, implementare efficacemente i controlli e documentare il tutto in modo verificabile per gli audit. Sembra carta – ma in cloud si traduce rapidamente in questioni operative concrete: chi può fare cosa? Dove risiedono i dati? Come vengono registrati i log? Come reagiamo agli incidenti? E come usciamo, se necessario?

Questo contributo fornisce una logica solida di selezione e integrazione: criteri decisionali per l’approvvigionamento, controlli concreti per l’integrazione nell’ISMS, prospettive tipiche di audit e indicazioni di attuazione dal punto di vista operativo. Il focus è su IaaS/PaaS/SaaS, cioè servizi di infrastruttura, piattaforma e applicazione dalla cloud – ciascuno con conseguenze per governance, amministrazione e sicurezza.

Cloud-Services sotto ISO 27001 nella pratica

Negli audit e nelle revisioni interne emergono schemi ricorrenti che non dipendono da singole configurazioni, ma da interfacce poco chiare tra provider e cliente:

• Responsabilità poco chiare: il Shared Responsibility Model (modello di responsabilità condivisa tra provider e cliente) non viene nella pratica tradotto in compiti, ruoli e evidenze.
• Scope troppo generico: „Usiamo la cloud“ non sostituisce la delimitazione del perimetro. Senza mappa dei servizi, flussi di dati e dipendenze, la gestione del rischio diventa casuale.
• Selezione del vendor senza clausole di sicurezza: acquisti e business privilegiano le funzionalità, IT/Security intervengono troppo tardi. Risultato: SLA senza metriche di sicurezza, mancanza di diritti di audit, subfornitori non chiari.
• Assenza di design del logging: i log esistono, ma non sono centralizzati, non sono correlati, mancano regole di retention e responsabilità. In caso di incidente risulta allora „nulla dimostrabile“.
• Nessun piano di exit: in cloud il lock-in raramente è „solo prezzo“. Si tratta di formati dati, accoppiamenti IAM, servizi proprietari e assenza di percorsi di migrazione.

ISO 27001 non impone il controllo massimo, ma un controllo adeguato e giustificato. Il passo decisivo è quindi trattare i Cloud-Services come una relazione con un fornitore più una piattaforma operativa critica – con controlli tecnici verificabili.

Inquadramento: ISO 27001, Allegato A e cosa cambia con la „cloud“

ISO 27001 richiede un sistema di gestione della sicurezza delle informazioni (ISMS) con approccio basato sul rischio, efficacia misurabile e miglioramento continuo. L’Allegato A (obiettivi di controllo/controlli, ristrutturato in ISO/IEC 27001:2022) è uno strumento, non un catalogo obbligatorio „sempre tutto“. In cloud l’implementazione si sposta:

• I controlli diventano più contrattuali e processuali (p.es. gestione dei fornitori, evidenze per gli audit, trasparenza sui subfornitori).
• I controlli diventano più guidati dalla configurazione (p.es. IAM, crittografia, segmentazione di rete), perché si controlla meno a livello „fisico“.
• Le evidenze diventano più data-driven (p.es. estratti di log, esportazioni di configurazioni, record di change), perché le checklist tradizionali per server non sono più adatte.

Nella pratica è utile la classificazione per modello di servizio: con SaaS controllate soprattutto identità, autorizzazioni, dati, integrazioni e gestione dei fornitori. Con PaaS si aggiungono impostazioni della piattaforma, controlli di rete e di runtime. Con IaaS sostenete responsabilità nettamente maggiori per i sistemi operativi, l’hardening, il patching e l’architettura di rete.

Criteri di selezione: come verificare i servizi cloud prima dell’acquisto

Dal punto di vista ISMS, la fase di selezione è il momento più favorevole per incorporare sicurezza e capacità di audit. In seguito ogni lacuna diventa costosa: integrazioni contrattuali, workaround, shadow-IT o strumenti aggiuntivi.

1) Scope-Fit e flussi di dati: cosa esattamente deve andare nel cloud?

Non partite dalle feature, ma dai valori informativi: quali tipologie di dati elabora il servizio (dati personali, riservati, critici per l’esercizio)? A quali sistemi è connesso (ERP, IAM, e‑mail, ticketing)? Un servizio che esporta e distribuisce dati richiede controlli diversi rispetto a uno strumento isolato.

Prova minima pratica: scheda del servizio con scopo, categorie di dati, interfacce, gruppi di utenti, dipendenze critiche e finestre operative. Questo sarà poi il ponte verso la valutazione del rischio, lo Statement of Applicability (SoA) e gli audit interni.

2) Tradurre il Shared Responsibility Model in compiti

Molti provider descrivono la responsabilità condivisa. Per il vostro ISMS ciò non è sufficiente finché non viene convertita in compiti concreti: chi configura l’MFA? chi verifica i log? chi è responsabile delle chiavi? chi applica le patch (in caso di IaaS)?

Si è dimostrata efficace una RACI-Matrix (Responsible, Accountable, Consulted, Informed) per ciascuna area di controllo. Determinante è il ruolo «Accountable»: una funzione interna che, all’occorrenza, assume la responsabilità di fronte ad auditor e al management.

3) Idoneità del fornitore: evidenze, diritti di audit, subappaltatori

ISO 27001 tratta esplicitamente la gestione dei fornitori. Per il cloud questo significa: servono informazioni affidabili sulle misure di sicurezza, sui subprocessori/subappaltatori, sulle questioni di sede/area geografica e sulle procedure di notifica per gli eventi di sicurezza. Verificate in particolare:

• Strategia di audit e di evidenza: ricevete rapporti/evidenze adeguate (p. es. report di verifica indipendenti) e sono sufficienti per il vostro ambito?
• Trasparenza sui subappaltatori: i subfornitori sono dichiarati, le modifiche comunicate e c’è un diritto di opposizione?
• Canali e termini di segnalazione: notifica degli incidenti di sicurezza, referenti, contatto 24/7, contenuti minimi della segnalazione.
• Continuità del servizio: disponibilità, finestre di manutenzione, processi di emergenza, backup/RESTore (spesso il punto critico nei SaaS).

Se desiderate approfondire i rischi dei fornitori: pianificate internamente un collegamento al vostro contributo sulla gestione dei fornitori (clausole contrattuali, criteri tecnici di verifica, processo di onboarding).

4) Capacità di integrazione tecnica: IAM, Logging, rete, chiavi

Un servizio cloud non è ‚uno strumento‘, ma parte della vostra architettura di sicurezza. Pertanto verificate in anticipo i punti di integrazione:

• Integrazione IAM: SSO (Single Sign-On), SCIM (provisioning/deprovisioning automatizzato), modello di ruoli, supporto per MFA e Conditional Access.
• Logging: esportazione nel vostro logging centrale/SIEM, dettagli dei log (azioni amministrative, autenticazione, accessi ai dati), conservazione, coerenza dei timestamp.
• Rete e accesso: Private Endpoints, RESTrizioni IP, separazione dei tenant, accesso API, rate limits.
• Crittografia/Key Management: crittografia at REST/in transit, chiavi del cliente (BYOK/CMK), rotazione, opzioni HSM, accesso alle chiavi da parte del provider.

Questi aspetti non sono ’nice to have‘. Determinano se i controlli in esercizio siano sostenibili e verificabili o se dovrete continuamente intervenire manualmente.

5) Conseguenze sui costi e sull’esercizio: la sicurezza è anche un onere ricorrente

I costi cloud sono spesso intesi come tariffe di utilizzo. Tuttavia, i costi aggiuntivi rilevanti per ISO 27001 si collocano regolarmente in:

• Gestione delle identità (SSO, mantenimento dei ruoli, ricertificazione delle autorizzazioni)
• Logging/Monitoring (volume dati, licenze SIEM, conservazione)
• Gestione di chiavi e certificati (HSM/Key Vault, rotazione, processi)
• Sforzo per audit e dimostrazione (revisioni dei fornitori, assessment annuali, audit interni)
• Prontezza all’uscita (esportazione dati, test di migrazione, funzionamento in parallelo)

Un dossier decisionale chiaro indica esplicitamente questi costi consequenziali, affinché le misure di sicurezza non partano ’sottofinanziate‘.

Controlli per l’integrazione nell’ISMS: famiglie di controllo pragmatiche

Invece di memorizzare singoli numeri dell’Annex A, per l’implementazione è più utile strutturare i controlli cloud in famiglie di controllo. Ogni famiglia dovrebbe fornire tre elementi: (1) regola/policy, (2) implementazione tecnica, (3) evidenza verificabile.

Cloud-Governance: Policies, Rollen, Entscheidungswege

Senza governance la cloud security si riduce a decisioni ad hoc. Al minimo dovRESTe definire:

• Processo di onboarding dei servizi cloud (chi approva, quali passaggi di verifica, quali requisiti minimi)
• Modello di ruoli (Service Owner, Information Owner, responsabili ISMS, team operativo/piattaforma, protezione dei dati)
• Change management (modifiche di configurazione, autorizzazioni, integrazioni; approvazioni e documentazione)
• Gestione delle eccezioni (accettazione del rischio con scadenza, misure compensative, data di revisione)

Prospettiva dell’audit: gli auditor cercano meno la ‚policy perfetta‘ e più evidenze che le decisioni siano prese in modo coerente, basato sul rischio e ripetibile.

Gestione degli asset e dei dati: classificazione, residenza dei dati, ciclo di vita

In cloud la classificazione dei dati è l’ancora: determina quali controlli sono obbligatori (es. crittografia, RESTrizioni di accesso, DLP). Stabilite:

• Classi di dati (es. pubblico, interno, confidenziale, strettamente confidenziale) e esempi chiari.
• Utilizzo cloud consentito per classe (quali categorie di servizi sono consentite, quali regioni/sedi).

Importante nella pratica: nel SaaS la «cancellazione» è spesso un processo (Soft Delete, Retention, Backups). Il vostro ISMS deve rappresentare e valutare questa realtà, non idealizzarla.

Identitäts- und Zugriffsmanagement (IAM): der häufigste Cloud-Audit-Fund

IAM è nei progetti cloud l’area con il maggior numero di finding, perché cresce rapidamente e dipende dai reparti. Controlli minimi:

• SSO und MFA per tutti gli account privilegiati, possibilmente per tutti gli utenti.
• Least Privilege (privilegi minimi necessari) e ruoli invece di diritti speciali individuali.
• Joiner/Mover/Leaver: provisioning/deprovisioning automatizzati, idealmente con SCIM.
• Regelmäßige Rezertifizierung delle autorizzazioni (chi verifica, come viene documentato, quale frequenza in base al rischio).
• Break-Glass-Accounts: accessi di emergenza con forte protezione, monitoraggio separato e utilizzo documentato.

Prove che gli auditor accettano: esportazione dei ruoli, stato MFA, log delle ricertificazioni, ticket/changes per le modifiche ai ruoli, registrazione delle azioni amministrative.

Verschlüsselung und Schlüsselmanagement: von „Häkchen“ zu kontrollierter Praxis

«Crittografia attiva» non è un controllo finché gli accessi alle chiavi, la rotazione e le responsabilità non sono chiari. Per i servizi cloud dovRESTe definire:

• Verschlüsselung in Transit: standard TLS, gestione dei certificati, nessun protocollo insicuro.
• Verschlüsselung at REST: crittografia standard, eventualmente chiavi gestite dal cliente (Customer Managed Keys).
• Key Lifecycle: rotazione, accesso (chi può gestire le chiavi), separazione dei compiti (Separation of Duties).
• Backups und Exporte: crittografia anche al di fuori della piattaforma, in particolare per gli export dei dati.

Conseguenza pratica: se scegliete BYOK/CMK, dovete poter gestire l’operatività necessaria (processi, monitoring, accesso d’emergenza). Senza questa capacità, le «chiavi proprie» sono spesso solo un controllo apparente.

Logging, Monitoring e Detection: auditabile invece di „potremmo“

Nel cloud è quindi necessario chiarire:

• Quali eventi vengono loggati? Autenticazione, azioni amministrative, modifiche alle policy, esportazioni di dati, chiamate API, errori/anomalie.
• Dove finiscono i log? Centralizzati, protetti da manomissione (scrittura una sola volta/archiviazione immutabile, ove possibile), con conservazione definita.
• Chi reagisce? Responsabilità, vie di allarme, reperibilità/sostituzione, runbook.

Un errore pratico comune è „troppo logging senza piano“. Meglio un profilo di logging basato sul rischio per classe di servizio più un set minimo sempre attivo (in particolare eventi admin e IAM).

Beispiel: Minimaler Audit-Nachweis-Ordner je Cloud-Service (Strukturvorschlag)
01_Scheda_servizio.pdf
02_Analisi_dei_rischi_e_trattamento_dei_rischi.pdf
03_SoA_Assegnazione_Controlli.pdf
04_Contratto_e_allegato_sicurezza.pdf
05_RACI_e_modello_operativo.pdf
06_IAM_Esportazione_ruoli_Prove_MFA/
07_Prove_Logging_Forwarding/
08_Record_modifiche_e_eccezioni/
09_Runbook_incidenti_e_test/
10_Piano_di_exit_e_test_di_export/

Gestione delle vulnerabilità e patch: varia a seconda del modello di servizio

Qui SaaS e IaaS si distinguono chiaramente:

• SaaS: il provider applica patch alla piattaforma e all’applicazione. I controlli di vostra competenza riguardano configurazione, IAM, integrazioni, endpoint e la valutazione delle informazioni su release/modifiche fornite dal provider.
• PaaS: il provider patcha i servizi di base; voi potete dover patchare runtime e dipendenze nella vostra applicazione. Importanti sono le policy sulle versioni supportate e sui deployment.
• IaaS: voi patchate sistemi operativi e applicazioni. Si tratta del classico programma di patching e hardening, con tool specifici per il cloud.

Prospettiva di audit: si verifica se le responsabilità sono chiare, se viene effettuata la valutazione delle vulnerabilità e se esiste una procedura per applicare tempestivamente gli aggiornamenti critici o per mitigarli.

Backup, RESTore e Business Continuity: RTO/RPO e ripristino reale

Nei progetti cloud la disponibilità viene spesso confusa con „il provider è altamente disponibile“. Per l’ISMS contano però i requisiti di business. Definire:

• RTO/RPO (Recovery Time Objective/Recovery Point Objective): con quale rapidità e con quale perdita di dati è accettabile tornare operativi?
• Ambito del backup: configurazioni (IAM, policy), dati, materiale chiave (dove consentito), configurazioni di integrazione.
• Test di RESTore: frequenza, criteri di successo, registrazioni. Senza test, il backup è debole in fase di audit.

Nel SaaS il punto critico è spesso: quali possibilità di esportazione esistono? Quanto rapidamente si riescono a ottenere i dati in emergenza? Quali dipendenze da gestione delle identità o posta elettronica impediscono l’accesso?

Incident Management e Forensics: cosa cambia nel cloud

La risposta agli incidenti nel cloud riguarda soprattutto l’accesso alle evidenze e la coordinazione. Stabilire per ogni servizio:

• Vie di contatto con il provider (security hotline, priorità ticket, escalation).
• Preservazione delle prove: quali log, snapshot o esportazioni sono possibili? Quale conservazione è attiva?
• Ruoli: chi conduce, chi decide su spegnimento/isolamento, chi comunica internamente/esternamente?

Una prova verificabile è un Runbook testato (una esercitazione tabletop è sufficiente all’inizio), incluse le lezioni apprese e il tracciamento delle azioni.

Gestione delle modifiche e delle configurazioni: conforme al cloud, non incentrata sui server

ISO 27001 richiede modifiche controllate. Nel cloud ciò significa: le modifiche avvengono frequentemente nelle configurazioni, nelle policy e nei ruoli. Buoni controlli sono:

• Configurazioni di baseline per classe di servizio (p. es. MFA attivata, logging attivo, ruoli admin limitati).
• Change-Records per modifiche rilevanti per la sicurezza (autorizzazioni, rete, chiavi, logging).
• Revisioni periodiche delle configurazioni e gestione delle deviazioni.

Se utilizzate Infrastructure as Code (IaC): supporta la tracciabilità, ma non è una soluzione automatica. Determinante è il processo: review, approvazione, rollback, e che anche le modifiche manuali vengano rilevate.

Exit-Strategie und Portabilität: Control gegen Lock-in und Betriebsrisiko

Un piano di exit è, nell’ambito di ISO 27001, un argomento molto solido nella gestione del rischio, perché riduce le dipendenze e aumenta la capacità d’azione in caso di crisi. Un piano di exit pragmatico comprende:

• Esportazione dei dati: formati, completezza, frequenza, crittografia, integrità (checksum), responsabili.
• Esportazione delle configurazioni: ruoli, policy, integrazioni, automazioni.
• Percorso di migrazione: opzioni di piattaforma target, dipendenze critiche, test minimo (es. test annuale di esportazione/RESTore).
• Clausole contrattuali: termini, supporto, cancellazione, RESTituzione, costi.

Importante: l’exit non è un „progetto finale“, ma una capacità. Piccoli test regolari sono meno costosi di una grande migrazione sotto pressione temporale.

Prospettiva audit: Welche Nachweise in Cloud-Setups wirklich zählen

Molti team documentano troppo nel posto sbagliato (testi lunghi) e troppo poco nel posto giusto (artefatti verificabili). Negli audit cloud in genere contano:

• Ambito e inventario: quali servizi cloud sono nello scope ISMS, con owner e finalità.
• Valutazione dei rischi: rischi documentabili per servizio o classe di servizio, inclusa la gestione/trattamento del rischio.
• SoA: scelta motivata dei controlli, inclusa implementazione/stato.
• Fascicolo fornitore: contratto, allegato di sicurezza, evidenze/report, informazioni sui subfornitori, review.
• Evidenze operative: export IAM, protocolli di recertificazione, inoltro dei log, esercitazioni sugli incidenti, test di RESTore.

Se volete organizzarvi in modo audit-ready, pianificate internamente un collegamento a una checklist „Audit-Ready“. Questo migliora sia la preparazione sia la qualità dell’archiviazione quotidiana.

Checklist pratica: integrazione di un servizio cloud in 10 passaggi conforme all’ISMS

1. Redigere il profilo del servizio (scopo, dati, interfacce, utenti, owner).
2. Classificazione dei dati e definire regioni/residenza consentite.
3. Shared Responsibility documentata come RACI per famiglia di controllo.
4. Verifica del fornitore inclusi subappaltatori, segnalazione incidenti, evidenze.
5. Effettuare la valutazione dei rischi, pianificare il trattamento del rischio (incl. misure compensative).
6. Contratto/allegato di sicurezza finalizzare (SLA, logging, supporto, exit, informazioni per audit).
7. Integrare l’IAM (SSO, MFA, ruoli, SCIM, break-glass).
8. Logging/Monitoring collegare, definire la conservazione e le notifiche di allarme.
9. BCM/Backup/RESTore definire e pianificare almeno un test.
10. Exit-Minimaltest definire (esportazione + validazione) e inserirlo nel piano annuale.

Questa sequenza è stata volutamente scelta affinché la governance e le evidenze non vengano gestite a posteriori, ma che l’approvvigionamento e l’esercizio siano sostenibili fin dall’inizio.

Verantwortlichkeiten und Governance im Alltag: Wer muss was entscheiden?

L’integrazione cloud nell ISMS spesso fallisce per assunzioni implicite: „Security macht das“ o „der Provider ist zuständig“. Per decisioni affidabili servono ruoli chiari:

• Service Owner: responsabilità funzionale, budget, accetta rischi residui nell’ambito della governance.
• Information Owner: responsabile del fabbisogno di protezione/classificazione dei dati (frequentemente il reparto di appartenenza, supportato da IT/Compliance).
• Cloud Platform/Operations: baseline tecniche, logging, account, automazione, gestione operativa.
• ISMS/Compliance: metodo, valutazione dei rischi, SoA, gestione delle evidenze, comunicazione con l’audit.
• Security: controlli, monitoraggio, gestione degli incidenti, valutazioni delle eccezioni.
• Datenschutz (se rilevante): basi giuridiche, trattamento su incarico, trasferimenti internazionali.

La direzione non è „Detailverantwortliche“, ma deve sostenere la governance: con mandati chiari, risorse per i controlli e una definita propensione al rischio.

Schlussfazit: Cloud-Services ISO-27001-konform nutzen heißt kontrolliert entscheiden

Cloud-Services unter ISO 27001 non sono in contraddizione – ma sono gestibili solo se selezione, contratto, configurazione e esercizio sono intesi come un sistema di controllo coerente. La leva centrale non è un singolo strumento, ma la vostra capacità di assegnare responsabilità in modo inequivocabile, documentare flussi di dati e rischi e implementare controlli tecnici in modo che reggano nel quotidiano e in sede di audit.

Se volete partire in modo pragmatico: definite un profilo di servizio, un pacchetto standard di requisiti minimi per IAM e logging, un allegato di sicurezza per i fornitori e un Exit-Minimaltest. In questo modo ridurrete notevolmente i rischi tipici del cloud (incertezza, mancanza di evidenze, Lock-in) — senza sovraccaricare il vostro ISMS con carta.

Per questo tema sono importanti anche Isms Cloud Integration e Cloud Governance. Il contributo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.