Rischio di terze parti tra GDPR, NIS2 e DORA

Lo stesso fornitore può generare obblighi in materia di privacy, cybersicurezza e resilienza operativa. Un fornitore di servizi paghe tratta dati personali; un fornitore di servizi gestiti dispone di accessi privilegiati; una piattaforma cloud supporta applicazioni critiche per il business. Talvolta un unico fornitore fa tutte e tre le cose.

Un registro condiviso dei fornitori aiuta i team a coordinare la valutazione, a condizione che ogni obbligo resti identificabile. Per un CTO, la sfida pratica è collegare gli impegni contrattuali alla realtà tecnica: a che cosa può accedere il fornitore, come si propagano i guasti, quali controlli sono comprovati da evidenze e se l'organizzazione è in grado di ripristinare l'operatività o di uscire dal rapporto.

Stabilire l'applicabilità prima di combinare le valutazioni

Questi strumenti normativi si sovrappongono, ma non si applicano allo stesso modo a ogni organizzazione o fornitore.

L'articolo 28 del GDPR impone ai titolari di ricorrere a responsabili del trattamento che presentino garanzie sufficienti. Un accordo ai sensi dell'articolo 28 non è appropriato solo perché un fornitore riceve dati: stabilite prima il ruolo effettivo nel trattamento.

Gli articoli da 20 a 23 della NIS2 riguardano la supervisione degli organi di gestione, le misure di gestione dei rischi e la segnalazione degli incidenti significativi. La NIS2 è una direttiva attuata tramite il diritto nazionale, quindi ambito di applicazione e procedure richiedono verifiche specifiche per ciascuna giurisdizione.

Il DORA si applica dal 17 gennaio 2025. Riguarda principalmente determinate entità finanziarie; i normali fornitori ICT possono essere soggetti a requisiti contrattuali dei clienti, mentre i fornitori ICT critici designati hanno un regime di sorveglianza distinto. Per le entità finanziarie coperte, il DORA opera come diritto UE settoriale negli ambiti pertinenti della NIS2. Non duplicate automaticamente entrambi gli insiemi di controlli.

Costruire il registro attorno alla dipendenza

Partite dal servizio, non dal questionario per i fornitori. Un fornitore può erogare più servizi con dati, accessi e importanza operativa diversi.

Come base pratica, registrate:

• Servizio, entità giuridica del fornitore, responsabile di business, responsabile tecnico e revisori.
• Funzioni supportate, sistemi, integrazioni e accessi privilegiati.
• Categorie di dati personali, finalità del trattamento, ubicazioni e sub-responsabili.
• Requisiti di disponibilità, obiettivi di ripristino e interruzione tollerabile.
• Provider sottostanti, dipendenze contrattuali e alternative realistiche.
• Obblighi applicabili, date delle evidenze, lacune non risolte e decisioni.

Individuate quali funzioni fallirebbero o si degraderebbero dopo una compromissione o un'interruzione. Un fornitore che conserva pochi dati sensibili può comunque controllare l'autenticazione o le pipeline di deployment. Viceversa, un servizio con un basso rischio di disponibilità può esporre dati personali altamente sensibili.

Mantenete separate queste dimensioni invece di ridurle a un unico punteggio di "rischio elevato" non motivato. Per le entità finanziarie soggette al DORA, collegate questo inventario operativo al registro di informazioni obbligatorio sugli accordi contrattuali per l'utilizzo di servizi ICT; un elenco generico di fornitori non è necessariamente sufficiente.

Riutilizzare le evidenze senza riutilizzare ciecamente le conclusioni

Un report di sicurezza, una mappa dei flussi di dati o un test di ripristino possono supportare più riesami. Prima di farvi affidamento, verificatene il perimetro del servizio, il periodo di riferimento, le esclusioni, le eccezioni e le responsabilità a carico del cliente.

Ad esempio, un report che copre l'infrastruttura del fornitore non copre necessariamente l'accesso del suo personale di supporto ai dati dei clienti. Una policy di backup documentata non dimostra che il ripristino soddisfi i requisiti di ripristino della vostra applicazione.

Mantenete una matrice che colleghi evidenze e domande:

Un certificato ISO o un report SOC 2 supporta la garanzia entro il proprio perimetro; nessuno dei due dimostra la conformità al GDPR o alla NIS2. Conservate il ragionamento del revisore, non solo il documento caricato. Valutare le garanzie di sicurezza dovrebbe essere un riesame tecnico ripetibile, non il controllo di un bollino.

Tradurre i requisiti in contratti e controlli

Ai sensi dell'articolo 28 del GDPR, le clausole per il responsabile del trattamento devono disciplinare materia, durata, natura e finalità del trattamento, tipo di dati e categorie di interessati. Coprono inoltre istruzioni documentate, riservatezza, sicurezza, condizioni per il ricorso a sub-responsabili, assistenza, cancellazione o restituzione e obblighi di informazione e audit. I trasferimenti internazionali richiedono una valutazione separata ai sensi del capo V; il solo hosting nell'UE non risolve le questioni relative agli accessi o ai trasferimenti successivi.

L'articolo 21 della NIS2 comprende la sicurezza della catena di approvvigionamento e la considerazione delle vulnerabilità e delle pratiche di cybersicurezza dei fornitori diretti. Tra le aspettative contrattuali pratiche possono rientrare restrizioni di accesso, gestione delle vulnerabilità, cooperazione in caso di incidente e fornitura di evidenze. Adattatele al servizio e ai requisiti nazionali invece di considerare giuridicamente sufficiente un unico pacchetto di clausole universali.

L'articolo 30 del DORA specifica le disposizioni contrattuali per i servizi ICT, con requisiti aggiuntivi per i servizi che supportano funzioni essenziali o importanti. Esaminate descrizioni dei servizi, ubicazioni, protezione e recupero dei dati, assistenza, risoluzione e diritti di supervisione pertinenti. Per le funzioni essenziali o importanti occorre prestare particolare attenzione a livelli di servizio, reporting, misure di emergenza, cooperazione nei test, diritti di audit e modalità di transizione.

Verificate poi l'attuazione. Se un contratto promette un accesso amministrativo limitato, ottenete evidenze di separazione dei ruoli, autenticazione, approvazione e logging. Se promette la cancellazione, stabilite che cosa accade ai backup e ai record conservati. Assegnate le lacune giuridiche e quelle tecniche ai revisori competenti.

Progettare i passaggi di consegne sugli incidenti prima di un incidente

La policy di risposta agli incidenti di un fornitore può supportare una valutazione di sicurezza lasciando irrisolti gli obblighi di notifica. Specificate canali di contatto, copertura dell'escalation, informazioni iniziali, aspettative sugli aggiornamenti e responsabilità della conservazione delle evidenze.

Ai sensi degli articoli 33 e 34 del GDPR, il responsabile del trattamento informa il titolare senza ingiustificato ritardo. Il titolare valuta la notifica all'autorità di controllo, da effettuare senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne è venuto a conoscenza, a meno che sia improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone. Un rischio elevato può richiedere la comunicazione agli interessati, fatte salve alcune eccezioni. Registrate la motivazione quando la notifica non è necessaria.

Le fasi di segnalazione previste a livello UE dalla NIS2 per gli incidenti significativi comprendono un preallarme entro 24 ore, una notifica entro 72 ore e, in genere, una relazione finale entro un mese dalla notifica; verificate le norme nazionali e settoriali. Il DORA ha un proprio quadro di segnalazione per i gravi incidenti connessi alle TIC. Non sostituite queste valutazioni con un unico indicatore di "violazione" del fornitore.

Come raccomandazione pratica, esercitatevi su un incidente presso un fornitore partendo da informazioni incomplete. Verificate se i team sono in grado di stabilire servizi coinvolti, esposizione, impatto operativo e decisioni di segnalazione senza attendere un rapporto finale sulla causa principale.

Esempio pratico: un servizio, tre percorsi di riesame

Supponiamo, a titolo illustrativo, che un'entità finanziaria coperta utilizzi una piattaforma ospitata di assistenza clienti che tratta dati personali e supporta una funzione che l'entità ha classificato come essenziale o importante ai sensi del DORA.

Il fornitore mette a disposizione un report di garanzia, una policy sugli incidenti e una sintesi dei test di ripristino. La sicurezza rileva che i controlli sugli accessi amministrativi sono comprovati da evidenze, ma il test di ripristino esclude l'integrazione del cliente.

La privacy individua separatamente un processo poco chiaro per le modifiche ai sub-responsabili e meccanismi di trasferimento non risolti per l'accesso remoto. Il riesame DORA rileva che l'assistenza alla transizione e le disposizioni di audit pertinenti richiedono attenzione.

Il piano d'azione risultante è specifico:

• Il responsabile tecnico testa il ripristino dell'integrazione e ne documenta il risultato.
• Il revisore privacy risolve le questioni su sub-responsabili e trasferimenti.
• L'ufficio legale e gli acquisti affrontano le lacune contrattuali.
• Il responsabile che risponde della decisione stabilisce se un uso temporaneo sia accettabile, con condizioni e una data di riesame.

Le evidenze vengono riutilizzate, ma nessuna delle tre conclusioni viene dedotta da un'altra. Un riesame di sicurezza superato non chiude le lacune in materia di privacy o di resilienza.

Monitorare modifiche, concentrazione e un'uscita realmente eseguibile

Fissate la frequenza dei riesami in base alla dipendenza e al rischio. Avviate un riesame aggiuntivo dopo incidenti, modifiche rilevanti del servizio, nuovi sub-responsabili, cambi di ubicazione dei dati, cambi di proprietà o rinnovi contrattuali.

Guardate oltre i nomi dei fornitori: più servizi possono dipendere dalla stessa regione cloud, dallo stesso provider di identità o dallo stesso subappaltatore. Valutate le interruzioni correlate e se l'alternativa proposta condivida la stessa dipendenza. L'articolo 29 del DORA disciplina esplicitamente la valutazione del rischio di concentrazione delle TIC.

Mantenete un piano di uscita proporzionato che copra esportazione dei dati, migrazione, continuità, revoca degli accessi ed evidenze di cancellazione. Testate l'utilizzabilità dell'esportazione e individuate chi può gestire la soluzione sostitutiva. Un diritto di risoluzione è più utile quando l'organizzazione è in grado di esercitarlo.

Anche le conseguenze sono diverse. Il GDPR prevede fasce sanzionatorie specifiche per tipo di violazione; la NIS2 richiede regimi sanzionatori nazionali con massimali diversi per i soggetti essenziali e importanti. Le sanzioni DORA per le entità finanziarie dipendono dalle disposizioni applicabili, mentre le sanzioni nell'ambito della sorveglianza dei fornitori critici sono distinte. Non modellate l'esposizione sulla base di un'unica presunta sanzione universale.

Partire da una dipendenza rilevante

Scegliete un fornitore che supporta una funzione importante. Riconciliate il suo inventario dei servizi, i contratti, le evidenze, i rischi aperti e le ipotesi di uscita. Concludete con responsabili nominati e conclusioni separate e datate per ciascun obbligo applicabile.

In Secani, i team possono modellare il servizio e il provider esterno, collegare requisiti e controlli alle evidenze e monitorare le lacune come attività con un responsabile. Decisioni sottoposte a revisione umana, link alle fonti, commenti e marcature temporali preservano il ragionamento. In questo modo si supporta un contesto condiviso sui fornitori senza nascondere le distinte valutazioni in materia di privacy, sicurezza e resilienza.