La gravità di un incidente di sicurezza la decide una persona, applicando criteri scritti e approvati in anticipo: sistemi coinvolti, dati a rischio, servizi interrotti, privilegi in gioco. L'intelligenza artificiale può proporre una priorità e motivarla, ma la ratifica resta a un responsabile, e la catena di escalation definisce chi interviene, entro quando e con quali poteri. Questa guida mostra come impostare livelli, criteri e responsabilità prima che arrivi l'allarme.
Chi decide la gravità di un incidente, e con quali criteri
La risposta breve: decide un responsabile indicato per ruolo, non il sistema di allarme. Un sistema può segnalare, correlare e proporre una valutazione; la classificazione di un evento come incidente, e la scelta del suo livello, sono atti di responsabilità. La pubblicazione NIST SP 800-61 revisione 3 del National Institute of Standards and Technology (NIST), uscita nell'aprile 2025, colloca la risposta agli incidenti dentro la gestione complessiva del rischio: ruoli, responsabilità e criteri di decisione fanno parte della preparazione, non di un dettaglio tecnico da improvvisare durante l'emergenza.
Perché la decisione sia rapida e difendibile, i criteri devono essere scritti prima e condivisi con chi li applicherà. I più utili rispondono a domande osservabili:
- Sistemi e servizi: l'evento tocca un sistema critico per il lavoro quotidiano (produzione, ordini, fatturazione) o uno secondario?
- Dati: sono coinvolti dati riservati, personali o soggetti a vincoli contrattuali?
- Privilegi: è coinvolto un account amministrativo o con accessi estesi?
- Continuità: un servizio è interrotto, o è degradata un'attività che non può fermarsi?
- Propagazione: l'evento può estendersi ad altri sistemi o sedi se nessuno interviene?
Ogni criterio deve poter essere verificato da chi riceve l'allarme senza interpretazioni creative. «Coinvolge dati riservati» funziona solo se esiste un elenco dei sistemi che li contengono; «servizio critico» solo se qualcuno ha stabilito quali sono.
Definire livelli di gravità comprensibili a tutti
Tre livelli bastano alla maggior parte delle imprese. Più livelli significano più discussioni su quale scegliere, proprio quando il tempo conta. Ogni livello deve avere un nome parlante, criteri di ingresso chiari e una destinazione nella catena di escalation. Una griglia di questo tipo si discute in mezz'ora e si applica in pochi minuti:
| Livello | Quando si applica | Chi viene coinvolto |
|---|---|---|
| Alta | Servizio critico interrotto o a rischio, dati riservati potenzialmente esposti, account privilegiato compromesso, propagazione in corso. | Responsabile IT e direzione, subito; decisione su contenimento e comunicazioni. |
| Media | Anomalia su sistema importante senza interruzione, oppure su dati non riservati; richiede verifica entro l'orario di lavoro. | Responsabile IT o suo sostituto; aggiornamento alla direzione solo se la verifica peggiora il quadro. |
| Bassa | Segnale da registrare e osservare: nessun impatto immediato, nessun criterio superiore soddisfatto. | Chi segue i sistemi nel normale turno; riesame periodico degli schemi ricorrenti. |
Accanto ai criteri di ingresso servono anche criteri di declassamento: quando un allarme alto può tornare medio o basso, e chi può deciderlo. Senza questa uscita, ogni caso aperto in alto resta alto per prudenza, e la prudenza diventa rumore.
Come evitare che tutto diventi urgente
Quando ogni allarme è urgente, nessuno lo è più: le persone smettono di leggere le notifiche e i casi veri si perdono nel mucchio. Tre regole pratiche riducono il problema alla radice.
Prima: l'urgenza ha un costo dichiarato. Alzare la priorità sveglia qualcuno, interrompe lavori, sposta attenzione. Mettilo per iscritto: chi alza un livello deve indicare quale criterio lo giustifica. Se il criterio non c'è, il livello resta quello assegnato inizialmente e il caso viene riesaminato con calma.
Seconda: il declassamento è un atto registrato, non una mancanza. Chi riceve un allarme alto e, dopo verifica, lo riporta a medio con una motivazione documentata sta facendo bene il suo lavoro. Se declassare viene percepito come «farsi carico di un rischio», tutti lasciano tutto in alto e la griglia diventa inutile. La registrazione della motivazione protegge la persona e migliora i criteri nel tempo.
Terza: i criteri si rivedono. Ogni pochi mesi, rileggi gli allarmi alti dell'ultimo periodo: quanti erano davvero alti? Se una categoria produce sistematicamente falsi allarmi, il problema è nel criterio o nella sorgente, non nelle persone. Su questo aspetto è utile anche la lettura dedicata a come valutare la qualità del triage di un SOC, il centro operativo per la sicurezza (Security Operations Center).
La catena di escalation: chi, quando, con quali poteri
Una catena di escalation ben fatta è un documento breve che risponde a cinque domande. Se una risposta manca, l'emergenza la troverà al posto tuo.
- Chi: per ogni livello, un ruolo con nome e un sostituto. Le persone vanno in ferie, si ammalano, cambiano azienda: il sostituto non è un optional.
- Quando: tempi massimi di presa in carico per livello, distinguendo orario di lavoro, sera e fine settimana. Se la notte e i festivi non hanno copertura, va detto esplicitamente e gestito come scelta, non scoperto durante un incidente: ne parliamo nell'articolo sul monitoraggio di notte, nei weekend e in reperibilità.
- Con quali poteri: cosa può decidere ciascun livello senza chiedere oltre. Isolare una postazione? Sospendere un account? Fermare un servizio che produce fatturato? Poteri diversi per livelli diversi, scritti e approvati dalla direzione.
- Come si passa al livello successivo: se il responsabile non risponde entro il tempo previsto, la notifica sale al sostituto o alla direzione. Attenzione a una distinzione fondamentale: il silenzio può far salire la notifica, ma non autorizza un intervento. Un'azione che richiede approvazione resta in attesa finché una persona non la concede.
- Cosa resta scritto: per ogni passaggio, chi ha deciso cosa, quando e perché, comprese le decisioni di attendere o declassare. Questa traccia serve al riesame, alle verifiche e a rispondere a domande future sull'accaduto.
La catena va inoltre provata: un criterio ambiguo o un contatto non aggiornato emergono molto meglio in una esercitazione di risposta agli incidenti che durante un evento reale.
Esempio illustrativo: il caso che si sgonfia e quello che non deve
Esempio illustrativo. Lo scenario seguente mostra il funzionamento di griglia e catena; non racconta un incidente avvenuto presso un cliente.
In un'azienda manifatturiera con due sedi, domenica pomeriggio, un account amministrativo del gestionale ordini viene usato da una sede diversa da quella abituale. Due criteri della griglia scattano insieme: account privilegiato e orario insolito. Il sistema propone priorità alta e la segnalazione arriva al responsabile IT con le motivazioni: cosa è stato osservato, quali criteri si applicano, quali informazioni mancano.
Il responsabile controlla il calendario delle manutenzioni approvate: il fornitore del gestionale aveva pianificato un intervento proprio per quel weekend, con l'indicazione che avrebbe operato dalla sede centrale. Le informazioni coincidono. Declassa a livello basso registrando la motivazione: «attività pianificata, riferimento alla richiesta di intervento approvata». Il caso resta tracciato, la decisione è ricostruibile, e al riesame trimestrale quel tipo di allarme servirà a migliorare il criterio, per esempio incrociando automaticamente il calendario manutenzioni.
Ora cambia un dettaglio: nessun intervento pianificato risulta approvato. Stessa anomalia, stesso account, ma il criterio di declassamento non c'è più. Il livello resta alto, la notifica segue la catena — responsabile, poi sostituto, poi direzione entro i tempi previsti — e la decisione sul contenimento, per esempio sospendere l'account, viene presa da chi ha quel potere per iscritto, dopo aver visto piano e conseguenze. Sospendere un account amministrativo può bloccare lavoro legittimo: per questo la scelta spetta a una persona, con le conseguenze visibili prima di confermare.
Come Ares e Hermes supportano il flusso proposta-approvazione
In OverZeus, due agenti si occupano di questo tratto del percorso, nel solco del posizionamento «lui si accorge, tu decidi».
- Ares organizza la risposta: applica la griglia concordata ai segnali raccolti, propone una priorità motivandola con i criteri che si sono attivati, prepara l'indagine e le opzioni di contenimento con le relative conseguenze. Le misure attive che propone vengono eseguite solo se elencate nel piano e approvate.
- Hermes porta la proposta alle persone giuste attraverso l'app: cosa è stato osservato, perché è rilevante, quali opzioni ci sono. Raccoglie approvazioni e rifiuti e segue la catena concordata se un destinatario non risponde, facendo salire la notifica al passaggio successivo. Vale una regola esplicita: l'assenza di risposta non viene interpretata come autorizzazione. Se l'approvazione prevista non arriva, l'intervento attivo non parte.
Il risultato è una divisione del lavoro chiara: gli agenti fanno il lavoro di preparazione — criteri applicati, contesto raccolto, opzioni spiegate — e le persone fanno il lavoro di responsabilità, ratificando, declassando o rifiutando con la motivazione che resta agli atti. Le regole di priorità ed escalation vanno concordate all'avvio del progetto insieme alle integrazioni: per inquadrare il contesto complessivo puoi partire dalla guida ai criteri per scegliere un SOC AI.
Dalla griglia alla pratica
Priorità ed escalation funzionano quando tre condizioni sono scritte prima dell'allarme: criteri di gravità verificabili, una catena con ruoli, sostituti, tempi e poteri, e la regola che ogni decisione — alzare, declassare, attendere — lascia una traccia motivata. L'AI accelera la proposta e ne spiega le ragioni; la decisione resta alle persone, e il silenzio non la sostituisce.
Vuoi vedere come la tua griglia di priorità diventa un flusso proposta-approvazione concreto, con il silenzio che non autorizza mai?
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.