SOC gestito e MDR: detection e response 24/7

SOC gestito, MDR, SOC as a service: di cosa parliamo

Un SOC gestito è un Security Operations Center che non costruisci in casa: lo eroga un partner, con le sue persone, i suoi processi e una piattaforma che raccoglie i log della tua infrastruttura. Il risultato che compri è semplice da dire: qualcuno si accorge di un attacco, verifica che sia vero, lo contiene e ti spiega cosa è successo, a qualsiasi ora.

Le sigle che trovi nelle offerte descrivono lo stesso modello da angoli diversi:

• SOC as a service mette l'accento sulla forma contrattuale: il centro operativo diventa un servizio a canone.
• MDR, Managed Detection and Response, mette l'accento sull'esito: detection e response funzionanti, non una console da guardare. Cosa include e quando è ancora presto per attivarlo è in MDR: cos'è e quando serve davvero.
• Cybersecurity gestita è il termine più largo, e spesso comprende anche pentest e gestione della postura cloud.

Quello che le sigle non dicono è cosa c'è sotto. Il SIEM è lo strumento che raccoglie e correla i log, il SOC è il team che lo fa lavorare, l'MDR è il pacchetto che li unisce: la distinzione è spiegata in MDR vs SIEM vs SOC. Allo stesso modo EDR e XDR sono tecnologie, mentre l'MDR è chi le presidia al posto tuo (EDR, XDR e MDR: le differenze). Se parti da zero, cosa fa un SOC, chi ci lavora e con quali metriche si misura è in cos'è un SOC.

Cosa è cambiato nel 2026: conta il tempo, non lo strumento

Un SOC si giudica da due numeri: quanto ci mette ad accorgersi di un attacco e quanto ci mette a fermarlo. I dati pubblicati quest'anno spiegano perché questi due numeri pesano più del catalogo di tecnologie.

• Il dwell time mediano globale è salito a 14 giorni, dagli 11 dell'edizione precedente, secondo Mandiant M-Trends 2026, che analizza le indagini Mandiant del 2025. È il tempo in cui un attaccante resta dentro prima di essere scoperto.
• Il passaggio di mano tra chi entra e chi colpisce si è ridotto a 22 secondi. Nel 2022 il tempo mediano tra l'accesso iniziale e la consegna a un secondo gruppo, per esempio di ransomware, superava le 8 ore (stesso report). Un alert minore alle 3 di notte può essere l'inizio di un attacco serio.
• Nel 52% delle indagini del 2025 le organizzazioni si sono accorte da sole dell'attività malevola, contro il 43% del 2024. La visibilità interna migliora, ma quasi un caso su due resta segnalato da qualcun altro.
• In Italia, chi fa un uso estensivo di AI e security automation identifica una violazione in media in 123 giorni, contro i 145 di chi non le usa, e chi usa queste tecnologie la contiene in 44 giorni invece di 65, secondo il comunicato IBM Italia sul Cost of a Data Breach 2026. Lo stesso comunicato indica in 3,55 milioni di euro il costo medio di una violazione in Italia.

La distanza tra questi numeri è la finestra in cui l'attaccante lavora indisturbato. Le metriche si leggono così: il dwell time misura la permanenza, il MTTR il tempo di risposta, e quanto tempo serve per accorgersi di un attacco mette in fila il percorso completo.

C'è poi un problema che nasce dentro il SOC stesso: l'alert fatigue. Quando gli allarmi superano la capacità di leggerli, quello vero finisce in coda dietro a quelli che non lo sono. Non si risolve aggiungendo strumenti, si risolve con calibrazione, correlazione e presidio continuo: lo spieghiamo in alert fatigue nel SOC.

SOC interno, gestito o ibrido: come si decide

La domanda vera non è quale fornitore scegliere, ma se costruire la capacità o acquistarla. Un SOC interno dà controllo diretto e conoscenza profonda del contesto. Il prezzo è la matematica dei turni: coprire 24 ore su 24, sette giorni su sette, senza buchi richiede una rotazione di circa sei analisti, che secondo le stime di mercato vale 400.000-600.000 euro l'anno di solo personale, prima di strumenti e formazione.

Il secondo ostacolo è trovare le persone. Nel comunicato IBM 2026, per l'Italia, la carenza di personale qualificato in sicurezza è il fattore che pesa di più sul costo di una violazione, con un impatto di 199.100 euro. Un SOC interno sottodimensionato non è un SOC più economico: è un SOC con le notti scoperte.

Le strade realistiche sono tre:

1. Interno, se il perimetro è ampio, hai già competenze di security operations e puoi reggere un costo fisso importante e mesi di messa a regime.
2. Gestito, se l'IT è piccolo e già pieno di lavoro, ti serve copertura continua in tempi brevi e preferisci un canone a un organico da costruire.
3. Ibrido, se hai uno o due specialisti: presidiano di giorno, quando la conoscenza del contesto conta di più, e il partner copre notti, weekend e picchi.

Il confronto completo, con i segnali che spingono da una parte o dall'altra, è in SOC interno vs gestito. Che lavoro fanno le persone dentro un SOC, livello per livello, lo racconta cosa fa un SOC analyst. E se ti manca la figura che governa la sicurezza, prima ancora di chi la presidia, vale la pena leggere CISO as a service.

NIS2 e DORA: cosa c'entra il SOC con gli obblighi

Né la NIS2 né DORA impongono di comprare un SOC. Chiedono però capacità che senza un presidio continuo sono difficili da dimostrare a un'autorità o a un auditor.

NIS2: gestione degli incidenti e notifiche in 24 e 72 ore

Il D.Lgs. 138/2024, che recepisce la NIS2 in Italia, mette la gestione degli incidenti tra gli elementi minimi delle misure di sicurezza dei soggetti essenziali e importanti (art. 24, comma 2, lettera b). L'art. 25, comma 5, fissa poi la sequenza verso il CSIRT Italia per gli incidenti significativi:

• una pre-notifica entro 24 ore da quando il soggetto è venuto a conoscenza dell'incidente;
• una notifica entro 72 ore, che aggiorna la pre-notifica con una valutazione iniziale di gravità e impatto e, ove disponibili, gli indicatori di compromissione;
• una relazione finale entro un mese dalla notifica, con la causa originale e le misure di attenuazione adottate.

Il punto operativo sta nella formula del decreto: il termine decorre "da quando sono venuti a conoscenza dell'incidente significativo". Per stare nelle 24 ore con informazioni utili servono qualcuno che si accorga dell'incidente, una cronologia degli eventi e gli indicatori di compromissione: è il lavoro quotidiano di un SOC. Chi notifica, con quali strumenti e con quali criteri di significatività è spiegato in notifica degli incidenti NIS2 e in referente CSIRT.

C'è un secondo aggancio, meno visto: tra gli stessi elementi minimi c'è la sicurezza della catena di approvvigionamento (art. 24, comma 2, lettera d). Un fornitore di SOC accede a log e sistemi critici, quindi va valutato e contrattualizzato con la stessa cura, come spieghiamo in third party risk management. Per il quadro completo degli obblighi c'è la pagina NIS2.

DORA: individuazione e gestione degli incidenti ICT

Per banche, assicurazioni, SGR, istituti di pagamento e di moneta elettronica, e per gli altri soggetti finanziari elencati all'art. 2, il riferimento è il Regolamento (UE) 2022/2554. L'art. 10 chiede meccanismi per individuare tempestivamente le attività anomale e risorse sufficienti per monitorare anomalie, incidenti e attacchi informatici; l'art. 17 un processo per individuare, gestire e notificare gli incidenti connessi alle TIC; l'art. 19 la segnalazione dei gravi incidenti all'autorità competente. Il quadro d'insieme è nella guida a DORA.

Come lavoriamo: dall'assessment al presidio 24/7

Il nostro SOC opera dall'Italia, 24 ore su 24, con analisti in Italia e dati trattati in EU. Siamo Managed Security Service Provider autorizzato di Google Cloud SecOps e SentinelOne. Il percorso ha tre fasi.

1. Assessment

Si parte da una call di 30 minuti con il nostro team tecnico. Segue un assessment gratuito: mappiamo asset, fonti di log, superficie d'attacco e gap di copertura, e definiamo quali minacce contano per il tuo settore. Il report resta tuo, anche se decidi di non proseguire.

2. Onboarding e tuning

Colleghiamo le fonti alla piattaforma, scriviamo le regole di detection sul tuo ambiente, riduciamo i falsi positivi e concordiamo i playbook di risposta, compreso cosa possiamo contenere in autonomia e quando ti chiamiamo prima. L'onboarding tipico richiede poche settimane: il tempo dipende soprattutto da quante fonti vanno collegate.

3. Presidio 24/7

Il SOC monitora, indaga, contiene e fa threat hunting. La presa in carico si misura in minuti, non in ore. Ricevi report mensili con i KPI di postura e hai un riferimento dedicato, non una coda di ticket.

Lo stack

• Google SecOps come piattaforma. Google la descrive come un'esperienza unificata di SIEM, SOAR e threat intelligence, con 12 mesi di retention dei dati a caldo già nel pacchetto Standard. Cos'è e come funziona è in Google SecOps: cos'è e come funziona.
• Mandiant per l'intelligence sulle minacce, integrata nel lavoro di detection e di indagine.
• SentinelOne su endpoint e server, per isolare la macchina compromessa e contenere l'attacco.
• Wiz per la postura del cloud e delle identità, i cui rischi arrivano nel SIEM (come, lo spiega Wiz e Google SecOps), più Horizon3 e Detectify per pentest automatici e superficie esterna.

Sopra la piattaforma lavora l'approccio Agentic SOC: agenti AI che accelerano triage e prime verifiche, analisti che prendono le decisioni che contano. Meno alert, più decisioni. E la retention conta più di quanto sembri: M-Trends 2026 cita minacce come BRICKSTORM con permanenze vicine ai 400 giorni, e osserva che una conservazione dei log di 90 giorni lascia senza visibilità sul vettore d'ingresso.

Cosa serve da parte tua

Un SOC gestito non è una delega a scatola chiusa. Per partire bene servono poche cose, ma servono davvero:

• Un referente interno con l'autorità di decidere durante un incidente, e un suo sostituto raggiungibile.
• Accesso alle fonti: endpoint, Active Directory o identity provider, firewall, cloud, posta. Ogni fonte che resta fuori è un angolo cieco.
• Un inventario degli asset, anche imperfetto: sapere quali sistemi sono critici decide le priorità del triage.
• Le regole d'ingaggio: cosa il SOC può isolare senza chiamarti, chi va chiamato di notte e in che ordine.
• Le fondamenta: MFA, backup testati e patch management. Il monitoraggio moltiplica il valore di queste misure, non le sostituisce.

Se una di queste voci manca, non è un motivo per rimandare: è il primo punto del piano che esce dall'assessment.

Se hai già un SIEM: QRadar, Splunk, Sentinel

Molte aziende arrivano al SOC gestito con un SIEM già in casa. Le strade sono due: tenerlo e farlo presidiare, oppure cogliere il momento per migrare. Per chi è su QRadar la domanda è ormai concreta, e le opzioni sono messe in fila in QRadar end of life: cosa fare.

Una migrazione verso Google SecOps fatta bene segue cinque fasi: inventario di fonti e detection, mapping dei log sul modello dati UDM, riscrittura delle regole in YARA-L, parallel run con i due sistemi accesi, cutover. La regola che non si tratta: il vecchio SIEM si spegne per ultimo, dopo aver verificato che il nuovo vede davvero gli attacchi. Il percorso fase per fase è in migrare da QRadar a Google SecOps, i fattori di costo in quanto costa una migrazione SIEM.

Se sul tavolo c'è anche Microsoft Sentinel, sono due piattaforme solide con modelli diversi di costo e di integrazione: il confronto sui criteri è in Google SecOps vs Microsoft Sentinel. E se il dubbio è se ti serve un SIEM o basta raccogliere i log, parti da log management vs SIEM.

Errori comuni e come scegliere il partner

Nelle offerte di SOC gestito gli errori si ripetono, e quasi tutti nascono dal confrontare la cosa sbagliata.

1. Confrontare i canoni invece degli SLA. Chiedi tempo di presa in carico e tempo di contenimento, come si misurano e quando parte il cronometro. È il metro che conta.
2. Comprare allerta, non risposta. Una mail alle 3 di notte non è detection and response. Chiedi cosa succede dopo l'alert, chi lo fa e con quali autorizzazioni.
3. Un 24/7 solo sulla carta. Fuori orario ci sono analisti al lavoro o solo notifiche automatiche?
4. Dati e regole prigionieri. Di chi sono log, detection e playbook se cambi fornitore? Il piano d'uscita si concorda prima di entrare.
5. Onboarding senza tuning. Un servizio che non calibra le regole sul tuo ambiente eredita lo stesso rumore, solo su un'altra coda.
6. Trascurare lingua e contesto. Durante un incidente si parla con direzione, legali e a volte con il CSIRT Italia: conta un interlocutore che conosce NIS2 e DORA e lavora nel tuo fuso orario.

Una checklist più ampia, valida per qualunque fornitore di sicurezza, è in come scegliere un'azienda di cybersecurity. La differenza tra un MSP generalista e un fornitore di sicurezza gestita è in managed service provider.

Da cosa dipende il costo di un SOC gestito

Non esiste un listino unico, e un prezzo dato prima di aver visto il perimetro dice poco. I fattori che spostano il canone sono sempre gli stessi:

• Perimetro: numero di endpoint, server, utenti e ambienti cloud.
• Volume di log: quanti dati si raccolgono e si analizzano. Pesa soprattutto sulla piattaforma: Google, per esempio, offre SecOps a pacchetti basati sull'ingestione.
• Copertura: orario d'ufficio oppure 24/7 con persone.
• Profondità: solo monitoraggio e allerta, oppure anche indagine, contenimento e threat hunting.
• Piattaforma: già tua o inclusa nel servizio. Tenere separate le due voci evita sorprese al rinnovo.
• Punto di partenza: un SIEM da migrare o molte fonti da collegare da zero cambiano il lavoro di onboarding.

Il termine di paragone resta il costo di fare da sé, con i sei analisti necessari per coprire i turni. Le voci una per una sono in quanto costa un SOC gestito. La stima sul tuo perimetro la facciamo dopo l'assessment, non prima.