Vai al contenuto
Legiscope
Menu
Protezione dei dati

Misure tecniche e organizzative: modello di allegato verificabile

Allegato TOM con perimetro, prove e gestione delle variazioni. Metodo, responsabilità, verifiche e documentazione da adattare al proprio contesto.

Disponibile anche in:Português·Svenska·Lietuvių·Dansk·Suomi·Norsk

Un allegato di misure tecniche e organizzative, spesso chiamato TOM, descrive come vengono protetti i dati nel servizio concreto. Per essere utile deve indicare perimetro, responsabilità, configurazioni e prove disponibili. Un elenco di parole come cifratura, backup e controllo degli accessi non permette di capire quali dati siano coperti né se le misure funzionino.

Gli articoli 28 e 32 GDPR sono riferimenti centrali per il rapporto con il responsabile e per la sicurezza adeguata al rischio. Questa guida segue il percorso di costruzione dell’allegato: identificare il trattamento, descrivere controlli osservabili, raccogliere evidenze e gestire le variazioni. La traccia deve essere completata con fatti verificati, senza trasformarla in una dichiarazione di conformità precostituita.

Delimitare il servizio cui si riferisce l’allegato

Indicate parti, servizio, ambienti e categorie di dati. Chiarite se il documento descrive misure generali del fornitore oppure configurazioni specifiche del cliente. La distinzione è essenziale: una funzionalità disponibile può richiedere attivazione, licenza o decisioni che non sono state ancora prese.

Collegate l’allegato alla nomina del responsabile del trattamento. Identificate versione, data e documenti richiamati, evitando riferimenti a pagine che cambiano senza una possibilità di ricostruzione. Se un controllo dipende da un subfornitore, rendete visibile questa dipendenza e la responsabilità di verifica.

La mappatura dei sistemi e dei flussi aiuta a evitare esclusioni involontarie. Un allegato può coprire produzione ma non assistenza, backup o ambienti che ricevono esportazioni. Tali limiti devono essere esaminati prima di considerare il documento completo.

Usare una struttura che renda verificabile ogni misura

Per ciascun controllo indicate obiettivo, attuazione, responsabile, perimetro e prova. Aggiungete frequenza o evento di riesame quando pertinente. La descrizione deve consentire a un revisore di formulare una domanda concreta, senza necessariamente rivelare dettagli tecnici che aumenterebbero il rischio.

Campo Esempio di contenuto da completare
Obiettivo Limitare accessi ai dati del servizio secondo il ruolo
Attuazione Processo di richiesta, approvazione e revoca
Perimetro Applicazioni e popolazioni coperte
Responsabilità Chi approva, configura e verifica
Evidenza Campione di autorizzazioni e revoche eseguite
Limiti Account o percorsi soggetti a eccezione
Riesame Evento o periodicità motivata

Distinguete misura applicata, pianificata e non pertinente. Una roadmap non dovrebbe essere descritta al presente come garanzia già operativa. Quando il controllo è parziale, indicate la porzione scoperta e la decisione sul rischio residuo.

Descrivere identità e autorizzazioni

Documentate creazione degli account, approvazione dei privilegi, revisione e cessazione. Considerate utenti ordinari, amministratori, identità di servizio e accessi esterni. Se il cliente deve fornire informazioni sugli ingressi e sulle uscite, spiegate il canale e il punto in cui il fornitore esegue la modifica.

La politica password e MFA può fornire il dettaglio dei percorsi di autenticazione. Nell’allegato precisate quali popolazioni e servizi siano coperti, evitando formule assolute se esistono eccezioni. La disponibilità di MFA non equivale all’obbligo effettivamente applicato.

Le prove possono includere configurazioni, richieste di accesso e campioni di revoca. Non consegnate password o token per dimostrare la misura. L’evidenza deve mostrare il funzionamento del controllo senza esporre i segreti che il controllo protegge.

Documentare cifratura e custodia delle chiavi

Indicate dove i dati sono cifrati, quali scenari la misura affronta e chi può accedere al contenuto. Distinguete dati in transito, archivi, backup ed esportazioni. La guida alla cifratura aiuta a formulare domande sulle chiavi e sui limiti della protezione.

Descrivete responsabilità di generazione, custodia, rotazione e recupero. Se una chiave è gestita dal cliente, verificate che il processo operativo sostenga tale attribuzione. Il contratto deve chiarire le dipendenze necessarie al servizio, senza dedurre dalla proprietà formale della chiave l’impossibilità di accesso da parte di qualsiasi altro soggetto.

Le evidenze possono comprendere schema architetturale, configurazione e prova controllata. Evitate promesse come «nessuno può leggere i dati» se l’applicazione li elabora in chiaro. Una descrizione precisa dei limiti è più utile di una formula assoluta non dimostrabile.

Coprire disponibilità e ripristino

Descrivete frequenza delle copie, perimetro, separazione, accessi e capacità di recupero. Distinguete obiettivi contrattuali da risultati osservati nelle prove. Un backup riuscito non dimostra automaticamente che il servizio sia ripristinabile con dati completi e applicazioni funzionanti.

Il piano di disaster recovery dovrebbe chiarire sequenza, dipendenze e responsabilità. Nell’allegato indicate che cosa deve fare il cliente e che cosa il fornitore. Se il recupero richiede chiavi o configurazioni custodite altrove, questa condizione deve essere esplicita.

Conservate prove recenti e pertinenti al servizio, con limiti del campione e azioni correttive. Non utilizzate una dimostrazione commerciale svolta su un ambiente diverso come unica evidenza della capacità di ripresa del trattamento effettivo.

Includere tracciabilità e gestione degli incidenti

Precisate sorgenti degli eventi, accessi ai log, conservazione e modalità di consegna. La progettazione dei log di sicurezza permette di distinguere autenticazione, consultazione, modifica ed esportazione. Non dichiarate tracciabilità di un’operazione che l’applicazione non registra.

Per gli incidenti, identificate canale, referenti, informazioni iniziali e aggiornamenti. Il contratto deve consentire al titolare di svolgere le proprie valutazioni, senza confondere il processo tecnico del fornitore con gli obblighi giuridici del cliente. Registrate anche disponibilità del contatto alternativo e gestione dell’assenza del referente ordinario.

Le prove possono comprendere un’esercitazione, una cronologia anonimizzata o un campione di comunicazione. Non è necessario divulgare dettagli di incidenti di altri clienti per dimostrare che un processo esiste. Valutate evidenze sufficienti e pertinenti, rispettando riservatezza e protezione dei terzi.

Trattare conservazione, cancellazione e uscita

L’allegato deve chiarire come vengono applicate le istruzioni di conservazione e cancellazione. Distinguete archivi attivi, backup, log e copie di assistenza. Una cancellazione nell’interfaccia può avere effetti differenti su queste componenti, che devono essere descritti con precisione.

Definite esportazione, restituzione e chiusura del servizio. Indicate formati, verifiche e responsabilità, evitando di rinviare ogni dettaglio al momento della cessazione. Un’uscita sicura richiede di sapere quali dati sono stati ottenuti, quali accessi sono stati revocati e quali copie rimangono per un motivo documentato.

Per un archivio ripristinato, considerate la verifica della cancellazione nei backup. Le istruzioni devono evitare che il recupero reintroduca dati eliminati o preferenze modificate senza riconciliazione.

Gestire variazioni e verifiche del documento

Stabilite come vengono comunicate modifiche rilevanti, quali informazioni riceve il cliente e chi valuta l’impatto. Una variazione del subfornitore o del percorso di assistenza può incidere sul contenuto dell’allegato anche senza cambiare il nome del servizio.

Il quadro CNIL sulla sicurezza dei dati personali offre un supporto per interrogare la completezza dei temi. Utilizzatelo come riferimento metodologico, mantenendo il documento aderente al contesto e alle evidenze disponibili.

Prima dell’approvazione, scegliete tre misure e chiedete di seguirle fino alla prova. Se il testo promette revoche, recuperi o cifratura ma nessuno sa individuare la configurazione o il risultato pertinente, completate il fascicolo o correggete la descrizione. L’allegato utile non è quello con il maggior numero di controlli elencati: è quello che rende comprensibili responsabilità, copertura e limiti delle misure effettivamente applicate.

Se una prova non può essere condivisa integralmente per ragioni di sicurezza, concordate un’alternativa che permetta comunque la valutazione: estratto pertinente, sessione di verifica o relazione con perimetro e conclusioni chiaramente descritti. L’indisponibilità del documento completo non autorizza a presumere che il controllo sia assente, ma neppure a considerarlo dimostrato senza elementi. Registrate l’evidenza alternativa, chi l’ha esaminata e quali limiti restano. Questa gestione rende il confronto con il fornitore concreto e riduce risposte standard che non consentono al cliente di valutare il proprio trattamento.

L
Scritto da
Legiscope
Legiscope

Metti in pratica questa guida

Scopri come Legiscope collega registri privacy, fonti e attività soggette a revisione.

Prenota una demo personalizzata
Continua a leggere

Articoli correlati

01Protezione dei dati

Accesso civico generalizzato: valutare il pregiudizio ai dati personali

Quando una richiesta di accesso civico generalizzato riguarda documenti con dati personali, l'amministrazione deve valutare se l'ostensione comporti un pregiudizio concreto alla protezione di quei…

8 settembre 2026
02Protezione dei dati

Accountability GDPR: organizzare prove e decisioni

L'accountability GDPR impone al titolare di rispettare i principi del trattamento e di poterlo dimostrare. Il punto di partenza è l'articolo 5, paragrafo 2, mentre l'articolo 24 collega la…

8 settembre 2026
03Protezione dei dati

Albo pretorio: oscurare i dati prima della pubblicazione

Prima di pubblicare un atto nell'albo pretorio online, l'ente deve verificare quale norma imponga o consenta la diffusione, quali dati siano necessari e per quanto tempo debbano restare disponibili.…

8 settembre 2026
04Protezione dei dati

Amministratori di sistema: fascicolo e verifica annuale

La verifica annuale degli amministratori di sistema deve collegare persone, funzioni autorizzate e sistemi effettivamente gestiti. Il risultato utile è un fascicolo che dimostra chi può svolgere…

8 settembre 2026
05Protezione dei dati

Approvare la sicurezza di un sistema: dossier e rischio residuo

L'approvazione della sicurezza di un sistema è una decisione documentata sulle condizioni alle quali il servizio può essere utilizzato. Riunisce perimetro, rischi, misure, verifiche e limitazioni…

8 settembre 2026
06Protezione dei dati

Articolo 12 GDPR: organizzare comunicazioni e richieste di diritti

L'articolo 12 GDPR stabilisce come rendere comprensibili le informazioni e come facilitare l'esercizio dei diritti. Per un'organizzazione, questo significa predisporre canali riconoscibili, personale…

8 settembre 2026
07Protezione dei dati

Audit di sicurezza informatica: scegliere il perimetro e le prove

Un audit di sicurezza informatica deve rispondere a una domanda definita e produrre conclusioni sostenute da prove. Prima di chiedere un preventivo, stabilire se occorre valutare architettura,…

8 settembre 2026
08Protezione dei dati

Basi giuridiche del trattamento: art. 6 GDPR in pratica

Ogni trattamento di dati personali deve poggiare su una delle sei basi giuridiche dell'art. 6, par. 1 GDPR: consenso, contratto, obbligo legale, interesse vitale, compito di interesse pubblico,…

7 luglio 2026