PA e GDPR: implementare un sistema di gestione della Data Protection

02 dicembre 2020
Tempo di lettura stimato: 5'
PA e GDPR: molta carta e poca sostanza? Spesso è così. Spesso il Regolamento viene applicato formalmente, ma poi nella sostanza ci accorgiamo che l’attuazione è un po’ zoppicante. In questo articolo vediamo come implementare un sistema di gestione della Data Protection nella PA, per limitare gli scivoloni e non fermarsi all’adeguamento di superficie.


Partiamo dall’inizio. Il Garante nel 2017 si era già pronunciato

Il GDPR è diventato applicabile nel maggio del 2018. Ma l’Autorità Garante, già nel 2017, aveva dato dei suggerimenti alle PA – e sappiamo che il suggerimento del Garante è come fosse normativa cogente! - dicendo loro che fra le priorità dovevano prevedere:
  • la designazione del responsabile per la protezione dei dati, cioè il DPO
  • l’istituzione del registro delle attività di trattamento
  • una Data Breach Policy, cioè uno schema che aiutasse il titolare a gestire eventuali violazioni
Ma cosa è successo? 
C’è stata un’applicazione distorta del GDPR e dei suggerimenti del Garante. 
Si è creata un sacco di carta, ma poca sostanza. 


Come evitare lo scollamento tra forma e sostanza? Con un sistema di gestione della Data Protection 

Come tutti i sistemi di gestione, anche quello della Data Protection prevede delle funzioni, cioè degli uffici che gestiscono dei processi, che vanno disegnati e mappati.
Quindi, per prima cosa, bisogna mappare. Se guardiamo al GDPR, il registro delle attività di trattamento è una mappatura dei processi, costruita secondo il punto di vista della protezione dei dati personali. 
E da dove si parte per disegnare il registro dei trattamenti nella PA?
Si potrebbe partire dai processi già mappati per altri sistemi di gestione: l’anticorruzione, la qualità 9001 o l’ambiente. 
E poi, oltre ai processi, l’organizzazione usa dei prodotti - per esempio, per gestire il processo di mappatura dei trattamenti possiamo usare PrivacyLab – ed eroga dei servizi. Servizi che non devono essere visti solo dal punto di vista della PA o dell’azienda che lavora con la PA, ma soprattutto da quello del cittadino. 
Il cittadino è l’entità dal mettere al centro
Bene. Questo è il quadro generale. Serve una cabina di regia che gestisca il sistema: serve la Data Governance.


DPO+RTD+RPCT+IT: la cabina di regia della Data Governance

La cabina di regia - la Data Governance - dovrà essere costituita sicuramente da almeno 3 figure:

1) Il DPO - che è obbligatorio nel pubblico, ma anche nelle realtà private che erogano servizi pubblici: le partecipate, le società di energia e anche le società che erogano servizi essenziali, come le banche e gli ospedali, per esempio.
2) L’RTD cioè il Responsabile per la Transizione al Digitale, che è obbligatorio per ogni PA. Ricordiamoci anche che le PA sono obbligate alla digitalizzazione, altrimenti si rischia il danno erariale. Chi è l’RTD? È un innovatore che, a differenza del DPO, deve essere solo interno. È una figura apicale automaticamente designata e non si può usare un prestanome. Diversamente dal DPO quindi - che se non lo nomini, non lo nomini, punto; poi ne paghi le conseguenze, ma nessuno viene piazzato obtorto collo a fare il DPO - nelle PA che non lo hanno nominato, l’RTD è il Sindaco. Può essere comune anche a più PA. È il caso, per esempio, dei Comuni molto piccoli.
3) L’RPCT cioè il Responsabile per la Prevenzione della Corruzione e la Trasparenza
Perché anche nella lotta alla corruzione e per la trasparenza bisogna fare il registro dei trattamenti. Bisogna mappare i processi e valutare il rischio, che in questo caso è il rischio di corruzione. 
E poi ci sono altri attori, tra cui l’informatico, che deve essere protagonista delle misure tecniche e fare squadra con gli altri attori per le misure organizzative. Ricordiamoci infatti che il GDPR parla di misure tecniche e organizzative ben 20 volte. Quindi è qualcosa che va applicato nella sostanza
La Data Governance deve essere gestita da tutti questi soggetti in sinergia, non da uno o dall’altro. Perché, per esempio, se il DPO non dialoga con l’RTD, è un DPO monco. Se queste due figure non si parlano, il dato non potrà mai essere protetto. E possono verificarsi dei Data Breach.


Il Data Breach nella PA

All’improvviso c’è un Data Breach. C’è la violazione. È il momento in cui ci si accorge che la cabina di regia ha fallito e che non è stato messo in atto un sistema di Data Protection adeguato. Spesso il sistema è stato formalizzato, ma poi ci si accorge che nella sostanza non è integrato con gli altri sistemi di gestione: l’informatico non parla col DPO, il DPO non sa neanche chi sia il Responsabile per la Transizione al Digitale o il Responsabile per la Prevenzione della Corruzione e la Trasparenza. E così si è aperta la breccia. 
Queste persone si devono conoscere, devono dialogare fra loro e devono riportare la loro valutazione del rischio per le attività di cui sono competenti in maniera specifica. 
A questo proposito è stato implementato un canale, il CSIRT (Computer Security Incident Response Team), che serve a: 

1) inviare una segnalazione – Per esempio: Peppino si connette al sito dell’AgID e vede che non funziona, quindi segnala; 
2) notificare un incidente che, in alcuni casi, è un obbligo ulteriore che si aggiunge alla segnalazione al Garante della violazione dei dati, perché vanno segnalate entrambe. 
La notifica è obbligatoria per tutte quelle organizzazioni che sono state identificate come operatori di servizi essenziali o fornitori di servizi digitali (come, per esempio i provider e gli ospedali). 
Se un ospedale fosse oggetto di Data Breach, non di incidente informatico, dovrebbe attivarsi per segnalarlo all’Autorità Garante – per garantire i diritti fondamentali dell’individuo - ed eventualmente agli interessati. Ma dovrebbe notificarlo, per legge, anche al Computer Security Incident Response Team per rafforzare il perimetro di sicurezza nazionale. 

Quindi la Data Breach Policy potrebbe diventare una Data Breach o Incident Response Policy, dove si va a disegnare un processo (worklofw) di gestione incidente/data breach con un'assegnazione dei ruoli che coinvolga il Responsabile per la Transizione al Digitale, il DPO e l'informatico, in maniera collaborativa e sincronizzata. 
Solo così può migliorare la gestione, altrimenti c'è un problema.

Se sei una PA non puoi non avere un RPTD che lavora in concerto col DPO e con il RPCT. Non puoi. E se c’è una violazione, non è il cittadino che deve pagare, ma sei tu amministratore che, disattendendo una normativa cogente, incappi in un danno erariale
Articolo tratto dall’intervento del Dottor Giuseppe Pacelli su RAISE Academy.
Questo era solo un assaggio!
La formazione completa e aggiornata su GDPR, privacy e cybersecurity è su Raise Academy, l'Accademia di Formazione Efficace di PrivacyLab che coinvolge consulenti e professionisti del GDPR, grazie al connubio tra tecnologia, presenza, competenza, contatto, condivisione e diffusione.
RIPRODUZIONE RISERVATA. Ne è consentito un uso parziale, previa citazione della fonte.

Biografia dell'autore

Andrea Chiozzi è nato a Reggio Emilia il 4 Agosto del 1969, reggiano “testaquadra” DOC come il lambrusco, ed è sposato con Luisa che lo sopporta da più di vent’anni.
Imprenditore e consulente, da più di 12 anni è l’Evangelist del GDPR.

Attività professionali:
Andrea Chiozzi è socio fondatore e CEO di PRIVACYLAB SRL, azienda che si occupa della produzione di PRIVACYLAB GDPR per la gestione avanzata delle attività legate alla compliance per il Regolamento Europeo 679/2016.
Esperto di GDPR e protezione dei dati personali (soprattutto nelle aree più problematiche quali il marketing digitale e i social network, il digital advertising, l’Internet of Things, i Big Data, il cloud computing),
Andrea presta consulenza per la media e la grande industria italiana e si occupa di organizzare e condurre i consulenti aziendali ad un approccio ottimizzato alla gestione della Compliance GDPR.
È ideatore del sistema Privacylab e della metodologia applicata ai consulenti certificati GDPR. 
Nel 2003 dà vita alla figura di “Privacy Evangelist” e comincia a girare l’Italia come relatore in vari convegni e corsi in tema di protezione dei dati personali arrivando a evangelizzare più di 10.000 persone.

È commissario d’esame per:

UNICERT per lo schema DSC_12/30 per Consulenti Certificati GDPR
TÜV dello schema CDP_ 201 Privacy Officer, Bureau Veritas
CEPAS Bureau Veritas DATA PROTECTION OFFICER per lo schema SCH73 norma Uni 11697:2017 (Accredia) 
ACS ITALIA DATA PROTECTION OFFICER per lo schema SCH01 norma Uni 11697:2017 (Accredia)
UNIVERSAL Gmbh DAKKS per lo schema ISO/IEC 17024:2012 "DATA PROTECTION OFFICER"

E' certificato con:
Unicert come "Consulente Certificato GDPR" n. 18203RE22
TÜV come “Privacy Officer e Consulente Privacy” n. CDP_196.
Cepas Bureau Veritas "Data protection Officer" n. DPO0206
UNICERT DAKKS " Data Protection Officer" n. DPO 0818 010012

Fa parte del Comitato Scientifico Privacy di Torino Wireless, GDPR Academy e di Agile DPO .

Le categorie

Gli argomenti dei nostri articoli

La guida di PrivacyLab

Per orientarti tra i nostri articoli

Resta informato su quello che succede.

Lasciaci la tua email e riceverai le nostre comunicazioni informative e commerciali

informativa sulla privacy