You are here

Home

Governance e flussi informativi – come cambia il mestiere del Security Manager

Mer, 05/03/2008 - 07:59 — Agatino Grillo

 Ieri 4 marzo 2008 la Banca d'Italia ha emanato le nuove disposizioni di vigilanza in materia di organizzazione e governo societario delle banche (pdf, 575 K, 16 pp), disposizioni commentate qui  da Cristina Cellucci per Compliancenet. Un capitolo di tali disposizioni riguarda i "flussi informativi” (capitolo 5, pag, 15) ove si legge: "le banche devono porre specifica cura nello strutturare forme di comunicazione e di scambio di informazioni complete, tempestive e accurate tra gli organi con funzioni di supervisione strategica, di gestione e di controllo, in relazione alle competenze di ciascuno di essi, nonché all’interno di ciascun organo; presidi organizzativi andranno approntati per evitare il rischio di divulgazione impropria di notizie riservate. (...) La predisposizione di flussi informativi adeguati e in tempi coerenti con la rilevanza e la complessità delle informazioni è necessaria anche per la piena valorizzazione dei diversi livelli di responsabilità all’interno dell’organizzazione aziendale." Detto in altri termini aumenterà, almeno nelle istituzioni finanziarie (gruppi bancari ed assimilabili) l'attenzione alla riservatezza, integrità e disponibilità delle informazioni necessarie per un corretto governo societario. In una parola: serve IT Governance.

Un nuovo quadro di riferimento per la security aziendale

Il Security Manager deve inoltre tenere presente che la recente ratifica della Convenzione del Consiglio d’Europa sulla criminalità informatica estende la responsabilità amministrativa delle imprese (decreto legislativo 231/01) anche ai cosiddetti "reati informatici" (qui  un'analisi più dettagliata del provvedimento); in poche parole: i vertici aziendali (gli stessi di cui al punto precedente se siamo in una istituzione finanziaria) chiameranno il Security Manager e gli chiederanno di adeguare il "modello organizzativo e di controllo" aziendale alle nuove esigenze.

Privacy e Compliance

La complessità del nuovo quadro normativo entro cui deve muoversi il responsabile della sicurezza delle informazioni obbliga quest'ultimo a muoversi in stretto contatto con le altre funzioni aziendali dedicate al controllo. Da questo punto di vista la partnership privilegiata dovrebbe essere (là dove la figura è prevista) con il Compliance Officer. Bene scrive Panfilo Marcelli nel suo "Privacy e Compliance: di cosa occorre tenere conto nell'aggiornamento del DPS". Nella redazione del Documento Programmatico sulla Sicurezza (DPS) ai sensi del "Codice in materia di protezione dei dati personali" non si può non ragionare che in un'ottica di più vasta conformità alle norme, siano esse leggi, regolamenti di mercato o procedure interne all'azienda stessa e quindi secondo un approccio tipico della Compliance. È del tutto inutile, specie in aziende di medie e grandi dimensioni e sicuramente in imprese bancarie o finanziarie, limitarsi a riportare nel DPS uno sterile elenco delle misure di sicurezza (lunghezza della password, tipo di antivirus utilizzato, eccetera). Occorre invece dare un quadro sinottico del “governo” delle tecnologie (IT Governance) e dei controlli per permettere al Titolare (il legale rappresentante dell'azienda) di poter affermare, quando relaziona al Consiglio di Amministrazione dell'avvenuta redazione del DPS come previsto dal punto 26 dell'allegato B del "Codice".

Che fare?

Credo che la cosa più importante sia in primis avere una corretta rappresentazione dei sistemi informativi con indicazione dei possibili punti di debolezza. Come si fa? Lascio la parola al Garante per la protezione dei dati personali (provvedimento del 17 gennaio 2008 sulla "Sicurezza dei dati di traffico telefonico e telematico"): I sistemi informativi (utilizzati per il trattamento dei dati di traffico) devono essere documentati in modo idoneo secondo i princìpi dell'ingegneria del software, evitando soluzioni documentali non corrispondenti a metodi descrittivi standard o di ampia accettazione. La descrizione deve comprendere, per ciascun sistema applicativo, l'architettura logico-funzionale, l'architettura complessiva e la struttura dei sistemi utilizzati per il trattamento, i flussi di input/output dei dati di traffico da e verso altri sistemi, l'architettura della rete di comunicazione, l'indicazione dei soggetti o classi di soggetti aventi legittimo accesso al sistema. La documentazione va corredata con diagrammi di dislocazione delle applicazioni e dei sistemi, da cui deve risultare anche l'esatta ubicazione dei sistemi nei quali vengono trattati i dati per le finalità di accertamento e repressione di reati. La documentazione tecnica deve essere aggiornata e messa a disposizione dell'Autorità su sua eventuale richiesta, unitamente a informazioni di dettaglio sui soggetti aventi legittimo accesso ai sistemi per il trattamento dei dati di traffico.
Buon lavoro a tutti.

Articoli collegati in questo sito

Ultimi articoli sulla sicurezza:

Ultimi articoli sulla compliance:

Link

Vota quest'articolo

Ti è piaciuto l'articolo? Votalo su Oknotizie 

AG-Vocabolario: 
Sicurezza
Compliance