Il Nuovo Regolamento Europeo sulla Privacy, emanato lo scorso maggio ed in vigore entro fine maggio 2018, pone nuove questioni relativamente all’impiego di programmi software per l’elaborazione di dati personali, in particolare se si tratta anche di dati c.d. “sensibili” secondo la vecchia definizione del D. Lgs 196/2003.

Infatti il nuovo Regolamento Europeo sulla privacy (“Regolamento UE 2016/679 del Parlamento europeo”) impone alle organizzazioni che intendono effettuare trattamenti di dati personali di “progettare” il sistema in modo tale che sia conforme fin da subito (Privacy by design ) alle regole della privacy, spostando la responsabilità del corretto trattamento tramite strumenti informatici idonei sul titolare e sul responsabile del trattamento, quando identificato.

Nella pratica una organizzazione, prima di impiegare un applicativo software per trattare dati personali dovrà verificare che esso sia conforme ai requisiti stabiliti dal regolamento UE 679/2016, ovvero che presenti caratteristiche di sicurezza adeguate per mantenere protetti i dati personali, compresa l’eventuale pseudonomizzazione dei dati personali, quando necessaria, e la cifratura dei dati stessi.

Il Regolamento parla anche di “certificazione” della privacy, che può riferirsi ad un singolo o ad un insieme di trattamenti effettuati da un programma software, oppure da tutti i trattamenti effettuati da una organizzazione. In quest’ultimo caso siamo molto vicini alla certificazione del sistema di gestione ISO 27001. Al proposito è stato approvato da ACCREDIA lo schema proprietario ISDP©10003:2015 (conformità alle norme vigenti EU in tema di trattamenti dei dati personali).

Lo schema di certificazione ISDP 10003:2015 risponde ai requisiti di cui agli art. 42 e 43 del Regolamento 679/2016 ed è applicabile a tutte le tipologie di organizzazioni soggette alle norme vigenti in tema di tutela delle persone fisiche con riguardo al trattamento dei dati personali e la libera circolazione di tali dati. Lo schema di certificazione specifica ai “Titolari” e “Responsabili” del

trattamento, soggetti ai vincoli normativi vigenti nel territorio dell’EU, i requisiti necessari per la corretta valutazione della conformità alle norme stesse.

Ricordiamo anche che all’art 25, coma 2 il Regolamento sancisce che:

Il titolare del trattamento mette in atto misure tecniche e organizzative adeguate per garantire che siano trattati, per impostazione predefinita, solo i dati personali necessari per ogni specifica finalità del trattamento. Tale obbligo vale per la quantità dei dati personali raccolti, la portata del trattamento, il periodo di conservazione e l’accessibilità. In particolare, dette misure garantiscono che, per impostazione predefinita, non siano resi accessibili dati personali a un numero indefinito di persone fisiche senza l’intervento della persona fisica.

Rappresenta la c.d. Privacy by default: devono essere trattati “per default” solo i dati necessari a perseguire le finalità del trattamento posto in essere dal responsabile dello stesso, ovvero non devono essere trattati dati in eccesso senza che una persona fisica autorizzata lo consenta.

La certificazione introdotta all’Art. 42 può servire a dimostrare l’adozione di misure tecniche ed organizzative adeguate.

L’impatto di queste regole sugli applicativi software utilizzati per trattare anche dati personali è notevole: una organizzazione di qualsiasi dimensione che adotta un sistema informatico gestionale che tratta dati personali non in modo conforme al Regolamento UE 679/2016 di fatto rischia di essere sanzionata perché non ha adottato misure di sicurezza adeguate. Le responsabilità ricadono, in questo caso, sul titolare del trattamento e sul responsabile del trattamento, ove presente.

Dunque prima di adottare un nuovo software che gestisce archivi contenenti dati personali (a maggior ragione se vengono gestiti dati sanitari o altri dati c.d. “sensibili”) titolari e responsabili del trattamento devono valutarne la conformità alla normativa sulla privacy e questo può essere al di fuori delle competenze di chi decide l’acquisto di un applicativo software (responsabili EDP, Direttori Generali, ecc.), soprattutto nelle piccole e medie imprese o nelle strutture sanitarie di modeste dimensioni (es. Cliniche ed ambulatori privati).

La casistica di software che ricadono in questa sfera è vastissima, si va dai comuni ERP che trattano anche dati del personale, ai software per la gestione delle paghe, ai programmi per la gestione delle fidelity card, ai software impiegati in strutture sanitarie o quelli utilizzati dagli studi legali.

Oggi molti applicativi, magari obsoleti, non permettono di implementare misure di sicurezza adeguate (password di lunghezza adeguata, password di complessità minima variate periodicamente, password trasmesse via internet con connessioni crittografate, gestione utenti, raccolta di dati minimi indispensabili, gestione dei consensi, procedure di backup, ecc.) e in futuro il loro impiego diverrà non conforme alla normativa sulla privacy, ovvero non saranno più commercializzabili.

Da un lato i progettisti e gli sviluppatori di applicativi software dovranno considerare fra i requisiti di progetto anche quelli relativi alla normativa privacy, dall’altro le organizzazioni che adotteranno applicativi software (o che già li stanno utilizzando) saranno responsabili della loro eventuale non conformità al Regolamento Privacy.

In caso di catastrofi e calamità naturali quali terremoti, alluvioni, inondazioni, incendi, eruzioni vulcaniche, uragani oppure atti terroristici, uno dei danni collaterali dopo la perdita di vite umane e i danni materiali ad edifici ed infrastrutture, occorre considerare il blocco dei sistemi informativi che può rallentare notevolmente la ripresa delle normali attività.

Le metodologie da impiegare per prevenire e mitigar i danni che possono compromettere la ripresa delle attività dopo un evento catastrofico riguardano la tematica della business continuity (continuità operativa).

Nell’intervento presentato lo scorso 17/11 al Convegno EVENTI SISMICI: PREVENZIONE, PROTEZIONE, SICUREZZA, EMERGENZA, le cui slide sonono scaricabili in questa pagina, si sono presentate tutte le attività da porre in essere per controllare tali situazioni indesiderate, in particolare sono stati trattati i seguenti argomenti:

• business continuitymanagement
• normative ISO 22301, ISO 2001/27002 e ISO 27031 per la gestione della business continuity, con particolare riferimento ai sistemi informatici
• gestione dei rischi per la continuità operativa
• disaster recovery
• obiettivi ed indicatori di business continuity
• business continuity plan (piano di continuità operativa).

La sicurezza dei dati in caso di terremoto

Lo scorso 4 maggio è stato pubblicato sulla gazzetta ufficiale della Comunità Europea il “Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (regolamento generale sulla protezione dei dati)” e dopo 20 giorni dalla sua pubblicazione è divenuto legge europea, pertanto a partire dal 25 maggio 2016 decorrono i due anni di transitorio per l’applicazione del nuovo Regolamento.

Nella pagina Documenti di questo sito è possibile scaricare il testo ufficiale (ora anche per gli utenti non registrati).

Il Garante per la Protezione dei dati personali ha pubblicato un’apposita guida (http://194.242.234.211/documents/10160/5184810/Guida+al+nuovo+Regolamento+europeo+in+materia+di+protezione+dati ).

Rispetto al precedente articolo pubblicato su questo sito il 27/04/2016, basato sulla traduzione della proposta di Regolamento approvata dal Parlamento Europeo a dicembre 2015, di cui il presente articolo costituisce un aggiornamento, si rilevano alcune differenze nella traduzione del testo originale inglese in lingua italiana, rispetto all’attuale Codice privacy D.Lgs 196/2003:

• Viene mantenuto il “Titolare del trattamento” (Data Controller);
• Viene mantenuto il “Responsabile del Trattamento” (Data processor);
• Viene abolito l’Incaricato del trattamento.

Il nuovo Regolamento introdurrà una legislazione in materia di protezione dati uniforme e valida in tutta Europa, affrontando temi innovativi – come il diritto all’oblio e alla portabilità dei dati – e stabilendo anche criteri che da una parte responsabilizzano maggiormente imprese ed enti rispetto alla protezione dei dati personali e, dall’altra, introducono notevoli semplificazioni e sgravi dagli adempimenti per chi rispetta le regole. Il Regolamento UE 679/2016, però, non sarà l’unica fonte legislativa per regolamentare la protezione dei dati personali, infatti le Autorità dei singoli Stati Membri – e quindi il Garante della Privacy per l’Italia – potranno integrare i contenuti del Regolamento dettagliando meglio alcuni aspetti che al momento appaiono poco chiari, introdurre linee guida generali e di settore, regolamentare aspetti particolari, ecc.

A tal proposito occorre ricordare che, con l’uscita del Regolamento 679 non vengono aboliti i provvedimenti del nostro Garante su Videosorveglianza, Amministratori di Sistema, fidelity card, biometria, tracciamento flussi bancari, ecc. Tali provvedimenti probabilmente verranno modificati e/o integrati dal Garante Privacy per aggiornarli ed eventualmente adeguarli alle prescrizioni del Regolamento Europeo 679.

Il Garante Privacy italiano potrà inoltre integrare il Regolamento UE 679 per disciplinare il trattamento di dati personali effettuato per adempiere obblighi di legge italiana e in particolari ambiti, ad esempio quello dei dati sanitari, oppure per definire in modo più dettagliato gli obblighi per le PMI (ovvero per le organizzazioni che occupano meno di 250 dipendenti, per le quali il regolamento 679 ha stabilito delle semplificazioni).

Ma quali sono le principali novità per le imprese nella gestione della privacy a fronte del Regolamento UE?

L’aspetto più significativo è sicuramente il cambio di approccio rispetto al Codice Privacy attualmente in vigore in Italia, ed in particolare all’Allegato B, ovvero al Disciplinare Tecnico delle Misure Minime di Sicurezza. Il nuovo Regolamento Europeo sulla privacy, infatti, non definisce requisiti specificati in termini precisi, come avviene per l’attuale normativa italiana sulla privacy, ma sposta la responsabilità di definire le misure di sicurezza idonee a garantire la privacy dei dati personali trattati sul titolare o responsabile del trattamento, dopo un’attenta analisi dei rischi.

Dunque non ci sono più misure minime, ma solo misure di sicurezza adeguate, progettate dal titolare o responsabile del trattamento dopo aver effettuato l’analisi dei rischi che incombono sui dati personali che si intende trattare. Sottolineiamo quest’ultimo aspetto: le misure di prevenzione vanno poste in atto prima di iniziare il trattamento.

Poiché a livello nazionale la legislazione italiana ed il Garante per la Protezione dei Dati Personali hanno seguito il percorso europeo, a partire dalla Direttiva Europea 46/95, a livello di principi sulla privacy non ci sono differenze significative tra normativa italiana e Regolamento Europeo. Infatti, alcune regole già imposte dal Codice Privacy e dalle successive disposizioni del Garante restano valide, anche se con contorni un po’ meno definiti da criteri oggettivi. In sostanza:

• Viene regolamentato solo il trattamento di dati personali di persone fisiche (non giuridiche) per scopi diversi dall’uso personale.
• Resta una distinzione fra trattamento di dati personali comuni e trattamento di dati c.d. sensibili, anche se la definizione del D.lgs 196/2003 non viene utilizzata nel Regolamento UE 679, lasciando però la possibilità agli Stati membri di stabilire una disciplina particolare in merito.
• Restano gli obblighi di informare l’interessato sull’uso che verrà fatto dei suoi dati personali.
• Restano gli obblighi di ottenere il consenso per i trattamenti non necessari o per i trattamenti di particolari tipi di dati, ad esempio quelli idonei a rivelare lo stato di salute delle persone, le origini razziali, le idee religiose, ecc.

Tra gli elementi che cambiano vi sono sicuramente:

• La denominazione ed i ruoli degli attori: il titolare del trattamento rimane tale, il responsabile del trattamento è ora responsabile in solido con il titolare per i danni derivanti da un trattamento non corretto, l’incaricato rimane il soggetto che fisicamente tratta i dati, ma tale ruolo non è delegabile, se non attraverso uno specifico accordo contrattuale. Il responsabile può individuare un proprio rappresentante.
• I dati personali trattati devono essere protetti con misure organizzative e tecniche adeguate a garantirne la riservatezza e l’integrità.
• I diritti dell’interessato sono più ampi e maggiormente tutelati.
• Il responsabile del trattamento deve mettere in atto misure tecniche ed organizzative tali da consentirgli di dimostrare che tratta i dati personali in conformità al Regolamento. Tali misure devono seguire lo stato dell’arte e devono derivare dall’analisi dei rischi che incombono sui dati, secondo relativa gravità e probabilità.
• Privacy by default: devono essere trattati “per default” solo i dati necessari a perseguire le finalità del trattamento posto in essere dal responsabile dello stesso, ovvero non devono essere trattati dati in eccesso senza che una persona fisica autorizzata lo consenta.
• Privacy by design: ogni nuovo trattamento di dati personali dovrà essere progettato in modo da garantire la sicurezza richiesta in base ai rischi a cui è sottoposto prima di essere implementato. Anche i sistemi informatici dovranno essere progettati secondo tale principio.
• Possono esserci più responsabili per un medesimo trattamento che risulteranno, pertanto, corresponsabili di eventuali trattamenti non conformi, ma dovranno stabilire congiuntamente le rispettive responsabilità.
• Le imprese con sede al di fuori dell’Unione Europea, che trattano dati personali di interessati residenti nella UE dovranno eleggere una propria organizzazione o entità all’interno della UE che sarà responsabile di tali trattamenti.
• Devono essere mantenuti registri dei trattamenti di dati effettuati con le informazioni pertinenti e le relative responsabilità. Tali registri non sono obbligatori per organizzazioni con meno di 250 dipendenti salvo che non trattino dati sensibili (secondo la definizione del Codice della Privacy attualmente in vigore) o giudiziari. Tale discriminante potrà essere meglio specificata da appositi provvedimenti del nostro Garante.
• Il responsabile del trattamento deve notificare all’autorità competente – e, in casi gravi, anche all’interessato – ogni violazione dei dati (data breach) trattati entro 72 ore dall’evento.
• Quando un trattamento presenta dei rischi elevati per i dati personali degli interessati (i casi specifici dovranno essere esplicitati dall’Autorità Garante), il responsabile del trattamento deve effettuare una valutazione di impatto preventiva, prima di iniziare il trattamento.
• Viene introdotta la certificazione del sistema di gestione della privacy (le cui modalità dovranno essere meglio definite tramite gli Organismi di Accreditamento Europei, ACCREDIA per l’Italia)..
• È richiesta la designazione di un Responsabile della Protezione dei Dati (Data Protection Officer) nelle Aziende Pubbliche e nelle organizzazioni che trattano dati sensibili o giudiziari su larga scala oppure che la tipologia di dati trattati e la loro finalità richieda il controllo degli incaricati al trattamento su larga scala.

Proprio quest’ultimo punto, variato rispetto alle precedenti versioni del Regolamento, farà molto discutere, poiché non stabilisce criteri precisi ed oggettivi (cosa significa “su larga scala”?) per l’adozione di tale figura professionale, di competenze adeguate a garantire una corretta applicazione della normativa sulla privacy. Il Responsabile per la Protezione dei Dati dovrà essere correttamente informato dal Responsabile del Trattamento su tutte le attività che riguardano la privacy e dovrà disporre di risorse adeguate per svolgere il proprio compito e mantenere le sue competenze adeguate al ruolo che ricopre. Egli dovrà inoltre essere indipendente dalle altre funzioni dell’organizzazione e riferire solamente all’alta direzione.

La sicurezza dei dati – in termini di riservatezza, integrità e disponibilità – deve essere garantita in funzione del rischio che corrono i dati stessi, dei costi delle misure di sicurezza e dello stato dell’arte della tecnologia. Pertanto le password di almeno 8 caratteri variate almeno trimestralmente, l’antivirus aggiornato, il firewall e l’aggiornamento del sistema operativo potrebbero essere misure adeguate per determinati trattamenti, ma non per altri, oppure in determinate organizzazioni, ma non in altre, in ogni caso lo potrebbero essere oggi, ma non domani quando il progresso tecnologico (anche degli hacker e di coloro che minacciano i nostri dati) potrebbe renderle insufficienti.

Lasciando per il momento stare gli impatti che il nuovo Regolamento UE sulla privacy potrà avere per i colossi del web, quali Facebook, Google, ecc., è opportuno osservare che per le piccole e medie imprese italiane dovrà cambiare l’approccio alla privacy, soprattutto per quelle organizzazioni che trattano dati sensibili o giudiziari. Occorrerà un cambio di mentalità: non serve più un po’ di carte (informative, consensi, lettere di incarico, …) ed alcune misure minime di sicurezza specifiche (password, antivirus,…) per garantire il rispetto della legge. Poiché molti imprenditori vedono la privacy solo come un disturbo da gestire soltanto per non incorrere in sanzioni e, quindi, come una pratica da sbrigare nel modo più indolore possibile, ecco che il passaggio al nuovo Regolamento – che dovrà avvenire nei prossimi due anni – non sarò proprio una passeggiata.

Le responsabilità in capo al responsabile del trattamento (ex titolare del trattamento) sono maggiori e comunque più impegnative da gestire, soprattutto laddove il trattamento di dati venga delegato a fornitori (es. consulenti del lavoro, consulenti fiscali e legali, strutture esterne, ecc.) che dovranno inevitabilmente essere tenuti sotto controllo.

Non è che taluni principi fossero assenti dalla normativa italiana del 2003, ma – complice la crisi e le semplificazioni adottate da precedenti governi, soprattutto l’abolizione del DPS – hanno un po’ sminuito l’importanza della privacy in azienda, anche perché – si sa come siamo fatti noi italiani – senza sanzioni esemplari non ci preoccupiamo di nulla… e sono stati molto rare le sanzioni comminate alle aziende, anche perché i controlli sono stati molto poco frequenti.

Paradossalmente ha spaventato di più la disposizione sui cookie perché la sua mancata applicazione è di fatto pubblica, mentre altre regole di fatto trascurate rimangono tra le muar delle organizzazioni di ogni dimensione.

L’indeterminatezza di alcune regole potrà essere colmata da disposizioni specifiche dei singoli Stati membri e/o da linee guida di settori specifici che potranno agevolare l’interpretazione della legge.

Ora la privacy sarà meno materia per avvocati – se non per la stesura di contratti che regolamentano i rapporti fra clienti e fornitori anche in materia di trattamento dati personali – e più materia per esperti della sicurezza delle informazioni. Infatti l’approccio del nuovo Regolamento Europeo sulla Privacy si avvicina, mutatis mutandis, a quello della norma UNI EN ISO/IEC ISO 27001 e della linea guida UNI EN ISO/IEC 27002.

L’adozione del nuovo Regolamento UE sarà, pertanto, più impegnativa per piccole organizzazioni che trattano molti dati c.d. sensibili o giudiziari, quali organizzazioni private nel campo della sanità (cliniche ed ambulatori privati, farmacie, …), studi di consulenza del lavoro, infortunistiche, studi legali, studi di consulenza fiscale, ecc., piuttosto che per aziende che trattano come unici dati sensibili i dati relativi ai propri dipendenti. Anzi saranno proprio queste ultime che dovranno pretendere da società e studi di consulenza esterna adeguate garanzie per il trattamento dei dati di cui sono responsabili.

In questo articolo (cfr. precedente articolo) passiamo ad esaminare la seconda parte della norma La norma UNI CEI ISO/IEC 27002:2014 – Raccolta di prassi sui controlli per la sicurezza delle informazioni (che sostituisce la ISO 27002:2005).

12 Sicurezza delle attività operative

Questa area comprende ben 7 categorie:

• Procedure operative e responsabilità (12.1): devono essere predisposte procedure per documentare lo svolgimento di una serie di attività inerenti la sicurezza, occorre gestire i cambiamenti all’organizzazione e la capacità delle risorse (di storage, di banda, infrastrutturali ed anche umane), infine è necessario mantenere separati gli ambienti di sviluppo da quelli di produzione.
• Protezione dal malware (12.2): un solo controllo in questa categoria (protezione dal malware) che prescrive tutte le misure di sicurezza da attuare contro il malware. Non solo antivirus per prevenire ed eliminare malware, ma anche azioni di prevenzione tecnica e comportamentali (consapevolezza degli utenti).
• Backup (12.3): devono essere documentate ed attuate procedure di backup adeguate a garantire il ripristino dei dati in caso di perdita dell’integrità degli stessi e la continuità operativa (vedasi anche punto 17).
• Raccolta di log e monitoraggio (12.4): devono essere registrati, conservati e protetti i log delle attività degli utenti normali e di quelli privilegiati (si ricorda che per apposita disposizione del Garante Privacy italiano i log degli accessi in qualità di Amministratore di Sistema devono essere mantenuti in modo “indelebile” per almeno 6 mesi), occorre inoltre mantenere sincronizzati gli orologi dei sistemi con una fonte attendibile.
• Controllo del software di produzione (12.5): particolari attenzioni devono essere adottate nell’installazione ed aggiornamento del software di produzione (non solo per organizzazioni del settore ICT, banche o assicurazioni, ma anche per aziende manifatturiere!).
• Gestione delle vulnerabilità tecniche (12.6): viene fornita dalla norma un’ampia guida attuativa sulla gestione delle vulnerabilità tecniche conosciute (occorre mantenere un censimento dell’hardware e del relativo software installato su ogni elaboratore, installare le patch di sicurezza in modo tempestivo, mantenersi aggiornati sulle vulnerabilità di sicurezza conosciute, ecc.), oltre alle indicazioni sulla limitazione nell’installazione dei software (è opportuno, infatti, ridurre al minimo la possibilità per gli utenti di installare applicativi software autonomamente, anche se leciti come le utility gratuite che, a volte, possono essere il veicolo di adware o altre minacce alla sicurezza).
• Considerazioni sull’audit dei sistemi informativi (12.7): gli audit sui sistemi informativi dovrebbero avere un impatto ridotto sulle attività lavorative e le evidenze raccolte dovrebbero essere raccolte senza alterare i dati dei sistemi (accessi in sola lettura) e dovrebbero essere mantenute protette.

Questi elementi nella precedente versione della norma erano in gran parte all’interno della sezione 10 “Communications and Operations Management” (ma la gestione delle vulnerabilità tecniche era, invece, al paragrafo 12.6, per puro caso lo stesso della versione attuale della norma), il quale comprendeva anche i controlli del punto 13 seguente.

13 Sicurezza delle comunicazioni

Questa sezione contiene due sole categorie:

• Gestione della sicurezza della rete (13.1): occorre adottare alcuni accorgimenti per garantire la sicurezza delle reti interne (responsabilità, autenticazioni, ecc.); viene anche citata la ISO/IEC 27033 nelle sue parti da 1 a 5 sulla sicurezza delle reti e delle comunicazioni per ulteriori informazioni. Deve, inoltre, essere gestita la sicurezza dei servizi di rete, compresi i servizi acquistati presso fornitori esterni, e la segregazione delle reti (separazione delle VLan, gestione delle connessioni Wi-Fi, …).
• Trasferimento delle informazioni (13.2): occorre stabilire ed attuare politiche e procedure per il trasferimento delle informazioni con qualsiasi mezzo (posta elettronica, fax, telefono, scaricamento da internet, ecc.), nel trasferimento di informazioni con soggetti esterni occorre stabilire accordi sulle modalità di trasmissione, le informazioni trasmesse tramite messaggistica elettronica dovrebbero essere adeguatamente controllate e protette (non solo e-mail, ma anche sistemi EDI, instant messages, social network, ecc.) e, infine, occorre stabilire e riesaminare periodicamente accordi di riservatezza e di non divulgazione con le parti interessate.

I 7 controlli di quest’area sono sicuramente molto dettagliati e migliorano, oltre ad aggiornare, la precedente versione della norma, includendo controlli (un po’ sparsi nella versione 2005 della ISO 27002) che recepiscono le nuove modalità di comunicazione, tra cui i social network, professionali e non.

14 Acquisizione, sviluppo e manutenzione dei sistemi

Quest’area tratta la sicurezza dei sistemi informativi impiegati per le attività aziendali e comprende tre categorie:

• Requisiti di sicurezza dei sistemi informativi (14.1): la sicurezza dei sistemi informativi- acquistati o sviluppati ad hoc – deve essere stabilita fin dall’analisi dei requisiti, deve essere garantita la sicurezza dei servizi applicativi che viaggiano su reti pubbliche (ad esempio attraverso trasmissioni ed autenticazioni sicure crittografate), infine occorre garantire la sicurezza delle transazioni dei servizi applicativi.
• Sicurezza nei processi di sviluppo e supporto (14.2): devono essere definite ed attuate politiche per lo sviluppo (interno o esterno all’organizzazione) sicuro dei programmi applicativi, devono essere tenuti sotto controllo tutti i cambiamenti ai sistemi (dagli aggiornamenti dei sistemi operativi alle modifiche dei sistemi gestionali), occorre effettuare un riesame tecnico sul funzionamento degli applicativi critici a fronte di cambiamenti delle piattaforme operative (sistemi di produzione, database, ecc.) e si dovrebbero limitare le modifiche (personalizzazioni) ai pacchetti software, cercando comunque di garantirne i futuri aggiornamenti. Inoltre dovrebbero essere stabiliti, documentati ed attuati principi per l’ingegnerizzazione sicura dei sistemi informatici e per l’impiego di ambienti di sviluppo sicuri. Nel caso in cui attività di sviluppo software fossero commissionate all’esterno, dovrebbero essere stabilite misure per il controllo del processo di sviluppo esternalizzato. Infine dovrebbero essere eseguiti test di sicurezza dei sistemi durante lo sviluppo e test di accettazione nell’ambiente operativo di utilizzo, prima di rilasciare il software.
• Dati di test (14.3): i dati utilizzati per il test dovrebbero essere scelti evitando di introdurre dati personali ed adottando adeguate misure di protezione, anche al fine di garantirne la riservatezza.

Nel complesso i 13 controlli di questa sezione sono molto dettagliati e comprendono una serie di misure di sicurezza informatica ormai consolidate che riguardano tutti gli aspetti del ciclo di vita del software impiegato da un’organizzazione per la propria attività. Alcuni principi vanno commisurati ad una attenta valutazione dei rischi, poiché una stessa regola di sicurezza informatica (ad es. l’aggiornamento sistematico e tempestivo del software di base) potrebbe non garantire sempre l’integrità e la disponibilità dei sistemi (ad es. errori o malfunzionamenti introdotti dagli ultimi aggiornamenti di un sistema operativo).

15 Relazioni con i fornitori

Questo punto di controllo tratta tutti gli aspetti di sicurezza delle informazioni che possono legati al comportamento dei fornitori. Sono state individuate due categorie:

• Sicurezza delle informazioni nelle relazioni con i fornitori (15.1): è necessario stabilire una politica ed accordi su tematiche inerenti la sicurezza delle informazioni con i fornitori che accedono agli asset dell’organizzazione; tali accordi devono comprendere requisiti per affrontare i rischi relativi alla sicurezza associati a prodotti e servizi nella filiera di fornitura dell’ICT (cloud computing compreso).
• Gestione dell’erogazione dei servizi dei fornitori (15.2): occorre monitorare – anche attraverso audit se necessario – e riesaminare periodicamente le attività dei fornitori che influenzano la sicurezza delle informazioni, nonché tenere sotto controllo tutti i cambiamenti legati alle forniture di servizi.

16 Gestione degli incidenti relativi alla sicurezza delle informazioni

L’area relativa agli incidenti sulla sicurezza delle informazioni (sezione 13 della precedente versione della norma) comprende una sola categoria (erano 2 nella precedente edizione):

• Gestione degli incidenti relativi alla sicurezza delle informazioni e dei miglioramenti (16.1): devono essere rilevati e gestiti tutti gli incidenti relativi alla sicurezza delle informazioni (viene qui richiamata la ISO/IEC 27035 – Information security incident management), ma anche rilevate ed esaminate tutte le segnalazioni di eventi relativi alla sicurezza che potrebbero indurre a pensare che qualche controllo è risultato inefficace senza provocare un vero e proprio incidente e pure tutte le possibili debolezze dei controlli messi in atto. In ogni caso ogni evento relativo alla sicurezza delle informazioni va attentamente valutato per eventualmente classificarlo come incidente vero e proprio o meno. Occorre poi rispondere ad ogni incidente relativo alla sicurezza delle informazioni in modo adeguato ed apprendere da quanto accaduto per evitare che l’incidente si ripeta. Infine dovrebbero essere stabilite procedure per la raccolta di evidenze relative agli incidenti e la successiva gestione (considerando anche eventuali azioni di analisi forense).

17 Aspetti relativi alla sicurezza delle informazioni nella gestione della continuità operativa

In quest’area (corrispondente al punto 14 sella precedente versione della norma) viene trattata la business continuity in 5 controlli suddivisi in due categorie:

• Continuità della sicurezza delle informazioni (17.1): la continuità operativa per la sicurezza delle informazioni dovrebbe essere pianificata a partire dai requisiti per la business continuity, piani di continuità operativa (business continuity plan) dovrebbero essere attuati, verificati e riesaminati periodicamente.
• Ridondanze (17.2): per garantire la disponibilità (e la continuità operativa) occorre prevedere architetture e infrastrutture con adeguata ridondanza.

Naturalmente sull’argomento esiste la norma specifica UNI EN ISO 22301:2014 – Sicurezza della società – Sistemi di gestione della continuità operativa – Requisiti.

18 Conformità

Questo ultimo punto di controllo (era il punto 15 nella ISO 27002:2005) tratta la gestione della cosiddetta “compliance”, ovvero la conformità a leggi, regolamenti ed accordi contrattuali con i clienti. Sono identificate due categorie:

• Conformità ai requisiti cogenti e contrattuali (18.1): occorre innanzitutto identificare i requisiti cogenti, quindi attuare controlli per evitare di ledere i diritti di proprietà intellettuale, proteggere adeguatamente le registrazioni che permettono di dimostrare la conformità a tutti i requisiti cogenti, in particolare devono essere rispettati leggi e regolamenti sulla privacy (in Italia il D.Lgs 196/2003 in attesa del nuovo Regolamento Europeo, ma nella norma viene citata come riferimento la ISO/IEC 29100:2011 “Information technology – Security techniques — Privacy framework”). Infine occorre considerare eventuali limitazioni all’uso dei controlli crittografici vigenti in alcune nazioni.
• Riesami della sicurezza delle informazioni (18.2): dovrebbe essere svolto periodicamente un riesame indipendente sulla sicurezza delle informazioni dell’organizzazione, i processi di elaborazione delle informazioni e le procedure dovrebbero essere riesaminate periodicamente per valutarne la continua conformità ed adeguatezza alla politica ed alle norme ed infine dovrebbero essere eseguite delle verifiche tecniche della conformità dei sistemi informativi a politiche e standard di sicurezza (ad esempio penetration test e vulnerability assessment). Su quest’ultimo controllo si fa riferimento alla ISO/IEC TR 27008 – Guidelines for auditors on information security management systems controls.

La norma UNI CEI ISO/IEC 27002:2014 “Raccolta di prassi sui controlli per la sicurezza delle informazioni” (che sostituisce la ISO 27002:2005) è stata progettata per essere impiegata nelle organizzazioni che intendono implementare un sistema di gestione della sicurezza delle informazioni ISO 27001 e la prendono come riferimento per la scelta dei controlli di sicurezza da attuare.

Struttura della norma

La norma contiene 14 punti di controllo di sicurezza (erano 11 nella precedente versione della norma) che riuniscono un totale di 35 categorie principali di sicurezza (erano 39 nella versione precedente) e 114 controlli (erano 133 nella versione precedente).

Ogni punto che definisce controlli di sicurezza contiene una o più categorie principali di sicurezza, al cui interno sono raggruppati i controllo relativi. Nella norma viene precisato che l’ordine dei punti è indipendente dalla loro importanza, infatti, a seconda delle circostanze, i controlli di sicurezza appartenenti ad uno o a tutti i punti di controllo potrebbero rivelarsi più o meno importanti ed ogni organizzazione che impiega la norma dovrebbe identificare i controlli applicabili al proprio interno, la loro importanza ed il loro impiego in ogni processo di business.

Ogni categoria principale di controllo di sicurezza contiene:

• L’obiettivo di controllo che dichiara cosa si vuole raggiungere
• I controlli che possono essere applicati per raggiungere l’obiettivo di controllo.

La descrizione dei controlli sono strutturate come segue:

• Controllo: definisce nello specifico il controllo funzionale alla soddisfazione dell’obiettivo di controllo.
• Guida attuativa: fornisce informazioni più dettagliate per supportare l’attuazione del controllo. La guida può risultare completamente attinente o sufficiente a tutte le situazioni oppure potrebbe non soddisfare i requisiti specifici di controllo dell’organizzazione.
• Altre informazioni: fornisce informazioni aggiuntive che potrebbe essere necessario considerare, per esempio considerazioni legali e riferimenti ad altre norme. Nel caso non vi siano informazioni aggiuntive da considerare questa parte non è riportata nel testo.

Elenco dei controlli

I punti di controllo definiti dalla norma sono i seguenti:

5 Politiche per la sicurezza delle informazioni

Al suo interno viene individuata la categoria “Indirizzi della direzione per la sicurezza delle informazioni” (5.1), in cui viene indicata la necessità di stabilire una politica per la sicurezza delle informazioni coerente con gli obiettivi e gli indirizzi dell’organizzazione in merito all’Information Security, anche in funzione del contesto di riferimento (mercato, esigenze dei clienti, leggi e regolamenti applicabili). Tale politica dovrà essere mantenuta aggiornata attraverso riesami periodici.

6 Organizzazione della sicurezza delle informazioni

In questa sezione sono definiti le seguenti categorie principali:

• Organizzazione interna (6.1): è necessario definire tutti i ruoli e le responsabilità per la sicurezza delle informazioni, separazioni dei compiti, modalità di contatto con le autorità e con gruppi specialistici ed infine le modalità di gestione dei progetti con riferimento alla sicurezza delle informazioni.
• Dispositivi portatili e telelavoro (6.2): in questa categoria sono raggruppati due controlli molto importanti che, forse, meriterebbero una trattazione separata, anche se poi i controlli relativi sono descritti in modo dettagliato. I dispositivi portatili da gestire e mantenere sotto controllo sono di diverse tipologie (notebook, tablet, smartphone, …) ed ognuna di essa meriterebbe una trattazione a sé, così come la proprietà del dispositivo (azienda, dipendente o collaboratore, o semplice visitatore) ed il tipo di impiego (esclusivamente aziendale, esclusivamente privato o misto come nel caso del BYOD, Bring Your Own Device). Per quanto riguarda il telelavoro occorre tenere sotto controllo diversi parametri ed aspetti di sicurezza fisica e logica, non trascurando il fatto che ora il telelavoro è inteso in senso più ampio rispetto alla precedente versione della norma.

Quest’area è nel complesso più ridotta rispetto alla sezione 6 della precedente versione della norma che, tra l’altro, riportava la medesima categoria riferita a dispositivi portatili e telelavoro alla sezione 11, quella del controllo accessi. Del resto questa seconda categoria deve essere considerata in senso un po’ più ampio perché la sicurezza dei dispositivi portatili e del telelavoro deve essere valutata insieme alla gestione delle connessioni wi-fi e degli accessi a siti web aziendali e ad eventuali servizi cloud.

Francamente ci si poteva aspettare qualcosa di più in quest’area ove al 6.2 l’evoluzione tecnologica in questi ultimi 9 anni trascorsi dalla precedente versione della ISO 27002 ha fatto passi da gigante moltiplicando anche le possibili vulnerabilità e qualche citazione più specifica del problema del BYOD e dell’autenticazione a due fattori (2FA) sarebbe stata gradita.

7 Sicurezza delle risorse umane

In questa sezione sono descritte le attività da considerare per garantire la sicurezza nella gestione del personale prima, durante ed al termine del rapporto di lavoro:

• Prima dell’impiego (7.1): in due controlli vengono esposte tutte le cautele da intraprendere al momento dell’assunzione di una persona o dell’incarico ad un collaboratore esterno, non solo accordi di riservatezza e clausole contrattuali sul futuro rapporto lavorativo, ma anche – per quanto reso possibile dalla legislazione applicabile – un’accurata indagine conoscitiva sul passato, lavorativo e non, del futuro dipendente/collaboratore.
• Durante l’impiego (7.2): nel corso della normale attività lavorativa viene data enfasi all’applicazione delle procedure stabilite e le responsabilità della Direzione nell’applicazione delle stesse, alla formazione-addestramento e sensibilizzazione del personale ed al ricorso ad eventuali processi disciplinari. Dunque regole da rispettare, ma anche motivazione ed incentivazione del personale, oltre che sanzioni a chi infrange le regole.
• Cessazione e variazione del rapporto di lavoro (7.3): vengono presi in esame tutti gli aspetti e le attività da svolgere quando si chiude un rapporto di lavoro o avviene un’assegnazione ad altro incarico, come ad esempio il prolungamento della validità degli accordi di riservatezza, i passaggi di consegne e la comunicazione all’altro personale interessato della cessazione del rapporto di lavoro.

Qualche perplessità desta la traduzione UNI in quest’area: viene utilizzato il termine “soffiare” in senso di “soffiata”, “spiata”, “delazione”, “informazione anonima su un comportamento non corretto” ed il termine “inazioni” probabilmente intendendo “omissioni” o il contrario di azioni, ovvero il “non agire”.

I contenuti sono analoghi a quelli della precedente versione della norma alla sezione 8, anche se i controlli sono in numero minore.

8 Gestione degli asset

In quest’area viene trattata la gestione degli asset (tradotti come “beni” nella precedente versione della norma ISO 27001) all’interno di tre categorie:

• Responsabilità per gli asset (8.1): tutti gli asset aziendali vanno inventariati, ne deve essere definito un responsabile e le regole per l’utilizzo e la gestione durante tutto il ciclo di vita.
• Classificazione delle informazioni (8.2): le informazioni dovrebbero essere classificate in funzione del livello di riservatezza richiesto e conseguentemente etichettate in funzione della loro classificazione. Le procedure per il trattamento degli asset dovrebbero essere una logica conseguenza della classificazione degli stessi e delle informazioni in essi trattate.
• Trattamento dei supporti (8.3): al fine di garantire riservatezza, integrità e disponibilità delle informazioni contenute nei supporti rimovibili (hard-disk esterni, chiavi USB, DVD, ecc.) occorre prevedere opportune procedure di gestione degli stessi durante tutto il loro ciclo di vita (impiego, dismissione, trasporto, ecc.).

Nella presente sezione – praticamente immutata rispetto alla corrispondente sezione 7 della precedente versione della norma, salvo l’aggiunta di due controlli – viene richiamata la classificazione degli asset finalizzata alla valutazione dei rischi contenuta nella ISO 27005.

9 Controllo degli accessi

Questa sezione tratta l’importante aspetto del controllo degli accessi alle aree dove sono custodite informazioni, in formato digitale o su supporto cartaceo, sia dal punto di vista degli accessi fisici, sia dal punto di vista degli accessi logici ai sistemi informatici. Le categorie prese in esame sono le seguenti:

• Requisiti di business per il controllo degli accessi (9.1): occorre definire una politica di controllo degli accessi basata sull’accesso alle sole informazioni necessarie per svolgere il proprio lavoro (come impone anche la normativa sulla privacy in vigore in Italia) e regolamentare l’accesso alle reti (soprattutto evitare l’uso incontrollato delle reti wi-fi senza autenticazione utente).
• Gestione degli accessi degli utenti (9.2): è necessario regolamentare il processo di registrazione (tramite credenziali di autenticazione univoche) e de-registrazione degli utenti, la fornitura delle credenziali di accesso (provisioning), la gestione degli accessi privilegiati (ad es. quelli in qualità di “amministratore di sistema”, cfr. apposita disposizione del Garante della Privacy), la gestione delle informazioni segrete per l’autenticazione (password, smartcard, ecc.), il riesame periodico dei diritti di accesso, la rimozione degli stessi al termine del rapporto (o la revisione in caso di cambio mansioni).
• Responsabilità dell’utente (9.3): è importante regolamentare ed istruire il personale sull’uso della password.
• Controllo degli accessi ai sistemi e alle applicazioni (9.4): è opportuno limitare l’accesso alle informazioni, predisporre procedure di log-on sicure, procedure di gestione delle password, limitare l’impiego di programmi di utilità privilegiati, limitare gli accessi al codice sorgente dei programmi.

Nei controlli esposti sono illustrati molti principi di sicurezza delle informazioni abbastanza noti ai più, ma spesso non recepiti nelle PMI per scarsa competenza dei responsabili IT (spesso esterni), richieste di gestioni semplificate da parte degli utenti e dei responsabili, mancanza di consapevolezza da parte della Direzione e, soprattutto, la ricerca del minor costo nelle apparecchiature e nella formazione del personale. Per questo motivo molte regole basilari, ad esempio relative ad una corretta gestione della rete wi-fi (creazione di accessi “ospite” per gli esterni, impiego di autenticazioni per singolo utente tramite protocollo Radius o da pannello di controllo del router, segmentazione delle reti in Vlan, …) e delle password (impiego di password complesse e memorizzate in modo sicuro tramite utility apposite, uso non promiscuo delle password, variazione delle password al primo accesso,…) spesso non vengono implementate.

Nel complesso sono presenti molti meno controlli rispetto alla precedente versione della norma alla sezione 11, ma i contenuti, opportunamente aggiornati, sono equivalenti.

10 Crittografia

Questo punto di controllo prevede una sola categoria “Controlli crittografici” (10.1) all’interno della quale sono descritti due controlli inerenti la politica relativa all’impiego dei controlli crittografici e la gestione delle chiavi crittografiche. La trattazione è molto dettagliata e comprende diversi aspetti da non sottovalutare come cosa fare in caso di indisponibilità, temporanea o permanente, delle chiavi crittografiche. In Italia occorre considerare la normativa specifica sulla firma digitale e la gestione dei certificati tramite le certification authority accreditate. Viene richiamata la norma ISO/IEC 11770 per ulteriori informazioni sulle chiavi.

Questa che era prima una categoria (cfr. punto 12.3 della norma ISO 27002:2005) ora è salito a livello di punto di controllo.

11 Sicurezza fisica e ambientale

La sezione comprende due categorie:

• Aree sicure (11.1): devono essere definiti dei perimetri che delimitano aree con diversi livelli di sicurezza, nei quali occorre prevedere adeguate protezioni per prevenire accessi indesiderati e safety (viene citata la normativa antincendio), devono essere attivati sistemi di controllo e registrazione degli accessi alle aree sicure, devono essere implementate particolari misure di sicurezza fisica per proteggere aree chiave e devono essere adottate misure di protezione contro disastri e calamità naturali (incendi, alluvioni, terremoti, ecc.). Inoltre devono essere progettate ed attuate procedure per permettere il lavoro in aree sicure e protette e, infine, devono essere implementati controlli particolari nelle aree di carico/scarico materiali.
• Apparecchiature (11.2): particolari accorgimenti devono essere intrapresi per proteggere le apparecchiature impiegate (per elaborazione o archiviazione di informazioni in genere) rispetto ad accessi non consentiti o minacce di possibili danneggiamenti, anche provenienti dalle infrastrutture di supporto (connettività di rete, energia elettrica, gas, acqua, ecc.) o da carenze di sicurezza dei cablaggi. Inoltre le apparecchiature devono essere sottoposte a regolare manutenzione, dispositivi hardware e software devono essere mantenuti sotto controllo in caso di trasferimenti all’esterno dell’organizzazione, adottando, nel caso particolari misure di sicurezza ed in caso di dismissione di apparecchiature o supporti di memorizzazione le informazioni in essi contenute devono essere cancellate in modo sicuro. Infine è necessario definire istruzioni affinché le apparecchiature non siano lasciate incustodite quando con esse è possibile accedere ad informazioni riservate ed occorre definire politiche di “scrivania pulita” per prevenire la visione di informazioni riservate da parte di personale non autorizzato.

fine I parte ….continua…

Il BCP (Business Continuity Plan) o Piano di Continuità Operativa è un documento richiesto alle organizzazioni certificate ISO 27001 (Sistema di gestione per la sicurezza delle informazioni – Requisiti) al controllo A.17.1 “Continuità della sicurezza delle informazioni”, ma anche – e soprattutto – dalla norma specifica UNI EN ISO 22301:2014 – Sicurezza della società – Sistemi di gestione della continuità operativa – Requisiti, che abbiamo trattato in un precedente articolo.

Gli eventi delle ultime settimane, ma anche degli ultimi anni, hanno mostrato quanto scarsa sia l’adozione di questo strumento nel nostro Paese. Molti sono, infatti, gli esempi di situazioni critiche – essenzialmente causate da disastri naturali – che non sono state fronteggiate nel modo corretto e che hanno portato a costi sociali elevatissimi che si sono scaricati inevitabilmente sulla collettività:

• Il terremoto dell’Aquila e dell’Emilia;
• Le alluvioni in Liguria ed in Toscana;
• Le interruzioni di energia elettrica protrattesi nel tempo a Cortina qualche Natale fa e, più recentemente, in Emilia dopo una forte nevicata;
• Le forti nevicate verificatesi in Emilia-Romagna nel 2012.

In tutte queste situazioni di emergenza, oltre ai danni materiali ed alle perdite di vite umane, si sono verificate disfunzioni e ritardi nella ripresa dell’operatività ordinaria. Il vantaggio di avere predisposto un buon piano di continuità operativo è proprio questo: ipotizzando una situazione di crisi si cerca di limitare i danni e di tornare all’operatività normale nel più breve tempo possibile.

Tornando ad aspetti più tecnici, mentre la ISO 27001 tratta la continuità operativa in termini di sicurezza delle informazioni, ovvero di garantire il ritorno alla piena disponibilità delle informazioni senza perdite significative delle stesse, la ISO 22301 amplia il raggio di azione del business continuity plan, comprendendo la gestione delle discontinuità di un servizio, non necessariamente legato alla disponibilità di informazioni su supporto cartaceo o elettronico (anche se oggi ben poche attività possono farne a meno). Alcuni esempi possono chiarire meglio il concetto:

• La gestione di un ospedale a fronte di grandi epidemie che riducono anche la disponibilità di risorse umane sufficienti ad affrontare l’emergenza;
• Un servizio di trasporto di persone o beni in caso di calamità naturali;
• Un servizio di pronto intervento di manutenzione in caso di calamità naturali che impediscono al personale di recarsi al lavoro;
• Un servizio di ristorazione collettiva in caso di calamità naturali o epidemie influenzali che impediscono al personale di recarsi al lavoro;
• E così via.

Si ricorda che la continuità operativa è l’insieme di attività volte a minimizzare gli effetti distruttivi, o comunque dannosi, di un evento che ha colpito un’organizzazione o parte di essa, garantendo la continuità delle attività in generale.

La sfera di interesse della continuità operativa va oltre il solo ambito informatico, interessando l’intera funzionalità di un’organizzazione (Azienda, Ente Pubblico, ecc.) ed è, pertanto, assimilabile all’espressione “business continuity”.

La continuità operativa comprende sia gli aspetti strettamente organizzativi, logistici e comunicativi che permettono la prosecuzione delle funzionalità di un’organizzazione, sia la continuità tecnologica, che riguarda l’infrastruttura informatica e telecomunicativa (ICT) ed è nota come “disaster recovery” (DR). Pertanto, le soluzioni per garantire la continuità dei servizi non considerano soltanto le componenti tecnologiche utilizzate, ma anche tutte le altre risorse (personale, impianti, infrastrutture, ecc.).

Le analisi, valutazioni e scelte di trattamento del rischio richieste dalla gestione della continuità operativa sono le seguenti:

• Identificazione dei rischi;
• Analisi e valutazione dei rischi;
• Analisi delle conseguenze di disastri, malfunzionamenti, interruzioni di servizi (Business Impact Analysis);
• Realizzazione di piani (controlli) affinché i processi di business siano riattivati entro il tempo richiesto.

Le analisi valutano per ogni asset (o gruppo di asset) critico il tempo che tale asset può rimanere indisponibile con danno basso o nullo. I piani (Business Continuity Plan) devono essere mantenuti costantemente aggiornati per essere efficaci al momento del bisogno.

Per meglio comprendere la predisposizione di un BCP occorre introdurre alcune definizioni basilari:

• Mission Critical Activity (MCA): attività critica o di supporto al business relativamente ai servizi o prodotti offerti dall’organizzazione (internamente o esternamente), incluse le sue correlazioni con altri processi e single points of failure, che permettono all’organizzazione di raggiungere i suoi obiettivi di business considerando le stagionalità e/o tempi di rilascio critici
• Business Impact Analysis (BIA): analisi gestionale attraverso la quale un’organizzazione valuta quantitativamente (per esempio finanziariamente, Service Level Agreement, SLA) e qualitativamente (per esempio reputazione, leggi, regolamenti) gli impatti e le perdite che possono risultare se l’organizzazione subisce un grave incidente, e il minimo livello di risorse necessarie per il ripristino.
• Maximum Tollerance DownTime (MTDT): massimo intervallo di tempo ammissibile di interruzione del servizio (quante ore posso permettermi di non erogare il servizio ai clienti?).
• Maximum Tollerance Data Loss (MTDL): massima perdita di dati tollerata (quanti dati posso permettermi di perdere?).
• RTO (Recovery Time Objective): periodo di tempo entro il quale devono essere ripristinati un minimo livello di servizio, i sistemi di supporto e le funzionalità principali dopo un’interruzione dei servizi. Normalmente è il lasso di tempo entro il quale cui le MCA devono essere ripristinate.
• RPO (Recovery Point Objective): istante (punto) nel tempo al quale i dati sono coerenti e possono essere ripristinati.
• MBCO (Minimum Business Continuity Objective): livello di servizio minimo accettabile dall’organizzazione per raggiungere i propri obiettivi di business durante una rottura.

Il processo di gestione della continuità operativa deve prendere in esame tutti i processi e le attività aziendali e classificarli in funzione della loro criticità nel modo seguente:

1. Attività critiche per il business (MCA’s);
2. Attività importanti;
3. Attività secondarie.

Per le attività critiche vengono stabiliti degli obiettivi di continuità operativa in termini di MTDT, MTDL, RTO, RPO, MBCO e stabiliti dei piani di continuità operativa, che comprendono le contromisure messe in campo per garantire gli obiettivi.

Per la pianificazione delle attività di continuità operativa è necessario valutare preliminarmente gli impatti degli eventi che possono causare interruzioni dei processi di business, predisponendo una BIA.

A seguito della valutazione dei rischi di interruzione del servizio erogato ai clienti devono essere predisposti, attuati e periodicamente verificati uno o più Piani di Continuità Operativa (Business Continuity Plan) aventi lo scopo di mantenere o ripristinare il funzionamento dei processi critici ed assicurare la disponibilità delle informazioni necessarie a garantire un livello di servizio accettabile, a fronte del verificarsi dei rischi di interruzioni o malfunzionamenti precedentemente identificati e valutati.

Dunque se pensiamo ad un servizio di pubblica utilità (servizi ospedalieri, trasporto pubblico, mense scolastiche, servizi di pulizia e raccolta rifiuti, ecc.) occorre definire due livelli:

• Un primo livello che identifica il ripristino di un servizio minimo dopo l’interruzione;
• Un secondo livello che sancisce la ripresa dell’attività ordinaria.

Per ogni livello devono essere stabiliti i tempi entro i quali vengono raggiunti e che possono costituire SLA contrattuali.

È bene comprendere che i BCP devono prefigurare uno scenario di crisi ben definito, al verificarsi del quale si vuole reagire in modo adeguato. Chiaramente non tutti gli scenari possibili possono essere gestiti nei BCP, ma solo quelli più probabili e di impatto più grave, sulla base della valutazione dei rischi preliminarmente svolta.

I contenuti dei BCP potrebbero essere i seguenti:

1. Scopo e campo di applicazione
2. Obiettivi
3. Requisiti di business continuity (RPO, RTO,…)
4. Identificazione dei processi critici (MCA’s)
5. Business Impact Analysis
6. Piano di Disaster Recovery
7. Piano di Continuità Operativa, contenente:

• Rilevazione dell’incidente (metodi e procedure): dichiarazione del disastro o incidente, valutazione del danno, attivazione del piano):
• Risposta all’incidente (attività, tempi, responsabilità, procedure);
• Ripristino dell’operatività (attività, tempi, responsabilità, procedure di azione e continuità);
• Risorse (personale e competenze, tecnologie, infrastruttura, software, dati, siti alternativi, centri di emergenza o crisi);
• Fornitori (Lista dei fornitori di recovery, dettagli dei contratti, procedure di attivazione);
• Organizzazione e Responsabilità;
• Documentazione;
• Comunicazioni (contatti, soggetti da informare, messaggi);

1. Test del BCP (prove, tempi, responsabilità)
2. Manutenzione del BCP

Si precisa che i BCP possono far riferimento ad altri documenti (ad es. Piani di Disaster Recovery), aggiornati autonomamente. In ogni caso deve essere sempre possibile risalire alla configurazione attuale del BCP, ovvero alle revisioni vigenti dei documenti esterni richiamati nel Piano di Continuità Operativa. Tale configurazione e la relativa rintracciabilità dei documenti relativi al BCP deve essere disponibile sia in formato elettronico, sia su supporto cartaceo, con gestione di copie di riserva del BCP disponibili in locali/siti/ubicazioni alternative, al fine di essere sempre disponibili in caso di verificarsi dell’evento che ha generato l’interruzione dei processi critici.

Si rammenta che per la Pubblica Amministrazione la continuità operativa ed i relativi Piani di Business Continuity sono previsti dall’Art. 50 bis del Codice per l’Amministrazione Digitale; essa, pertanto, deve essere gestita dagli responsabili degli Enti Pubblici in modo adeguato, con riferimento agli standard internazionali sulla materia.

[Download non trovato]

La norma ISO 27001 pubblicata nel 2013 è stata tradotta in italiano e convertita in norma UNI nel marzo 2014 come UNI CEI ISO/IEC 27001:2014 – Tecnologie informatiche – Tecniche per la sicurezza – Sistemi di gestione per la sicurezza delle informazioni – Requisiti. Essa specifica i requisiti per stabilire, attuare, mantenere e migliorare in modo continuo un sistema di gestione per la sicurezza delle informazioni nel contesto di un’organizzazione, includendo anche i requisiti per valutare e trattare i rischi relativi alla sicurezza delle informazioni adattati alle necessità dell’organizzazione.

La nuova ISO 27001 non riporta termini e definizioni, ma richiama la ISO 27000.2014 (scaricabile gratuitamente da http://standards.iso.org/ittf/licence.html) per tutti i termini utilizzati nelle norme della serie ISO 27k.

Si segnala che nel capitolo introduttivo della ISO 27001 è scomparso il paragrafo “Approccio per processi”, sebbene venga sottolineata l’importanza che il sistema di gestione per la sicurezza delle informazioni sia parte integrante dei processi e della struttura gestionale complessiva dell’organizzazione.

La norma ISO 27001 riprende la nuova struttura di tutte le norme sui sistemi di gestione e, pertanto, al capitolo 4 tratta il “contesto dell’organizzazione”. In questo capitolo viene esposto che per comprendere l’organizzazione e il suo contesto (4.1) occorre determinare i fattori esterni ed interni pertinenti alle finalità dell’organizzazione stessa e che influenzano la sua capacità di conseguire i risultati previsti per il proprio sistema di gestione per la sicurezza delle informazioni e che per comprendere le necessità e le aspettative delle parti interessate (4.2) occorre individuare le parti interessate al sistema di gestione per la sicurezza delle informazioni ed i requisiti delle stesse attinenti ad esso.

Anche la determinazione del campo di applicazione del Sistema di Gestione per la Sicurezza delle Informazioni (SGSI o ISMS, Information Security Management System) è un’attività inerente la comprensione dell’organizzazione ed il suo contesto. In questo ambito l’organizzazione deve determinare i confini di applicabilità del sistema di gestione per la sicurezza delle informazioni ISO 27001 al fine di stabilirne il campo di applicazione, in modo analogo a quanto avveniva nella versione precedente della norma, considerando anche i fattori esterni ed interni ed i requisiti delle parti interessate esposti ai paragrafi precedenti.

Il capitolo 5 “Leadership” rispecchia anch’esso la nuova struttura delle norme sui sistemi di gestione. In esso, al paragrafo 5.1, viene indicato quali modalità l’alta direzione deve attuare per dimostrare leadership e impegno nei riguardi del sistema di gestione per la sicurezza delle informazioni. In analogia con altri sistemi di gestione, l’alta direzione deve stabilire politica ed obiettivi, mettere a disposizione le risorse necessarie per l’attuazione del SGSI, comunicare l’importanza di un’efficace gestione della sicurezza delle informazioni e dell’essere conforme ai requisiti del SGSI stesso; deve, inoltre, assicurare che il SGSI ISO 27001 consegua i risultati previsti, fornire guida e sostegno al personale per contribuire all’efficacia del sistema di gestione della sicurezza delle informazioni e, naturalmente, deve promuovere il miglioramento continuo.

Il paragrafo 5.2 tratta della politica per la sicurezza delle informazioni per la quale i requisiti sono analoghi a quelli presenti negli altri sistemi di gestione: naturalmente la politica deve essere documentata, comunicata all’interno dell’organizzazione ed essere disponibile a tutte le parti interessate.

Anche il paragrafo 5.3 – che riguarda ruoli, responsabilità e autorità nell’organizzazione – è molto simile a quanto riportato nelle altre norme sui sistemi di gestione; in particolare, il fatto che la l’alta direzione debba assegnare responsabilità e autorità per assicurare che il sistema di gestione per la sicurezza delle informazioni sia conforme ai requisiti della norma e per riferire alla direzione stessa sulle prestazioni del sistema di gestione per la sicurezza delle informazioni, se non definisce la nomina di un responsabile per il sistema di gestione della sicurezza delle informazioni poco ci manca. Pur non essendo richiesto un rappresentante della direzione (non lo era neanche nella versione 2005 ISO e 2006 UNI della norma) viene rafforzato il concetto che è necessario assegnare responsabilità precise, all’interno o all’esterno dell’organizzazione (consulente), per garantire la conformità del SGSI.

Il capitolo 6 “Pianificazione” tratta, nel paragrafo 6.1, quali azioni occorre attuare per affrontare rischi ed opportunità. Infatti sulla base di quanto emerso dall’analisi del contesto dell’organizzazione occorre determinare i rischi e le opportunità che è necessario affrontare per assicurare che il sistema possa conseguire i risultati previsti, possa prevenire, o almeno ridurre, gli effetti indesiderati e realizzare il miglioramento continuo. Le azioni per affrontare rischi ed opportunità devono essere pianificate, così come le modalità per integrare ed attuare le azioni stesse nei processi del proprio sistema di gestione per la sicurezza delle informazioni e per valutare l’efficacia di tali azioni.

La valutazione dei rischi relativi alla sicurezza delle informazioni è trattata al paragrafo 6.1.2, dove sono riportati i requisiti per il processo di valutazione del rischio relativo alla sicurezza delle informazioni. Il processo di valutazione del rischio dovrà comprendere le seguenti attività

• Stabilire e mantenere i criteri di rischio relativo alla sicurezza.
• Assicurare che le ripetute valutazione del rischio producano risultati coerenti, validi e confrontabili tra loro (il metodo usato deve essere ripetibile e riproducibile con risultati coerenti come se fosse un dispositivo di misurazione sotto conferma metrologica).
• Identificare i rischi relativi alla sicurezza.
• Analizzare i rischi individuati, valutando le possibili conseguenze che risulterebbero se tali rischi si concretizzassero e valutando la verosimiglianza realistica di concretizzarsi dei rischi identificati, ovvero la probabilità che essi accadono, e, infine, determinando i livelli di rischio.
• Ponderare i rischi comparando i risultati dell’analisi dei rischi con i criteri stabiliti e definendo le priorità di trattamento dei rischi precedentemente valutati.

Naturalmente la valutazione dei rischi deve essere documentata.

Il trattamento del rischio relativo la sicurezza delle informazioni (6.1.3) deve essere definito ed applicato attraverso un processo del tutto similare a quello stabilito nella versione precedente della norma, anche se esposto in modo differente. Oltre a selezionare l’opzione di trattamento dei rischi consuete occorre determinare i controlli necessari per attuare le opzioni selezionate per il trattamento del rischio, tenendo presente controlli riportati nell’appendice A e meglio dettagliati nella norma ISO 27002 (anch’essa tradotta finalmente in italiano come UNI CEI ISO/IEC 27002:2014 – Tecnologie informatiche – Tecniche per la sicurezza – Raccolta di prassi sui controlli per la sicurezza delle informazioni) al fine di non omettere controlli che potrebbero essere necessari.

Resta la necessità di redigere una Dichiarazione di Applicabilità che riporti:

• i controlli selezionati come necessari (che siano attuati o meno) e la relativa giustificazione per l’inclusione;
• i controlli presenti nell’Appendice A della ISO 27001 stessa eventualmente esclusi con le giustificazioni per la loro esclusione
• i controlli selezionati attualmente applicati.

Quest’ultimo punto costituisce una novità nel testo della norma che chiarisce e sancisce una prassi comunemente adottata dagli Organismi di Certificazione, ovvero quella di accettare una dichiarazione di applicabilità di determinati controlli di sicurezza la cui attuazione è stata pianificata, ma deve ancora venire.

Infine occorre predisporre un piano di trattamento dei rischi relativi alla sicurezza delle informazioni che dovrà essere approvato dalla Direzione, comprendente anche l’accettazione dei rischi residui che si è deciso di non trattare.

Anche questo processo di trattamento del rischio dovrà essere documentato.

Il sistema di gestione per la sicurezza delle informazioni ISO 27001 dovrà porsi degli obiettivi e pianificare le azioni adeguate per conseguirli (paragrafo 6.2). Le caratteristiche degli obiettivi sono le stesse degli altri sistemi di gestione (devono essere coerenti con la politica, misurabili, ecc.).

La pianificazione delle azioni poste in essere per conseguire gli obiettivi per la sicurezza delle informazioni deve comprendere le azioni pianificate, le risorse necessarie, le responsabilità, i tempi di completamento delle azioni, e le modalità di valutazione dei risultati.

Il capitolo 7 “Supporto” non presenta novità significative rispetto all’analogo capitolo delle altre norme relative ad altri sistemi di gestione. Pertanto i paragrafi Risorse (7.1), Competenza (7.2) Consapevolezza (7.3) e Comunicazione (7.4) non presentano sorprese di sorta, ma solo una esplicitazione più chiara rispetto al passato di cosa ci si dovrebbe attendere da un sistema di gestione per la sicurezza delle informazioni.

Il paragrafo 7.5 “Informazioni documentate” con i suoi sotto paragrafi descrive i requisiti relativi a documenti e registrazioni, secondo la dizione delle precedenti norme sui sistemi di gestione. Anche in questo caso i requisiti non presentano novità rispetto al passato, ma solo un diverso ordine di esposizione ed una maggior chiarezza nel descrivere che cosa ci si aspetta da un sistema di gestione documentato.

Non sono richieste procedure particolari, né un manuale del sistema di gestione ISO 27001, ma solo le informazioni documentate indicate nei vari punti della norma.

Il capitolo 8 “Attività operative” dispone requisiti relativi ai punti:

• pianificazione e controlli operativi (8.1);
• valutazione del rischio relativo la sicurezza delle informazioni (8.2);
• trattamento del rischio relativo la sicurezza delle informazioni (8.3).

In questo capitolo non ci sono novità rispetto alla versione precedente della norma, ma solo una riscrittura secondo la nuova struttura delle norme sui sistemi di gestione di quanto era già prescritto in passato. I contenuti, in verità, sono alquanto scarni, infatti viene prescritto di mantenere sotto controllo i processi operativi dell’organizzazione (processo produttivo o erogazione del servizio, approvvigionamenti, commerciale, ecc.) attraverso l’attuazione di tutti i controlli di sicurezza pianificati, monitorando ogni cambiamento e rivalutando periodicamente i rischi secondo le modalità già descritte nei paragrafi deò capitolo 6.

Il capitolo 9 “Valutazione delle prestazioni”, riporta i requisiti per il monitoraggio, la misurazione, l’analisi e la valutazione (9.1) del SGSI, per gli audit interni (9.2) e per il riesame della direzione (9.3). Anche in questo capitolo non sono presenti novità sostanziali rispetto alla precedente versione della norma, ma solo una riscrittura del testo in modo più chiaro. In particolare viene indicata la necessità di monitorare e misurare l’efficacia dell’attuazione dei controlli di sicurezza e tutti i processi che forniscono evidenza del buon funzionamento del SGSI.

Nel capitolo 10 “Miglioramento” sono trattate non conformità, azioni correttive e miglioramento continuo. Anticipando quello che avverrà per la prossima versione della norma ISO 9001:2015, si rileva l’eliminazione delle requisito riguardante le azioni preventive che vanno a confluire insieme a tutte le azioni di miglioramento non legate a non conformità o incidenti sulla sicurezza delle informazioni.

È curioso il fatto che mentre nella versione precedente la norma ISO 27001 non dedicava un paragrafo alle non conformità, che venivano citate nel testo, ma erano citati anche gli incidenti per la sicurezza delle informazioni, questa nuova versione non tratta gli incidenti – se non nei controlli dell’appendice A – e dedica il paragrafo 10.1 alle non conformità ed alle azioni correttive attuate per eliminarle.

Si ricorda che ACCREDIA ha disposto che Tutte le certificazioni emesse sotto accreditamento a fronte della ISO/IEC 27001:2005 dovranno essere ritirate entro il 1° ottobre 2015; oltre tale data potranno sussistere solo certificazioni secondo la nuova ISO 27001:2013. Pertanto restano pochi mesi per convertire i vecchi SGSI alla nuova norma. Probabilmente la stragrande maggioranza delle organizzazioni con SGSI certificato o certificando ISO 27001 dispongono già della certificazione ISO 9001 per la qualità, ma la nuova norma ISO 9001:2015, la cui struttura è allineata alla ISO 27001:2013 deve ancora essere ufficialmente emessa.

Il consiglio per le organizzazioni che si stanno adeguando alla 27001:2013 è quello di strutturare il sistema di gestione integrato secondo il nuovo schema, dunque allineare anche il sistema di gestione per la qualità sulla base delle indicazioni disponibili dalla bozza di ISO 90001:2015. Così facendo si avrà un sistema di gestione integrato ISO 9001-27001 omogeneo e meglio gestibile nell’immediato.

Questo probabilmente comporterà ristrutturare il manuale del sistema di gestione, anche se non esplicitamente richiesto dalla nuova norma, al fine di mantenere una continuità con il passato e garantire il controllo su tutta la documentazione del sistema di gestione.

Le modifiche al SGSI non sono sostanziali e riguardano più che altro i 114 controlli di sicurezza dell’appendice A e della ISO 27002 che naturalmente impattano sul trattamento dei rischi e sulla Dichiarazione di Applicabilità (Statement of Applicability, SoA).

La privacy dei privati cittadini utenti delle farmacie e dei piccoli ambulatori privati spesso è messa a repentaglio da una gestione non accurata delle regole stabilite dalla normativa al riguardo (D.Lgs 196/2003 – “Codice per la protezione dei dati personali”) e da tutte le buone pratiche di gestione della sicurezza delle informazioni.

I titolari di farmacie ed ambulatori medici polifunzionali sono di fatto legali rappresentanti di imprese che, seppur di piccole dimensioni, raccolgono e gestiscono dati personali sensibili (in particolare dati sanitari relativi alla salute delle persone) di una grande moltitudine di persone fisiche e, come tali, sono tenuti a rispondere di fronte alla legge di tali gestioni.

In questi ultimi anni si è passati da una gestione prevalentemente cartacea dei dati personali sensibili raccolti da queste organizzazioni, ad una gestione elettronica di molte informazioni che riguardano la sfera privata delle persone, ovvero i dati sanitari.

Se pensiamo ad una farmacia moderna possiamo trovare molti trattamenti di dati in formato digitale che solo pochi anni fa non erano presenti: si passa dal ben noto scontrino fiscale parlante (sul quale ha molto disquisito il Garante della Privacy), generato e poi gestito da un sistema informatico, alla ricetta elettronica di recente introduzione, passando per una serie di servizi che le farmacie hanno introdotto da pochi anni: intolleranze alimentari, analisi della pelle, gestione referti esami diagnostici, preparazione di diete, fidelity card, e-commerce, ecc.. Ma anche servizi meno recenti come le prenotazioni di esami tramite CUP ASL o la Dispensazione per Conto vengono gestiti dalle farmacie, attraverso appositi portali dedicati, per conto dei clienti.

Ognuno di questi trattamenti di dati presenta vulnerabilità intrinseche per la sicurezza delle informazioni trasmesse: credenziali di accesso non sufficientemente difficili da individuare, scarsa protezione dei PC e dei Server da attacchi esterni, inadeguata protezione dei medesimi elaboratori in caso di furto e via dicendo.

Come le piccole organizzazioni di altri settori industriali o dei servizi, anche le farmacie non sono dotate di personale esperto nella gestione della sicurezza dei sistemi informatici e spesso il coinvolgimento dei fornitori esterni specializzati non è così sistemato (soprattutto per motivi di costo) da poter garantire una protezione adeguata.

D’altro canto dai computer delle farmacie transitano quantità di dati sensibili di gran linga superiori a quelle di altre piccole organizzazioni e costituiscono il canale di consultazione di archivi di prenotazione di esami diagnostici di un elevatissimo numero di pazienti. Da qui la necessità di proteggere i sistemi informatici delle farmacie, sia da un punto di vista logico, sia fisico, in modo molto più attento rispetto ad un normale PC aziendale.

Anche i piccoli ambulatori privati, che ospitano medici che eseguono visite specialistiche ed esami diagnostici, ultimamente hanno trovato grande beneficio dall’utilizzo delle nuove tecnologie, nonostante la ritrosia all’utilizzo del computer da parte di numerosi medici. Tutto ciò, però, comporta la necessità di proteggere adeguatamente i dati sensibili dei pazienti che transitano in formato digitale in reti locali poco protette. In tali organizzazioni spesso non è nemmeno chiaro chi è il titolare del trattamento dati – il medico che visita il paziente o il centro medico – ed a chi vengono eventualmente delegate le responsabilità per i trattamenti delegati ad altri.

In generale, nelle farmacie e nei piccoli centri medici, tutta la “parte informatica” è delegata a fornitori specializzati che talvolta non conoscono in modo preciso la normativa sulla privacy e sono negligenti nel sottoscrivere le proprie assunzioni di responsabilità a fronte delle attività eseguite; conseguentemente tutte le responsabilità ricadono sul titolare del trattamento, persona fisica o giuridica avente comunque un legale rappresentante, generalmente poco avvezzo a questioni informatiche.

Dal punto di vista normativo, poi, il passaggio da una normativa italiana – molto completa e severa per taluni aspetti, ma ormai obsoleta per quanto riguarda il disciplinare tecnico delle misure minime di sicurezza – ad un nuovo Regolamento Europeo in fase di approvazione, non fa che complicare le cose per le piccole organizzazioni che finora hanno avuto regole precise (password di almeno 8 caratteri variate ogni 3 mesi se si trattano dati sensibili, backup almeno ogni 7 giorni, aggiornamenti semestrali dei programmi software, assenza di idonee dichiarazioni di conformità dei fornitori, ecc.) con le quali confrontarsi. Il nuovo Regolamento, infatti, introdurrà la necessità di valutare i rischi che si corrono dal punto di vista della sicurezza dei dati personali e, conseguentemente, progettare il sistema di gestione della privacy in funzione delle reali esigenze di riservatezza, adottando misure di sicurezza adeguate (non solo “minime”).

Inoltre l’attuale versione del Regolamento Europeo sulla Privacy in approvazione contiene l’obbligo per i titolari di dati personali di dotarsi – entro determinate condizioni – di un “Privacy Officer”, ovvero di una persona, dotata di adeguate competenze in materia di privacy e sicurezza dei dati, responsabile per la gestione della privacy all’interno dell’organizzazione. Ma il limite attualmente stabilito per l’obbligo di nominare un Privacy Officer è legato al numero di dati personali gestiti (più di 5000 in un anno) che viene facilmente superato da una farmacia di medio volume di affari, ma non da numerose imprese industriali con oltre 50 dipendenti.

La ratio del nuovo Regolamento UE è evidentemente quella di garantire migliore protezione dove esistono maggiori rischi, sia per il numero di dati personali trattati, sia per la vulnerabilità dei sistemi.

Il cambio di mentalità di chi gestisce piccole organizzazioni nel settore sanitario non sarà facile, anche perché non ci saranno più regole precise da seguire per stare tranquilli, ma, oserei dire giustamente, il Regolamento Europeo ribalterà la responsabilità di progettare un sistema di gestione della privacy adeguato sulle spalle degli imprenditori. Molti di questi ultimi non saranno in grado di valutare in modo competente ed oggettivo quali misure adottare e dovranno fare attenzione a non credere alle “ricette preconfezionate” a basso costo che hanno già rovinato l’approccio alla privacy negli anni del ben noto DPS (Documento Programmatico sulla Sicurezza).

Già oggi il rischio di molte piccole organizzazioni del settore sanitario è quello di non essere conformi alla legislazione attuale sotto diversi aspetti (mancate nomine degli incaricati, mancanza di credenziali di autenticazione ai sistemi informatici adeguate e variate periodicamente, utilizzo troppo invasivo della videosorveglianza, archiviazione di dati privi di protezione, ecc.), figuriamoci domani se saranno i titolari del trattamento (ovvero i legali rappresentanti o direttori delle organizzazioni) a dover decidere quali misure di sicurezza sono adeguate! Il rischio concreto è quello di sottovalutare il problema privacy, come del resto è avvenuto dopo l’abolizione del DPS che non ha abolito tutti gli altri adempimenti!

Dimenticarsi di proteggere adeguatamente i dati personali dei propri clienti può comportare non solo sanzioni civili (e in alcuni casi anche reati penali) in caso di ispezione da parte del nucleo Privacy della Guardia di Finanza (oggi peraltro molto rare), ma anche, in caso di richiesta di risarcimento danni da parte dell’interessato i cui dati sensibili sono stati violati, ingenti perdite economiche. Talvolta, poi, la mancata diligenza del titolare del trattamento potrebbe portare anche al divieto di intraprendere relazioni commerciali con la Pubblica Amministrazione, riducendo o annullando di fatto la possibilità di operare.

Infine, oltre agli aspetti legati al rispetto della normativa cogente, esistono altri pericoli a cui è sottoposta una organizzazioni che gestisce in modo inconsapevole la sicurezza dei dati, ad esempio la perdita di dati e l’indisponibilità di risorse per garantire la continuità del servizio al cliente e, quindi, perdite economiche più o meno rilevanti in funzione della gravità dell’evento.

La Regione Emilia Romagna ha pubblicato un nuovo bando per il finanziamento di Progetti per l’ICT nelle piccole e medie imprese (Asse 2:Sviluppo innovativo delle imprese – Scadenza: 31/03/2015 – Attività II.1.1 Sostegno a progetti di introduzione di ict nelle pmi. Bando per piccole e medie imprese).

Abbiamo già parlato in un precedente articolo della fatturazione elettronica che è divenuta obbligatoria dallo scorso 6 giugno per fatture emesse nei confronti di alcuni Enti della Pubblica Amministrazione e che andrà ad estendersi a tutta la P.A. entro marzo 2015. Vorrei, in queste righe, riprendere quanto discusso – a volte anche animosamente – nel bel convegno organizzato dall’Ordine degli Ingegneri di Bologna lo scorso 5 giugno.

Quello che si è sentito in quell’occasione, ma anche in altri tavoli e platee, è una sorta di insurrezione popolare contro questa novità che sembra imporre maggiori oneri anche a piccole organizzazioni (ad es. Studi professionali) che hanno rapporti, magari occasionali, con la P.A..

Tutto questo amore per la carta e la fattura cartacea nei confronti dell’equivalente elettronico (di fatto un file XML) che sa di vintage, ma che non porta veri vantaggi all’impresa, è del tutto ingiustificato. Se mi è permesso un paragone non dobbiamo rimpiangere i dischi in vinile degli anni ’70 rispetto ai CD o alla cosiddetta “musica liquida”, ma la musica degli anni ’60-’70-’80 rispetto a quella dei giorni nostri… Analogamente rimpiangeremo, forse, i contenuti (gli importi) delle fatture su carta, ma avremo solo vantaggi dalla fattura elettronica.

Se la fattura elettronica non è qualcosa di fantascientifico ed inquietante, non è dunque un X-Files su cui gli agenti Fox Mulder e Dana Scully dell’FBI del famoso telefilm degli anni ’90 dovrebbero indagare, ma “semplicemente” un XML-File, generabile con applicazioni dalle interfacce amichevoli e reperibili con sempre maggiore facilità, anche a costi contenuti o addirittura gratis.

Una volta creata la cosiddetta Fattura PA conforme agli standard previsti dalle Regole Tecniche emesse dall’Agenzia per l’Italia Digitale (AGID, http://www.agid.gov.it/, ex DigitPA, ex CNIPA). Occorrerà firmarla digitalmente (con firma digitale che ormai tutte le imprese dovrebbero possedere e se non ce l’hanno se la procurino perché fa risparmiare tempo e denaro) ed inviarla via PEC (posta elettronica certificata, anch’essa ormai dovrebbe essere utilizzata da quasi tutte le imprese perché è utile e fa risparmiare anch’essa) al Cliente Pubblica Amministrazione.

Dopodiché viene il passo più difficile: la fattura elettronica va conservata in formato digitale, attraverso un apposito sistema di Conservazione Sostitutiva. Questo passo del processo – reso obbligatorio dalla normativa al riguardo – appare un po’ più ostico perché la conservazione sostitutiva richiede procedimenti più complessi e software che operi in conformità alle Regole Tecniche emesse (ed eventualmente aggiornate) dall’AGID, oltre alla nomina di un Responsabile dell’Archiviazione Sostitutiva, con determinate caratteristiche e competenze, che garantisca tutto il processo e lo validi mediante propria firma digitale. Tra l’altro la gestione dei supporti di memorizzazione richiede una certa ridondanza e garanzia di disponibilità delle informazioni per i tempi prescritti dalla legge per le registrazioni relative.

In pratica, non essendo percorribile la strada di una gestione “fai da te” da parte dell’impresa (gli applicativi di Conservazione Sostitutiva open-source o freeware non esistono e svilupparseli in casa è molto impegnativo), le opzioni che si presentano alle organizzazioni che devono emettere fattura nei confronti della P.A. (anche solo una fattura all’anno) sono due:

1. Acquistare un software per la gestione della fatturazione elettronica e della conseguente conservazione sostitutiva delle fatture.
2. Rivolgersi a servizi in outsourcing – generalmente accessibili via web – per la fatturazione elettronica e conservazione sostitutiva.

La scelta dipende da diversi fattori:

• Quante fatture PA vengono emesse rispetto al totale delle fatture?
• Come si svolge il processo di fatturazione e la gestione contabile successiva?
• L’organizzazione potrebbe trarre vantaggi nell’introduzione di una gestione documentale digitalizzata e di una conservazione sostitutiva su tutto il ciclo attivo e passivo?
• Di quali risorse hardware e software dispone l’organizzazione per poter gestire internamente il processo di archiviazione sostitutiva?
• Di quali software gestionali per contabilità e fatturazione dispone l’organizzazione?
• La contabilità è gestita interamente all’interno dell’azienda oppure ci si rivolge ad uno Studio di Commercialista o ad altra società di servizi fiscali?
• Come si svolge l’attività dell’organizzazione ed i relativi processi amministrativi? Ci sono più sedi? L’Amministrazione è centralizzata? Chi può emettere le fatture?
• Ecc., ecc.

Se, infatti, per alcune realtà il costo di implementare una fatturazione elettronica ed una conservazione sostitutiva internamente, magari introducendo una gestione documentale informatizzata anche per altri processi aziendali (vedi articolo precedente), può portare in pochi anni un buon ritorno dell’investimento, per altre organizzazioni, per lo più di piccole dimensioni e con poche fatture PA emesse, la soluzione di esternalizzare tutto il processo di fatturazione – oppure solo quello verso la P.A. – può costituire una soluzione ottimale.

Diversi fornitori si stanno proponendo sul mercato con le proprie soluzioni, in-house ed in outsourcing tramite servizi cloud.

La scelta della soluzione migliore per la propria organizzazione deve essere molto attenta, non solo per non spendere cifre eccessive per il servizio di fatturazione elettronica su qualche decina di fatture PA, ma, soprattutto, per non vincolarsi in soluzioni poco espandibili in futuro e poco integrate o integrabili con gli altri applicativi circostanti presenti in azienda.

Occorre pertanto valutare quali miglioramenti possono essere apportati da una gestione completamente elettronica del processo di fatturazione (e relativa conservazione sostitutiva) che, in taluni casi, potrebbe evitare il reinserimento della fattura nei sistemi contabili in quanto i servizi di fatturazione elettronica forniscono generalmente il flusso dei dati inseriti pronto per essere importato nel proprio gestionale. Su quest’ultimo aspetto è bene fare attenzione: se il proprio software contabile (o quello del proprio Commercialista) non è compatibile con il tracciato record della fattura PA e non ha intenzione di adeguarsi per il futuro, probabilmente è il momento di cambiarlo perché il fornitore non ha voglia di investire su di esso.

Alcune funzioni fornite dai servizi in outsourcing, ed i relativi costi, possono far privilegiare una soluzione rispetto ad un’altra per i vantaggi in termini di efficienza che può portare all’organizzazione.

Che dire poi sui rischi, reali o presunti, che si corre a lasciare le proprie fatture elettroniche, le uniche versioni valide ai fini di legge (eventuali stampe o versioni in formato pdf non sono valide ai fini legali nei confronti delle Autorità Tributarie)? Nella maggior parte dei casi tali fatture sono molto più sicure che negli archivi cartacei o digitali di molte imprese e dei loro Commercialisti, ma occorre comunque fare una attenta valutazione dei rischi, declinando la sicurezza della fattura elettronica in termini riservatezza (vogliamo che altri non conoscano i dati delle nostre fatture?), integrità (le fatture elettroniche saranno sempre corrette ed integre?) e disponibilità (ne possiamo disporre a piacimento, in tempi ridotti, anche a fronte di accertamenti fiscali?).

Su questi aspetti occorrerà valutare cosa garantiscono i fornitori dei servizi di fatturazione elettronica in cloud, sia formalmente nel contratto di fornitura del servizio in cloud computing (vedi precedenti articoli), sia in base ad una valutazione oggettiva dell’azienda fornitrice: è certificata ISO 9001 per il suo sistema di gestione qualità? È certificata ISO 27001 per la sicurezza delle informazioni? Gestisce la business continuity (continuità operativa) con appositi piani? È certificata ISO 22301 per i sistemi di gestione di business continuity?

In conclusione l’introduzione della fatturazione elettronica in azienda, almeno per le fatture verso la Pubblica Amministrazione, non sarà sicuramente a costo zero, ma produrrà costi per investimenti in tecnologia e formazione del personale, ma potrà generare risparmio di tempo – e quindi di costi – nel futuro nei processi correlati. Una progettazione competente dell’adeguamento potrà portare sicuramente vantaggi futuri, viceversa la ricerca della soluzione gratis, oppure a costi minimi, rischia di generare solo costi inutili e di non eliminare inefficienze, bensì di crearne di nuove.

In ogni caso farà risparmiare la Pubblica Amministrazione, quindi tutti noi.

Vedi anche:

• Fatturazione elettronica: online la circolare interpretativa del DM 55/2013
• Fattura elettronica: online l’aggiornamento delle Specifiche operative AgID