Procedura - Incident response

Scopo

Gestire gli incidenti di sicurezza delle informazioni su tutto il ciclo: rilevamento e valutazione degli eventi, triage, contenimento, analisi, risoluzione, comunicazioni proporzionate e lezioni apprese, in coerenza con il piano di risposta agli incidenti dell’ISMS (dettaglio operativo e versioni correnti disponibili su richiesta formale per audit e committenze) e con le buone pratiche del framework ISO/IEC 27035 (gestione degli incidenti di sicurezza informatica).

Per disservizi di servizio senza primaria natura di sicurezza si applica la Procedura - Incident di servizio (cloud / SaaS). Per violazioni di dati personali e notifiche GDPR si applica la Procedura - Data breach e notifica e il DPA con il titolare/cliente.

Contatti e canali (intake)

Ruolo	Contatto
Coordinamento IRT / funzione CSIRT aziendale, DPO, sicurezza ISMS, referente tecnico (organizzazione ridotta: stessa persona)	Marcello Ricci — mricci@flowvenue.com
Apertura segnalazione (incidente di sicurezza, disservizio, richiesta di supporto collegata)	info@flowvenue.com — WhatsApp +39 350 998 6359

Sostituzioni formali di figure (es. assenza prolungata) e finestre temporali di notifica verso la committenza (es. richieste tipo “entro 1 ora dalla classificazione”) si definiscono per iscritto negli accordi contrattuali ove richiesto dal capitolato.

Rilevamento, valutazione e correlazione (funzione “detect”)

1. Fonti: monitoraggio e allarmi (CloudWatch e osservabilità applicativa), log di sicurezza e operativi rilevanti, segnalazioni interne, segnalazioni del cliente tramite canali concordati.
2. Valutazione tempestiva: classificare la severità (critical / high / medium / low), stimare l’impatto su dati e servizi e assegnare un coordinatore dell’incidente.
3. Correlazione: incrociare evidenze su più fonti (es. applicativo + CloudTrail / log infrastruttura) per ricostruire timeline e portata, prima di comunicazioni esterne.

Triage e coordinamento

1. Triage: verificare se l’evento è solo operativo, incidente di sicurezza, o anche data breach; attivare il perimetro procedurale corretto.
2. Team di risposta: il coordinamento tecnico-organizzativo della fase di contenimento, analisi e risoluzione è assunto da un team di risposta agli incidenti interno (funzioni sicurezza/operations/sviluppo secondo ruoli ISMS). La letteratura di settore può riferirsi a IRT o CSIRT aziendale; non implica per sé adesione o segnalazione obbligatoria verso CSIRT Italia o altri CSIRT di comunità, salvo quanto previsto per commessa (vedi sotto).
3. Allineamento ISO/IEC 27035: le fasi operative (rilevamento, contenimento, analisi, risoluzione, chiusura e miglioramento) sono condotte in aderenza ai principi di ISO/IEC 27035; per la parte “parte 2” (linee guida per pianificare e preparare la gestione degli incidenti) si fa riferimento al piano ISMS e al presente documento, aggiornati nei riesami indicati più avanti.

Attività su Flowvenue

1. Aprire l’incidente con severità e record nel sistema di tracking usato dall’organizzazione.
2. Attivare il team di risposta e un canale di comunicazione dedicato (interno).
3. Eseguire contenimento applicativo (revoca token, blocco account, feature flag, limitazioni temporanee).
4. Analizzare root cause e impatto su dati/servizi; documentare evidenze essenziali.
5. Ripristinare l’operatività in modo controllato e comunicare lo stato agli stakeholder secondo policy e accordi.
6. Eseguire post-mortem (ove proporzionato alla gravità) e aggiornare procedure, controlli o risk register se emergono gap.

Attività su AWS

1. CloudWatch: verificare log e metriche correlate all’incidente.
2. IAM / S3 / RDS / ECS: isolare risorse compromesse se applicabile.
3. Applicare remediation infrastrutturali (rotazione credenziali, security group, patch).

Comunicazioni e perimetro degli stakeholder

• Interno: funzioni critiche coinvolte (es. operations, sviluppo, management, legale/privacy se indicazione di breach).
• Cliente / titolare: secondo contratto, DPA e procedure di data breach.
• Fornitori cloud e terze parti: coinvolgimento quando l’incidente attraversa il perimetro del fornitore o richiede supporto infrastrutturale, nel rispetto degli accordi con il subprocessore.

Amministrazione pubblica (committente PA): tempistiche, canali, contenuti delle comunicazioni e eventuale coinvolgimento periodico in momenti di revisione dello stato degli incidenti di interesse si definiscono negli accordi contrattuali e negli allegati di sicurezza della singola commessa, ove applicabile. La presente procedura non sostituisce tali obblighi negoziati.

Metriche degli incidenti di cybersecurity (monitoraggio)

L’organizzazione raccoglie e riesamina indicatori utili al miglioramento continuo, ad esempio (non esaustivo): numero di incidenti per periodo e per fascia di severità, tempi di rilevamento e di contenimento indicativi, incidenti riaperti o recidivi, esiti delle azioni correttive. La dashboard operativa dettagliata e le SLO/SLA verso il cliente restano, ove presenti, nei contratti e nella reportistica concordata.

Esempio pratico

• Accesso sospetto a risorsa:
  • Flowvenue: blocco account/token.
  • AWS: verifica CloudTrail/CloudWatch, rotazione chiavi, hardening delle policy.

Output

• Incident report completo (o sintesi per gravità bassa, secondo policy interna).
• Piano di remediation e prevenzione.
• Aggiornamenti documentali derivati dal post-mortem.

Riesame, collaudo del piano e formazione

1. Riesame della procedura e del piano IR: almeno annuale, oppure dopo un incidente critico, oppure in caso di cambiamenti organizzativi o ambientali significativi (es. nuovo modello di servizio, nuovo perimetro cloud, rilevanti modifiche normative applicabili al contesto).
2. Collaudo / esercitazione: sono condotti esercizi (es. tabletop o simulazioni mirate) a cadenza pianificata e comunque quando l’analisi del rischio o il riesame lo richiedono, per verificare ruoli, contatti e passi operativi.
3. Aggiornamenti materiali del piano: in corrispondenza di revisioni sostanziali del piano di risposta, gli operatori coinvolti ricevono briefing / aggiornamento formativo sulle modifiche; dove opportuno si programma simulazione o esercizio ridotto sulle parti cambiate.
4. Lezioni apprese: gli esiti della gestione incidenti e del post-mortem alimentano gli aggiornamenti del piano e delle procedure, chiudendo il ciclo di miglioramento continuo.

Frequenza operativa

A evento (ogni incidente di sicurezza), integrata dai riesami e dalle attività di collaudo / formazione di cui sopra.

Documentazione contrattuale da integrare ove richiesta dalla commessa

Per rispondere in modo completo a questionari o capitolati che citano espressamente i seguenti punti, è necessario armonizzare la presente procedura con clausole contrattuali e allegati (offerta tecnica, SLA, piano di sicurezza, DPA):

Tema	Cosa formalizzare in contratto / allegati
Notifica all’Amministrazione per incidenti di sicurezza o cloud con impatto sul servizio	Canale (es. PEC, portale, referente), soglie di impatto, tempistiche, contenuto minimo della comunicazione.
Segnalazione volontaria o obbligatoria a CSIRT Italia (o altri CSIRT di comunità)	Presenza/assenza dell’obbligo, modalità, ruoli e responsabilità tra fornitore e committente.
Coinvolgimento periodico della PA in condivisione o revisione dello stato degli incidenti	Calendario, livello di dettaglio, riservatezza, NDA.
CERT come struttura nominata o dedicata	Se il capitolato richiede un CERT con requisiti specifici, nominare la struttura o il fornitore esterno e allegare SOW/SLA; l’IRT interno copre il coordinamento operativo salvo diverso accordo.
Metriche e reporting verso il committente	KPI concordati, frequenza report, strumenti di export evidenze.

Ultimo aggiornamento: maggio 2026