MTTR: significato, calcolo e differenza con MTTD

La risposta breve: MTTR significa Mean Time To Respond (in alcune definizioni Mean Time To Remediate) ed è il tempo medio che serve per reagire a un incidente una volta che lo hai visto, dal primo allarme al contenimento. Si calcola dividendo il tempo complessivo impiegato per chiudere gli incidenti di un periodo per il numero di incidenti dello stesso periodo. È una delle metriche che dice di più sulla salute reale delle tue security operations, perché misura non quanto sei attrezzato in teoria, ma quanto sei veloce quando succede davvero.

Cos'è il MTTR, in parole semplici

MTTR è la media del tempo che passa tra il momento in cui un incidente viene rilevato e il momento in cui viene chiuso. La sigla è la stessa, ma dietro ci sono due letture leggermente diverse che vale la pena tenere distinte.

• Mean Time To Respond: il tempo per iniziare a reagire, cioè per prendere in carico l'allarme e mettere in campo le prime azioni di contenimento.
• Mean Time To Remediate: il tempo per chiudere del tutto, cioè per rimuovere la minaccia e riportare i sistemi in sicurezza.

Nel linguaggio quotidiano del mid-market le due si sovrappongono spesso, e va bene così: il concetto che conta è uno solo, quanto tempo passa dall'allarme alla fine dei giochi. Più questo numero è basso, meno margine ha l'attaccante.

Cosa si intende per MTTR: quattro R, non una

Se cerchi il significato della sigla trovi definizioni diverse, e non è un errore di qualcuno: la R cambia a seconda del mondo in cui ti trovi.

• Mean Time To Respond, tempo medio di risposta: quanto passa dal rilevamento alle prime azioni di contenimento. È l'accezione più usata nelle security operations.
• Mean Time To Remediate, tempo medio di rimedio: quanto passa dal rilevamento alla rimozione completa della minaccia. Anche questa è cybersecurity.
• Mean Time To Repair, tempo medio di riparazione: quanto dura l'intervento tecnico su un sistema guasto. Viene dalla manutenzione industriale e dall'IT operations.
• Mean Time To Recovery (o Restore), tempo medio di ripristino: l'intero periodo di indisponibilità, dal guasto al servizio di nuovo in piedi.

La differenza pratica è dove metti il traguardo: la risposta finisce quando l'attaccante è fermo, la riparazione quando la macchina riparte. Quando leggi MTTR in un report di sicurezza si intende quasi sempre risposta o remediation di un incidente, ed è di questo che parliamo qui.

MTTR e MTBF non misurano la stessa cosa

Un'altra confusione ricorrente riguarda il MTBF (Mean Time Between Failures), il tempo medio di funzionamento tra un guasto e il successivo. Il MTBF racconta quanto un sistema è affidabile, il MTTR quanto sei rapido a rimetterlo in piedi: messi insieme danno la disponibilità del servizio. In security operations il MTBF serve a poco, perché un attacco non è un guasto casuale che si presenta con una sua frequenza media: le metriche che governano il rischio restano MTTD e MTTR.

MTTD e MTTR: differenza, formule ed esempio

Qui casca molta gente. Il MTTR misura la reazione dopo che hai visto l'attacco. Ma prima ancora c'è il tempo per accorgersene, e quello ha un nome diverso: MTTD, Mean Time To Detect. La finestra totale in cui sei esposto è la somma dei due.

• MTTD: quanto tempo passa tra l'intrusione e il momento in cui te ne accorgi.
• MTTA (Mean Time To Acknowledge): quanto tempo passa tra l'allarme e il momento in cui qualcuno lo prende in carico. È il pezzo che di notte e nel weekend si allunga di più.
• MTTR: quanto tempo passa tra l'allarme e il contenimento.

Le formule sono le stesse per entrambe le metriche, cambia solo cosa misuri: MTTD = tempo totale di rilevamento diviso il numero di incidenti, MTTR = tempo totale di risposta diviso il numero di incidenti.

Un esempio per fissare l'ordine delle cose. Un attaccante entra il primo del mese. Il tuo presidio se ne accorge il quindici: sono quattordici giorni di MTTD. Da lì scatta la risposta, che si chiude in novanta minuti: quello è il MTTR. Il lettore che guarda solo il MTTR vede una security operation rapidissima, ma l'azienda è rimasta scoperta per due settimane. Se nello stesso mese chiudi altri due incidenti in trenta e sessanta minuti, il MTTR del periodo è la media dei tre, cioè sessanta minuti (i numeri sono un esempio didattico, non un benchmark).

Puoi avere un MTTR bassissimo e restare comunque esposto per settimane, semplicemente perché non hai visto nulla per settimane. Per questo le due metriche vanno lette insieme: abbiamo dedicato un pezzo intero al primo tempo, quello della scoperta, in quanto tempo serve per accorgersi di un attacco. La metrica gemella che tiene insieme intrusione e scoperta è il dwell time, che vale la pena conoscere per capire il quadro completo.

Perché il MTTR conta davvero

Il MTTR non è un numero da dashboard per far contento il management. È, molto concretamente, la finestra di tempo in cui l'attaccante lavora indisturbato. In quella finestra fa le cose che fanno male: si muove lateralmente da una macchina all'altra, cerca le credenziali di amministratore, individua i backup per neutralizzarli, esfiltra i dati e, quando è pronto, cifra tutto.

Ogni ora in meno sul MTTR è un pezzo di questa catena che l'attaccante non riesce a completare. Contenere in dieci minuti significa spesso fermarlo prima che arrivi ai sistemi critici. Contenere in dieci giorni significa, il più delle volte, gestire un disastro invece di un incidente. Non a caso l'analisi IBM sul costo delle violazioni mostra da anni che le aziende che contengono in fretta pagano molto meno di quelle che ci mettono mesi: la velocità di risposta si traduce direttamente in euro. Per il quadro italiano, con i settori più colpiti e le tecniche più frequenti, abbiamo raccolto i numeri in attacchi cyber in Italia.

Quanto dovrebbe essere basso? I benchmark di settore

La domanda giusta non è "qual è il numero perfetto", perché non esiste un valore valido per tutti: dipende dal settore, dalla superficie di attacco e dalla maturità delle operations. La domanda giusta è "di che ordine di grandezza stiamo parlando".

Il riferimento più citato è il report Mandiant M-Trends 2025, che misura da anni i tempi di permanenza degli attaccanti. La tendenza è di un miglioramento globale, ma con un dato che resta scomodo: quando la minaccia viene scoperta internamente, e non segnalata da terzi, i tempi si allungano. In parole povere, molte aziende scoprono di essere state colpite perché glielo dice qualcun altro, non perché se ne sono accorte da sole.

La lettura pratica per il mid-market è questa: l'obiettivo realistico non è raggiungere un numero magico, ma spostare il baricentro dalle ore ai minuti sulla risposta, e dai mesi ai giorni sulla scoperta. È un percorso, non un interruttore.

Come si riduce il MTTR (sul serio)

Il modo sbagliato di abbassare il MTTR è comprare l'ennesimo strumento e aggiungerlo alla pila di console che qualcuno, in teoria, dovrebbe guardare. Più strumenti scollegati non abbassano il tempo di risposta, lo alzano, perché aumentano il rumore. Il modo giusto passa da quattro leve.

1. Detection continua, 24/7. Non puoi rispondere a ciò che non vedi. Il presidio deve coprire notte e weekend, perché è esattamente lì che gli attaccanti preferiscono muoversi: quando in azienda non c'è nessuno a guardare.
2. Playbook di risposta già pronti. Quando scatta l'allarme non è il momento di improvvisare. Avere procedure definite per i casi ricorrenti, chi isola cosa, chi decide, chi comunica, taglia via i minuti persi a capire cosa fare.
3. Automazione e agenti sulle azioni ripetitive. Isolare un endpoint compromesso, bloccare un account, arricchire un alert con il contesto: sono azioni che una risposta automatizzata esegue in secondi, liberando gli analisti per le decisioni che richiedono davvero una testa umana.
4. Correlazione, non accumulo di alert. Il valore non sta nel generare più allarmi, ma nel collegarli tra loro per capire in fretta se sono lo stesso incidente. Meno rumore, decisioni più rapide, MTTR più basso.

Queste quattro leve hanno un tratto in comune: richiedono un presidio che lavori in continuo e capacità che non si improvvisano. Per il mid-market costruirle in casa, con un team interno h24, è raramente sostenibile. È qui che entra in gioco il SOC gestito: porta detection continua e capacità di risposta senza dover assumere e trattenere un team di analisti su tre turni. Se il concetto è nuovo, il punto di partenza è cos'è un SOC e come funziona.

Come si misura il MTTR in pratica

Per usare il MTTR come metrica di governo, e non come numero buttato in una slide, non basta applicare la formula vista sopra. La media da sola inganna, e vale la pena tenere a mente tre accortezze.

• Definisci quando parte il cronometro e quando si ferma. Il MTTR ha senso solo se tutti concordano su cosa conta come "rilevamento" e cosa come "contenimento". Senza una definizione condivisa, confronti numeri che misurano cose diverse.
• Guarda anche la mediana, non solo la media. Un singolo incidente gestito malissimo può gonfiare la media e nasconderti che il grosso dei casi va bene, o viceversa. La mediana racconta il caso tipico, la media pesa gli estremi.
• Segmenta per gravità. Il tempo di risposta a un alert di bassa priorità e quello a un ransomware in corso non vanno mescolati. Un MTTR medio basso può nascondere una risposta lenta proprio sugli incidenti che contano.

La cosa importante non è ossessionarsi sul decimale, ma seguire il trend nel tempo: il MTTR sta scendendo mese dopo mese? Se sì, le leve che hai messo in campo stanno funzionando. Se resta piatto, è il segnale che manca qualcosa a monte, di solito la detection continua o i playbook.

In sintesi

Il MTTR è il tempo che passa tra l'allarme e il contenimento, ed è la finestra in cui l'attaccante decide se il tuo sarà un incidente gestibile o un disastro. Va letto insieme al MTTD, perché la vera esposizione è la somma dei due. E si abbassa non accumulando strumenti, ma costruendo detection continua, playbook e automazione, con un presidio che c'è anche quando in azienda non c'è nessuno.

Se vuoi capire come si mette in pratica tutto questo, il punto di partenza sono i nostri servizi di observability e SecOps: è il modo con cui AmagisTech porta il tempo di risposta dalle ore ai minuti per le aziende mid-market italiane.