Questo articolo, pur in assenza del previsto regolamento, vuole essere un contributo per definire una metodologia di approccio per cercare di essere in linea con quanto la legge 675/1996 sulla "privacy" prescrive in termini di sicurezza.

Viene soprattutto preso in esame il caso di trattamento automatizzato con l'uso di calcolatori elettronici.

IMPATTI ORGANIZZATIVI

Una delle prime decisioni che dovrebbero essere prese riguarda la identificazione di uno specifico ufficio o persona con il preciso compito di gestire tutti gli obblighi che la legge impone.

Le mansioni dei componenti l'ufficio dovrebbero essere specificate per iscritto.

Per ogni banca dati o trattamento, andrà tenuta copia dei seguenti documenti:

- Notificazione al garante:

• Descrizione del trattamento
• Descrizione del Sistema di sicurezza
• Dati sensibili
• ...............

- Successive variazioni
- Richiesta di trasferimento all'estero
- Risposte del Garante
- Informativa agli interessati
- Documenti di raccolta del consenso
- Istanze degli interessati
- Risposte del titolare
- Documentazione interna:

• Processi di gestione
• Lista incaricati e mansioni relative
• Rapporti Audit
• Test di sicurezza
• ...............

L'art. 15 obbliga a dotarsi, per ogni banca dati, di opportune misure di sicurezza.

Anche in questo caso sarà opportuno individuare una persona cui affidare questa specifica responsabilità.

Dovrà essere compito di questa persona non solo mettere in atto le misure di sicurezza necessarie, ma anche tenere aggiornata la relativa documentazione. Ricordiamoci che, in caso di contestazioni, l'onere della prova spetta al titolare della banca dati.

Un modo pratico di procedere potrebbe essere il seguente:
- Inventario delle banche dati
- Individuare i responsabili e gli incaricati
- Definire i trattamenti
- Definire le misure di sicurezza
- Definire l'applicazione per la gestione della documentazione richiesta dalla legge.

LE INFORMAZIONI PRIVATE

Sono da considerare informazioni "private" quelle relative alle persone fisiche o giuridiche. per una azienda tipo ricadono sicuramente sotto tale definizione le informazioni relative a:
- i dipendenti
- i clienti
- i fornitori
- i probabili clienti (aziende e privati)
- i concorrenti

in pratica quasi l'intero sistema informativo. Sono escluse le applicazioni statistiche e poche altre.

A meno che non si tratti di una piccola azienda, i sistemi informativi sono normalmente complessi e spesso collegati con i sistemi di altre aziende (consociate, business partner, banche, enti statali, ecc..); pertanto è consigliabile adottare una metodologia precisa per fare l'inventario delle banche dati che contengono informazioni soggette alla legge ed i relativi trattamenti.

Il percorso logico da seguire nell'analisi dovrebbe partire dalle applicazioni, in seguito le banche dati, i dati privati, gli archivi fisici, i collegamenti con altre applicazioni/sistemi, gli archivi tecnici (copie di back-up, copie per i test), i log applicativi e di sistema, gli archivi di sicurezza per il piano di disaster recovery ed, in fine, gli archivi storici.

Le Applicazioni

L'inventario di tutte le applicazioni esistenti in azienda è fondamentale per verificare se trattano dati privati, rilevarne il trattamento e le finalità; queste informazioni sono preziose per le notifiche al Garante.

In questo contesto è importante innanzitutto definire che cosa si intende per applicazione; per esempio sotto il titolo di applicazione del personale potrebbero ricadere tutti i programmi applicativi per la gestione delle retribuzioni, le carriere, gli skill, ecc. ed il proprietario responsabile (sia della applicazione che dei dati relativi) potrebbe essere il Direttore del personale o persona da lui delegata.

Nelle organizzazioni dove il concetto di proprietà delle applicazioni non è applicato converrà, per fare l'inventario, rivolgersi a tutti i manager aziendali oltre che ai responsabili del centro elaborazione dati. Infatti ci potrebbero essere applicazioni acquistate all'esterno o date in gestione ad altri centri o comunque applicazioni poco note al personale del centro elaborazione dati stesso ( es. quelle dipartimentali ).

Le Banche Dati

Una volta completato l'inventario delle applicazioni si può verificare il contenuto delle relative banche dati e definire se vi siano dati che ricadono sotto la legge.

E' in questa fase che si dovrebbe anche individuare se esistono e quali sono i cosiddetti dati sensibili.

Infatti per questa particolare tipologia di dati viene richiesta una attenzione specifica ed un trattamento differenziato.

Il mio suggerimento è quello di prendere in esame solo le banche dati primarie e di trattare gli altri archivi come archivi derivati, ma facenti parte di un unico trattamento.

Altri Archivi

Non scordiamoci di considerare anche eventuali nastri depositati fuori dell'azienda nei cosiddetti archivi di sicurezza o storici o dati in elaborazione a società di servizi.

Collegamenti

Sicuramente un punto critico per molte organizzazioni; dipende dalla complessità del sistema informativo e dal suo grado di distribuzione. In un centro ben organizzato tutti i collegamenti tra applicazioni dovrebbero essere descritti nei documenti tecnici. Ciò è meno vero per gli ambienti distribuiti, soprattutto se il protocollo di rete non è di tipo gerarchico, ma paritetico.

Le LAN sono reti che appartengono a questa categoria. I responsabili delle varie applicazioni dovrebbero essere la fonte delle informazioni necessarie per questo inventario.

Dobbiamo ora estendere la nostra ricerca ad altre categorie di archivi che sicuramente contengono dati privati, anche se non sono direttamente riconducibili alle singole applicazioni. Mi riferisco a tutti quegli archivi che vengono creati dai sistemi operativi o fanno parte dei processi di gestione dei centri di calcolo. Ricadono sotto questa categoria per esempio i log, che contengono le informazioni delle attività fatte durante la giornata da chiunque operi sui calcolatori.

Normalmente questi log contengono il codice della persona che ha operato e le indicazioni di che cosa ha fatto, ora e minuto. Di per sé potrebbero costituire una banca dati autonoma e pertanto da notificare separatamente.

Le fonti di informazione per questa tipologia di archivi sono sicuramente i responsabili del centro e la loro struttura tecnica più che i responsabili delle applicazioni.

LA SICUREZZA INFORMATICA

Oggi i rischi per l'integrità dei dati si sono moltiplicati. Si parla sempre più spesso di intercettazioni, di pirati informatici, di virus ecc.. Volendo classificare i rischi abbiamo:


Rischi secondo l'origine:

• Interni - connessi alla attività dei dipendenti della azienda. Secondo le statistiche sono i più probabili.
• Esterni - connessi alla attività di qualunque altra persona.
• Ambientali - relativi a eventi di grande portata, quali: incendi, terremoti, allagamenti, ecc..
  

Rischi secondo le cause:

• Carenze organizzative - responsabilità non correttamente assegnate, sottovalutazione dei rischi, ecc..
• Colpa - se causati da ignoranza, incuria o leggerezza. Statisticamente è la causa più diffusa.
• Dolo - In rapida crescita. Infatti con l'avvento di Internet è cresciuto enormemente il numero delle persone che possiedono le apparecchiature e le necessarie conoscenze tecniche per arrecare danno.
  

Rischi secondo le modalità:

• Intercettazioni - principalmente lungo la rete di trasmissione.
• Ingegneria sociale - per divertimento, si prende gioco della vittima. Sono le modalità più diffuse e pericolose
• Backdoor - Quando i programmatori lasciano dei punti di ingresso non noti nel software.
• Cavalli di Troia - lo dice lo stesso nome - software predisposto per operare in modo non noto all'utente.
• Denial of service - comandi che pregiudicano la efficienza delle reti e dei server.
• Virus - software che ha la capacità di autopropagarsi
• Personificazione - quando ci si presenta sotto mentite spoglie.
  

Ovviamente la lista potrebbe essere più lunga e completa. Vorrei solo aggiungere che con l'avvento della informatica distribuita e di Internet, il possibile Hackers può essere chiunque e in qualunque parte del mondo ed è praticamente impossibile individuarlo.

Le Contromisure

Di fronte ad una casistica di minacce cosi variegata ed eterogenea e per molti versi imprevedibile, le difese parziali ed improvvisate sono destinate ad essere poco efficaci.

Infatti anche per la sicurezza informatica, come per molti sistemi di sicurezza, si può dire che è l'anello più debole che determina il grado di resistenza della catena.

Ciclo della Sicurezza

Analisi dei rischi: In questa fase si dovrebbe procedere all'inventario dei dati da proteggere e alla valutazione dei rischi a cui sono soggetti. particolare attenzione va posta ai rischi dovuti alle carenze organizzative ed alla scarsa cultura sugli aspetti della sicurezza informatica.

Definizione della politica aziendale sulla sicurezza: E' la fase più importante. E' fondamentale che il management aziendale prenda atto dei rischi e definisca una adeguata risposta in termine di politica aziendale (regole, organizzazione, responsabilità, ecc.) e relativi budget di spesa. Il bilanciamento costi benefici e l'accettazione dei rischi residui sono parte non rinunciabile di questa fase. Il risultato concreto è la pubblicazione dello standard aziendale di sicurezza.

Realizzazione: Occorre tradurre quanto definito nella fase precedente in atti concreti. Questa fase, in organizzazioni complesse, può richiedere alcuni anni e molto impegno. Se i sistemi informativi nella fase di progetto non sono stati disegnati tenendo nel dovuto conto i requisiti della sicurezza, questa fase può avere costi molti elevati e talvolta non bilanciati con i benefici che si vogliono ottenere.

Amministrazione: Sicurezza vuol dire regole, vincoli, controlli, liste di accesso, permessi ecc..; ciò comporta una certa dose di inevitabile burocrazia e di lavoro amministrativo. Senza l'attività di amministrazione, dopo qualche tempo, il sistema di sicurezza si degrada e fallisce i suoi obiettivi.

Auditing e controlli: Costruire un sistema di sicurezza senza, in qualche modo, verificarne l'efficacia, serve a poco. I sistemi informatici sono normalmente molto complessi (sistemi operativi, applicazioni, banche dati, reti, ecc.) e solo con test accurati si può avere una ragionevole certezza di aver costruito un sistema privo di scoperture o manchevolezze. Ovviamente non possiamo limitarci ai test iniziali, ma questi vanno ripetuti con frequenze opportune (1 o 2 volte l'anno).

Con ciò il ciclo è concluso. Ovviamente, poiché difficilmente i sistemi informativi e l'ambiente in cui operano sono statici, il ciclo della sicurezza non termina mai. E' altamente raccomandabile che almeno una volta l'anno si riparta con una revisione dei rischi e, se necessario, anche con le altre fasi.

ARCHITETTURA DI SICUREZZA

E' l'insieme di regole, funzioni, strumenti, oggetti e controlli, coerentemente disegnati e resi funzionanti, che garantiscono in ogni struttura organizzativa, ambiente informatico, sistema informativo, singolo elaboratore, ecc. il rispetto degli standard di sicurezza definiti dall'azienda.

Normalmente abbiamo architetture di sicurezza differenziate per:
- Ambiente tradizionale (Centro di calcolo con mainframe e rete privata)
- Ambiente distribuito/Server (LAN con server dipartimentali)
- Ambiente Internet/Intranet (Web)
- Ambiente distribuito/Client (Workstation, browser).

Gli elementi essenziali di una architettura sono:
- Funzioni di sicurezza: Identificazione e autenticazione degli utenti, controllo accessi ai dati ed alle applicazioni, crittografia, non rigetto, firma elettronica, ecc. sono esempi di funzioni che vanno valutate e decise.
- Meccanismi di sicurezza: Sono i prodotti Hardware e Software che realizzano le funzioni di sicurezza previste nell'architettura.
Credo che sia chiaro da questa esposizione che la scelta dei prodotti di sicurezza sia un momento decisionale importante, ma non prioritario, nella costruzione della architettura di sicurezza. I prodotti dovrebbero essere funzionali alle scelte aziendali e non viceversa.
- Oggetti di sicurezza: E' importante che vengano con molta precisione individuati quegli oggetti informatici che sono funzionali ai meccanismi di sicurezza. Fanno parte di questa categoria le password, le chiavi di crittografia, le liste di accesso, ecc.. Una protezione non appropriata di questi oggetti potrebbe vanificare l'efficacia dell'intero sistema.
- Processi di gestione: E' l'insieme dei processi e delle regole per la gestione delle funzioni, dei meccanismi e degli oggetti di sicurezza che fanno parte della architettura. Vi dovrebbero far parte anche processi di allarme e controllo.

Un'architettura di sicurezza così strutturata e gestita dovrebbe senz'altro rispondere a quanto previsto dall'articolo 15 e soprattutto essere preventiva e tecnologicamente sempre aggiornata.

ARTICOLO 15

In modo esplicito l'art. 15 richiede che i dati personali oggetto di trattamento siano custoditi ... controllati ... in modo da ridurre al minimo i rischi di distruzione, perdita anche accidentale, ... di accesso non autorizzato, ... di trattamento non consentito, ... di trattamento non conforme alla finalità della raccolta.

Di seguito verranno prese in esame le funzioni di sicurezza che rispondono ai singoli requisiti.

Non tratterò invece la scelta dei meccanismi di sicurezza; in altre parole dei prodotti che realizzano le funzioni prescelte.

Custodia

Presuppone che siano definiti dei processi (norme e responsabilità) nell'area sia della sicurezza fisica che logica.

Sicurezza fisica

Locali dei centri di calcolo isolati e dotati di accessi controllati. E' importante che solo gli addetti ai lavori (incaricati del trattamento) vi possano accedere e che altre persone (visitatori, addetti ai lavori ausiliari, ecc.) vi accedano solo con apposita autorizzazione.

E' buona norma dotare gli ingressi di apparecchiature per la identificazione delle persone (es. lettori di badge) e tutte le aperture di allarmi per cautelarsi da intrusioni durante il periodo in cui il centro resta non presidiato.

Per i server dipartimentali o comunque distribuiti le soluzioni possono essere molte, più o meno efficaci: uso di armadietti chiusi a chiave, locali appositamente predisposti, lucchetti, ecc.. Ricordiamoci che nei personal Computer è molto facile asportare i dischi fissi.

Poiché sono sempre possibili delle intercettazioni anche le apparecchiature di rete dovrebbero essere custodite opportunamente.

Un discorso a parte meritano le nastroteche. Nastri etichettati e gestiti con la tecnica del carico e scarico e inventari periodici di controllo (almeno una volta all'anno).

Poiché la legge parla di rischi di perdita anche accidentale, se i nastri sono unici, sarà bene dotarsi di opportuni impianti antincendio che non provochino ulteriori danni ai nastri in caso di utilizzo di dette apparecchiature.

Quanto detto per i nastri vale anche per i dischi rimovibili.

Sicurezza logica

I metodi per proteggere le informazioni dal punto di vista logico sono molti e svariati e fortemente dipendenti dalla tipologia dei sistemi operativi utilizzati (piattaforme Software). Comunque alcune caratteristiche sono comuni a tutte le piattaforme.

Ne illustro alcune che sono applicabili sia ai sistemi host che ai server distribuiti ed in qualche misura anche alle singole workstation:
- Integrità del sistema operativo: è il primo elemento chiave. Non tutti i sistemi operativi da questo punto di vista sono uguali; inoltre vanno installati e mantenuti a regola d'arte. La classificazione del TCSEC Americano aiuta a fare un primo confronto. per avere comunque maggiori certezze è necessario far fare da personale specializzato gli opportuni test (penetration test) per individuare le scoperture ed avere le indicazioni per rimediarvi.
Deve essere sempre tenuto presente che una scopertura sul sistema operativo indebolisce tutte le altre protezioni di sicurezza.
- Sistema chiuso o aperto: per stare più tranquilli ed avere minori rischi è sicuramente consigliabile disegnare il sistema di sicurezza secondo la regola che è tutto proibito meno le cose autorizzate ( sistema chiuso), piuttosto che secondo lo schema opposto: è tutto permesso meno le cose proibite (sistema aperto). La prima soluzione è più costosa e richiede una accurata amministrazione.
- Accessi discrezionali od obbligatori: si parla di accesso discrezionale quando si demanda ad una persona (normalmente proprietario della applicazione) l'autorità di decidere a chi dare l'accesso ai dati e a chi no. Si ha l'accesso obbligatorio quando l'accesso ai dati è strutturale e controllato dal sistema di sicurezza.
Penso che per i dati sensibili sia preferibile adottare la soluzione degli accessi obbligatori.
- Classificazione delle informazioni: Sul piano pratico converrebbe adottare un sistema di classificazione che veda, per esempio, i dati "sensibili" classificati ad un livello più alto dei dati "personali". L'adozione di un opportuno sistema di classificazione, oltre ad accrescere la protezione dei dati, dovrebbe permettere di adottare un sistema di protezione selettivo.

Un esempio potrebbe essere:
- Informazioni "sensibili": altamente riservate
- Informazioni "private": riservate
- Altre informazioni aziendali riservate: riservate
- Altre informazioni aziendali: non classificate
Un sistema di classificazione, perché sia efficace, deve comprendere anche le informazioni cartacee.
- Metodi di accesso: Il più usato è quello basato su parole chiave o password. per accrescerne l'efficacia occorre che ci siano regole precise di gestione delle password. Occorre definirne la lunghezza minima, la durata, e le regole grammaticali per evitare le password facilmente indovinabili. Ogni password dovrebbe essere abbinata ad un individuo; è l'unico modo per poter risalire alle responsabilità di eventuali azioni contrarie a quanto previsto dalla legge.
- Antivirus: Nell'architettura di sicurezza dei personal Computer dovrebbe essere sempre previsto non solo un Antivirus, ma anche e soprattutto un rigoroso processo di controllo dei dischetti che entrano in azienda e, se collegati ad Internet, del software che viene scaricato dalla rete.

La lista di metodologie di protezione potrebbe continuare, ma ritengo che quelle richiamate siano sufficienti per disegnare una architettura di sicurezza minima. Ovviamente se le banche dati dovessero essere inserite in un sistema particolarmente esposto, come per esempio un Web di Internet, occorrerà provvedere ad un disegno specifico e prevedere la installazione di Firewall e di protocolli di mutuo riconoscimento basati su chiavi crittografiche.

I controlli

La legge li richiede in modo esplicito; inoltre, dimostrare di averli in funzione, sarà sicuramente utile per il Responsabile, se dovesse essere necessario.

Controlli periodici

possiamo dividere i controlli in:
- Auditing: personale specializzato, spesso esterno all'azienda, verifica l'aderenza dei comportamenti e delle soluzioni tecniche agli standard di sicurezza (in questo caso anche alle disposizioni di legge). L'Auditing richiede, come prerequisito, che l'azienda si sia data per iscritto le regole e abbia definito ruoli e responsabilità.
- Revisioni interne: differiscono dalle metodologie precedenti solo per il fatto che sono eseguite dallo stesso personale interno dell'azienda e richiedono preparazione ed impegno meno gravoso. Spesso precedono le revisioni ufficiali vere e proprie.
- Test: tecnici dotati di opportuni tools e metodologie provano a violare i sistemi informativi, ad accedere ai dati ed alle applicazioni pur non avendo alcuna autorizzazione iniziale

Controlli continui

- Analisi dei log: per prima cosa occorre che il meccanismo che registra i log (liste di attività) sia attivato sia sui sistemi operativi che sui software di sicurezza e che i log siano protetti e mantenuti per un periodo sufficiente. L'attività di analisi per la ricerca di eventi anomali e la successiva determinazione delle cause andrebbe fatta giornalmente. Accumulare log per periodi più lunghi, data la mole di dati da verificare, renderebbe vana ogni attività di verifica. L'uso di tools automatici di supporto snellisce molto questa attività e la rende meno gravosa.
Mi rendo conto che in molte aziende questa attività potrebbe essere in contrasto con accordi sindacali che limitano le possibilità di controllo.
Inoltre i log sono di per sé banche dati con informazioni private e pertanto da gestire opportunamente.
- Routine di controllo: sotto questa terminologia si intendono tutti quei software che effettuano operazioni di verifica continua sui sistemi per garantire che gli standard di sicurezza siano rispettati e che ne segnalano le deviazioni. Ritengo che si possano personalizzare queste routine facendo in modo che verifichino, laddove è possibile, che il trattamento delle banche dati personali resti conforme a quanto notificato al Garante.

Rischi di distruzione o perdita anche accidentale

Un dato memorizzato in un archivio elettronico può essere distrutto o perso per svariate cause:
- comandi applicativi errati: ciò è dovuto essenzialmente ad applicazioni non ben testate. Si riduce il rischio sia seguendo rigorose procedure di test che separando il mondo cosiddetto di sviluppo e test da quello di produzione.
- comandi operativi errati: Un operatore può sempre sbagliare e provocare distruzioni irreparabili. Volendo ridurre tale rischio è necessario ridurre al minimo le necessità di comandi manuali, demandando tali comandi ad applicazioni specializzate (schedulatori, sistemi di automazione).
- software pericoloso: metto in questa categoria, oltre ai virus, tutta quella serie di routine, per altro molto diffuse nei centri elaborazioni, che possono accedere ai dati superando le barriere dei sistemi di sicurezza e al di fuori del controllo dei programmi applicativi. L'uso di tali programmi dovrebbe essere vietato (salvo uno ristretto utilizzo in casi particolari) ed inoltre con opportuni controlli andrebbero ricercati e cancellati dalle librerie.
- malfunzionamenti dell'Hardware: anche l'hardware più costoso e tecnologicamente più evoluto è soggetto a malfunzionamenti. La difesa più efficace consiste nel duplicare gli archivi con frequenze prestabilite.
- eventi disastrosi: Mi riferisco ad incendi, allagamenti, esplosioni o atti dolosi, ecc. che distruggano i supporti magnetici su cui i dati sono registrati.

Ritengo che con questo articolo la legge imponga l'adozione di misure di back-up obbligatorie per tutte le banche dati private.

In altre parole le applicazioni che gestiscono i dati privati andrebbero inserite tra quelle vitali per l'azienda e trattate secondo le procedure di disaster/recovery.

Rischi di accesso non autorizzato

Se vogliamo tenere sotto controllo il rischio di accesso non autorizzato dobbiamo disporre di una funzione di controllo accessi che copra l'intero sistema informativo e non solo le specifiche applicazioni. Infatti dobbiamo cautelarci da ogni manomissione di dati, sia da parte del personale degli uffici che per compito deve trattare i dati privati, sia del personale tecnico del centro elaborazioni che svolge operazioni di trattamento sugli archivi interi.
Particolare cura deve essere posta agli accessi da parte di applicazioni o da comandi di sistema operativo.
In altre parole i dati privati devono avere una protezione totale e le logiche con cui vengono date le autorizzazioni devono essere sotto il controllo diretto del Responsabile del trattamento.

Rischio di trattamento non consentito o non conforme

Per poter ridurre questa tipologia di rischio bisogna fare in modo che il trattamento definito per ogni banca dati e notificato al Garante rimanga tale e non possa essere modificato da nessuno senza la espressa volontà del Titolare. per ottenere ciò, più che sulle soluzioni tecniche, bisogna agire sulla organizzazione e l'assegnazione delle responsabilità.

ARTICOLI 20 e 21

Gli articoli citati, come del resto molti altri, pongono precisi limiti e divieti, a seconda dei casi, alla diffusione e comunicazione dei dati privati e/o sensibili. Ricordiamoci che è considerata comunicazione la semplice possibilità di consultazione dei dati. E' anche previsto che il Garante possa vietare la diffusione di alcuni dati e che è vietata la comunicazione e la diffusione dei dati di cui è stata ordinata la cancellazione.

Tutto questo vuol dire che l'accesso in lettura dei dati deve essere strettamente controllato e che i software di trasmissione devono essere gestiti molto accuratamente.

Una particolare comunicazione/trasmissione è il trasferimento dei dati all'estero. Sulle reti si dovranno installare dei filtri, gateway o firewall per evitare trasmissioni verso località non desiderate.

INTERNET

Un accenno particolare merita Internet e le banche dati su Web.

Come tutti sanno, Internet viene considerato poco sicuro, sia per i rischi di intercettazione, sia per il fatto che gli elaboratori si trovano esposti a possibili attacchi da parte di persone sconosciute, che possono agire del tutto indisturbate.

Costruire oggi, nel rispetto di quanto previsto da questa legge, una banca dati con informazioni private su Web è probabilmente molto costoso. Infatti si tratta di disegnare e realizzare un sito chiuso e controllato, quando tutta l'architettura dei Web è basata su software nati per diffondere le informazioni.

Da tener presente che sono già disponibili sul mercato software, che usando tecniche crittografiche, garantiscono la riservatezza delle trasmissioni e delle comunicazioni e permettono anche accessi selettivi ai Web. per lo più sono oggi destinati alle applicazioni finanziarie ed al commercio elettronico.

TOOLS di SUPPORTO

Vorrei qui far presente che per molte aziende rispettare tutte le obbligazioni ed incombenze burocratiche che la legge impone potrà essere non solo costoso, ma sul piano organizzativo gravoso. Basta pensare ai 5 giorni di tempo per rispondere alle richieste dei Titolari delle informazioni private.

In aggiunta a beneficio del Titolare e del Responsabile occorrerà tenere traccia di molte delle operazioni fatte (cancellazioni, variazioni, risposte agli aventi diritto, ecc.).

Probabilmente non sarà conveniente agire in modo manuale. Occorrerà pensare ad una applicazione opportuna che metta in relazione le banche dati private, i loro contenuti, le modalità di trattamento, i dati di notifica e tutte le altre informazioni che via via si dovessero creare.

Tale applicazione dovrà permettere inoltre una facile e veloce consultazione per poter fornire le risposte opportune sia al Garante che agli aventi diritto.

CONCLUSIONI

A conclusione di quanto trattato, dobbiamo porci la domanda se i Titolari ed i Responsabili dei trattamenti di banche dati personali possono dormire sonni tranquilli.

La risposta è senz'altro sì, a condizione che abbiano chiaro che:
- senza sicurezza non c'è privacy dei dati personali
- senza un'adeguata architettura (vanno evitate le soluzioni improvvisate) governata da, magari semplici ma efficaci processi
- i test ed i controlli sono fondamentali per l'efficacia delle soluzioni adottate
- in ogni caso la sicurezza costa.