Gestione della postura di sicurezza SaaS per gli audit 2026

Il rilievo di audit SaaS senza responsabile

Alle 08:15 di un martedì, il Responsabile della sicurezza delle informazioni (CISO) di una fintech in rapida crescita riceve un messaggio dal Responsabile della protezione dei dati: “Perché un’esportazione clienti da uno strumento di collaborazione è condivisibile pubblicamente, e chi ha approvato l’app OAuth che può leggerla?”

Alle 09:00, la funzione Finanza conferma che lo strumento è pagato con una carta dipartimentale, non tramite il processo centrale di approvvigionamento. Alle 10:30, l’IT scopre che l’utente che ha creato il link pubblico ha lasciato l’azienda tre mesi prima. A mezzogiorno, la Funzione legale chiede se si tratti di una violazione dei dati personali ai sensi del GDPR. Alle 14:00, il Comitato rischi chiede se il problema incida sull’igiene cyber NIS2 e sul rischio ICT di terze parti DORA. Alle 16:00, l’auditor interno richiede baseline di configurazione, riesame degli accessi amministrativi, titolarità del servizio cloud, log e due diligence sui fornitori.

La verità scomoda è che l’organizzazione non ha subito una classica indisponibilità SaaS né un guasto del fornitore. Ha subito un fallimento della governance.

Questo scenario non è più eccezionale. Un team marketing collega una piattaforma di IA a un CRM con ampie autorizzazioni OAuth. Le Risorse Umane acquistano uno strumento di analisi di nicchia al di fuori del processo di approvvigionamento. Un team di assistenza clienti abilita, per comodità, esportazioni pubbliche dei ticket. L’ingegneria integra un’estensione del browser in un flusso di lavoro di sviluppo. Ogni decisione può sembrare circoscritta, ma nel loro insieme queste scelte creano una superficie di controllo distribuita, popolata da dati regolamentati, flussi di lavoro privilegiati e dipendenze operative.

La gestione della postura di sicurezza SaaS, o SSPM, è la disciplina che trasforma questa realtà SaaS frammentata in un controllo governato, testato e verificabile. Se applicata correttamente, fornisce a CISO, compliance manager, auditor e responsabili di processo una traccia unica di evidenze per ISO/IEC 27001:2022, igiene cyber NIS2, rischio ICT DORA e responsabilizzazione della sicurezza ai sensi del GDPR.

La posizione di Clarysec è netta: la SSPM non deve essere trattata come un’ulteriore dashboard. Deve essere integrata nel SGSI, collegata alla titolarità del rischio, mappata sugli obblighi legali, supportata da politiche e verificata tramite evidenze ricorrenti.

È qui che Zenith Blueprint: roadmap in 30 passi per l’auditor Zenith Blueprint, Zenith Controls: guida alla conformità trasversale Zenith Controls e i modelli di policy Clarysec diventano pratici. Aiutano a convertire la proliferazione SaaS in un modello di controllo comprensibile per un auditor e presidiabile da un organo di gestione.

Perché la gestione della postura di sicurezza SaaS è diventata una questione di conformità

In passato il SaaS veniva trattato come “software eseguito da qualcun altro”. Questa impostazione non è più difendibile.

In ambito NIS2, molti fornitori cloud, SaaS, di infrastrutture digitali, di servizi gestiti e di servizi di sicurezza gestiti possono rientrare nelle aspettative regolamentate di cibersicurezza in funzione di settore, dimensioni, ruolo e criticità. Ancora più importante, le organizzazioni che si affidano al SaaS devono governarlo come parte delle proprie misure di gestione del rischio. NIS2 Article 20 rende gli organi di gestione responsabili dell’approvazione delle misure di gestione dei rischi di cibersicurezza, della vigilanza sulla loro attuazione e della formazione ricevuta. Article 21 richiede misure tecniche, operative e organizzative concrete, tra cui analisi dei rischi, politiche, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e manutenzione sicure, test di efficacia, igiene cyber, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset e autenticazione a più fattori ove appropriato.

DORA innalza ulteriormente l’asticella per le entità finanziarie. Dal 17 gennaio 2025, DORA si applica a molte organizzazioni del settore finanziario come regime di resilienza operativa per le entità incluse nel perimetro. Richiede governance ICT, identificazione e classificazione degli asset ICT e delle funzioni supportate, controlli di protezione e prevenzione, gestione degli incidenti, continuità, test e gestione del rischio ICT di terze parti. I fornitori SaaS che supportano funzioni critiche o importanti entrano nel perimetro delle evidenze DORA, mentre l’entità finanziaria regolamentata resta responsabile.

Il GDPR aggiunge un livello di evidenze privacy. Article 5 richiede integrità, riservatezza e responsabilizzazione. Article 32 richiede una sicurezza del trattamento adeguata. In pratica, un’organizzazione deve sapere quali dati personali esistono, dove sono trattati, chi può accedervi, quali fornitori li trattano e quali misure di sicurezza li proteggono. Una configurazione SaaS errata trasforma queste domande in questioni urgenti di valutazione dell’impatto della violazione.

ISO/IEC 27001:2022 è il ponte. Le clausole 4.1 a 4.4 richiedono all’organizzazione di definire contesto, requisiti delle parti interessate, ambito, interfacce e dipendenze. La clausola 5 richiede leadership, politica, ruoli e responsabilità. Le clausole 6.1.1 a 6.1.3 richiedono valutazione del rischio, trattamento del rischio, Dichiarazione di Applicabilità e decisioni sul rischio residuo. Le clausole 8.1, 8.2 e 8.3 richiedono pianificazione operativa, valutazione del rischio e trattamento del rischio. Le clausole 9 e 10 richiedono monitoraggio, audit interno, riesame della direzione e miglioramento.

Se non si è in grado di rispondere a quali strumenti SaaS trattano dati regolamentati, chi ne è proprietario, come sono configurati, chi dispone di accessi amministrativi, quali integrazioni sono attive e quali evidenze dimostrano che il controllo funziona, la posizione di conformità è fragile.

Il modello SSPM di Clarysec: inventario, titolarità, baseline, evidenze

Clarysec tratta la gestione della postura di sicurezza SaaS come un ciclo di controllo ripetibile, non come un progetto una tantum di bonifica.

1. Individuare ogni servizio SaaS, incluso lo shadow SaaS.
2. Assegnare un responsabile di processo e un proprietario tecnico.
3. Classificare dati, utenti, integrazioni e criticità operativa.
4. Applicare baseline di configurazione sicure.
5. Riesaminare utenti, amministratori, guest, account di servizio e ambiti OAuth.
6. Abilitare logging, generazione di alert e conservazione.
7. Monitorare la condivisione pubblica e l’esposizione dei dati.
8. Collegare fornitori, contratti, accordi sul trattamento dei dati ed exit planning.
9. Raccogliere evidenze con una cadenza definita.
10. Alimentare le risultanze nel trattamento del rischio, nel riesame della direzione e nel miglioramento.

Questo modello è strettamente allineato ai controlli ISO/IEC 27002:2022 ISO/IEC 27002:2022, in particolare 5.9 inventario delle informazioni e di altri asset associati, 5.15 controllo degli accessi, 5.18 diritti di accesso, 5.19 sicurezza delle informazioni nei rapporti con i fornitori, 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, 8.2 diritti di accesso privilegiato, 8.3 restrizione dell’accesso alle informazioni, 8.9 gestione della configurazione, 8.15 logging, 8.16 attività di monitoraggio e 8.32 gestione delle modifiche.

Il Zenith Blueprint, nella fase Controls in Action, Step 23 per i controlli organizzativi, afferma:

Il cloud non è più una destinazione: è l’impostazione predefinita. Dall’archiviazione alla collaborazione, dall’infrastruttura al machine learning, le organizzazioni sono sempre più costruite su livelli di ambienti di terze parti, astratti e gestiti da remoto. Il controllo 5.23 riconosce questa realtà e richiede che la sicurezza delle informazioni sia affrontata esplicitamente nella selezione, nell’uso e nella gestione dei servizi cloud, non come un ripensamento, ma come principio progettuale fin dall’inizio.

Questo è il fulcro della SSPM. Non si tratta solo di rilevare una configurazione errata a posteriori. Si tratta di inserire selezione, onboarding, esercizio, monitoraggio e uscita dal SaaS nel sistema di gestione.

La stessa sezione di Zenith Blueprint spiega la realtà della responsabilità condivisa con un linguaggio che ogni membro del Consiglio di amministrazione dovrebbe ascoltare:

I fornitori cloud proteggono l’infrastruttura, ma siete comunque responsabili dei vostri dati, delle vostre configurazioni, delle vostre politiche di accesso e della vostra preparazione alla risposta agli incidenti. Un bucket di archiviazione configurato in modo errato, una dashboard esposta pubblicamente o autorizzazioni eccessive in una configurazione IAM cloud non sono fallimenti del cloud. Sono fallimenti della governance.

Il fornitore può gestire la piattaforma, ma l’organizzazione resta responsabile della configurazione del tenant, delle identità, delle approvazioni degli accessi, dei dati esposti, delle integrazioni, dei flussi di gestione degli incidenti e delle evidenze di conformità.

Il controllo 5.23 è l’ancora, ma la SSPM richiede una famiglia di controlli

In Zenith Controls, il controllo ISO/IEC 27002:2022 5.23, sicurezza delle informazioni per l’uso dei servizi cloud, è classificato come controllo preventivo a supporto di riservatezza, integrità e disponibilità. Il suo concetto di cibersicurezza è Protect, con capacità operativa nella sicurezza dei rapporti con i fornitori e domini che coprono governance, ecosistema e protezione.

Questo è rilevante perché la SSPM non è un singolo controllo. È una disciplina trasversale ai controlli.

Zenith Controls collega 5.23 ai rapporti con i fornitori previsti dal controllo 5.19 perché i fornitori SaaS sono fornitori critici, ma 5.23 aggiunge aspetti specifici del SaaS, come multi-tenancy, trasparenza sulla localizzazione dei dati e responsabilità condivisa. Collega 5.23 al trasferimento di informazioni perché API, integrazioni e flussi di lavoro tra servizi SaaS spostano dati in modo continuo. Collega 5.23 all’inventario degli asset perché le organizzazioni necessitano di visibilità aggiornata sui dati archiviati nel cloud e sulle risorse SaaS. Collega inoltre la governance cloud a monitoraggio, restrizione degli accessi, gestione della configurazione e vigilanza sui fornitori.

Per i diritti di accesso, Zenith Controls mappa 5.18 su 5.15 controllo degli accessi, 5.16 gestione delle identità, 5.3 separazione dei compiti, 5.36 conformità a politiche, regole e standard per la sicurezza delle informazioni e 8.2 diritti di accesso privilegiato. Per la SSPM, ciò significa che il riesame degli accessi non è un mero esercizio su foglio di calcolo. È la prova operativa che ciclo di vita dell’identità, principio del privilegio minimo, segregazione e governance degli accessi privilegiati funzionano all’interno delle applicazioni SaaS.

Fondamento delle policy: definire la postura attesa prima di acquistare strumenti

Molti fallimenti SaaS nascono da un linguaggio di policy vago. “Usare gli strumenti approvati in modo sicuro” non è sufficiente. Le politiche Clarysec definiscono aspettative specifiche su registro, accessi, logging, configurazione e riesame dei fornitori.

Per le PMI, la Politica di utilizzo del cloud per PMI Politica di utilizzo del cloud - PMI offre un punto di partenza pratico. Dalla sezione “Requisiti di governance”, clausola di policy 5.3:

Un Registro dei servizi cloud deve essere mantenuto dal fornitore IT o dal Direttore generale. Deve registrare: 5.3.1 Il nome e la finalità di ciascun servizio cloud approvato 5.3.2 La persona o il team responsabile (Proprietario dell’applicazione) 5.3.3 I tipi di dati archiviati o trattati 5.3.4 Il Paese o la regione in cui i dati sono archiviati 5.3.5 Le autorizzazioni di accesso degli utenti e gli account amministrativi 5.3.6 I dettagli contrattuali, le date di rinnovo e i contatti di supporto

Questa clausola è il nucleo operativo della SSPM. Fornisce agli auditor il primo oggetto di evidenza: un registro che collega l’uso del SaaS a proprietari, dati, geografia, accessi e contratti.

La stessa Politica di utilizzo del cloud per PMI, dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.2, definisce le impostazioni di baseline:

Requisiti di configurazione di sicurezza 6.2.1 Quanto segue deve essere abilitato su tutte le piattaforme cloud: 6.2.2 Autenticazione a più fattori (MFA) per account amministrativi e utenti 6.2.3 Impostazioni di complessità della password (minimo 10 caratteri, nessun riutilizzo) 6.2.4 Registrazione delle attività per tentativi di accesso e accesso ai dati 6.2.5 Restrizioni di accesso (ad es. lista di autorizzazione IP, ove supportata) 6.2.6 Gli accessi amministrativi devono essere limitati a persone nominative o a fornitori di supporto autorizzati. 6.2.7 I contenuti condivisi pubblicamente devono essere monitorati regolarmente per prevenire perdite di dati. 6.2.8 Quando gli account utente non sono più necessari, l’accesso deve essere revocato immediatamente e ogni dato residuo deve essere riesaminato e archiviato o cancellato.

Per gli ambienti enterprise, la Politica di utilizzo del cloud Politica di utilizzo del cloud assegna una governance centralizzata più robusta. Dalla sezione “Requisiti di governance”, clausola di policy 5.3:

Ogni servizio cloud deve avere un proprietario del servizio assegnato, responsabile della gestione del ciclo di vita degli asset informativi, della governance dell’utilizzo, del tracciamento del budget e del monitoraggio continuo della conformità.

Questa frase chiude una lacuna di audit comune. Se nessuno è proprietario di un servizio SaaS, nessuno è responsabile della deriva della configurazione, della ricertificazione degli accessi, dell’esposizione dei dati, delle decisioni di rinnovo, del contatto in caso di incidente o dell’exit planning.

Anche la governance dei privilegi deve essere esplicita. La Politica di gestione degli account utente e dei privilegi per PMI Politica di gestione degli account utente e dei privilegi - PMI, dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.4, stabilisce:

Riesame degli accessi e logging 6.4.1 Deve essere eseguito ogni sei mesi un riesame di tutti gli account utente e dei relativi privilegi. 6.4.2 Durante i riesami, il referente IT deve validare se ciascun account rimane attivo, necessario e assegnato alle autorizzazioni corrette. 6.4.3 I log di creazione degli account, disattivazione degli account e modifiche dei privilegi devono essere conservati in modo sicuro per almeno 12 mesi.

Per il SaaS, ogni piattaforma critica necessita di un ciclo definito di riesame degli accessi, anche se la piattaforma è amministrata da un team di funzione anziché dall’IT centrale.

Anche il logging deve essere esplicito. La Politica di logging e monitoraggio per PMI Politica di registrazione e monitoraggio - PMI, dalla sezione “Requisiti di governance”, clausola di policy 5.5, stabilisce:

Servizi cloud e logging di terze parti 5.5.1 Per le piattaforme in cui il logging non è sotto il controllo diretto dell’IT (ad es. e-mail SaaS), si applicano i seguenti requisiti: 5.5.1.1 Il logging deve essere abilitato e configurato ove disponibile 5.5.1.2 Gli alert devono essere instradati al fornitore di supporto IT 5.5.1.3 I contratti devono richiedere ai fornitori di conservare i log per almeno 12 mesi e di fornire accesso su richiesta

Infine, la governance dei fornitori SaaS deve essere documentata. La Politica di sicurezza delle terze parti e dei fornitori per PMI Politica di sicurezza delle terze parti e dei fornitori - PMI, dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.3, stabilisce:

Monitoraggio continuo della sicurezza dei fornitori 6.3.1 I fornitori critici o ad alto rischio devono essere riesaminati almeno annualmente. Il riesame deve verificare: 6.3.1.1 L’uso continuativo di metodi di accesso sicuri 6.3.1.2 Certificazioni di sicurezza valide o evidenze dei controlli aggiornate 6.3.1.3 Storico degli incidenti o problematiche segnalate 6.3.1.4 Conformità contrattuale alle clausole di sicurezza 6.3.2 Tali riesami devono essere documentati e conservati nella registrazione del fornitore. Le azioni di follow-up devono essere tracciate chiaramente. 6.3.3 Quando i fornitori gestiscono infrastrutture IT o applicazioni, il monitoraggio può includere: 6.3.3.1 Richiesta di log di audit 6.3.3.2 Riesame delle attività degli account 6.3.3.3 Conferma che non si sia verificato alcun accesso non autorizzato

Nel loro insieme, queste politiche trasformano la SSPM da aspirazione di sicurezza a modello operativo applicabile.

Uno sprint SSPM di 30 giorni per le evidenze

Un CISO o un compliance manager pragmatico può iniziare con uno sprint di evidenze di 30 giorni. Selezionare le cinque piattaforme SaaS più rilevanti per i dati regolamentati o per le operazioni critiche. I candidati tipici includono Microsoft 365 o Google Workspace, CRM, ticketing, HRIS, automazione finanziaria, assistenza clienti e sistemi di analisi.

Settimana 1: creare il registro SaaS

Usare i campi della clausola 5.3 della Politica di utilizzo del cloud per PMI come registro minimo. Per ciascun servizio SaaS, acquisire:

• Nome del servizio e finalità aziendale
• Proprietario dell’applicazione e proprietario tecnico
• Tipi di dati, inclusi dati personali e categorie particolari di dati, ove applicabile
• Paese o regione di archiviazione dei dati
• Gruppi di utenti e account amministrativi
• App OAuth e integrazioni di terze parti
• Proprietario del contratto, data di rinnovo e contatto di supporto
• Criticità per le operazioni
• Obblighi applicabili, quali NIS2, DORA, GDPR o contratti con i clienti

Ciò supporta le clausole ISO/IEC 27001:2022 4.2 e 4.3 perché dipendenze regolamentari, contrattuali e da terze parti devono influenzare il campo di applicazione del SGSI. Supporta inoltre l’identificazione e la classificazione, in stile DORA Article 8, delle funzioni aziendali supportate dall’ICT, degli asset informativi, degli asset ICT e delle dipendenze.

Settimana 2: definire baseline di configurazione sicure

Per ciascuna piattaforma SaaS selezionata, definire da 10 a 15 controlli di baseline.

• MFA applicata per tutti gli utenti, con MFA resistente al phishing per gli amministratori ove possibile
• Condivisione esterna disabilitata per impostazione predefinita o limitata a domini approvati
• Link pubblici disabilitati o limitati nel tempo
• Account guest riesaminati mensilmente
• Ruoli amministrativi assegnati a persone nominative
• Autenticazione legacy disabilitata
• Flusso di approvazione delle app OAuth abilitato
• Ambiti OAuth ad alto rischio bloccati o soggetti ad approvazione della sicurezza
• Registrazione di audit abilitata
• Autorizzazioni di esportazione dei dati limitate
• Impostazioni di conservazione allineate ai requisiti legali e aziendali
• Token API riesaminati e ruotati
• Alert di sicurezza instradati a IT o SOC
• Impostazioni di prevenzione della perdita di dati abilitate ove supportate
• Account break-glass documentati e monitorati

Il Zenith Blueprint, nella fase Controls in Action, Step 19, controllo 8.9 gestione della configurazione, spiega perché questo è importante:

Molte violazioni non derivano da difetti del software, ma da scelte di configurazione inadeguate. Password predefinite lasciate invariate, servizi non sicuri abilitati, porte non necessarie aperte o sistemi esposti a Internet senza giustificazione. Il controllo 8.9 garantisce che ogni sistema sia costruito su una baseline di configurazione sicura e riesaminato regolarmente per prevenire la deriva nel tempo.

Per il SaaS, la deriva della configurazione include un responsabile di processo che abilita la condivisione pubblica, un amministratore che approva un ampio accesso di terze parti o un fornitore che modifica le impostazioni predefinite dopo il rilascio di una funzionalità.

Settimana 3: riesaminare accessi e integrazioni

Esportare utenti, gruppi, amministratori e applicazioni connesse. Per ciascun account amministrativo, confermare persona nominativa, giustificazione aziendale, stato MFA, ultimo accesso, livello di privilegio, copertura del backup, aspetti di separazione dei compiti ed evidenza dell’approvazione.

Per app OAuth e integrazioni, confermare proprietario dell’app, dati acceduti, autorizzazioni richieste, stato del rischio del fornitore, data dell’ultimo utilizzo, esigenza continuativa e se il consenso sia stato concesso dall’utente o approvato dall’amministratore.

Il Zenith Blueprint, nella fase Controls in Action, Step 19, controllo 8.3 restrizione dell’accesso alle informazioni, fornisce il principio operativo:

L’accesso alle informazioni deve essere aperto quanto necessario, ma ristretto quanto possibile.

Questo si applica non solo alle persone, ma anche ad applicazioni, servizi e API. Un’integrazione OAuth inattiva può conservare l’accesso molto tempo dopo la scomparsa del dipendente o del progetto che l’ha creata.

Settimana 4: produrre evidenze pronte per l’audit e trattamento del rischio

Per ciascuna piattaforma SaaS, archiviare la voce di registro, la baseline di configurazione, screenshot o esportazioni che dimostrino le impostazioni chiave, il sign-off del riesame degli accessi, le evidenze del riesame degli amministratori, le evidenze del riesame OAuth, le evidenze di logging e alerting, la registrazione del riesame della sicurezza del fornitore, le risultanze aperte e le azioni di trattamento del rischio.

Creare quindi una sintesi direzionale di una pagina che mostri risultanze critiche, proprietari in ritardo, lacune di configurazione ad alto rischio non risolte, integrazioni non approvate, lacune nel logging, eccezioni e decisioni richieste. Questo supporta la clausola ISO/IEC 27001:2022 9.1 monitoraggio, la clausola 9.2 audit interno e la clausola 9.3 riesame della direzione. Crea inoltre un ponte pratico verso la responsabilizzazione della direzione prevista da NIS2 Article 20 e la vigilanza dell’organo di gestione prevista da DORA.

Mappatura di conformità trasversale: un pacchetto di evidenze SSPM, molti obblighi

Il valore aziendale della SSPM non consiste solo in una migliore sicurezza. Consiste anche nella riduzione della duplicazione degli adempimenti di conformità.

NIS2 Article 21 richiede misure tecniche, operative e organizzative appropriate e proporzionate. L’inventario SaaS supporta la gestione degli asset. Le baseline di configurazione supportano l’igiene cyber. MFA e riesame degli accessi supportano il controllo degli accessi. Il logging supporta la gestione degli incidenti. Il riesame dei fornitori supporta la sicurezza della catena di fornitura. La cadenza delle evidenze supporta politiche e procedure per valutare l’efficacia.

DORA richiede alle entità finanziarie di identificare e classificare funzioni supportate dall’ICT, asset informativi, asset ICT e dipendenze da terze parti. Richiede inoltre misure di protezione e prevenzione, controlli di accesso, autenticazione forte, cifratura, continuità, test, gestione degli incidenti e governance del rischio ICT di terze parti. Un pacchetto di evidenze SSPM SaaS può supportare registri DORA, mappatura delle dipendenze, vigilanza contrattuale, diritto di audit ed exit planning.

Il GDPR richiede ai titolari del trattamento di dimostrare la conformità a integrità, riservatezza e responsabilizzazione. I registri SaaS identificano dove vengono trattati i dati personali. Le baseline di configurazione riducono la divulgazione non autorizzata. Il riesame degli accessi supporta il principio del privilegio minimo. Il logging supporta l’indagine sulle violazioni. Le registrazioni dei fornitori supportano la governance dei responsabili del trattamento e la responsabilizzazione.

NIST CSF 2.0 aggiunge un livello utile di comunicazione. La funzione GOVERN richiede che i requisiti di cibersicurezza legali, regolamentari e contrattuali siano compresi e gestiti. Gli esiti relativi alla catena di fornitura richiedono ruoli dei fornitori, contratti, due diligence, monitoraggio e attività successive alla cessazione del rapporto. Le funzioni IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER si mappano naturalmente su inventario SaaS, controllo degli accessi, protezione dei dati, logging, risposta agli incidenti e ripristino.

Gli auditor orientati a COBIT 2019 e ISACA affrontano di norma la SSPM tramite governance, obiettivi di gestione, titolarità del rischio, funzionamento dei controlli e assurance. Chiederanno se le decisioni SaaS sono allineate agli obiettivi aziendali, se le risposte al rischio sono documentate, se le responsabilità sono assegnate e se le attività di assurance dimostrano che i controlli operano.

La prospettiva di audit: come auditor diversi verificano la postura di sicurezza SaaS

Un programma SSPM robusto resiste a stili di audit diversi perché produce evidenze al livello corretto.

Un auditor ISO/IEC 27001:2022 partirà da ambito, parti interessate, valutazione del rischio, Dichiarazione di Applicabilità ed evidenze operative. Se il controllo 5.23 è incluso, si aspetterà evidenze relative a selezione, uso, gestione e uscita dai servizi cloud. Se sono inclusi controlli sui diritti di accesso, campionerà utenti e chiederà se le modifiche Joiner-Mover-Leaver sono riflesse nelle autorizzazioni SaaS.

Un revisore DORA si concentrerà su funzioni critiche o importanti, dipendenza ICT di terze parti, completezza del registro, contratti, classificazione degli incidenti, test ed exit planning. Se una piattaforma SaaS supporta operazioni di pagamento, onboarding clienti, trading, analisi del rischio o comunicazioni con i clienti, lo standard delle evidenze aumenta.

Un auditor GDPR o revisore privacy chiederà dove sono archiviati i dati personali, chi può accedervi, quali esportazioni e impostazioni di condivisione esistono, se i responsabili del trattamento sono governati, se i log supportano la valutazione delle violazioni e se i controlli sono proporzionati al rischio.

Rischio dei fornitori, responsabilità condivisa e preparazione agli incidenti

La SSPM inizia spesso dalla configurazione, ma non può fermarsi lì. Il SaaS è anche una questione di rischio dei fornitori e di preparazione alla gestione degli incidenti.

DORA richiede alle entità finanziarie di mantenere registri dei contratti di servizi ICT, distinguere gli accordi che supportano funzioni critiche o importanti, valutare il rischio di concentrazione, valutare l’idoneità dei fornitori e mantenere strategie di uscita. I contratti dovrebbero trattare descrizioni dei servizi, localizzazione dei dati, protezione di disponibilità, autenticità, integrità e riservatezza, accesso ai dati, ripristino e restituzione, assistenza in caso di incidente, cooperazione con le autorità, diritti di risoluzione, requisiti di sicurezza, diritto di audit e supporto alla transizione.

NIS2 Article 21 include inoltre la sicurezza della catena di fornitura e richiede alle entità di considerare le vulnerabilità specifiche dei fornitori diretti e dei prestatori di servizi, la qualità dei prodotti e le pratiche di cibersicurezza dei fornitori.

In pratica, il riesame di un SaaS critico dovrebbe combinare evidenze dei questionari di sicurezza, riesame contrattuale, stato dell’accordo sul trattamento dei dati, storico degli incidenti, impegni di livello di servizio, accesso ai log, rapporti di audit, evidenze di configurazione e fattibilità dell’uscita.

La lacuna di responsabilità condivisa emerge quando i team presumono che la certificazione del fornitore copra la configurazione del tenant. Non è così. Un fornitore può gestire una piattaforma sicura mentre il cliente abilita la condivisione pubblica, lascia attivi account amministrativi inattivi o concede ambiti API eccessivi. La SSPM chiude questa lacuna.

La preparazione agli incidenti è altrettanto importante. La segnalazione degli incidenti significativi NIS2 include un’allerta precoce entro 24 ore, una notifica entro 72 ore e un rapporto finale non oltre un mese dalla notifica di 72 ore. DORA richiede la gestione degli incidenti connessi all’ICT con rilevazione, registrazione, classificazione, escalation, comunicazione e notifica. Anche la valutazione delle violazioni dei dati personali ai sensi del GDPR dipende dalla comprensione tempestiva di ciò che è accaduto, dei dati interessati e delle persone impattate.

Se un’app OAuth sospetta ha avuto accesso ai file dei clienti, occorre sapere quando l’app è stata autorizzata, quale utente l’ha autorizzata, quali ambiti sono stati concessi, quali dati sono stati acceduti, se i dati sono stati scaricati o condivisi, quali utenti o clienti sono stati interessati, se l’accesso è ancora attivo e quali azioni di contenimento sono state adottate.

Senza logging e conservazione, l’organizzazione può essere costretta ad assumere lo scenario peggiore. Ciò aumenta l’esposizione legale, la pressione comunicativa verso i clienti e l’incertezza regolamentare. Quando un fornitore SaaS addebita costi aggiuntivi per i log di audit, il proprietario del rischio deve accettare esplicitamente il rischio residuo o approvare il livello di licenza richiesto. Tale decisione deve essere inserita nella registrazione del trattamento del rischio e nel riesame della direzione.

Schemi comuni di fallimento SSPM

Gli stessi schemi di fallimento si ripetono in tutti i settori.

Primo, lo shadow SaaS viene scoperto tramite fatture, cronologia del browser o log SSO anziché tramite il processo di approvvigionamento. La soluzione non è solo bloccare gli strumenti. È un processo leggero di intake utilizzabile dai team di funzione.

Secondo, la titolarità SaaS è poco chiara. Il CRM è “di proprietà delle Vendite”, ma nessuno nelle Vendite sa spiegare ruoli amministrativi, token API, esportazioni di dati o impostazioni di conservazione. Assegnare separatamente proprietari delle applicazioni e proprietari tecnici.

Terzo, i riesami degli accessi sono troppo generici. Un revisore approva “tutti gli utenti approvati” senza controllare ruoli ad alto rischio, utenti inattivi, guest, collaboratori esterni o account di servizio. Il riesame degli accessi SSPM deve essere classificato in base al rischio.

Quarto, le app OAuth sono ignorate. Molte organizzazioni riesaminano gli utenti umani, ma non le autorizzazioni app-to-app. Nel SaaS moderno, le integrazioni possono essere più potenti degli utenti.

Quinto, le baseline di configurazione esistono solo come screenshot del progetto di certificazione. Non sono monitorate per rilevare la deriva. Allineare la SSPM alla gestione della configurazione affinché i controlli di baseline diventino evidenze ricorrenti.

Sesto, riesame dei fornitori e riesame della postura di sicurezza SaaS sono separati. L’approvvigionamento ha il contratto, l’IT ha la console amministrativa, la Privacy ha l’accordo sul trattamento dei dati e la Sicurezza ha il Registro dei rischi. L’auditor vede frammenti. La SSPM li riunisce.

Reportistica direzionale: rendere visibile al Consiglio il rischio SaaS

NIS2 e DORA rendono entrambe la governance ICT e di cibersicurezza una questione di direzione. ISO/IEC 27001:2022 richiede inoltre leadership, risorse, assegnazione dei ruoli, monitoraggio e riesame della direzione.

Un report direzionale SSPM efficace deve rispondere a queste domande:

• Quali servizi SaaS critici sono in ambito?
• Quali processi regolamentati dipendono da essi?
• Quali contengono dati personali o dati aziendali sensibili?
• Quali hanno riesami degli accessi scaduti?
• Quali hanno lacune di configurazione ad alto rischio non risolte?
• Quali hanno app OAuth o integrazioni non approvate?
• Quali fornitori non dispongono di evidenze di sicurezza aggiornate?
• Quali lacune di logging incidono sulla segnalazione degli incidenti?
• Quali eccezioni richiedono accettazione del rischio?
• Quali investimenti o decisioni sono necessari?

Questo trasforma la SSPM da progetto tecnico di pulizia a input di governance. Rende inoltre il CISO più efficace perché l’accettazione del rischio viene portata al livello corretto.

Trasformare la postura di sicurezza SaaS in evidenze pronte per l’audit

Se l’organizzazione utilizza SaaS per dati regolamentati, operazioni finanziarie, assistenza clienti, HR, collaborazione, ingegneria o analytics, la SSPM non è più opzionale. Fa parte dell’igiene cyber, della gestione del rischio ICT, della responsabilizzazione privacy e della capacità di dimostrare la conformità in sede di audit.

Clarysec può aiutare a passare da risultanze SaaS frammentate a un programma strutturato e guidato dalle evidenze utilizzando:

• Zenith Blueprint: roadmap in 30 passi per l’auditor Zenith Blueprint per strutturare l’attuazione su uso del cloud, restrizione degli accessi e gestione della configurazione.
• Zenith Controls: guida alla conformità trasversale Zenith Controls per mappare i controlli ISO/IEC 27002:2022 su NIS2, DORA, GDPR, NIST CSF 2.0 e aspettative di audit.
• Modelli di policy Clarysec come Politica di utilizzo del cloud Politica di utilizzo del cloud, Politica di utilizzo del cloud per PMI Politica di utilizzo del cloud - PMI, Politica di gestione degli account utente e dei privilegi per PMI Politica di gestione degli account utente e dei privilegi - PMI, Politica di logging e monitoraggio per PMI Politica di registrazione e monitoraggio - PMI e Politica di sicurezza delle terze parti e dei fornitori per PMI Politica di sicurezza delle terze parti e dei fornitori - PMI per creare regole operative applicabili.

Iniziare dalle cinque piattaforme SaaS a rischio più elevato. Assegnare i proprietari. Acquisire evidenze su dati, accessi, configurazione, integrazioni, log e fornitori. Trasformare le risultanze in azioni di trattamento del rischio e decisioni direzionali.

È così che la gestione della postura di sicurezza SaaS diventa più di una categoria di strumenti. Diventa una disciplina di conformità difendibile per il 2026.

Scaricare i modelli di policy Clarysec, usare Zenith Blueprint per pianificare lo sprint SSPM di 30 giorni per le evidenze e mappare i controlli SaaS con Zenith Controls prima che sia il prossimo audit a individuare le lacune.