Gestione Incidenti IT Aziendale: Processo e Best Practice [2026]

Una PMI italiana subisce in media 12 incidenti IT significativi all'anno — dalla stampante che non stampa al server che non risponde. La differenza tra chi ci mette 15 minuti a risolvere e chi ci mette 3 giorni non è la tecnologia: è il processo. BullTech Informatica, MSP attivo dal 2009 a Vimercate (MB) con oltre 200 clienti B2B, ha gestito più di 15.000 incidenti IT con un MTTR medio sotto le 2 ore per incidenti critici. Ecco come strutturare un processo che funziona.

Framework ITIL per incident management

ITIL (Information Technology Infrastructure Library) è il framework di riferimento mondiale per la gestione dei servizi IT. Non devi implementare tutto ITIL — basta il modulo di incident management. Il concetto è semplice: ogni interruzione o degrado di un servizio IT è un "incidente". Ogni incidente deve essere registrato, classificato, assegnato, risolto e documentato. Sembra banale, ma il 60% delle PMI gestisce gli incidenti IT via email e passaparola — e il risultato è che gli incidenti si ripetono, i tempi di risoluzione si allungano e nessuno sa quanto costa il downtime.

Classificazione incidenti: P1, P2, P3, P4

Non tutti gli incidenti sono uguali. Un server ERP offline è diverso da una stampante inceppata. La classificazione ITIL usa due variabili: impatto (quanti utenti/processi coinvolti) e urgenza (quanto velocemente serve la risoluzione). La combinazione determina la priorità.

La classificazione deve essere chiara e condivisa. Gli utenti tendono a considerare tutto "urgentissimo". Definisci criteri oggettivi: P1 = più di 10 utenti impattati O sistema critico down. P2 = 3-10 utenti O servizio degradato. P3 = 1-2 utenti, servizio non critico. P4 = nessun impatto immediato.

Il processo di gestione incidenti: 6 fasi

1. Detection (rilevamento)

L'incidente può essere rilevato in due modi: l'utente segnala il problema (via ticket, email o telefono), oppure il sistema di monitoring lo rileva automaticamente. Il secondo è meglio del primo: con un SIEM o un sistema di monitoring come Zabbix o PRTG, scopri i problemi prima che gli utenti se ne accorgano. Esempio: il server risponde lentamente alle 14:00, il monitoring genera un alert, il tecnico interviene prima che alle 14:30 gli utenti inizino a chiamare.

2. Triage (classificazione e assegnazione)

Chi riceve l'alert o il ticket lo classifica (P1-P4) e lo assegna al tecnico giusto. Il triage deve essere veloce: per un P1, non puoi perdere 20 minuti a decidere chi lo gestisce. Definisci in anticipo la matrice di assegnazione: incidenti di rete = tecnico A, incidenti server = tecnico B, incidenti applicativi = tecnico C. Per BullTech, il triage P1 avviene entro 5 minuti dall'alert.

3. Containment (contenimento)

Prima di risolvere, contieni il danno. Se un PC ha un ransomware, isolalo dalla rete immediatamente — non cercare di capire cos'è mentre cripta i file server. Se il server è sotto attacco DDoS, attiva le regole di mitigazione. Se un database è corrotto, blocca gli accessi prima che i dati danneggiati si propaghino alle repliche. Il contenimento limita il raggio d'azione dell'incidente.

4. Eradication (eliminazione della causa)

Trova e rimuovi la causa root. Il malware va rimosso (non solo messo in quarantena). La vulnerabilità che ha permesso l'accesso va patchata. La configurazione errata va corretta. L'errore umano va prevenuto con formazione o automazione. Se risolvi il sintomo senza eliminare la causa, l'incidente si ripeterà.

5. Recovery (ripristino)

Ripristina il servizio alla normalità. Potrebbe significare riavviare un server, ripristinare da backup, ricostruire un endpoint, riconfigurare un servizio. Il recovery deve essere verificato: non basta dire "il server è tornato online" — bisogna verificare che tutte le applicazioni funzionino, che i dati siano integri, che gli utenti possano lavorare.

6. Lessons learned (post-mortem)

Dopo ogni incidente P1/P2, fai un post-mortem entro 48 ore. Cosa è successo? Perché? Cosa abbiamo fatto bene? Cosa possiamo migliorare? Quali azioni correttive implementiamo? Senza post-mortem, gli stessi incidenti si ripetono. BullTech conduce post-mortem strutturati e condivide il report con il cliente.

Tool per la gestione incidenti

KPI: come misurare la gestione incidenti

Senza metriche, non sai se stai migliorando o peggiorando. I KPI essenziali:

• MTTA (Mean Time To Acknowledge): tempo medio dalla segnalazione alla presa in carico. Target BullTech: P1 < 15 min, P2 < 30 min.
• MTTR (Mean Time To Resolve): tempo medio dalla segnalazione alla risoluzione. Target: P1 < 4h, P2 < 8h, P3 < 24h.
• First-contact resolution rate: % di incidenti risolti al primo contatto senza escalation. Target: > 70% per P3/P4.
• SLA compliance: % di incidenti risolti entro gli SLA concordati. Target: > 95%.
• Incident recurrence rate: % di incidenti che si ripetono. Se è alta, i post-mortem non funzionano.

Escalation matrix: chi chiamare e quando

Definisci in anticipo la catena di escalation. Esempio per i clienti BullTech:

Livello 1 (Service Desk): primo contatto, triage, risoluzione P3/P4. Se non risolve in 30 minuti, escala. Livello 2 (Senior Engineer): incidenti P2 e P3 non risolti dal L1. Competenze specialistiche (networking, security, cloud). Se non risolve in 2 ore per P2, escala. Livello 3 (Specialist/Vendor): incidenti P1 e P2 complessi. Coinvolgimento del vendor (Microsoft, Fortinet, SentinelOne) se necessario. Management: notifica automatica per tutti i P1. Comunicazione al cliente entro 30 minuti per P1.

Come BullTech gestisce gli incidenti per i clienti

BullTech offre un servizio di incident management completo per i clienti con contratto MSP. Come punto di riferimento per la sicurezza informatica Milano, il nostro servizio include: monitoring proattivo 24/7 con Zabbix e PRTG (rileviamo i problemi prima degli utenti), ticketing centralizzato con SLA garantiti (P1 risposta 15 min, H24 per incidenti critici), team di 8 tecnici specializzati con escalation strutturata, post-mortem per ogni incidente P1/P2 con action plan, report mensile con KPI: MTTR, MTTA, SLA compliance, trend.

Per i clienti senza contratto MSP, offriamo supporto a chiamata con tempi di risposta best-effort. Ma consigliamo il contratto MSP: quando hai un P1 alle 2 di notte, non vuoi aspettare 8 ore per una risposta. Se stai cercando un servizio di help desk IT outsourcing, il nostro team è strutturato per gestire escalation H24 con SLA contrattuali.

Domande frequenti sulla gestione incidenti IT