La sicurezza del sito web: le regole per realizzare un sito conforme

La sicurezza di un sito web è fondamentale per proteggere i dati e le informazioni degli utenti e dei gestori.

Sappiamo (dalla ISO 27001 e dal GDPR in primis) che la sicurezza va declinata nelle sue proprietà: Riservatezza, Integrità e Disponibilità. Dunque, non solo è importante garantire la riservatezza dei dati, ma anche la loro integrità (esattezza, correttezza) e la loro disponibilità in tempi idonei laddove attraverso il sito web si fornisce un servizio a clienti effettivi e potenziali. Inoltre, l’indisponibilità del sito web a causa di un attacco hacker (attacco DDOS, defacement del sito web) comporta un grave rischio reputazionale per il suo proprietario.

Leggi tutto

La Certificazione privacy: lo schema ISDP©10003

La certificazione ai sensi dell’art. 42 del Regolamento Generale sulla Protezione dei Dati (General Data Protection Regulation, GDPR) è un processo che dimostra l’impegno di un’azienda a proteggere i dati personali gestiti (ad es. dei propri clienti e dipendenti), relativamente ad un processo, prodotto o servizio.

La certificazione GDPR non è obbligatoria, ma può essere un’ottima opportunità per le aziende che desiderano dimostrare il loro impegno verso la conformità alle normative sulla protezione dei dati personali e, quindi, aumentare la loro reputazione sul mercato, magari accedendo, in un prossimo futuro, a gare di appalto particolarmente significative.

Il processo di certificazione GDPR prevede una valutazione dettagliata dei sistemi e dei processi di protezione dei dati dell’organizzazione da parte di un organismo di certificazione accreditato. Questo Organismo esaminerà le procedure interne dell’azienda, le tecnologie utilizzate per proteggere i dati e la formazione del personale in materia di sicurezza dei dati. Se l’azienda supera la valutazione, verrà rilasciata una certificazione che dimostra che il prodotto, processo o servizio dell’organizzazione oggetto di certificazione è conforme ai requisiti del GDPR.

Leggi tutto

Luci ed ombre del contratto di trattamento dati con il Responsabile del trattamento

man and a woman on a business meeting
Photo by Artem Podrez on Pexels.com

Gli accordi fra Titolare del trattamento e Responsabile del Trattamento sono probabilmente uno dei punti più difficili da gestire nell’applicazione del GDPR, sia perché i requisiti del GDPR sono diversi dalla vecchia nomina del responsabile esterno del trattamento del Codice Privacy, sia perché le responsabilità, in capo sia al Titolare, sia al Responsabile sono più pesanti che in passato.

Spesso tale accordo è imposto dal Titolare al Responsabile che non gradisce e troppo spesso il Titolare evita contrasti con il Responsabile, magari fornitore già scelto da tempo, e desiste. In altri casi – come quelli dei colossi del web, fornitori di servizi cloud – il Titolare non ha nemmeno modo di discutere le clausole contrattuali dell’accordo per la protezione dati imposto dal Responsabile.

Leggi tutto

Responsabile della Conservazione Digitale

Molte imprese si sono trovate a dover nominare il Responsabile della Conservazione (RdC) per ottemperare ai requisiti delle nuove Linee Guida AgiD sulla conservazione dei documenti digitali. Tale adempimento non riveste, infatti, solo le Pubbliche Amministrazioni, ma tutte le imprese che utilizzano sistemi di conservazione “a norma” (archiviazione sostitutiva), compresi i sistemi di fatturazione elettronica, ormai divenuti obbligatori per tutte le organizzazioni.

Leggi tutto

Valutazione del rischio per la sicurezza delle informazioni vs. valutazione del rischio privacy

In un precedente articolo abbiamo trattato della valutazione del rischio privacy per adempiere ai requisiti del GDPR (Regolamento UE 2016/679 sulla protezione dei dati personali), ma chi ha o deve implementare un sistema di gestione per la sicurezza delle informazioni come deve considerare la valutazione dei rischi sui trattamenti di dati personali? Tale valutazione è implicita nella valutazione dei rischi sulla sicurezza delle informazioni, ovvero è un “di cui” di essa? Oppure, come sostengono alcuni esperti di privacy, è tutta un’altra cosa e va considerata separatamente? Cerchiamo di chiarire questi aspetti.

Leggi tutto

La Check-list di valutazione del fornitore

Fin dagli albori dei sistemi qualità ISO 9001 (ma ai tempi era anche ISO 9002) la qualifica del fornitore è stato un elemento particolarmente significativo, da soddisfare anche attraverso la sottomissione ai fornitori di un questionario di (auto)valutazione e qualifica del fornitore che andava a valutare la sua organizzazione, le sue metodologie di assicurazione qualità e l’eventuale situazione rispetto alla certificazione di qualità (ISO 9001/ISO 9002/ISO 9003, certificazioni di prodotto, ecc.). Tali questionari avevano una loro ratio: se ben strutturati consentivano di valutare numerosi aspetti dei processi operativi del fornitore e spesso lo invitavano a migliorare i suoi controlli qualità. Chiaramente una visita in loco poteva sempre permettere al cliente di verificare la veridicità delle risposte fornite.

Nel corso degli anni i metodi di valutazione dei fornitori si sono evoluti, ma i questionari sono in parte rimasti, almeno per i fornitori di prodotti e servizi critici, magari affiancati da visite presso la loro sede o veri e propri audit di 2a parte.

Negli ultimi tempi questa modalità di valutazione è estesa ad altri settori: la privacy, la sicurezza informatica e la Sostenibilità, tipicamente declinata nei suoi elementi costituenti: Ambiente (Environment), Responsabilità Sociale (Social Accountability) e Governance, nota con l’acronimo ESG.

Purtroppo, grandi aziende hanno distribuito a pioggia questi questionari per valutare tutti i loro fornitori, senza distinzione.

Così molte aziende si sono viste recapitare (via e-mail) un questionario al quale devono tassativamente rispondere, ma non sanno come, soprattutto per quanto riguarda alcune domande.

Spesso, poi, le risposte ai questionari vengono valutate con algoritmi matematici, applicando metodi quali-quantitativi. In altre parole, ad ogni domanda bisogna rispondere con un SI o NO oppure con un Conforme/Parzialmente Conforme/Non Conforme, e così via. Ad ogni risposta è poi assegnato un punteggio (ed eventualmente un peso) che contribuisce al calcolo di un punteggio complessivo (spesso tramite una media pesata).

Dunque, troppe risposte negative o parzialmente negative possono portare ad escludere una PMI dall’Albo Fornitori di un cliente importante per aspetti non strettamente legati al prodotto/servizio fornito.

Ma andiamo ad esaminare le due principali tipologie di questionari:

  • quello dedicato alla Sostenibilità (ESG) e
  • quello dedicato alla Privacy (Data Protection secondo il GDPR, Reg UE 2016/679) ed alla Sicurezza Informatica (Cybersecurity).

I questionari sulla Sostenibilità riportano domande anche molto specifiche come, ad esempio, richieste sul calcolo della carbon footprint, delle emissioni di CO2 e/o monitoraggio dei consumi energetici.

person holding green grains
Photo by Min An on Pexels.com

Ovviamente a tali domande molte PMI, soprattutto quelle nel settore dei servizi, non sanno cosa rispondere, né pensano di implementare un sistema di misura e monitoraggio di tali elementi.

In molti contesti il questionario non dovrebbe essere applicabile: se il fornitore ha un basso impatto ambientale, non dovrebbe essere valutato su questi aspetti, in quanto non posso trattare allo stesso modo un fornitore di prodotti derivanti da un processo manifatturiero, un semplice rivenditore di prodotti e un fornitore di servizi di sviluppo software ed assistenza software e sistemistica. Se il fornitore appartiene a queste ultime tipologie, dovrebbe poter rispondere: “Caro cliente, siamo un’azienda di servizi che lavora in uffici neanche tanto vasti, il nostro impatto ambientale è limitato e più che cercare di fare la raccolta differenziata e di limitare i consumi energetici (già ridotti) non possiamo”. Del resto i valori di alcuni parametri sopra menzionati non avrebbero senso e non sarebbero comunque comparabili con aziende industriali.

Sugli aspetti Social dei questionari ESG, non ha molto senso richiedere il possesso di una certificazione nell’ambito della Responsabilità Sociale (SA 8000 o altri; ci sono diversi standard, forse troppi, nessuno standard ISO certificabile), soprattutto quando il fornitore non è a rischio di non rispettare i diritti dei lavoratori, soprattutto riguardo al lavoro forzato o al lavoro minorile.

Questi ultimi aspetti, viceversa, spesso risultano difficilmente applicabili a fornitori che producono in Paesi nei quali la normativa sul lavoro non è severa come nel nostro, anzi, lo sfruttamento dei lavoratori e il disconoscimento dei loro diritti è all’ordine del giorno.

In queste situazioni il tipico caso è quello dell’azienda A (grande azienda, anche multinazionale) vuole imporre criteri rigorosi di responsabilità sociale all’azienda B (il nostro fornitore che è un semplice rivenditore) che acquista i prodotti dall’azienda C, che è una grande azienda che opera in mercati del lavoro poco regolamentati (Asia, Africa…). L’azienda B può essere assolutamente compliance a tutte le norme applicabili in Italia e forse più, ma che controllo può imporre su fornitori di altri Paesi che controllano il mercato globale?

Lato Governance spesso viene richiesta l’attuazione di un Modello Organizzativo 231 (per le aziende italiane) che per certi settori non ha senso poiché la probabilità di incappare in uno dei reati previsti dal D.lgs 231/2001 è quasi inesistente. Idem dicasi per la nuova normativa anticorruzione (ISO 37001).

Al di là del consiglio di rispondere con serietà, competenza e massima trasparenza, sarebbe utile instaurare un canale di comunicazione con il cliente per evitare di essere fortemente penalizzati da un algoritmo di valutazione del questionario che non considera adeguatamente nel calcolo il settore di appartenenza del fornitore.

Passiamo al questionario sulla Privacy e/o sulla Cybersecurity.

Il questionario Privacy viene giustamente adottato per qualificare il responsabile (esterno) del Trattamento di Dati personali ai sensi dell’art. 28 del GDPR, ma non solo. Alcune organizzazioni che hanno molto a cuore la tutela dei dati personali che gestiscono, anche perché molto critici (dati sanitari, dati bancari, ecc.), lo mandano a chiunque ha un appalto di servizi. Starà poi al fornitore spiegare che magari il proprio software in cloud non tratta dati personali di cui il cliente è titolare, a parte i dati delle credenziali di accesso degli utenti e, pertanto, non potrà mai essere investito del titolo di Responsabile del Trattamento.

Se, viceversa, il fornitore tratta dati personali occorre fare attenzione ad alcune domande. Ad esempio, spesso il cliente richiede se il fornitore ha svolto una DPIA (valutazione di impatto sui dati personali), che in realtà è applicabile solo in alcuni casi. Ricordiamo infatti che la DPIA è dovuta, oltre ai casi esplicitamente previsti dal Regolamento UE 679/2016 e dalle indicazioni del nostro Garante Privacy, se un trattamento di dati personali – a seguito della valutazione dei rischi – presenta rischi elevati per i diritti e le libertà degli interessati.

 Anche le domande sul DPO (RPD) dovrebbero prevedere la non applicabilità del requisito per determinati tipi di organizzazione, anche se la nomina di un DPO è comunque un’azione volontaria consigliabile in molte realtà.

Per quanto riguarda la nomina dei responsabili del trattamento (sub-responsabili per il trattamento che un fornitore effettua per un cliente titolare del trattamento) con adeguato accordo contrattuale, essa è un atto doveroso, ma è difficile ribaltare al sub-responsabile i medesimi requisiti contrattuali imposti dal titolare (cliente) al responsabile (fornitore). Immaginiamo ad esempio una società di servizi di elaborazione dati relativi alla gestione del personale che ha numerosi clienti che la hanno nominata responsabile del trattamento, ma che ovviamente utilizza il medesimo programma software per elaborare i dati di tutti i clienti ed ha un contratto con i fornitori del software (tipicamente in Saas, ovvero in cloud) unico con la nomina del fornitore del software  a responsabile del trattamento. In tale situazione è difficile che tutti i requisiti, anche quelli particolari, coincidano con quelli richiesti dal cliente titolare del trattamento.

Poi ci sono le misure di sicurezza.

Spesso le check-list comprendono riferimenti a controlli estratti da linee guida ENISA, ISO 27002 e quant’altro di meglio c’è a disposizione. Peccato che talvolta queste misure di sicurezza non sono correttamente declinate.

Ad esempio, il controllo degli accessi logici e le regole di autenticazione non possono essere imposti tu cur dal cliente al fornitore: alcune regole come il cambio password ogni 3 o 6 mesi non ha senso richiederle come obbligo. Ci sono illustri pareri (NIST in primis) che sono contrari al cambio password frequente, a vantaggio di altre misure di sicurezza alternative (es. MFA con elevata complessità della password).

Dunque, sarebbe più corretto chiedere al fornitore quali policy di controllo degli accessi logici ha implementato e non accontentarsi di risposte del tipo: “per accedere ai sistemi informatici abbiamo imposto una password” … che vuol dir tutto e vuol dir niente.

Poi chiaramente il questionario dovrebbe concentrarsi sulle misure di sicurezza relative al trattamento che il fornitore fa per il cliente. Se il responsabile del trattamento fornisce un software i cloud (SaaS) non ha particolare rilevanza come effettua i backup dei propri dati gestionali internamente, ma è importante capire quali misure di sicurezza ha adottato il datacenter che ospita il servizio.

Stesso discorso vale per backup, anti-malware, firewall ed altre misure di sicurezza che dovrebbero essere commisurate all’attività effettivamente svolta dal fornitore per il cliente. Non basta affermare di disporre di queste misure di sicurezza, bisogna capire come sono applicate. Quando l’accesso del fornitore ai dati del cliente avviene sui database installati presso il cliente normalmente le misure di sicurezza importanti sono quelle implementate dal cliente stesso (regole di autenticazione, VPN per accessi dall’esterno, ecc.). In conclusione, occorre essere preparati per rispondere adeguatamente a queste richieste dei clienti e, se si ritiene di essere adeguatamente strutturati ed organizzati su questi aspetti, è opportuno cercare un dialogo con persone competenti appartenenti all’organizzazione del cliente. Nella

Esiste l’informativa privacy perfetta?

Uno degli aspetti fondamentali del Regolamento Europeo per la Protezione dei Dati (Reg. UE 679/2016, noto anche come GDPR) è costituito da Diritti dell’interessato, i cui requisiti sono descritti al Capo III del Regolamento stesso. Ed uno dei principali documenti (forse il principale) che ogni organizzazione ha predisposto per dimostrare il corretto adempimento a questo elemento è costituito dall’Informativa.

In realtà il Regolamento, agli articoli 12, 13 e 14 non cita il termine “Informativa”, ma “informazioni da fornire all’interessato”, ma ciò non cambia la sostanza, per cui quasi tutte le organizzazioni del nostro Paese, forse anche per continuità con la normativa precedente (D. Lgs 196/2003), hanno predisposto una o più informative per il trattamento di dati personali.

Leggi tutto

Le nuove Linee Guida del GPDP sui cookie

Il Garante per la Protezione ei Dati Personali (GPDP) ha recentemente emanato un provvedimento (pubblicato in G.U. lo scorso 09/07) denominato “Linee guida cookie e altri strumenti di tracciamento”, facendo seguito alla consultazione pubblica iniziata lo scorso dicembre.

Il presente articolo segue analogo articolo che commentava la versione posta in consultazione delle medesime Linee Guida e che ora sono state ufficialmente approvate, seppur con qualche modifica.

 Tali Linee Guida di fatto aggiornano un provvedimento analogo (n. 229, dell’8 maggio 2014) adottato prima dell’entrata in vigore del Regolamento UE 679/2016.

Leggi tutto

La valutazione del rischio Privacy

Perché valutare il rischio per la protezione dati

Sebbene il Regolamento UE 679/2016 (ormai più noto con l’acronimo inglese, GDPR) indichi diverse volte la necessità di effettuare una valutazione dei rischi che incombono sui dati personali, in molte organizzazioni non c’è una chiara evidenza di un processo documentato di valutazione dei rischi che abbia portato ad intraprendere determinate azioni e misure di sicurezza.

Già all’art. 25 (Privacy-by-design & privacy-by-default), comma 1, il GDPR ci indica la necessità di effettuare una valutazione dei rischi:

Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento, come anche dei rischi aventi probabilità e gravità diverse per i diritti e le libertà delle persone fisiche costituiti dal trattamento, sia al momento di determinare i mezzi del trattamento sia all’atto del trattamento stesso il titolare del trattamento mette in atto misure tecniche e organizzative adeguate, quali la pseudonimizzazione, volte ad attuare in modo efficace i principi di protezione dei dati, quali la minimizzazione, e a integrare nel trattamento le necessarie garanzie al fine di soddisfare i requisiti del presente regolamento e tutelare i diritti degli interessati.

Leggi tutto

Si fa presto a dire “Misure di Sicurezza adeguate”

Come noto il Regolamento UE 679/2016 (GDPR) non prevede più – a differenza del previgente D.Lgs 196/2003 – di attuare delle misure “minime” di sicurezza” a protezione dei dati personali trattati da un’organizzazione (titolare o responsabile del trattamento), bensì misure di sicurezza adeguate, stabilite a fronte di una valutazione dei rischi sui trattamenti.

In particolare, all’Articolo 32 del GDPR: Sicurezza del trattamento (Considerando 83), si riporta quanto segue:

1. Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, il titolare del trattamento e il responsabile del trattamento mettono in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio, che comprendono, tra le altre, se del caso:

a) la pseudonimizzazione e la cifratura dei dati personali;

b) la capacità di assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento;

c) la capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico;

d) una procedura per testare, verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento.

2. Nel valutare l’adeguato livello di sicurezza, si tiene conto in special modo dei rischi presentati dal trattamento che derivano in particolare dalla distruzione, dalla perdita, dalla modifica, dalla divulgazione non autorizzata o dall’accesso, in modo accidentale o illegale, a dati personali trasmessi, conservati o comunque trattati.


Leggi tutto