Per quasi due mesi uno dei principali operatori italiani di telecomunicazioni e servizi cloud ha convissuto con un incidente ransomware senza darne notizia pubblica. La vicenda Retelit è emersa il 4 agosto 2026 grazie a un'inchiesta di IrpiMedia, dopo che il gruppo Qilin aveva già pubblicato online centinaia di gigabyte di documenti interni. Non è solo la storia di un'azienda violata: è un caso di scuola su cosa succede quando a essere colpito è un fornitore su cui poggiano decine di enti pubblici e imprese strategiche.

I fatti, in ordine

La ricostruzione incrociata delle fonti disponibili delinea questa sequenza:

  • 8 giugno 2026 — data dell'attacco secondo la stessa Retelit, che nel proprio diritto di replica dichiara di averlo notificato alle autorità competenti. Un documento interno consultato da IrpiMedia e datato ai primi giorni di giugno descrive l'incidente, il che colloca la scoperta in quel periodo.
  • 11 luglio 2026 — Qilin inserisce Retelit S.p.A. nel proprio sito di leak, classificandola nel settore Business Services / Telecommunications. La rivendicazione viene ripresa il giorno successivo dal blog di settore Bismark, senza conferme ufficiali.
  • 14 luglio — il gruppo pubblica un sample di documenti interni e passaporti, la prova classica del possesso dei dati.
  • 30 luglio – 1 agosto — riscatto evidentemente non pagato: Qilin diffonde il grosso del materiale. La pagina pubblica indica circa 270.000 file; IrpiMedia stima almeno 300 GB. Sempre il 30 luglio CERT-AGID viene a conoscenza dell'incidente e comincia ad avvisare i referenti per la sicurezza delle pubbliche amministrazioni potenzialmente coinvolte.
  • 4-6 agosto — pubblicazione dell'inchiesta e replica dell'azienda.

Sulla dinamica tecnica, secondo una fonte vicina all'evento l'attacco sarebbe partito dal computer di un amministratore di sistema, dal quale sono state carpite credenziali poi usate per movimenti laterali fino all'infrastruttura di virtualizzazione. Il presidio SOC non avrebbe rilevato né i movimenti laterali né la cifratura dei server finché non era troppo tardi.

Retelit ridimensiona il perimetro: l'incidente avrebbe riguardato 3 dei 38 data center nazionali, pari a circa il 7% dei sistemi distribuiti nei data center, senza coinvolgere la parte di connettività. L'azienda dichiara di aver informato i clienti impattati, ACN, il CSIRT, la Polizia Postale e, in via cautelativa, il Garante privacy, e di aver istituito una war room con il supporto di società di incident response e analisi forense. Conferma inoltre di aver osservato "evidenze compatibili con una esfiltrazione di dati". IrpiMedia ha successivamente indicato i tre siti come Verona, Roma e Milano, precisando che proprio quello di Milano è certificato da ACN per la gestione dei backup e la continuità dei servizi.

Sul ripristino, il quadro è meno rassicurante delle percentuali: un cliente riferisce un backup recuperato "solo al 70%", un'azienda del Nord Est dichiara di aver perso in modo irrimediabile le informazioni ospitate nel data center.

Perché il perimetro non si misura in percentuali

Il 7% dei sistemi è un numero rassicurante solo se si guarda l'infrastruttura dall'interno. Dal punto di vista del rischio-Paese, il dato rilevante è un altro: tra i clienti di Retelit figurano Leonardo, almeno tre gestori di identità digitali e 193 pubbliche amministrazioni. Nella comunicazione di CERT-AGID compaiono soggetti come Cineca, Lepida e InfoCamere — conservazione documentale, SPID, firma digitale. L'azienda gestisce inoltre 47.000 km di fibra, oltre 35 data center e la comproprietà di un cavo sottomarino, ed è coinvolta nel dossier di acquisizione di Telecom Italia Sparkle.

Quando il fornitore è un nodo di concentrazione, l'impatto non si calcola sui suoi sistemi: si calcola sui servizi che quei sistemi reggono per conto di terzi.

Cosa significa per le aziende e la PA italiane

Tre lezioni che vale la pena portare in consiglio di amministrazione.

La qualificazione non è un controllo di sicurezza. Il servizio multicloud di Retelit è qualificato ACN per l'uso da parte della PA. Una qualifica attesta che un fornitore ha dimostrato, in un dato momento, il possesso di determinati requisiti: non è un monitoraggio continuo, non sostituisce il vostro audit e non trasferisce il rischio. Chi seleziona un fornitore solo perché "è nell'elenco" sta delegando una decisione che resta sua.

Il rischio non si esternalizza con il workload. Se ospitate dati personali presso un provider, resta il titolare del trattamento a rispondere davanti al Garante. Il provider è responsabile ai sensi dell'art. 28 GDPR e deve assistervi, ma la notifica ex art. 33 — entro 72 ore dalla conoscenza — e l'eventuale comunicazione agli interessati ex art. 34 restano in capo a voi. La domanda operativa da porsi oggi è banale e quasi mai risolta: quanto tempo passa tra il momento in cui il mio fornitore scopre un incidente e il momento in cui lo so io? Se il contratto non fissa un termine in ore, quel tempo è indefinito.

Il backup che non avete testato non è un backup. "Dati immutabili a prova di ransomware" è un claim di marketing, non un controllo. Il ripristino parziale lamentato da più clienti indica che il problema non era necessariamente la cifratura ma il modo in cui i backup erano stati raccolti e verificati. Un restore test documentato, su dati reali e con tempi misurati, vale più di qualsiasi certificazione appesa alla parete.

Il contesto normativo

Un operatore di telecomunicazioni e un fornitore di servizi di cloud computing rientrano tra i soggetti disciplinati dal d.lgs. 138/2024 (recepimento NIS2). Per questi soggetti la catena di notifica al CSIRT Italia è scandita: pre-notifica entro 24 ore dalla conoscenza di un incidente significativo, notifica entro 72 ore, relazione finale entro un mese. Sono termini verso l'autorità, non verso il pubblico: la NIS2 non impone in via generale un comunicato stampa, e questo spiega — senza giustificarla sul piano reputazionale — l'assenza di comunicazione esterna.

Il punto più scomodo riguarda però i clienti. L'art. 24 del d.lgs. 138/2024 include esplicitamente la sicurezza della catena di approvvigionamento tra le misure di gestione del rischio: se siete soggetti NIS2 e un vostro fornitore ICT rilevante viene compromesso, la domanda dell'autorità non sarà "come è successo a loro", ma "come lo avevate previsto nel vostro piano". Per gli operatori finanziari lo stesso ragionamento passa da DORA: registro delle informazioni sui fornitori ICT, clausole contrattuali obbligatorie, strategia di uscita e diritto di audit.

Cosa fare subito

  • Verificate se siete clienti diretti o indiretti. Non solo contratti a vostro nome: chiedete ai vostri fornitori SaaS e ai system integrator dove sono ospitati i loro carichi. La dipendenza di secondo livello è quella che nessuno mappa.
  • Se avete ricevuto una comunicazione dal fornitore, tracciate la data. Serve a ricostruire il decorso delle 72 ore GDPR e a valutare se il ritardo del fornitore ha inciso sui vostri obblighi.
  • Cambiate le credenziali con cui accedete ai portali del fornitore e revocate token e API key emessi verso l'infrastruttura interessata. In un furto di documenti interni finiscono spesso schemi di rete, elenchi di contatti e riferimenti tecnici utili a un attacco successivo.
  • Fate un restore test reale entro questo mese, non una verifica di consistenza. Misurate RTO e RPO effettivi e verbalizzate il risultato.
  • Rivedete le clausole di notifica nei contratti in scadenza: termine massimo in ore per l'informativa al cliente, obbligo di condividere gli indicatori di compromissione, diritto di audit e obblighi in caso di esfiltrazione.
  • Monitorate l'esposizione dei vostri dati nei leak pubblicati: in un dump da 270.000 file possono comparire documenti che vi riguardano anche se non siete stati "la vittima".
  • Se trattate dati personali, valutate fin da subito se l'incidente presso il fornitore configura una violazione da annotare nel registro e, in caso di rischio, da notificare al Garante.

In sintesi

Retelit non è un caso isolato: nel 2026 Qilin è tra i gruppi più attivi contro obiettivi italiani, con vittime che vanno dalle PMI a realtà storiche come Loescher Editore. Quello che rende questa vicenda diversa è il posto che l'azienda occupa nella catena: quando cade un fornitore certificato che serve 193 amministrazioni, il perimetro dell'incidente non coincide con il perimetro dell'azienda. È esattamente il rischio che NIS2 e DORA hanno provato a normare — e che, a giudicare da come è arrivata la notizia ai clienti, molti contratti non coprono ancora.