CISO e DPO: rendere chiari i passaggi di consegne

I team di sicurezza e privacy esaminano spesso lo stesso sistema da prospettive diverse. Il CISO si chiede se accessi, resilienza e trattamento del rischio siano adeguati. Il DPO fornisce consulenza su liceità del trattamento, diritti degli interessati, garanzie e conformità alla normativa sulla protezione dei dati. Il loro lavoro si sovrappone, ma la loro autorità non dovrebbe diventare intercambiabile.

Per il vertice aziendale, la domanda pratica non è semplicemente chi ricopra ciascun ruolo. È chi fornisce i fatti, chi consiglia, chi attua e chi prende la decisione di cui risponde. Queste distinzioni contano quando si lancia un prodotto, cambia un fornitore o un incidente impone di agire prima che l'indagine sia conclusa.

Un assetto funzionante garantisce a entrambe le funzioni una visibilità tempestiva, preservando l'indipendenza del DPO. Chiarisce inoltre che la nomina di specialisti, interni o esterni, non trasferisce la responsabilità del titolare per le decisioni sul trattamento.

Separare i mandati prima di assegnare le persone

Le responsabilità di un CISO dipendono dalla governance dell'organizzazione. Il titolo può indicare un dirigente a capo di una funzione di sicurezza, uno specialista che gestisce un sistema di gestione della sicurezza delle informazioni oppure un consulente a tempo parziale. Un responsabile della sicurezza delle informazioni può avere un ambito più ristretto. Definite il mandato invece di presumere che il titolo basti a stabilirlo.

Il DPO ha compiti e tutele specifici previsti dagli articoli da 37 a 39 del GDPR. Tra questi rientrano informare e fornire consulenza, sorvegliare l'osservanza, fornire pareri sulle valutazioni d'impatto sulla protezione dei dati, cooperare con l'autorità di controllo e fungere da punto di contatto per essa. Il DPO deve riferire direttamente al vertice gerarchico e non ricevere istruzioni per quanto riguarda l'esecuzione di tali compiti.

La sicurezza riguarda più dei soli dati personali. Un attacco ransomware che colpisce i disegni tecnici o la pianificazione della produzione è una questione di sicurezza anche quando non sono coinvolti dati personali. La privacy riguarda più della sola sicurezza: un database ben protetto può comunque contenere informazioni raccolte senza un'adeguata base giuridica o conservate senza necessità.

Il terreno comune comprende le misure tecniche e organizzative basate sul rischio richieste dall'articolo 32 del GDPR. Controlli degli accessi, meccanismi di ripristino e test possono supportare entrambe le funzioni. Le evidenze condivise sono utili, ma non rendono identiche le valutazioni sottostanti.

Stabilire quali ruoli servono davvero alla vostra organizzazione

Valutare l'obbligo di nomina del DPO separatamente dalla pianificazione dell'organico

Un DPO non è automaticamente obbligatorio per ogni organizzazione. Ai sensi dell'articolo 37 del GDPR, la designazione è obbligatoria per le autorità pubbliche e gli organismi pubblici, fatta eccezione per le autorità giurisdizionali, e per le organizzazioni le cui attività principali consistono nel monitoraggio regolare e sistematico su larga scala oppure nel trattamento su larga scala di categorie particolari di dati o di dati personali relativi a condanne penali e reati.

Non riducete questa valutazione alle dimensioni dell'azienda. Un'organizzazione relativamente piccola può svolgere trattamenti che rendono obbligatoria la nomina, mentre il solo numero di dipendenti non risponde al criterio del GDPR. Il diritto nazionale può imporre ulteriori obblighi di designazione. In Germania, valutate le norme nazionali aggiuntive invece di basarvi esclusivamente sull'articolo 37 o su una soglia di organico ricordata a memoria.

Conservate una valutazione sulla nomina che identifichi le entità, i trattamenti e le giurisdizioni pertinenti, le ragioni della conclusione e gli eventi che farebbero scattare una nuova valutazione. Un nuovo servizio di monitoraggio, un'acquisizione o l'avvio di trattamenti di dati sensibili possono cambiare la risposta.

Quando un DPO non è obbligatorio, assegnate comunque le responsabilità in materia di privacy. Basi giuridiche, trasparenza, gestione dei diritti, sicurezza e obblighi di responsabilizzazione non scompaiono. Usate con consapevolezza il titolo formale di DPO: una nomina volontaria va trattata come un vero ruolo di DPO, non come una semplice etichetta per un referente amministrativo.

Distinguere la responsabilità della sicurezza da un obbligo universale di nominare un CISO

Il GDPR non prevede alcun obbligo specifico di nominare una persona con il titolo di CISO. Altre norme settoriali o nazionali possono incidere sulla governance della sicurezza, quindi valutatele separatamente.

ISO/IEC 27001 richiede che vengano assegnate responsabilità e autorità per il SGSI nel perimetro definito; non prescrive un titolo professionale universale. Anche i contratti con i clienti possono richiedere un referente nominato per la sicurezza, responsabilità definite o particolari evidenze di garanzia.

Per le organizzazioni che rientrano nell'ambito di applicazione, gli articoli da 20 a 23 della direttiva NIS2 disciplinano la supervisione da parte degli organi di gestione, le misure di gestione dei rischi di cibersicurezza e la segnalazione degli incidenti. La NIS2 viene attuata tramite il diritto nazionale e la sua applicabilità dipende da settore, dimensioni, servizio e criteri di inclusione, non dal solo organico. Per le attività in Germania, utilizzate le indicazioni del BSI sulla NIS2 insieme alla normativa applicabile.

La decisione del vertice è quindi duplice: determinare i requisiti legali e contrattuali, poi dotare di risorse il lavoro di sicurezza necessario per gestire l'attività. Un titolo professionale privo di autorità, capacità e accesso non risolve nessuno dei due problemi.

Verificare i conflitti di interesse rispetto ai poteri decisionali effettivi

L'articolo 38, paragrafo 6, del GDPR consente al DPO di svolgere altri compiti, a condizione che non diano adito a un conflitto di interessi. Cumulare i ruoli non è automaticamente vietato, ma richiede una valutazione sostanziale. La questione centrale è se la persona determini finalità e mezzi di trattamenti sui quali deve poi fornire consulenza o vigilare in modo indipendente.

Esaminate l'autorità connessa alla nomina proposta:

• La persona può decidere perché vengono raccolti i dati di dipendenti o clienti?
• Può scegliere gli strumenti di monitoraggio, definirne l'ambito o stabilire la conservazione?
• Approva sistemi o modalità di trattamento invece di limitarsi a fornire consulenza?
• Sorveglierebbe decisioni che ha preso in un altro ruolo?
• Può sollevare criticità direttamente presso il vertice senza un incentivo contrastante?

Un CISO che approva i sistemi di monitoraggio dei dipendenti presenta un profilo di conflitto diverso da un consulente di sicurezza che fornisce raccomandazioni senza potere decisionale. I ruoli dirigenziali in ambito IT, risorse umane e direzione meritano particolare attenzione, ma i soli titoli non costituiscono una valutazione completa.

Documentate i compiti dell'altro ruolo, le deleghe, le linee di riporto e le garanzie. Rivedete la valutazione quando le responsabilità cambiano. Un vice o un revisore indipendente può contribuire alla continuità e alla garanzia, ma non sana automaticamente una nomina incompatibile.

Come raccomandazione pratica, separate i ruoli quando la funzione di sicurezza ha un'autorità rilevante sul trattamento dei dati personali. Non giustificate una doppia nomina solo perché l'azienda è piccola o la persona gode di fiducia. La fiducia non elimina l'autoverifica né le responsabilità in competizione.

Le nomine esterne richiedono la stessa attenzione. L'esternalizzazione può garantire indipendenza rispetto alle linee di riporto interne, ma possono comunque sorgere conflitti a causa di mandati sovrapposti o di incentivi del fornitore.

Definire i passaggi di consegne attorno al lavoro ricorrente

Una matrice delle responsabilità dovrebbe descrivere decisioni e output, non solo la partecipazione. Evitate righe che recitano "sicurezza e privacy congiuntamente responsabili" senza indicare chi deve agire per primo.

Quanto segue è un punto di partenza pratico, non una ripartizione normativa di ogni obbligo:

Modifiche di prodotto: anticipare il primo passaggio quanto basta perché conti

Per una nuova piattaforma per i clienti, il responsabile di business dovrebbe indicare la finalità prevista e le decisioni sul trattamento. Fornite una breve scheda della modifica che copra categorie di dati, persone interessate, sistemi, fornitori, accessi, conservazione e data prevista di rilascio. Includete uno schema dei flussi di dati quando rende più comprensibile l'assetto.

La sicurezza valuta poi minacce e protezioni: accessi privilegiati, autenticazione, segregazione, logging, backup e ripristino, nonché le evidenze necessarie prima del rilascio. Gli specialisti privacy valutano base giuridica, trasparenza, minimizzazione, conservazione, rapporti di trattamento e la necessità di una DPIA. Ai sensi dell'articolo 35 del GDPR, una DPIA è obbligatoria quando il trattamento può presentare un rischio elevato; consultate il DPO, se designato.

Il passaggio di consegne dovrebbe produrre conclusioni esplicite, non approvazioni separate e non motivate. Registrate il parere del DPO ove pertinente, la decisione di business, le condizioni di rilascio e il responsabile di ogni azione residua. Se il vertice non segue il parere, conservatene la motivazione ed effettuate l'escalation delle criticità giuridiche non risolte. L'accettazione di un rischio di business non può rendere lecito un trattamento illecito.

Fissate eventi che facciano scattare il riesame, come nuovi dati sensibili, monitoraggio dei dipendenti, finalità modificate, accessi sostanzialmente più ampi o un nuovo fornitore. È più utile che pretendere la stessa documentazione per ogni piccola modifica di interfaccia.

Onboarding dei fornitori: separare le garanzie di sicurezza dalla liceità del trattamento

Il responsabile di business dovrebbe identificare il servizio, i dati coinvolti e ciò che il fornitore farà effettivamente. La sicurezza valuta le garanzie pertinenti, le modalità di accesso, il supporto in caso di incidente e la resilienza. La privacy valuta se il fornitore sia un responsabile del trattamento, un titolare autonomo o un altro soggetto coinvolto nel trattamento.

Quando si applica l'articolo 28, il contratto deve contenere le clausole richieste per il responsabile del trattamento. I trasferimenti internazionali richiedono una valutazione separata; un accordo sul trattamento o una sede di hosting preferita non risolvono questa questione.

Concordate chi ottiene le evidenze mancanti e chi negozia le modifiche contrattuali. Un errore comune è considerare il questionario di sicurezza come il riesame completo, lasciando inesplorati ruoli nel trattamento, sub-responsabili, cancellazione e trasferimenti. Un altro è negoziare le clausole privacy senza conoscere l'effettivo accesso tecnico del fornitore.

Il deliverable dovrebbe indicare quali servizio e configurazione sono stati valutati, le condizioni accettate, le questioni aperte e gli eventi che fanno scattare una nuova valutazione. Le modifiche sostanziali ad accessi, sub-responsabili o luoghi di trattamento dovrebbero raggiungere entrambe le funzioni.

Incidenti: scambiarsi i fatti prima di avere certezze

In caso di sospetta violazione, la sicurezza indaga mentre la privacy valuta le implicazioni per le persone interessate e per la notifica. Nessuno dei due team dovrebbe attendere un rapporto completo prima di condividere le informazioni pertinenti.

Un primo passaggio di consegne dovrebbe indicare che cosa è accaduto, quando è stato rilevato, quali sistemi e dati possono essere coinvolti, se riservatezza, integrità o disponibilità siano state compromesse, quale contenimento sia stato attuato e che cosa resti ignoto. Assegnate a qualcuno il compito di tenere la cronologia e aggiornare entrambe le funzioni man mano che i fatti cambiano.

Ai sensi dell'articolo 33 del GDPR, il titolare deve notificare la violazione all'autorità di controllo 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. Il responsabile del trattamento deve informare il titolare senza ingiustificato ritardo. Registrate la valutazione del momento in cui si è venuti a conoscenza della violazione; non date per scontato che ogni allerta iniziale faccia decorrere il termine di legge né che sia necessaria una piena certezza forense prima di agire.

L'articolo 34 può richiedere la comunicazione alle persone interessate in presenza di un rischio elevato, fatte salve le sue eccezioni. Concordate chi coordina le scadenze, prepara le comunicazioni all'autorità, autorizza le comunicazioni e conserva le evidenze. Documentate le violazioni dei dati personali, compresa la motivazione quando la notifica è ritenuta non necessaria. La mancanza di alcuni fatti può richiedere una notifica in più fasi, anziché il silenzio mentre l'indagine prosegue.

Per un incidente che riguarda un soggetto rientrante nell'ambito di applicazione, valutate in parallelo se raggiunga la soglia applicabile di incidente significativo ai sensi della NIS2. La direttiva prevede un preallarme entro 24 ore, una notifica dell'incidente entro 72 ore e, in genere, una relazione finale entro un mese dalla notifica; verificate le norme nazionali e settoriali. Si tratta di presupposti e destinatari diversi rispetto al GDPR, non di un unico processo di segnalazione intercambiabile.

Richieste di esercizio dei diritti: tenere distinto il supporto operativo dalla titolarità della risposta

Le richieste di esercizio dei diritti richiedono spesso il supporto della sicurezza e dell'IT per verificare l'identità in modo proporzionato, localizzare le informazioni, proteggere i dati di terzi e consegnare la risposta in modo sicuro. La privacy coordina la valutazione giuridica, con il parere del DPO ove opportuno. Il titolare resta responsabile della risposta.

Ai sensi dell'articolo 12 del GDPR, il termine ordinario di risposta è di un mese. Può essere disponibile una proroga di ulteriori due mesi, se necessario, con comunicazione e motivazione entro il primo mese. Le richieste sono in genere gratuite, con condizioni limitate per l'addebito di un contributo o il rifiuto.

Registrate chi è titolare della scadenza, quali sistemi devono essere consultati e chi approva la comunicazione dei dati. Non richiedete per impostazione predefinita documenti d'identità eccessivi e non lasciate che un'esportazione tecnica diventi una risposta non rivista. Un processo operativo condiviso può collegare la valutazione della privacy con le ricerche e i controlli sulla consegna descritti nella gestione delle richieste di accesso degli interessati.

Scegliere tra nomine interne ed esterne in base a competenze e accesso

L'articolo 37, paragrafo 6, del GDPR consente espressamente che il ruolo di DPO sia ricoperto da un dipendente o assolto in base a un contratto di servizi. Anche la guida della sicurezza può essere esternalizzata come scelta organizzativa, nel rispetto dei requisiti applicabili e con un mandato chiaro.

Un DPO interno può conoscere a fondo l'azienda e avere facile accesso ai colleghi. L'organizzazione deve comunque garantire competenze, risorse, tempo dedicato, indipendenza e sostituzioni. Un DPO esterno può portare esperienza specialistica e capacità aggiuntiva, ma ha bisogno di un canale affidabile verso modifiche di prodotto, contratti, valutazioni e incidenti. Nessuno dei due modelli funziona se il DPO viene a conoscenza delle decisioni solo dopo la loro attuazione.

Confrontate le esigenze operative complessive invece di limitarvi a mettere a confronto stipendio e compenso forfettario. Considerate formazione, consulenza specialistica, sostituzioni in caso di assenza, tempo di coordinamento, picchi di progetto e costi per attività fuori dal perimetro. Non esiste una regola universale affidabile secondo cui l'esternalizzazione costi meno.

Per i mandati esterni, concordate:

• Referenti nominati, sostituti, percorsi di escalation e accesso al vertice gerarchico.
• Quali riesami, riunioni, attività di formazione e supporto in caso di incidente sono inclusi.
• Tempi di risposta adeguati al lavoro urgente e a quello ordinario.
• Come informazioni, pareri e decisioni saranno documentati e conservati.
• Riservatezza, limiti di accesso, gestione dei conflitti e modalità di uscita.

Se un unico fornitore copre entrambe le funzioni, verificate chi svolge ciascun mandato e come vengono gestiti i conflitti. Nomi diversi in un'offerta non bastano se la stessa persona controlla e verifica le decisioni sul trattamento.

Nominate un coordinatore interno con l'autorità per ottenere informazioni e sollecitare l'attuazione. Gli specialisti esterni non possono valutare sistemi non comunicati né far eseguire azioni di cui nessuno all'interno è responsabile. La direzione mantiene le decisioni su budget e priorità di business, e il titolare mantiene la responsabilità ai sensi dell'articolo 24 del GDPR.

Adeguare l'assetto al carico di lavoro

Per un'organizzazione più piccola non soggetta all'obbligo di nomina del DPO, possono essere appropriati un responsabile privacy e un responsabile della sicurezza nominati, con la possibilità di ricorrere a consulenza specialistica per le questioni complesse. È cosa diversa dal conferire a qualcuno una nomina formale di DPO.

Quando il DPO è obbligatorio ma i candidati interni detengono un'autorità operativa in conflitto, vale la pena considerare una nomina esterna. Abbinatela a una responsabilità interna per l'attuazione, invece di aspettarvi che il fornitore gestisca ogni attività privacy.

Quando le richieste di garanzia dei clienti impongono di costruire un SGSI e l'esperienza interna in materia di sicurezza è limitata, una guida esterna della sicurezza può supportare il lavoro iniziale. Decidete chi manterrà in seguito valutazioni del rischio, evidenze e reporting alla direzione; un incarico di progetto non dovrebbe lasciare un vuoto di responsabilità quando termina.

Un'organizzazione strutturata può gestire entrambe le funzioni internamente, a condizione di tutelare l'indipendenza del DPO e di destinare capacità sufficiente. La decisione dovrebbe basarsi su carico di lavoro, competenze e autorità effettivi, non sul presupposto che l'interno sia sempre meglio o l'esterno sempre più semplice.

Esempio pratico: un produttore che prepara un portale clienti

Consideriamo, a titolo illustrativo, un'azienda manifatturiera con 200 dipendenti, un piccolo team IT e un portale previsto per l'assistenza clienti e la manutenzione dei macchinari. Supponiamo che il portale conterrà dati di contatto dei clienti, storici degli interventi e registri delle attività dei tecnici. I clienti chiedono inoltre una governance della sicurezza documentata. Si tratta di fatti ipotetici, non di una conclusione giuridica valida per ogni produttore di quelle dimensioni.

Il vertice commissiona innanzitutto valutazioni separate sull'obbligo di nomina del DPO e sull'applicabilità delle norme settoriali di cibersicurezza. Non deduce l'ambito di applicazione della NIS2 dal solo numero di dipendenti. Riesamina inoltre la nomina a DPO già conferita al direttore IT, perché quel direttore sceglie i sistemi e ne approva il funzionamento.

Dopo aver valutato conflitti e capacità, l'azienda nomina un DPO esterno e un responsabile della sicurezza a tempo parziale. Il direttore IT è responsabile della realizzazione tecnica, il direttore del service è titolare delle finalità del trattamento e dei requisiti di business del portale e un coordinatore interno tiene il registro delle azioni. L'amministratore delegato promuove le decisioni e risolve le controversie sulle risorse.

In fase di progettazione, la sicurezza raccomanda un logging dettagliato delle attività per indagare su eventuali abusi. La privacy rileva che i log rivelano anche il comportamento dei tecnici. Il direttore del service spiega l'esigenza operativa; la sicurezza propone accessi limitati e un uso definito a fini di indagine; la privacy valuta necessità, trasparenza e conservazione. Il parere del DPO viene registrato prima che il responsabile competente decida la configurazione. Il DPO non approva la progettazione del logging al posto della direzione.

Il registro del lancio contiene la descrizione dei flussi di dati, la valutazione del fornitore, le conclusioni di sicurezza, l'esito dello screening DPIA, le azioni privacy e le condizioni di rilascio accettate. Ogni azione aperta ha un responsabile e una scadenza.

Il vertice conduce poi un'esercitazione da tavolo che simula un account del portale compromesso. La sicurezza fornisce un primo pacchetto di fatti; la privacy valuta i possibili danni; il coordinatore monitora le scadenze della valutazione; il manager autorizzato gestisce le comunicazioni. L'esercitazione rivela che nella procedura di gestione degli incidenti mancavano i recapiti di emergenza del DPO esterno. Correggere questa piccola lacuna rende il passaggio di consegne utilizzabile sotto pressione.

Rendere la collaborazione verificabile senza condividere tutto

Prevedete per i disaccordi un percorso di escalation definito. I compromessi tecnici possono essere portati al responsabile del servizio e allo sponsor esecutivo; le criticità di conformità non risolte dovrebbero raggiungere il vertice gerarchico attraverso il canale di riporto indipendente del DPO. Conservate le posizioni divergenti invece di riscrivere il registro per far sembrare che vi sia accordo.

Condividete solo le informazioni di cui ciascun ruolo ha bisogno, in particolare nelle indagini delicate. Ai sensi dell'articolo 38 del GDPR, il DPO deve avere accesso alle informazioni pertinenti sul trattamento, ma ciò non giustifica la distribuzione di dati grezzi dei dipendenti o di materiale forense a ogni partecipante al progetto. Utilizzate limiti di accesso e sintesi opportunamente oscurate, senza trattenere i fatti necessari per la valutazione.

Il vertice dovrebbe esaminare alcuni segnali operativi: modifiche attuate prima della consultazione, azioni scadute dopo un parere, incidenti con un'escalation interfunzionale tardiva e incertezze ricorrenti su chi abbia il potere decisionale. Questi elementi rivelano le carenze di governance più chiaramente del conteggio di policy o riunioni.

Un riesame pratico da parte del vertice dovrebbe concludersi con decisioni, non soltanto con report aggiornati. Se le valutazioni arrivano ripetutamente in ritardo, modificate il criterio di presa in carico dei progetti. Se le azioni restano aperte perché i team non hanno capacità sufficiente, assegnate risorse o rivedete il piano di consegna. Se nessuno sa individuare chi decide, correggete la delega prima di accettare un altro rilascio.

Mantenete compatto il registro che ne risulta: la questione, i pareri pertinenti di sicurezza e privacy, la decisione e chi ne risponde, la sua motivazione, i responsabili delle azioni e una data di riesame. Distinguete una lacuna nelle evidenze da un controllo attuato che non ha funzionato. Richiedono un seguito diverso, anche quando entrambi compaiono come attività aperta.

Domande che il vertice dovrebbe chiarire esplicitamente

Il DPO deve approvare ogni lancio?

Il GDPR definisce un ruolo di consulenza e sorveglianza, non un obbligo generalizzato di approvazione dei rilasci da parte del DPO. Un'organizzazione può istituire passaggi di consultazione obbligatori, ma dovrebbe distinguere la consultazione dall'autorità di lancio del responsabile di business. Una consultazione completata non dimostra inoltre che il trattamento sia lecito.

Le evidenze di sicurezza possono soddisfare i riesami privacy?

Possono supportarli. I registri delle revisioni degli accessi o i test di ripristino possono alimentare una valutazione ai sensi dell'articolo 32. Non dimostrano una base giuridica, un'adeguata trasparenza o un periodo di conservazione giustificato. Individuate che cosa dimostra ciascun elemento invece di trattare un unico pacchetto di evidenze come approvazione per tutto.

Partire da due processi e da una traccia di evidenze snella

Iniziate dalle modifiche di prodotto e dalla gestione degli incidenti. Per ciascuno, indicate il responsabile della presa in carico, le informazioni richieste, gli eventi che fanno scattare il riesame, il potere decisionale, il percorso di escalation e le sostituzioni. Testate entrambi con casi realistici prima di estendere la matrice.

Secani collega requisiti, evidenze, responsabili, attività e decisioni di riesame in un contesto condiviso. Per un perimetro di servizio circoscritto, i team possono modellare i sistemi e i provider di supporto, associare le evidenze ai requisiti o alle decisioni che supportano e trasformare le domande di riesame senza risposta in lavoro assegnato. Pianificate i limiti di accesso per i collaboratori interni ed esterni; il ruolo documentato per l'API OSCAL concede solo l'accesso alla validazione. Mantenete esplicita la revisione umana dei suggerimenti generati con l'aiuto dell'IA e conservate fonti, commenti, approvazioni e marcature temporali.

Il passo successivo concreto è una sessione congiunta con il responsabile di business, il responsabile della sicurezza, il team privacy e il DPO. Fate passare una modifica imminente e un incidente plausibile attraverso i passaggi di consegne proposti. Ovunque il gruppo non riesca a individuare chi agisce dopo, migliorate il processo prima del prossimo caso urgente.