Risposta breve
Le lavorazioni secondarie non costituiscono una categoria a sé stante della GDPR. Il termine indica in questo contesto un principio strutturale organizzativo e tecnico nel Elenco delle attività di trattamento: Un'elaborazione standard centrale costituisce il nucleo comune di un processo. Le varianti locali o specifiche per un caso d'uso vengono gestite come forme subordinate di tale elaborazione standard.
Un modello di questo tipo può risultare particolarmente rilevante per i gruppi aziendali. Molti processi vengono eseguiti in modo simile in diverse società, paesi o sedi, ma presentano alcune differenze nei singoli aspetti. In queste circostanze, copie non collegate tra loro possono causare incongruenze. Un’elaborazione principale con elaborazioni secondarie associate consente invece di integrare tra loro standard comuni, deviazioni locali, responsabilità, approvazioni, versioni, indicazioni di stato e la disattivazione delle varianti non più necessarie.
Discrepanze locali nel RoPA del Gruppo
Nei gruppi aziendali esistono numerose attività di elaborazione che vengono svolte in forma simile in diverse società o in diverse sedi. Ciò riguarda, ad esempio, i processi HR, la gestione delle candidature, il CRM, la comunicazione con gli inquilini, i processi di facility management, la gestione dei fornitori, la registrazione dei visitatori, la gestione della formazione, il supporto IT, la gestione del parco veicoli, i sistemi di segnalazione e i processi di marketing.
Il nucleo comune dei processi è spesso simile. A un esame più attento, tuttavia, possono emergere differenze significative. Una società si avvale di un fornitore di servizi locale, mentre un’altra ricorre a un fornitore utilizzato a livello di gruppo. In singole sedi vengono trattati dati aggiuntivi o vengono coinvolti ulteriori destinatari. I termini di conservazione possono variare a causa dei requisiti locali. Anche la definizione delle finalità, le applicazioni utilizzate, le Base giuridica oppure i processi interni di approvazione non devono necessariamente essere identici in tutte le società.
Non tutte queste deroghe richiedono necessariamente un’attività di trattamento completamente autonoma. Tuttavia, devono essere documentate in modo strutturato, in modo che lo standard comune e le rispettive specificità locali rimangano comprensibili.
Nella pratica, spesso si copia un’attività di trattamento già esistente e la si adatta successivamente alla società o alla sede in questione. Questo approccio può inizialmente ridurre l’onere documentale. Tuttavia, con l’aumentare del numero di copie, diventa più difficile individuare il nesso tra il processo originale e le varianti locali e gestirlo in modo sostenibile.
Rischi legati alle copie RoPA non collegate
Di norma è possibile creare rapidamente una copia di un’attività di trattamento esistente. La voce esistente viene ripresa e adattata alle specificità locali nei singoli campi. Questo approccio può diventare problematico non appena la descrizione centrale o un’altra specifica comune subisce modifiche.
Una copia non collegata non contiene di norma informazioni attendibili sul processo principale su cui si basa. Se, ad esempio, viene modificata una categoria di dati centrale, occorre innanzitutto individuare quali voci locali sono interessate da tale modifica. Lo stesso vale in caso di sostituzione di un fornitore di servizi, di adeguamento di un termine di cancellazione, di modifiche alle misure tecniche e organizzative o di revisione di una descrizione centrale del processo.
Se esistono numerose copie simili, con il passare del tempo può diventare difficile distinguere quale voce rispecchi lo standard a livello di gruppo e quali voci contengano semplicemente delle variazioni locali. Ciò non comporta solo un problema di documentazione, ma incide in particolare sulla gestione, sull’aggiornamento, sul reporting e sulla conservazione della documentazione.
Ai sensi dell'art. 30 GDPR deve essere Elenco delle attività di trattamento tra cui informazioni relative alle finalità della Elaborazione, le categorie di interessati e di dati personali, i destinatari, eventuali trasferimenti verso paesi terzi, i termini di cancellazione previsti e, per quanto possibile, una descrizione generale delle misure tecniche e organizzative. L’elenco deve essere tenuto per iscritto, sebbene sia ammesso anche un formato elettronico, e deve essere messo a disposizione dell’autorità competente Autorità di vigilanza da mettere a disposizione su richiesta.
In questo contesto, non è importante solo la completezza delle singole voci, ma anche la struttura dell’elenco. Se diverse copie descrivono lo stesso processo in modo divergente, può risultare difficile illustrare in modo comprensibile lo stato attuale delle cose alla direzione, ai responsabili della protezione dei dati o alle autorità di controllo.
Il concetto di “sub-trattamento” nel RoPA
Il termine „sub-Elaborazione“ in questo articolo è utilizzato consapevolmente in senso operativo. Con ciò non si intende né un trattamento in subappalto da parte di un altro responsabile del trattamento, né una nuova categoria giuridica di GDPR.
Una sotto-Elaborazione indica piuttosto una variante secondaria di un trattamento principale nell’ambito dell’elenco delle attività di trattamento.
L'elaborazione delle anagrafiche descrive in particolare il nucleo comune del processo:
- lo scopo generale,
- il processo principale,
- i gruppi di persone regolarmente coinvolti,
- categorie tipiche di dati,
- sistemi centrali,
- Destinatario predefinito,
- fornitori di servizi tipici,
- fondamentale misure tecniche e organizzative,
- la logica di cancellazione predefinita,
- rischi principali,
- responsabilità principali, nonché
- controlli standard previsti e approvazioni.
La sotto-Elaborazione rappresenta invece la deviazione controllata dallo standard comune. Può riferirsi in particolare a:
- una società locale,
- una sede,
- un determinato Paese,
- un dipartimento,
- un caso d'uso aggiuntivo,
- un fornitore di servizi diverso,
- una categoria di dati aggiuntiva,
- un altro termine di conservazione locale,
- un destinatario aggiuntivo,
- una fase del processo a livello locale,
- uno stato diverso,
- una condivisione locale oppure
- una misura locale complementare.
In questo modo, invece di avere diverse copie non collegate tra loro, si ottiene un’elaborazione centrale alla quale sono assegnate in modo tracciabile le rispettive varianti locali o specifiche per ciascun caso d’uso.
Esempio: gestione delle candidature in un gruppo aziendale
Per quanto riguarda la gestione delle candidature, il nucleo comune del processo è simile in molte aziende. Le candidature vengono ricevute, esaminate, coordinate con i reparti competenti, documentate e cancellate alla scadenza dei termini previsti. I soggetti interessati sono i candidati. Tra i dati tipicamente trattati figurano le informazioni di contatto, i dati contenuti nei curriculum vitae, i titoli di studio, gli appunti relativi ai colloqui e i dati relativi alle comunicazioni. Di norma sono coinvolti un sistema di gestione delle candidature, l’ufficio del personale, i reparti specializzati interessati e, se del caso, fornitori di servizi esterni.
Questo nucleo comune può essere documentato in una procedura standard. La configurazione concreta può tuttavia variare da una società all’altra.
Ad esempio, una società tedesca può utilizzare il sistema centrale di gestione delle candidature, mentre in Francia viene coinvolto anche un fornitore di servizi locale. Negli Stati Uniti può essere utilizzata un’altra piattaforma per i colloqui. Una società conserva determinati documenti per un periodo più lungo a causa dei requisiti locali in materia di diritto del lavoro. Un’unità aziendale raccoglie ulteriori documenti relativi al portafoglio. In una sede vengono effettuati controlli di sicurezza per determinati ruoli. In un Paese vigono disposizioni diverse Obbligo di informazione, mentre in un’altra società è prevista anche una procedura relativa al comitato aziendale.
Queste differenze non comportano in ogni caso dieci attività di trattamento completamente autonome. Nella misura in cui il nucleo comune del processo rimanga valido, esse possono essere gestite come varianti del trattamento di base. Grazie alla classificazione come sottotrattamenti, rimane chiaro quali dati siano validi a livello di gruppo e in quali punti sussistano divergenze locali.
| Domanda di valutazione | Copia non collegata | Elaborazione dei dati anagrafici con sottosezioniElaborazione |
|---|---|---|
| Nucleo di processo comune | Viene descritto più volte. | Viene aggiornato una volta nella gestione anagrafica. |
| Scostamento locale | Spesso è riconoscibile solo nella copia. | Viene espressamente documentata come variante. |
| Modifiche allo standard | Devono essere ricontrollate una per una nelle copie interessate. | Possono essere gestiti a livello centrale e verificati per le diverse varianti. |
| Responsabilità locale | Spesso non è chiaro o è presente solo nei campi di testo libero. | Può essere assegnato a un proprio ruolo locale o a un proprietario. |
| Reportistica | Richiede il consolidamento successivo di più voci. | Le varianti rimangono associate al rispettivo processo principale. |
| Capacità di revisione | La cronologia e le decisioni sono suddivise in diverse voci. | Le variazioni, i controlli e le approvazioni rimangono collegati tra loro. |
| Disattivazione e archiviazione | Spesso rimangono copie che non vengono più utilizzate. | Le varianti possono essere disattivate o archiviate in modo mirato. |
| Prospettiva gestionale | Mostra numerose voci simili senza un’assegnazione di livello superiore. | Mostra un processo comune con caratteristiche controllate. |
Le elaborazioni secondarie non hanno quindi lo scopo di ridurre il volume di documentazione richiesto. Esse mirano a Documentazione strutturarlo in modo tale che sia possibile gestire sia gli standard comuni che le specificità locali.
Eredità e manutenzione locale dei campi
Non è necessario aggiornare nuovamente tutte le informazioni relative a un’attività di trattamento in ogni variante locale. Nel caso di processi comparabili a livello di gruppo, può essere opportuno riprendere determinate informazioni dall’elaborazione centrale. Per altre informazioni dovrebbe essere possibile integrarle, verificarle o sovrascriverle a livello locale.
| Gruppo di campi | Trattamento tipico | Motivazione |
|---|---|---|
| Nome del processo e scopo principale | Assegnazione centralizzata | Favorisce una struttura uniforme e la riconoscibilità. |
| Descrizione del processo standard | Assegnazione centralizzata | Evita di creare copie della stessa descrizione che differiscano tra loro. |
| Categorie di dati standard | Ereditare e integrare localmente | Le categorie di dati locali aggiuntive devono rimanere identificabili. |
| Gruppi di persone interessate | Ereditare e integrare localmente | I gruppi sono spesso simili, ma non necessariamente del tutto identici. |
| Sistema centrale | Assegnazione centralizzata | I sistemi utilizzati a livello di gruppo non devono essere aggiornati più volte. |
| Sistemi locali | Aggiungere a livello locale | Eventuali applicazioni diverse devono essere espressamente documentate. |
| Fornitore di servizi standard | Assegnazione centralizzata | Evita di inserire più volte gli stessi dati relativi al fornitore di servizi. |
| Fornitori di servizi locali | Aggiungere a livello locale | Può essere utilizzato per Elaborazione dell'ordine, i trasferimenti verso paesi terzi e i rischi possono essere rilevanti. |
| Base giuridica | Applicare parzialmente e verificare localmente | Le peculiarità locali possono richiedere una valutazione a parte. |
| Termini di cancellazione | Rendere ereditario e configurare in modo che sia sovrascrivibile localmente | Deve essere possibile rappresentare le differenze nazionali o organizzative. |
| Misure tecniche e organizzative | Ereditare e integrare localmente | Le misure a livello centrale possono essere integrate da provvedimenti a livello locale. |
| Rischi | Collegare tra loro i rischi centrali e quelli locali | È necessario distinguere tra le situazioni di rischio a livello di gruppo e quelle a livello locale. |
| Proprietario | Assegnazione locale | La responsabilità operativa deve essere chiaramente definita per ciascuna variante. |
| Approvazione | A seconda del processo, a livello locale o centrale | Lo stato di approvazione può variare da una variante all’altra. |
| Stato | Gestire a livello locale | Una variante può essere attiva, pianificata, disattivata o archiviata. |
| Data della recensione | Impostazione locale o centrale | La competenza dipende dal profilo di rischio e dal modello organizzativo. |
L'obiettivo non è quello di ereditare centralmente il maggior numero possibile di campi. Occorre piuttosto stabilire quali dati rappresentino effettivamente uno standard vincolante e quali informazioni richiedano una verifica e un controllo a livello locale.
Requisiti per le varianti locali
Le varianti locali non dovrebbero essere gestite come copie liberamente modificabili. È invece necessaria una struttura che consenta di tracciare il riferimento all'elaborazione principale, la specifica divergenza e la responsabilità ad essa associata.
Una sotto-Elaborazione dovrebbe quindi almeno far capire:
- su quale elaborazione di base si fonda,
- quale società, quale sede o quale dipartimento sia interessato,
- quali campi si discostano dallo standard a livello di gruppo,
- per quale motivo sia necessaria la deroga,
- chi ha verificato la discrepanza,
- chi ha concesso l'autorizzazione,
- quali rischi aggiuntivi potrebbero derivare da tale scostamento,
- quali misure locali sono previste,
- in quale momento debba essere effettuata una nuova verifica e
- se la variante è pianificata, in fase di verifica, attiva, disattivata o archiviata.
Senza queste informazioni, si corre il rischio che venga creata semplicemente un’altra copia con una denominazione diversa. Solo l’assegnazione documentata, la motivazione e l’approvazione trasformano la divergenza locale in un oggetto di governance gestibile.
Discostamenti specifici per i casi d'uso
Non tutte le varianti sono legate a un determinato Paese, a una società o a una sede. Possono esserci delle differenze anche a causa di un caso d'uso specifico.
Un processo CRM può, ad esempio, essere utilizzato come standard per l’assistenza clienti. Una business unit utilizza lo stesso processo anche per un programma di eventi, mentre un’altra unità lo impiega per la comunicazione con i partner. In una sede può essere utilizzata una fonte di dati aggiuntiva. Un team di progetto può integrare il processo esistente con funzioni di analisi.
In tali casi occorre verificare se si tratti ancora di una componente del processo principale esistente o se sia necessario documentare un’attività di trattamento autonoma. Sono determinanti, in particolare, la finalità, i dati trattati, i destinatari, il livello di rischio e la responsabilità organizzativa.
Non sarebbe quindi opportuno considerare automaticamente ogni divergenza come un sub-Elaborazione classificarla, né rappresentare ogni particolarità tramite una copia completamente nuova e non collegata. È fondamentale stabilire se il nucleo comune del processo sia ancora valido e se la deviazione possa essere descritta in modo sufficientemente preciso, verificata e approvata.
Distinzione rispetto all’attività di trattamento autonoma
I trattamenti in subappalto non devono portare a nascondere differenze sostanziali tra le attività di trattamento. Un trattamento autonomo Elaborazione può essere preso in considerazione in particolare quando:
- se lo scopo è sostanzialmente diverso,
- vengano coinvolti altri gruppi interessati,
- vengano trattati ulteriori categorie di dati che comportano un rischio più elevato,
- un altro sistema o un altro fornitore di servizi modifichi in modo sostanziale la situazione di rischio,
- vengano coinvolti altri destinatari oppure
- la variante locale rappresenta, dal punto di vista organizzativo, un processo a sé stante.
Se viene utilizzato un sistema HR standard per la gestione delle candidature, ma una società locale lo impiega anche per effettuare valutazioni automatizzate dell’idoneità avvalendosi dell’intelligenza artificiale, ciò può andare oltre una semplice deviazione minima, a seconda della configurazione concreta. In tal caso, può trattarsi di un’attività di trattamento autonoma o, quantomeno, di una sotto-Elaborazione potrebbe essere necessaria una valutazione dei rischi specifica e un’autorizzazione separata.
È quindi determinante la delimitazione tecnica. La semplificazione amministrativa non può essere l’unico fattore determinante per decidere se si tratti di una variante o di un’attività di trattamento autonoma.
Approvazione delle deroghe locali
Una variante locale non dovrebbe essere trasferita allo stato operativo senza una verifica documentata. Il processo di approvazione richiesto non deve necessariamente essere complesso, ma dovrebbe prevedere responsabilità e fasi di verifica ben definite.
Un processo tipico può comprendere le seguenti fasi:
- Il proprietario locale presenta la richiesta di deroga.
- Il sistema indica quali campi si discostano dallo standard.
- Il responsabile della protezione dei dati verifica la rilevanza ai fini della normativa sulla protezione dei dati.
- Ove necessario, vengono coinvolti l’ufficio legale, il reparto di sicurezza informatica, il responsabile della protezione dei dati o altri organismi competenti.
- I rischi individuati e le misure necessarie vengono documentati.
- La variante viene approvata, approvata con riserva o rinviata per essere rielaborata.
- Alla variante vengono assegnati uno stato e una data di revisione.
- La variazione rimane collegata all'elaborazione di base.
In questo modo non solo viene documentata una modifica al record di dati, ma rimane anche tracciabile su quale base la variazione sia stata verificata e approvata.
Modello di stato per le sotto-elaborazioni
Le elaborazioni secondarie dovrebbero disporre di uno stato proprio. Senza un modello di stato di questo tipo, non è possibile distinguere in modo affidabile se una variante sia semplicemente in fase di preparazione, sia già stata verificata, sia in uso operativo o non sia più utilizzata.
| Stato | Significato |
|---|---|
| Bozza | La variante è in fase di preparazione e non è ancora valida. |
| In fase di verifica | Protezione dei dati, l'ufficio legale o altri soggetti competenti verificano la discrepanza. |
| Restituito | Mancano alcune informazioni oppure la discrepanza non è sufficientemente motivata. |
| Approvato | La variante è attiva e può essere utilizzata. |
| Approvato con riserva | La variante è attiva, ma è soggetta a determinate misure o scadenze. |
| In fase di revisione | La variante viene rivalutata. |
| Disattivato | La variante non viene più utilizzata, ma rimane comunque comprensibile. |
| Archiviato | Questa variante è rilevante dal punto di vista storico, ma non è più operativa. |
| Cancellato | La variante può essere eliminata, purché non sussistano obblighi di documentazione di natura giuridica o tecnica che lo impediscano. |
Un RoPA di gruppo può diventare poco chiaro non solo a causa dell’aggiunta continua di nuove voci. Lo stesso vale per le varianti che non sono più necessarie dal punto di vista operativo, ma il cui stato non è stato aggiornato. Un modello di stato tracciabile è quindi un requisito fondamentale per la gestione continua dell’elenco.
Disattivazione, archiviazione e cancellazione
Le varianti non più rilevanti non dovrebbero essere mantenute in modo permanente come attività di elaborazione attive. Un immediato Cancellazione tuttavia, non è sempre la soluzione più adeguata.
Innanzitutto occorre verificare se la variante in questione sia stata effettivamente utilizzata a livello operativo. Se non è mai stata impiegata, è possibile che Cancellazione possono essere presi in considerazione, purché non sussistano né obblighi legali di prova né motivi interni che giustifichino un’ulteriore Immagazzinamento esistere.
Se invece la variante è stata utilizzata a fini operativi, è generalmente più opportuno disattivarla o archiviarla. In questo modo rimane tracciabile se e per quale periodo la variante è esistita, quando è stata disattivata, quali dati sono stati interessati, quali termini di conservazione devono ancora essere rispettati e quali decisioni devono essere prese in relazione alla Elaborazione sono state adottate.
Una verifica dei sub-Elaborazione è da prendere in considerazione in particolare quando:
- la società in questione non utilizza più il processo,
- il sistema in uso è stato disattivato,
- è stato cambiato il fornitore di servizi,
- lo scopo è venuto meno,
- il caso d'uso sottostante è stato completato,
- una deroga, finora di natura locale, è stata integrata nello standard a livello di gruppo,
- la variante è stata sostituita da una nuova variante oppure
- nel corso di un audit è stata riscontrata una struttura obsoleta.
La disattivazione rientra quindi nell'ambito della governance e non è semplicemente una misura volta alla pulizia formale dell'elenco.
Requisiti relativi alla rendicontazione
Per un responsabile della protezione dei dati a livello di gruppo o per una funzione centrale di protezione dei dati, un elenco di numerose attività di trattamento pressoché identiche ha solitamente un valore informativo limitato. È invece necessaria un’analisi da cui emerga:
- quali processi sono standardizzati a livello di gruppo,
- quali società o sedi si discostano dallo standard,
- quali deviazioni presentano un rischio maggiore,
- quali varianti non sono ancora state approvate,
- per quali varianti è ormai necessario adottare misure a livello locale,
- quali voci sono obsolete e
- quali differenze locali dovrebbero, se del caso, essere integrate nello standard a livello di gruppo.
Un report sulla gestione delle candidature non dovrebbe quindi limitarsi a mettere semplicemente in parallelo diverse operazioni di trattamento non collegate tra loro. Dovrebbe riportare il processo principale, le varianti attive, le rispettive discrepanze, lo stato di rischio e di approvazione, le revisioni in ritardo, le misure in sospeso, le varianti scadute e le società prive di una verifica aggiornata.
Una tale rendicontazione presuppone che l’elaborazione dei dati anagrafici e delle varianti sia collegata in modo strutturato. Solo allora il RoPA può andare oltre la semplice Documentazione può essere utilizzato anche come strumento di controllo.
Rapporto con l’art. 30 del GDPR
Art. 30 GDPR richiede ai titolari del trattamento un registro delle operazioni di trattamento che rientrano nella loro responsabilità. I responsabili del trattamento devono tenere un registro delle categorie di operazioni di trattamento che effettuano per conto di un titolare del trattamento. Il registro in questione è il Autorità di vigilanza da mettere a disposizione su richiesta.
Il GDPR non impone tuttavia alcun modello tecnico specifico. In particolare, dall'art. 30 risulta che GDPR Non è detto che ogni variazione locale debba necessariamente essere registrata come voce completamente isolata. Allo stesso modo, la norma non richiede che processi simili vengano documentati tramite copie non collegate tra loro.
È fondamentale che le informazioni effettivamente rilevanti siano accurate, comprensibili e disponibili. L’EDPB descrive il registro come un inventario delle operazioni di trattamento, sulla base del quale è possibile individuare le responsabilità e i possibili rischi. Tra le informazioni rilevanti figurano, tra l’altro, la finalità, le categorie di dati, i destinatari, eventuali trasferimenti, i periodi di conservazione o di cancellazione e le misure di sicurezza previste.
Le operazioni di subappalto non sostituiscono quindi i requisiti di cui all’art. 30 GDPR. Rappresentano piuttosto un possibile modello organizzativo per rappresentare in modo strutturato le informazioni necessarie all'interno di complesse strutture aziendali.
Supporto fornito da Ailance RoPA
Ailance RoPA può rappresentare i processi aziendali come elaborazioni di base interconnesse e varianti locali o specifiche per i singoli casi d'uso. L'elaborazione di base centrale descrive lo standard comune, mentre le elaborazioni secondarie subordinati ne definiscono le rispettive peculiarità.
I campi possono essere importati dall'elaborazione dei dati anagrafici, integrati localmente o sovrascritti in modo controllato. In questo modo, eventuali discrepanze rimangono evidenti. È possibile assegnare a ciascuna variante responsabilità, approvazioni, misure, indicazioni di stato e scadenze di revisione.
Per quanto riguarda il controllo, occorre distinguere in particolare tre livelli:
Standard
Quali dati sono validi a livello di gruppo per il processo comune?
Variante
Quali informazioni si applicano in modo diverso a una determinata società, a una sede o a un caso d’uso specifico?
Prova
Chi ha verificato, approvato, modificato, rivalutato o disattivato la deviazione?
Questa distinzione è particolarmente rilevante per le organizzazioni di grandi dimensioni con numerosi processi simili. Spesso i problemi nel RoPA non derivano solo dalla mancanza di voci, ma dal fatto che tra voci simili non esiste una struttura chiara.
Esempio: comunicazione con gli inquilini
Un gruppo immobiliare svolge un’attività di trattamento dei dati finalizzata alla comunicazione con gli inquilini. Il trattamento dei dati anagrafici può comprendere, in particolare, le seguenti informazioni:
- Comunicazione con gli inquilini,
- Dati anagrafici,
- Dati di contatto,
- Riferimento al contratto,
- Gestione delle richieste,
- Utilizzo di un sistema CRM centralizzato,
- un termine standard per la cancellazione,
- Destinatari predefiniti e
- centrale misure tecniche e organizzative.
A livello locale possono esserci diverse varianti. Una società si avvale inoltre di un centro servizi locale. In una sede viene utilizzato un ulteriore strumento di comunicazione. In una regione vengono elaborate informazioni specifiche sui sinistri. Una società si affida a un fornitore esterno di servizi di stampa, mentre un’altra gestisce una propria app per gli inquilini.
Queste peculiarità possono essere documentate sia come attività di trattamento autonome sia come attività di sub-trattamento chiaramente delimitate. Nella misura in cui il nucleo comune del processo permane, l’assegnazione al trattamento principale consente una rappresentazione più chiara dello standard a livello di gruppo e delle rispettive deroghe locali.
Esempio: processi di gestione delle strutture
I processi relativi alle strutture, data la loro natura legata alla sede, sono particolarmente soggetti alla creazione di numerose voci simili. Tra queste figurano, ad esempio, la registrazione dei visitatori, Controllo degli ingressi fisici, Videosorveglianza, gestione delle chiavi, gestione dei parcheggi, coordinamento delle pulizie e segnalazioni di riparazioni.
Molte sedi gestiscono questi processi in modo simile. La loro configurazione concreta può tuttavia variare notevolmente da una sede all’altra. In una sede, ad esempio, Videosorveglianza utilizzato in una sede, ma non in un’altra. Alcune sedi si avvalgono di fornitori di servizi locali, elaborano le targhe automobilistiche, tengono registri aggiuntivi degli accessi o utilizzano un’app specifica. Altre sedi continuano a lavorare con elenchi manuali.
Le elaborazioni secondarie possono contribuire a rendere visibili queste varianti di sede, senza suddividere il processo comune della struttura in numerose voci non correlate. In questo modo, il controllo centrale può continuare a identificare quali specifiche fanno parte del processo standard e in quali sedi si registrano deviazioni da esso e per quali motivi.
Esempio: CRM
I processi CRM sono spesso rilevanti a livello di gruppo. L'elaborazione dei dati anagrafici può riguardare la gestione di clienti e potenziali clienti. Le varianti locali possono, tra l'altro, riflettere diversi consensi al trattamento dei dati a fini di marketing, campagne locali, fonti di dati aggiuntive, destinatari specifici, logiche di cancellazione diverse o diverse modalità di utilizzo del sistema.
Proprio nei processi CRM, in presenza di copie non collegate tra loro sussiste il rischio di informazioni contraddittorie riguardo alle finalità, ai destinatari, Base giuridica e i termini di cancellazione. Una procedura principale con procedure secondarie associate può invece consentire di individuare quali dati siano validi a livello di gruppo e quali particolarità locali o specifiche per i singoli casi d’uso siano state verificate e approvate.
Domande di verifica per i RoPA di gruppo esistenti
Per una prima analisi della situazione, è possibile selezionare un processo presente in più società o in più sedi. Tra questi figurano, ad esempio, la gestione delle candidature, il CRM, la comunicazione con gli inquilini, il facility management, la gestione dei fornitori, la registrazione dei visitatori, la gestione dei corsi di formazione o il supporto IT.
Successivamente, occorre esaminare in particolare le seguenti questioni:
- Esiste un processo di base chiaramente definito?
- Quali varianti locali o specifiche per determinati casi d’uso esistono?
- Le discrepanze sono espressamente documentate o figurano semplicemente in copie indipendenti l'una dall'altra?
- Chi ha verificato e approvato le rispettive discrepanze?
- Quali varianti non vengono più utilizzate a livello operativo?
Se non è possibile rispondere facilmente a queste domande, ciò non indica di norma che il numero delle operazioni di trattamento sia troppo esiguo. È invece possibile che vi sia una mancanza di struttura tra le voci presenti.
Conclusione
I processi secondari possono costituire un modello strutturale adeguato per i RoPA a livello di gruppo, qualora processi simili vengano eseguiti in diverse società, paesi o sedi, pur non essendo identici in ogni dettaglio.
Le copie non collegate possono essere inizialmente create con uno sforzo minimo. Tuttavia, con l’aumentare del loro numero, possono portare a informazioni contraddittorie, responsabilità poco chiare, difficoltà nell’aggiornamento e una limitata possibilità di analisi. Un’elaborazione dei dati di base con varianti locali o specifiche per i casi d’uso può invece mettere in evidenza quali informazioni costituiscono lo standard comune e in quali punti sussistono scostamenti verificati.
Una struttura di questo tipo supporta i processi di approvazione, la rendicontazione, le revisioni, nonché la disattivazione e l’archiviazione delle varianti non più necessarie. È fondamentale che ogni variazione possa essere associata a un processo tracciabile, a un responsabile e a uno stato documentato.
Domande e risposte
Cosa sono i trattamenti secondari nel registro delle attività di trattamento?
Le elaborazioni secondarie sono varianti subordinate di un’elaborazione principale. Rappresentano deviazioni locali o specifiche per un caso d’uso rispetto al nucleo comune del processo. Il termine non indica una categoria autonoma della GDPR, bensì un possibile modello strutturale per i RoPA dei gruppi aziendali.
I trattamenti secondari sono la stessa cosa del trattamento in subappalto?
No. In questo articolo, con il termine “sub-trattamenti” non si intendono né i subappaltatori né i responsabili del trattamento in subappalto. Il termine indica varianti di un’attività di trattamento all’interno di un modello RoPA strutturato.
Perché i subappalti possono essere utili per le grandi aziende?
In molti gruppi aziendali i processi vengono eseguiti in modo simile, ma non del tutto identico. Le elaborazioni secondarie consentono di combinare un processo di base comune con variazioni locali controllate, senza dover creare una copia separata per ogni variante.
Quando è opportuno utilizzare un’elaborazione secondaria anziché una copia?
Una sotto-Elaborazione è da prendere in considerazione quando il nucleo comune del processo rimane invariato e solo singoli dati differiscono a livello locale o in base a specifici casi d’uso. Ciò può riguardare, ad esempio, fornitori di servizi locali, categorie di dati aggiuntive, scadenze diverse, sistemi locali o autorizzazioni particolari.
Quando è preferibile il trattamento in proprio rispetto al subappalto?
Una autonoma Elaborazione può essere necessario qualora, in particolare, la finalità, il livello di rischio, il sistema utilizzato, le categorie di dati, i destinatari o la responsabilità organizzativa differiscano in misura tale da rendere il nucleo originario del processo non più sostenibile.
Quali campi dovrebbero essere importati dall'elaborazione dei dati anagrafici?
In genere, il nome del processo, lo scopo principale, la descrizione standard, i sistemi centrali, le categorie di dati standard, i fornitori di servizi standard, i sistemi centrali misure tecniche e organizzative nonché la logica di cancellazione predefinita. È necessario verificare, per ciascun gruppo di campi, se tale applicazione sia corretta.
Quali informazioni devono essere incluse in una variante locale?
Una variante locale dovrebbe in particolare... colpiti Società, sede o caso d'uso, campi che presentano discrepanze, motivo della discrepanza, persone responsabili, rischi, misure, approvazioni, informazioni sullo stato e data prevista per la revisione.
Come dovrebbero essere approvate le deroghe locali?
Qualsiasi deroga locale deve essere richiesta, sottoposta a verifica tecnica, documentata e approvata. A seconda della natura e del rischio della deroga, potrebbero essere coinvolti i reparti responsabili della protezione dei dati, l'ufficio legale, la sicurezza informatica, il responsabile della protezione dei dati o altri organismi competenti. La variante deve rimanere associata al trattamento di base a cui si riferisce.
Quando è opportuno disattivare le elaborazioni secondarie?
È necessario valutare in particolare la disattivazione qualora la variante locale non venga più utilizzata, abbia perso la sua finalità, un sistema sia stato disattivato, sia stato cambiato il fornitore di servizi o la precedente deroga sia stata integrata nello standard a livello di gruppo.
I trattamenti secondari dovrebbero essere cancellati o archiviati?
Se una variante è stata utilizzata a livello operativo, è spesso più opportuno archiviarla o disattivarla piuttosto che procedere immediatamente a Cancellazione. In questo modo è possibile tracciare le decisioni precedenti, i termini di cancellazione e le altre documentazioni. Una Cancellazione può essere presa in considerazione soprattutto nel caso in cui la variante non sia mai stata utilizzata in ambiente produttivo e non sussistano motivi giuridici o tecnici che ne giustifichino la conservazione.
In che modo Ailance RoPA può supportare le operazioni di sub-elaborazione?
Ailance RoPA è in grado di integrare tra loro elaborazioni dei dati di base, varianti locali, campi importati, scostamenti, responsabilità, approvazioni, misure, indicazioni di stato e revisioni. Ciò consente di rappresentare in modo strutturato sia gli standard comuni che le specificità locali all’interno del RoPA del gruppo.
Qual è il vantaggio principale delle lavorazioni secondarie?
Il vantaggio principale risiede nel collegamento tracciabile tra lo standard e la deroga. Il RoPA non si limita quindi a mostrare diversi processi simili, ma indica anche in quali punti una determinata variante si discosta dallo standard, per quale motivo ciò avvenga e chi abbia verificato e approvato la deroga.
German 
English 
Italian 
French