Report SOC mensile: cosa deve contenere e come leggerlo

Un report SOC mensile utile risponde a tre domande: cosa è successo nel mese (alert e incidenti per gravità, con i tempi di rilevamento e di risposta), quanto vede davvero il SOC (fonti di log attive, fonti che tacciono, falsi positivi) e cosa va fatto adesso (raccomandazioni con un responsabile e una data). Se una delle tre manca, hai un elenco di numeri, non un report.

Qui trovi le sezioni che un report periodico di un SOC gestito deve contenere, come leggerlo in poco tempo, i segnali che dicono che è vuoto e come usarlo con il consiglio di amministrazione e negli audit NIS2 e ISO/IEC 27001. Cosa comprende il servizio nel suo insieme (perimetro, SLA, uscita) è un altro discorso, che trovi in servizio SOC gestito: cosa include e cosa chiedere.

Le sette sezioni di un report SOC mensile

Il formato cambia da fornitore a fornitore, il contenuto no. Un report che regge ha queste sette parti, anche se le chiama in modo diverso.

1. Sintesi per la direzione

Mezza pagina, scritta per chi non legge il resto. Dice se nel mese ci sono stati incidenti rilevanti, se gli impegni di servizio sono stati rispettati, se la visibilità del SOC è cambiata e quali due o tre decisioni servono dall'azienda. Se la sintesi si limita a ripetere i grafici, non sta facendo il suo lavoro.

2. Alert e incidenti per gravità

Il cuore operativo. Un buon report mostra il passaggio dai volumi alle decisioni:

• quanti alert sono arrivati e quanti sono stati analizzati da un analista;
• quanti sono diventati incidenti, divisi per livello di gravità;
• per ogni incidente rilevante: cosa è successo, quali sistemi ha toccato, cosa ha fatto il SOC, cosa resta da fare a te;
• quali eventi sono stati valutati come potenzialmente significativi ai fini della notifica al CSIRT Italia, e con quale esito.

L'ultimo punto conta perché la notifica resta in capo all'azienda: l'art. 25 del D.Lgs. 138/2024 la attribuisce ai soggetti essenziali e importanti, non al fornitore. Il report deve lasciare traccia di come è stata presa la decisione, anche quando la conclusione è stata non si notifica.

3. Tempi di rilevamento e di risposta

Le metriche classiche sono tre:

• MTTD (Mean Time To Detect): il tempo medio per accorgersi di un'attività malevola;
• MTTA (Mean Time To Acknowledge): il tempo medio tra l'alert e la presa in carico da parte di un analista;
• MTTR (Mean Time To Respond): il tempo medio tra l'alert e il contenimento.

Due accorgimenti rendono questi numeri leggibili. Il primo: il report scrive da dove parte e dove si ferma il cronometro, altrimenti due mesi non sono confrontabili. Il secondo: i tempi vanno divisi per gravità e confrontati con gli SLA del contratto, perché una media unica nasconde l'incidente critico gestito in ritardo dietro decine di alert minori chiusi in fretta. Per formule ed esempi c'è la guida su MTTR e MTTD; per il tempo che un attaccante passa nella rete prima di essere scoperto, quella sul dwell time.

4. Falsi positivi e regole modificate

Un SOC che non riduce il rumore finisce per ignorarlo. La sezione dice quanti alert si sono rivelati falsi positivi, quali regole li hanno generati, quali regole sono state modificate, aggiunte o disattivate e perché. La disattivazione di una regola è una scelta che tocca la tua visibilità: va scritta e motivata, non decisa in silenzio.

5. Copertura delle fonti di log

È la sezione che si salta più spesso ed è quella che dice di più. Un SOC non vede quello che non riceve. Il report confronta le fonti previste dal contratto con quelle che hanno inviato dati nel mese, e segnala:

• le fonti che hanno smesso di inviare log, per quanto tempo e con quale causa;
• i sistemi nuovi entrati in azienda e non ancora collegati;
• i casi d'uso di rilevamento che dipendono da una fonte mancante.

Per i soggetti NIS2 il tema ha un riferimento preciso. Le misure di base della determinazione ACN 379907/2025 chiedono, alla misura PR.PS-04, che per i sistemi informativi e di rete rilevanti siano acquisiti e conservati almeno i log necessari al monitoraggio degli eventi di sicurezza (allegati 1 e 2). Per i soggetti essenziali la misura DE.CM-01 (allegato 2, punto 5) elenca anche cosa monitorare: accessi da remoto, attività dei sistemi perimetrali, eventi amministrativi di rilievo, accessi riusciti o falliti a risorse di rete, endpoint e applicativi. Una fonte che tace per tre settimane senza che il report lo dica è un buco in quella misura.

6. Raccomandazioni con stato

Ogni raccomandazione ha un responsabile, una priorità e una data, e il report del mese dopo dice se è stata chiusa. Le raccomandazioni ricorrenti rimaste aperte sono l'informazione più utile per chi decide il budget: indicano dove il rischio resta fermo perché manca una patch, una configurazione o una persona.

7. Trend sui mesi

Un mese da solo dice poco. Il report mette a confronto almeno gli ultimi tre o sei mesi su poche serie: incidenti per gravità, tempi rispetto agli SLA, percentuale di falsi positivi, copertura delle fonti, raccomandazioni aperte. Così si vede se il servizio migliora, se l'ambiente sta cambiando o se un numero è salito per un motivo che merita una domanda.

Come leggerlo in venti minuti

Non serve partire dalla prima pagina. Un ordine che funziona:

1. Copertura delle fonti: se il SOC ha visto meno del solito, tutti gli altri numeri vanno letti con quella lente. Pochi incidenti con molte fonti spente non sono una buona notizia.
2. Incidenti ad alta gravità: cosa è successo, cosa è stato fatto, cosa resta a te.
3. SLA: quali impegni non sono stati rispettati e con quale spiegazione.
4. Raccomandazioni aperte: quali dipendono da te e da quanto tempo aspettano.
5. Trend: cosa è cambiato rispetto ai mesi precedenti e perché.

Se dopo questi cinque passaggi non sai dire se il mese è andato meglio o peggio del precedente, il problema è il report, non la tua lettura.

I segnali di un report vuoto

Alcuni report periodici sono generati in automatico dalla console e spediti così come escono. Si riconoscono da alcuni segnali:

• solo volumi (eventi raccolti, alert generati) senza dire quanti sono stati analizzati e con quale esito;
• nessuna menzione delle fonti di log, oppure un elenco statico identico ogni mese;
• tempi medi senza divisione per gravità e senza confronto con gli SLA;
• raccomandazioni generiche (aggiornare i sistemi, formare il personale) che tornano uguali ogni mese, senza responsabile né stato;
• nessun incidente per mesi in un'azienda con centinaia di utenti, senza una riga che spieghi perché;
• nessuna differenza tra un mese e l'altro, salvo le date in copertina;
• nessun nome di un analista o di un referente a cui fare domande.

Un report di questo tipo non dice se il servizio funziona. Se lo ricevi da un fornitore attuale, i criteri per confrontarlo con altri sono nella guida su come scegliere un MSSP in Italia.

Il report davanti al consiglio di amministrazione

Con la NIS2 il report non resta più solo all'IT. L'art. 23 del D.Lgs. 138/2024 stabilisce che gli organi di amministrazione e direttivi dei soggetti essenziali e importanti approvano le modalità di attuazione delle misure di sicurezza, ne sovrintendono l'attuazione e sono responsabili delle violazioni. Il comma 3 aggiunge che questi organi "sono informati su base periodica o, se opportuno, tempestivamente, degli incidenti e delle notifiche di cui agli articoli 25 e 26".

Le misure di base ACN vanno nella stessa direzione: la misura ID.IM-01 prevede che gli organi di amministrazione e direttivi siano informati mediante "apposite relazioni periodiche" sugli esiti del piano di adeguamento (allegati 1 e 2), e per i soggetti essenziali anche sul piano di valutazione dell'efficacia delle misure (allegato 2).

Il report del SOC non è quella relazione, ma ne è una delle fonti principali. Per il CdA conviene estrarne una pagina sola, con:

• gli incidenti rilevanti del periodo e le eventuali notifiche, in linguaggio non tecnico;
• tre indicatori stabili nel tempo, sempre gli stessi (per esempio tempi rispetto agli SLA, copertura delle fonti, raccomandazioni aperte da più di novanta giorni);
• le decisioni richieste: budget, priorità, accettazione formale di un rischio.

Un consiglio che riceve ogni trimestre la stessa pagina impara a leggerla e a fare domande. Un consiglio che riceve quaranta pagine di grafici non la legge.

Il report come evidenza per NIS2 e ISO/IEC 27001

Un report fatto bene è anche materiale di audit. Qualche aggancio concreto:

• NIS2, valutazione dell'efficacia: l'art. 24, comma 2, lettera f) del D.Lgs. 138/2024 include tra le misure minime "politiche e procedure per valutare l'efficacia delle misure di gestione dei rischi per la sicurezza informatica". Tempi, copertura e trend mese su mese sono dati su cui quella valutazione si appoggia.
• NIS2, gestione degli incidenti: la lettera b) dello stesso comma richiede la gestione degli incidenti, e la misura ACN RS.MA-01 chiede che il piano di gestione degli incidenti indichi anche la reportistica da usare per documentarli.
• NIS2, livelli di servizio: la misura DE.CM-01 (punto 2) chiede di definire e documentare i livelli di servizio attesi anche ai fini di rilevare tempestivamente gli incidenti significativi. Il confronto mensile con gli SLA ne è la verifica.
• NIS2, fornitori: la lettera d) richiede la sicurezza della catena di approvvigionamento. Il report è il modo più semplice per dimostrare che il fornitore di sicurezza gestita viene controllato nel tempo, non solo scelto.
• ISO/IEC 27001:2022: il punto 9.1 (monitoraggio, misurazione, analisi e valutazione) e il punto 9.3 (riesame di direzione) richiedono di misurare le prestazioni del sistema di gestione e di portarle alla direzione; il controllo 8.16 dell'Annex A (Monitoring activities) riguarda il monitoraggio di reti, sistemi e applicazioni. I report periodici, conservati e firmati, sono una delle evidenze che un auditor chiede.

Due avvertenze. Il report dimostra il lavoro del SOC, non la conformità dell'azienda: le misure che restano al cliente (patch, configurazioni, governance) vanno documentate altrove. E per servire da evidenza i report vanno conservati con data e versione, non solo letti e cestinati.

Cosa far scrivere nel contratto sul report

Il report si negozia prima di firmare, non dopo il terzo mese deludente. Le voci da mettere per iscritto:

• cadenza (mensile, più una sintesi trimestrale per la direzione) e data di consegna;
• indice delle sezioni, con le metriche e la loro definizione, compreso da dove parte il cronometro;
• confronto con gli SLA per livello di gravità;
• elenco delle fonti di log previste e segnalazione di quelle inattive;
• una riunione di revisione in cui un analista commenta il report e risponde alle domande;
• accesso a una vista in tempo reale, oltre al documento;
• conservazione dei report e loro restituzione a fine contratto.

Se stai confrontando offerte anche sul prezzo, i fattori che lo determinano sono in quanto costa un SOC gestito.

Se vuoi vedere come lavoriamo noi su questi punti, 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 un confronto sul report che ricevi oggi.