Quando esamino il quadro di rischio di un’organizzazione, c’è una domanda a cui quasi nessuno sa rispondere subito: sai quali delle condotte che oggi gestisci come “cattiva prassi interna” sono anche reati tipizzati? La Legge 26.388 dell’Argentina ha tracciato quella linea più di quindici anni fa. Eppure continua a vivere, nella maggior parte dei quadri di governance, come una questione delegata all’area legale e non come ciò che è anche: un input diretto per la progettazione dei controlli.
Lavoro in governance, rischio e conformità (GRC), non in diritto penale. Per questo non mi interessa ripercorrere la legge articolo per articolo, ma guardarla dal punto in cui diventa rilevante per chi gestisce un’organizzazione: il momento in cui una condotta smette di essere una violazione della politica interna e diventa un fatto che il Codice Penale prende in considerazione. Dal quadro verso l’operatività, quindi: cosa ha riformato la Legge 26.388, quali controlli del tuo programma vengono messi sotto pressione quando quelle condotte si verificano, e cosa deve avere previsto la tua governance del rischio per non improvvisare il giorno in cui accade.
Cosa regola la Legge 26.388 e perché interessa al tuo quadro di governance?
La Legge 26.388, emanata nel 2008, non è una legge a sé stante: ha riformato il Codice Penale argentino per incorporare i cosiddetti reati informatici. Invece di creare uno statuto separato, ha equiparato condotte del mondo digitale a figure penali esistenti e ne ha aggiunte di nuove. Tra le principali: l’accesso illegittimo a un sistema o dato informatico (articolo 153 bis), la violazione delle comunicazioni elettroniche come la posta (articoli 153 e 155), la frode informatica mediante manipolazione di sistemi (articolo 173, comma 16), il danno informatico, che comprende alterare o distruggere dati e distribuire programmi dannosi (articoli 183 e 184), e la distribuzione di materiale di abuso sessuale su minori tramite mezzi elettronici (articolo 128).
Per un responsabile della sicurezza o della conformità, il dato rilevante non è la pena. È che la legge ha dato un nome penale a un insieme di condotte che il tuo programma già conosce con un altro vocabolario. Ciò che chiami “condividere le credenziali”, “accesso indebito”, “manipolazione di un sistema” o “introduzione di malware” ha, dal 2008, una seconda lettura. Quella doppia natura, violazione interna e reato, è esattamente ciò che obbliga a portare la Legge 26.388 sul tavolo della governance del rischio e non solo sulla scrivania dell’avvocato.
Conviene un chiarimento di criterio prima di procedere: la qualificazione penale di un fatto concreto è lavoro di specialisti del diritto. Il mio terreno, e quello di chiunque si occupi di GRC, è un altro. È assicurare che l’organizzazione disponga dei controlli, delle politiche e delle registrazioni necessarie affinché quella condotta sia meno probabile, resti documentata quando si verifica e possa essere gestita senza lasciare l’azienda esposta per aver improvvisato.
Dalla politica di uso accettabile al rischio penalizzato: quali controlli vengono messi sotto pressione?
L’utilità pratica della Legge 26.388 per la governance del rischio emerge quando la si legge al contrario. Invece di chiedersi “cosa punisce la legge”, conviene chiedersi “quale dei miei controlli affronta ciascuna di queste condotte”. Lì la norma smette di essere un testo legale e diventa una mappa di esposizione.
L’incrocio è diretto. Ogni condotta che la legge prende in considerazione ha, dal lato dell’organizzazione, un controllo che la previene o la rileva e una componente di cybersecurity awareness che la sostiene. Quando quel controllo fallisce o non esiste, non si apre solo una lacuna operativa: si apre una lacuna che può avere conseguenze penali per persone concrete e reputazionali per l’organizzazione.
| Condotta prevista dalla Legge 26.388 | Rischio organizzativo tipico | Controllo e awareness che lo affronta |
|---|---|---|
| Accesso illegittimo a sistemi o dati (art. 153 bis) | Credenziali condivise, accessi non revocati dopo l’uscita, escalation di privilegi | Gestione degli accessi, revisione periodica dei permessi, politica di uso accettabile e awareness sul non condividere le credenziali |
| Frode informatica (art. 173, comma 16) | Manipolazione di sistemi per frodare, frode del CEO, alterazione di registri | Segregazione dei compiti, doppia convalida delle operazioni sensibili, awareness su ingegneria sociale e richieste urgenti |
| Danno informatico e programmi dannosi (artt. 183 e 184) | Introduzione di malware, cancellazione o alterazione di dati, sabotaggio | Gestione dei cambiamenti, copie di backup, controllo del software, awareness su allegati ed eseguibili |
| Violazione delle comunicazioni elettroniche (artt. 153 e 155) | Intercettazione o divulgazione indebita di email e messaggi | Classificazione delle informazioni, politica di riservatezza, controllo degli inoltri, awareness sulla gestione di dati di terzi |
La tabella non esaurisce la legge, ma ordina la conversazione. Ciò che mostra è che la Legge 26.388 quasi mai richiede un controllo nuovo: richiede che quelli che hai già funzionino e, soprattutto, che tu possa dimostrare che esistevano ed erano stati comunicati. La Legge 25.326 sulla protezione dei dati impone quella logica di evidenza in modo esplicito; la Legge 26.388 la impone in modo indiretto, attraverso il rischio che una condotta della tua organizzazione finisca analizzata sotto il Codice Penale.
Cosa deve avere documentato la tua organizzazione?
Se una condotta può essere letta in chiave penale, la domanda di governance è sempre la stessa: cosa aveva l’organizzazione per prevenirla e cosa può mostrarne? Tre blocchi di documentazione risolvono la maggior parte dei casi.
Il primo è la politica di uso accettabile, vigente, comunicata e accettata in modo verificabile. Non basta che esista in una cartella. Deve indicare con chiarezza cosa è permesso e cosa non lo è rispetto all’accesso ai sistemi, all’uso delle credenziali, alla gestione di informazioni di terzi e all’installazione di software. E deve poter dimostrare che ogni collaboratore l’ha conosciuta e accettata, rispetto a quale versione e in quale data.
Il secondo è l’evidenza della formazione di awareness. Il fatto che le persone sappiano che certe azioni non sono solo una violazione della politica interna, ma condotte che la legge considera reato, cambia il calcolo di chi potrebbe commetterle e protegge chi potrebbe incorrervi per ignoranza. Affinché quella conoscenza sia un controllo reale, deve essere registrata: chi si è formato, su quale contenuto, quando e con quale esito. Il rischio umano resta il fattore che origina più incidenti, e la cybersecurity awareness è il controllo che agisce prima che la condotta si verifichi.
Il terzo è la registrazione tecnica dei controlli di accesso e di cambiamento: log di accesso, gestione dei privilegi, tracciabilità delle modifiche. Questo blocco tende a essere il più solido nelle organizzazioni mature e il più debole in quelle cresciute in fretta senza formalizzare la propria governance.
Piattaforme come SMARTFENSE risolvono il secondo blocco per progettazione: ogni accettazione di politica, ogni completamento di un modulo e ogni superamento di una valutazione resta registrato con data, autenticazione dell’utente e versione del contenuto. Per un responsabile della conformità, questo trasforma la awareness da buona intenzione in un controllo che si può auditare. La sezione risorse di conformità contiene materiale aggiuntivo su come articolare il quadro legale con il programma di awareness.
Quando denunciare è una decisione di governance, e non solo legale?
Qui conviene essere precisa sul limite del mio ruolo. La decisione giuridica di avviare un’azione penale, come formularla e con quale qualificazione, spetta all’area legale e agli specialisti che l’organizzazione designa. Ciò che invece è una decisione di governance, e quindi deve essere previsto prima dell’incidente, è il criterio e il processo che portano a quell’istanza.
Un’organizzazione senza quel criterio definito improvvisa nel momento peggiore. Di fronte a un accesso illegittimo o a una frode interna, le domande si accumulano: chi decide se questo sale al piano penale? Con quale soglia? Chi preserva le informazioni mentre si decide? A quale area si notifica per prima? Se quelle risposte si costruiscono al momento, l’organizzazione perde tempo, perde tracciabilità e spesso perde la possibilità di agire.
La governance del rischio non risolve il caso penale. Definisce chi decide, con quali criteri e con quali informazioni disponibili. Questo si documenta in una procedura di gestione degli incidenti che contempli, oltre alla risposta tecnica, il percorso decisionale per quando un fatto potrebbe avere implicazioni penali. Il “come” giuridico resta nelle mani di chi compete; il “quando si attiva e chi lo attiva” è responsabilità della governance.
Il confine tra il disciplinare e il penale
Buona parte dei fatti che la Legge 26.388 prende in considerazione nasce all’interno dell’organizzazione. Un collaboratore che accede a un sistema per cui non è autorizzato, che inoltra informazioni riservate o che manipola un registro sta, allo stesso tempo, violando la politica interna e realizzando una condotta che la legge penale prende in considerazione. Distinguere quei due piani è uno dei compiti più delicati della governance del rischio.
Il piano disciplinare lo risolve l’organizzazione con i propri strumenti: la politica, il regolamento interno, le conseguenze previste per ogni violazione. Il piano penale eccede l’organizzazione ed è regolato dalla legge e dall’attività di chi la applica. Confonderli genera due errori opposti ed entrambi costosi. Trattare come semplice violazione interna qualcosa che la legge considera reato può lasciare l’organizzazione esposta. Trattare come caso penale ogni violazione minore logora il clima di lavoro e satura l’area legale con fatti che si risolvevano con un controllo meglio progettato.
La via d’uscita non è giuridica, è di criterio preventivo. Una matrice che classifichi i tipi di incidente secondo la loro gravità e definisca, per ogni livello, quale risposta è appropriata e chi la decide, evita quella confusione. Non è un documento legale: è uno strumento di governance che dà all’organizzazione un linguaggio comune per decidere a mente fredda ciò che, a caldo, si decide quasi sempre male.
Continuità operativa dopo un incidente con implicazioni penali
Un incidente che passa al piano penale non finisce quando viene contenuto tecnicamente. In realtà inizia una fase che molte organizzazioni non hanno mappato: la convivenza tra il continuare a operare e il sostenere un processo che può estendersi nel tempo. Preservare le informazioni senza fermare l’operatività, comunicare alle parti adeguate senza alimentare il rumore, e mantenere il servizio mentre si gestisce il caso sono sfide di continuità, non di risposta agli incidenti.
Per questo insisto, ogni volta che esamino un quadro, sul fatto che la Legge 26.388 non si gestisce il giorno del fatto. Si gestisce prima, nella progettazione dei controlli, nella chiarezza delle politiche, nella tracciabilità della awareness e in una procedura che contempli la possibilità che un incidente faccia escalation. Un’organizzazione che arriva preparata a quel momento non solo riduce la propria esposizione: protegge la propria capacità di continuare a funzionare, che è, in fondo, ciò di cui tratta la governance del rischio.
L’articolazione tra quadro legale e cultura della sicurezza non è esclusiva dell’Argentina. La legge quadro sulla cybersecurity in Cile e il dibattito normativo in tutta la regione spingono nella stessa direzione: trattare la awareness come un controllo formale e non come un’attività di riempimento. La conformità normativa intesa come impegno sostenuto è la migliore descrizione della direzione verso cui va l’esigenza.
Cosa trarre dalla Legge 26.388 per la governance del rischio?
La Legge 26.388 è in vigore da più di quindici anni, e la sua maggiore utilità per un’organizzazione non sta nel timore della pena. Sta nel fatto che offre una mappa delle condotte che il quadro di governance deve affrontare con controlli concreti, politiche chiare ed evidenza che entrambi esistano.
La domanda che vale la pena portarsi via non è se la tua organizzazione potrebbe subire un reato informatico, perché la risposta è che sì. È se la tua governance del rischio ha previsto quali controlli lo prevengono, chi decide quando un fatto fa escalation e cosa può dimostrare l’organizzazione il giorno in cui dovrà rispondere. Se quelle risposte oggi si costruiscono al momento, quello è il lavoro da fare. Non per evitare una sanzione, ma per sostenere la fiducia di clienti, regolatori e direzione, che è la condizione di fondo della continuità operativa.
Lascia un commento