Il problema dei controlli condivisi tra sicurezza e privacy non è trovare un reparto da inserire in una matrice. È stabilire chi deve intervenire quando una revisione degli accessi resta incompleta, una cancellazione non raggiunge i backup o un incidente richiede decisioni sia tecniche sia sul trattamento dei dati. Se il responsabile indicato è «IT e privacy», l’auditor può trovare due team coinvolti ma nessuno che risponda dello stato del controllo.
Per evitare questo vuoto serve un owner operativo riconoscibile, affiancato da esecutori, decisori e verificatori con compiti distinti. L’assegnazione deve comparire nelle prove: richieste approvate, risultati dei test, eccezioni gestite e azioni correttive chiuse. Di seguito trovi un metodo applicato a tre controlli nei quali il passaggio tra funzioni crea spesso ambiguità, senza ricostruire una matrice RACI generale.
Assegnare gli owner tra sicurezza e privacy
L’owner operativo di un controllo non coincide necessariamente con il responsabile di una funzione né con un ruolo previsto dalla normativa. È la persona incaricata di mantenerlo funzionante: conosce il perimetro, coordina gli esecutori, verifica la disponibilità delle evidenze e porta le anomalie a chi può decidere.
Il GDPR, negli articoli 5, 24, 32, 38 e 39, disciplina responsabilizzazione del titolare, misure di sicurezza e compiti del DPO. L’assegnazione interna descritta qui è una scelta organizzativa per rendere verificabili questi presidi, non una sostituzione delle responsabilità normative. Nei controlli di sicurezza e privacy, chiamare qualcuno «owner» non trasferisce automaticamente a quella persona le responsabilità del titolare del trattamento.
Una regola operativa utile è assegnare l’ownership a chi può coordinare il ciclo completo del controllo. Se quella persona può soltanto sollecitare altri reparti, senza ottenere informazioni o attivare un’escalation, l’incarico è debole. Occorre allora attribuirle un mandato concreto oppure suddividere il controllo in attività collegate, ciascuna con un responsabile.
Il DPO svolge funzioni di consulenza e sorveglianza: non va quindi indicato automaticamente come esecutore, approvatore e verificatore di ogni attività che riguarda dati personali. L’assetto deve rispettarne l’indipendenza ed evitare conflitti di interessi. La verifica di questi aspetti resta distinta dal metodo operativo qui proposto.
Definire il confine prima di scegliere il nome
«Gestione degli accessi» è un perimetro troppo ampio per assegnare un owner verificabile. «Riesame trimestrale delle utenze del CRM, comprese quelle dei fornitori» identifica invece un’attività osservabile, con un inizio e un risultato atteso. La frequenza è un esempio organizzativo, non un requisito universale.
Per ogni controllo condiviso tra sicurezza e privacy, descrivi prima il risultato che deve essere dimostrato. Poi individua chi dispone delle leve necessarie per ottenerlo. Una scheda operativa può contenere questi campi:
- Perimetro: sistemi, trattamenti, categorie di utenti e dipendenze coinvolte.
- Owner operativo: persona incaricata, ruolo organizzativo e sostituto in caso di assenza.
- Contributi richiesti: chi esegue, chi decide le eccezioni e chi verifica il risultato.
- Evidenza attesa: documento o registrazione, periodo coperto e criterio di accettazione.
- Passaggio tra team: condizione di consegna, destinatario e percorso di escalation.
Il campo più importante è spesso l’ultimo. «Inviare il report alla funzione privacy» non chiarisce cosa debba accadere dopo. «La funzione competente conferma la coerenza delle autorizzazioni con le finalità del trattamento; l’IT revoca gli accessi respinti e registra l’esito» descrive invece una sequenza verificabile.
La scheda deve essere accettata dai ruoli coinvolti. Un nome inserito unilateralmente in un foglio non dimostra che la persona abbia ricevuto l’incarico, compreso il perimetro o ottenuto accesso alle informazioni necessarie.
Tre controlli condivisi e i rispettivi punti di consegna
Gli esempi seguenti non prescrivono un organigramma. Mostrano come separare l’operatività tecnica dalla decisione sul processo e dalla verifica finale. I ruoli vanno adattati alle dimensioni dell’organizzazione e ai poteri effettivamente attribuiti.
Riesame degli accessi: chi decide e chi revoca
Considera un CRM che contiene dati di clienti e contatti commerciali. L’amministratore del sistema può estrarre le utenze, ma non sempre conosce la necessità concreta di ogni autorizzazione. Il responsabile del processo commerciale può confermare tale necessità, ma non dispone necessariamente dei permessi per revocare gli accessi.
Qui sicurezza e privacy devono condividere il risultato atteso senza confondere le attività. Un possibile assetto prevede un owner operativo del riesame, un responsabile di processo che valuta gli accessi e un esecutore tecnico che applica le modifiche.
La prova di chiusura non è il solo elenco delle utenze. Deve collegare la situazione iniziale alle decisioni e allo stato finale:
| Passaggio | Ruolo operativo nell’esempio | Evidenza da conservare |
|---|---|---|
| Estrazione delle utenze nel perimetro | Amministratore del sistema | Report datato con criteri di estrazione |
| Valutazione della necessità degli accessi | Responsabile del processo | Decisioni riconducibili a utenti e autorizzazioni |
| Revoche e modifiche | Esecutore tecnico | Ticket e riscontro dello stato aggiornato |
| Verifica del completamento | Verificatore designato | Confronto tra decisioni e modifiche effettuate |
L’owner resta responsabile del coordinamento fino all’ultimo passaggio. Se mancano tre revoche, il controllo non è completato solo perché il responsabile commerciale ha approvato il report. Per distinguere documenti disponibili e prove utilizzabili, è utile applicare criteri coerenti alle evidenze di audit.
Cancellazione e backup: evitare due definizioni di «completato»
Una richiesta di cancellazione può risultare chiusa nel sistema principale mentre copie, esportazioni o backup conservano ancora i dati. Il team applicativo e quello infrastrutturale potrebbero usare criteri di completamento diversi, lasciando il problema senza un responsabile end-to-end.
Il primo passo è censire le copie comprese nel controllo e quelle gestite attraverso procedure differenti. Chi governa il processo di trattamento definisce il risultato richiesto con il supporto delle competenze pertinenti; chi gestisce applicazioni e infrastruttura documenta come quel risultato viene realizzato. La valutazione della liceità dei tempi e delle modalità di conservazione non si risolve con una scelta tecnica.
Per questo controllo di sicurezza e privacy, l’owner deve ottenere una risposta esplicita sulle copie residue. «Il dato non compare più nell’interfaccia» non dimostra che il percorso sia completo.
Le evidenze possono comprendere l’esito della cancellazione applicativa, il perimetro delle copie, le regole applicate ai backup e una prova della procedura prevista in caso di ripristino. Quest’ultima serve a verificare come vengono trattati dati già cancellati che potrebbero riapparire dopo un restore.
Se una componente non consente il risultato previsto, l’owner apre un’azione correttiva con perimetro, responsabile e criterio di verifica. Non chiude il controllo annotando genericamente «limite tecnico» e non presenta una decisione interna sul rischio come prova di conformità del trattamento.
Incidenti: separare il contenimento dalla valutazione privacy
Durante un incidente, sicurezza e privacy hanno bisogno di fatti comuni, ma devono rispondere a domande differenti. Il team tecnico deve capire cosa è accaduto e contenere l’evento; la funzione competente deve valutare le conseguenze per i dati personali e attivare il percorso decisionale previsto dall’organizzazione.
Non ogni incidente informatico comporta una violazione di dati personali. La pagina del Garante sulle violazioni di dati personali chiarisce il tema del data breach e degli adempimenti collegati. La valutazione concreta deve essere condotta dai soggetti competenti, non dedotta automaticamente dalla classificazione tecnica dell’evento.
L’owner del processo di gestione incidenti coordina la raccolta dei fatti. Il dossier iniziale dovrebbe indicare sistemi e dati potenzialmente coinvolti, intervallo temporale, soggetti interessati e informazioni ancora da verificare. Deve inoltre distinguere fatti confermati e ipotesi, così che una decisione non si basi su un dato provvisorio presentato come certo.
Il passaggio alla valutazione privacy va registrato: chi ha ricevuto il dossier, quando, quali integrazioni ha richiesto e quale decisione è stata assunta. La chiusura tecnica dell’incidente non coincide automaticamente con la chiusura delle attività privacy o delle azioni correttive.
Quando il controllo fallisce, l’ownership deve restare visibile
Il momento decisivo non è l’assegnazione iniziale, ma la gestione dell’anomalia. Un controllo può avere un owner formalmente corretto e perdere comunque responsabilità quando il problema viene trasferito a un altro reparto o a un fornitore.
Nei controlli di sicurezza e privacy, l’owner del controllo e l’owner della remediation possono essere persone diverse. Il primo mantiene visibilità sulla copertura e sul rischio residuo; il secondo realizza l’intervento assegnato. La consegna dell’attività non deve interrompere il collegamento tra i due.
Per esempio, una revisione rileva utenze di ex collaboratori ancora attive. L’owner del riesame apre il finding e documenta il perimetro. L’amministratore incaricato revoca gli accessi. Il verificatore controlla che le utenze indicate siano effettivamente disabilitate e che la prova copra l’elenco originale, non un campione scelto dopo l’intervento.
La chiusura va motivata rispetto al difetto rilevato. Un ticket con stato «risolto» è insufficiente se non contiene il riscontro dell’intervento o il collegamento alla relativa evidenza. Se l’azione modifica il controllo, occorre aggiornare anche procedura, perimetro e scheda di ownership.
Le variazioni di incarico devono essere datate, con una consegna esplicita delle attività aperte. Le buone pratiche per l’audit trail aiutano a ricostruire chi ha modificato lo stato, quale prova ha utilizzato e perché ha considerato il problema chiuso.
Se interviene un’automazione, assegnare anche il recupero dall’errore
Un workflow automatico può distribuire ticket o proporre la classificazione di un incidente. Questo non elimina il bisogno di individuare chi controlla il risultato, corregge gli errori e gestisce i casi che l’automazione non riesce a trattare.
Anche quando un sistema di IA supporta sicurezza e privacy, l’ownership deve coprire il recupero dall’errore. Se una richiesta viene instradata al team sbagliato, devono essere chiari il responsabile della correzione, il percorso di escalation e la gestione delle attività rimaste sospese.
L’analisi di come l’assenza di un owner degli errori indebolisce la fiducia nei sistemi di IA offre un criterio di progettazione pertinente: rendere visibili gli stati del workflow, le fonti utilizzate e il percorso di correzione, anziché affidarsi soltanto a un punteggio di confidenza.
Nell’evidence pack conserva quindi anche la decisione umana che corregge o conferma l’esito, quando prevista dal processo. Il solo output automatico non dimostra chi abbia assunto la decisione operativa.
Preparare una prova di ownership per l’auditor
Per verificare l’assetto, seleziona un controllo reale e ricostruiscine l’ultima esecuzione. Parti dalla scheda di assegnazione, segui i contributi dei diversi team e arriva alle evidenze di completamento. Se devi spiegare a voce chi ha deciso un’eccezione, probabilmente manca una registrazione nel fascicolo.
Un evidence pack sui controlli di sicurezza e privacy dovrebbe permettere di rispondere a quattro domande: chi coordinava l’attività, chi poteva decidere, chi ha eseguito l’intervento e chi ne ha verificato l’esito. Non serve duplicare ogni documento per ogni funzione: serve collegare la stessa prova ai controlli pertinenti, preservando contesto e autorizzazioni di accesso.
Prima dell’audit controlla inoltre che l’owner sia ancora in carica, che il sostituto sia identificato e che le eccezioni aperte abbiano una scadenza. Un controllo apparentemente completato può avere una copertura parziale: il dossier deve mostrarla, non nasconderla dietro un indicatore verde.
Questo lavoro rende l’assegnazione verificabile nel tempo. Per inserirlo nel percorso più ampio di conformità GDPR dimostrabile in audit, mantieni distinti requisiti, controlli, risultati dei test e decisioni sulle anomalie.
Domande frequenti
È necessario nominare un solo owner per ogni controllo? Un owner operativo unico è una scelta utile per evitare vuoti di coordinamento, non una regola universale qui attribuita al GDPR. Nei controlli complessi puoi assegnare owner alle singole componenti, mantenendo un responsabile del risultato complessivo.
Chi decide se IT e funzione privacy non concordano sulla chiusura? Il conflitto va portato al ruolo con il potere decisionale previsto dalla governance interna. Per i controlli di sicurezza e privacy, registra il punto controverso, le prove disponibili e la decisione, senza trasformare il silenzio di una funzione in approvazione.
La stessa persona può eseguire e verificare il controllo? La separazione offre maggiore indipendenza. Se le risorse non la consentono, documenta il limite e prevedi un riesame proporzionato da parte di un altro ruolo, soprattutto per attività ad alto rischio. Non presentare un’autoverifica come verifica indipendente.
Rendere operativa l’assegnazione
AuditReady centralizza evidenze con ownership, versioni e audit trail e consente di gestire controlli, findings e remediation. Per applicare questo modello ai tuoi presidi, valuta AuditReady per i controlli GDPR, partendo da un controllo concreto e dal suo ultimo ciclo di esecuzione.
audit-ready evidence pack demo / not legal advice