La corsa a ostacoli della transizione digitale

Partiamo dal “generale”

Lo sappiamo, la transizione digitale è un punto fermo del Piano Nazionale di Ripresa e Resilienza (PNRR)[i]: se non si compie, arriveranno meno soldi dall’Unione Europea e, questione più grave, l’Italia rimarrà indietro economicamente e socialmente.

Tuttavia, la transizione digitale è un tema che il nostro legislatore ha a cuore da anni. Intanto, già la prima versione del D.Lgs. 82/2005 – Codice dell’Amministrazione Digitale (CAD)[ii], in vigore dal 1 gennaio 2006, prevedeva, all’art. 17, che ogni pubblica amministrazione si dotasse di un centro di competenza che curasse lo sviluppo dei servizi forniti dai sistemi informativi (transizione digitale?). L’art. 17, variamente rimaneggiato negli anni, a partire dal 27 gennaio 2018, cambia la rubrica passando da “Strutture per l’organizzazione, l’innovazione e le tecnologie” a “Responsabile per la transizione digitale e difensore civico digitale”, confermata anche nell’attuale formulazione. Nasce, dunque, un soggetto, appunto il Responsabile per la Transizione Digitale (RTD), che ha il compito, abbastanza articolato, di governare il traghettamento della pubblica amministrazione in cui opera verso “lidi digitali”. E come può farlo? Ispirandosi ad un altro articolo del CAD ovvero il 14‑bis, inserito a valere dal 14 settembre 2016, istitutivo dell’Agenzia per l’Italia Digitale (AGID) alla quale assegna, tra le tante funzioni, la redazione (e verifica) del “Piano triennale per l’informatica nella Pubblica Amministrazione”. In verità, l’idea del piano triennale non è nuova giacché l’art. 7 del (soppresso) D.Lgs. 39/1993 prevedeva che l’allora Autorità per l’Informatica nella Pubblica Amministrazione (AIPA poi diventata CNIPA) redigesse un piano contenente “i progetti e i principali interventi di sviluppo e gestione dei sistemi informativi automatizzati delle amministrazioni”.

Quindi, già da quasi trent’anni, l’Italia, almeno nel comparto pubblico (da sempre vero volano di qualsiasi iniziativa di sviluppo, anche non tecnologico), ha posto le basi per la transizione al digitale cioè per cambiare prospettiva nel fornire servizi alla comunità. Certo, senza voler ripercorrere la storia dell’informatica pubblica italiana, i primi piani adottati puntavano soprattutto all’introduzione di nuove tecnologie nei polverosi uffici ministeriali o comunali (i primi personal computer, le prime LAN, i primi collegamenti remoti, ecc.).

Oggi, il piano si fonda su paradigmi, sistemi e strumenti che, tra l’altro, sono ampiamente nell’uso comune dei cittadini: il web, l’email, le app per dispositivi mobili, il cloud e così via.

L’ultima versione del piano è stata formalizzata con il DPCM del 17 luglio 2020[iii]: è la versione 2020‑2022[iv] che contiene molti suggerimenti per il RTD ma anche molti “ostacoli”, nel senso di step da superare o requisiti da soddisfare per avviare, per esempio, un nuovo servizio digitale. Infatti, basta fermarsi al paragrafo Princìpi guida per capire che possono esserci enormi difficoltà a realizzare, a far realizzare o a trovare sul mercato servizi applicativi che offrano una perfetta rispondenza agli undici princìpi esposti. Naturalmente, le amministrazioni pubbliche possono tranquillamente procedere con un approccio graduale, soprattutto nei casi in cui partono da zero o quasi. I piccoli comuni, per esempio, raramente hanno inserito al primo posto, in passato, programmi di transizione digitale dei loro servizi per due ragioni molto semplici:

• non sentivano l’urgenza della digitalizzazione perché il rapporto ravvicinato con l’istituzione facilita l’erogazione dei servizi; per esempio, l’ottenimento di un certificato poteva (e forse può) ben essere soddisfatto con la classica richiesta verbale allo sportello;
• non avevano le risorse per avviare seri programmi di transizione; mancavano le risorse umane per pianificare e condurre i progetti oltre che per sostenerne i risultati a regime; e, per tornare all’esempio precedente, tutto questo, forse, costa più del classico servizio allo sportello.

È chiaro che la pandemia (ma anche la velocità del mondo) ha reso indifferibile una rapida convergenza al digitale.

Dunque, rimuoviamo gli ostacoli:

• troviamo le risorse; quelle finanziarie dovrebbero arrivare dal PNRR mentre le risorse umane sarà più facile reperirle con la recente riforma Brunetta sulle assunzioni nella P.A.[v];
• pianifichiamo i servizi da digitalizzare; si tratta di formare una scala di priorità perché, si sa, non è possibile fare tutto insieme ed anche la più semplice amministrazione pubblica offre, come minimo, una mezza dozzina di servizi alla propria comunità di riferimento; nella definizione dei criteri di priorità occorre stabilire il giusto equilibrio tra il contesto interno della pubblica amministrazione e le esigenze della comunità di riferimento; alcune delle domande sono “Quanto questo servizio è necessario alla nostra comunità?”, “Qual è la frequenza con cui viene richiesto?”, “Chi sono i soggetti destinatari del servizio?”, “La struttura organizzativa è pronta ad offrire il servizio in modalità digitale?”;
• troviamo la soluzione giusta; si tratta di (ri)progettare il servizio ed individuare le soluzioni tecnologiche che meglio possono soddisfare i princìpi presenti nel piano triennale; non è una cosa facile, anche se, com’è noto, AGID ha messo a disposizione il Cloud Marketplace (e già si è a buon punto perché almeno il principio cloud first viene soddisfatto); purtroppo, però, il marketplace non risulta proprio amichevole nell’uso perché, ad esempio, quando si filtra su una determinata categoria SaaS (p.e. servizi scolastici), spesso, i fornitori che il sistema seleziona offrono prodotti che appartengono a tutt’altra categoria;
• gestiamo la transizione; forse, è la fase più difficile perché la “messa in moto” richiede impegni di natura tecnica (gestione delle utenze, configurazione del DBMS, ecc.) ma anche organizzativa (formazione del personale, comunicazione del servizio all’utenza, ecc.) sia quando si trasforma un servizio tradizionale in un servizio digitale sia quando si sostituisce un servizio che è già digitale (magari cambiando fornitore);
• portiamo il servizio a regime; alimentiamo il funzionamento del servizio, valutiamone l’efficacia e l’efficienza, modifichiamolo sulla base dei feedback, sosteniamolo nel tempo.

La “specialità” degli operatori di servizi essenziali

Sin qui, ci siamo limitati a delineare i passi salienti, provocatoriamente enfatizzati come “ostacoli”, che, in via generale, le pubbliche amministrazioni devono apprestarsi a condurre per concretizzare la transizione digitale. Tuttavia, ci sono pubbliche amministrazioni speciali. Il riferimento è a quei soggetti, definiti “operatori di servizi essenziali”, che rientrano nell’ambito applicativo del D.Lgs. 65/2018[vi] (detto decreto NIS) ovvero a quei soggetti che soddisfano i seguenti criteri:

1. forniscono un servizio che è essenziale per il mantenimento di attività sociali e/o economiche fondamentali;
2. la fornitura di tale servizio dipende dalla rete e dai sistemi informativi;
3. un incidente avrebbe effetti negativi rilevanti sulla fornitura di tale servizio.

Tra questi soggetti, per esempio, rientrano gli ospedali, i gestori di servizi ferroviari, i gestori degli acquedotti, ecc. sottoposti ad uno specifico obbligo che ne traina tanti altri: devono notificare allo CSIRT[vii] senza ingiustificato ritardo, gli incidenti aventi un impatto rilevante sulla continuità dei servizi essenziali forniti. Questo significa che devono mettere in piedi un’infrastruttura tecnica ed organizzativa che si ispiri agli standard di sicurezza delle informazioni comunemente utilizzati (ISO/IEC 27001) o al classico framework NIST[viii]: Identify, Protect, Detect, Respond and Recover.

Per questi soggetti non è sufficiente attenersi genericamente al principio, previsto dal Piano Triennale, di “sicurezza e privacy by design” ma è necessario attrezzarsi per un atteggiamento proattivo che identifichi esattamente quello che succede nei propri sistemi informativi per far scattare i meccanismi di prevenzione e di protezione adeguati.

Quindi, un ulteriore e pesante requisito da assicurare nella transizione digitale che, ricordiamo, può essere anche una transizione da “vecchio” digitale a “nuovo” digitale (rinnovo della piattaforma, cambio di fornitore, cambio di paradigma di servizio, ecc.).

L’“ultra‑specialità” del perimetro di sicurezza nazionale cibernetica

Il decreto NIS è l’applicazione nell’ordinamento italiano della direttiva europea 2016/1148 e, quindi, in qualche modo, una strada obbligata. Tuttavia, il legislatore italiano ha inteso rafforzare ulteriormente il quadro di regole per la cybersecurity identificando, nell’ambito degli operatori di servizi essenziali, un ulteriore sottoinsieme di soggetti che dovranno rispondere a requisiti ancora più stringenti. Lo ha fatto con il D.L. 105/2019 convertito con la Legge 133/2019 che definisce il perimetro di sicurezza nazionale cibernetica (d’ora in poi solo “perimetro”) composto da

tutte le amministrazioni pubbliche, gli enti e gli operatori pubblici e privati aventi una sede nel territorio nazionale, da cui dipende l’esercizio di una funzione essenziale dello Stato, ovvero la prestazione di un servizio essenziale per il mantenimento di attività civili, sociali o economiche fondamentali per gli interessi dello Stato e dal cui malfunzionamento, interruzioni, anche parziali, ovvero utilizzo improprio, possa derivare un pregiudizio per la sicurezza nazionale

I soggetti che rientrano nel perimetro sono identificati, e periodicamente aggiornati ma non resi pubblici[ix], con un atto amministrativo del Presidente del Consiglio dei Ministri (o di un Ministro appositamente delegato) così come previsto dal DPCM 131 del 30 luglio 2020 (Regolamento in materia di perimetro di sicurezza nazionale cibernetica)[x]. Appena un soggetto riceve la comunicazione di essere all’interno del perimetro è obbligato ad osservare misure stringenti sia nella progettazione, acquisizione, testing ed esercizio delle infrastrutture informatiche sia nella notifica di eventi da cui possa derivare un pregiudizio per la sicurezza nazionale[xi]. L’inosservanza di tali obblighi, peraltro, è punita dal D.L. 105 con pesanti sanzioni pecuniarie amministrative che possono arrivare a sfiorare i 2.000.000 di euro.

Il corpus normativo previsto dal D.L. 105 si è recentemente arricchito proprio del provvedimento che individua le categorie di beni, sistemi e servizi ICT destinati ad essere impiegati nel perimetro di sicurezza nazionale cibernetica ovvero il DPCM del 15 giugno 2021 (pubblicato nella G.U. 198 del 19/8/2021): quando i soggetti che rientrano nel perimetro intendono acquistarli devono preventivamente farne comunicazione al Centro di Valutazione e Certificazione Nazionale accludendo anche una valutazione del rischio nel contesto di impiego.

Si aggiunge, quindi, per i soggetti che rientrano nel perimetro, un ulteriore requisito da osservare nell’evoluzione dei propri sistemi informativi e, quindi, nella transizione digitale.

Senza dimenticare il GDPR

Ma il terreno più scivoloso e, forse, più insidioso dal punto di vista sanzionatorio è il Reg. UE 2016/679 (GDPR)[xii]. È più scivoloso per un paio di ragioni principali:

• le organizzazioni, pubbliche e private, sono, a volte anche inconsapevolmente, voraci di dati personali e, spesso, trascurano il principio di “minimizzazione dei dati” (art. 5, par. 1, lettera c);
• i partner/fornitori che trattano dati personali (responsabili del trattamento ai sensi dell’art. 28 del GDPR) sono scelti senza particolare cura e, spesso, con criteri di risparmio di costi.

Su quest’ultimo elemento occorre riflettere tenendo conto del recente rapporto “Threat Landscape for Supply Chain Attacks”[xiii] pubblicato dell’Agenzia Europea per la Sicurezza Cibernetica (ENISA) che, tra gli altri risultati, ha fatto emergere che:

• il 62% degli attacchi ai clienti sono avvantaggiati dalla fiducia nei fornitori;
• il 58% degli attacchi provenienti dalla catena della fornitura è finalizzata a conquistare dati personali o segreti industriali.

Quindi, un ulteriore elemento di attenzione: bisogna scegliere i partner secondo requisiti che riducano il rischio per i dati personali. Anche, in questo caso, per superare questo “ulteriore ostacolo” della transizione digitale è opportuno studiare, calibrare ed applicare le clausole contrattuali tipo approvate di recente dalla Commissione Europea[xiv].

Conclusioni

Nell’atletica leggera, per vincere la corsa ad ostacoli, ci vogliono forza, agilità e ritmo. Nella transizione digitale bisogna aggiungere qualcosa in più: studio, pazienza e tenacia.

Note

[i] https://www.governo.it/sites/governo.it/files/PNRR.pdf

[ii] Si consiglia di consultare le varie versioni della norma, anche articolo per articolo, attraverso la Documentazione Economica e Finanziaria (https://def.finanze.it/DocTribFrontend/RS2_HomePage.jsp)

[iii] https://pianotriennale-ict.italia.it/assets/pdf/2020-2022/DPCM_17_luglio_2020_pdf_testo.pdf

[iv] https://www.agid.gov.it/sites/default/files/repository_files/piano_triennale_per_l_informatica_nella_pa_2020_2022.pdf

[v] http://www.funzionepubblica.gov.it/sites/funzionepubblica.gov.it/files/legge113_6_agosto_2021_conv_DL_80_2021.pdf

[vi] https://www.sicurezzanazionale.gov.it/sisr.nsf/wp-content/uploads/2018/06/Dlgs-65_2018-NIS.pdf

[vii] https://csirt.gov.it/

[viii] https://www.nist.gov/cyberframework

[ix] https://www.governo.it/it/articolo/cyber-aggiornato-l-elenco-dei-soggetti-del-perimetro-di-sicurezza-cibernetica-nazionale

[x] https://www.gazzettaufficiale.it/eli/id/2020/10/21/20G00150/sg

[xi] Pregiudizio per la sicurezza nazionale: danno o pericolo di danno all’indipendenza, all’integrità o alla sicurezza della Repubblica e delle istituzioni democratiche poste dalla Costituzione a suo fondamento, ovvero agli interessi politici, militari, economici, scientifici e industriali dell’Italia, conseguente all’interruzione o alla compromissione di una funzione essenziale dello Stato o di un servizio essenziale

[xii] https://www.garanteprivacy.it/documents/10160/0/Regolamento+UE+2016+679.+Arricchito+con+riferimenti+ai+Considerando+Aggiornato+alle+rettifiche+pubblicate+sulla+Gazzetta+Ufficiale++dell%27Unione+europea+127+del+23+maggio+2018.pdf/1bd9bde0-d074-4ca8-b37d-82a3478fd5d3?version=1.9

[xiii] https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks/at_download/fullReport

[xiv] https://www.ictsecuritymagazine.com/articoli/arrivano-le-clausole-contrattuali-tipo-dalla-commissione-europea/

 

Articolo a cura di Francesco Maldera