La violazione è avvenuta fra il 2 e il 18 dicembre 2025. È stata scoperta il 18 dicembre 2025. I clienti hanno iniziato a essere avvisati il 26 giugno 2026. Il numero definitivo delle persone coinvolte — 9.540.683 — è stato comunicato all'autorità sanitaria statunitense e reso pubblico nei primi giorni di settembre 2026.

Nove mesi fra l'intrusione e la conoscenza pubblica della sua dimensione. È questo, più del numero, l'aspetto della vicenda Aesto Health che merita attenzione da questa parte dell'Atlantico.

I fatti

Aesto Health è una società tecnologica di Birmingham, in Alabama, che fornisce a studi medici e strutture sanitarie tre servizi: migrazione sicura dei dati, scambio di cartelle cliniche elettroniche e archiviazione di dati legacy. In altre parole, custodisce i dati che i suoi clienti hanno smesso di usare quotidianamente ma non possono cancellare.

Il 18 dicembre 2025 la società ha identificato un incidente su una parte della propria infrastruttura Amazon Web Services. Gli specialisti esterni incaricati dell'indagine hanno confermato che l'ambiente AWS è stato acceduto da un terzo non autorizzato fra il 2 e il 18 dicembre 2025.

Le informazioni sottratte comprendono nome e cognome, numeri di previdenza sociale, date di nascita parziali, numeri di patente e di documenti di identità statali, numeri di conto finanziario, codici fiscali, cartelle cliniche, anamnesi, informazioni su rimborsi e fatturazione e dati assicurativi sanitari.

I clienti coinvolti sono almeno 35 fra ospedali, cliniche e gruppi medici, distribuiti in numerosi stati. Con 9,5 milioni di persone interessate, si tratta della seconda violazione sanitaria confermata più estesa del 2026 negli Stati Uniti, dietro all'incidente DentaQuest da 15 milioni di record. Aesto Health ha dichiarato di non aver riscontrato evidenze di furto di identità o frode finanziaria collegate alla violazione e ha offerto servizi di monitoraggio del credito.

L'archivio è il punto debole, non l'ospedale

Il dato più istruttivo di questa vicenda è dove è avvenuta la violazione. Non in un ospedale, non in un sistema clinico in produzione: nel magazzino.

Il modello di business di Aesto Health consiste esattamente nel tenere i dati che le strutture sanitarie non usano più — gli archivi dei gestionali dismessi, le cartelle migrate da sistemi spenti anni fa. Sono dati che hanno perso ogni valore clinico e hanno conservato tutto il loro valore identitario. Un'anamnesi del 2011 non serve più a curare nessuno, ma un codice fiscale, un numero di documento e una diagnosi psichiatrica del 2011 valgono per un ricattatore esattamente quanto valevano allora.

Qui si innesta una dinamica che in Italia conosco bene e che vedo ripetersi in quasi ogni assessment nel settore sanitario: gli archivi crescono e l'attenzione alla loro sicurezza decresce. La conservazione è imposta da obblighi normativi, quindi nessuno cancella. Il sistema non è più in produzione, quindi nessuno lo monitora. Il fornitore che lo custodisce è stato scelto anni fa con un contratto orientato al costo per gigabyte, non alle garanzie di sicurezza. Il risultato è un deposito enorme di dati sensibili, sempre più grande, presidiato sempre meno.

Un'infrastruttura di archiviazione ha inoltre un profilo di rilevamento particolarmente sfavorevole. In un sistema in produzione, un'estrazione massiva di dati altera i tempi di risposta, satura le connessioni, disturba gli utenti: qualcuno se ne accorge. In un archivio dove il traffico normale è quasi nullo, non c'è alcun utente da disturbare. Sedici giorni di accesso non autorizzato, in quel contesto, sono un tempo del tutto plausibile — e quello che va misurato non è la lentezza dell'incidente, ma se esistesse un allarme sul volume di letture.

La cronologia che in Europa non reggerebbe

Applichiamo il calendario europeo ai fatti americani, non per fare confronti retorici ma perché è l'esercizio che ogni DPO dovrebbe fare leggendo questa notizia.

Aesto Health, in uno schema GDPR, sarebbe un responsabile del trattamento ai sensi dell'articolo 28. I 35 clienti sanitari sarebbero altrettanti titolari. L'articolo 33, paragrafo 2, impone al responsabile di informare il titolare senza ingiustificato ritardo dopo essere venuto a conoscenza della violazione. Il paragrafo 1 dà al titolare 72 ore, da quando ne viene a conoscenza, per notificare all'autorità di controllo.

Sei mesi fra la scoperta dell'incidente e l'avviso ai clienti non sono compatibili con quel testo. Ma il punto pratico non è la censura al fornitore: è che i 35 titolari erano inadempienti senza saperlo. Ognuno di loro doveva svolgere una propria valutazione del rischio, decidere se notificare all'autorità e se comunicare agli interessati — e ha ricevuto le informazioni necessarie sei mesi dopo. Di fronte al Garante, la responsabilità della notifica resta del titolare. Il contratto con il responsabile è l'unico strumento che ha per governare quel rischio.

Ed è qui la domanda che vale la pena porsi oggi, non dopo un incidente: nel contratto con il fornitore che custodisce i vostri archivi legacy, il termine per la comunicazione di una violazione è espresso in ore o è la formula "senza ingiustificato ritardo" copiata dal regolamento? Ed è previsto che il fornitore consegni non solo la notizia, ma le informazioni minime necessarie a permettervi la valutazione del rischio — categorie di dati, numero di interessati, finestra temporale?

Esiste poi un effetto moltiplicatore tipico di queste architetture: un incidente in un unico responsabile diventa decine di notifiche separate all'autorità. In Italia lo scenario è tutt'altro che teorico. Aziende sanitarie che hanno esternalizzato la conservazione a un unico fornitore, cooperative di medici di medicina generale che condividono lo stesso gestionale, software house sanitarie che ospitano gli archivi di decine di strutture: la geometria è la stessa.

L'articolo 28 richiede che il titolare ricorra unicamente a responsabili che presentino garanzie sufficienti. La sanzione della CNIL all'Hôpital Privé de la Loire, di cui abbiamo scritto il 5 settembre, mostra la direzione in cui si muovono le autorità europee: le garanzie vanno verificate con controlli tecnici concreti, non presunte sulla base di una dichiarazione contrattuale.

Cosa fare subito

  • Mappare chi custodisce i vostri archivi legacy. L'inventario non va costruito per applicazione, ma partendo da una domanda diversa: dove vivono oggi i dati dei sistemi che abbiamo spento? Migrazioni, gestionali dismessi, backup storici presso terzi, copie consegnate a un fornitore durante un cambio di piattaforma.
  • Rivedere i contratti (DPA) con questi fornitori, verificando che prevedano un termine di comunicazione espresso in ore (24-48 è un obiettivo ragionevole), l'obbligo di fornire le informazioni necessarie alla valutazione del rischio, e un diritto di audit esercitabile.
  • Applicare davvero le regole di conservazione anche agli archivi. Un archivio che non è in grado di cancellare i dati oltre il termine di legge non è un servizio: è una passività permanente. Definire i termini per tipologia di dato e chiedere al fornitore la prova documentale delle cancellazioni effettuate.
  • Verificare le misure tecniche minime sugli archivi in cloud: cifratura con chiavi gestite dal cliente, MFA obbligatoria su console e utenze amministrative, eliminazione delle chiavi di accesso statiche a lunga vita, conservazione dei log di accesso per un periodo congruo.
  • Attivare allarmi sul volume, non solo sugli accessi. In un archivio a traffico quasi nullo, un picco di letture o di esportazioni è il segnale più affidabile che esista: è anche l'unico controllo che avrebbe accorciato una finestra di sedici giorni.
  • Provare la catena di notifica prima che serva. Chiedere oggi al fornitore, per iscritto, in quanto tempo vi informerebbe e quali informazioni vi consegnerebbe. La risposta — o la sua assenza — è già un risultato dell'audit.
  • Preparare il percorso delle 72 ore: chi decide, con quale modello precompilato, con quali soglie per la comunicazione agli interessati ai sensi dell'articolo 34.