Il tuo fornitore SaaS è stato violato — gli obblighi di notifica che restano tuoi

Questo playbook scatta nel momento in cui apprendi che un'organizzazione *fuori* dal tuo controllo — piattaforma SaaS, cloud provider, managed service provider, fornitore di integrazioni, service paghe — ha subito un incidente di sicurezza che può toccare i tuoi dati o l'erogazione dei tuoi servizi.

Copre la domanda che segue: quali notifiche restano tue, ed entro quando.

Non copre la tua incident response interna — se l'attaccante ha anche un foothold nel tuo perimetro, fai girare in parallelo il tuo playbook IR ordinario; questo governa solo il workstream notifiche. Non copre nemmeno la selezione dei fornitori o la negoziazione contrattuale, salvo dove una clausola è l'unica cosa che ti procurerà evidenze in tempo utile.

Il vincolo che definisce tutto: devi notificare su un orologio di legge usando evidenze che controlla un terzo, non obbligato a consegnartele in fretta. Tutto quello che segue discende da qui.

L'errore più costoso è trattarla come una sola scadenza. Sono almeno tre, e partono da momenti diversi.

GDPR (se ci sono dati personali). Ai sensi dell'art. 33(2) il responsabile ti informa "senza ingiustificato ritardo". Le tue 72 ore ex art. 33(1) partono da quando *tu* diventi consapevole — e le Linee guida EDPB 9/2022 sulla notifica di violazione dei dati personali, v2.0 sono esplicite al §44: in linea di principio il titolare va considerato "consapevole" una volta che il responsabile lo ha informato della violazione. La ricezione dell'avviso del fornitore è il tuo trigger. Registrane il timestamp.

> Correggi un mito diffuso prima che ti costi. Si legge spesso che l'EDPB imporrebbe ai responsabili di notificare al titolare entro 72 ore. Non è vero. Il §45 dice chiaramente che il GDPR non prevede un termine esplicito entro cui il responsabile debba avvisare il titolare, se non il "senza ingiustificato ritardo". L'unico termine azionabile verso il fornitore è quello scritto nel tuo contratto — e il §46 prevede espressamente clausole di notifica anticipata a supporto del tuo obbligo delle 72 ore.

NIS2 (se sei soggetto essenziale o importante). La direttiva 2022/2555 all'art. 23(4) fissa early warning a 24 ore, notifica a 72 ore, relazione finale a un mese. Il punto decisivo: il trigger dell'art. 23 è un *incidente significativo che colpisce i tuoi servizi*, non la proprietà del sistema compromesso. La violazione di un fornitore che disturba significativamente il tuo servizio essenziale è un tuo incidente significativo. Da notare anche che il fornitore può avere un obbligo autonomo: il regolamento di esecuzione (UE) 2024/2690 fissa soglie di significatività vincolanti proprio per cloud provider, managed service provider, MSSP e data center.

DORA (se sei entità finanziaria). Il regolamento 2022/2554 art. 19, operativizzato dall'art. 5 del regolamento delegato (UE) 2025/301, impone la notifica iniziale entro 4 ore dalla classificazione dell'incidente come grave e comunque non oltre 24 ore dall'averne avuto conoscenza — condizioni cumulative, non alternative. Relazione intermedia: 72 ore dalla *notifica iniziale*, non dall'awareness. Relazione finale: un mese dall'intermedia. L'art. 5(4) concede una proroga per weekend e festivi fino a mezzogiorno del giorno lavorativo successivo — ma l'art. 5(5) la esclude per enti creditizi, CCP, gestori di sedi di negoziazione e per i soggetti classificati essenziali o importanti ai sensi NIS2. La maggior parte dei lettori di questo playbook ricade nell'esclusione.

Nel primo giorno contano due cose, e nessuna delle due è l'indagine.

1. Stabilisci e registra il tuo timestamp di awareness. Ogni scadenza a valle si calcola da lì, e un regolatore lo ricostruirà a posteriori dalla tua casella di posta, dal ticketing e dalla timeline di disclosure pubblicata dal fornitore. Cattura:

• L'ora esatta di arrivo dell'avviso e il canale (email dell'account manager, status page, trust portal, comunicato stampa o — non di rado — un giornalista).
• Se esisteva un segnale precedente che un osservatore competente direbbe avrebbe dovuto allertarti: un alert di login anomalo da quell'integrazione, un degrado sulla status page, un warning da un partner. Se c'era, documentalo *e* documenta perché non ha scatenato escalation. Nasconderlo è molto peggio che spiegarlo.
• Chi ha ricevuto l'avviso e quando è arrivato alla persona autorizzata a dichiarare l'incidente. Un avviso fermo tre giorni in una casella condivisa è un rilievo di governance, non una difesa.

2. Classifica rispetto a ciascun regime applicabile. Fai girare i test in parallelo, non in sequenza:

• Il fornitore trattava dati personali di cui sei titolare? → valutazione art. 33 GDPR.
• È significativamente disturbato un servizio che eroghi come soggetto essenziale o importante? → art. 23 NIS2.
• Il fornitore supporta una funzione critica o importante? → classificazione art. 19 DORA, e avvia il sotto-orologio delle 4 ore nel momento in cui lo classifichi grave.

Quello che non devi fare in questa finestra è aspettare che il fornitore confermi se il *tuo* tenant è coinvolto. Quella risposta arriva regolarmente dopo settimane. I gate di early warning e notifica iniziale sono preliminari per costruzione.

Al gate delle 72 ore devi una notifica sostanziale, e ti mancheranno ancora fatti che il fornitore non ha rilasciato. Notifica lo stesso, e notifica onestamente.

Struttura la submission attorno a ciò che puoi attestare direttamente:

• Cosa sai: quale fornitore, quale servizio, il resoconto pubblicato dal fornitore con i suoi timestamp, quali tue categorie di dati o processi di business vivono su quella piattaforma, la tua documentazione dei flussi contrattuali.
• Cosa hai valutato in autonomia: la revisione dei tuoi log per l'integrazione coinvolta — grant e consensi OAuth, anomalie nel volume di chiamate API, egress di dati inusuale, autenticazioni di service account da sorgenti nuove. È telemetria che possiedi *tu*, e nella prima settimana è spesso l'unica evidenza indipendente disponibile.
• Cosa è in attesa di conferma dal fornitore: etichettato esplicitamente come tale, con la data in cui l'hai richiesto e il termine di risposta che hai fissato.

È la terza categoria che separa una notifica difendibile da una debole. I supervisori conoscono bene gli incidenti di terze parti e si aspettano punti aperti a 72 ore. Quello che attira scrutinio è la notifica che spaccia il linguaggio marketing del fornitore per fatto verificato, o che omette in silenzio di aver chiesto evidenze senza ottenerle.

Una nota procedurale su cui agire subito: l'EDPB ha adottato nella plenaria del 10 giugno 2026 un template comune di notifica di violazione, in consultazione pubblica fino al 5 agosto 2026, pensato per armonizzare le notifiche art. 33 tra le autorità di controllo. Mappa ora i tuoi campi di intake su quel template, invece di scoprire il disallineamento a incidente in corso.

Stai notificando un incidente che non puoi indagare. La tua leva è quasi interamente contrattuale, e quasi interamente pre-negoziata.

Richiedi per iscritto entro le prime 24 ore, con un termine di risposta esplicito agganciato al tuo gate regolamentare:

1. Se *il tuo specifico tenant, istanza o dataset* rientra nell'ambito colpito — e, se non ancora determinato, la data entro cui il fornitore conta di determinarlo.
2. La timeline dell'incidente lato fornitore: prima attività anomala, detection, containment, disclosure.
3. Categorie di dati acceduti o esfiltrati, a livello di campo dove possibile.
4. Indicatori di compromissione che puoi cacciare nel tuo perimetro — in particolare token, credenziali o API key che il fornitore ti ha emesso o deteneva per tuo conto.
5. Se sono state esposte credenziali, token OAuth o materiale di sessione che danno accesso *dentro i tuoi sistemi*. È la domanda che converte l'incidente del fornitore in una tua intrusione, ed è quella a cui si risponde più tardi.
6. Le notifiche regolamentari depositate dal fornitore e i relativi numeri di protocollo.

Sul punto 5, l'incidente Klue del giugno 2026 è il caso di riferimento: una credenziale legacy compromessa su un servizio di integrazione ha permesso a un attaccante di ottenere token OAuth verso piattaforme cliente connesse, tra cui Salesforce, e di raggiungere dati dentro diversi ambienti cliente a valle. Le organizzazioni a valle hanno poi dovuto notificare in proprio — LastPass ha dichiarato l'accesso a dati cliente nella propria istanza Salesforce, e 8x8 ha depositato un Form 8-K alla SEC il 17 giugno 2026 per una violazione avvenuta presso un fornitore. La violazione era di Klue. Le notifiche erano loro.

Se sei entità finanziaria, ricorda che l'art. 30(2)(f) DORA impone già che il contratto obblighi il fornitore ad assisterti quando un incidente ICT colpisce il servizio — senza costi aggiuntivi o a un costo determinato ex ante — e che l'art. 30(3)(b) richiede periodi di preavviso e obblighi di reporting definiti per i contratti a supporto di funzioni critiche o importanti. Se il fornitore temporeggia, cita la clausola.

Il problema strutturale sotto tutto questo: le evidenze arrivano nella tua casella come prosa non strutturata del fornitore, e ogni regolatore le vuole come una sintesi strutturata diversa degli stessi fatti. Fare quella mappatura a mano, a incidente in corso, è il punto in cui il gate delle 72 ore si perde davvero. Il motore di compliance di Zero Hunt mappa un'unica base di evidenza su 32 framework — tra cui NIS2 con il Titolo 13, GDPR e DORA — con mappatura dei controlli cross-framework e report firmati ECDSA che portano la chain-of-custody per costruzione: le notifiche per regime diventano export da un solo record, non tre ricostruzioni parallele.

Ordinata per il gate che consuma ogni artefatto:

Per la determinazione dell'awareness (prime 24h) - Notifica del fornitore con header originali e timestamp di ricezione. - Log di escalation interna dalla ricezione alla dichiarazione di incidente. - Qualsiasi segnale precedente relativo a quel fornitore, con esito del triage.

Per le notifiche a 72 ore - Registro dei trattamenti e flussi dati per quel fornitore (estratto art. 30 GDPR). - Estratto contrattuale: clausole di notifica, diritti di audit, obblighi di assistenza. - La tua telemetria di autenticazione e API per l'integrazione coinvolta, sulla finestra di incidente dichiarata dal fornitore più 30 giorni precedenti. - Inventario di token e credenziali di quel fornitore, con stato e timestamp di revoca. - Richieste scritte di evidenza al fornitore, con date e termini.

Per la relazione finale - Sintesi forense o dichiarazione di root cause del fornitore. - La tua verifica indipendente dello scope dichiarato dal fornitore. - Record di remediation: credenziali ruotate, consensi revocati, scope ristretti, modifiche contrattuali. - Cross-reference a ogni altra notifica depositata sugli stessi fatti. - Aggiornamento della valutazione di rischio fornitore e conseguente cambio di status.

Aspettare la certezza del fornitore prima di far partire il tuo orologio. L'orologio è partito quando sei stato informato. L'indagine è ciò che fai *dentro* la finestra, non prima che si apra. Le organizzazioni notificano in ritardo di continuo perché trattano "non sappiamo ancora se siamo coinvolti" come motivo per non notificare, mentre la norma lo tratta come contenuto da inserire nella notifica.

Dare per scontato che il fornitore abbia notificato per te. Non l'ha fatto, e in genere non può. Nel GDPR la responsabilità della notifica resta del titolare anche quando il responsabile notifica per suo conto su autorizzazione (Linee guida EDPB 9/2022 §48). Nel DORA l'art. 19(5) consente all'entità finanziaria di esternalizzare il reporting ma la lascia "pienamente responsabile", e l'art. 28(1) ripete il concetto per il rischio terze parti in generale. Esternalizzare il lavoro non esternalizza mai il dovere.

Trattare una violazione multi-tenant come un problema altrui. Quando un responsabile serve più titolari colpiti dallo stesso incidente, il §47 EDPB gli impone di riportare i dettagli a *ciascun* titolare — e ciascuno di quei titolari deve la propria valutazione. Se tutti danno per scontato che ci penserà il cliente più grande, il risultato è una stanza piena di notifiche tardive.

Non revocare mai i token. Il fallimento tecnico più frequente. Le integrazioni dei fornitori detengono grant OAuth a lunga vita e API key verso il tuo ambiente. Se il fornitore è stato violato, tratta come esposta ogni credenziale che deteneva per te e ruotala — non aspettare che confermi quali token specifici siano stati presi. La conferma arriva tipicamente dopo la finestra in cui la rotazione avrebbe fatto la differenza.

Scoprire che il contratto non ha clausole di notifica. È a incidente in corso che le organizzazioni scoprono che l'accordo non obbliga il fornitore a nulla di più preciso di "tempestivamente". Il rimedio non è disponibile durante l'incidente; è disponibile al rinnovo. Mettilo nella action list post-incidente e usa l'incidente in corso come business case.

I soggetti italiani hanno qui una guida del regolatore insolitamente chiara, e più esigente di quanto molte organizzazioni assumano. Le FAQ NIS di ACN su misure di sicurezza e notifica incidenti affrontano direttamente lo scenario fornitore:

• Incidente sui sistemi del cliente, con fornitore che eroga servizi (ISB.F.1) — l'obbligo di notifica ex art. 25 d.lgs. 138/2024 è in capo al cliente. ACN aggiunge che, in base alla misura GV.SC-01, il cliente soggetto NIS deve assicurarsi che il fornitore segnali tempestivamente gli eventi di sicurezza che impattano i servizi del cliente.
• Incidente sui sistemi del fornitore (ISB.F.2) — l'obbligo è in capo al fornitore, *e anche* al soggetto NIS cliente se l'incidente si configura come significativo anche in relazione ai servizi e alle attività del cliente. È una doppia notifica esplicita.
• Servizi cloud (ISB.F.3) — obbligo su entrambi, cliente e fornitore, con una sola eccezione: quando il servizio cloud è di tipo IaaS o di hosting dell'infrastruttura del cliente, notifica solo il cliente. La distinzione SaaS/IaaS decide chi deposita.

I termini dell'art. 25 ricalcano la direttiva: pre-notifica a 24 ore, notifica a 72 ore, relazione finale a un mese.

Un adempimento di governance che spesso coglie impreparati: la determinazione ACN 127437/2026, pubblicata il 13 aprile 2026, ha introdotto all'art. 18 l'obbligo di dichiarare i *fornitori NIS rilevanti* nella finestra di aggiornamento annuale dal 15 aprile al 31 maggio. Se il fornitore appena violato non è nel tuo elenco dichiarato e probabilmente avrebbe dovuto esserci, quel gap diventa visibile ad ACN esattamente nel momento in cui notifichi. Riconcilia le due cose prima di inviare.

Per il contesto generale di implementazione NIS2, la Technical Implementation Guidance on cybersecurity risk management measures di ENISA, pubblicata il 26 giugno 2025, è il companion non vincolante al regolamento di esecuzione 2024/2690.