Servizio SOC gestito: cosa include e cosa chiedere

Un servizio SOC gestito è un contratto con cui un fornitore esterno sorveglia i tuoi sistemi, valuta gli allarmi e gestisce gli incidenti per tuo conto. Quello che compri, in concreto, sono sette impegni da mettere per iscritto: perimetro, fonti di log, orari di copertura, SLA di presa in carico, onboarding, report e condizioni di uscita. Più un ottavo punto che spesso manca: cosa resta a te.

Questa pagina non spiega cos'è un SOC, non entra nella scelta tra SOC interno e gestito e non parla di quanto costa un SOC gestito: ognuno di questi temi ha la sua guida. Qui si guarda dentro l'offerta, voce per voce. Che sul preventivo ci sia scritto SOC as a service, managed SOC o MDR, le voci da controllare sono le stesse.

Perché un SOC gestito si legge come un contratto

Un SOC gestito è un rapporto di fornitura in cui un terzo ha accesso profondo ai tuoi sistemi e decide, in parte, cosa succede durante un incidente. La normativa europea lo tratta con attenzione particolare.

• Il considerando 86 della direttiva (UE) 2022/2555 (NIS2) ricorda che i fornitori di servizi di sicurezza gestiti sono stati essi stessi bersaglio di attacchi e, per la loro integrazione nelle attività del cliente, presentano un rischio particolare. La conclusione è testuale: "I soggetti essenziali e importanti dovrebbero pertanto esercitare una maggiore diligenza nella selezione di un fornitore di servizi di sicurezza gestiti."
• In Italia l'art. 24, comma 2, lettera d) del D.Lgs. 138/2024 mette la sicurezza della catena di approvvigionamento, compresi i rapporti con i fornitori diretti di servizi, tra le misure minime per i soggetti NIS2.
• I fornitori di servizi di sicurezza gestiti compaiono anche nell'allegato I della direttiva (punto 9, gestione dei servizi TIC business-to-business): se superano le soglie dimensionali, rientrano a loro volta nell'ambito della direttiva.

Tradotto: quello che il fornitore promette conta solo se è scritto, misurabile e verificabile.

1. Il perimetro: cosa viene sorvegliato, e cosa no

Un'offerta seria parte da un elenco di asset, non da una lista di funzionalità:

• endpoint e server, con il numero e i sistemi operativi coperti;
• identità: la directory aziendale, gli accessi privilegiati, l'autenticazione a più fattori;
• cloud: quali account e tenant, su quali provider;
• rete e perimetro esterno: firewall, VPN, accessi remoti;
• posta elettronica e applicazioni critiche per il business;
• eventuali ambienti OT o di produzione, che richiedono regole a parte.

Per ogni voce va chiarito se il SOC si limita a osservare e avvisare, oppure se può anche intervenire. E va scritto cosa resta fuori: un sistema non elencato è un sistema che nessuno guarda. Chiedi infine come entra nel perimetro un asset nuovo, senza un nuovo negoziato ogni volta.

2. Le fonti di log: da dove arrivano i dati

Un SOC vede solo ciò che riceve. La seconda voce da mettere per iscritto è l'elenco delle fonti collegate: log degli endpoint, della directory, del firewall, del cloud, della posta. Per ognuna servono quattro risposte:

1. Chi costruisce e mantiene il connettore, e cosa succede quando un aggiornamento lo rompe.
2. Come ti accorgi se una fonte smette di inviare dati. Una fonte silenziosa è un punto cieco che nessun allarme segnala, a meno che il servizio non sorvegli anche la salute delle fonti.
3. Per quanto tempo si conservano i log, e se la durata è coerente con i tuoi obblighi di audit e di indagine.
4. Di chi è la piattaforma su cui finiscono i dati: tua, con il fornitore che ci lavora sopra, oppure del fornitore. La differenza pesa soprattutto il giorno in cui esci.

3. Gli orari: cosa vuol dire davvero SOC 24/7

La dicitura 24/7 è la voce più usata e meno precisa delle offerte. La domanda giusta non è se il servizio è attivo di notte, ma chi guarda l'allarme alle tre di notte di un sabato di agosto: un analista in turno, oppure una notifica che resta in coda fino al lunedì?

Fatti scrivere la copertura per fascia oraria (giorni feriali, notti, fine settimana, festivi), la lingua in cui il SOC ti contatta e la catena di escalation. E guarda il rovescio: un SOC attivo 24 ore su 24 serve a poco se dalla tua parte, alla stessa ora, non risponde nessuno. Il contratto deve indicare i tuoi referenti reperibili e cosa fa il SOC se non li trova.

4. Gli SLA: presa in carico, notifica, contenimento

Un SLA scritto bene non è un unico numero. Distingue almeno tre tempi, ciascuno per livello di gravità dell'incidente:

• presa in carico: quanto passa da quando scatta un allarme a quando un analista lo sta guardando;
• notifica: entro quanto ricevi una comunicazione con cosa è successo, su quali sistemi e cosa ti si chiede di fare;
• contenimento: entro quanto il SOC agisce, nei casi in cui è autorizzato a farlo.

Chiedi anche chi misura questi tempi e cosa succede quando non vengono rispettati: un livello di servizio senza misura resta un'intenzione.

Per i soggetti NIS2 c'è un motivo in più. L'art. 25, comma 5, del D.Lgs. 138/2024 chiede una pre-notifica al CSIRT Italia entro 24 ore da quando si è venuti a conoscenza di un incidente significativo, e una notifica entro 72 ore con una valutazione iniziale e, ove disponibili, gli indicatori di compromissione. Spesso è il SOC a farti venire a conoscenza dell'incidente: i suoi tempi e le informazioni che ti consegna vanno allineati a quelle scadenze. Il percorso completo è nella guida alla notifica degli incidenti NIS2.

Per banche, assicurazioni e altre entità finanziarie vale anche il Regolamento (UE) 2022/2554 (DORA): l'art. 30 chiede che i contratti per servizi ICT contengano la descrizione dei livelli di servizio e, per quelli a supporto di funzioni essenziali o importanti, obiettivi di prestazione quantitativi e qualitativi precisi, tali da permettere un monitoraggio efficace.

5. L'onboarding: come si arriva al primo giorno operativo

Tra la firma e il servizio a regime c'è un progetto, e conviene che sia descritto prima di firmare. Un onboarding ordinato copre di solito questi passaggi:

1. inventario degli asset e conferma del perimetro;
2. collegamento delle fonti di log e verifica che i dati arrivino completi;
3. regole di rilevamento adattate al tuo ambiente, con una fase di taratura per ridurre i falsi positivi;
4. matrice di escalation: chi chiamare, in che ordine, per quale tipo di incidente;
5. autorizzazioni di risposta: quali azioni il SOC può fare senza chiederti (isolare un endpoint, sospendere un account, bloccare un indirizzo) e quali richiedono il tuo via libera;
6. criteri di chiusura dell'onboarding, cioè cosa deve essere vero perché il servizio sia considerato a regime.

La durata dipende dal numero e dal tipo di fonti: chiedi un piano con date e responsabili per ogni passaggio. Le autorizzazioni di risposta meritano una riunione dedicata, perché decidono se in piena notte un attacco viene fermato o solo descritto.

6. Report e visibilità: cosa ricevi e quando

Il servizio si giudica da quello che ricevi, su tre livelli:

• per incidente: una comunicazione con cronologia, sistemi coinvolti, azioni fatte e azioni che restano a te;
• periodico: incidenti gestiti, tempi rispettati rispetto agli SLA, fonti che hanno smesso di inviare dati, regole modificate, raccomandazioni;
• di revisione: un incontro a cadenza fissa in cui si rivedono perimetro, tendenze e priorità.

Verifica anche se hai accesso a una vista in tempo reale o solo ai documenti, e se i report reggono come evidenza in un audit NIS2, DORA o ISO/IEC 27001. Cosa deve esserci nel report periodico è spiegato in report SOC mensile: cosa deve contenere.

7. Cosa resta al cliente

Un SOC gestito sposta il lavoro di sorveglianza, non la responsabilità. L'art. 25 del D.Lgs. 138/2024 attribuisce l'obbligo di notifica ai soggetti essenziali e importanti, e per le entità finanziarie l'art. 28, paragrafo 1, lettera a) di DORA dice che chi affida servizi ICT a terzi resta pienamente responsabile del rispetto degli obblighi. Il fornitore ti prepara le informazioni, la decisione e l'invio restano tuoi.

Nella pratica, restano di solito al cliente:

• la correzione delle cause: patch, configurazioni, ripristino da backup;
• le decisioni di business, come fermare una linea di produzione o un servizio online;
• un referente interno reperibile, con l'autorità per decidere;
• l'aggiornamento del SOC sui cambiamenti: un nuovo sistema, un'acquisizione, un fornitore che entra;
• governance, policy e gestione del rischio, che nessun servizio di monitoraggio sostituisce.

Se un'offerta non dice cosa resta a te, lo scopri durante il primo incidente. Come si dividono i compiti quando una parte del SOC resta interna lo spieghiamo in SOC ibrido (co-gestito). Per avere qualcuno pronto a intervenire quando l'incidente è aperto esiste l'incident response retainer. Sul confine tra servizio gestito e fondamenta da sistemare prima c'è la guida su cos'è l'MDR e quando serve.

8. Come si esce

È la voce che si legge per ultima e che pesa di più nel tempo. Il contratto deve dire cosa succede quando finisce:

• i dati: log, storico degli incidenti, report. In quale formato li ricevi e in quanto tempo;
• il lavoro fatto sul tuo ambiente: regole di rilevamento, playbook, configurazioni. Restano a te o al fornitore;
• il periodo di transizione: per quanto tempo il servizio continua mentre passi a un altro fornitore o lo riporti in casa;
• il preavviso e le condizioni di recesso.

Due riferimenti normativi aiutano a impostare la clausola. I log contengono dati personali, e il fornitore che li tratta per tuo conto agisce di norma come responsabile del trattamento: l'art. 28, paragrafo 3, lettera g) del GDPR chiede che a fine servizio, su scelta del titolare, cancelli o restituisca i dati personali e cancelli le copie esistenti. Per le entità finanziarie, l'art. 30 di DORA chiede garanzie di accesso, ripristino e restituzione dei dati in un formato facilmente accessibile e, per le funzioni essenziali o importanti, strategie di uscita con un periodo di transizione adeguato; l'art. 28, paragrafo 8, chiede di predisporre strategie di uscita per quei servizi. E una scelta tecnica fa da garanzia pratica: se la piattaforma su cui vivono i log è intestata a te, cambiare fornitore significa cambiare chi ci lavora sopra, non migrare anni di dati.

Le domande da fare prima di firmare

1. Quali asset sono nel perimetro, quali sono fuori, e come ne aggiungo di nuovi?
2. Quali fonti di log collegate, chi mantiene i connettori e come mi accorgo se una fonte tace?
3. Chi guarda gli allarmi di notte, nel fine settimana e nei festivi?
4. Quali sono i tempi di presa in carico, notifica e contenimento per ogni livello di gravità, chi li misura e cosa succede se non vengono rispettati?
5. Le informazioni che ricevo bastano per la pre-notifica entro 24 ore e la notifica entro 72?
6. Quali azioni di risposta può fare il SOC senza chiedermi il permesso?
7. Che report ricevo, con quale cadenza, e reggono un audit?
8. Alla fine del contratto, cosa mi resta in mano e in quale formato?

Due offerte con lo stesso nome possono dare risposte molto diverse a queste domande: confrontarle qui, prima che sul canone, dice cosa si sta comprando.

Se vuoi vedere come rispondiamo noi a queste domande, la pagina sulla cybersecurity gestita di AmagisTech descrive il SOC gestito operativo dall'Italia 24 ore su 24 su Google SecOps, e da lì puoi chiedere una valutazione sul tuo perimetro.