Procedura - Incident di servizio (cloud / SaaS)

Scopo Gestire gli incidenti di servizio: eventi che degradano o interrompono la disponibilità, le prestazioni o funzionalità percepite dagli utilizzatori della…

Scopo

Gestire gli incidenti di servizio: eventi che degradano o interrompono la disponibilità, le prestazioni o funzionalità percepite dagli utilizzatori della piattaforma erogata in cloud, esclusi gli incidenti la cui natura primaria è sicurezza delle informazioni o violazione di dati personali (gestiti da altre procedure).

Distinzione da altri processi

Tipo di evento Riferimento principale
Servizio (down, latenza eccessiva, errori applicativi diffusi, malfunzionamento funzionale) Questa procedura.
Sicurezza (sospetta intrusione, abuso account, malware, indicazioni di attacco) Procedura - Incident response.
Dati personali / notifiche GDPR Procedura - Data breach e notifica e DPA.

Se durante un incidente di servizio emergono indizi di incidente di sicurezza, si sospende la trattazione puramente “operativa” e si coinvolge immediatamente il processo di incident response sicurezza.

Classificazione impatto (orientativa)

Le etichette servono a prioritizzare il lavoro interno; i tempi verso il cliente dipendono da contratto, SLA negoziati o canale di supporto concordato, ove presenti.

Livello Descrizione sintetica
P1 – Critico Servizio di produzione largamente non utilizzabile o interrotto per molti utenti; oppure perdita di dati lato applicativo (non confondere con breach privacy).
P2 – Maggiore Degradazione significativa ma con workaround parziale, o impatto limitato a un sottoinsieme di funzioni/tenant.
P3 – Minore Anomalie localizzate, cosmetiche o con impatto basso; possono essere pianificate in release successiva.

Rilevamento

Gestione operativa

  1. Registrazione: creare un record nel sistema di tracking usato dall’organizzazione (ticket/issue) con classificazione impatto, sintomi, orario di rilevazione e servizi coinvolti.
  2. Triage: assegnare un coordinatore dell’incidente; verificare se si tratta solo di servizio o anche di sicurezza.
  3. Contenimento / mitigazione: rollback, feature flag, scalabilità, fix temporaneo o permanente, secondo quanto applicabile.
  4. Comunicazioni: aggiornare gli stakeholder interni; verso il cliente comunicare in modo proporzionato allo impatto e ai canali previsti. Salvo diversi accordi contrattuali, non si assume un obbligo di aggiornamento continuo 24/7 verso tutti i clienti: si applica ragionevolezza e, per P1, lo sforzo di comunicazione è massimo compatibilmente con la risoluzione tecnica e con eventuali finestre orarie definite per il rapporto commerciale.
  5. Chiusura: ripristino del servizio accettato; chiusura del ticket con sintesi di causa radice (anche ad alto livello) e azioni correttive o di follow-up.
  6. Post-incident: per P1 e P2 ricorrenti, documentare in tracking interno le lezioni apprese e collegare eventuali change o problem record (Procedura - Problem management).

Output attesi

Riesame

La procedura è riesaminata almeno annualmente o dopo cambiamenti rilevanti del modello di supporto o del perimetro di servizio.

Ultimo aggiornamento: maggio 2026