Che cos'è un SGSI? Collegare il lavoro di sicurezza alle decisioni aziendali

Il lavoro di sicurezza può sembrare intenso senza essere coordinato. L'ingegneria applica patch ai sistemi, le risorse umane gestiscono le uscite del personale, l'ufficio acquisti valuta i fornitori e la direzione approva le eccezioni. Un sistema di gestione per la sicurezza delle informazioni (SGSI) collega queste attività a obiettivi comuni e a un processo decisionale esplicito.

Per un amministratore delegato, la domanda importante non è se l'azienda disponga di abbastanza documenti sulla sicurezza. È se la leadership sappia spiegare che cosa va protetto, quali rischi contano, chi ne è responsabile e perché l'attuale livello di protezione è accettabile. Un SGSI rende queste risposte ripetibili man mano che l'azienda cambia.

Che cosa gestisce effettivamente un SGSI

Un sistema di gestione per la sicurezza delle informazioni è il sistema organizzativo con cui si gestiscono i rischi per la sicurezza delle informazioni. Comprende responsabilità, politiche, processi, risorse, controlli e valutazione. Un software può supportarlo, ma il software non è il sistema. Una raccolta di documenti può descriverlo, ma i soli documenti non dimostrano che funzioni.

Il suo scopo è proteggere tre proprietà delle informazioni:

• Riservatezza: le informazioni sono accessibili soltanto a persone e sistemi autorizzati.
• Integrità: le informazioni restano accurate, complete e protette da modifiche inappropriate.
• Disponibilità: gli utenti autorizzati possono ottenere le informazioni e utilizzare i servizi di supporto quando necessario.

Queste proprietà si traducono in preoccupazioni concrete per l'azienda. Dati dei clienti esposti possono minare la fiducia e generare obblighi di legge. Istruzioni di pagamento errate possono causare perdite finanziarie. Una piattaforma di assistenza non disponibile può impedire all'azienda di rispettare gli impegni presi con i clienti.

La ISO/IEC 27001 fornisce requisiti riconosciuti per un SGSI con un campo di applicazione definito. I punti da 4 a 10 riguardano contesto dell'organizzazione, leadership, pianificazione, supporto, attività operative, valutazione delle prestazioni e miglioramento. Un'organizzazione può sviluppare e far funzionare un SGSI prima di puntare alla certificazione.

Il sistema di gestione fornisce il collegamento tra le singole misure di protezione e le decisioni aziendali. Un backup è un controllo. Decidere che cosa deve poter essere ripristinato, finanziare la capacità di ripristino, verificarla e intervenire quando i test falliscono è lavoro del sistema di gestione.

Perché la leadership ha bisogno di questi collegamenti

Le decisioni sulla sicurezza vengono già prese in tutta l'azienda, che la si chiami SGSI o no. Qualcuno sceglie un fornitore SaaS, approva un accesso privilegiato, accetta una patch rinviata o si impegna con un cliente su un requisito di ripristino. Senza un processo condiviso, queste decisioni possono basarsi su presupposti diversi e nessuno risponde del loro effetto complessivo.

Un SGSI offre alla leadership una base per assegnare priorità a risorse limitate. Aiuta inoltre i team a rispondere alle domande dei clienti partendo da registrazioni mantenute aggiornate, invece di ricostruire le proprie pratiche a ogni valutazione commerciale. Questo non garantisce l'esito positivo di una gara d'acquisto, ma rende più sostenibili le affermazioni su cui si basa.

I collegamenti dovrebbero rispondere a domande pratiche:

Questi collegamenti contano soprattutto durante la crescita. Le pratiche informali che funzionano quando tutti si conoscono diventano inaffidabili con l'arrivo di nuovi team, sedi, fornitori e impegni verso i clienti.

Definire un campo di applicazione che rifletta l'azienda

Partite dal contesto aziendale, non da un elenco di controlli. Individuate i servizi che l'organizzazione fornisce, le informazioni che utilizzano, le parti interessate e i loro requisiti, nonché le condizioni interne ed esterne che incidono sulla sicurezza.

Il campo di applicazione definisce il perimetro del SGSI. Dovrebbe indicare le attività coperte, le unità organizzative, le sedi ove pertinente, la tecnologia e le interfacce con altre parti dell'azienda. Un primo campo di applicazione utile potrebbe riguardare un prodotto rivolto ai clienti e le relative attività operative, anziché ogni attività aziendale.

Tuttavia, un campo di applicazione mirato non può ignorare le dipendenze. Se le risorse umane avviano la procedura di uscita dei dipendenti con accesso al prodotto, quell'interfaccia conta. Se un fornitore cloud ospita il servizio, l'esternalizzazione non fa sparire la dipendenza. Se l'assistenza esporta informazioni sui clienti, il processo di esportazione rientra nell'analisi.

Redigete una dichiarazione del campo di applicazione, poi mettetela alla prova con tre domande:

• Un cliente capirebbe che cosa è coperto e che cosa no?
• Abbiamo incluso le dipendenze necessarie a proteggere il servizio coperto?
• I responsabili designati possono mantenere il sistema entro questo perimetro?

Iniziare in piccolo è una raccomandazione pratica, non un'autorizzazione a definire un perimetro fuorviante. Un campo di applicazione chiaro con responsabili definiti è più solido di un ampio registro che nessuno aggiorna. Ampliatelo in modo deliberato quando nuovi servizi o dipendenze lo giustificano.

Assegnare decisioni, non solo attività

Per un SGSI conforme alla ISO 27001, l'alta direzione deve fornire indirizzo e supporto. Delegare il coordinamento a un responsabile della sicurezza non trasferisce la responsabilità della leadership su priorità, risorse e rischio accettabile.

Separate le responsabilità che spesso finiscono per concentrarsi nel lavoro di una sola persona:

Una piccola azienda può assegnare più responsabilità a una sola persona. Dovrebbe comunque indicare quale ruolo quella persona sta esercitando e dove serve un confronto indipendente, in particolare per l'audit interno.

Definite soglie di escalation. Un team lead potrebbe approvare un'eccezione operativa di breve durata entro limiti concordati; un rischio che minaccia impegni importanti verso i clienti può richiedere l'approvazione dei vertici. Registrate motivazione, condizioni, data di scadenza ed evento che attiva il riesame. «Accettato dalla direzione» non basta se nessuno sa indicare chi ha deciso o quale esposizione è stata accettata.

Trasformare la valutazione dei rischi in un processo di prioritizzazione

La valutazione dei rischi dovrebbe descrivere scenari plausibili, non limitarsi a nominare asset o elencare debolezze. «Database clienti» è un asset. «Un account amministrativo compromesso consente l'estrazione massiva dei dati dei clienti» è uno scenario di rischio con una causa e una conseguenza.

Stabilite un metodo di valutazione documentato e criteri di accettazione del rischio. La ISO 27001 non richiede una specifica formula di punteggio. Come approccio pratico, definite categorie di probabilità e impatto in un linguaggio comprensibile per chi decide, includendo interruzione operativa, perdite finanziarie, conseguenze contrattuali e, ove pertinente, danni alle persone.

Per ogni scenario rilevante, registrate:

• Il servizio, le informazioni e le dipendenze interessati.
• La minaccia o l'evento e le vulnerabilità pertinenti.
• I controlli esistenti e i loro limiti noti.
• Probabilità, impatto e priorità che ne deriva.
• Il responsabile del rischio e il trattamento proposto.

Il trattamento può consistere nel ridurre l'esposizione tramite controlli, evitare un'attività, condividere aspetti del rischio tramite contratti o assicurazioni, oppure accettare il rischio entro criteri approvati. Un'assicurazione non ripristina le informazioni perse e un contratto con un fornitore non elimina le responsabilità dell'organizzazione.

Distinguete il rischio attuale dal rischio residuo dopo il trattamento. Non riducete una valutazione solo perché un'attività è stata pianificata. Rivalutate dopo l'attuazione e dopo aver ottenuto evidenze adeguate del funzionamento. Fate approvare il piano di trattamento e l'accettazione del rischio residuo dall'autorità definita.

Il registro dei rischi operativo dovrebbe restare un registro delle decisioni: che cosa è cambiato, perché è stato scelto un trattamento e quando la valutazione deve essere riesaminata.

Selezionare i controlli e spiegarne l'applicabilità

I controlli sono le misure utilizzate per modificare il rischio. Comprendono misure tecniche come l'autenticazione a più fattori, processi organizzativi come le valutazioni dei fornitori, misure relative alle persone come la formazione e protezioni fisiche per dispositivi e locali.

L'Allegato A della ISO/IEC 27001:2022 contiene 93 controlli di riferimento: 37 organizzativi, 8 relativi alle persone, 14 fisici e 34 tecnologici. La selezione è basata sul rischio; un'organizzazione non attua automaticamente tutti i controlli. La ISO/IEC 27002 fornisce una guida all'attuazione, non un requisito di certificazione del SGSI a sé stante.

Per la ISO 27001, determinate i controlli necessari al trattamento dei rischi e confrontateli con l'Allegato A per verificare che nessun controllo necessario sia stato omesso. I controlli possono essere necessari anche per requisiti legali o contrattuali e non devono limitarsi all'Allegato A.

La Dichiarazione di applicabilità registra i controlli necessari, la motivazione della loro inclusione, lo stato di attuazione e la motivazione dell'esclusione dei controlli dell'Allegato A. È distinta dal piano di trattamento dei rischi: la prima spiega l'insieme dei controlli applicabili, il secondo le azioni necessarie a trattare i rischi. Per questa struttura di riferimento consultate la guida ai controlli dell'Allegato A.

Per ogni controllo selezionato, definite un responsabile, il risultato atteso, il modo in cui funziona e quali evidenze ne dimostreranno l'efficacia. «Controllo degli accessi attuato» è meno utile di un processo esplicito che copra approvazione, assegnazione, revisione e rimozione.

Le politiche dovrebbero stabilire regole che le persone possano seguire. Le procedure dovrebbero spiegarne l'esecuzione. Né le une né le altre dovrebbero promettere revisioni o restrizioni tecniche che l'organizzazione non è in grado di mantenere.

Integrare le evidenze nelle normali attività

Le evidenze dovrebbero nascere dallo svolgimento del lavoro, non dalla ricostruzione di una storia prima di un audit. Una revisione degli accessi può produrre un elenco utenti datato, le decisioni del revisore, ticket di rimozione e la conferma che le modifiche sono avvenute. Un'esercitazione di ripristino può produrre le condizioni del test, i risultati, i limiti osservati e le azioni successive.

Uno screenshot può mostrare un'impostazione in un dato momento. Non dimostra necessariamente che l'impostazione copra tutti i sistemi pertinenti o che sia rimasta efficace per un intero periodo. I revisori dovrebbero esaminare ambito, data, fonte, completezza e quale conclusione l'evidenza supporti effettivamente.

Un insieme pratico di evidenze del SGSI comprende:

Non ogni riga richiede un documento separato. Una piccola organizzazione può combinare le registrazioni, purché chiarezza e tracciabilità restino intatte. Proteggete anche le evidenze stesse: esportazioni di utenti, registrazioni di incidenti e screenshot possono contenere informazioni sensibili e richiedono regole adeguate di accesso e conservazione.

Esempio pratico: una piattaforma di assistenza clienti

Consideriamo, a titolo illustrativo, un'azienda di software di 30 persone che utilizza una piattaforma di assistenza SaaS. Supponiamo che la piattaforma contenga nomi dei clienti, recapiti, cronologie dei ticket e occasionali allegati diagnostici. Il personale utilizza account individuali, un fornitore esterno ospita l'applicazione e alcuni ticket vengono esportati per la risoluzione dei problemi. Sono ipotesi esemplificative, non un modello aziendale prescritto.

Il campo di applicazione del SGSI copre le attività di assistenza clienti e le relative dipendenze: identità del personale, fornitore SaaS, accesso dagli endpoint, esportazioni, conservazione e modalità di ripristino. Il responsabile dell'assistenza è titolare del servizio; l'IT gestisce i controlli degli accessi; l'ufficio acquisti coordina la valutazione del fornitore; la leadership approva i rischi che superano i poteri delegati.

La valutazione iniziale individua tre scenari:

Supponiamo che una riconciliazione degli account riveli che un ex dipendente ha ancora accesso. L'azione immediata è rimuoverlo e valutare se l'account sia stato utilizzato in modo inappropriato. L'azione del sistema di gestione è capire perché la rimozione non è avvenuta. Forse le risorse umane hanno avvisato l'IT, ma l'applicazione di assistenza mancava dalla checklist di uscita.

L'azione correttiva aggiorna quindi l'inventario delle applicazioni, aggiunge la piattaforma di assistenza alla procedura di uscita, assegna la responsabilità della conferma e verifica le uscite successive. Chiudere soltanto il ticket di rimozione risolverebbe la condizione immediata senza eliminarne la causa.

Supponiamo ora che il fornitore SaaS modifichi l'elenco dei suoi sub-responsabili del trattamento. Il responsabile del fornitore valuta la modifica rispetto ai requisiti contrattuali, di sicurezza e di privacy pertinenti. Registra se incide sul trattamento dei dati, sulle dipendenze o sul rischio accettato e se serve una valutazione specialistica. La modifica ha un responsabile e un percorso di revisione, invece di restare non letta in una casella di posta condivisa.

La leadership riceve le decisioni ancora aperte: se finanziare una soluzione alternativa più solida, ridurre le informazioni raccolte negli allegati o accettare un'esposizione residua definita. È così che il SGSI collega i rilievi operativi alle scelte aziendali.

Adottare una cadenza in grado di rilevare i cambiamenti

Programmate i riesami in base al rischio, alla frequenza dei cambiamenti e agli obblighi. Una revisione settimanale delle lacune durante l'attuazione iniziale e un riesame periodico della direzione possono essere scelte pratiche utili, ma non sono intervalli universali imposti dalla ISO 27001. La norma richiede audit interni e riesami della direzione a intervalli pianificati.

Aggiungete eventi che attivano un riesame: incidenti, rilasci importanti, acquisizioni, cambi di fornitore, nuovi obblighi di legge, impegni significativi verso i clienti e rilievi di audit. Un calendario da solo non coglierà cambiamenti importanti tra una riunione programmata e l'altra.

Il monitoraggio verifica se controlli e obiettivi funzionano come previsto. L'audit interno valuta se il SGSI è conforme ai requisiti ed è attuato e mantenuto efficacemente. Il riesame della direzione considera l'idoneità, l'adeguatezza e l'efficacia del sistema e decide su cambiamenti e risorse. Queste attività si alimentano a vicenda, ma non sono intercambiabili.

La direzione dovrebbe ricevere informazioni pronte per decidere: rischi rilevanti, trattamenti in ritardo, problemi ricorrenti, rilievi di audit, requisiti in evoluzione e vincoli di risorse. Contare le attività completate senza esaminarne i risultati può nascondere prestazioni deboli. La guida alle metriche del SGSI approfondisce le misure utili.

Anche la gestione degli incidenti rientra in questo ciclo. Definite canali di segnalazione, criteri di valutazione, responsabilità di risposta, poteri di comunicazione e modalità di ripristino. Verificate i canali di contatto e il processo decisionale tramite esercitazioni. Valutate gli obblighi di notifica applicabili invece di presumere che un'unica scadenza valga per ogni incidente.

Dopo un incidente o una non conformità, affrontate il problema immediato, indagate sulle cause, attuate un'azione correttiva e valutatene l'efficacia. I rilievi ricorrenti sono un motivo per ripensare la progettazione del processo o le risorse, non per ripetere semplicemente lo stesso promemoria.

Distinguere SGSI, certificazione e obblighi di legge

Il SGSI è il sistema che l'organizzazione gestisce. La ISO 27001 è una norma rispetto alla quale quel sistema può essere valutato. La certificazione è rilasciata da un organismo di certificazione indipendente, non dall'ISO né da Secani, e si applica al campo di applicazione dichiarato.

La certificazione può essere un utile strumento di garanzia quando clienti o altre parti interessate la richiedono. Non dimostra che ogni attività aziendale sia coperta, che ogni controllo funzioni sempre o che non possano verificarsi incidenti. Verificatene ambito e stato invece di considerare un certificato come garanzia di sicurezza per l'intera azienda.

L'applicabilità giuridica richiede un'analisi separata. L'articolo 32 del GDPR richiede misure tecniche e organizzative di sicurezza adeguate in base ai rischi pertinenti. La NIS2 disciplina, attraverso il recepimento nazionale, la supervisione della direzione, le misure di gestione dei rischi e la notifica degli incidenti per i soggetti interessati.

Un SGSI può organizzare evidenze e responsabilità a supporto di tali obblighi, ma la certificazione non attesta la conformità al GDPR o alla NIS2. Non è nemmeno corretto affermare che un SGSI non possa mai essere obbligatorio per legge: occorre verificare le norme nazionali o settoriali applicabili.

Evitare tre errori di attuazione prevedibili

Adottare modelli senza modificarli. I modelli possono fornire una traccia, ma i responsabili devono verificare ogni impegno rispetto alla prassi effettiva. Una politica che richiede revisioni che nessuno svolge crea una lacuna non gestita.

Tracciare un perimetro che nessuno può mantenere. Un inventario ambizioso non è utile se responsabilità e dipendenze non sono chiare. Partite da un perimetro di servizio difendibile, poi ampliatelo secondo un piano esplicito.

Considerare la certificazione il traguardo finale. Il sistema deve continuare a funzionare attraverso cambi di personale, cambi di fornitore, incidenti e nuovi prodotti. Prevedete un budget per gestione, riesame e miglioramento, non solo per la documentazione iniziale.

Un avvertimento correlato riguarda l'automazione non verificata. Le registrazioni raccolte automaticamente e le sintesi generate dall'IA possono supportare il lavoro, ma sono comunque le persone a dover stabilire la pertinenza, valutare le lacune e approvare le conclusioni.

Rendere concreta la prima decisione della leadership

Scegliete un servizio rappresentativo e chiedete al suo responsabile di presentare una dichiarazione del campo di applicazione, una mappa delle dipendenze, i primi scenari di rischio, i controlli attuali e le decisioni ancora aperte. Concordate chi può accettare i rischi, quali risorse sono disponibili e quando verranno riesaminati i progressi. Si crea così un punto di partenza gestibile senza fingere che l'intera organizzazione sia già coperta.

Il modello di workspace di Secani supporta questo flusso di lavoro modellando i servizi e gli oggetti di supporto, collegando le evidenze a requisiti, controlli e decisioni e assegnando responsabili e compiti di revisione. I team possono trasformare evidenze mancanti o responsabilità poco chiare in attività. I suggerimenti assistiti dall'IA restano bozze soggette a revisione umana, con fonti e approvazioni mantenute tracciabili.

La prossima conversazione con la leadership dovrebbe quindi essere specifica: quale servizio proteggiamo per primo, quale esposizione richiede una decisione ora e quali evidenze dimostreranno che quella decisione ha funzionato?