Progetto Firm@

Carla Almirante Angelo Cardani Ruggero Civitarese Filippo Chesi
Progetto Firm@
L’impiego della firma digitale
per la gestione dei progetti
di Fondo Sociale Europeo in Regione
Lombardia. Un caso concreto di
eGovernement
B U O N E P R AT I C H E
Edizioni Change
© 2005 - Edizioni Change
20100 Milano – Via Vittor Pisani 13 – Tel. 02-6700230
Progetto grafico: Francesca Caricato

Indice
Parte I - Aspetti generali dei progetti di e-gov 9

1. Definizione del problema ed approcci possibili 10
1.1 Aspetti qualificanti e portata innovativa nei progetti di
e-go vernment 10
1.2 Le diverse forme dei progetti di e-government 11
1.2.1 Il livello di interazione 11
1.2.2 Il livello di servizio effettivo offerto 13
1.2.3 Le tipologie di servizio di e-government offerto 15
1.2.4 Il posizionamento del Progetto Firm@ 17
1.3 Concezione e attuazione di un progetto di e-gov 18
23
2. Le problematiche intrinseche del singolo progetto di e-gov
23
2.1 La razionalizzazione dei processi e il ridisegno organizzativo
26
2.2 La gestione dell’interazione con l’utente
26
2.2.1 L’identificazione dell’utente
29
2.2.2 Lo scambio di informazioni “firmate”
31
2.2.3 La gestione documentale: scambi e archiviazione
33
2.3 Il problema della sicurezza delle transazioni
34
2.3.1 La sicurezza degli accessi
35
2.3.2 Gestione delle transazioni economiche
39
2.3.3 Tutela della privacy
3. I presupposti tecnologici ed infrastrutturali 42

3.1 La tecnologia del certificato digitale 42
3.1.1 Concetti generali 42
3.1.2 Il certificato digitale 43
3.1.3 Le infrastrutture a chiave pubblica 45
3.2 Interoperabilità e standardizzazione 48
3.2.1 Interoperabilità tecnica 49
3.2.2 Interoperabilità e firma digitale 50
3.2.3 Interoperabilità semantica e gestionale 52
3.3 Strumenti di identificazione 53
3.3.1 La Carta d’Identità Elettronica 53
3.3.2 La Carta Nazionale dei servizi 55
3.3.3 Le Carte Regionali dei Servizi 55
3.3.4 La Tessera Sanitaria 60
3.4 Firma digitale e autenticazione dei documenti 61
3.4.1 Concetto e definizioni 61
3.4.2 La questione del non ripudio della firma digitale 65
3.4.3 Concessione e gestione della firma: la certificazione
della Firma Digitale 69
3.4.4 Processo di funzionamento della Firma Digitale 74
3.4.5 Problemi Aperti 76
3.5 Trasmissione certa: posta elettronica certificata (PEC) 78
3.5.2 La sperimentazione relativa alla PEC 79
3.6 Ricezione e gestione: il protocollo informatico 80
3.6.2 Il Protocollo Informatico nella PA: livelli di attivazione 81
3.6.3 Il nucleo minimo di protocollo: soluzioni e approcci 83
3.6.4 Il percorso di attivazione 85
4. Conclusioni e prospettive 88
4.1 L’attivazione di servizi innovativi 88
4.2 L’evoluzione del contesto normativo: il futuro “Codice della PA
Digitale” 90
5. Allegato: le fonti normative di riferimento 92

5.1 Fonti normative in materia di firma digitale 92
5.2 Fonti normative in materia di e-mail certificata 94
5.3 Fonti normative in materia di protocollo informatico 94
Parte II - Il progetto firm@ 97
6. Introduzione 98
6.1 Obiettivi del progetto 98
6.2 Ambito di riferimento 100
6.3 Documentazione di riferimento 102
6.4 Articolazione del Progetto 104
7. Aspetti di contesto 106

7.1 Strutture regionali di riferimento per la gestione FSE 106
7.1.1 Autorità di Gestione 106
7.1.2 Autorità di Pagamento 109
7.1.3 Autorità di Controllo di II livello 110
7.2 Le procedure di gestione dei Progetti FSE 110
7.2.1 Procedure dell’Autorità di Gestione 110
7.2.2 Procedure dell’autorità di pagamento 111
7.2.3 Procedure Generali 112
7.3 La Gestione Documentale 112
7.4 Il Sistema informativo per la gestione FSE 117
7.4.1 MonitorWEB - Schema complessivo del sistema 119
7.4.2 Presentazione progetti 120
7.4.3 Valutazione 121
7.4.4 Gestione progetti 122
7.4.5 Gestione delle visite ispettive 124
7.4.6 Porte applicative 125
7.4.7 Architettura 126
8 Il Protocollo Informatico della Regione Lombardia 127

8.1 La Posta Elettronica Certificata e il Protocollo Regionale 128
8.2 Gestione della Firma Digitale da parte del Sistema Protocollo 129
Regionale
9 Introduzione della Firma Digitale nella Gestione FSE 131

9.1 L’approccio metodologico 131
9.2 Documenti trattati nell’ambito del Progetto Firm@ 132
9.3 Le procedure interessate dal Progetto Firm@ 138
9.4 Attuale supporto informatico alle procedure individuate 141
9.4.1 Area rivolta agli operatori di formazione 141
9.4.2 Area rivolta ai funzionari regionali 143
9.5 Modifiche apportate al Sistema Informativo con l’introduzione
della Firma Digitale 144
9.5.1 Descrizione delle procedure prima dell’introduzione della
Firma Digitale 144
9.5.2 Descrizione delle procedure dopo l’introduzione della Firma
Digitale 146
9.6 Sintesi della soluzione informatica adottata 147
9.6.1 Architettura del Sistema 148
9.6.2 Il flusso procedurale 150
10 Modalità di attuazione della sperimentazione 151

10.1 Individuazione della procedura di test: l’Avvio dei Progetti 151
10.2 Supporto informatico alla gestione della Firma Digitale 151
10.2.1 Area rivolata agli operatori di formazione 152
10.2.2 Area rivolta ai funzionari regionali 159
Bibliografia 165
Sitografia 166
Introduzione
Il Progetto Firm@ si inserisce nel più vasto panorama dei pro-

getti di e-government che, attraverso l’utilizzo della rete e delle nuove
tecnologie, si propongono di trasformare le relazioni interne ed esterne
della Pubblica Amministrazione.
Gli obiettivi di fondo di questi progetti sono:
• migliorare la disponibilità del servizio (efficacia del servizio);
• ottimizzare le attività di produzione del servizio (efficienza del
servizio);
• dare centralità a cittadini e imprese lungo tutto il ciclo di vita
del servizio;
• semplificare le procedure amministrative.
L’introduzione delle nuove tecnologie comporta la rivisitazione
di interi processi, determinando la necessità di analizzare e gestire i
cambiamenti che insorgono nei seguenti ambiti:
• organizzazione;
• tecnologia e infrastrutture;
• interoperabilità dei processi tra Pubbliche Amministrazioni.
Un aspetto in qualche modo trasversale ai tre ambiti individuati
è dato dallo stato ancora incerto, e a tratti contraddittorio, della nor-
mativa.
Il documento che segue propone, da un lato, un focus sulle pro-
blematiche generali intrinseche ai progetti di e-government (presuppo-
sti tecnologici e infrastrutturali, normativa di riferimento e strumenti
tecnologici) e, dall’altra, esamina in modo approfondito, a titolo di test
case, il Progetto Firm@, un progetto finanziato col Fondo Sociale Eu-
ropeo che introduce la firma digitale nel processo di gestione dei corsi
di formazione finanziati via FSE dalla Regione Lombardia.
Più precisamente, il documento si articola nel modo seguente:
Parte I
• si propone una classificazione dei progetti di e-government se
condo le due variabili efficienza ed efficacia e si focalizzano le
problematiche di carattere organizzativo e tecnologico;
7 PROGETTO FIRM@ Documento di progettazione

• si esaminano nel dettaglio le principali componenti tecnologi
che e infrastrutturali che costituiscono una sorta di kit che
permette l’attivazione di questo tipo di progetti;
• si richiama la normativa di riferimento.
Parte II
• si esaminano gli aspetti di contesto del Progetto Firm@,
quali: l’organizzazione della Direzione Generale, l’insieme
delle procedure all’interno delle quali viene introdotta la firma
digitale e il sistema informativo di supporto;
• si fa il punto sulle infrastrutture tecnologiche presenti che con
sentono l’introduzione dell’utilizzo della firma digitale all’interno
del processo;
• si approfondiscono l’architettura generale della soluzione e le
variazioni apportate a livello organizzativo, procedurale e
applicativo dall’introduzione della firma digitale.

PARTE I
ASPETTI GENERALI DEI PROGETTI DI e-GOV
1. Definizione del problema ed approcci possibili
1.1 Aspetti qualificanti e portata innovativa nei progetti di

e-government
Da un punto di vista gestionale (connesso quindi con le proble-
matiche relative all’attivazione di un servizio e dunque, in ultima ana-
lisi, con l’ottica dell’Ente attuatore) si può affermare che la gestione on
line di un servizio è caratterizzata almeno da tre componenti tipiche:
• la costruzione e attivazione di un portale di interfaccia e inte
razione con l’esterno, che può avere diversi gradi di evoluzio
ne nella quantità e qualità dei servizi offerti;
• la riorganizzazione dell’Ente attraverso un intervento sulla
struttura organizzativa, che viene rivista in chiave di servizio
al cittadino in una logica per processi;
• l’informatizzazione e l’allineamento delle basi dati del back
office a supporto dell’erogazione del servizio “a distanza”,
in modo esaustivo.
Attivare un servizio con modalità on line significa quindi prende-
re in considerazione tutte e tre le componenti sopra descritte.
Con riguardo alle possibili variabili di lettura e interpretazione
delle esperienze di gestione on line si ritiene possibile individuarne due:
• la prima variabile fa riferimento al livello di interazione che
viene consentito all’utente esterno che si appresta all’utilizzo
delle funzionalità offerte. Nei sistemi e-government essa com
prende sia le modalità di interfaccia che la quantità e qualità
dei servizi offerti;
• la seconda variabile fa riferimento al livello di servizio
effetvo per l’utente, tale livello dipende da come funziona il
sistema di erogazione del servizio e dall’impatto con il sistema
organizzativo dell’Ente. Le principali caratteristiche di questa
seconda variabile sono:
1. la possibilità di operare a distanza senza necessità di
recarsi presso il luogo fisico di erogazione del servizio;
2. una riduzione certa dei tempi di attesa;
10 L’impatto Economico dei Fondi Strutturali

3. la possibilità di avere servizi innovativi, accessori ri
spetto a quanto erogabile in modo tradizionale.
Le caratteristiche peculiari del servizio erogato sono date da una
lettura congiunta di tali variabili.
Infatti le stesse ne definiscono le caratteristiche attraverso:
• la definizione delle funzionalità del portale di interfaccia;
• la definizione del funzionamento sostanziale della macchina
amministrativa nel suo complesso, che può essere descritto in
termini di relazioni tra i meccanismi che governano ciò che
accade nel back office:
- software;
- basi dati;
- modello organizzativo.
Il capitolo successivo ha lo scopo di fornire un quadro delle varia-
bili che caratterizzano la reale portata innovativa (in termini di “cambio
di paradigma” nell’erogazione dei servizi pubblici) dei diversi progetti
di e-gov che sono in gestione in questi anni.
L’idea è che i diversi progetti vanno analizzati non solo per l’am-
bito di cui si occupano (p.es. tributi piuttosto che erogazione di finan-
ziamenti) ma anche per la loro reale portata innovativa.
1.2 Le diverse forme dei progetti di e-government

1.2.1 Il livello di interazione
L’Unione Europea ha definito un sistema di monitoraggio del-
lo sviluppo dell’e-government, in modo da stimolare il confronto e
l’attività dei Paesi Membri in materia, individuando quattro livelli di
interazione tra il cittadino e la Pubblica Amministrazione:
Livello 1: Informativo (Information). Sono disponibili on line solo

le informazioni necessarie per avviare la procedura che porta all’eroga-
zione del servizio. In particolare devono essere presenti sul sito infor-
mazioni in merito a:
• descrizione dell’organizzazione e delle attività dell’ente che ero
ga il servizio;
• contatti per richiedere ulteriori informazioni;
• dettagli sulle procedure e sulle modalità di erogazione del servizio.
Livello 2: Download modulistica (One-way Interaction). E’ pos-
sibile scaricare on line i moduli necessari ad avviare la procedura che

porta all’erogazione del servizio. In particolare deve verificarsi almeno
una delle seguenti condizioni:
• esistenza di link on line per eseguire il download del modulo;
• possibilità di stampare on line il modulo;
• possibilità di ordinare on line il modulo.
Livello 3: Inoltro richiesta (Two-way Interaction). E’ possibile avvia-
re on line la procedura che porta all’erogazione del servizio. In partico-
lare, devono verificarsi contemporaneamente le seguenti condizioni:
• disponibilità del modulo elettronico che, una volta compi-
lato dall’utente, consente all’ente di avviare la procedura che
porta all’erogazione del servizio;
• esistenza di strumenti di autenticazione dell’utente tipo:
- nome utente;
- nome utente e informazioni personali;
- numero identificativo utente e password;
- identificazione elettronica;
- firma digitale.
Livello 4: Esecuzione transazione, compreso pagamento e conse-
gna (Full electronic case handling). Possibilità di eseguire on line
l’intera procedura che porta all’erogazione del servizio, comprensiva
di pagamento, notifica e consegna. In particolare devono verificarsi
contemporaneamente le seguenti condizioni:
• assenza totale di moduli cartacei ai fini dell’erogazione del servizio;
• possibilità di gestire, da parte dell’utente, tutto il processo dal
terminale di accesso on line;
• possibilità di gestire on line la notifica, il pagamento e la con-
segna associati all’erogazione del servizio.
Il servizio minimo consiste nel garantire on line ai cittadini una
semplice offerta informativa per arrivare poi alla possibilità di scaricare la
modulistica (modalità interattive monodirezionali) ed infine di effettuare
dei pagamenti attraverso modalità differenti, che vanno dal pagamento
con carta di credito all’addebito diretto su c/corrente bancario o postale.
Il pagamento on line, infatti, rappresenta la modalità interattiva
più avanzata, che va a completare l’intera transazione tra il cittadino e
l’ente e che, allo stato attuale, è attiva solo in pochi casi concreti, sia per
la difficoltà nel mettere a punto l’infrastruttura necessaria ad effettuare
tali operazioni sia per la necessità di implementare ambienti sicuri per
le transazioni e l’identificazione univoca del cittadino.
1.2.2 Il livello di servizio effettivo offerto
Con riferimento al livello di servizio effettivo, si possono indi-
viduare almeno 4 livelli caratterizzanti le funzionalità del sistema di
erogazione e l’impatto con il sistema organizzativo interno all’Ente:
1. un primo livello che possiamo definire portale isolato,
caratterizzato da un livello di integrazione minima con il
sistema organizzativo e i sistemi informativi dell’Ente. L’inse-
rimento di dati da parte dell’utente non provoca interazioni
né con i sistemi informativi né con il processo di gestione dei
tributi. Le caratteristiche distintive di questo livello di intera
zione on line sono:
• utente compila i propri dati direttamente su web;
• il sistema non è in grado di interpretare e valutare il conte-
nuto della transazione;
• nessuna interazione tra sistema web e sistemi informativi di
back office;
• impegno operatori nella trascrizione dei dati.
2. un secondo livello definibile come portale non integrato ma
che guida il processo caratterizzato da un livello di integra
zione medio/bassa con il sistema organizzativo e con i sistemi
informativi di back office, ma da una individuazione e defini
zione dei processi di lavoro caratteristici. Il portale non inter
viene sugli archivi delle procedure ma guida l’operatore nelle
operazioni da svolgere. Le caratteristiche distintive di questo
livello di interazione on line sono:
• non è in grado di interpretare e valutare il contenuto della
transazione;
• fornisce un workflow che segue tutto l’iter del processo;
• nessuna interazione tra sistema web e sistemi informativi
diback office;
• impegno operatori nella trascrizione dei dati;
3. un terzo livello più evoluto definito come portale integrato
con i sistemi transazionali, caratterizzato dalla piena integra
zione tra sistema web e i sistemi informativi di back office del
l’ufficio tributi. Permette la integrazione con i sistemi infor
mativi di back office, l-utente riconosciuto può intervenire di

rettamente sui dati/processo, sempre con la supervisione e il
controllo degli operatori. Le caratteristiche distintive di que
sto livello di interazione on line sono:
• interazione completa tra sistema web e sistemi informativi
di back office;
• nessun impegno da parte degli operatori nella trascrizione
dei dati;
• l’utente riceve dal sistema informazioni dirette sulla propria
posizione.
4. un quarto livello del portale integrato con banche dati del
l’ente integrate, il livello è caratterizzato da una completa in
tegrazione e messa a sistema di tutte le banche dati dell’En
te, per cui l’immissione dei dati dell’utente genera un impatto
diretto non solo sui sistemi informativi di back office del
l’ufficio con cui il cittadino si sta relazionando, ma anche sui
sistemi informativi di altri uffici interessati e rispetto ai quali
possono essere effettuati controlli incrociati di correttezza dei
dati immessi. Le caratteristiche distintive di questo livello di
interazione on line sono:
• i processi dell’Ente sono tutti integrati tra di loro, permette
di avere in linea più banche dati;
• interazione completa tra sistema web e sistemi informativi
di back office di tutte le aree dell’ente;
• nessun impegno da parte degli operatori nella trascrizione
dei dati.
Dall’analisi congiunta del posizionamento rispetto alle due varia-
bili descritte in questo e nel precedente paragrafo (livello di interazione
e livello di servizio), deriva un giudizio complessivo sulla portata del
progetto di e-government, con:
• un primo dimensionamento degli sforzi necessari per l’Ente
attuatore e dunque delle risorse umane e tecnologiche da uti-
lizzare;
• un’idea di massima sulla strada da percorrere una volta definte
le priorità relativamente ai servizi da erogare (alcuni richie-
dono per definizione livelli di interazione più alti ecc.).

Conseguentemente un Ente, una volta deciso quali servizi ero-
gare secondo modalità innovative, si deve porre la domanda di quanto
è disposto ad innovare la struttura organizzativa e i processi al fine di
supportare tale scelta e, soprattutto, di quante risorse ha a disposizione.
Ancora una volta la scelta è collegata al grado di innovatività verso
cui ci si spinge, e ancora una volta le alternative possibili sono molte.
Possono ad esempio essere gestiti completamente interi processi
attraverso l’impiego di procedure e strumenti innovativi, ma qualo-
ra manchi l’integrazione con altri sistemi informativi e banche dati
dell’Ente, e dunque con altri processi gestionali (che andrebbero per
questo opportunamente rivisti) questi processi rischiano di essere delle
“isole”, e dunque di perdere molti dei vantaggi impliciti nell’adozione
di forme di gestione differenti (efficienza su tutti).
Al di là comunque delle scelte appena illustrate appare chiaro
che l’implementazione di una qualsiasi introduzione di innovazioni di
questo tipo ha delle ricadute in termini organizzativi, dove non in ter-
mini strettamente “numerici” (adeguamento delle strutture), di sicuro
in termini di competenze da sviluppare attraverso, per esempio, inter-
venti formativi specifici.
Una scelta trasversale rispetto a quelle poste in precedenza riguar-
da la decisione, da prendersi una volta definiti i confini dei servizi da
erogare in modalità on line, di quali flussi documentali “spostare” nelle
nuove modalità di interazione, e di quali invece mantenere nelle moda-
lità tradizionali (trasmissione cartacea, protocollazione e gestione della
pratica nel modo consueto).
Un esempio che si può fare a riguardo è quello della presentazio-
ne di una domanda (es. di accreditamento o di partecipazione ad una
gara di appalto) per via telematica e utilizzando un dispositivo di firma
digitale, in modo da avere immediata visione del numero di pratiche e
delle caratteristiche della “domanda” del servizio, rimandando la verifica
della conformità dei documenti e dei requisiti ad un momento successi-
vo consentendone la trasmissione, ad esempio, per posta ordinaria.
L’esempio può essere esteso ai flussi documentali tra enti diversi e
a diversi ambiti di applicazione.
1.2.3 Le tipologie di servizio di e-government offerto

Mettendo a sistema le due variabili (livello di interazione e livello
di servizio effettivo) è possibile costruire una matrice caratterizzata dal-
l’incrocio tra i diversi livelli.

Ciascuno dei quadranti della matrice rappresenta uno stato tipi-
co del sistema di e-government attuato da un’amministrazione.
Sistema di e-government Caratteristiche
livello minimo di servizio percepito

informazioni on line
solo cambiamento nella modalità di erogazione
livello medio di servizio percepito
alto livello di servizio tradizionale individuazione e definizione dei processi di
lavoro
alto livello di servizio percepito
e-government formale
rischio di delusione rispetto alle prestazioni
equilibrio tra servizio percepito e servizio
e-government sostanziale erogato oneroso da mantenere allineate
le basi dati
macchina amministrativa innovativa a regime
PA on line
ampliamento della gamma dei servizi da offrire
La matrice successiva mostra invece un altro modo di interpre-

tare i diversi incroci possibili tra livelli delle variabili e fa riferimento
alle conseguenze organizzative che comporta la realizzazione di un
servizio di e-government.

1.2.4 Il posizionamento del Progetto Firm@

Il posizionamento del Progetto Firm@ così come riportato nello
schema nasce dalla considerazione che:
• il progetto stesso prevede un elevato livello di interazione, per
il quale “a regime” tutto il processo sarà completato on-line,
senza necessità di trasmissione di documenti cartacei (livello
4 dell’asse delle ordinate);
• esiste di fatto già un portale (monitorweb) che permette di
erogare interamente il servizio a distanza, chiudendo la tran-
sazione on-line ed effettuando tutte le operazioni e verifiche
successive previo riconoscimento dell’utente (livello 3 dell’as-
se delle ascisse).
Da questo punto di vista comunque il Progetto Firm@ rappresen-
ta un caso molto interessante per riuscire a contestualizzare, a toccare
con mano all’interno di un unico progetto, tutte le principali proble-
matiche connesse con la realizzazione di un progetto di e-government
“evoluto”, in grado cioè di mettere concretamente in pratica tutta una
serie di attività con il supporto concreto di strumenti di interazione ad
alto contenuto tecnologico.
Il livello medio, esclusi i casi di “eccellenza” che rimangono co-
munque molto pochi, di tali progetti si attesta infatti su un livello
di interazione tendenzialmente più basso e su una minore capacità di
erogare completamente il servizio a distanza, mancando in molti casi
presupposti (organizzativi e gestionali più che tecnologici), in grado di
spingere il posizionamento verso l’alto nei termini delle due variabili
di riferimento.
1.3 Concezione e attuazione di un progetto di e-gov

La parte I del presente documento non tratta più di tanto dei
vantaggi e delle opportunità legati all’introduzione di un progetto di
e-gov – che sono ben noti e discussi in letteratura – ma si pone piut-
tosto l’obiettivo di fornire un quadro degli aspetti da considerare nella
concezione e nell’attivazione di un progetto di e-gov per poterne defi-
nire un piano di fattibilità concreto e garantire così l’effettivo livello di
innovatività che è possibile raggiungere.
Come abbiamo visto, il concetto di e-government presuppone
un completo cambio di paradigma nell’erogazione dei servizi pubblici
reso possibile dall’evoluzione tecnologica, dalla sviluppo delle tecnolo-
gie ICT e dalla diffusione di internet.
La realizzazione di questo “salto” impone però di presidiare con-

giuntamente evoluzioni che interessano diversi ambiti: organizzativo,
tecnologico, istituzionale e che si sviluppano inevitabilmente in un
orizzonte medio-lungo.
Nella realizzazione di un progetto di e-gov si possono individuare
alcuni passaggi “chiave”.
Concezione e progettazione del modello “a tendere”

E’ la fase iniziale in cui il progetto prende forma. Scopo di questa
fase è da un lato definire le modalità innovative di erogazione dei servi-
zi e il loro contenuto effettivo, e dall’altro di effettuare una macro-valu-
tazione di fattibilità (tecnologica, organizzativa, normativa, culturale,
infrastrutturale...) e di sostenibilità economica.
Chiude questa fase la progettazione dell’”action plan” per la rea-
lizzazione dell’intervento, ossia l’esplicitazione delle tappe fondamen-
tali (su un orizzonte inevitabilmente di più anni) di sviluppo in fun-
zione tra l’altro dello sviluppo dei necessari presupposti infrastrutturali
e/o del comportamento dei soggetti esterni collegati.
Progettazione di dettaglio
Scopo di questa fase è la progettazione effettiva del sistema al-
meno nelle sue prime tappe di sviluppo. Si tratta di una progettazione
che abbraccia congiuntamente sia gli aspetti organizzativo-gestionali
(assetti, processi, procedure, flussi di interscambio, ...) che quelli tec-
nologici (hardware e software).
Nella pratica questa fase vede spesso una focalizzazione dell’at-
tenzione sugli aspetti tecnologici. Va segnalato tuttavia che, affinché le
innovazioni non rimangano in superficie ma incidano profondamen-
te nelle modalità della PA di erogare servizi, questo passa attraverso
un’inevitabile ridisegno gestionale dei processi rispetto a cui le solu-
zioni tecnologiche sono da un lato uno dei presupposti e dall’altro lo
strumento che supporta e che quindi viene plasmato su misura rispetto
alle esigenze organizzative.
Sviluppo della soluzione tecnologica

Scopo di questa fase è la realizzazione e l’attivazione dei sistemi
informativi che consentono l’erogazione dei servizi on-line (primo tra
tutti il “portale di interazione” con il cittadino) e il loro collegamento
con l’insieme dei sistemi che gestiscono i procedimenti amministrativi.
Punti di attenzione di questa fase sono innanzitutto la capacità
di integrare i processi informativi tradizionali presieduti unicamente

dal personale dell’ente con l’interazione con il cittadino garantita dal
portale, ovvero di acquisire ex-novo soluzioni in grado di supportare i
processi laddove non fosse presente una sufficiente automatizzazione.
L’altro aspetto problematico (e che in alcuni casi, come p.es. la
gestione dei tributi locali, può avere un impatto molto forte sull’at-
tuazione dell’intero progetto) è l’aggiornamento, la pulizia e l’allinea-
mento delle banche dati dell’ente coinvolte nell’erogazione del servizio
on-line: se qualunque cittadino in ogni momento deve poter conoscere
la sua situazione relativamente ad un certo aspetto della sua vita sociale
(p.es. la possibilità di iscrivere i figli ad un asilo comunale) il sistema deve
basarsi su una banca dati perfettamente aggiornata della situazione.
Attivazione del servizio

E’ questa forse la fase più delicata perché presuppone la gestione
contemporanea di diversi aspetti:
• test di funzionamento delle soluzioni tecnologico-gestionali;
• formazione degli addetti;
• informazione sul territorio;
• avvio del servizio in forma “prototipale” e/o circoscritta ad
alcune categorie di utenti;
• gestione in parallelo del servizio in modalità tradizionale ed
on-line.
La tabella successiva riporta a titolo esemplificativo le attività
principali coinvolte nell’attivazione di un generico progetto di e-gov.
Fasi Sotto-fasi Attività principali

Analisi-diagnosi organizzativa / gestionale
Analisi-diagnosi
e sullo stato delle tecnologia
Progettazione delle linee guida del modello
Definizione modello servizi/ Esplicitazione delle macro-alternative
Concezione e
modello di organizzazione tecnico-gestionali
progettazione
del modello Valutazione di macro-fattibilità
“a tendere” Valutazione del gap tra situazione attuale
e modello a tendere
Piano di azione
Valutazione dei presupposti infrastrutturali
Esplicitazione del percorso da compiere

Progettare gli aspetti organizzativi
e procedurali di massima
Reingegnerizzazione dei processi
Adeguamento organizzativo
Predisporre le linee guida per procedure
di funzionamento coerenti con il modello
Progettazione complessivo
di dettaglio Analisi della struttura
e tipologia dei dati e degli archivi
Progettazione software (front
Progettazione esecutiva del sw e relativa
office e integrazione back
documentazione
office)
Definizione specifiche di dettaglio delle
procedure di estrazione dati
Predisposizione HW
e sviluppo SW
Sviluppo servizio web
e customizzazione Definizione dei test case di componente
Esecuzione dei test di componente
Integrazione dei diversi cluster di servizi
Sviluppo e sulla piattaforma
avvio servizi Test e collaudo
Test
on line
Collaudo
Acquisizione ed installazione delle
attrezzature client per il test ed il supporto
Impianto e gestione centro allo sviluppo del sw
di competenza
Fornitura servizi assistenza e supporto ai
comuni
Come già detto, lo scopo del presente lavoro non è tanto indivi-
duare le soluzioni, quanto piuttosto fornire una mappa il più possibile
chiara delle problematiche e degli aspetti che devono essere considerati
nella pianificazione e nella gestione di un progetto di e-gov.
La mappatura delle problematiche presentata si articola su due
fronti:
• i problemi intrinseci al singolo progetto di e-gov, con questo
intendendo gli aspetti, i vincoli e le opportunità la cui defini-
zione e soluzione ricade generalmente nell’ambito di influenza
dei decisori che governano il singolo progetto
• le problematiche “infrastrutturali” con questo intendendo
gli aspetti che devono essere presidiati o le condizioni che de-
vono essere assicurate perché il progetto abbia successo, ma
che generalmente ricadono al di fuori della sfera di azione dei
decisori coinvolti nello sviluppo del singolo progetto.

La distinzione tra aspetti locali ed infrastrutturali è utile nella
analisi del contesto in cui si inserisce un progetto di e-gov in vista del-
la progettazione di un piano di attuazione coerente con le aspettative
p.es. in termini di innovazione dei servizi che il progetto comporta, ma
anche con la valutazione concreta della sua fattibilità complessiva.

2. Le problematiche intrinseche del singolo
progetto di e-gov
2.1 La razionalizzazione dei processi e il ridisegno

organizzativo
L’esplicitazione dei contenuti e delle modalità innovative del ser-

vizio da offrire in modalità e-gov sono il primo passo per la definizione
dei confini del problema da affrontare.
Le possibilità nei confronti dell’utente sono:
• offrire servizi nuovi (aggiuntivi al servizio tradizionale) che pri-
ma non era tecnicamente possibile offrire ovvero non era eco
nomicamente possibile offrire;
• cambiare le modalità di erogazione dei servizi tradizionali fa-
cilitando l’utente:
• possibilità di gestione del servizio on-line interagendo diretta
mente con il sistema;
• eliminando gli scambi cartacei e la necessità della presenza
fisica allo sportello.
Dal punto di vista dell’Ente la portata dell’innovazione risiede in:
• razionalizzazione dei processi: automazione dei flussi e intera-
zione con le basi dati: necessità di integrità, completezza e
protezione;
• risparmio di tempo/di risorse.
La realizzazione di un progetto di e-gov non può quindi prescin-
dere dal considerare gli impatti che questo ha sul modo di funzionare
dell’Ente. E’ abbastanza evidente che perché il progetto possa funzio-
nare è necessario introdurre nell’Ente una serie di elementi organiz-
zativi “minimali”:
• esplicitazione e razionalizzazione di procedure e processi: l’ero-
gazione di un servizio on-line comporta che l’organizzazione
dell’Ente sia in grado di funzionare in accordo alle richieste
che arrivano al sistema attraverso processi fluidi e integrati.
Se questo non avviene l’e-gov rimane un aspetto superficiale:

il sistema accetta richieste via internet che tuttavia vengono
erogate in maniera tradizionale. E’ fondamentale quindi pro
cedere ad un ridisegno delle procedure in tal senso. Va no
tato che in molti casi esistono delle procedure “di fatto”, non
formalizzate e poco riproducibili. Il primo passo nell’attiva
zione del sistema sarà quindi una presa d’atto delle procedure
esistenti, prima ancora di una loro ri-progettazione;
• presidio protocollo/sportello telematico e integrazione con i processi
tradizionali: l’erogazione di un servizio on-line avviene attra
verso l’interazione dell’utente con un portale attraverso cui
viene raccolta l’esigenza ed erogato il servizio. Indipendente
mente dalle caratteristiche dei processi o dei sistemi informa
tivi di supporto deve essere presidiata l’interazione dell’utente
con il portale in modo da garantire la qualità del servizio;
• sviluppo di sistemi informativi dedicati e integrazione banche
dati: l’evasione on-line della richiesta dell’utente presuppone
infine che il processo possa essere gestito da un sistema in
formativo (con una supervisione dei punti sensibili) e che sia
no disponibili basi dati aggiornate ed affidabili.
Si pensi ad esempio al problema dei tributi locali: i processi
sono complessi ma formalizzabili, sono disponibili molti si
stemiinformativi a supporto ma la vera difficoltà degli Enti
consiste nell’avere a disposizione basi dati sufficientemente
aggiornate e complete da permettere un’interazione diretta
dell’utente con i suoi dati tributari senza rischio di danni.
Nella maggior parte dei casi, ad esempio, un sistema di protocol-
lo informatico rappresenta il primo passo nell’automazione dei proce-
dimenti amministrativi o, più in generale, nel supporto all’informatiz-
zazione dei processi o flussi di lavoro (workflow).
Tali flussi possono in alcuni casi essere gestiti attraverso oppor-
tuni strumenti informatici (WorkFlow Management Systems) rappre-
sentati da prodotti commerciali attualmente diffusi in diversi settori
industriali, ed in tutti quei casi (diffusi anche nelle imprese di servizi)
dove è possibile individuare le condizioni che permettono a soluzioni
di workflow di migliorare la produttività complessiva del sistema. Tali
condizioni sono rappresentate dalla stabilità temporale dei processi,
dalla complessità dei procedimenti amministrativi e dalla loro
numerosità.
Se l’adozione del protocollo informatico spesso rappresenta il pri-
mo passo verso l’automazione dell’ufficio, il passo successivo è in gene-

re costituito dal supporto concreto alla gestione di flussi documentali
generati dal procedimento per il quale il passaggio dal protocollo è solo
una delle diverse attività che possono essere svolte.
L’Ente è così chiamato a delineare la relazione tra i sistemi di
protocollo e gestione di flussi documentali e il loro possibile sviluppo,
identificando una soluzione completa e flessibile in grado di essere ap-
plicata nei differenti uffici della Pubblica Amministrazione e di evolve-
re a seconda delle necessità.
Appare da subito evidente come queste scelte abbiano delle no-
tevoli ricadute organizzative e gestionali, che possono anche essere mi-
nime (es. attuazione del solo protocollo informatico e gestione delle
pratiche in modo “tradizionale” un volta ricevuti gli input), ma posso-
no anche arrivare, con degli interventi di BPR, a ridefinire in tutto o in
parte processi, ruoli e procedure.
Oltre a capire le condizioni minime che devono essere garantite
il punto importante è la possibilità di incidere significativamente sul
modo di funzionare attraverso una rivisitazione “strutturale” dell’orga-
nizzazione dell’Ente in funzione dell’erogazione del servizio.
Le alternative di progettazione della macro-struttura inoltre sono
legate alla responsabilità e alle modalità di coordinamento per quanto
riguarda l’attività interna:
• modello “tradizionale”: lo sportello di interfaccia interagisce
con gli altri uffici dell’Ente in modo del tutto analogo a come
si comporta con gli altri (p.es. secondo un regolamento che
definisce le modalità di interazione); non intervengono varia
zioni sostanziali rispetto al modello organizzativo preesistente;
• modello “evoluto”: l’organizzazione dell’Ente viene rivista in
chiave di servizio al cittadino e organizzata per processi.
In questo senso lo sportello coordina direttamente l’attività
degli uffici coinvolti nei procedimenti autorizzatori (definen
done di volta in volta priorità, tempi e modi a seconda delle
esigenze e del livello di servizio).
Il modello “evoluto” comporta:
• una riorganizzazione per processi (in una logica cliente-forni-
tore) di tutta la parte dell’Ente interessata all’erogazione di ser
vizi di e-gov (alle imprese ma anche ai cittadini);
• lo sviluppo di un sistema informativo “on-line” a supporto
dell’erogazione dei servizi che faciliti:
- l’interazione con l’utente;

- il fluire del processo autorizzatorio;
- l’interazione con gli altri attori coinvolti;
• un cambiamento culturale forte e pervasivo (diffuso).
Ruolo dello sportello e-gov

Tipologia Caratteristiche principali
nei confronti della struttura
• struttura funzionale • interagisce con gli utenti
• meccanismi di coordinamento • coordina lo scambio di infor
tra uffici mazioni e documenti tra uffici
tradizionale • sportello e-gov “coordina chi ed enti
eroga” • ha funzioni di expediting
• sportello e-gov inserito in una
Funzione
• struttura per processi secondo • interagisce con gli utenti
un modello “cliente-fornitore” • governa i processi programman-
• sportello e-gov “è chi eroga” do l’attività delle risorse
• sportello e-gov inserito in • ha funzioni di expediting
una struttura complessiva di
orientata al cliente
front-office
• si supera la competenza “set
toriale” dell’Ente, a favore di una
competenza “tematica” ritaglia
ta sui bisogni dell’utente
Queste scelte in molti casi riescono a fare la differenza tra progetti

di e-government “ambiziosi”, che si pongono l’obiettivo di (e a volte
rappresentano l’occasione per) rivedere regole strutturate di funzio-
namento, e progetti di e-government che semplicemente permettono
l’utilizzo di strumenti di interazione evoluta, ma “realizzano” poi i ser-
vizi secondo procedure consolidate.
2.2 La gestione dell’interazione con l’utente

2.2.1 L’identificazione dell’utente
L’erogazione on-line di un qualunque servizio pubblico ha come
presupposto la possibilità per l’Ente di riconoscere inequivocabilmente
l’identità dei soggetti che fruiscono dei servizi attraverso i portali te-
lematici. L’identificazione dell’utente rappresenta quindi un elemento
estremamente delicato e critico nel processo di erogazione di un servi-
zio on line.
In particolare l’interazione da parte dell’Ente con un soggetto che
accede ad un servizio on line comporta:

• l’accesso al sistema tramite un portale web attraverso cui
l‘utente possa fornire la sua identità (p.es. mediante l’inseri-
mento di username e password, ovvero mediante l’inserimen-
to di una tessera magnetica) al sistema;
• l’attivazione di un sistema di riconoscimento e decodifica di
codici di accesso inseriti dall’utente e in grado di collegarli al
dossier che raccoglie le informazioni legate all’utente;
• la costruzione e l’aggiornamento del dossier del soggetto che
accede ai servizi, completo dei dati già in possesso dell’ammi-
nistrazione, più alcuni dati aggiuntivi inseriti direttamente
dall’utente;
• il fatto che ci sia stato un riconoscimento certo da parte di
un’autorità preposta dell’utente al momento in cui richiede per
la prima volta l’accesso ai servizi on line;
• la garanzia della sicurezza dei dati immessi e del rispetto della
privacy.
L’identificazione dell’utente di un servizio on-line può avvenire
attraverso soluzioni differenti che hanno ricadute diverse in termini di
impatto sull’attivazione del servizio (tecnologico ed economico), po-
tenzialità di servizi principali ed accessori erogabili, tipologia di intera-
zione possibile da parte dell’utente.
L’impatto sull’attivazione del servizio on-line può essere ricondot-
to ai seguenti aspetti che devono in qualche modo essere presidiati:
• creazione iniziale del profilo utente per quel particolare servi
zio, a fronte di un riconoscimento certo dell’utente (primo ac-
cesso e apertura profilo);
• gestione in sicurezza di tutte le transazioni successive ricono
scendo univocamente gli utenti registrati (accessi successivi);
• verifica periodica, attraverso un’attività di auditing, della va-
lidità dei presupposti di accesso, ossia che non ci siano disalli
neamenti tra lo strumento di identificazione e il soggetto che
lo utilizza (es. furti di password, smarrimento di tessere, ecc.).
Tra i molteplici strumenti di identificazione in questa sede è op-
portuno distinguere tra le seguenti alternative:
• sistemi basati sulla coppia username e password: l’attiva-
zione al servizio avviene solitamente attraverso registrazione
spontanea dell’utente e rilascio delle chiavi di accesso da parte
del sistema. Richiede il minor investimento a livello infrastrut-

turale ma ha anche una portata limitata genericamente al sin-
golo sistema/servizio;
• sistemi basati sul rilascio di tessere di riconoscimento (ma-
gnetiche, con codice a barre o con microchip) dedicate a quel
la famiglia di servizi: la concessione della tessera è solitamente
l’occasione dell’identificazione certa dell’utente da parte del
gestore del servizio, sono necessari lettori dedicati ma i proble
mi infrastrutturali da affrontare sono più limitati del caso suc-
cessivo. Questa soluzione consente generalmente di utilizzare
la tessera oltre che come mero strumento di riconoscimento
anche come supporto per la memorizzazione di informazioni
utili all’erogazione di servizi specifici (p.es. la storia clinica del
paziente sulla tessera sanitaria);
• sistemi basati sull’utilizzo di tessere di riconoscimento (ma-
gnetiche, con codice a barre o con microchip) a rilevanza
generale (p.es. regionale o nazionale): il vantaggio indubbio
di questa soluzione è da un lato che il gestore del servizio non
deve preoccuparsi né dell’identificazione certa dell’utente né
della validità del supporto perché questi aspetti sono garantiti
da un certificatore a monte e dall’altro che il sistema consente
l’identificazione del soggetto in quanto “cittadino” (codice fi-
scale) e quindi ha potenzialmente una valenza universale per
tutti i servizi legati alla persona. Gli svantaggi sono legati es-
senzialmente a difficoltà e vincoli infrastrutturali.
Per quanto riguarda il tipo di interazione consentita è evidente
che i sistemi basati su username e password sono molto indicati per
quei servizi che vengono erogati essenzialmente attraverso un’intera-
zione diretta del cittadino con un portale telematico: non richiedendo
lettori dedicati, possono essere utilizzati comodamente ovunque e sono
attivabili con costi contenuti. Gli svantaggi sono ovviamente una mi-
nore sicurezza, un campo di utilizzo limitato a quel servizio e un costo
maggiore per l’eventuale identificazione certa in sede di rilascio iniziale
e per la verifica della validità.
Per contro i sistemi basati su tessera di riconoscimento sono adatti
a servizi che richiedono un’interazione del soggetto con operatori di-
versi e diffusi sul territorio (p.es. nel caso dei servizi sanitari la tessera
di riconoscimento con memorizzazione dei dati del paziente consente
l’interazione con farmacisti, medici di base, ...).

2.2.2 Lo scambio di informazioni “firmate”
La gestione di un servizio on-line generalmente richiede che pos-
sa avvenire tra utente ed Ente lo scambio di informazioni “firmate”, os-
sia di informazioni o dichiarazione di cui si possa attestare l’autenticità
e la provenienza ai fini della validità legale del servizio erogato.
Gli aspetti che vanno presidiati sono:
• la produzione dell’informazione e la sua firma;
• la sua eventuale cifratura;
• la trasmissione e la ricezione.
Per quanto riguarda il primo aspetto è opportuno distinguere
due situazioni paradigmatiche a seconda che l’interazione tra utente
ed ente consista:
a) essenzialmente nello scambio on-line di un documento prodotto
dall’utente
questa procedura, che va ripetuta tante volte quanti sono i
documenti da firmare, prevede la digitazione del PIN una vol-
ta individuato il documento da firmare, e previo inserimento
della smart card nell’apposito lettore. In nessun modo avvie
ne una trasmissione automatica di questo documento, che
andrà trasmesso al destinatario utilizzando l’e-mail (per l’im-
piego di posta certificata si veda il relativo paragrafo).
Ciò che viene garantito in questo caso dall’impiego di un cer-
tificato di firma digitale è la certezza del contenuto, non l’av-
venuta trasmissione e/o ricezione;
b) nella gestione di un processo articolato, supportato da un oppor-
tuno sistema informativo di workflow che preveda la generazione
e la firma di più documenti impiegando procedure automatiche
Quando la mole di documenti da firmare lo richiede è con
sentito l’utilizzo di procedure automatiche, nel corso delle
quali sostanzialmente avviene una sola volta l’operazione fisica
di sottoscrizione a fronte di più documenti.
In particolare, è necessario che quando il titolare appone la
sua firma mediante una procedura automatica utilizzi una
coppia di chiavi diversa da tutte le altre in suo possesso.
Nel secondo caso si propone la seguente problematica: da un lato
il sistema informativo che gestisce il processo e che genera i documenti
da scambiare con l’utente ha la necessità di gestire un proprio criterio
di codifica dei documenti scambiati e delle informazioni in questi con-
tenute, in modo da saperli riconoscere e poterli gestire correttamente
lungo tutto il procedimento. Dall’altro, per poter certificare l’auten-
ticità e la correttezza dei singoli scambi il sistema informativo deve
interagire – e quindi creare e scambiare documenti compatibili – con
le autorità di certificazione che attestano la validità e la provenienza
dei documenti e con il protocollo informatico che attesta la ricezione
degli stessi e questo comporta inevitabilmente delle limitazioni nelle
possibilità di codifica dei documenti in funzione del riconoscimento
automatico ai fini della gestione del procedimento.
Per quanto riguarda il tipo di firma da adottare si pongono le se-
guenti alternative: firma “debole” quando il supporto non ha validità
generale e l’autenticità della firma è garantita esclusivamente dall’ente
che emette il certificato per fini propri; firma “forte” quando si utilizza
la firma digitale la cui autenticità e rilascio sono garantite dagli enti
certificatori indipendenti.
I documenti firmati possono essere suddivisi in tre sottocategorie:
• Documento in chiaro con firma digitale;
• Documento cifrato con firma digitale;
• Documento cifrato con firma digitale e validazione temporale.
Le caratteristiche delle tre tipologie di documenti sopra citate
sono riportate nella tabella seguente.
Tipi di documenti firmati digitalmente:

cifrato con validazione
in chiaro cifrato
temporale
Appone la propria Cifra il testo del Cifra il testo del docu-
firma digitale a un documento con la mento con la chiave
documento in chiaro, chiave pubblica del pubblica del desti-
ovvero lo cifra con la destinatario prelevata natario, vi appone
propria chiave priva- dall’archivio della la firma digitale e lo
Azioni del mittente
ta, e lo spedisce CA e vi appone la spedisce all’autorità
propria firma digitale per la validazione
(ovvero cripta ancora temporale
il testo con la propria
chiave privata)
Certifica, conserva La TSA appone il
Certifica l’identità
e pubblica le chiavi timestamping, cioè
del possessore di
Azioni dei soggetti identificando il pos- stabilisce la data di ri-
una coppia di chiavi;
certificatori sessore lascio del documen-
registra e pubblica la
to e, dunque, la sua
chiave pubblica
validità temporale

Riceve il docu- Decifra il testo rice- Decifra il testo con la
mento, preleva la vuto con la propria propria chiave priva-
chiave pubblica del chiave privata e ta, verifica l’identità
mittente dalla CA e verifica l’identità del del mittente, prende
Azioni del
decifra il messaggio mittente prelevan- atto della validità
destinatario
rilevando l’identità do la sua chiave temporale del docu-
del mittente pubblica (associata al mento
certificato di identità
digitale) dalla CA
Mittente e destinata- Mittente e destinata- Mittente e destinata-
rio sono collegati via rio sono collegati via rio sono collegati via
Internet o Intranet; Internet o Intranet; le Internet o Intranet; le
le procedure di procedure di registra- procedure di registra-
Condizioni registrazione e certi- zione e certificazione zione e certificazione
ficazione sono rigo- sono rigorose; la se- sono rigorose; la se-
rose; la segretezza gretezza della chiave gretezza della chiave
della chiave privata è privata è garantita privata è garantita
garantita
2.2.3 La gestione documentale: scambi e archiviazione

L’erogazione di servizi da parte della PA, è basata necessariamente
sulla forte interazione con l’utenza e con altri Enti.
Si pensi ad esempio al rilascio di una autorizzazione: il processo
“standard” prevede almeno il deposito di una domanda da parte del
cittadino interessato e in molti casi una serie di interazioni dell’ente
che rilascia l’autorizzazione con altri attori pubblici e/o privati (es. tri-
bunale, ASL, Questura, ecc.).
Tutti questi passaggi intermedi comportano la produzione e la
gestione di documenti che hanno generalmente rilevanza giuridica, e
lo scambio degli stessi a diversi livelli istituzionali. Ciò comporta la ne-
cessità di una continua e celere identificazione univoca della “pratica”,
sia da parte del cittadino che dell’Amministrazione, al fine di valutarne
e presidiarne lo stato di avanzamento.
La gestione di un servizio on-line presuppone che questo flusso
sia automatizzato e gestito attraverso un sistema di workflow ad hoc e
che i documenti oggetto dello scambio siano possibilmente digitali.
L’eliminazione della carta nella gestione delle procedure ammini-
strative è un passaggio che offre molte opportunità (facilità di indivi-
duazione e tracciabilità dei documenti, possibilità di automatizzazione
del flusso, risparmio di spazio fisico nell’archiviazione, ...) ma pone
anche una serie di problemi: disponibilità di tecnologie e di competen-
ze specifiche, affidabilità dei sistemi informatici di gestione, soluzione
di problematiche infrastrutturali, presidio dell’evoluzione tecnologica

e conseguente aggiornamento dei supporti.
Il documento informatico deve preservare tutte le caratteristi-
che funzionali attribuite al documento cartaceo, proprio per questo
motivo è necessario predisporre un sistema di produzione, distribuzio-
ne e conservazione del documento informatico.
Relativamente al documento informatico vi sono alcuni concetti-chia-
ve di cui è indispensabile tenere conto:
• l’immodificabilità: che può essere garantita via software
attraverso il salvataggio del documento in modalità non più
modificabile ovvero protetto da password, oppure tramite l’ap-
posizione della firma digitale;
• la conservabilità: questa viene assicurata attraverso la periodi-
ca duplicazione dei documenti su supporti nuovi al fine di
prevenire il deperimento degli stessi e il periodico aggiorna-
mento del formato di codifica e/o del supporto in funzione
dell’evoluzione tecnologica degli strumenti hardware e softwa-
re di riproduzione;
• l’autenticità: tale proprietà viene assicurata al documento in-
formatico attraverso la firma digitale che consente di stabilire
se un documento è stato emesso da un determinato soggetto;
• il non ripudio: anche tale proprietà viene garantita dalla fir-
ma digitale e consiste nel fatto che il documento non può essere
disconosciuto da chi lo ha emesso (salvo querela di falso).
Anche relativamente al flusso documentale vi sono alcuni con-
cetti-chiave che è necessario prendere in considerazione:
Gestione automatizzata del flusso dei documenti e protocollo
informatico: per realizzarla è necessaria un’infrastruttura applicativa
su cui incentrare i sistemi di gestione documentale integrati con il pro-
tocollo, i sistemi di pianificazione e controllo, i sistemi di workflow
per la gestione dell’iter procedurale. Le funzionalità prevedono l’acqui-
sizione dei documenti da supporti informatici e l’integrazione con le
e-mail (utilizzando lo standard XML, la classificazione e fascicolazione
in base al titolario di archivio, la certificazione dei documenti). La nor-
mativa stabilisce che ogni amministrazione deve individuare al proprio
interno un insieme di “Aree organizzative omogenee” (AOO) e per
ciascuna di esse deve dotarsi di un sistema di protocollo informatico
che realizzi alcune funzionalità di base (nucleo minimo). Le funzio-
nalità che realizzano il nucleo minimo del sistema di protocollo sono
quelle che permettono di fornire il servizio di certificazione. Il nucleo

minimo prevede anche l’adozione di un titolario di classificazione per
permettere all’amministrazione di archiviare i documenti protocollati
a seconda dell’argomento di riferimento. In tal modo, oltre a favorire
la ricerca dei documenti protocollati grazie all’uso di parole chiave,
si pongono le basi per una eventuale gestione dell’intero patrimonio
documentale dell’amministrazione.
Registrazione di protocollo: è l’operazione con la quale si me-
morizzano le informazioni principali relative al documento nel registro
di protocollo, corrisponde alla assunzione di responsabilità da parte
dell’amministrazione e in particolar modo serve a certificare l’esistenza
del documento a partire da una certa data. Questo significa:
• nel caso di documenti ricevuti, l’amministrazione non può ne-
gare, a fronte della richiesta di esibizione del contenuto di una
registrazione, che un documento sia esistito. Inoltre essa certi-
fica il fatto che il documento è entrato nell’ambito dell’ammi-
nistrazione e dei processi amministrativi di quest’ultima che
lo riguardano;
• nel caso di documenti prodotti dall’amministrazione, la stessa
può avvalersi dello strumento protocollo informatico per fini
probatori (ad esempio per dimostrare a terzi che un proprio
documento è stato prodotto o che ha ottenuto un valore uffi-
ciale prima di una certa data).
2.3 Il problema della sicurezza delle transazioni

Il tema della sicurezza ha sempre rivestito un importante ruolo
nella gestione di qualunque sistema informatico.
Nel nostro caso, senza trascurare i temi della sicurezza intrinseca
dei dati gestiti (protezione dal rischio di perdita delle informazioni a
causa di rotture o malfunzionamenti dei sistemi informatici), il tema
della sicurezza si focalizza inevitabilmente sulla protezione delle tran-
sazioni gestite.
Gli aspetti più rilevanti da presidiare in un progetto di e-gov sono
quindi la gestione sicura di:
• accessi da parte degli utenti: il sistema deve permettere l’acces-
so ai soli utenti riconosciuti come validi e deve essere in grado
di non far commettere danni e di tenere traccia di quello che
succede;
• transazioni di informazioni riservate e più specificamente di
pagamento;
• tutela della privacy.
2.3.1 La sicurezza degli accessi
Con la diffusione dei computer e delle reti locali vissuta negli
anni ‘ ed ‘ diventa rilevante la gestione di accessi sicuri ai sistemi
connessi in rete.
E’ proprio in questi anni che vengono alla ribalta i problemi cor-
relati all’accesso non autorizzato, se non addirittura fraudolento, ad
importanti basi dati anche di organizzazioni governative e militari.
Dunque al problema della salvaguardia dell’informazione contro
eventi imprevisti si affianca la necessità di vigilare sull’identità del per-
sonale che accede ai sistemi e sulla costruzione di infrastrutture logiche
di sicurezza che consentano la strutturazione di veri e propri livelli di
accesso collegati alla precedente operazione di riconoscimento. Tutto
ciò viene spesso sintetizzato con l’acronimo A.A.A. (Access Authoriza-
tion Accounting), ovvero Accesso Autorizzazione e Registrazione. Con
ciò si intende che l’utilizzo di un sistema informatico può avvenire solo
se vengono soddisfatti questi 3 prerequisiti:
1. Access: un processo che consenta di vigilare sulla provenienza
della richiesta di utilizzo del sistema informatico;
2. Authorization: una procedura che consenta di gestire il sopra-
citato “livello di accesso” ovvero il problema di “cosa” deve
essere disponibile all’utente;
3. Accounting: una serie di log e procedure che consentano di
“tracciare” l’operato dell’utente una volta che esso abbia passa-
to le prime due fasi di verifica.
I problemi più immediati che si devono fronteggiare sono colle-
gati alla possibilità che un operatore non autorizzato acceda al sistema
informativo attraverso l’utilizzo di credenziali altrui o addirittura senza
nemmeno possedere alcuna credenziale al sistema.
In fondo non si tratta che di riproporre in ambito allargato le
soluzioni escogitate per il medesimo problema nel caso di computer
singoli.
Altro problema poi è l’esistenza delle remote vulnerabilities: vulnerabi-
lità remote, che permettono cioè ad un operatore via rete di accedere in
modo non autorizzato alle risorse del sistema informatico.
Le soluzioni per questo tipo di problemi si diluiscono su più at-
tività di cui citiamo:
1. installazione di firewall per limitare le metodologie di accesso;
2. installazione di sistemi IDS (Intrusion Detection System) per
l’immediato rilevamento di tentativi di intrusione;

3. manutenzione evolutiva dei sistemi.
Come ultima tematica rilevante citiamo la necessità di proteggere
i dati che transitano su una rete da tentativi di intercettazione o copia
dei medesimi da parte di soggetti terzi.
La risposta tecnologica più frequente risiede nell’adozione di
metodi di cifratura più o meno complessi dei dati in transito; il re-
cente interesse globale per le reti VPN (Virtual Private Network) e le
tecnologie collegate alla cifratura secondo lo standard SSL/TLS sono
l’evidente sintomo di quanto questo problema non possa più essere
considerato secondario.
Un elemento importante per una strategia di protezione globale
è la corretta identificazione della persona che effettua una qualunque
transazione.
I sistemi d’accesso basati su autenticazione si fondano attualmen-
te su tre classi di verifica:
1. Secret based: basata sulla conoscenza di un segreto (una pas-
sword, una chiave privata, ecc...);
2. Token based: basata sul possesso di un oggetto unico, non
riproducibile e che non può essere manomesso (smartcard
crittografiche, token usb, ecc...);
3. Biometrico: basata su una caratteristica individuale specifica
e unica (firma autografa, impronte digitali, pattern dell’iride
e della retina, impronta vocale, forma del palmo della mano,
caratteristiche del viso, dinamica di digitazione su tastiera,
ecc...).
In particolare le tecniche biometriche, nate inizialmente in am-
bienti dove il problema dell’identificazione certa della persona assume
carattere critico, quali quelli militari o comunque legati alla Difesa, si
stanno progressivamente espandendo anche all’ambito dell’industria
privata e della PA; ciò al fine di controllare gli accessi ad applicazioni
informatiche critiche ed a dati sensibili da parte del personale dipen-
dente o dei fruitori dei servizi erogati on-line.
2.3.2 Gestione delle transazioni economiche

Il pagamento on line di un tributo può avvenire attraverso mo-
dalità diverse:
• attraverso l’utilizzo di carta di credito direttamente dal porta-
le dell’Ente;

• attraverso i servizi di home banking messi a disposizione dalle
banche;
• attraverso il servizio messo a disposizione dalle Poste italiane;
• ecc.
La modalità di pagamento con carte di credito è quella più fre-
quentemente utilizzata su Internet. L’utente esegue il pagamento di un
servizio (in questo caso di un servizio di Fiscalità Locale) inserendo in
un apposito spazio i dati della propria carta di credito.
Questo tipo di pagamento è basato sul concetto di credito e que-
sto perché una banca “acquirer” garantisce il credito per una persona,
o per una azienda, nei confronti del circuito emittente la carta, fino ad
una certa cifra giornaliera o mensile. In questo modo, nel momento in
cui il portatore della carta effettua un pagamento non viene controllata
la sua reale disponibilità, il suo conto in banca. Il creditore (nel nostro
caso tipicamente la Tesoreria dell’Ente) può quindi immediatamente
essere accreditato del valore dell’operazione, anche se in quel momento
l’utente non ne ha sufficiente disponibilità.
Dal punto di vista tecnico esistono due modalità mediante le
quali è possibile fornire il servizio di pagamento con carta di credito
nei confronti di un Ente:
• Pagamento diretto sul sito dell’Ente (payment gateway inter-
no all’Ente);
• Ridirezione dell’utente dal Portale al sito di una banca che, ad
esempio, potrebbe essere proprio la banca che gestisce la Tesore-
ria dell’Ente (payment gateway esterno all’Ente).
La differenza sostanziale tra la prima e la seconda ipotesi si ri-
scontra non tanto rispetto al servizio percepito dall’utente, che sostan-
zialmente resta lo stesso, quanto dal punto di vista dell’Ente che, nella
seconda ipotesi viene sollevato dall’onere di dover acquisire e gestire il
payment gateway ed anche dalla responsabilità della gestione sicura dei
dati delle carte di credito, che è a totale carico della banca reindirizzata
per il pagamento.
Il pagamento attraverso l’utilizzo dei servizi di home banking
messi a disposizione dalle banche è un processo che si realizza esterna-
mente al portale dell’Ente e coinvolge l’utente, la banca a cui si appog-
gia e la Tesoreria quale destinatario del pagamento. Lo stesso vale per il
pagamento attraverso il servizio di Poste Italiane.
La sicurezza della transazione di pagamento rappresenta di fatto
l’elemento più delicato dell’intero processo e può essere considerata

sia dal punto di vista di chi offre il proprio servizio a pagamento, sia
dal punto di vista di chi utilizza la propria carta di credito on line per
l’esecuzione del pagamento.
Dal momento in cui si decide di effettuare un acquisto utiliz-
zando una carta di credito, la transazione è gestita da una complessa
sequenza di procedure e strutture. In breve, le figure chiave sono:
• le associazioni o circuiti a cui fanno capo le carte di credito;
• le società emittenti, ovvero le banche;
• i venditori e gli acquirenti. Gli acquirenti sono rappresentati
dalle società di servizi finanziari che trattano la transazione
nell’interesse dei venditori. Alcuni grandi venditori gestisco
no il passaggio internamente, ma la maggior parte delega a
terzi, che possono anche fornire servizi di hosting.
La domanda di quale sia la parte che si accolla il costo in caso di fro-
de on line è complessa. Nella maggior parte dei casi il titolare della
carta di credito è responsabile per l’uso di una carta rubata, ma la sua
responsabilità si ferma a un limite piuttosto basso. In tal modo le socie-
tà emittenti coprono gran parte dei costi, compresa l’istruttoria della
transazione contestata. I costi possono diventare molto più alti se la
controversia non si risolve rapidamente.
Se fosse possibile autenticare i titolari di carta di credito prima di
un acquisto con un ragionevole livello di certezza, si potrebbe ridurre
la probabilità di utilizzo di una carta rubata. Ne gioverebbero diretta-
mente venditori e banche, ma allo stesso modo, seppur indirettamente,
anche i titolari delle carte. Una procedura che dimostri la propria iden-
tità darebbe un maggior senso di sicurezza, così da incoraggiare i pos-
sessori di carta di credito ad effettuare tranquillamente acquisti on line.
Per garantire la sicurezza dei dati immessi, soprattutto del nu-
mero di carta di credito, possono essere utilizzati sistemi senza o con
crittografia:
• Sistemi senza crittografia: non usare crittografia significa af-
fidarsi alla sicurezza “fuori banda”: per esempio i beni ordinati
elettronicamente non saranno consegnati prima che il com
pratore spedisca un fax (o una lettera, o una chiamata telefo
nica) a conferma dell’ordine. Esempi di questo tipo di sistemi
sono Compuserve, First Virtual e Internet Shopping Network.
In Compuserve ogni cliente, per comunicare, usa una linea
che ritiene sicura e si identifica col sistema. Sia in First Virtual
che in Internet Shopping Network il compratore ha un

conto con il sistema e riceve una password in cambio del nu-
mero di carta di credito. La password non è protetta mentre
viaggia su Internet e dunque è vulnerabile agli attacchi di chi
“origlia” (eavesdropper). First Virtual fornisce una certa forma
di protezione chiedendo conferma al compratore di ogni pa-
gamento tramite e-mail, ma l’attuale forma di sicurezza si basa
sul fatto che il compratore può revocare l’acquisto entro un
certo periodo di tempo e fino ad allora il venditore si assume
la totalità del rischio.
• Crittografia a chiave condivisa: per tale tipo di crittografia, il
compratore e il venditore da un lato e le parti che forniscono
autenticazione e autorizzazione dall’altro hanno bisogno di un
segreto condiviso (per esempio una chiave DES o almeno una
password o un PIN). È quindi chiaro che tale tipo di codifica
non consente di risolvere casi di pagamenti contestati.
Per questo motivo la crittografia a chiave condivisa non è con-
sigliata per pagamenti oltre un certo valore.
• Crittografia a chiave pubblica: il compratore ha una chiave
segreta per la firma, e un certificato per la corrispondente
chiave pubblica per la verifica della firma (certificato rilasciato,
per esempio, da una specifica autorità). Tale tipo di crittogra
fia consente di risolvere qualsiasi contesa tra mittente e desti
natario. In questo caso l’autenticazione off-line non comporta
alcun problema, dal momento che il venditore può facilmen-
te verificare la firma del compratore (e può confrontare il cer-
tificato del compratore con una propria “lista nera” di certifi-
cati, se necessario). L’autorizzazione richiede comunque o una
connessione in linea o la presenza di hardware affidabile pres-
so il compratore.
Con riguardo alle transazioni economiche tra Pubbliche Ammi-
nistrazioni ed utenti merita di essere segnalato il progetto volto a far
sì che la Carta Nazionale dei Servizi-CNS non sia soltanto una chiave
personale di accesso on-line alla P.A. ma anche strumento sicuro per i
pagamenti telematici di tasse, prestazioni e servizi erogati dagli uffici
pubblici, rendendo così più agevoli e comodi i rapporti che imprese e
cittadini intrattengono con la Pubblica ammini-strazione.
Grazie all’accordo siglato il  giugno  tra il CNIPA e l’e-Commit-
tee (Comitato di coordinamento delle infrastrutture per l’e-banking)
dell’ABI (Associazione Bancaria Italiana), si sono poste le basi per l’in-
serimento della Pubblica Amministrazione nel sistema “Bankpass Web”

consentendo così ai cittadini-utenti di farsi riconoscere e di richiedere
servizi on line alla Pubblica Amministrazione e, al tempo stesso, auto-
rizzare eventuali pagamenti.
Tale sistema è stato sperimentato a Bologna e a Verona e si intende
estenderlo progressivamente a tutto il territorio nazionale.
BANKPASS Web è un servizio che offre ai consumatori una soluzio-
ne per effettuare transazioni sicure su Internet tramite l’integrazione
di diversi strumenti di pagamento in un unico “portafoglio virtuale”
(wallet).
Tale wallet virtuale può contenere carte di credito bancarie, carte
di debito PagoBancomat, carte ricaricabili, ecc..
Il servizio consente agli utilizzatori di effettuare pagamenti su
Internet senza mai inserire i dati sensibili delle proprie carte di pa-
gamento. Il pagamento viene infatti avviato tramite l’utilizzo di una
coppia di chiavi di sicurezza (User ID e Password) che vengono asse-
gnate al momento della sottoscrizione del contratto presso una banca
distributrice.
Il cittadino, nel caso in cui debba acquistare servizi erogati da
una Pubblica Amministrazione, accede al sito Internet della stessa e
richiede di usufruire di un servizio a pagamento inserendo la propria
CNS in un apposito lettore per identificarsi.
Al momento del pagamento il sistema riconoscerà il cittadino/
titolare del wallet Bankpass Web e aprirà automaticamente il portafo-
glio virtuale consentendo al consumatore di scegliere lo strumento di
pagamento con cui desidera concludere la transazione senza chiedergli
di autenticarsi con user id e password.
Questa modalità di riconoscimento per il momento è valida so-
lamente per i servizi offerti dalla Pubblica Amministrazione per cui è
richiesta l’identificazione del cittadino tramite CNS e solo se al wallet
Bankpass è stata precedentemente associata la CNS del titolare del wallet.
E’ da rilevare il fatto che la piattaforma tecnologica realizzata da
e-Committee è condivisa ed utilizzata dalla maggior parte delle ban-
che presenti nelle aree interessate dai progetti di e-Government e può
essere gestito da più società, nel rispetto del Regolamento di Bankpass
Web, definito dalla stesso e-Committee.
2.3.3 Tutela della privacy

Un ambito sempre più rilevante del tema della sicurezza dei dati
e della loro protezione dalle eventuali intrusioni di agenti esterni, è
rappresentato ultimamente dalla questione legata alla privacy.

Sotto questa etichetta stanno una serie di regole, norme, azioni e stru-
menti, ai quali ogni organizzazione (e per certi versi ogni singolo cit-
tadino) deve far ricorso al fine di assicurare l’effettiva protezione, se-
condo degli standard condivisi, di tutta una serie di dati personali e
aziendali.
In estrema sintesi ogni organizzazione e ogni individuo che nel-
l’esercizio delle proprie funzioni si trovi a gestire, memorizzare e/o
scambiare dati personali riguardanti membri della propria organiz-
zazione e terzi, deve garantire che gli stessi vengano detenuti presso
sistemi di archiviazione protetti da intrusioni esterne, ma soprattutto
deve dichiarare ex-ante l’approccio seguito nell’archiviazione e gestione
degli stessi dati.
Le Pubbliche Amministrazioni che agiscono perseguendo finalità
istituzionali (come è l’erogazione di pubblici servizi anche attraverso
modalità e strumenti innovativi) non sono tenute a chiedere esplicita
autorizzazione ai proprietari degli stessi dati.
La normativa di riferimento, recentemente innovata, fa esplicito
riferimento ai dati conservati su supporto informatizzato e/o gestiti
avvalendosi dell’uso di calcolatori.
In tal senso ogni individuo che interagisca con il flusso di dati
di questa natura, provvedendo all’archiviazione, alla conservazione o
all’aggiornamento, deve essere esplicitamente incaricato dall’azienda,
che parimenti è obbligata a nominare un responsabile del trattamento
dei dati, il quale risponde in solido con gli amministratori/rappresen-
tanti legali nei confronti dei terzi per eventuali casi di danno causato a
terzi dalla gestione non idonea dei dati.
Tutto questo insieme di regole e procedure è ulteriormente aggra-
vato nel caso ci si trovi di fronte alla gestione di dati così detti sensibili
(riguardanti nello specifico dati di natura legale, medica ecc.). In tutti
questi casi occorre una ulteriore esplicita dichiarazione delle modalità
secondo le quali avviene il trattamento dei dati e un incarico specifico
agli addetti al trattamento.
In sintesi riguardo a questo aspetto appare necessario esplicitare quanto
segue: “I dati sensibili e giudiziari contenuti in elenchi, registri o ban-
che di dati, tenuti con l’ausilio di strumenti elettronici, sono trattati
con tecniche di cifratura o mediante l’utilizzo di codici identificativi o
di altre soluzioni che, considerato il numero e la natura dei dati trattati,
li rendono temporaneamente inintelligibili anche a chi è autorizzato
ad accedervi e permettono di identificare gli interessati solo in caso di
necessità” (fonte: dlgs /).

Quanto finora esposto comporta una serie di azioni specifiche da
porre in essere a cura dell’Amministrazione nel caso la stessa si trovi a
gestire, nell’ambito di un progetto di e-government, dei dati di natura
personale. Ciò comporta ovviamente la necessità di tenere conto di
queste problematiche in sede di progettazione preventiva, e ha delle
ricadute sulle successive fasi di attuazione del progetto e di erogazione
dei servizi.
Queste ricadute sono così sintetizzabili:
• nella necessità di proteggere adeguatamente i dati personali ed
eventualmente sensibili da intrusioni esterne (la protezione da
deterioramento dei supporti informatici e/o da agenti che
possano causare la perdita parziale o totale di dati non è stret-
tamente rilevante in questo caso), che possano comportare la
sottrazione e/o la cessione a terzi dei dati gestiti (eventi che
l’amministrazione si impegna a scongiurare, e rispetto ai quali
si assume preventivamente la responsabilità);
• di predisporre meccanismi di archiviazione e codifica dei dati
sensibili idonei a non renderli immediatamente leggibili an-
che agli operatori autorizzati, se non in caso di necessità;
• di regolare lo scambio di dati con altre Pubbliche Ammini
strazioni, verificando che lo stesso avvenga solo se esplicita
mente richiesto dalla normativa vigente;
• nella necessità di essere in grado in ogni momento di dimostrare:
- che il trattamento dei dati avviene a cura di personale incari
cato e nelle modalità consone;
- le singole responsabilità, anche individuali, in caso di eventi
come quelli appena descritti.
Tutto ciò comporta la necessità pratica di dotarsi di strumenti in grado
di tracciare gli eventi eseguiti sulla base di dati, e di attribuire ad ogni
azione una responsabilità.
Tale risultato è ottenibile pensando e realizzando:
• strumenti che consentano accessi controllati (attraverso log in)
al sistema di gestione dei dati e che siano in grado di monito-
rare e registrare le sessioni di lavoro;
• sistemi evoluti e regole precise di archiviazione e lettura dei
dati stessi.

3. I presupposti tecnologici ed infrastrutturali
3.1 La tecnologia del certificato digitale

3.1.1 Concetti generali
Come anticipato, la tecnologia legata ai certificati digitali rende,
di fatto, possibile, sia la sicurezza delle comunicazioni via Internet che
l’autenticazione di documenti elettronici tramite firma digitale. Si in-
tende, qui, approfondire le modalità del loro utilizzo e i meccanismi
alla base del loro funzionamento.
Un certificato digitale è un file che può essere paragonato ad un
passaporto, o ad una carta di identità, cioè ad un documento di rico-
noscimento rilasciato da un’Autorità di Certificazione (CA nel seguito)
universalmente nota, accettata e riconosciuta come affidabile, e utiliz-
zata per autenticare l’identità di un soggetto. Le CA svolgono, cioè, il
ruolo di garanti dell’identità di chi usa il certificato da loro rilasciato.
Hanno anche il compito di mantenere un pubblico registro dei certi-
ficati emessi e una Lista dei Certificati Revocati (Certification Revoca-
tion List) disponibile per la verifica per via telematica da parte di tutti
gli utenti della validità del certificato.
I certificati digitali vengono utilizzati non solo per garantire l’iden-
tità di un soggetto fisico che ne fa uso ma anche di un sito Internet o
di un software. Per comunicare ed effettuare con fiducia transazioni via
Internet, aziende e persone devono essere in grado di identificare gli
individui con cui hanno a che fare e di assicurarsi che le informazioni
scambiate on-line siano al sicuro da intercettazioni e alterazioni.
Il meccanismo su cui si basa il loro utilizzo è la crittografia, che
consiste nell’applicazione di un algoritmo ad un messaggio che lo ren-
de illeggibile a meno di non possedere la chiave di decifratura.
In generale un sistema crittografico può trasformare un file di
dati in un insieme di simboli incomprensibili a chiunque non possieda
lo strumento per decifrarli. Un qualunque messaggio viene nascosto
(crittografato) in modo che esista un altro procedimento simile che
consenta di risalire al messaggio originale, è cioè un sistema reversibile.
Le principali tecniche crittografiche sono:
1. La tecnica di crittografia a chiave privata o simmetrica, pre-
vede l’esistenza di una sola chiave da utilizzare per cifrare e

decifrare il messaggio che si intende inviare. Ciò comporta la
necessità, una volta crittografato il messaggio, di trasmettere al
destinatario la chiave segreta per decifrarlo, con il rischio che
questa venga intercettata da un terzo. Se non si hanno sistemi
sicuri la chiave può essere facilmente scoperta e usata da chiun-
que abbia interesse;
2. Nel caso di crittografia a chiave pubblica o asimmetriche, si
ottiene invece una coppia di chiavi asimmetriche, una privata,
che conosce solo il sottoscrittore, il quale ha anche l’obbligo di
custodirla, e l’altra pubblica, custodita da un terzo garante – il
certificatore – che ha l’obbligo di renderla pubblica a chiunque
abbia necessità di decodificare un messaggio criptato con la
chiave privata del sottoscrittore.
Il messaggio può essere cifrato in due modi: il mittente può co-
dificare il messaggio con la chiave pubblica del destinatario - nota e
resa disponibile dalle CA - il quale, per decodificare il messaggio, usa la
propria chiave privata, nota solo a questi.
Oppure si può operare al contrario: il mittente cifra il messaggio
da inviare con la propria chiave privata e il destinatario lo decifrerà con
la chiave pubblica del mittente. Se il destinatario riuscirà a leggere in
chiaro il messaggio decifrato con la chiave pubblica del mittente avrà la
certezza che il messaggio in questione viene proprio da quel soggetto.
Anche in questo caso la sicurezza della chiave privata spetta al sotto-
scrittore, mentre la sicurezza di quella pubblica è garantita dalla CA,
che la renderà disponibile a chi ne farà richiesta.
È opportuno rilevare che la conoscenza della chiave resa pubblica
non fornisce alcuna informazione sulla correlata chiave privata, né può
essere strumento per riuscire a ricavarla. La chiave pubblica è solo il
mezzo per codificare o decodificare un testo su un supporto elettronico.
3.1.2 Il certificato digitale

Tornando al certificato digitale, siamo ora in grado di dettagliar-
ne meglio il contenuto. Il file, oltre ai dati anagrafici del sottoscrittore,
contiene la sua chiave pubblica (sia esso una persona fisica o un di-
spositivo hardware) firmata digitalmente dalla chiave privata di una
Autorità di Certificazione. Esistono più tipologie di certificati digitali
che, pur sfruttando le potenzialità della crittografia, hanno obiettivi
diversi:
• Accesso sicuro ad un portale: il certificato digitale funziona

come chiave d’accesso a determinate pagine Internet o a
particolari servizi. Anziché fornire all’utente username e pas-
sword (o un codice pin) si provvede a dotarlo di un certificato
digitale, che dovrà essere caricato sul proprio pc. In tal modo
si ottiene il vantaggio di evitare che altre persone possano ac-
cedere in luogo di quel determinato utente in quanto il certi-
ficato digitale è strettamente personale.
• Firma di un documento: il certificato digitale permette di ap-
porre una firma digitale ad un documento informatico. Que
sto significa che, quando il messaggio giunge al destinatario,
la firma digitale apposta alla e-mail fornisce la garanzia che il
messaggio è stato scritto e spedito effettivamente dal mittente.
• Crittografatura di un documento: viene utilizzata la chiave
pubblica contenuta nel certificato per crittografare e spedire
un messaggio al titolare del certificato stesso, con la sicurezza
che nessun altro potrà leggere il contenuto del messaggio (in
fatti solo il titolare è in possesso della corrispondente chiave
privata per decifrare il messaggio).
• Firma e crittografatura di un documento: le due opzioni pos-
sono essere sommate per dare la garanzia al destinatario che il
messaggio può essere letto solo da lui ed è stato inviato da
una persona ben precisa.
Il formato standard più diffuso di certificato digitale è l’X..,
contenente, in uno standard riconosciuto, una serie di dati obbligatori
ai quali possono essere aggiunte ulteriori estensioni per riportare infor-
mazioni aggiuntive.
Un certificato digitale contiene sempre i seguenti elementi:
• numero di serie del certificato;
• ragione e denominazione sociale del certificatore;
• dati identificativi del titolare della chiave pubblica;
• valore della chiave pubblica;
• periodo di validità delle chiavi.
Il certificato contiene anche le informazioni sulla validità tem-
porale dello stesso. Ciò è dovuto al fatto che la sicurezza di qualsiasi
sistema di “cifratura” non è assoluta, ma relativa al tempo necessario a
terzi per risalire alla chiave segreta con la tecnologia attualmente dispo-
nibile: tempo molto maggiore di quello che si attribuisce come periodo
di validità del certificato e delle chiavi.
Generalmente il certificato digitale ha validità biennale.
3.1.3 Le infrastrutture a chiave pubblica
Attraverso i certificati digitali è possibile realizzare una struttura
gerarchica di autenticazione, nella quale una Autorità di Certificazione
Primaria (Primary Certification Authority - PCA) autentica l’identità
di Autorità di Certificazione sottostanti, autorizzandole ad autenticare,
a loro volta, l’identità di altre Autorità di Certificazione o di utenti
finali. Tale tipo di struttura gerarchica viene definito PKI - Public Key
Infrastructure (Infrastruttura a Chiave Pubblica).
L’implementazione di una PKI deve tenere conto di una serie di

requisiti progettuali che si possono sintetizzare nei seguenti:
• supporto per applicazioni multiple: una stessa infrastruttura
deve garantire il supporto per molteplici applicazioni (posta
elettronica sicura, applicazioni Web, trasferimento di file sicu-
ro); il modello di gestione della sicurezza deve essere consisten-
te e uniforme per tutte le applicazioni;
• interoperabilità tra infrastrutture differenti: in presenza di
domini di sicurezza distinti, ognuno amministrato da un’in-
frastruttura specifica, è richiesta l’interoperabilità delle varie
infrastrutture al fine di garantire il raggiungimento di un buon
livello di scalabilità;
• supporto per una molteplicità di politiche: cammini di cer-
tificazione considerati appropriati per un’applicazione, posso-
no non essere considerati altrettanto validi per un’altra applica
zione; ci si potrebbe ad esempio fidare di un’autorità di certifi
cazione che certifica web server relativamente a transazioni co
merciali di bassa entità, ma non relativamente a transazioni di

elevato valore; per rispondere, quindi, ad entrambi i requisiti
di scalabilità e supporto per applicazioni multiple, è necessario
implementare meccanismi che permettano da un lato di attri
buire politiche differenti ai vari cammini di certificazione dal
l’altro di associare ad ogni applicazione una politica di sicurez
za specifica;
• aderenza agli standard: una vera interoperabilità tra PKI di
stinte è ottenibile soltanto con l’adozione di standard che de-
finiscono i protocolli funzionali e di comunicazione relativi ai
componenti costitutivi di una infrastruttura a chiave pubblica.
Le infrastrutture a chiave pubblica forniscono il supporto neces-
sario alla tecnologia di crittografia a chiave pubblica, offrendo servizi
relativi alla gestione delle chiavi, dei certificati e delle politiche di si-
curezza.
Le componenti di una infrastruttura a chiave pubblica sono:
• Autorità di registrazione (che nel caso italiano coincide con
l’Autorità di certificazione): si occupa di accertare l’identità
dell’utente che richiede il certificato elettronico prima della ef
fettiva emissione dello stesso; è indispensabile procedere a tale
verifica dato che con l’emissione di un certificato elettronico
si rende pubblicamente valida l’associazione tra una certa chia-
ve pubblica e una certa entità. Una volta attestata la validità
dell’identità dell’utente attraverso una serie di procedure defi
nite nell’ambito di una precisa politica di sicurezza, l’autorità
di registrazione ha il compito di abilitare l’utente come appar
tenente ad uno specifico dominio di fiducia.
• Autorità di certificazione (che nel caso italiano funge anche
da Autorità di registrazione): costituisce la componente chiave
di una PKI; la funzionalità principale di un’autorità di certifi-
cazione consiste nel creare certificati elettronici; un’autorità di
certificazione tuttavia non si deve limitare esclusivamente alla
generazione dei certificati, ma deve poterne gestire l’intero ci-
clo di vita. Il ciclo di vita comprende le fasi di generazione,
aggiornamento (nel caso in cui il certificato stia per perdere va
lidità temporale), sostituzione (nel caso di scadenza della vali
dità temporale) e revoca nel caso in cui le condizioni di emis-
sione del certificato non siano più valide; compito ulteriore
dell’autorità di certificazione è stabilire relazioni di fiducia con
altri domini di fiducia gestiti da altre Autorità di certificazione.

• Sistema distribuito di directory: tale sistema costituisce un
elemento fondamentale per la distribuzione su larga scala delle
chiavi pubbliche utilizzate nella cifratura e nella firma dei dati;
il sistema di directory contiene i certificati a chiave pubblica,
reperibili dagli utenti quando necessario, e le liste contenenti
certificati a chiave pubblica sottoposti a revoca; l’obiettivo che
si intende raggiungere disponendo di directory pubbliche è
facilitare la gestione e la distribuzione di certificati elettronici
su larga scala.
• Autorità di timestamping: un problema fondamentale, nella
gestione del ciclo di vita di un documento elettronico firmato,
riguarda la collocazione temporale del documento stesso e
della firma digitale su di esso apposta: può accadere infatti che
un documento elettronico venga firmato con una chiave pri
vata relativa ad un certificato che ha esaurito il proprio perio
do di validità, oppure che è stato revocato dalla CA. Chi deve
verificare la firma, controllando la lista di revoca (CRL) emessa
dalla CA, può appurare se esse vada ritenuta valida o meno;
per poter fare questo, occorre però conoscere le posizioni tem
porali relative fra data di revoca del certificato e data di firma
del documento: se il documento è stato firmato prima che il
certificato venisse revocato, allora la firma è da ritenersi vali
da; viceversa, nel caso in cui il documento sia stato firmato
dopo la revoca del certificato, la firma non è valida. Risulta
quindi necessario, per far fronte al problema sopra delineato,
poter disporre di un servizio che fornisca un riferimento tem-
porale assoluto all’interno della CA: a questa esigenza viene
incontro il servizio di timestamping. Questo servizio fornisce
una marca temporale a chi ne fa richiesta: se un documento,
dopo essere stato firmato, viene inviato al server di timestam-
ping (TSS), esso pone una marca temporale sul documento,
e poi lo firma, collocando così la firma in un determinato
istante temporale. Anche ogni revoca di un certificato sarà
marcata temporalmente: avremo così gli elementi per poter
effettuare il confronto fra gli istanti di revoca del certificato e
di firma del documento. Quando il documento verrà restitui-
to marcato temporalmente, ad esso sarà allegato il certificato
contenente la chiave pubblica necessaria a verificare la firma
del TSS.
• Utenti finali: devono essere dotati di un software in grado di
interagire con tutte le componenti della PKI.
E’ essenziale che ogni PKI stabilisca relazioni di fiducia con PKI
esterne (si parla di cross certification), solo in questo modo si è in gra-
do di stabilire dei corretti cammini di certificazione.
3.2 Interoperabilità e standardizzazione

Il concetto di interoperabilità indica la possibilità per un sistema
ricevente di una certa amministrazione di trattare automaticamente le
informazioni trasmesse dal sistema di mittente di un’altra amministra-
zione o di un cittadino al fine di automatizzare le attività e i processi
sottostanti.
Con riguardo alla Pubblica Amministrazione il nuovo paradig-
ma di riferimento risulta dunque di difficile compatibilità con il tradi-
zionale modello di azione diffuso nella stessa.
Questo infatti tendeva storicamente ad adottare sistemi di infor-
mazione a compartimenti stagni.
Essere interoperabili al proprio interno significa consentire alle
informazioni di circolare in sicurezza e tuttavia semplicemente, al fine
di accrescere l’efficienza complessiva del processo.
E’ questo il presupposto per estendere lo stesso modello all’ester-
no, in modo da poter cooperare efficacemente con tutte le altre orga-
nizzazioni coinvolte e con il destinatario finale del procedimento.
Nel dibattito dottrinale si è andata consolidando una classifica-
zione della interoperabilità che verte su tre aspetti distinti:
• l’interoperabilità tecnica, che concerne questioni tecniche di
collegamento tra sistemi, la definizione delle interfacce, il for
mato dei dati e i protocolli, comprese le telecomunicazioni;
• l’interoperabilità semantica, che si occupa di assicurare che
il significato esatto delle informazioni scambiate sia compren-
sibile da qualsiasi altra applicazione, anche non pensata inizial
mente per quel determinato scopo;
• l’interoperabilità gestionale, che si occupa di modellare i pro-
cessi di lavoro, allineando le architetture dell’informazione con
gli obiettivi dell’organizzazione, e di aiutare i processi di busi-
ness nella cooperazione.
In concreto riteniamo possibile distinguere da un lato quelle che
sono le problematiche connesse alla interoperabilità tecnica inerenti
gli aspetti hardware e software; dall’altro quelle concernenti l’interope-
rabilità semantica e gestionale che tratteremo congiuntamente presen-
tando numerosi punti di connessione e costituendo l’aspetto al tempo

stesso più critico e strategico di questa tematica.
Riteniamo inoltre possibile collocare a un livello intermedio, ri-
spetto ai due sopra definiti, la problematica dell’interoperabilità con-
nessa alla firma digitale in quanto essa presenta sia aspetti di tipo tec-
nico che di tipo semantico.
3.2.1 Interoperabilità tecnica

In questo ambito si inseriscono tutte le problematiche connes-
se all’utilizzo di tecnologie e strumenti altamente innovativi, che non
sempre sono attuabili utilizzando infrastrutture tecnologiche (personal
computer, reti e connessioni) obsolete, o semplicemente non aggiorna-
te rispetto agli ultimi standard.
Ciò che occorre dunque fare in via preventiva rispetto all’avvio/
sperimentazione del progetto di e-government è una puntuale verifica
di quali siano gli standard tecnologici minimi che debbano caratteriz-
zare gli strumenti attraverso cui è gestito il processo che si decide di
innovare.
La risposta che può essere data a tale problema non può che es-
sere comunque quella di scegliere di adeguare le infrastrutture che non
dovessero soddisfare tale vincolo tecnologico, pena l’inattuabilità del
progetto.
In seguito all’analisi del gap esistente tra le proprie dotazioni tec-
nologiche e quelle necessarie, va stabilito un percorso di adeguamento,
che può essere volto alla semplice risposta puntuale alle nuove esigenze
oppure può inserirsi in una politica di innovazione complessiva delle
dotazioni tecnologiche.
Ciò di cui si dovrà tenere conto è che l’adeguamento delle do-
tazioni tecnologiche non riguarda solo l’Ente attuatore del progetto,
ma insiste anche su tutti gli attori coinvolti nello stesso, siano essi altre
Pubbliche Amministrazioni o utenti finali/destinatari. La criticità di
tale variabile è sempre da tenere presente in quanto non sempre si han-
no a disposizione le leve gestionali per poterla correttamente gestire.
In molti casi la soluzione attuata è una “convivenza” tra vecchie e
nuove procedure e modalità di interazione, tali da favorire l’interazione
evoluta da parte di coloro che riescono a rispondere al vincolo tecnolo-
gico, mantenendo comunque inalterata la possibilità di operare di chi
non risponde a tali standard, almeno nella fase iniziale.
Una ulteriore problematica è rappresentata dalla “disponibilità
delle librerie necessarie”; è infatti necessario che i software impiegati
nella gestione del processo che si vuole innovare abbiano determinate
caratteristiche.
Tale problematica, al contrario di quella vista sopra, ha una con-
figurazione “asimmetrica”, nel senso che investe maggiormente l’Ente
attuatore rispetto agli altri attori.
Se ad esempio si pensa all’applicazione della firma digitale, si
può subito notare come, indipendentemente da quale sia il software
di sottoscrizione o l’Ente che ha fornito il certificato di firma, e dun-
que indipendentemente dagli strumenti impiegati dal singolo utente,
l’Ente che si trova nel ruolo del destinatario delle richieste/domande,
deve essere in grado di “leggere” tutti i documenti inviati (ovviamente
inviati impiegando tecnologie standard e compatibili).
Ciò pone un problema di disponibilità e aggiornamento di tutti
i software potenzialmente utilizzabili dall’utenza per la sottoscrizione e
la trasmissione, al fine di garantire a tutti pari opportunità.
Si deve inoltre prendere in considerazione il fatto che un utente
dotato di firma digitale potrebbe relazionarsi con una pluralità di sog-
getti; tale soggetto in assenza di una piena interoperabilità tecnica po-
trebbe scontrarsi con la circostanza che per compiere due diverse ope-
razioni dovrebbe essere dotato di due card e di altrettanti supporti.
Esemplificativo può essere il caso di una Società che per ricevere
determinati finanziamenti si relazionerà con il sistema implementato
dalla Regione ed utilizzerà la card da questa rilasciata mentre per l’invio
dei bilanci utilizzerà il sistema della Camera di Commercio e la card
rilasciatagli dalla CCIA.
In presenza di una piena interoperabilità tecnica al soggetto dovreb-
be essere consentito compiere queste operazioni grazie ad una sola card.
3.2.2 Interoperabilità e firma digitale

Per interoperabilità delle firme digitali si intende la possibilità che
un qualsiasi documento elettronico firmato da un soggetto mittente,
che utilizza i servizi di un determinato certificatore, possa essere corret-
tamente trattato da un soggetto destinatario che utilizza i servizi offerti
da un diverso certificatore.
Ove non fosse assicurata l’interoperabilità come sopra definita, lo
scambio di documenti elettronici potrebbe avvenire solo nella cerchia
ristretta dei soggetti che utilizzano un medesimo certificatore.
In termini generali il processo di firma di un documento elettro-
nico, dopo che il firmatario abbia verificato il contenuto del documen-
to da sottoscrivere, comporta i seguenti passi:
1. generazione dell’impronta del documento elettronico;
2. firma, tramite la chiave privata accessibile solo previo inseri-

mento del PIN, dell’impronta del documento elettronico (tut-
to ciò corrisponde alla firma del documento);
3. creazione di una “busta elettronica” che contiene il documen-
to, la firma definita come al punto precedente e il certificato
che collega la chiave privata al suo possessore cioè, in questo
caso, al firmatario.
A sua volta il destinatario dovrà essere in grado di eseguire il pro-
cesso di verifica e in particolare di:
1. aprire la “busta elettronica”;
2. verificare se il certificato del firmatario è “fidato”, ossia se rila-
sciato da un certificatore inserito nell’elenco pubblico dei cer-
tificatori accreditati;
3. verificare l’impronta del documento elettronico con la chiave
pubblica del firmatario estratta dal certificato (tutto ciò corri-
sponde alla verifica della firma e della integrità del documento);
4. calcolare l’impronta del documento elettronico e confrontare
il valore ottenuto con quello firmato ai fini dell’integrità del
messaggio;
5. aprire il certificato e leggere l’identità del soggetto per verifica-
re l’identità del mittente e la validità temporale della sua firma;
per effettuare tale verifica dovrà accedere ad una speciale lista
(Certification Revocation List) generata da ogni certificatore e
ricercare se il certificato ricevuto appartenga alla lista oppure
no; in caso negativo, il certificato deve essere considerato anco-
ra valido e pertanto il documento elettronico può considerarsi
valido.
Per assicurare l’interoperabilità dei processi di firma e di verifica
allorquando mittente e destinatario utilizzino i servizi offerti da due
diversi certificatori, occorre che il sistema di verifica fornito da ciascun
certificatore sia sempre in grado di:
1. riconoscere il formato della busta elettronica;
2. aprire la busta stessa ed estrarre le informazioni in essa contenute;
3. leggere il contenuto del certificato ed estrarre correttamente
l’identità della persona che ha firmato e la relativa chiave
pubblica;
4. capire quale algoritmo sia stato utilizzato per ottenere l’im-
pronta del documento elettronico e applicare lo stesso algorit-
mo al documento estratto dalla busta elettronica;
5. verificare la validità del certificato sulle liste di revoca o sospen-
sione del certificatore che lo ha rilasciato.
Quanto sopra, e cioè l’interoperabilità, non è garantito dal sem-
plice rispetto delle vigenti regole tecniche in materia di firma digita-
le, che non possono individuare soluzioni tecniche univoche, essendo
vietato ogni riferimento diretto a tecniche specifiche, per evitare l’in-
sorgere di squilibri del mercato o di escludere a priori di una serie di
fornitori di tecnologie.
Al fine di assicurare l’interoperabilità almeno con riferimen-
to all’ambito della Pubblica Amministrazione, l’AIPA (ora CNIPA)
nel corso dell’anno  ha emanato la circolare AIPA/CR/24 del
//, recante “Le linee guida per l’interoperabilità dei certificato-
ri”, consistenti in un insieme di specifiche tecniche univoche definite
con il contributo dei primi certificatori iscritti nell’elenco pubblico e
con l’apporto della Banca d’Italia.
Dette linee guide considerano, ai fini dell’interoperabilità:
• i contenuti del certificato e la loro rappresentazione e formato;
• le estensioni del certificato e i relativi contatti;
• le liste di revoca e sospensione e i relativi contenuti;
• la rappresentazione delle informazioni nelle buste PKCS#7.
3.2.3 Interoperabilità semantica e gestionale

Tale tematica ricomprende da un lato problematiche relative alla co-
municazione tra sistemi e allo scambio di informazioni, dall’altro proble-
matiche organizzative legate alla reingegnerizzazione dei processi di lavoro.
Tali aspetti non sono stati al momento ancora affrontati in un’ot-
tica generale ma ci si è limitati ad occuparsene relativamente a singoli
sistemi. Si è di conseguenza cercato di creare sistemi all’interno dei
quali le informazioni scambiate fossero comprensibili da qualsiasi ap-
plicazione e che avessero come utilizzatori organizzazioni con strutture
e processi di lavoro funzionali e conseguenti alle nuove architetture
dell’informazione.
L’aspetto della interoperabilità gestionale è probabilmente quello
più problematico poiché incide direttamente e profondamente sulle
modalità operative degli Enti, riguardando i dirigenti di ogni settore, e
modificando le abitudini di qualsiasi dipendente pubblico.
Il punto chiave è bene noto a tutte le (poche) organizzazioni,
pubbliche e private, che hanno provato a ridisegnare i propri processi
di lavoro a seguito dell’introduzione delle nuove tecnologie. I processi

vanno estesi fino ad includere partner, fornitori e utenti. Si pensi, ad
esempio, al fatto che il cittadino che compila modulistica on line è
come se entrasse nella sede dell’ente e si aggirasse tra gli uffici, aprendo
da solo cassetti per prendere moduli e timbri.
Essere interoperabili al proprio interno significa consentire alle
informazioni di circolare senza steccati, perseguendo la cooperazione al
posto della rigida suddivisione di mansioni e compiti, semplicemente
col fine di essere più efficienti. E’ questo il presupposto per estendere lo
stesso modello all’esterno, in modo da poter cooperare efficacemente
con tutte le altre organizzazioni.
3.3 Strumenti di identificazione

Gli strumenti di identificazione on line, quali la Carta di Identità
Elettronica e la Carta Nazionale dei Servizi, vengono individuati nelle
politiche di e-government come i mezzi attraverso i quali gli utenti
vengono riconosciuti in rete in modo certo al fine di usufruire dei ser-
vizi erogati per via telematica dalle amministrazioni pubbliche.
Tali strumenti risultano dunque funzionali ai progetti mirati al-
l’ammodernamento della pubblica amministrazione e al miglioramen-
to del dialogo tra uffici pubblici e cittadini.
In particolare sono da considerarsi indispensabili per lo sviluppo
dei servizi di e-government a maggior valore aggiunto, che necessitano
di condizioni di certezza e sicurezza (si pensi ad esempio agli accorgi-
menti da adottare in materia di accesso ad archivi personalizzati, tran-
sazioni ecc.).
3.3.1 La Carta d’Identità Elettronica

Per Carta d’Identità elettronica si intende il documento di rico-
noscimento personale rilasciato dal Comune su supporto informatico.
La CIE ha validità di cinque anni.
Il legislatore nel prevedere lo strumento della Carta d’Identità
Elettronica ha posto come elementi cardine del progetto:
• la sicurezza dello strumento: risponde all’esigenza di produrre
uno strumento sicuro sotto i diversi aspetti della produzione,
rilascio nonché utilizzo da parte del titolare. La sicurezza non
solo deve accompagnare tutti i flussi informatici necessari al
circuito di emissione, ma deve anche essere presente sul sup-
porto fisico al fine di scoraggiare tentativi di contraffazione,
nonché di consentire un’identificazione certa da parte delle
istituzioni competenti;

• l’interoperabilità a livello nazionale: consiste nella possibilità
di utilizzare il documento di identità come strumento per ac-
cedere ai servizi informatici, attraverso l’utilizzo di tecniche di
autenticazione opportunamente combinate alla specificazione
di un codice personale di identificazione (PIN);
• l’utilizzo della carta d’identità elettronica come carta servizi:
relativo alla necessità di disporre di un supporto in grado di
funzionare allo stesso modo e su tutto il territorio naziona-
le nei confronti delle pubbliche amministrazioni centrali. La
richiesta di un servizio ad una pubblica amministrazione cen-
trale deve essere uguale in tutti i Comuni e le diverse modalità
di richiesta, a parte i contenuti specifici del servizio coinvolto,
devono conservare, ai fini dell’usabilità da parte dell’utente, le
stesse caratteristiche di rappresentazione.
Il legislatore ha anche previsto che la CIE possa essere utilizza-
ta per il trasferimento elettronico dei pagamenti tra soggetti privati e
pubbliche amministrazioni, previa definizione, d’intesa tra il Comune
interessato e l’intermediario incaricato di effettuare il pagamento, delle
modalità di inserimento e validazione dei dati necessari.
Con riguardo alla CIE si è avuta una prima sperimentazione che
ha portato al rilascio effettivo di circa  mila card in  Comuni ita-
liani. Successivamente il Ministero dell’interno, d’intesa con il Mini-
stro per l’Innovazione e le Tecnologie, ha varato la II fase del progetto
in cui, recependo le indicazioni emerse dalla fase pilota, sono state va-
rate le nuove caratteristiche organizzative e tecniche delle infrastrutture
necessarie per la diffusione più capillare del nuovo strumento.
E’ in atto la diffusione vera e propria nei  comuni che hanno
aderito alla II fase. Saranno distribuiti altri mila esemplari a coloro
che, avendo superato i  anni di età, ne faranno richiesta.
Nella fase di sperimentazione è stata realizzata l’infrastruttura di
accesso (sicura e certificata) ai servizi anagrafici, demografici e di con-
valida dei dati anagrafici in oltre . comuni (su ) con più di 
milioni di posizioni controllate e allineate. Nei comuni sperimentatori
sono stati complessivamente implementati  servizi tra i quali l’ac-
cesso ai servizi demografici (in  comuni) e tributari (), il pagamen-
to elettronico di imposte, contravvenzioni e tributi (), lo sportello
telematico municipale (), l’autocertificazione assistita (), i sondaggi
on-line (), l’anagrafe on-line (13), lo stato di avanzamento delle pra-
tiche () e i servizi di autorizzazione e concessione ().

A supporto delle attività è stato istituito un gruppo di lavoro in-
terministeriale a sua volta articolato in un sottogruppo organizzativo-
giuridico-amministrativo e in uno tecnico-scientifico.
3.3.2 La Carta Nazionale dei servizi

La Carta nazionale dei servizi è stata oggetto del recente DPR
/ nel quale si prevede che in attesa della carta d’identità elet-
tronica essa sia emessa dalle pubbliche amministrazioni interessate al
fine di anticiparne le funzioni di accesso ai servizi in rete delle stesse.
La CNS, diversamente dalla CIE non è un documento per l’iden-
tificazione “a vista” ma costituisce solamente uno strumento di identi-
ficazione in rete.
All’emissione provvedono, su richiesta del soggetto interessato, le
P.A. che intendono rilasciarla, previa identificazione del titolare.
La CNS contiene:
• un certificato di autenticazione, consistente nell’attestato elet-
tronico che assicura l’autenticità delle informazioni necessarie
per l’identificazione in rete del titolare della carta, rilasciato da
un certificatore accreditato;
• i dati identificativi del titolare;
• il codice numerico di identificazione della carta, nonché le
date del suo rilascio e della sua scadenza.
La CNS può contenere le informazioni necessarie per apporre
firme digitali.
La CNS ha la validità temporale determinata dall’amministrazio-
ne emittente, comunque non superiore a sei anni.
Tutte le pubbliche amministrazioni che erogano servizi in rete
devono consentire l’accesso ai servizi medesimi da parte dei titolari del-
la carta nazionale dei servizi indipendentemente dall’ente di emissione,
che e’ responsabile del suo rilascio.
3.3.3 Le Carte Regionali dei Servizi

3.3.3.1 Regione Lombardia
Il progetto CRS-SISS prevede l’utilizzo delle infrastrutture di rete
e della Carta a microprocessore per il miglioramento dei Servizi al Cit-
tadino in Lombardia.
La Regione Lombardia ha incaricato Lombardia Informatica di
realizzare il progetto avvalendosi della società LISIT, appositamente
costituita, e di un gruppo di Partner (Telecom Itala, Finisiel, Lutech)

costituitisi in RTI e partecipanti al capitale azionario LISIT in grado di
assicurare la realizzazione di tutte le componenti del progetto. Lombar-
dia Informatica S.p.A.: braccio operativo della Regione per l’ICT, ha in
carico il coordinamento e la supervisione tecnica del progetto (Project
Management).
Con l’acronimo SISS si indica il Sistema Informativo Socio Sa-
nitario ovvero la extranet che connette tutti gli operatori e le strutture
sanitarie della Lombardia.
All’interno del progetto si vengono a prevedere due carte: la CRS
destinata ai cittadini e la Carta Siss destinata agli operatori.
Carta Regionale dei Servizi

La Carta CRS permetterà di accedere ai servizi che la Regione
Lombardia e, in un secondo momento, altre Pubbliche Amministra-
zioni renderanno progressivamente disponibili.
Si prevede che la Carta Regionale dei Servizi possa essere utiliz-
zata dal medico curante, in farmacia, in una struttura ospedaliera o
negli uffici della ASL e permetta di accedere ai dati sanitari aggiornati
e ad informazioni cliniche relative all’assistito. Tali informazioni sa-
ranno leggibili soltanto attraverso appositi terminali e potranno essere
utilizzate dal medico di fiducia e dagli operatori socio-sanitari abilitati.
La Carta CRS darà inoltre accesso ad un sistema che permette di fare
prenotazioni a distanza.
La Carta Regionale dei Servizi sostituisce da subito la Tessera Sa-
nitaria Cartacea.
Infine, la nuova Carta CRS fungerà anche da Tessera Europea di
Assicurazione Malattia, consentendo di beneficiare dell’assistenza sani-
taria nei paesi europei, in sostituzione del modello E-111.
Funzioni della Carta Regionale dei Servizi:
•
Identifica e autentica il titolare
•
Registra informazioni sanitarie utili per emergenze
•
Sostituisce l’attuale tesserino sanitario cartaceo e il CF
•
Sostituisce l’attuale tesserino esenzioni cartaceo
•
Funge da Carta Europea mod. E111
•
Consente agli operatori sanitari di accedere a tutti i dati del
titolare
Contenuto della Carta Regionale dei Servizi:
• Dati amministrativi

• Dati sanitari di emergenza
• Dati anagrafici
• Possibilità di inserire la firma digitale
• 6 Kb per servizi privati
Nel caso delle smart card del cittadino, Regione Lombardia ha
in corso di definizione un accordo con la Pubblica Amministrazione
Centrale per far sì che la carta CRS sia la Carta Nazionale dei Servizi
(CNS) per la Lombardia. A questo fine LISIT e i Partner dovranno
assicurare la conformità della carta CRS con la carta CNS.
Carta SISS
Funzioni della Carta Siss:
• Identifica ed autentica l’operatore
• Consente all’operatore sanitario di utilizzare il SISS
• Permette l’accesso ai dati clinici dei cittadini (conformemente
al ruolo dell’operatore)
• Permette di aggiornare la storia clinica dei cittadini
Contenuto della Carta Siss:
• Dati anagrafici
• Firma digitale
• Cifratura
Risultati della sperimentazione nella Asl di Lecco

Situazione utenti attivati
Cittadini MMG/PLS Farmacie
320.339 Carte Cittadino 250 MMG/PLS Aderenti

89 Farmacie Attivate su 89
Circolanti; su 275;
52% Consensi Informati 90 Sale di Ambulatori
registrati Comunali attivate;
14 Cartelle Cliniche Inte-
Fonte: Relazione al
grate
Forum P.A. 2004

Situazione strutture attivate
Azienda Sanitaria Azienda Enti Erogatori Enti gestori

Locale Ospedaliera Privati delle Assi
15 Presidi di Scelta 3 Presidi Avviati; Mangioni 6 Residenze Sani-
e Revoca; tarie
ed Assistenziali per
Anziani (RSA)
23 Postazioni di 230 Postazioni di 8 Sportelli con 10 Consultori
Lavoro Attivate Lavoro Attivate Identificazione Familiari Pubblici
Cittadino tramite
Carta;
20 Branche Specia- 100 Prestazioni
listiche Prenotabili; Prenotabili
250 Prestazioni Casa di cura di
Disponibili Lecco
12 Sportelli con
Identificazione
Fonte: Relazione Cittadino tramite
al Forum P.A. 2004 Carta
I risultati della sperimentazione su Lecco
Fonte: Relazione
al Forum P.A. 2004

3.3.3.2 Regione Lazio
Il progetto Cartalazio è stato realizzato da Laziomatica S.p.A.,
nell’ambito del piano di E-Government della Regione Lazio.
Il progetto, presentato a Forum P.A. , consta di due fasi:
• Prima fase: individuazione di . utenti pilota tra: farma-
cisti, medici di base, operatori ASL, sindaci, categorie profes-
sionali (architetti, ingegneri), dirigenti regionali; ad essi verrà
consegnata una smart card con firma digitale e autenticazione.
• Seconda fase: distribuzione massiva di smart card a tutti i cit-
tadini della Regione Lazio, ad essi verrà consegnata una smart
card con sola autenticazione.
Tale progetto ha come obiettivi:
• l’autenticazione univoca per tutti i Servizi che prevedono la
smart card;
• la diffusione degli strumenti di Firma Digitale;
• l’avviamento della Carta del Professionista;
• l’avviamento della Carta Nazionale dei Servizi per i cittadini.
CartaLazio non surroga il documento d’identità, non contiene
la foto del titolare e non è dunque sottoposta agli stessi requisiti di
sicurezza interna ed esterna previsti per Carta d’Identità Elettronica
(CIE).
Essa contiene invece un Certificato di Autenticazione Digitale
e di Firma Digitale che viene rilasciata dall’Amministrazione che la
emette, la quale è responsabile della verifica dell’identità del richieden-
te, della consegna fisica del supporto, della sua eventuale revoca, della
conservazione e della tutela dei dati personali.
L’accesso ai servizi può essere variabile, in funzione delle caratte-
ristiche di quello richiesto. Si hanno servizi ad accesso:
• libero;
• basato su codice identificativo e password;
• mediante carta a microchip con codice di autenticazione se-
condo lo standard previsto dalla Carta Nazionale dei Servizi
(come descritto nell’allegato 4 all’Avviso di selezione dei pro-
getti di e-government emessi dal Dipartimento per l’innova-
zione e le tecnologie);
• mediante carta a microchip con certificato di firma digitale a
norma;

• mediante carta a microchip o dispositivo equivalente, con cer-
tificato di autenticazione e/o di firma leggera.
L’obiettivo primario di CartaLazio è la possibilità di gestire le
diverse modalità di autenticazione univoca per tutte le Amministrazio-
ni interessate, semplificando l’accesso alle applicazioni informatiche e
fornendo un sistema ben strutturato per la gestione di certificazioni ed
autorizzazioni.
A questo scopo il progetto prevede la realizzazione e la messa in
opera della struttura tecnica ed organizzativa che, fruendo di servizi
erogati dalla Certification Authority, consenta l’avviamento della Car-
ta dei Servizi per i Cittadini e la diffusione degli strumenti di firma
digitale.
3.3.4 La Tessera Sanitaria

La tessera sanitaria è prevista dall’art. 50 della Legge 326/2003 al
fine di effettuare il monitoraggio della spesa farmaceutica e delle presta-
zioni specialistiche erogate dal Servizio Sanitario Nazionale. L’obiettivo
prioritario di tale monitoraggio è di pervenire alla auspicata apprio-
priatezza delle prescrizioni e, conseguentemente, al miglior governo e
razionalizzazione della spesa in campo sanitario.
Lo scopo del monitoraggio suddetto è, quindi, la conoscenza del-
la tipologia di spesa sanitaria al fine di pervenire al miglior grado di
appropriatezza delle prescrizioni sanitarie. Ciò costituisce un elemento
di notevole importanza per le decisioni di carattere economico-pro-
grammatico che la Regione dovrà assumere nella fase di adozione del
prossimo Bilancio e del Piano Sanitario Regionale.
La normativa sopra riportata prevede la consegna a tutti i citta-
dini della tessera sanitaria sulla quale è riportato il codice fiscale del
titolare in codice a barre e in banda magnetica. La tessera consente ai
cittadini sia l’accesso alle prestazioni specialistiche (visite, esami dia-
gnostici, di laboratorio, prestazioni specialistiche varie) sia l’erogazione
dei farmaci. Pertanto, senza la tessera sanitaria non sarà più possibile
ottenere tali prestazioni, se non dietro pagamento del corrispettivo da
parte del cittadino.
I dati relativi ai farmaci nonché alle prestazioni specialistiche ero-
gate su presentazione della tessera sanitaria verranno trasmessi, dalle
farmacie e dalle strutture erogatrici, per via telematica, al Ministero
delle Finanze per il monitoraggio della relativa spesa.
La Tessera sanitaria contiene:
• i dati anagrafici dell’assistito ed il codice fiscale;

• la data di scadenza valida ai soli fini dell’assistenza sanitaria (ad
esempio per gli stranieri con permesso di soggiorno);
• un’area libera per eventuali dati sanitari regionali;
• tre caratteri braille per i non vedenti;
• il codice fiscale in formato bar code e banda magnetica dell’as-
sistito e la Tessera europea di assicurazione di malattia (E111).
Quest’ultima potrà essere utilizzata, a partire dal mese di novem-
bre , per l’assistenza sanitaria nei Paesi dell’Unione europea e nei
Paesi aventi accordi bilaterali con l’Italia
Con riguardo alla modalità di funzionamento è da sottolineare,
come sopra precisato, che la tessera sanitaria reca il codice fiscale del
titolare in formato a codice a barre nonché in banda magnetica, quale
unico requisito necessario per l’accesso alle prestazioni a carico del Ser-
vizio sanitario nazionale (SSN).
All’atto dell’utilizzo di una ricetta medica recante la prescrizione
di farmaci, sono dunque rilevati otticamente i codici a barre relativi al
numero progressivo regionale della ricetta, ai dati delle singole con-
fezioni dei farmaci acquistati nonché il codice a barre della Tessera
sanitaria.
Riguardo allo stato attuale del progetto è da segnalare che a no-
vembre , con decreto, firmato dal Ministro dell’Economia e delle
Finanze e dal Ministro della Salute, è stata estesa a Umbria, Emilia
Romagna, Veneto e Lazio l’attivazione del sistema Tessera Sanitaria già
sperimentato in Abruzzo da luglio .
L’inizio della sperimentazione è previsto a novembre  in
Umbria, a gennaio  in Emilia Romagna, a febbraio  in Vene-
to e a marzo  in Lazio.
3.4 Firma digitale e autenticazione dei documenti

Come già anticipato, la tecnologia dei certificati digitali e, quin-
di, la crittografia a chiave pubblica, sta anche alla base del sistema di
autenticazione di documenti attraverso la firma digitale.
La tecnica crittografica, in questo caso, non viene utilizzata per
rendere il documento riservato ma solo, come meglio specificato in
seguito, per garantirne l’integrità e la provenienza.
3.4.1 Concetto e definizioni

I termini firma elettronica e firma digitale vengono erroneamente
utilizzati come sinonimi, sebbene tecnicamente ci si riferisca a due ri-
sultati diversi.
Per firma elettronica, esplicitamente considerata nella direttiva
comunitaria //CE, si intende qualunque mezzo informatico di
identificazione di un documento elettronico, cioè l’insieme di dati in
forma elettronica, allegati oppure connessi tramite un’associazione lo-
gica ad altri dati elettronici, utilizzati come metodo di autenticazione
informatica.
Questo tipo di firma assicura solo la provenienza del documento,
ma non offre alcuna garanzia circa l’integrità del contenuto.
La firma elettronica avanzata rappresenta un’evoluzione della
firma elettronica; come questa è ottenuta attraverso una qualunque
procedura informatica che garantisca la connessione univoca al fir-
matario e la sua univoca identificazione, creata con mezzi sui quali il
firmatario può operare un controllo esclusivo. Tale firma deve anche
essere collegata ai dati ai quali si riferisce in modo da consentire di
rilevare se i dati stessi siano stati successivamente modificati.
La firma digitale (tipico esempio di firma elettronica forte), se-
condo quanto scritto nel D.P.R. n. 513/199 e ripreso dal D.P.R. n.
445/200 è il
“risultato della procedura informatica (validazione) basata su un
sistema di chiavi asimmetriche a coppia, una pubblica e una pri-
vata, che consente al sottoscrittore, tramite la chiave privata, e al
destinatario, tramite la chiave pubblica, rispettivamente di rendere
manifesta e di verificare la provenienza e l’integrità di un documen-
to informatico o di un insieme di documenti informatici”.
La firma digitale è quindi un’informazione aggiunta ad un docu-
mento informatico al fine di garantirne l’esatta provenienza e l’assoluta
integrità rispetto al testo originale. Obiettivo naturale della firma di-
gitale è quello di permettere la sottoscrizione di documenti realizzati
su supporti informatici, snellendo le procedure di trasmissione di tali
documenti, mantenendone intatta l’integrità e garantendone la prove-
nienza.
Il legislatore europeo, dovendo fornire un quadro coerente a li-
vello comunitario per la regolamentazione delle firme elettroniche, si è
ispirato al principio di neutralità nei confronti della tecnologia, citan-
do espressamente la fattispecie della firma elettronica.
Il legislatore italiano invece, citando specificatamente la firma di-
gitale, ha stabilito requisiti più rigidi, al fine di equiparare questa ulti-
ma alla firma autografa per riconoscerle validità e rilevanza giuridica.
Affinché una tipologia di sottoscrizione, differente dalla firma
tradizionale su carta, possa rappresentarne giuridicamente una valida

sostituzione, è necessario che soddisfi tutti i requisiti tipici propri di
questa ultima.
La firma autografa attraverso la calligrafia, elemento identifica-
tivo della persona, è rivelatrice immediata dell’autore del documento,
quindi permette l’esatta identificazione del soggetto mittente di deter-
minati documenti; è inoltre esclusiva, e quindi indica solo un soggetto
firmatario. Apposta, inoltre, su ogni singola parte del documento ne
garantisce l’integrità del contenuto.
La firma digitale opera come la firma autografa grazie al requisito
di esclusività di cui gode la coppia di chiavi, assegnata ad un determi-
nato soggetto. È evidente che una coppia di chiavi indica uno e un solo
sottoscrittore. Inoltre, la pubblicazione della chiave pubblica nell’ap-
posito registro e la garanzia circa l’identità del sottoscrittore concessa
dal certificatore, permettono di individuare, senza alcun dubbio il mit-
tente/firmatario.
Infine la firma autografa non è riutilizzabile, è indissolubile ri-
spetto al supporto sul quale è impressa, non può essere trasportata su
un altro documento, è intrinsecamente legata al testo cui è apposta
tanto che i due oggetti, documento e firma, possono essere separati
fisicamente senza che il legame tra loro venga meno.
Ne segue che la firma digitale è sempre unica, a testi diversi corri-
sponderanno firme diverse. Ciò garantisce l’integrità del contenuto del
documento firmato digitalmente rispetto all’originale.
Infine la firma digitale può essere generata solo dal legittimo pro-
prietario. Il regolamento tecnico impone, infatti, che una coppia di
chiavi sia attribuibile ad un’unica persona fisica e rivolge particolare at-
tenzione ai requisiti di sicurezza dei dispositivi di custodia delle chiavi.
Nella tabella di seguito proponiamo un quadro completo e sinte-
tico delle diverse tipologie di firma elettronica citate dalla normativa.
Uso della firma digitale nella PA

Tabella 2.1.1: le tipologie di firma elettronica
Requisiti del Funzione dei
Tipo di firma Descrizione Effetti
certificatore certificati
Dati elettronici
allegati ad altri
dati elettronici,
Firma Sono gli stessi Collegano la firma Sul piano
utilizzati come
elettronica requisiti richie- elettronica al titolare probatorio sono
metodo di
sti per l’attività e ne confermano liberamente
autenticazione
bancaria e cre- l’identità valutabili in base
informatica
ditizia. L’attività alle caratteristiche
Firma
è libera e non di qualità e sicu-
elettronica
necessita di rezza del sistema
Firma creata con
autorizzazione di firma utilizzato
elettronica mezzi sui quali
preventiva
avanzata il firmatario ha
un controllo
esclusivo
Firma Sono gli stessi Contengono i dati Hanno piena
elettronica richiesti per previsti dalla validità giudica
avanzata, l’attività banca- normativa e sono e quindi
creata con un ria e creditizia, firmati digitalmente i documenti
dispositivo più alcuni di dal Certificatore che firmati in questo
Firma
sicuro, accom- affidabilità. È li ha rilasciati. modo hanno
elettronica
pagnata da richiesta una Tutte le operazioni pieno valore
qualificata
un certificato comunicazione relative a tali legale. Sul piano
rilasciato da di inizio attività certificati probatorio fanno
un Certificato- al M.I.T. (revoca,sospensione, piena prova di
re qualificato ecc.) sono oggetto autenticità.
Firma
elettronica
qualificata,
Gli stessi
è un’
requisiti
informazione
dell’attività
aggiunta ad
bancaria e
un documento
creditizia.
Firma digitale informatico al
In più è
fine di garan-
richiesto
tirne l’esatta
l’accreditamen-
provenienza
to presso
e l’assoluta
il M.I.T.
integrità
rispetto al
testo originale

La firma digitale è sicuramente utile e utilizzabile sia in ambito
pubblico – in relazione all’agire della P.A. – che in ambito privato,
come nel caso dei contratti stipulati a distanza.
La pubblica amministrazione italiana sta vivendo una sicura ri-
voluzione per quanto riguarda l’applicazione delle nuove tecnologie
in genere, e di strumenti di informatizzazione di documenti e proces-
si in particolare. Si attende ancora, tuttavia, la creazione di una Rete
Unitaria della P.A. che manterrà il dialogo con i cittadini attraverso
Internet.
Entro il //, anche se il termine non è perentorio, le P A. do-
vranno, anche se è meglio dire avrebbero dovuto, adottare il Protocollo
informatico.
In una accezione minimale avrebbero dunque dovuto quanto
meno trasformare gli archivi cartacei in archivi informatizzati.
Questo dovrebbe consentire un’accelerazione non solo nello
scambio di informazioni tra uffici ma anche nell’accesso alle stesse da
parte dei privati interessati e, in ultima analisi una riduzione dei tempi
di erogazione di una serie di servizi al cittadino.
Occorre precisare che esistono due tipi di documenti amministra-
tivi: quelli a rilevanza interna, per i quali non è indispensabile l’utilizzo
della firma digitale, e quelli a rilevanza esterna, che, invece, richiedono
la firma digitale, idonea a identificare il sottoscrittore.
Trattando di firma digitale ci si riferisce dunque alla seconda ti-
pologia di documenti.
3.4.2 La questione del non ripudio della firma digitale

3.4.2.1 Situazione attuale
Al secondo comma dell’art. 10 del DPR 445/00 (Testo unico delle
disposizioni legislative e regolamentari in materia di documentazione
amministrativa) il legislatore prende in considerazione il documento
informatico sottoscritto con firma elettronica. La firma elettronica leg-
gera non è altro che un sistema di identificazione alla base del quale vi
è sempre la crittografia asimmetrica, ma manca una terza parte fidata
che garantisca sia sulla vigenza della validità della coppia di chiavi, sia
l’identità del titolare della stessa. Si accede, quindi, ad un programma
di firma, si genera la coppia di chiavi e da questo momento sarà possi-
bile firmare elettronicamente qualsiasi documento informatico.
Tale tipo di firma non fornisce tutte le garanzie necessarie a dare
certezza ai documenti informatici. Nonostante le scarse garanzie for-
nite da questo tipo di firma il legislatore ne ha affermato la capacità di

soddisfare il requisito della forma scritta. Una affermazione del genere
si discosta totalmente da ciò che il legislatore aveva previsto per questa
materia nel DPR 513/97. La prima organica regolamentazione della
materia, infatti, permetteva solamente ai documenti informatici sotto-
scritti con firma digitale, di soddisfare il requisito della forma scritta.
Il legislatore del ’97 prevedendo che il documento informatico
firmato con firma digitale fosse equiparato alla scrittura privata (con
l’esplicito richiamo alla disciplina contenuta nell’art. 2702 c.c. ad ope-
ra dell’art. 5 DPR 513/97) e che i contratti stipulati con strumenti
informatici o per via telematica mediante l’uso della firma digitale,
fossero validi e rilevanti a tutti gli effetti di legge (art. 11 DPR 513/97),
aveva di conseguenza stabilito che la forma informatica che rispettasse
determinati requisiti fosse idonea a soddisfare la forma scritta ad sub-
stantiam.
La mutazione legislativa operata dal legislatore del DLgs 10/02
è di enorme rilevanza all’interno del quadro normativo di riferimento
del documento informatico. Si è infatti modificato l’art. 10 del DPR
445/00 stabilendo che un documento informatico sottoscritto con fir-
ma elettronica leggera assolva al requisito della forma scritta; ciò impli-
ca che per tutti gli atti per i quali era richiesta la forma scritta ad sub-
stantiam sia sufficiente l’apposizione di una firma elettronica debole.
Gli “atti che devono farsi per iscritto” a norma dell’art. 1350 c.c.
potrebbero secondo il nuovo assetto normativo, essere fatti attraverso
documenti informatici per loro natura insicuri.
A questo punto ci si deve chiedere quale sia il valore probatorio
del documento informatico previsto dal secondo comma dell’art. 10
del DPR 445/00 a seguito della modifica operata dal DLgs 10/02.
Visti i presupposti sarebbe naturale pensare che il documento infor-
matico sottoscritto con una firma debole abbia l’efficacia probatoria
della scrittura privata. Invece, da una parte si dice che il documento
informatico soddisfa il requisito della forma scritta e dall’altra che non
sarebbe considerato sotto il profilo probatorio come una scrittura pri-
vata ma semplicemente rimessa al libero apprezzamento del giudice.
Il documento informatico sottoscritto, sia pure con una firma
elettronica debole, è comunque un documento informatico al quale
dovrebbe applicarsi il primo comma dell’articolo 10 che espressamente
richiama l’art. 2712 del codice civile. A norma di questo articolo il
giudice è tenuto a considerare veri i fatti e le cose rappresentate in un
documento informatico, salvo che colui contro il quale il documento
è prodotto non ne disconosca la conformità ai fatti e alle cose medesi-

me. Se ciò è valido per un documento informatico non sottoscritto a
maggior ragione lo sarà per un documento sottoscritto. Il documento
non sottoscritto, infatti, dovrebbe avere un valore minore rispetto ad
uno sottoscritto.
Il terzo comma regola il documento informatico quando questo
è sottoscritto con una firma digitale “o con un altro tipo di firma elet-
tronica avanzata”. Questo fa piena prova fino a querela di falso, della
provenienza delle dichiarazioni di chi l’ha sottoscritto. Il vecchio testo
richiamava esplicitamente l’art. 2702 c.c. e, quindi la intera normati-
va relativa alla scrittura privata. La modifica apportata dal legislatore
ha una portata non indifferente, poiché il richiamo operato sembra
ricondurre alla fattispecie probatoria dell’atto pubblico o almeno alla
scrittura privata autenticata. Le garanzie che circondano la procedura
di certificazione della firma digitale hanno presumibilmente condotto
il legislatore a considerare che il documento informatico firmato di-
gitalmente abbia la stessa efficacia probatoria di una scrittura privata
autenticata.
Questa impostazione sembra però essere smentita dal successivo
articolo 24, che prevede la possibilità dell’autenticazione della firma
digitale per opera di un notaio o di altro pubblico ufficiale autorizzato.
La scrittura privata informatica era sottoposta alle medesime
regole descritte dall’articolo 2702 cod. civ. (art. 5 DPR 513/1997).
Quindi, sotto il profilo del valore da attribuire al documento all’in-
terno del processo, anche il documento informatico sottoscritto con
firma digitale era sottoponibile agli istituti del riconoscimento, della
verificazione e, infine, della querela di falso.
Il legislatore nella ultima stesura del terzo comma dell’articolo 10
del testo unico, non richiama più per intero l’articolo 2702 del codice
civile al fine di regolare la nuova fattispecie informatica; il legislatore
si limita a dire che tale nuovo tipo di documento fa piena prova fino a
querela di falso.
A tal proposito c’è chi considera la firma digitale come un ra-
dicale cambiamento rispetto al vecchio sistema di imputazione degli
atti giuridici. Difatti, per tale filone interpretativo, il documento infor-
matico firmato digitalmente impedirebbe, per sua stessa natura disco-
noscimento della sottoscrizione digitale, quindi non potrebbe essere
messa in discussione, attraverso l’atteggiamento della parte contro cui
il documento è proposto, l’autenticità del documento. Secondo questo
orientamento, è sufficiente l’uso della chiave segreta, necessario per ap-
porre la firma giudizio di verificazione, a vincolare il titolare della cop-

pia di chiavi, il quale per evitare gli effetti giuridici derivanti dall’uso
della firma dovrà dimostrare di non essere il soggetto che fisicamente
ha firmato il documento; questo sarà possibile solo attraverso una que-
rela di falso.
3.4.2.2 Lo scenario prospettato dal Codice delle Pubbliche

Amministrazioni
E’ da segnalare che il Consiglio dei Ministri, l’ novembre ,
ha approvato in via preliminare lo schema del “Codice delle pub-
bliche amministrazioni digitali”. Nelle sue linee generali il codice di-
sciplinerà praticamente tutti gli aspetti dell’impiego delle tecnologie
nelle pubbliche amministrazioni, con particolare attenzione non solo
alla gestione dei documenti, ma anche ai rapporti con i cittadini per
via telematica e allo sviluppo, all’acquisizione e al “riuso” dei sistemi
informatici.
Le precedenti disposizioni sono abrogate, compresi tutti gli ar-
ticoli del testo unico sulla documentazione amministrativa (DPR
445/00) che riguardano la materia.
Viene inoltre abrogato il decreto legislativo 10/02, che tanta
confusione ha creato nel campo delle firme elettroniche.
Le “nuove” disposizioni, che nella sostanza riprendono i principi
del DPR 513/97, con l’aggiornamento necessario per il rispetto della
direttiva //CE prevedono tre tipologie:
1. Firma “forte” (ovvero firma digitale o firma elettronica quali
ficata, cioè basata su un certificato qualificato e creata median-
te un dispositivo sicuro): il documento soddisfa il requisito
della forma scritta ed è equiparato alla scrittura privata per gli
aspetti processuali.
2. Firma “debole” (che non comprende le “autorizzazioni infor-
matiche”, in sostanza le combinazioni username-password):
il documento “è liberamente valutabile in giudizio, tenendo
conto delle sue caratteristiche oggettive di qualità e sicurezza”;
così è soddisfatta la previsione della direttiva europea.
3. Documento non firmato: vale come una riproduzione mecca-
nica (è prevista una piccola modifica all’art. 2712 del codice
civile).

Tabella riepilogativa evoluzione normativa
Codice delle PA
DPR 513/97 D.Lgs 10/02
digitali 2005
Documento infor- Non soddisfa Si dice che assolva Si prevede che
matico firmato con il requisito della il requisito il documento sia
firma debole forma scritta della forma scritta; rimessa alla libera
normativa valutazione
contradditoria: del giudice, tenuto
il documento è in- conto delle sue
fatti rimesso al libero caratteristiche
apprezzamento del oggettive di qualità
giudice e sicurezza
Documento Equiparato Piena prova fino Ritorno ai principi
informatico firmato alla scrittura privata; a querela di falso, del 1997.
con firma digitale richiamo sembrerebbe Il documento
all’art. 2702 c.c riconducibile soddisfa il requisito
alla fattispecie della forma scritta;
della scrittura privata equiparato alla forma
autenticata ma scritta per gli aspetti
normativa contrad processuali. L’utilizzo
dittoria. del dispositivo di
firma si presume
riconducibile al
titolare, salvo sia data
prova contraria
3.4.3 Concessione e gestione della firma: la certificazione

della Firma Digitale
Il principio fondamentale della firma digitale è quello di garan-
tire, attraverso una precisa serie di elaborazioni, che un documento
redatto in forma elettronica abbia la stessa valenza giuridica di un do-
cumento cartaceo firmato con firma olografa.
La firma digitale in quanto tale tuttavia non garantirebbe la vera
identità del titolare della chiave privata. Chiunque potrebbe infatti ge-
nerare (o farsi assegnare) una coppia di chiavi a nome di un terzo e
come tale agire nel mondo virtuale.
Per risolvere questo problema, è necessaria una operazione di
certificazione, è necessaria, cioè, la presenza di un organismo terzo ga-
rante. La garanzia che questo ente fornisce è relativa all’identità del
titolare, o meglio alla relazione univoca tra la chiave utilizzata nella
transazione/trasmissione e la persona cui la chiave appartiene.
Nel proseguo della trattazione ci occuperemo preliminarmente di
quella che è l’architettura complessiva del sistema e dunque del ruolo

dei certificatori che assolvono alle funzioni di concessione delle firme
digitali, verifica e (qualora sia necessario) revoca delle stesse.
Successivamente esamineremo il ciclo di funzionamento della fir-
ma digitale e quindi prenderemo in considerazione sia i vari passaggi
necessari alla creazione di un documento firmato digitalmente sia i
possibili supporti necessari alla memorizzazione.
3.4.3.1 Definizione del problema

L’utilizzo della firma digitale prevede un quadro nel quale gli at-
tori coinvolti sono oltre naturalmente al firmatario del documento e
al destinatario dello stesso, l’Ente Certificatore e, più in generale, l’in-
frastruttura in grado di presidiare dal punto di vista tecnologico e della
sicurezza l’utilizzo della crittografia.
Il quadro può essere dunque rappresentato come l’insieme di una
serie di soggetti che si riconoscono mutuamente ed interagiscono in
una occasione particolare (vedi rilascio) o ripetutamente (in ogni caso
di utilizzo della firma).
Il mutuo riconoscimento è attualmente l’unica cosa in grado di
assicurare il funzionamento del sistema, in quanto non esistono degli
standard (o meglio non sono applicati) né riguardo alla struttura dei
certificati, né riguardo alla rappresentazione dei dati, ecc. ma più che
altro delle regole pratiche di funzionamento.
In base a queste regole pratiche vigenti nel sistema italiano, si è
giunti alla situazione in cui ogni Autorità di certificazione iscritta al-
l’elenco pubblico del CNIPA è in grado di leggere e gestire i certificati
emessi da altre Autorità di certificazione.
L’insieme degli attori, ma anche delle infrastrutture tecnologiche,
delle “regole del gioco” e delle persone, che rendono possibile l’utilizzo
di dispositivi di firma digitale, vanno sotto il nome di PKI (Public Key
Infastructure).
3.4.3.2 Il certificatore
Appare dunque evidente il ruolo primario ricoperto dalle autori-
tà di certificazione, che rappresentano l’unico attore in grado di garan-
tire “erga omnes” l’identità del soggetto dotato di dispositivo di firma
digitale e di chiave di firma.
Il Certificatore ha il compito di accertare l’identità personale
del richiedente e di aggiornare apposite liste dei certificati emessi e di
quelli sospesi o revocati, cosicché:

• chi abbia firmato un messaggio con una chiave non sospesa né
revocata non possa in alcun modo disconoscerne il contenuto
e la paternità;
• chiunque riceva un documento con firma digitale possa verifi-
care l’identità del firmatario e la validità del relativo certificato.
La certificazione della chiave pubblica è il punto critico del siste-
ma della firma digitale, tanto che, anche in questo caso, il nostro legi-
slatore ha dettato regole piuttosto restrittive per coloro i quali vogliano
candidarsi come enti certificatori.
L’ente certificatore, terza parte fidata nella trasmissione di docu-
menti con firma digitale, è chiamato a svolgere una serie di compiti,
principalmente deve:
• stabilire l’algoritmo di codifica e decodifica e predisporre il
pacchetto software in grado di gestirlo;
• ricevere le domande di assegnazione di una coppia di chiavi;
• valutare e registrare le caratteristiche di ogni richiedente (azien-
da o persona) per assegnare la relativa chiave pubblica (e quin-
di la chiave privata corrispondente), emettendo un apposito
certificato digitale;
• registrare in un’apposita banca dati la coppia di chiavi assegna-
ta perché non possa essere più assegnata;
• stabilire il termine di scadenza del certificato, quindi il periodo
di validità delle chiavi (in funzione di determinate caratteri
stiche individuate dal regolamento tecnico all’articolo 4,
comma 7);
• pubblicare on line il certificato e la chiave pubblica in modo
che chiunque abbia interesse possa avere la sicurezza dell’avve-
nuta certificazione;
• ricevere le segnalazioni di eventuali smarrimenti, furti, divul-
gazioni improprie di chiavi, ecc. ecc., e ne pubblica la sospen-
sione o la revoca in tempi molto stretti.
L’utente che desidera utilizzare il meccanismo della firma digitale,
si registra presso un’autorità di certificazione, grazie a tale registrazione,
gli viene attribuito un identificatore.
Mediante un software adatto al sistema crittografico adottato,
l’utente genera la coppia di chiavi da utilizzare.
La richiesta di certificazione all’Autorità di Certificazione da par-
te dell’utente avviene attraverso l’invio della chiave pubblica, generata

autenticandola mediante l’identificatore ricevuto nel momento della
registrazione, dall’Autorità stessa.
A questo punto l’Autorità crea il certificato che garantisce l’ap-
partenenza della chiave pubblica all’utente; la veridicità del certificato
è assicurata dalla firma digitale che l’autorità appone sul certificato. In
questo modo viene risolto il problema della distribuzione delle chiavi
pubbliche, in quanto tale distribuzione avviene tramite l’invio dei cer-
tificati, che in quanto sottoscritti dall’Autorità, garantiscono l’autenti-
cità e la veridicità delle chiavi pubbliche.
E’ bene sottolineare che questo ruolo fondamentale non è rico-
perto però da un solo ente riconosciuto da tutti, ma in linea teorica
può essere ricoperto da chiunque rispetti determinati requisiti e si sot-
toponga al processo di riconoscimento come ente di certificazione. Ciò
vale a livello nazionale, e ancora di più a livello globale.
L’esistenza di più Autorità comporta che i certificati necessari per
la conoscenza della chiave pubblica appartenente ad un soggetto, sono
firmati da diverse autorità, ed è impensabile che ogni utente abbia di-
retta conoscenza delle chiavi pubbliche di ogni interlocutore, sotto for-
ma di certificato elettronico, o delle chiavi pubbliche delle corrispon-
denti autorità di certificazioni competenti (che gli permette di venire a
conoscenza della chiave pubblica del suo interlocutore).
E’ indispensabile, quindi, avere a disposizione un meccanismo
che permetta il ritrovamento dei certificati elettronici degli interlocu-
tori appartenenti a domini di sicurezza esterni, curati da Autorità di
certificazioni diverse dalla propria. Questo meccanismo utilizza le cate-
ne di certificazione, note anche come cammini di certificazione.
Il cammino di certificazione permette, grazie alla conoscenza di
un insieme di chiavi pubbliche appartenenti al proprio dominio, di
risalire attraverso varie ricerche, alle chiavi pubbliche registrate in un
dominio differente, grazie alle comunicazioni che si vengono ad in-
staurare tra Autorità differenti.
Il problema di avere più autorità di certificazione, e quindi diver-
se liste da consultare per rintracciare le chiavi pubbliche, è stato risolto
prevedendo l’elenco pubblico dei certificatori, previsto dall’articolo 
comma 6 del DPR  dicembre  n. 445 e specificato nel DPCM
 gennaio , viene mantenuto dal Centro nazionale per l’infor-
matica nella pubblica amministrazione e viene reso disponibile per via
telematica attraverso la rete Internet. Con il Decreto della Presidenza
del Consiglio dei Ministri del  luglio  viene definitivamente
sancita l’assegnazione al CNIPA della competenza per la tenuta del-
l’elenco pubblico dei certificatori.

L’elenco pubblico viene reso disponibile in due distinte unità in-
formative:
• La prima contiene la lista dei certificati delle chiavi di certifica-
zione (art. 41 comma 1 lettera f ) e le rimanenti informazioni
previste nel medesimo articolo 41 fatta eccezione per i manua-
li operativi;
• La seconda contiene i manuali operativi aggiornati forniti al
CNIPA dai certificatori (art. 41 comma 1 lettera g).
La lista dei certificati ed i singoli manuali operativi sono sotto-
scritti dal CNIPA, nella persona del Presidente. I codici identificativi
del certificato di sottoscrizione utilizzato dal Presidente del Cnipa, Li-
vio Zoffoli, sono stati pubblicati con la Circolare  settembre , n.
CNIPA/CR/42 (G.U. n. 222 del  settembre ).
La lista dei certificati è strutturata, in un archivio WINZIP non
compresso, come insieme di directory, ciascuna dedicata ad un certifi-
catore iscritto, ognuna contenente i certificati forniti dalle aziende, ed
un file in formato che presenta le informazioni previste dall’articolo 41.
La verifica della firma del CNIPA e la successiva estrazione degli
oggetti firmati può essere effettuata con qualsiasi software in grado di
elaborare file firmati in modo conforme alla circolare AIPA/CR/24, 
giugno .
La P.A. come possibile certificatore

Merita di essere segnalato il fatto che, ai fini della sottoscrizione
di documenti informatici di rilevanza esterna, le pubbliche ammini-
strazioni, ai sensi dell’art.29 quinquies del DPR 137/2003, possono
optare per due diverse soluzioni:
• svolgere direttamente l’attività di rilascio dei certificati qualifi-
cati avendo a tal fine l’obbligo di accreditarsi; tale attività può
essere svolta esclusivamente nei confronti dei propri organi ed
uffici, nonché di categorie di terzi, pubblici o privati. I certifi-
cati qualificati rilasciati in favore di categorie di terzi possono
essere utilizzati soltanto nei rapporti con l’Amministrazione
certificante, al di fuori dei quali sono privi di ogni effetto. Con
decreto del Presidente del Consiglio dei ministri, su proposta
dei Ministri della funzione pubblica e per l’innovazione e le
tecnologie e dei Ministri interessati, di concerto con il Mini-
stro dell’economia e delle finanze, sono definite le categorie di
terzi e le caratteristiche dei certificati qualificati;

• rivolgersi a certificatori accreditati, secondo la vigente norma
tiva in materia di contratti pubblici.
3.4.3.3 Le revoche dei certificati

Critica nel processo di gestione dei certificati elettronici è l’ope-
razione di revoca.
La difficoltà legata a tale operazione è il garantire una corretta no-
tifica su larga scala dell’avvenuta revoca di un particolare certificato.
Il meccanismo comunemente utilizzato per notificare su larga
scala le revoche, utilizza le “liste di revoca dei certificati” (certificate
revocation list o CRL).
Ogni autorità di certificazione pubblica periodicamente una
struttura dati contenente l’elenco dei certificati revocati (firmata digi-
talmente dall’autorità stessa, a garanzia della sicurezza dei dati conte-
nuti nella lista).
Ogni CRL deve poter essere consultabile da ogni utente, in fase
di verifica di una firma, per essere certi che il certificato utilizzato sia
valido e non revocato.
La pubblicazione delle liste avviene con una certa periodicità, quin-
di il problema che si pone è che non avviene una revoca in tempo reale.
Alternativamente alla pubblicazione delle liste, alcune autorità
usano un metodo di comunicazione delle liste in modalità broadcast,
ossia appena sopravviene una revoca l’autorità comunica agli utenti
interessati la CRL, questo sistema presenta degli svantaggi in quanto
non è sicuro che le CRL effettivamente raggiungano gli utenti finali in
modo sicuro.
3.4.4 Processo di funzionamento della Firma Digitale

La firma digitale è la sequenza, o “stringa di dati”, che risulta dal
procedimento di codifica di un file (messaggio di posta elettronica,
documento di testo, immagine, ecc.), ottenuta utilizzando il metodo
della crittografia a doppia chiave.
Poiché l’interesse, in questo caso, è garantire non la riservatezza,
bensì l’autenticità e integrità del contenuto, il meccanismo di cifratura
non si applica all’intero documento, bensì alla cosiddetta impronta,
una stringa di dati riassuntiva ottenuta applicando al documento un
algoritmo di hash, ciò rende le operazioni di firma estremamente più
veloci. Una volta ottenuta l’impronta, questa viene crittografata con la
chiave privata del mittente e costituisce la firma del documento.
Al momento della ricezione, il destinatario, attraverso apposito

software, effettua nuovamente la funzione di hash sul documento per-
venuto in chiaro e decodifica con la chiave pubblica la firma del docu-
mento, ottenendo così l’originale impronta.
A questo punto, la verifica dell’uguaglianza delle due impronte
garantisce l’integrità e l’autenticità del documento.
Per firmare un documento digitalmente occorre seguire un de-
terminato iter:
1. si deve produrre l’impronta dal file originario, ossia la stringa
di dati riassuntiva che ne sintetizza univocamente il contenuto;
2. si prosegue con la cifratura dell’impronta con la chiave privata
del mittente/firmatario. Il risultato di questa operazione è la
firma digitale vera e propria;
3. generata così la firma digitale, il mittente può inviare in chiaro
il documento firmato, corredato della firma e del certificato
digitale contenente la chiave pubblica;
4. il destinatario, attraverso un opportuno software, decifra la
firma digitale con la chiave pubblica del mittente (legge l’im-
pronta). Se questa operazione riesce, il destinatario ha la cer-
tezza che il Message Digest è stato generato dalla unica chiave
privata - quindi da quel determinato sottoscrittore;
5. successivamente il destinatario calcola nuovamente la funzio-
ne di HASH sul documento ricevuto in chiaro e confronta
il risultato con l’impronta del mittente. Se le due impronte
coincidono il destinatario ha la conferma che il contenuto del
documento ricevuto in chiaro non ha subito alcuna alterazio-
ne o danneggiamento durante la trasmissione (anche un solo
bit modificato avrebbe generato un’impronta diversa da quella
“firmata”).
La trasmissione del documento firmato ad un destinatario preve-
de, quindi, il contemporaneo invio di:
• testo originale in chiaro;
• impronta cifrata;
• certificato digitale del mittente contenente la chiave pubblica.
Il tutto viene accorpato in un file, secondo lo standard PKCS#7
che definisce i formati standard per file cifrati e/o firmati digitalmen-
te. Secondo la normativa italiana, i file firmati digitalmente devono
necessariamente assumere l’estensione .p7m, in aggiunta all’estensione
originaria.
E’ importante sottolineare che la stringa di dati che chiamiamo
“firma digitale”, essendo il risultato di un’operazione effettuata su uno
specifico file di dati, è in realtà diversa per ogni singolo file trattato. E’
infatti la chiave privata, quella che genera il risultato, ad essere unica.
La firma digitale non è riproducibile, non è possibile associare
una certa firma digitale ad un testo diverso dall’originale. La sicurezza
dell’intero meccanismo è garantita dalla impossibilità di ricostruire la
chiave privata (segreta) a partire da quella pubblica, anche se le due
chiavi sono univocamente collegate.
Supporti per la memorizzazione

L’algoritmo che produce la firma digitale, quindi la chiave pri-
vata, deve risiedere su un supporto di memorizzazione, e così anche il
certificato elettronico che serve per la trasmissione della chiave pubbli-
ca, legata alla chiave privata.
Un importante, e sicuro supporto di memorizzazione è la smart
card, che consente di archiviare certificati, chiavi private, e di eseguire
operazioni di crittografia con chiave pubblica, come la firma digitale.
Esistono due tipi di smart card, una dotata di capacità di elabora-
zione, che quindi può eseguire dei veri e propri programmi come critto-
grafare un documento, ed una che ha solo funzioni di memory card.
Altri dispositivi di memorizzazione come la flash memory (è un
chip di memoria), o il cd-rom non si prestano ad essere utilizzati per la
memorizzazione di chiavi private e certificati in quanto non possiedo-
no una capacità elaborativi propria.
Altro dispositivo di memorizzazione è il Token USB, che è un
dispositivo hardware da collegare alla porta USB del pc, che come la
smart card incorpora un chip dotato di capacità elaborative autonome
con memoria non volatile.
3.4.5 Problemi aperti

Una realtà che può comportare alcuni problemi è quella del-
l’omocodia; con tale termine si intende quella particolare situazione
che si verifica quando due (o più) soggetti abbiano dati anagrafici tali
da generare lo stesso codice fiscale (Omocodici). Fino ad oggi sono
stati riscontrati oltre 25.000 casi.
In caso di omocodia l’Agenzia delle Entrate provvede ad attri-
buire a ciascun soggetto un nuovo codice fiscale, calcolato a partire
dal codice fiscale “base” comune a più soggetti. La distinzione avviene
effettuando, nell’ambito dei sette caratteri numerici, sistematiche so-
stituzioni di una o più cifre, a partire da quella più a destra, con corri-

spondenti caratteri alfabetici.
Sul sito Internet dell’Agenzia delle Entrate è disponibile il pro-
gramma di controllo della correttezza formale del codice fiscale; questo
può essere utilizzato e integrato da Enti e Amministrazioni nei propri
sistemi informativi, per la verifica di codici fiscali, anche se generati da
una risoluzione di omocodia.
Il fatto che vengano risolti eventuali casi di omocodia risulta si-
gnificativo in relazione alla tematica della firma digitale. Il soggetto che
richiede una smart card ad un Ente Certificatore infatti deve presenta-
re, tra la documentazione necessaria, proprio il codice fiscale. Inoltre
tra i dati inseriti nel certificato digitale vi è anche il codice fiscale.
Si deve poi tenere conto del fatto che il codice fiscale è lo stru-
mento attraverso il quale gli utenti compiono tutta una serie di attività
relative ai loro rapporti con la P.A. (si pensi alla richiesta di determinati
certificati o alla tessera sanitaria che si basa proprio sul codice fiscale);
di conseguenza nel caso in cui il cittadino dovesse svolgere operazioni
che comportano l’utilizzo sia della smart card (per la firma digitale) che
del codice fiscale un caso di omocodia potrebbe determinare notevoli
complicazioni.
Una ulteriore problematica di particolare rilevanza è quella legata
alla presenza di una pluralità di certificatori e alla scelta del legislatore
di non individuare regole tecniche univoche al fine di non ingene-
rare squilibri nel mercato. Infatti nel caso in cui venissero dettate delle
regole tecniche particolarmente precise e dettagliate si finirebbe per
forza di cosa a rifarsi a uno dei modelli esistenti. Ciò verrebbe a deter-
minare, per il Certificatore individuato come modello, una posizione
di forza inaccettabile da parte degli altri Certificatori.
Questa scelta se da un lato tutela il mercato dall’altro pone ap-
punto dei problemi legati alla ancora scarsa standardizzazione presente
nella realtà italiana delle firme digitali.
Sia il Cnipa sia l’Assocertificatori sono attivi per cercare di creare
una sempre maggiore omogeneità.
Assocertificatori, dopo avere contribuito alla definizione della
circolare AIPA sulla interoperabilità, ha provveduto a costituire al pro-
prio interno il “Comitato Tecnico per la firma digitale”, cui sono stati
attribuiti dal Consiglio Direttivo dell’Associazione i seguenti compiti:
• analisi delle problematiche relative all’interoperabilità e predi-
sposizione di proposte operative per la piena attuazione del-
l’interoperabilità tra i soci;

• esecuzione di un piano di verifiche periodiche di interoperabi-
lità tra i soci;
• studio ed approfondimento delle questioni tecniche relative
a nuove norme tecniche, all’adozione di nuovi standard, alle
modifiche di norme tecniche o standard esistenti, all’adozione
ed alla compatibilità di standard internazionali ed elaborazio-
ne di proposte operative per i soci;
• elaborazione di documenti, studi, indicazioni o raccomanda
• studio ed approfondimento delle necessità di intervento o mo-
difica delle procedure operative e di sicurezza dei soci a seguito
dell’eventuale verificarsi di problemi applicativi ed elaborazio-
ne di proposte di intervento per i soci;
• elaborazione di proposte di miglioramento degli aspetti tecnici
in generale relativi all’attività di certificazione.
3.5 Trasmissione certa: posta elettronica certificata (PEC)

La Posta Elettronica Certificata (PEC) è un sistema di posta elet-
tronica nel quale è fornita al mittente documentazione elettronica, con
valenza legale, attestante l’invio e la consegna di documenti informatici.
“Certificare” queste due fasi significa che il mittente riceve dal
proprio gestore di posta (il cui elenco ufficiale è istituito presso il CNI-
PA, al quale sono assegnati compiti di vigilanza e controllo sull’attività
degli iscritti) una ricevuta che costituisce prova legale dell’avvenuta spe-
dizione del messaggio e dell’eventuale allegata documentazione. Allo
stesso modo, quando il messaggio perviene al destinatario, il gestore
invia al mittente la ricevuta di avvenuta (o mancata) consegna con
precisa indicazione temporale. Nel caso in cui il mittente smarrisca le
ricevute, la traccia informatica delle operazioni svolte viene conservata
per 24 mesi in un apposito registro informatico custodito dai gestori,
con lo stesso valore giuridico delle ricevute.
L’oggetto dell’invio fra mittente e destinatario è un messaggio di
posta certificata composto dal messaggio originale, che coincide con
quanto predisposto dal mittente, da una parte di testo descrittivo e
dai dati di certificazione. La trasmissione, tra mittente e destinatario,
avviene mediante l’invio del messaggio di posta certificata sottoscritto
dal gestore di riferimento del mittente con firma elettronica.
Tale procedura in effetti non fissa però in modo univoco il conte-
nuto della mail e dei relativi allegati, ponendo la questione dell’opportu-

nità o della necessità di una firma disgiunta da parte del mittente (utiliz-
zando ognuno propri supporti e certificati) e del certificatore di posta.
Nel primo caso si ha la “validazione” dei contenuti, nel secondo la
certezza dell’avvenuta trasmissione e dell’avvenuta o mancata ricezione.
Il DPR approvato il  gennaio  prevede che il documento
informatico trasmesso per via telematica si intende inviato dal mitten-
te se trasmesso, e si intende consegnato al destinatario se disponibile
all’indirizzo elettronico da questi dichiarato.
La validità della trasmissione e ricezione del messaggio di posta
elettronica certificata è attestata rispettivamente dalla ricevuta di accet-
tazione (fornita al mittente dal suo gestore di posta elettronica) e dalla
ricevuta di avvenuta consegna (fornita al mittente dal gestore di posta
elettronica utilizzato dal destinatario).
La ricevuta di avvenuta consegna è rilasciata contestualmente alla
consegna del messaggio di posta elettronica certificata nella casella di
posta elettronica del destinatario, indipendentemente dall’avvenuta
lettura da parte del soggetto destinatario.
Nel caso la trasmissione del messaggio avvenga tra diversi gestori
deve essere assicurata l’interoperabilità dei medesimi (ovviamente ciò
non si pone come problema se i due utenti utilizzano lo stesso gestore
(sulla cui scelta la legge però non pone vincoli, né consente alla PA di
imporre il suo gestore agli utenti). Il gestore del destinatario provvede-
rà a rilasciare al gestore del mittente una “ricevuta di presa in carico”
con la quale attesta l’avvenuta presa in carico del messaggio.
Attraverso l’impiego di posta certificata, le problematiche relati-
ve all’interoperabilità risultano, per quanto possibile, amplificate, così
come si complica il quadro della verifica della validità dei certificati,
che diventa doppia (verifica del certificato dell’utente e verifica del cer-
tificato del gestore di posta).
3.5.2 La sperimentazione relativa alla PEC

La sperimentazione ha avuto inizio nel  per iniziativa del
Centro tecnico per la Rupa attraverso l’attività del Gruppo di Lavo-
ro; inizialmente sono stati presi in considerazione principalmente gli
aspetti legati all’interoperabilità e sono stati prodotti una serie di docu-
menti tecnici di supporto per i fornitori del servizio.
Successivamente, in seguito alla istituzione del CNIPA, sono pro-
seguite le verifiche di interoperabilità delle piattaforme sw e le relative
richieste d’iscrizione all’”Indice dei Gestori” del servizio.
Il CNIPA considera ormai conclusa la fase di sperimentazione e

di conseguenza dal  novembre  non vengono più accettate nuove
richieste d’iscrizione per i Gestori e non si procede a verificare l’intero-
perabilità di nuove piattaforme.
La partecipazione alla fase di sperimentazione non costituisce
nessun tipo di titolo rispetto alla successiva fase ufficiale della PEC,
che sarà regolata da legge dello Stato.
3.6 Ricezione e gestione: il protocollo informatico

Ogni Pubblica Amministrazione, perseguendo gli obiettivi pre-
visti dal proprio mandato istituzionale, riceve e produce una enorme
quantità di documenti. Tale attività si estrinseca in processi governati
da procedure e regole variabilmente complesse ed articolate.
È evidente come sia necessario quindi, che tutte le informazioni,
che transitano da e per la Pubblica Amministrazione, siano all’occorren-
za rintracciate. A questa necessità rispondono gli uffici del protocollo.
Ma che cos’è esattamente l’attività di protocollazione? Si tratta di
quella fase del processo che certifica provenienza e data di acquisizio-
ne del documento identificandolo, in maniera univoca, nell’ambito di
una sequenza numerica collegata con l’indicazione cronologica. Costi-
tuisce chiaramente il punto nevralgico di tutti i flussi di lavoro tra le
amministrazioni e all’interno di ciascuna di esse.
Proprio in materia di semplificazione amministrativa, infatti, si
inserisce il Protocollo Informatico.
Il Protocollo Informatico e, più in generale, la gestione elettro-
nica dei flussi documentali, hanno la finalità di migliorare l’efficienza
interna degli uffici attraverso la riduzione dei volumi cartacei, la razio-
nalizzazione dei flussi documentali fino ad arrivare, dove è possibile
all’eliminazione dei registri cartacei.
Il legislatore italiano, scegliendo il  gennaio  come termine,
non perentorio, per realizzare la struttura minima necessaria per attiva-
re il Protocollo Informatico lo definisce come
“l’insieme delle risorse di calcolo, degli apparati, delle reti di comuni-
cazione e delle procedure informatiche utilizzati dalle amministra-
zioni per la gestione dei documenti”.
Si tratta di tutte le risorse tecnologiche necessarie alla realizzazio-
ne di un sistema automatico per la gestione e l’archiviazione elettronica
dei flussi documentali.
Ottimizzare la gestione delle informazioni in modo da rendere di
facile reperibilità i documenti e i dati in transito è indispensabile non
solo per semplificare le azioni di chi lavora all’interno della macchina
amministrativa ma anche per fornire ai cittadini e alle imprese servizi
più efficienti e con un grado di trasparenza sempre maggiore.
Infatti con l’introduzione del protocollo informatico si facilite-
rebbe l’accesso allo stato dei procedimenti e ai relativi documenti da
parte di cittadini, imprese e altre amministrazioni.
Il Protocollo Informatico si pone come il punto di avvio di un
sistema informatico nel quale l’informazione che vi transita è solo di
tipo digitale, e l’informazione su supporti documentali cartacei viene
trasformata in digitale.
Ciò significa, quindi, accelerare e promuovere presso gli Enti Lo-
cali la gestione del flusso documentale informatico nel rispetto della
sicurezza operativa e delle condizioni di interoperabilità tra sistemi di
protocollo informatico al fine di semplificare e rendere più efficiente ed
efficace l’azione amministrativa.
Infatti dietro al concetto di Protocollo Informatico si configura
una nuova strategia per la gestione di documenti e informazioni che
impegnerà ogni Amministrazione a:
• riorganizzare e concentrare gli Uffici di protocollo, dando vita
a nuove aree organizzative (AAOO);
• adottare precisi standard di protocollo identici per tutte le am-
ministrazioni;
• rivedere tutte le attuali procedure informatiche per renderle
compatibili con il Protocollo Informatico e garantire l’inte-
roperabilità tra amministrazioni e facilitare l’accesso ai docu-
menti da parte dei soggetti interessati.
3.6.2 Il Protocollo Informatico nella PA: livelli di attivazione

Il legislatore definisce protocollo informatico come “l’insieme
delle risorse di calcolo, degli apparati, delle reti di comunicazione e
delle procedure informatiche utilizzati dalle amministrazioni per la ge-
stione dei documenti”, ovvero, tutte le risorse tecnologiche necessarie
alla realizzazione di un sistema automatico per la gestione elettronica
dei flussi documentali.
Ogni sistema di protocollo informatico, che si intende adottare o
realizzare, deve ottemperare a specifiche indicazioni, riportate nel Testo
Unico (DPR 445/2000).
Il Centro Nazionale per l’Informatica nella Pubblica Ammini-
strazione (CNIPA) e il legislatore italiano hanno individuato 4 livelli

di realizzazione della piattaforma del Protocollo informatico:
1. Nucleo minimo di protocollo
2. Gestione documentale
3. Workflow documentali
4. BPR.
La data del  gennaio  è un termine non perentorio che in-
dica il termine entro il quale le amministrazioni dovrebbero garantire
almeno le funzionalità minime del protocollo.
Il nucleo minimo di Protocollo non è altro che la gestione infor-
matica dei documenti in modalità base, caratterizzata da una serie ele-
mentare di attività.
In particolare rientrano nel nucleo minimo le attività di:
• registrazione in un archivio informatico delle informazioni ri-
guardanti un documento (numero di protocollo, data, mitten-
te/destinatario, oggetto, ecc.,);
• segnatura sul documento delle informazioni riguardanti il do-
cumento stesso (numero, data, AOO);
• classificazione d’archivio al fine di permettere una corretta or-
ganizzazione di tutto il materiale documentale.
La scelta del nucleo minimo evidenzia l’intenzione, almeno in una
prima fase, di circoscrivere gli obietti degli interventi della P.A. alla
sola registrazione dei documenti (protocollazione), e alla loro orga-
nizzazione nel sistema documentario, ciò al fine di considerare solo
la documentazione protocollata e quindi coinvolgere nel processo di
informatizzazione il solo Ufficio di Protocollo.
La realizzazione del nucleo minimo di protocollo permette co-
munque di fornire un servizio di certificazione, attraverso l’assunzione
di responsabilità che deriva dalla registrazione di protocollo (operazio-
ne che permette di memorizzare le informazioni principali del docu-
mento nel registro di protocollo).
Per gestione documentale – secondo livello di realizzazione del Pro-
tocollo Informatico – si intende la gestione informatica dei documenti
in modalità avanzata la quale comprende:
• registrazione del documento con trattamento delle immagini
(scansione di documenti cartacei);
• assegnazione per via telematica al destinatario;

• gestione avanzata della classificazione dei documenti (utilizzo di
thesauri e vocabolari avanzati ecc..);
• collegamento dei documenti alla gestione dei procedimenti.
Realizzare le attività del secondo livello significa, in linea di mas-
sima, concentrarsi sull’obiettivo di creazione di un patrimonio infor-
matico, nonché considerare la maggior parte delle informazioni che
partono e arrivano alla P.A. coinvolgendo più uffici.
Ciò dovrebbe permettere di:
• archiviare, trasmettere e gestire flussi documentali in forma
elettronica, lungo canali telematici sicuri e certificati.
• ricercare il contenuto dei documenti in base a criteri logico-
funzionali
Per Workflow Documentali - terzo livello di realizzazione – si in-
tende tutta l’attività di razionalizzazione e conseguente informatizza-
zione dei soli processi documentali di un’amministrazione escludendo
i processi primari.
Si tratta in pratica di rendere il protocollo un ambiente condivi-
so, in cui visualizzare e gestire i documenti elaborati nei vari momenti
del workflow, ma con in più un forte impatto dei flussi documentali
sui processi di lavoro, che non vengono di fatto reingegnerizzati, ma
“adeguati” al flusso documentale.
Il BPR prevede, invece, la reingegnerizzazione di tutti i processi
dell’amministrazione al fine di una loro conseguente informatizzazio-
ne. Nello specifico ci riferiamo a quei processi, gestiti mediante work-
flow, che possiedono dei particolari requisiti quali la complessità, la
ripetitività e la stabilità dell’iter.
3.6.3 Il nucleo minimo di protocollo: soluzioni e approcci

Sebbene il DPR 445/2000 fissasse la data del  gennaio 
come termine minimo entro il quale le amministrazioni avrebbero
dovuto garantire almeno le funzionalità minime del protocollo, non
molti Enti hanno provveduto ad attivarsi in tale direzione.
Tra i pochi progetti relativi al protocollo informatico meritano
di essere menzionati:
• il progetto di Protocollo informatico della Regione Campa-
nia (segnalato dal “Secondo rapporto sulla innovazione nel-
le Regioni italiane ”) : esso é conforme alla normativa
vigente e integrato con la gestione dei flussi documentali; si

pone l’obiettivo di creare un vero e proprio archivio informa-
tico. E’ in uso un’applicazione per la gestione dei documenti
che è in grado di decentrare le attività di protocollazione con
numerazione unica; collegare i documenti (flusso documenta-
le); registrare e segnare il protocollo; classificare i dati a livello
archivistico; ricercare e individuare le informazioni e i relativi
spostamenti;
• il progetto PROTOINT della Regione Friuli Venezia Giulia
(segnalato dal “Secondo rapporto sulla innovazione nelle Re-
gioni italiane ”) cofinanziato col 1° Avviso di e-govern-
ment e in fase di realizzazione: il progetto prevede, attraverso
l’integrazione dei diversi sistemi di protocollo delle PA pre-
senti sul territorio regionale, la realizzazione di una rete per
lo scambio dei documenti in modo certificato e sicuro, pur
in presenza di sistemi informativi e di strumenti applicativi
gestionali eterogenei.
Si prevede anche la realizzazione di un indice locale delle infor-
mazioni ed una gestione a carico del singolo ente per l’aggiornamento
costante dell’indice nazionale. Obiettivo finale del progetto è dunque
la semplificazione delle operazioni d’interscambio documentale tra le
Pubbliche Amministrazioni, anche grazie all’utilizzo di un sistema di
posta certificata;
• il progetto di Protocollo informatico del Comune di Porde-
none: per realizzarlo il Comune si è dotato di firma digita-
le e di una casella di posta istituzionale certificata (comune.
pordenone@cert.amministrazionefuturo.com), che garanti-
sce l’identificazione e l’originalità del documento e consente
l’emissione di una apposita ricevuta di recapito. Di conseguen-
za tutti i documenti soggetti a registrazione debbono essere
inviati a tale indirizzo. La corrispondenza così pervenuta viene
immediatamente protocollata e trasferita via e-mail all’Ufficio
competente, evitando così l’utilizzo di materiale cartaceo. Per
garantire l’originalità della corrispondenza gli utenti debbono
fornirsi di firma digitale da richiedere agli Enti Certificatori.
Con riguardo alla Regione Lombardia è da segnalare: il Progetto
relativo al Sistema Documentale Regionale.
Obiettivo di tale progetto è la sostituzione dei flussi documentali
cartacei con il loro equivalente digitale, in armonia con la normativa
vigente, in una logica di ottimizzazione dei costi ed incremento di ef-
ficienza.
Il sistema documentale regionale agisce secondo tre direttrici:
1. Gestire l’ingresso e l’uscita dei documenti elettronici ed even-
tualmente produrre copie digitali anche dei documenti ancora
generati in forma cartacea;
2. Seguire il percorso dei documenti all’interno dell’organizza-
zione regionale ed assistere gli operatori nell’espletamento dei
processi amministrativi ad essi collegati, indipendentemente
dalle caratteristiche e dalla natura specifica del procedimento;
3. Mettere a disposizione degli operatori un sistema universale
per l’archiviazione digitale di tutti i documenti (elettronici e
non) di facile consultazione e conforme alle norme di legge.
Con riguardo alle modalità di funzionamento del sistema si pre-
vede che il documento digitale acquisito attraverso una Casella di posta
Certificata venga messo a disposizione delle altre componenti del Siste-
ma Documentale Regionale.
Inoltre un sistema di Protocollo Informatico assiste l’operatore
nella protocollazione automatica o semi automatica del documento
digitale, e provvede alla sua archiviazione (Gestione Documentale) ed
al suo smistamento, secondo le norme CNIPA.
Si prevede di mettere a disposizione degli operatori un sistema
di Gestione Procedimenti (Workflow Management System) per l’even-
tuale gestione informatizzata dell’intero iter. I processi amministrativi
possono generare nuovi documenti digitali che, se destinati all’esterno,
possono essere affidati al sistema di Protocollo informatico e spediti
automaticamente mediante il sistema di posta certificata.
Si stabilisce inoltre che un sistema universale ed integrato di Ge-
stione Documentale custodisca ogni tipo di documento digitale (anche
multimediale) trattato dal sistema informativo regionale e lo archivi,
mantenendolo a disposizione per consultazione on line, secondo l’or-
ganizzazione richiesta dagli utenti (cartelle, pratiche ecc.).
L’estensione delle caselle di posta certificata a tutte le strutture
regionali e la progressiva generalizzazione dell’uso di un unico sistema
per la gestione e l’archiviazione dei documenti rappresenta la fase con-
clusiva dell’attivazione del Sistema Documentale Regionale.
3.6.4 Il percorso di attivazione

Le regole tecniche per il funzionamento del protocollo infor-
matico nella pubblica amministrazione sono rintracciabili nel DPR
445/2000 e nel DPCM 31/10/2000.

In particolare il DPCM 31/10/200 introduce una nuova disci-
plina per le modalità di registrazione e di trasmissione dei documenti
informatici per via telematica.
Tuttavia per poter implementare un’efficiente piattaforma per il
Protocollo Informatico le Amministrazioni devono affrontare diverse
problematiche.
È la normativa a definire le caratteristiche tecniche ed i requisiti
operativi del Protocollo Informatico e ad offrire i contributi di maggio-
re rilevanza in materia.
Vengono, infatti, proposti alle PA quali interventi predisporre
per rendere operativo il sistema di workflow-management digitale. In
particolare viene suggerito di:
• individuare le aree organizzative omogenee (AAOO);
• individuare i settori dell’amministrazione che presentano esi
genze omogenee di gestione della documentazione;
• nominare i responsabili del servizio di gestione del protocollo
informatico, della gestione dei flussi documentali, degli archivi;
• adottare il manuale di gestione del Protocollo da condividersi
all’interno dell’organizzazione;
• definire i tempi,le modalità e le misure organizzative/tecniche
finalizzate ad eliminare i protocolli di settore e quelli diversi
dal Protocollo informatico.
Ogni amministrazione dovrebbe quindi, fare una precisa analisi
che riguardi:
• gli obiettivi di adeguamento organizzativo: individuazione del
le AAOO (Aree organizzative Omogenee);
• le modalità tecniche di registrazione dei documenti informatici
ed i requisiti di sicurezza dei sistemi di protocollo informatico;
• il formato e le modalità tecniche di trasmissione dei documenti
informatici tra le pubbliche amministrazioni.
L’attuazione del progetto protocollo informatico è il primo passo
per il raggiungimento degli obiettivi di trasparenza previsti in uno dei
10 obiettivi di legislatura.
A tale scopo sono stati avviati dei gruppi di lavoro con alcune
amministrazioni per la realizzazioni di sistemi integrati di protocollo
informatico e di processi amministrativi automatizzati. In tale attività
il Project Office offre alle amministrazioni una collaborazione tecnica
e acquisisce le informazioni relative all’architettura dei vari modelli in

riferimento ai vari progetti, al loro contesto applicativo, alle problema-
tiche sorte in termini di identificazione degli interlocutori, sicurezza,
privacy e quanto altro.
Tutto ciò allo scopo di individuare una casistica da mettere a
disposizione delle amministrazioni che intendano in futuro realizzare
progetti analoghi e che pertanto si trovano di fronte, a prescindere al
tipo di processo amministrativo da mettere in trasparenza, a problema-
tiche simili.

4 Conclusioni e prospettive
4.1 L’attivazione di servizi innovativi

Come abbiamo visto l’attuazione concreta di un sistema di e-go-
vernment comporta il presidio di un insieme molto variegato di proble-
matiche che spesso non sono direttamente sotto la sfera di influenza dei
decisori coinvolti nello sviluppo del singolo progetto, ovvero non han-
no trovato ancora completa definizione dal punto di vista normativo.
Il grande movimento che si sta facendo attorno ai progetti di e-
gov testimonia indubbiamente la grande attenzione e aspettativa che si
ha nei confronti di queste innovazioni.
Va tuttavia detto che i servizi e-gov attualmente attivati sfruttano
ancora poche delle potenzialità offerte dalla tecnologia e si concentra-
no prevalentemente sull’attuazione di portali e canali informativi o di
transazioni che tuttavia non incidono significativamente nelle modalità
di approccio al problema e quindi dell’aumento dell’efficacia percepita
dai cittadini stessi:
• spesso i progetti sono solo di facciata e non si colgono le reali
potenzialità innovative dell’e-gov;
• spesso si dà risalto solo all’aspetto informatico-tecnologico.
In questo senso il nostro punto di vista è che l’e-Government
richieda di spostare il focus dell’attenzione dalla tecnologia e dall’infor-
matica alla complessità dei problemi di natura organizzativo-gestionale
che devono essere presidiati sia nella concezione (maggiore “coraggio”
nella ricerca di innovazioni radicali nel modo di concepire i servizi
tradizionali, ma anche pragmatismo e capacità di implementarli) ma
anche nella pianificazione del cambiamento e del business planning
per finire con lo start-up e il supporto al cambiamento.
A completamento del lavoro, nella pagina successiva si riporta un
breve estratto di una indagine che inquadra il fenomeno dell’impiego
di strumenti informatici evoluti a supporto dei processi caratteristici e
di quelli di erogazione dei Servizi, nell’ambito degli Enti locali.
In estrema sintesi quello che si riscontra è:
a) un basso utilizzo di strumenti di riconoscimento certo del-
l’utente come la CIE, i quali hanno carattere tendenzialmente

sperimentale soprattutto nelle realtà di medio-grandi dimen-
sioni, molti quale risultato “collaterale” nell’ambito dei proget-
ti di e-government finanziati nell’ambito del I Avviso del DIT.
Ciò che non è chiarito dall’inchiesta di cui si riporta l’estratto è
cosa si intenda per impiego di CIE, se il semplice rilascio anche
a titolo sperimentale o la concreta possibilità di interazione a
distanza da parte del cittadini con l’impiego della CIE;
b) un buon grado di diffusione del protocollo informatico (dovu-
to alle ultime innovazioni normative che ne rendono di fatto
obbligatoria l’adozione), per il quale da altre fonti sembra però
possibile poter affermare che ci si attesta su livelli minimali di
attuazione (cd nucleo minimo di protocollo informatico);
c) un livello di diffusione della firma digitale abbastanza basso,
con ogni probabilità statisticamente correlato con l’introduzio-
ne di strumenti come la CIE e con la partecipazione a progetti
di e-governemt, con una diffusione quindi ancora a carattere
sperimentale.
Carta identità Protocollo

Firma digitale
Area elettronica informatico
Risposte
geografica
n° % n° % n° %
Province
Nord 37 0 0 26 70 14 38
Centro 18 1 6 8 44 4 22
Sud 19 0 0 11 58 5 26
Isole 9 0 0 5 56 0 0
Italia 83 1 1 50 60 23 28
Comuni medio–grandi (*)
Nord 33 11 33 22 67 9 27
Centro 14 6 43 10 71 4 29
Sud 21 0 0 11 52 2 10
Isole 8 1 13 5 63 0 0

Italia 76 18 24 48 63 15 20
Fonte: Comuni medio-piccoli (**)

Deliberazione
4/2003 della Corte Nord 463 17 4 287 62 19 4
dei Conti Sezione
Autonomie Centro 148 4 3 87 59 4 3
Sud 189 4 2 70 37 3 2
(*): più di 60.000
abitanti
Isole 88 1 1 26 30 3 3
(**): da 8.000 a
Italia 888 26 3 470 53 29 3
59.999 abitanti
4.2 L’evoluzione del contesto normativo: il futuro “Codice

della PA Digitale”
E’ da segnalare che il Consiglio dei Ministri, l’ novembre ,

ha approvato in via preliminare lo schema del “Codice delle pub-
bliche amministrazioni digitali”. Nelle sue linee generali il codice di-
sciplinerà praticamente tutti gli aspetti dell’impiego delle tecnologie
nelle pubbliche amministrazioni, con particolare attenzione non solo
alla gestione dei documenti, ma anche ai rapporti con i cittadini per
via telematica e allo sviluppo, all’acquisizione e al “riuso” dei sistemi
informatici.
Le precedenti disposizioni sono abrogate, compresi tutti gli ar-
ticoli del testo unico sulla documentazione amministrativa (DPR
445/00). Viene inoltre abrogato il decreto legislativo 10/02.
Vediamo ora le più importanti statuizioni del Codice dell’Ammi-
nistrazione Digitale:
Obbligo per le Pubbliche amministrazioni di scambiarsi on-line i
dati relativi alle pratiche di cittadini ed imprese.
Obbligo per le Pubbliche Amministrazioni di riorganizzare i pro-
pri siti Internet in modo da individuare una serie di contenuti minimi
e necessari, compresa la disponibilità di moduli e formulari per via te-
lematica. Devono essere disponibili: organigramma con articolazione
degli uffici e relative attribuzioni; nomi dei responsabili dei vari pro-
cedimenti e relativa durata; scadenze e modalità di adempimento dei
procedimenti; elenco completo delle caselle di posta elettronica istitu-
zionali; elenco di tutti i bandi di gara; elenco dei servizi forniti in rete.
Obbligo per le Pubbliche amministrazioni di utilizzare la posta

elettronica per lo scambio di documenti ed informazioni, verificando-
ne la provenienza.
Obbligo per le Pubbliche Amministrazioni di adottare, a partire
dal � gennaio , quale unico standard di accesso ai servizi erogati
on-line esclusivamente la Carta d’Identità Elettronica e la Carta Na-
zionale dei Servizi.
Obbligo di trasferire fondi per via telematica tra Pubbliche am-
ministrazioni e tra esse ed i cittadini e le imprese.
Sistematico allargamento dello Sportello Unico Telematico delle
Imprese verso l’utenza, snellendo e facilitando il disbrigo on-line delle
pratiche e, soprattutto, avviando una omogeneizzazione delle relative
procedure a livello nazionale.
Diritto per i cittadini e le imprese a richiedere ed ottenere l’uso
delle tecnologie dell’informazione e della comunicazione nei rapporti
con le Pubbliche amministrazioni centrali e con i gestori di pubblici
servizi statali.
Obbligo per le Amministrazioni pubbliche di accettare da cittadini
e imprese i pagamenti effettuati on-line a partire dal � gennaio .
Possibilità per cittadini e imprese di accedere ai documenti e par-
tecipare al procedimento amministrativo grazie all’uso dei nuovi stru-
menti informatici.
Diritto di trasmettere documenti alla Pubblica Amministrazione
con qualsiasi mezzo telematico o informatico, purché sia accertata la
fonte di provenienza.
Possibilità, grazie alle nuove tecnologie, di una maggiore parte-
cipazione dei cittadini, anche residenti all’estero, alla formazione dei
processi decisionali attinenti alla collettività (e-Democracy).
Riconosciuto il valore probatorio al documento informatico.

5 Allegato: le fonti normative di riferimento
5.1 Fonti normative in materia di firma digitale

In materia di firma digitale bisogna innanzitutto fare riferimento
all’art. 15.2 della legge n. 59/97 (Bassanini 1) il quale prevede che
“gli atti, dati e documenti formati dalla pubblica amministrazione e
dai privati con strumenti informatici o telematici, i contratti stipulati
nelle medesime forme, nonché la loro archiviazione e trasmissione con
strumenti informatici sono validi e rilevanti a tutti gli effetti di legge”.
Merita di essere rilevato il fatto che si viene a stabilire il medesimo tipo
di criterio per il settore pubblico e per quello privato.
Per dare attuazione a tale previsione è stato successivamente ema-
nato il DPR 513/97 che è stato poi ricompreso nel DPR 445/2000.
Anche l’Unione Europea è intervenuta sulla tematica delle firme
con la direttiva CE 93/99 recepita dal legislatore italiano con il D.lgs
n. 10/02.
Tale recepimento ha presentato degli aspetti di problematicità
non soltanto perché la direttiva prevede più tipologie di firme elettro-
niche e diversi livelli di servizi di certificazione, ma soprattutto perché,
non occupandosi della validità giuridica del documento informatico,
lasciava al legislatore nazionale il compito di coordinare la disciplina
di tali firme, con le norme interne relative alla validità e all’efficacia
probatoria del documento con esse sottoscritto.
Il legislatore italiano ha stabilito che sia sufficiente la firma elet-
tronica affinché Il documento informatico soddisfi il requisito legale
della forma scritta.
Invece, affinché il documento informatico faccia piena prova,
fino a querela di falso, della provenienza delle dichiarazioni da chi l’ha
sottoscritto ha stabilito che debba essere sottoscritto con firma digi-
tale o con un altro tipo di firma elettronica avanzata, e la firma debba
basarsi su di un certificato qualificato ed essere generata mediante un
dispositivo per la creazione di una firma sicura.
Inoltre per la generazione della firma digitale deve utilizzarsi una
chiave privata la cui corrispondente chiave pubblica sia stata oggetto
dell’emissione di un certificato qualificato che, al momento della sot-
toscrizione, non risulti scaduto di validità ovvero non risulti revocato
o sospeso.
Attraverso il certificato elettronico si devono rilevare la validità
del certificato elettronico stesso, nonché gli elementi identificativi del
titolare e del certificatore.
Il legislatore ha poi previsto che in tutti i documenti informatici
delle pubbliche amministrazioni la firma autografa o la firma, comun-
que prevista, possa essere sostituita dalla firma digitale.
Per quanto riguarda le istanze e le dichiarazioni inviate per via
telematica alla P.A. esse sono valide:
a) se sottoscritte mediante la firma digitale, basata su di un cer-
tificato qualificato, rilasciato da un certificatore accreditato, e
generata mediante un dispositivo per la creazione di una firma
sicura;
b) ovvero quando l’autore è identificato dal sistema informatico
con l’uso della carta d’identità elettronica o della carta nazio-
nale dei servizi.
Fonti normative in materia di firma digitale e di strumenti
di identificazione
Delega al Governo per il conferimento di funzioni e compiti

L. 59/97 alle regioni ed enti locali, per la riforma della Pubblica
Amministrazione e per la semplificazione amministrativa
Regolamento recante criteri e modalità per la formazione,
DPR 513/97 l’archiviazione e la trasmissione di documento con strumenti
informatici e telematici a norma dell’art. 15 della legge n.59/97
Direttiva CE 93/99 Quadro comunitario per le firme elettroniche
Regolamento recante caratteristiche e modalità per il rilascio

DPCM 22/10/99
della Carta d’Identità Elettronica
Testo Unico delle disposizioni legislative e regolamentari in materia

DPR 445/00
di documentazione amministrativa
Attuazione della direttiva 1999/93/CE relativa ad un quadro

D.Lgs. 10/02
comunitario per le firme elettroniche
Regolamento recante disposizioni di coordinamento in materia

DPR 137/03 di firme elettroniche a norma dell’articolo 13 del decreto legislativo
n. 10, 23 gennaio 2002
Regole tecniche per la formazione, la trasmissione, la conservazione,
DPCM 13/01/2004 la duplicazione, la riproduzione e la validazione, anche temporale,
dei documenti informatici
Regolamento concernente la diffusione della Carta Nazionale

DPR 117/2004
dei -servizi
DPCM 2/07/04 Competenze in materia di certificatori di firma elettronica

5.2 Fonti normative in materia di e-mail certificata
Il  marzo  il Consiglio dei Ministri su proposta del Mi-
nistro per l’Innovazione e le Tecnologie e del Ministro per la Funzione
Pubblica ha approvato uno schema i DPR volto a disciplinare le mo-
dalità di utilizzo della Posta Elettronica Certificata sia nei rapporti con
la PA che tra privati cittadini.
Nella seconda metà di ottobre  le Commissioni parlamenta-
ri competenti hanno completato i lavori, valutando positivamente lo
schema di DPR relativo alla PEC.
Il  gennaio  il decreto è stato definitivamente approvato
dal Consiglio dei Ministri.
5.3 Fonti normative in materia di protocollo informatico

In base alla attuale normativa relativa al protocollo informatico le
pubbliche amministrazioni devono provvedere ad introdurre nei piani
di sviluppo dei sistemi informativi automatizzati progetti per la realiz-
zazione di sistemi di protocollo informatico.
Le pubbliche amministrazioni debbono dunque predisporre ap-
positi progetti esecutivi per la sostituzione dei registri di protocollo
cartacei con sistemi informatici.
Le pubbliche amministrazioni avrebbero dovuto provvedere
entro il � gennaio  a realizzare o revisionare sistemi informativi
automatizzati finalizzati alla gestione del protocollo informatico e dei
procedimenti amministrativi.
Ciascuna amministrazione deve individuare, nell’ambito del pro-
prio ordinamento, gli uffici da considerare ai fini della gestione unica
o coordinata dei documenti per grandi aree organizzative omogenee,
assicurando criteri uniformi di classificazione e archiviazione, nonché
di comunicazione interna tra le aree stesse.
I Concetti chiave riscontrabili nella normativa sono:
A) Sistema di gestione informatica dei documenti (in forma
abbreviata “sistema”) è l’insieme delle risorse di calcolo, degli
apparati, delle reti di comunicazione e delle procedure infor-
matiche utilizzati dalle amministrazioni per la gestione dei do-
cumenti; esso deve:
• garantire la sicurezza e l’integrità del sistema;
• garantire la corretta e puntuale registrazione di protocollo dei
documenti in entrata e in uscita;

• fornire informazioni sul collegamento esistente tra ciascun
documento ricevuto dall’amministrazione e i documenti dalla
stessa formati nell’adozione dei provvedimenti finali;
• consentire il reperimento delle informazioni riguardanti i do-
cumenti registrati;
• consentire, in condizioni di sicurezza, l’accesso alle informa-
zioni del sistema da parte dei soggetti interessati, nel rispetto
delle disposizioni in materia di tutela delle persone e di altri
soggetti rispetto al trattamento dei dati personali;
• garantire la corretta organizzazione dei documenti nell’ambito
del sistema di classificazione d’archivio adottato.
B) Registrazione di protocollo: per ogni documento ricevuto o
spedito dalle pubbliche amministrazioni è effettuata mediante
la memorizzazione delle seguenti informazioni:
• numero di protocollo del documento generato automatica
mente dal sistema e registrato in forma non modificabile;
• data di registrazione di protocollo assegnata automaticamente
dal sistema e registrata in forma non modificabile;
• mittente per i documenti ricevuti o, in alternativa, il destina-
tario o i destinatari per i documenti spediti, registrati in forma
non modificabile;
• oggetto del documento, registrato in forma non modificabile;
• data e protocollo del documento ricevuto, se disponibili;
• l’impronta del documento informatico, se trasmesso per via
telematica, costituita dalla sequenza di simboli binari in grado
di identificarne univocamente il contenuto, registrata in forma
non modificabile.
C) Segnatura di protocollo: operazione che va effettuata con-
temporaneamente alla segnatura di protocollo, è l’apposizio-
ne o l’associazione all’originale del documento, in forma per-
manente non modificabile, delle informazioni riguardanti il
documento stesso. Essa consente di individuare ciascun do-
cumento in modo inequivocabile. Le informazioni minime
previste sono:
• il progressivo di protocollo;
• la data di protocollo;
• l’identificazione in forma sintetica dell’amministrazione o dell’area.

Merita di essere segnalato il fatto che il legislatore si è occupa-
to di normare in maniera approfondita lo scambio documentale tra
Pubbliche Amministrazioni mentre si è occupato solo marginalmente
di disciplinare lo scambio documentale tra P.A. ed altri soggetti quali
privati cittadini, aziende, ecc.
Riguardo quest’ultimo punto l’Allegato n°3 al Primo Avviso per
la selezione di progetti di e-government “Interoperabilità dei sistemi
di protocollo e la Posta certificata” si è occupato dello scambio docu-
mentale tra cittadini e imprese dotati di una casella di posta certificata
e Pubblica Amministrazione (eventualità che, attualmente, risulta an-
cora poco frequente).
Fonti normative in materia di protocollo informatico e posta

elettronica certificata
DPR 428/98
Regolamento recante norme per la gestione del protocollo
(Abrogato e sostituito
informatico da parte delle amministrazioni pubbliche
dal DPR 445/2000)
Testo Unico delle disposizioni legislative e regolamentari in materia
DPR 445/2000
di documentazione amministrativa
Direttiva sulla trasparenza della azione amministrativa e gestione
Direttiva M.I.T 9/12/02
elettronica dei flussi documentali
Allegato n°3 al Primo
avviso per la selezione
Interoperabilità dei sistemi di protocollo e la posta certificata
di progetti
di e-government
Approvazione delle linee guida per l’adozione del protocollo
D.M. 14/10/03 informatico e per il trattamento informatico dei procedimenti
amministrativi
Direttiva
Impiego della posta elettronica nelle pubbliche amministrazioni
M.I.T.27/11/2003

PARTE II
IL PROGETTO FIRM@
6 Introduzione
6.1 Obiettivi del progetto

Il Progetto Firm@ si configura come un progetto di e-Govern-
ment attuato dalla Regione Lombardia, volto ad accelerare l’informa-
tizzazione dei processi di gestione del Programma Operativo Regionale
(POR), Obiettivo 3 del Fondo Sociale Europeo (FSE), attraverso l’in-
troduzione della Firma Digitale.
In particolare, il progetto si occupa di studiare e attuare soluzioni
che consentano alla Direzione Generale Formazione Istruzione e Lavo-
ro, che ha in carico l’Obiettivo 3 del FSE, di recepire documentazione
firmata con Firma Digitale eliminando, o comunque riducendo, scam-
bio di documentazione cartacea con gli operatori di formazione, ossia
i soggetti beneficiari del Fondo.
Da un punto di vista operativo, il progetto prevede la realizza-
zione delle procedure per la gestione di documentazione firmata con
firma digitale all’interno di MonitorWEB, l’applicativo già in uso per
la gestione on-line delle pratiche di richiesta di finanziamento.
Attraverso MonitorWEB, infatti, la Direzione Generale ha già
introdotto un ottimo livello di informatizzazione del processo: la tec-
nologia Internet/intranet permette agli operatori di intergire via WEB
con la Regione presentando i progetti e effettuandone la gestione in
itinere, e permette ai funzionari regionali di svolgere il loro lavoro di
ricezione, valutazione, gestione e controllo.
Gli operatori, accedendo a MonitorWEB attraverso una coppia
username –password riservate, hanno la possibilità di inserire e trasmet-
tere alla Regione le informazioni rilevanti nei diversi momenti dell’iter
della pratica. Non essendo gestita la Firma Digitale, tuttavia, l’utilizzo
dell’applicativo WEB non ha implicato, per quanto riguarda i docu-
menti più critici, l’abolizione della carta, ma il suo affiancamento alle
altre informazioni trasmesse dagli operatori alla Regione per via elet-
tronica. In altre parole, la documentazione cartacea, firmata in origi-
nale con firma autografa, viaggia per così dire in parallelo alla pratica
elettronica, lungo l’intero iter di lavoro.
L’introduzione della Firma Digitale rappresenta, quindi, un ul-
teriore passaggio per raggiungere un maggiore livello di informatizza-

zione che vede crearsi, accanto ad un archivio cartaceo costituito da
tutti i documenti inerenti una pratica e prodotti sia internamente che
esternamente alla Regione, un archivio elettronico parallelo.
Il progetto si propone di affrontare e avviare un processo di riso-
luzione delle diverse problematiche di carattere procedurale, organizza-
tivo e tecnologico derivanti dall’introduzione della Firma Digitale nella
gestione FSE. Le tematiche principali su cui è rivolta l’attenzione sono
le seguenti:
• i momenti e le modalità di comunicazione operatore-Regione
che prevedono la ricezione di documentazione da firmata da
parte degli operatori di formazione
• le tipologie di documento oggetto di scambio e le eventuali
criticità derivanti dall’introduzione della firma digitale
• le strutture regionali di riferimento che recepiscono, verifica-
no e validano la documentazione pervenuta da parte degli
operatori
• gli aspetti di contesto tecnologico ed informatico ai fini di una
proposta operativa per l’integrazione delle procedure di firma
all’interno del flusso informativo attuale
Per quanto riguarda gli aspetti di carattere procedurale, un pre-
supposto fondamentale per l’analisi condotta nel Progetto Firm@ è
il Manuale delle Procedure FSE, il documento ufficiale che descrive le
attività svolte all’interno della Direzione.
Per quanto riguarda gli aspetti organizzativi, si è individuato un
elemento di problematicità nel fatto che la firma digitale è, a tutt’oggi,
utilizzata solo in alcuni ambiti e sono poco conosciute le implicazioni
di carattere legale e operativo legate al suo utilizzo. Questo comporta
la necessità di prevedere un’adeguata istruzione sia del personale addet-
to al protocollo che dei funzionari regionali di riferimento, che devono
familiarizzarsi con la ricezione di documenti elettronici e con le pro-
cedure di gestione di situazioni anomale, muovendosi su un terreno
legislativo e tecnologico ancora poco conosciuto,
A proposito del contesto tecnologico, invece, facciamo presente
che l’attivazione del Progetto Firm@, va a coincidere con la fase di
sperimentazione, a cura di Lombardia Informatica, delle procedure per
la ricezione e la protocollazione di documenti firmati con firma digi-
tale pervenuti per via elettronica al Protocollo Elettronico Regionale.
Oltre alle problematiche di carattere prettamente applicativo, quin-
di, si tratta,almeno in una prima fase, di affrontare le problematiche

derivanti dalle modifiche apportate all’architettura del sistema Moni-
torWEB per permettere il dialogo col protocollo.
Queste osservazioni suggeriscono di collocare il Progetto Firm@
in un contesto strettamente sperimentale e di ipotizzare un passaggio in
produzione solo dopo la verifica e il consolidamento delle procedure
applicate ad un ristretto numero di pratiche e limitatamente ad alcuni
particolari momenti dell’iter burocratico dei progetti FSE.
E’, quindi, senz’altro da prevedere, per un periodo di tempo signi-
ficativo, un parallelismo tra le vecchie e le nuove modalità di trasmis-
sione di documenti, garantendo che il risultato finale sia esattamente il
medesimo, indipendentemente dal flusso procedurale seguito.
6.2 Ambito di riferimento

La Pubblica Amministrazione sta utilizzando le nuove tecnologie
basate su Internet per rinnovare e snellire l’iter burocratico di diver-
se procedure e per proporre alle aziende e ai cittadini, destinatari dei
servizi, una nuova immagine di sé stessa in termini di efficienza e di
efficacia.
L’utilizzo della rete permette lo sviluppo di progetti di e-govern-
ment, che si propongono la trasformazione delle relazioni interne ed
esterne della P.A. mediante l’uso di tecnologie informatiche e di comu-
nicazione :
Gli obiettivi di fondo di questi progetti sono:
• migliorare la disponibilità del servizio (efficacia del servizio)
• dare centralità a cittadini e imprese lungo tutto il ciclo di vita
del servizio
• semplificare le procedure amministrative
• ottimizzare le attività di produzione del servizio (efficienza del
servizio).
Un settore in cui la tecnologia Internet sta offrendo notevoli
vantaggi è quello della gestione delle richieste di finanziamento di at-
tività da parte di aziende, enti o privati cittadini su fondi erogati dalla
P.A.. Questo tipo di pratiche prevede, solitamente, iter piuttosto lun-
ghi e complessi, a partire dalla distribuzione dei formulari cartacei, con
tutti i problemi di aggiornamento e di adeguamento a nuovi criteri
che vengono via via deliberati, alla loro consegna agli sportelli abilitati,
fino all’erogazione del finanziamento e alla certificazione delle spese
da parte del destinatario, attraverso tutti i passaggi intermedi quali
l’istruttoria e le fasi di gestione in itinere.

Il beneficiario spesso non ha visibilità di quanto succede alla pra-
tica nei diversi passaggi e stenta ad avere precisi riferimenti interni alla
P.A. a cui rivolgere i propri dubbi e le proprie richieste.
A questo proposito, la tecnologia internet sta certamente rappre-
sentando la chiave di volta per la rivisitazione di questo tipo di proces-
si: gli utenti (enti di formazione, aziende, enti pubblici, ecc.) possono
accedere al sito web e consultare le informazioni relative alla legge e
ai fondi di loro interesse (destinatari, spese ammissibili, tempi per la
presentazione etc.) e, una volta compilata e presentata la pratica on-
line, seguirne in tempo reale lo stato di avanzamento, inviare quando
richiesto i moduli di certificazione della spesa, e effettuare attraverso
il sito tutte le altre operazioni di carattere gestionale e amministrativo
previste.
I vantaggi così ottenuti per i beneficiari finali si possono riassu-
mere nel modo seguente:
• l’utente non ha più bisogno di recarsi agli sportelli per richie
dere informazioni e la modulistica per presentare i progetti
• l’utente compila il progetto dall’ufficio o da casa, tramite Inter
net, e poi lo invia alla Struttura di competenza sempre via In
ternet
• il servizio è fruibile  ore al giorno, sette giorni su sette
• la possibilità di errori è fortemente ridotta
• per consultare e compilare la modulistica non c’è bisogno di
installare software particolari, ma è sufficiente un normale
browser
• si può seguire in tempo reale lo stato di avanzamento dei pro-
pri progetti
• i ritardi nel flusso di lavoro diminuiscono con un vantaggio
per tutti.
I vantaggi offerti alla P.A. sono altrettanto evidenti:
• l’immagine della Struttura di competenza offerta al pubblico è
quella di un centro vitale ed efficiente, capace di dare e ricevere
informazioni e servizi in modo puntuale e rapido
• la banca dati relativa ai progetti è automaticamente alimentata
a partire dal data-entry effettuato dagli tenti, senza ulteriori
oneri di inserimento
In particolare, Firm@ riguarda il finanziamento di progetti di

formazione attraverso i fondi stanziati per l’Obiettivo 3 del Fondo so-
ciale Europeo, gestiti dalla Regione Lombardia - Direzione Generale,
Istruzione, Formazione e Lavoro. I beneficiari sono gli operatori di
formazione (operatori nel seguito) che svolgono attività di formazione
nell’ambito della Lombardia.
L’iter per ottenere il finanziamento è piuttosto articolato, ma, dal
punto di vista del beneficiario, può essere riassunto nelle seguenti fasi
fondamentali:
• la pubblicazione di un bando di gara che stabilisce il settore
della formazione, le risorse disponibili e le caratteristiche dei
destinatari
• la presentazione dei progetti da parte degli operatori interessati
• la valutazione dei progetti
• la comunicazione, da parte degli operatori alla Regione, di infor-
mazioni rilevanti in alcuni momenti critici di avanzamento dei
progetti, quali l’avvio e la conclusione delle attività formative
• il rilascio degli attestati regionali ai partecipanti ai progetti
• la certificazione delle spese
• l’erogazione di acconti e del saldo finale
• eventuali controlli ispettivi effettuati presso l’operatore per ve-
rificare il corretto svolgersi delle attività
6.3 Documentazione di riferimento

L’argomento trattato dal Progetto Firm@ è vasto e complesso
e necessita, per una piena comprensione, della conoscenza di diversi
presupposti di base concernenti sia gli aspetti di carattere legale e le-
gislativo legati alla Firma Digitale che di quelli legati alle procedure,
alle modalità di attuazione e agli strumenti informatici di supporto
all’attività della D.G.
Riteniamo indispensabile, quindi, citare le fonti documentali di
riferimento relativi ad aspetti di carattere generale, procedurale e tec-
nologico già consolidati, ritenuti presupposti di partenza indispensabi-
li per la comprensione dell’analisi che segue. Esse sono esplicitate nei
seguenti punti:
- Il documento “Progetto Firm@ - Parte I”, in cui si sono esami-
nate le problematiche di carattere generale, legale e legislativo
legate all’introduzione della firma digitale nella Pubblica Am-
ministrazione

- il “Manuale delle Procedure FSE”, il documento ufficiale della
D.G. decretato con Atto Formale n. data, in cui vengono de-
scritti in modo analitico i processi principali attraverso cui la
Direzione Generale Formazione, Istruzione e Lavoro svolge la
propria attività di programmazione, gestione e controllo del
Programma Operativo Obiettivo 3 del Fondo Sociale Europeo
(-)
- le “Specifiche Tecniche di MonitorWEB” stilate e distribuite
a cura di Archidata. MonitorWEB è il Sistema Informativo
Regionale, realizzato in architettura Internet, utilizzato per la
presentazione dei progetti di Fondo Sociale Europeo a cura
degli operatori di formazione e per la gestione degli stessi da
parte delle Strutture competenti della alla D.G. Formazione
Istruzione e Lavoro della Regione Lombardia
Ulteriori presupposti di partenza utili alla comprensione di
quanto segue, sono le modalità di implementazione del protocollo in-
formatico a cura di Lombardia Informatica. Tali modalità non sono a
tutt’oggi consolidate in quanto è prevista la loro sperimentazione pro-
prio contestualmente a quella del Progetto Firm@. A tale proposito è
opportuno senz’altro citare i seguenti documenti, stilati e distribuiti a
cura di Lombardia Informatica s.r.l.:
“Linee guida per l’interoperabilità tra Portali Verticali e Protocollo”...
“Documento tecnico per l’integrazione tra Portali Verticali e Protocollo”...
Rimandando, quindi, ai documenti di cui sopra per la definizio-
ne del contesto legislativo, procedurale ed informatico in cui si opera,
ci si propone qui di definire nello specifico le procedure in cui attivare
la sperimentazione della Firma Digitale, descrivendone le nuove mo-
dalità di attuazione confrontandole con le precedenti.
Nel seguito del capitolo viene approfondito maggiormente il
contesto, esaminando alcuni aspetti di dettaglio relativi:
• alla struttura della Direzione Generale Formazione, Istruzione
e Lavoro, committente del progetto
• alle procedure di gestione del Programma Operativo Regionale
• al Sistema Informativo che attualmente supporta l’attività de-
gli operatori di formazione e dei funzionari regionali
Questi argomenti sono ampiamente sviluppati nel Manuale delle
Procedure FSE citato in premessa e vengono qui richiamati in modo

sintetico solo gli aspetti interessanti ai fini del “Progetto Firma”. Delle
procedure di gestione e del Sistema Informativo, quindi, si prende-
ranno in considerazione solo i momenti che prevedono scambio di
corrispondenza tra operatori e Regione Lombardia. Si rimanda, quin-
di, alla lettura del “Manuale delle Procedure” per ogni altro ulteriore
approfondimento.
6.4 Articolazione del Progetto

Segue una tabella riassuntiva con le principali fasi in cui si ar-
ticola il Progetto Firma@, con il dettaglio delle attività previste, dei
risultati attesi e del ruolo giocato dai diversi membri della compagine
proponente del progetto.
Tabella riepilogativa evoluzione normativa
Fase Attività principali Risultati attesi Ruolo
- analisi di esperienze Documento di sintesi Lattanzio & Associati

di firma digitale contenente:
nella P.A. Think Lab
- analisi delle - aspetti di carattere
problematiche generale sulla firma
legate alla attivazione digitale e sua intro
della firma digitale duzione nella P.A.
sotto i diversi aspetti: - esperienze di firma
procedurale, digitale nella P.A.
tecnologico, - aspetti di carattere
organizzativo/culturale procedurale e orga
1 Analisi e
all’interno nizzativo nell’intro
modello
della gestione FSE duzione della firma
di soluzione
- sviluppo relativo a nella gestione FSE
MonitorWEB - modello di soluzio
- descrizione del modello ne adottato
di funzionamento - specifiche tecniche
esplicitando vincoli e della soluzione
alternative di soluzioni
informative (macro Action Plan del Pro-
flussi) e gestionali getto Firm@
- messa a punto
di un action plan
di riferimento
sviluppo e attivazione attivazione della fase Think Lab
2 Sviluppo dei
dei moduli software di sperimentazione
moduli sw
necessari

- manuale operativo per Manuale operativo Lattanzio & Associati
il funzionamento (proce- del funzionamento
durale) del processo
gestito da Monitorweb
3 Progettazione
- rappresentazione dei
funzionamento
flussi informativi e dei
di dettaglio
processi
- esplicitazione dei ruoli
- definizione delle
procedure di riferimento

7 Aspetti di contesto
In questo capitolo viene fornito il contesto organizzativo in cui

si colloca il Progetto Firm@, attraverso la descrizione sintetica dei se-
guenti aspetti:
• le strutture interne alla Direzione Generale Formazione, Istru-
zione e Lavoro che hanno in gestione l’attività FSE
• le procedure di gestione suddivise per area d’intervento
• il Sistema Informativo attuale, che deve ospitare le procedure
di gestione della firma digitale
Quanto riportato è un estratto di argomenti ampiamente trattati
nel Manuale delle Procedure FSE, citato tra i documenti essenziali di
riferimento.
7.1 Strutture regionali di riferimento per la gestione FSE

Il Manuale delle procedure FSE classifica i principali attori regio-
nali coinvolti nella gestione del Fondo in:
• Autorità di Gestione
• Autorità di Pagamento
• Autorità di Controllo di II Livello.
7.1.1 Autorità di Gestione

L’organizzazione della DG Formazione Istruzione e Lavoro at-
tualmente si articola in Unità Organizzative all’interno delle quali sono
presenti diverse strutture. Ciascuna U.O. e quindi ciascuna struttura
opera, per le attività di sua competenza come autorità di Gestione.
La Giunta Regionale, attribuisce la responsabilità dell’attuazione
del POR FSE 2000-2006 alla DG Formazione Istruzione e Lavoro.
Le varie competenze dell’Autorità di Gestione vengono poi suddivise,
nell’ambito della stessa DG, attraverso atti formali interni.
Conformemente al regolamento CE 1260/1999 l’Autorità di
Gestione è responsabile dell’efficacia e della regolarità ella gestione e
dell’attuazione degli interventi finanziati dal FSE o da altre fonti co-
munitarie.

• predisposizione delle modifiche del complemento di program
mazione
• elaborazione e presentazione del rapporto annuale di esecuzione
• organizzazione della valutazione intermedia, in collaborazione
con lo Stato Membro e la Commissione
• predisposizione e definizione dei dispositivi e degli atti conse
quenziali
• selezione dei progetti
• adempimenti delle procedure connesse alla gestione (avvio,
modifiche, revoche, ecc.)
• gestione degli importi da recuperare relativi a pagamenti già
effettuati
• vigilanza sul rispetto degli obblighi in materia di informazione
e pubblicità
• compatibilità politiche comunitarie (appalti, pari opportunità,
ambiente)
• aiuti di stato
• attuazione di misure di controllo interne volte a verificare la
regolarità delle operazioni finanziate
• controllo sull’avanzamento della realizzazione dei progetti
• ricezione controllo dei dati di spesa nonché garanzia della loro
reperibilità
• adozione di disposizioni per la disciplina delle attività di ge-
stione e di controllo
Organigramma della dg formazione, istruzione e lavoro

Unita’ organizzative, strutture e loro ruolo
U.O. Struttura Ruolo
• Predispone gli atti tipici della

programmazione pluriennale in
materia di formazione istruzione
e politiche del lavoro, in armonia
con la programmazione regio
nale. Stabilisce le modalità di
Piani e programmi attuazione dell’erogazione dei
finanziamenti.
• Predispone i dispositivi (BANDI)
di finanziamento;
• Si occupa dell’Accreditamento
delle sedi
Qualificazione • Opera una valutazione
dei sistemi riforme di legittimità e di merito
e programmazione sia sulle Azioni di sistema
che sulle Azioni rivolte
Qualificazione dei sistemi alle persone;
• Svolge controlli a campione sugli
operatori che hanno ottenuto
i finanziamenti FSE
• Assiste la Direzione generale
per la realizzazione di un sistema
Innovazione del sistema organico di Obbligo Formativo
educativo, dell’istruzione • Supporto la Direzione generale
e della formazione professionale nella definizione dei criteri
di articolazione territoriale
dell’offerta formativa
Politiche attive e preventive

del lavoro
• Ciascuna struttura coadiuva
Formazione continua e sviluppo la struttura Piani e Programmi
dell’imprenditorialita’ nella predisposizione
dei dispositivi di finanziamento
Formazione che riguardano ciascuna tipologia
emercato Formazione professionale specifica di intervento formativo;
del lavoro
Centro permanente • Ciascuna struttura si occupa
per l’innovazione dei sistemi della gestione operativa
informativi del progetto relativo alla sua area
di intervento
Supporto del sistema formazione

Istruzione e diritto allo studio • Ciascuna struttura coadiuva
la struttura Piani e Programmi
nella predisposizione dei disposi
tivi di finanziamento che riguar
Sistema educativo dano ciascuna tipologia specifica
e universita’ di intervento formativo;
Formazione superiore e universita’ • Ciascuna struttura si occupa
della gestione operativa
del progetto relativo
alla sua area di intervento
• Autorità di pagamento FSE.verifi

ca degli indicatori fisici e finanzia
ri FSE raccordandosi con il
Monitoraggio Sistema Informativo Ragioneria
flussi finanziari Generale dello Stato
Autorita’ di pagamento F.S.E.
e relazioni
istituzionali f.S.E. • Supporta l’attività del valutatore
indipendente. Monitora e sempli
fica i flussi finanziari FSE .Certifica
zione la spesa FSE
7.1.2 Autorità di Pagamento

L’Autorità di Pagamento, secondo quanto stabilito dai regola-
menti CE / e 438/, ha la responsabilità della gestione
complessiva dei flussi di risorse finanziarie del Programma/i finan-
ziato/i.
È infatti l’organismo preposto alla ricezione dei pagamenti dalla
Commissione Europea e dal Ministero dell’economia e delle Finanze
nonché all’elaborazione e alla presentazione delle richieste di pagamento.
L’Autorità di Pagamento e l’Autorità di Gestione sono collocate
in strutture distinte per assicurare la necessaria segregazione funzionale
tra la gestione delle attività di controllo e di certificazione delle spese
da quelle di gestione vera e propria degli interventi.
Tale separazione nel caso specifico della Regione Lombardia è
assicurata dall’attribuzione della qualità di Autorità di Pagamento, e
quindi dei compiti ad essa affidati, ad un ufficio specifico - Struttura
Monitoraggio FSE – gerarchicamente sottoposto all’U.O. Attuazione
Misure FSE.
Quest’U.O. non svolge funzione di line rispetto al POR, per cui
non ha né la necessità né tanto meno la responsabilità di svolgere fun-
zioni sovrapponibili all’Autorità di Gestione.
L’Autorità di pagamento inoltre accede direttamente a tutti i dati
del sistema informativo

7.1.3 Autorità di Controllo di II livello
Un accenno all’’Autorità di Controllo di II livello.
In posizione di indipendenza rispetto ai responsabili degli altri
processi quest’autorità ha la responsabilità del monitoraggio sistema-
tico dell’andamento delle operazioni e dei loro risultati, sia in termini
qualitativi che quantitativi. Ha inoltre il compito di accertare l’adegua-
tezza del sistema del controllo dei primo livello.
Le diverse tipologie di controllo svolte sono classificate in base al
soggetto destinatario della verifica.
7.2 Le procedure di gestione dei Progetti FSE

Una volta individuati i principali attori regionali coinvolti nel
processo di gestione del POR, il Manuale delle procedure FSE va ad
individuare e descrivere nel dettaglio le attività svolte dalle Autorità di
Gestione e di Pagamento, classificandole per aree di intervento. Essen-
do le procedure svolte dalla Autorità di Controllo di II livello, di com-
petenza della Direzione Generale Bilancio, non rappresentano oggetto
di indagine. Vengono, invece, individuate alcune procedure trasversali
rispetto alle Autorità di Gestione e di Pagamento.
7.2.1 Procedure dell’Autorità di Gestione

Area programmazione che comprende:
• Programmazione del POR e del CdP
• Programmazione ed emissione dei Dispositivi
Procedure di accesso che comprendono
• Accreditamento delle sedi operative

• Presentazione dei progetti
• Valutazione e selezione dei progetti
Area gestione che comprende:
• Gestione delle attività
• Gestione della Garanzia Fidejussoria
• Gestione della certificazione antimafia
• Gestione delle Commissioni d’esame e rilascio attestati
• Gestione delle revoche
• Gestione esiti dei controlli
Area finanziaria che comprende:
• Gestione delle spese (impegni e liquidazioni)
• Certificazioni intermedie della spesa e rendicontazione finale
del Beneficiario Finale
• Concessione di Aiuti di Stato
Area controllo che comprende:
• Controllo ordinario di primo livello (In ufficio ed in loco)
• Procedure di controllo automatico - Controllo ordinario di
primo livello (in ufficio)
• Controllo ordinario di primo livello (in loco) – Controllo
ispettivo
• Piste di controllo dell’Autorità di Gestione
Area valutazione, monitoraggio, informazione e sorveglianza
che comprende:
• Valutazione del programma
• Monitoraggio delle attività
• Piano di informazione e comunicazione
• Sorveglianza del programma
• Preparazione delle riunioni del Comitato di Sorveglianza
• Rapporto annuale di esecuzione
7.2.2 Procedure dell’autorità di pagamento

• Certificazione della spesa
• Gestione delle entrate

• Piste di controllo dell’Autorità di Pagamento
• Rettifiche finanziarie
7.2.3 Procedure Generali

• Protocollo
• Gestione e archiviazione dei documenti
• Sistema informativo
7.3 La Gestione Documentale

Particolare attenzione per il Progetto Firm@ merita la procedura
Gestione e archiviazione dei documenti citata tra le Procedure Generali.
In essa, infatti, tra l’altro, viene descritta l’attuale articolazione e orga-
nizzazione dell’archivio delle pratiche FSE -.
Tale archivio risulta suddiviso nelle seguenti principali sezioni:
a) l’archivio progetti non finanziati, che contiene la documenta-
zione delle domande di finanziamento dei progetti non am-
messi (NA) e non finanziati (NF);
b) l’archivio progetti in corso, distribuito presso i diversi uffici e
le strutture di competenza;
c) l’archivio progetti conclusi, che archivia i progetti conclusi,
rendicontati e saldati. E’ concentrato in appositi locali;
d) l’archivio pagamenti, suddiviso in archivio Progetti e archivio
Operatori e finalizzato a supportare le attività di pagamento
relative ai progetti finanziati e ancora in corso;
e) l’archivio accreditamento, che raccoglie la documentazione
relativa all’accreditamento delle sedi operative ed è collocato
presso la struttura che si occupa della procedura di accredita-
mento;
f) l’archivio valutazione, che raccoglie la documentazione (decreti di
costituzione dei nuclei di valutazione, verbali, graduatorie, richie-
ste di riesame, ecc.) relativa alla valutazione dei progetti FSE;
g) l’archivio dell’Ufficio ispettivo, che raccoglie le pratiche relati
ve alle visite ispettive.
Oltre a questi archivi, vanno ricordati anche gli archivi informa-
tici che integrano e completano le informazioni presenti negli archivi
cartacei.

La struttura complessiva degli archivi cartacei e informatici può
essere sinteticamente così rappresentata:
Ai fini del Progetto Firm@, come meglio esplicitato nel Capitolo

4., ci concentriamo sui documenti inerenti i progetti FSE, riassumibili
nello schema seguente in cui sono organizzati a seconda della fase pro-
cedurale.

Cartaceo Informatico Documenti e informazoni generali
✓ Domanda di contributo sottoscritta dal:
 legale rappresentante
 procuratore
 persona delegata con atto del...
 altro
✓ Progetto originale (fase di presentazione)
✓ Progetto aggiornato o variato (in corso o concluso)
✓ Dati anagrafici dell’Operatore
✓ Dati relativi alle sedi operative
Copia della carta d’identità del soggetto che sottoscrive
✓
la domanda di contributo
Atto costitutivo o statuto oppureriferimento alla pratica
✓
dove è archiviato...
✓ Certificato di iscrizione alla C.C.I.A. o depositato c/o...
✓ Modifiche statutarie
✓ Scheda di valutazione del progetto
✓ Domanda riesame valutazione
✓ Motivazione acoglimento/rigetto della domanda
✓ Lettera di intenti ATS/accordo di partership
✓ Costituzione ATS
✓ Certificazione antimafia (se richiesta)
✓ Enta delegato
✓ Lettera di sostegno delle parti sociali
✓ Dichiarazione di conformità provinciali
✓ Dichiarazione di intenti di aziende interessate agli stage
✓ Business Plan
✓ Atri documenti

Cartaceo Informatico Atti formali e comunicazioni agli Operatori
✓ Decreto di approvazione delle agraduatorie
Lettera di esito istruttoria
✓
(procedura adottata per i primi dispositivi)
✓ Pubblicazione dell’esito istitutoria sul BURL con relativi dati
✓ Corrispondenza
✓ ✓ E-mail
✓ Variazione del Legale Rappresentante
 Allegato verbale di assemblea straordinaria

o altro documento attestante la variazione
Richiesta di modifica motivata del nominativo
✓
del revisore contabile
✓ Autorizzazione
✓ Richiesta di variazione della sede di svolgimento del corso
✓  allegata autocertificazione idoneità strutture

Decreti (revoca, rinuncia, riparametrazione,
✓
fermo amministrativo, ecc.
✓ Richiesta di deroghe
✓ Autorizzazioni alle deroghe
Cartaceo Informatico Documenti avvio

✓ Dati generali relativi all’avvio
✓ Atto di adesione firmato
Comunicazione avvio sottoscritta dal legale
✓
rappresentante contenente:
 Dichiarazione del legale rappresentante

che comprovi il possesso da parte degli allievi
dei requisiti richiesti dal dispositivo
 Autocertificazione relativa all’adempimento

degli abblighi collegati alle modalità
di selezione, definiti nel progetto
 Comunicazione nominativo revisione contabile

incaricato
 Autocertificazione per le strutture non accreditate

✓ Data e n. pagine registro vidimato
✓ Schede stage vidimate registrate
✓ Anagrafica allievi
✓ Elenco allievi con firme autografate
✓ Variazione elenco allievi
✓ Calendario di massima
Piano di attività
✓
(per azioni di sistema e sovvenzioni globali)
Stato avanzamento lavori
✓

Cartaceo Informatico Liquidazioni e saldi
✓ Dati generali sui movimenti contabili relativi al progetto
Archivio
✓ Dati sull’Operatore (Banca, conto corrente, ecc.)
pagamenti
Archivio
✓ Decreti di impegno
pagamenti
Archivio
✓ Decreti di liquidazione
pagamenti
Archivio
✓ Decreto di saldo
pagamenti
Cartaceo Informatico Certificazioni contabile della spesa

✓ Piano dei conti Fondo Sociale Europeo
✓ Dati relativi alle certificazioni della spesa
✓ Elenco giustificativi di spesa
Autocertificazione - intermedia
✓
(firmata dal legale rappresentante)
Autocertificazione - finale
✓
(firmata dal legale rappresentante)
Relazione di certificazione intermedia della spesa
✓
(firmata del revisore)
Relazione di certificazione finale della spesa
✓
(firmata del revisore)
Richieste di ulteriori acconti
✓ Garanzia fidejussoria (se richiesta)
✓ Svincolo fidejussoria
Cartaceo Informatico Verifiche ispettive

✓ Variabili di ispezione
✓ Provvedimenti:
 Archiviazione senza rilievi

 Diffida
 Revoca
Variabili di ispezione
 provvedimenti conseguenti
✓ Variabili G.D.F.
 provvedimenti conseguenti
✓ Altro

Cartaceo Informatico Fine Attività
✓ Comunicazione fine attività progetto
✓ Relazione finale
✓ Richiesta di commissione d’esami
✓ Richiesta rilascio attestati
✓ Verbale e prove di accertamento finale
Cartaceo Informatico Segnalazioni/esposti

✓ Eventuali segnalazioni/esposti
✓ Altra documentazione su segnalazioni/esposti
7.4 Il Sistema informativo per la gestione FSE

Il Sistema informativo per la gestione FSE da parte della Direzio-
ne generale Formazione, Istruzione e Lavoro è costituito dall’insieme
delle informazioni, dei flussi e dei processi organizzativi e informati-
vi che trattano sia manualmente, sia elettronicamente le informazioni
connesse alla gestione, al finanziamento e al controllo del Programma.
Esso può essere descritto anche come un insieme di processi, ciascuno
dei quali svolge un insieme di attività, tratta una certa classe di eventi e di
informazioni ed è eseguito da una o più unità organizzative.
In estrema sintesi, il Sistema informativo prevede le funzionalità utili:
1. alla compilazione, da parte degli operatori di formazione, delle
pratiche di richiesta di finanziamento e di richiesta di accredi-
tamento
2. alla valutazione, gestione e controllo della pratiche pervenute
da parte dei funzionari preposti
3. alla consultazione ed estrapolazione delle informazioni attra-
verso interrogazioni complesse della banca dati
4. alla reportistica per la gestione e il monitoraggio del Programma
5. alla gestione finanziaria del Programma
6. alla trasmissione delle informazioni relative al monitoraggio al
Ministero del Tesoro e del Bilancio tramite il Sistema Informa-
tivo della Ragioneria Generale dello Stato (SIRGS)
7. alla comunicazione dei dati al data warehouse direzionale
Le funzionalità di cui ai punti . e . sono messe a disposizione
dall’applicativo MonitorWEB, prevalentemente rivolto alle attività di
carattere gestionale. Sono, di fatto, le funzionalità utili al supporto

informatico alle procedure dell’Autorità di Gestione relative alle Aree:
Procedure di accesso, Area Gestione, Area Controllo e, parzialmente, Area
Finanziaria. Attraverso MonitorWEB, infatti, viene effettuata la certi-
ficazione intermedia e finale delle spese da parte dei beneficiari finali.
Le funzionalità di cui ai punti . e . sono messe a disposizione da
Nautilus, un sistema di monitoraggio e analisi dati disegnato secondo i
criteri progettuali dell’architettura client-server e orientato alla business
intelligence. Per motivi di efficienza, dovendo accedere alle informazio-
ni in sola consultazione, lavora su una copia aggiornata giornalmente
della banca dati di MonitorWEB. Sono funzionalità utili a supportare
in modo trasversale l’attività di tutte le Aree, in particolare dell’ Area
valutazione, monitoraggio, informazione e sorveglianza.
Per quanto riguarda il punto . l’articolazione degli strumenti
è più complessa: per la produzione e gestione degli atti legati all’iter
burocratico e finanziario delle pratiche (es. atti di approvazione, di im-
pegno e pagamento) è in uso, all’interno di delle Direzioni Generali re-
gionali, la procedura informatica di Atti Formali curata da Lombardia
Informatica s.p.a. Atti Formali si interfaccia a sua volta alla procedura
del Bilancio in uso presso la Ragioneria di Stato, per quanto riguarda la
gestione delle risorse finanziarie. Tra Atti Formali e MonitorWEB-Nau-
tilus c’è uno scambio reciproco di informazioni: MonitorWEB-Nautilus
mettono a disposizione delle strutture regionali competenti le infor-
mazioni e la reportistica utile ad attivare la stesura di atti di impegno
e pagamento. Tale reportistica comprende, ad esempio, le graduatorie
stilate dopo la fase di valutazione e le informazioni relative alla certifi-
cazione della spesa in base alle quali vengono liquidati ai beneficiari gli
acconti e il saldo relativi ad un progetto. Viceversa, le informazioni di
carattere finanziario relative agli atti vengono recepite all’interno della
banca dati di MonitorWeb ai fini del mantenimento di tutte le informa-
zioni utili a produrre il monitoraggio fisico, procedurale e finanziario.
Sono comprese nel punto  le funzionalità utili al supporto informati-
co delle procedure dell’Area Finanziaria.
Per quanto riguarda il punto ., apposite procedure si preoccupa-
no di trasmettere al sistema SIRGS i dati di monitoraggio, attraverso
l’interfaccia di comunicazione MonitWEB. L’area di riferimento è an-
cora l’Area Finanziaria.
Per quanto riguarda il punto . la banca dati di viene messa a
disposizione per alimentare, con apposite procedure a cura della Re-
gione, il data warehouse rivolto al sistema direzionale.
Dato che il Progetto Firm@ riguarda in modo specifico l’intro-
duzione della firma digitale all’interno delle procedure relative all’Area

di Accesso e all’Area di Gestione, viene approfondita solo la compo-
nente MonitorWEB dell’intero Sistema Informativo.
7.4.1 MonitorWEB - Schema complessivo del sistema

Lo schema complessivo di MonitorWEB è il seguente:
Attraverso MonitorWEB gli enti di formazione effettuano la pre-

sentazione on-line dei progetti e delle domande di accreditamento e,
per i progetti che vengono finanziati, comunicano alla Regione ulterio-
ri informazioni utili nelle fasi più significative dell’iter: l’avvio e la con-
clusione delle attività formative, la certificazione delle spese sostenute e
il rilascio dei certificati/attestati.
Da parte degli organi di gestione, invece, attraverso MonitorWEB
viene svolta la procedura di valutazione dei progetti e vengono inserite
o modificate le informazioni utili alla gestione dei progetti quali: i dati
di protocollo, lo stato di avanzamento e i principali parametri fisici,
finanziari e procedurali che possono variare in corso d’opera. Sempre
a cura degli organi di gestione viene gestito, attraverso il sistema infor-

mativo, il processo di autorizzazione e rilascio dei certificati/attestati
regionali e, viene, inoltre, autorizzata l’emissione dei pagamenti da
parte dell’Ufficio competente.
Un apposito modulo permette la gestione dell’attività di control-
lo di primo livello, ossia delle visite ispettive effettuate presso gli enti
di formazione per verificare il corretto svolgersi delle attività formative
oltre che la corretta gestione contabile e amministrativa.
Sui dati di MonitorWEB relativi a enti di formazione, progetti,
partecipanti viene infine effettuato il monitoraggio finanziario e proce-
durale di tutta l’attività di formazione legata al Fondo Sociale Europeo.
Nel seguito vengono esaminati più nel dettaglio i diversi moduli.
7.4.2 Presentazione progetti

Il modulo permette agli enti di formazione di effettuare la pre-
sentazione on-line di richieste di finanziamento di progetti di Fondo
Sociale Europeo. Le operazioni gestite attraverso il Sistema Informati-
vo sono le seguenti:
7.4.2.1 Pubblicazione di un bando di gara

Dopo essere stato pubblicato sul BURL, viene resa disponibile su
MonitorWEB la modulistica elettronica relativa ad un nuovo bando.
La modulistica è costituita da più sezioni, ossia più pagine WEB in cui
vengono logicamente raggruppate le informazioni del progetto richie-
ste per quel bando: informazioni di carattere testuale sui contenuti,
informazioni di carattere finanziario, numero di partecipanti etc. La
modulistica resta disponibile durante tutto il periodo di apertura del
bando mentre ne viene inibito l’utilizzo alla data di chiusura.
7.4.2.2 Registrazione di un ente di formazione

La registrazione permette all’ente di formazione di fornire al Si-
stema Informativo le proprie credenziali e di ottenere i dati di accesso
ai servizi utili alla presentazione dei progetti.
Il valore di username viene proposto dall’ente mentre la password
viene assegnata in automatico dal Sistema e inviate via e-mail.
E’ prevista una fase di validazione del profilo dell’ente da parte di
un apposito Ufficio al fine di far sì che non siano presenti in banca dati
più registrazioni corrispondenti ad un singolo ente.

7.4.2.3 Compilazione e trasmissione della modulistica
Gli enti che hanno effettuato con successo la registrazione al Si-
stema Informativo possono procedere con la compilazione dei progetti
sui bandi pubblicati e aperti. Fino a quando l’ente non effettua l’invio
telematico della domanda attraverso un’apposita funzione, la domanda
resta in stato di bozza e l’ente può tornare a più riprese sul progetto
per apportarne le modifiche opportune. In questa fase il progetto non
è visibile ai funzionari regionali preposti alla gestione.
Al momento dell’invio telematico, invece, il Sistema Informativo
verifica la congruità di quanto inserito con le specifiche del bando a
cui si riferisce il progetto e, se non vengono riscontrate anomalie, con-
ferma l’avvenuta operazione, inibendo ulteriori modifiche al progetto
e rendendolo disponibile ai funzionari regionali all’interno dell’area
loro riservata. Dal momento che, come anticipato in premessa, non
essendo a tutt’oggi operativa la firma digitale occorre un documento
cartaceo firmato dal legale rappresentante per completare la pratica, il
Sistema Informativo permette all’ente di stampare in automatico una
Dichiarazione Riassuntiva contenente le principali informazioni del
progetto e l’esplicito riferimento agli allegati inviati per via elettronica.
7.4.3 Valutazione
Il Sistema Informativo propone un’area riservata ai membri del
Nucleo di Valutazione che ha in carico la protocollazione dei progetti
presentati e della successiva fase istruttoria, in cui i progetti vengono
esaminati per essere ammessi o meno al finanziamento. Prima di en-
trare nel merito di un progetto, i valutatori ne giudicano l’ammissibi-
lità formale (valutazione ex-ante). Se la domanda risulta correttamente
presentata viene giudicata secondo i diversi criteri di valutazione, già
precedentemente stabiliti al momento della pubblicazione del bando.
Per ogni criterio è previsto un set di risposte disponibili a ognuna delle
quali è associato un diverso punteggio. Al termine della valutazione
si assegna ad ogni progetto un punteggio complessivo derivante dalla
somma dei punteggi ottenuti sui diversi criteri. I criteri sono relativi sia
al soggetto/compagine proponente che al progetto.
Il Sistema Informativo permette al Nucleo di Valutazione di pre-
disporre on-line la modulistica per la valutazione dei progetti e degli
enti proponenti. In altre parole, i membri del Nucleo possono inserire
nel sistema nuovi criteri, assegnarne il set di valori ammessi associan-
dovi i punteggio e creare, quindi, le schede di valutazione. Per ogni
progetto e ente del bando, procedono poi con la compilazione delle

relative schede e, al termine, il Sistema Informativo effettua in automa-
tico il calcolo del punteggio complessivo di ogni progetto, dato dalla
somma dei punteggi ottenuti sul progetto stesso e sull’ente proponente.
Una volta terminata la valutazione di tutti i progetti di un bando,
il Sistema Informativo è in grado di ordinare i progetti ammissibili per
punteggio in modo decrescente, stilandone, quindi, in automatico la
graduatoria. Una volta note le risorse finanziarie disponibili, è poi in
grado di stabilire quali sono i progetti finanziabili e quali sono i proget-
ti che, pur rientrando nell’elenco dei progetti ammessi, non risultano
finanziabili. Lo stato delle pratiche viene, di conseguenza, modificato
in automatico dal Sistema Informativo in base all’elaborazione svolta.
7.4.4 Gestione progetti

Questo modulo contiene tutte le funzioni che permettono agli
enti proponenti e ai funzionari di gestione di effettuare via web tutte le
operazioni previste per l’avanzamento delle pratiche relative ai progetti
presentati.
I principali momenti dell’iter sono: la fase di avvio delle attività,
la certificazione intermedia delle spese, il rilascio dei certificati/attesta-
ti regionali, la conclusione delle attività e la certificazione finale delle
spese.
7.4.4.1 Avvio dei progetti

L’Ente Gestore compila , attraverso MonitorWEB, la scheda di
Avvio del progetto e le schede allievi comunicando i dati aggiorna-
ti relativamente alla tempistica dell’attività ed ai suoi partecipanti. In
questa fase, l’Ente Gestore indica anche i dati del Revisore Contabile
del progetto (vedi paragrafo dedicato alla certificazione della spesa).
Il Revisore ha il ruolo di controllore delle certificazioni intermedie e
finali relative al progetto.
Al termine della compilazione dei dati di avvio, l’Ente Gestore
produce la documentazione cartacea utile per completare l’operazione.
Alla ricezione dell’a comunicazione cartacea di avvio, il funziona-
rio incaricato ha la possibilità di visualizzare/modificare i dati relativi al
numero di allievi, alla durata del progetto e alle date aggiornate di avvio e
conclusione nelle sezioni relative ai dati fisici e procedurali. Ha, inoltre,
la possibilità di accedere ai dati delle anagrafiche allievi, verificandone la
congruenza con le caratteristiche dei destinatari previste dal progetto.
Ha, infine, accesso alla funzione utile a segnalare la pagabilità del pri-
mo acconto all’Ufficio preposto ai pagamenti.

7.4.4.2 Chiusura dei progetti
Una volta terminate le attività previste dal progetto, l’ente ge-
store procede con le pratiche utili alla comunicazione di fine attività,
comunicando le informazioni definitive relative alla tempistica (date di
avvio e conclusione) e al numero di partecipanti che hanno raggiunto
i requisiti formativi e sono, quindi, rendicontabili. Una volta effettuata
l’operazione di chiusura formale del progetto sul Sistema Informativo,
l’ente può procedere con la certificazione finale delle spese.
7.4.4.3 Certificazione periodica delle spese

La certificazione delle spese del progetto è demandata all’ente
gestore che, al momento dell’avvio del progetto, sceglie e comunica
alla Regione un revisore contabile che ha il ruolo di controllore sulle
operazioni contabili svolte dall’ente. I giustificativi cartacei di spesa
non vengono, quindi, consegnati e controllati da un apposito ufficio
Regionale, ma i dati ad essi relativi vengono inseriti nel Sistema Infor-
mativo e tenuti agli atti dagli enti gestori. Dopo l’avvio del progetto,
quindi, l’Ente Gestore ha accesso all’inserimento dei giustificativi di
spesa nel Sistema Informativo e, a scadenze stabilite, alla stampa del-
la documentazione cartacea riassuntiva da consegnare in Regione per
completare l’operazione di certificazione periodica della spesa. Conte-
stualmente alla documentazione cartacea perviene alla Regione anche
una relazione cartacea a cura del Revisore Contabile.
Una volta pervenuta la documentazione relativa alla certificazio-
ne intermedia, il funzionario incaricato può accedere alla sezione del
progetto dedicata alle certificazioni e verificare la congruenza dei dati
con la relazione presentata dal Revisore Contabile. Una volta effettuate
le verifiche può, attraverso la maschera confermare o meno l’importo
trasmesso e, sempre attraverso il Sistema Informativo, indicare la pa-
gabilità del progetto agli Uffici preposti.
7.4.4.4 Rilascio dei certificati/attestati regionali

Lo scopo generale della procedura è quello di snellire il proces-
so di rilascio dei certificati/attestati, demandando all’Ente Gestore di
progetti di formazione la stampa dei certificati stessi e della documen-
tazione utile al rilascio e gestendo, attraverso il Sistema Informativo
MonitorWEB, le fasi di richiesta da parte dell’Ente Gestore e di au-
torizzazione alla stampa da parte delle strutture regionali competenti.
Tali strutture sono:

Le tipologie di certificato/attestato regionale attualmente rilascia-
te sono le seguenti:
1)Certificato di frequenza
2)Certificato di frequenza e profitto
3)Attestato di qualifica professionale
4)Attestato di qualifica post-diploma
5)Attestato di specializzazione professionale
6)Attestato di specializzazione post-diploma
Il certificato di cui al punto ) non prevede prova finale ma viene
rilasciato solo in base al raggiungimento di una percentuale minima
di frequenza da parte del partecipante che, solitamente, è pari al %.
I certificati/attesti di cui al punto ), ), ) e ) prevedono una prova
d’esame con una commissione che, nel caso dei certificati di cui al pun-
to ) è composta da un funzionario regionale come presidente e da do-
centi interni all’ente come membri, mentre, nel caso degli attestati di
cui ai punti ), ) ) e ) è a composizione completamente regionale.
Il Sistema Informativo permette di gestire in modalità on-line
le comunicazioni tra gli enti gestori e i funzionari di riferimento fina-
lizzate alla convocazione della commissione d’esame e alla successiva
autorizzazione della stampa dei certificati/attestati da parte degli enti.
Una volta stampati, i certificati/attestati vengono trasmessi alla
Regione per la vidimazione finale. Al termine del processo i funzionari
incaricati indicano nel Sistema Informativo l’avvenuto rilascio.
7.4.5 Gestione delle visite ispettive

Un ulteriore modulo previsto all’interno del Sistema Informativo
MonitorWEB è quello atto a supportare l’attività ispettiva di primo
livello, intesa come l’insieme delle attività effettuate dall’amministra-
zione nei confronti dei beneficiari e finalizzate alla verifica del rispetto
da parte di questi ultimi della normativa e dei fini connessi ai finanzia-
menti ottenuti. I controlli di primo livello si differenziano da quelli di
secondo livello che rappresentano, invece, una sorta di audit interno
all’amministrazione teso alla verifica dell’adeguatezza del sistema atti-
vato, in modo da evidenziarne eventuali rischi di inadeguatezza, rischi
che potrebbero condurre al mancato raggiungimento degli obiettivi
collegati ai fondi comunitari.
I controlli di primo livello trovano la propria fondamentale espli-
cazione attraverso una serie di meccanismi di sorveglianza della spesa

connessi al monitoraggio di indicatori fisici e finanziari e vedono un
contatto diretto con i beneficiari dei cofinanziamenti attraverso il siste-
ma dei controlli effettuati ex ante, in itinere ed ex post.
Essi si attuano prevalentemente attraverso delle visite ispettive
richieste da apposita Struttura Regionale incaricata e espletate a cura
dei membri di un Nucleo Ispettivo, che possono essere funzionari re-
gionali o membri interinali di supporto all’attività. I controlli possono
essere svolti a campione oppure in seguito a segnalazioni puntuali su
determinati progetti e enti gestori.
Il Sistema Informativo propone un potente motore di ricerca che
permette di selezionare un set di progetti a campione imponendo dei
criteri di selezione su informazioni significative del progetto quali i
dati finanziari, l’ambito territoriale e i destinatari. Su uno o più proget-
ti selezionati è, quindi. Possibile, aprire una pratica on-line e inserire
nella cartella virtuale i vari eventi significativi avvenuti nel corso del-
l’indagine (visite, richieste all’ente di documentazione supplementa-
re/chiarimenti, segnalazione di anomali verso altri uffici regionali etc.),
indicandone l’esito e le eventuali irregolarità riscontrate.
Una articolata reportistica permette, quindi, di monitorare at-
traverso il Sistema Informativo l’intera attività ispettiva, effettuando
anche indagini statistiche sulla tipologia di irregolarità più o meno fre-
quenti.
7.4.6 Porte applicative

Particolare attenzione è da dedicare al modulo che permette di
alimentare la banca dati di Monitorweb da parte di sistemi informativi
esterni, sfruttando il protocollo SOAP. SOAP è un protocollo applica-
tivo e consiste in una serie di regole che permettono ad applicazioni
distribuite di scambiarsi informazioni; fornisce un modo consistente e
strutturato di trasporto dei dati e di chiamata dei metodi fra le poten-
ziali applicazioni distribuite.
Il pacchetto di informazioni scambiate prende il nome di payload
ed è una struttura dati, anche complessa, descritta utilizzando XML. Il
protocollo di trasporto non è predefinito ma si privilegia http per la sua
ampia distribuzione e perché permette di utilizzare le caratteristiche di
richiesta/risposta che sono tipiche di SOAP.
In particolare è possibile mettere in comunicazione con Moni-
torweb sistemi informativi che producono un flusso di informazioni e
di dati relativi a:

• anagrafiche degli allievi
• giustificativi di spesa
Visto l’ingente volume di dati, infatti, l’inserimento on-line di
queste informazioni è molto oneroso. Inoltre occorre considerare che
esse sono già, di fatto, presenti nei sistemi informativi utilizzati inter-
namente dagli enti gestori.
Il modulo permette, quindi, una volta sviluppate le procedure
client da parte degli enti gestori, un travaso diretto dei dati dai loro
sistemi informativi al Sistema Informativo Regionale MonitorWEB
7.4.7 Architettura
Lo schema fisico dell’architettura hardware utilizzata può essere
rappresentato come in figura:

8 Il Protocollo Informatico della Regione Lombardia
Un prerequisito fondamentale per introdurre l’utilizzo della fir-

ma digitale nelle attività di gestione del FSE è rappresentato dalla pre-
senza di un Sistema di Protocollo Informatico, in grado di recepire in
modo automatico documentazione pervenuta in modalità elettronica
oltre che cartacea e di effettuare verifiche di congruità e di validità sui
documenti firmati in ingresso.
Esigenze simili a quelle di MonitorWEB sono emerse, negli ulti-
mi tempi, da parte di diversi Sistemi Informativi interni alla Regione
il ché ha portato Lombardia Informatica, responsabile del Sistema Pro-
tocollo, alla progettazione di un servizio di comunicazione “privilegiato”
fra tali Sistemi (detti anche Portali Verticali) e il Sistema Protocollo
Regionale. Le caratteristiche del servizio prevedono l’automazione del-
l’attività di protocollazione, garantendo, al Sistema che effettua la ri-
chiesta, un feed-back relativo all’esito dell’operazione, comprensivo dei
dati di protocollo assegnati, nel caso di esito positivo.
La soluzione tecnologica proposta da Lombardia Informatica,
nel rispetto della attuale architettura del Protocollo informatico della
Regione Lombardia e dei conseguenti vincoli tecnologici che essa im-
pone, prevede una soluzione di interoperabilità basata:
• sulla Posta Elettronica Certificata, per la trasmissione dei docu-
menti al Protocollo Regionale
• sull’impiego della Firma digitale, per la validazione dei docu-
menti scambiati
Su questi presupposti, Lombardia Informatica ha realizzato
un’interfaccia tra il Sistema di Posta Certificata e il Sistema di Proto-
collo che permetta ai Portali Verticali la trasmissione delle richieste e
la verifica dell’esito dell’operazione con il recupero delle informazioni
di protocollo.
Lo schema dell’architettura è il seguente:

Nel seguito, viene esplicitata con maggiore dettaglio la soluzione
adottata. Una trattazione ancora più completa sui requirements fun-
zionali relativi all’interoperabilità fra Sistema di Protocollo e Portali
verticali e sulla definizione delle interfacce dei servizi da realizzare a
cura dei Portali stessi, è contenuta nei documenti relativi al Protocollo
citati nel Capitolo: Documenti di riferimento.
E’ da considerare che l’attivazione della casella di Posta Elettroni-
ca Certificata e il suo collegamento con il Protocollo sono attualmente
in fase di sperimentazione così come l’introduzione della gestione della
Firma Digitale in MonitorWEB.
Questo argomento porta e considerare di limitare, almeno in una
prima fase, la mole di documenti elettronici da gestire.
8.1 La Posta Elettronica Certificata e il Protocollo Regionale

Per la ricezione di documenti in formato elettronico, è stata at-
tivata dalla Regione Lombardia una casella di Posta Elettronica Certi-
ficata (PEC). Le caratteristiche di questo strumento di comunicazione
sicura e degli aspetti legislativi che ne supportano l’adozione per la P.A.
sono stati ampiamente trattati nella Parte I del documento.
Per automatizzare il processo di protocollazione, Lombardia In-
formatica ha realizzato l’interfaccia PEC/PLF tra il Sistema di Posta
Elettronica Certificata e il Sistema di Protocollo Federato e ha definito
le specifiche per la trasmissione di documenti.

Al fine di stabilire un canale “sicuro” di comunicazione telemati-
ca tra il portale e l’interfaccia PEC-PLF viene richiesto che il portale
• sia un Portale Accreditato, ossia un Sistema con un suo codice
identificativo noto all’interfaccia PEC/PLF
• utilizzi una casella di posta elettronica ubicata sul mail server
della Regione Lombardia.
Per la trasmissione di documentazione elettronica al protocollo,
il Portale Verticale Accreditato, deve effettuare le seguenti operazioni:
• predisporre la richiesta secondo le specifiche fornite da Lom-
bardia Informatica. In breve la richiesta consiste in un mes-
saggio e-mail con uno o più documenti allegati (di cui uno
principale, firmato) e con un ulteriore allegato in formato
XML contenente, opportunamente formattate, le specifiche
della trasmissione (Mittente, Destinatario, Oggetto, Nome dei
Documenti ivi contenuti etc.)
• trasmettere il messaggio così composto alla casella di Posta
Certificata
• verificare l’esito dell’operazione
A tal fine, l’interfaccia PEC-PLF mette a disposizione i seguenti
servizi:
• gestione dei Portali accreditati
• richiesta di Protocollazione
• riscontro della Richiesta
e definisce le regole di protocollazione adottate nel sistema infor-
matico.
8.2 Gestione della Firma Digitale da parte del Sistema Proto

collo Regionale
Le specifiche del Protocollo Informatico della Regione Lombar-
dia stabiliscono che, il messaggio e-mail di richiesta debba contenere:
• un documento primario in formato PDF firmato (con firma
forte o debole se accreditata dalla Regione (es. CRS))
• N documenti allegati, in uno dei formati stabiliti dalla Regio-
ne, firmati o no
Sui documenti firmati viene effettuata la verifica che la firma sia
integra ed il certificato non sia scaduto. In caso contrario, il messaggio
viene scartato, con notifica al mittente.

Tra i casi di normale protocollazione meritano una particolare
attenzione i casi di protocollazione di e-mail, provenienti da sistemi di
posta non certificata, contenenti solo testo e/o in allegato documenti
informatici non firmati o firmati con un certificato di firma rilascia-
to da una “CA non accreditatata”. In tali casi il Protocollista effettua
una normale protocollazione evidenziando in un apposito campo del
Protocollo le caratteristiche formali dell’e-mail (solo testo, allegati non
firmati, CA non accreditata, etc).

9 Introduzione della Firma Digitale nella
Gestione FSE
9.1 L’approccio metodologico

L’analisi del contesto sviluppata nei precedenti capitoli, mette
in evidenza che si sono venuti a creare, negli ultimi anni, i requisi-
ti per l’introduzione della firma digitale all’interno delle procedure di
gestione del POR FSE - Obiettivo 3; ciò, in particolare, per
quanto riguarda l’autenticazione della documentazione trasmessa dagli
operatori di formazione alla Regione durante l’iter procedurale delle
pratiche relative a domande di finanziamento di progetti FSE o di ac-
creditamento di sedi operative.
In particolare, le condizioni che evidenziano che i tempi siano
maturi per compiere questo passo sono i seguenti:
• l’introduzione di MonitorWEB ha permesso di consolidare un
canale di comunicazione on-line “Operatori di Formazione Re-
gione Lombardia” mettendo a disposizione funzionalità per un
accesso sicuro e per l’inserimento delle informazioni inerenti
l’operatore e i progetti di formazione. Attualmente la trasmis-
sione delle informazioni viene completata dalla trasmissione di
documentazione cartacea, firmata con firma autografa, conte-
nente una sintesi dei dati maggiormente sensibili (dati econo-
mici, dati identificativi dell’ente).
• l’esigenza di informatizzare la trasmissione di documentazione,
da parte dei Sistemi Informativi interni alla Regione Lombar-
dia, ha accelerato la messa a punto delle procedure di ricezione
di documentazione firmata con firma digitale da parte del Pro-
tocollo.
Il prossimo passo consiste, quindi, nello studio delle modalità
di introduzione della firma digitale nelle procedure di gestione FSE,
tenendo conto delle caratteristiche dei documenti oggetto di scambio
e dell’attuale supporto informatico alle procedure stesse.
L’approccio metodologico del Progetto Firm@ prevede i seguenti
passaggi:
1. analisi della documentazione cartacea attualmente oggetto di
scambio

analisi delle diverse tipologie di documento al fine di
ricondurla ad alcune categorie standard. I criteri di aggregazio
ne sono, ad esempio:
- la fase procedurale della domanda in cui è richiesta all’opera
tore la presentazione del documento
- il soggetto che appone la firma (rappresentante legale, altro
soggetto)
- se il documento è o meno generato a partire dalle informazio-
ni inserite nel sistema informativo MonitorWEB
2. estrapolazione di ogni singola procedura interessata dall’introdu-
zione della firma digitale:
individuazione dei momenti del flusso procedurale in cui av-
viene la trasmissione della documentazione di cui sopra e che
vengono, quindi, modificati con l’introduzione della firma
digitale
3. considerazioni sull’attuale supporto informatico alla procedu-
ra da parte di MonitorWEB
verifica dell’esistenza o meno di un flusso procedurale già in-
formatizzato su cui implementare le procedure di gestione del-
la firma digitale
4. studio e realizzazione di soluzioni standardizzare dal punto di
vista tecnologico, procedurale e organizzativo per l’introduzione
delle firma digitale, al fine di soddisfare le esigenze attuali e
quelle che si potranno presentare in futuro.
9.2 Documenti trattati nell’ambito del Progetto Firm@

L’espressione Documenti trasmessi dall’operatore alla Regione,
comprende, di fatto, l’insieme delle informazioni utili ai fini dell’otte-
nimento del finanziamento/accreditamento. In particolare si tratta di
documenti:
• utili a garantire la Regione dal punto di vista legale e finanzia-
rio (quali, ad esempio, la garanzia fidejussoria rilasciata dal-
l’Istituto di Credito dell’operatore a copertura del progetto in
caso di revoca oppure gli obblighi del gestore con cui l’opera-
tore si impegna al corretto svolgimento delle attività relative al
progetto presentato)
• utili a comunicare alla Regione le informazioni di dettaglio re-
lative all’ente, ai progetti di formazione e alle sedi utilizzate

Abbiamo già sottolineato in precedenza che tali documenti si di-
stinguono attualmente in:
1. documenti elettronici comprendenti dati inseriti nel Sistema
Informativo dopo procedura di accesso
2. documenti, firmati o meno con firma autografa, trasmessi in
modalità cartacea alla Regione
Alla prima categoria, appartengono, ad esempio le schede conte-
nenti i dati dei progetti, compilate via WEB attraverso il Sistema Infor-
mativo nella fase di presentazione, dopo aver effettuato l’accesso con i
propri dati riservati. Per quanto riguarda queste informazioni, il Pro-
getto Firm@ non introduce alcun cambiamento rispetto alla situazione
attuale.
Per quanto riguarda la seconda categoria, Il Progetto Firm@ si
focalizza sulla documentazione cartacea trasmessa dagli Operatori di
formazione alla Regione durante l’iter delle domande di finanziamento
di progetti FSE. Verranno, quindi, nel seguito esaminati solo i docu-
menti di questa sotto-categoria ed esaminate le fasi procedurali del
progetto in cui tali documenti vengono trasmessi. Viene rimandata ad
un momento successivo l’analisi di altri documenti; per esempio, quelli
relativi alle domande di accreditamento di sedi operative.
Punto di partenza è, quindi, l’elenco riportato al capitolo 2.3 del
presente documento, in cui vengono riassunti i documenti che costi-
tuiscono un fascicolo di progetto.
Essi sono classificabili, in base all’origine, nel modo seguente (è
riportata tra parentesi l’abbreviazione con cui vengono indicati nel se-
guito):
• documenti prodotti in automatico dal Sistema Informativo
MonitorWEB (prodotto MonitorWEB)
• documenti di cui il prototipo, da compilare e trasmettere a
cura dell’Operatore, è presente su MonitorWEB (prototipo
MonitorWEB)
• documenti di cui il fac-simile, da utilizzare e trasmettere a
cura dell’Operatore, è presente su MonitorWEB (fac-simile
MonitorWEB)
• documenti provenienti da altra fonte diversa da MonitorWEB
(altra origine)

in base alla firma apposta nel modo seguente (è riportata tra pa-
rentesi l’abbreviazione con cui vengono indicati nel seguito):
• documenti firmati dal rappresentante legale, o dal soggetto
col potere di firma (rappresentante legale)
• documenti firmati da soggetto diverso dal rappresentante lega-
le e dal soggetto col potere di firma (altro soggetto)
e in base alla fase di avanzamento del progetto:
• documenti trasmessi alla presentazione
• documenti trasmessi all’avvio
• documenti di notifica variazione trasmessi in itinere
• documenti trasmessi alla certificazione intermedia e finale
• documenti trasmessi a fine attività
• documenti trasmessi in fase di ispezione
La tabella seguente riassume le considerazione precedenti. I do-
cumenti cartacei che costituiscono un fascicolo progetto sono raggrup-
pati per fase di avanzamento e, per ognuno di essi, viene indicato il
soggetto firmatario e l’origine del documento.
Presentazione Firma Origine

Domanda di contributo sottoscritta dal: prodotto Moni-
rappr. legale
legale rappresentante (o soggetto analogo) torWEB
Copia della carta d’identità del soggetto che sottoscrive
rappr. legale altra origine
la domanda di contributo
Atto costitutivo o statuto oppure riferimento alla pratica
dove è archiviato
Certificato di iscrizione alla C.C.I.A. o depositato c/o rappr. legale altra origine
Modifiche statutarie rappr. legale altra origine
Domanda riesame valutazione rappr. legale altra origine
Lettera di intenti ATS / accordo di partnership rappr. legale altra origine
Dichiarazione di conformità alle priorità provinciali rappr. legale altra origine
Dichiarazione di intenti di aziende interessate agli stage rappr. legale altra origine
Business Plan rappr. legale altra origine
Notifica delle variazioni
Variazione del Legale Rappresentante rappr. legale altra origine
Allegato verbale di assemblea straordinaria
o altro documento attestante la variazione
Richiesta di modifica motivata del nominativo
del revisore contabile
Richiesta di variazione della sede di svolgimento
del corso

Allegata autocertificazione idoneità strutture rappr. legale altra origine
Variazione elenco allievi rappr. legale altra origine
Richiesta di deroghe rappr. legale altra origine
Avvio
rappr. legale prototipo
Atto di adesione firmato
MWEB
Comunicazione avvio sottoscritta dal legale prototipo
rappr. legale
rappresentante contenente: MWEB
Obblighi del gestore
MWEB
altro sogget- prototipo
to (allievi, MWEB
Elenco allievi con firme autografe
rappresentante
legale)
altro soggetto prototipo
Costituzione ATS
MWEB
altro soggetto Fac-simile
Calendario di massima (direttore del MWEB
corso)
altro soggetto prototipo
(funzionario MWEB
Garanzia fidejussoria (se richiesta)
Istituto di
Credito)
Registro didattico (direttore del MWEB
corso)
(direttore del MWEB
Registro stage
corso e respon-
sabile azienda)
Piano di attività
Certificazione antimafia (se richiesta)
MWEB
Stato avanzamento lavori (per azioni di sistema
e sovvenzioni globali)
Certificazioni contabile della spesa
rappr. legale prodotto Moni-
Piano dei conti Fondo Sociale Europeo
torWEB
Autocertificazione - intermedia prodotto Moni-
rappr. legale
(firmata dal legale rappresentante) torWEB
Autocertificazione - finale prodotto Moni-
rappr. legale
(firmata dal legale rappresentante) torWEB
Relazione di certificazione intermedia della spesa altro soggetto altra origine
(firmata dal revisore) (revisore)
Relazione di certificazione finale della spesa altro soggetto altra origine
(firmata dal revisore) (revisore)

Richieste di ulteriori acconti rappr. legale
Chiusura edizioni
altro soggetto prodotto Moni-
Modello F1 (direttore del torWEB
corso)
Richiesta di commissione d’esami
torWEB
altro soggetto prodotto Moni-
(direttore del torWEB
Verbale e prove di accertamento finale.
corso, presi-
dente)
Fine Attività
Comunicazione fine attività progetto
torWEB
Relazione finale rappr. legale altra origine
Verifiche ispettive
Documentazione richiesta all’ente rappr. legale altra origine
Nel seguito vengono riportati i documenti appartenenti ai diversi

incroci Origine/Firma.

Origine/firma Rappresentante legale Altro soggetto
Domanda di contributo
Comunicazione avvio
Elenco allievi
Piano dei conti Fondo Sociale Europeo
Prodotto Modello F1
Autocertificazione - intermedia
MonitorWEB Verbale e prove
Autocertificazione - finale
di accertamento finale
Richieste di ulteriori acconti
Comunicazione fine attività progetto
Atto di adesione firmato
Obblighi del gestore
Prototipo
Certificazione antimafia Costituzione ATS
MonitorWEB
Richiesta di commissione d’esami
Garanzia fidejussoria
Calendario di massima
Fac-simile
Registro didattico
MonitorWEB
Registro stage
Copia della carta d’identità
Atto costitutivo o statuto
Certificato di iscrizione alla C.C.I.A
Modifiche statutarie
Domanda riesame valutazione
Lettera di intenti ATS
Lettera di sostegno delle parti sociali
Dichiarazione conformità priorità
provinciali Relazione di certificazione
Dichiarazione di intenti per stage intermedia della spesa
Altra Origine Business Plan Relazione di certificazione
Variazione del Legale Rappresentante finale della spesa
Richiesta di modifica revisore contabile
Richiesta di variazione della sede
Richiesta di deroghe
Variazione elenco allievi
Piano di attività
Variazioni Elenco allievi
Stato avanzamento lavori
Documentazione richiesta in visite
ispettive

9.3 Le procedure interessate dal Progetto Firm@
Nel Manuale delle Procedure FSE è riportato il seguente schema
che traduce il flusso informativo del ciclo di vita di un progetto FSE:

Concentrando l’attenzione sulla documentazione scambiata tra
operatori e Regione, è possibile semplificare ulteriormente il flusso e
schematizzarlo nel modo seguente:
1) Presentazione Progetto
➞
2) Avvio
➞
3) Certificazione intermedia delle spese
➞
Chiusura delle edizioni formative e rilascio dei certificati/attestati regionali
➞
4) Chiusura del progetto

➞
5) Certificazione finale
In tutte le procedure citate è prevista, da parte dell’ente Gestore,

la trasmissione di documentazione firmata da parte del rappresentante
legale dell’Ente, da un soggetto con delega di firma o da altri soggetti
esterni all’Ente.
Le procedure , , ,  e , relativamente rispettive alla Presentazione,
all’Avvio, alla Certificazione intermedia, alla Conclusione e alla Certifica-
zione finale si presentano estremamente omogenee per quanto riguarda
le funzioni da espletare a cura dell’Ente e del Funzionario per portare a
completamento il particolare passo dell’iter. Un elemento importante
di diversificazione tra le diverse fasi, invece, è la composizione degli al-
legati previsti. Oltre ad essere documenti fisicamente differenti, hanno
anche una diversa competenza per quello che riguarda la firma.
In fase di certificazione, per esempio, perviene al funzionario di

gestione la relazione trimestrale inviata dal revisore contabile e non dal
rappresentante legale o dal soggetto con potere di firma del progetto.
In altri casi possono entrare in gioco altri soggetti esterni all’ente, quali,
ad esempio, il funzionario dell’istituto di credito che rilascia la garanzia
fidejussoria.
Un discorso a parte merita il passo relativo alla Chiusura delle
edizioni al fine del rilascio dei certificati. Questo è un processo più
articolato, differente a seconda della certificazione rilasciata prevista
(certificato di frequenza, frequenza e profitto, attestato di qualifica o
specializzazione) e che coinvolge, oltre ai funzionari di gestione, l’Uf-
ficio preposto alla nomina delle commissioni d’esame e al rilascio degli
attestati. La procedura prevede anche uno scambio di documentazione
interna alla Regione che richiede un supplemento di analisi. Al mo-
mento, il processo di gestione delle commissioni d’esame non è gestito
attraverso MonitorWEB ma ne è prevista a breve l’integrazione e si ri-
tiene opportuno rimandare a quel momento l’analisi complessiva della
procedura con l’introduzione della Firma Digitale.
Tornando alle procedure , , ,  e  sottolineiamo nuovamente
che esse possono essere ricondotte ad una procedura tipo, che prevede
sostanzialmente i seguenti passaggi, suddivisi tra quelli effettuati dal-
l’operatore e quelli effettuati a cura della Regione, in particolare dal-
l’Ufficio Protocollo e dai funzionari regionali di riferimento:
Passaggi effettuati a cura dell’operatore:

1. compilazione delle informazioni relative ai progetti, attraverso
le funzionalità offerte dal sistema informativo
2. operazione di conferma e conseguente congelamento delle in
formazioni
3. preparazione della documentazione cartacea generata in modo
automatico dal Sistema a partire dai dati inseriti
4. completamento del fascicolo con documentazione compilata
dall’operatore in modalità off line rispetto al Sistema Informativo
5. trasmissione del fascicolo al Protocollo Regionale
Passaggi effettuati a cura della Regione

1. protocollazione dei documenti pervenuti
2. trasmissione ai funzionari regionali incaricati
3. verifica della documentazione pervenuta a cura dei funzionari

9.4 Attuale supporto informatico alle procedure individuate
MonitorWEB offre attualmente ampie funzionalità per la ge-
stione del flusso informativo relativo alle procedure sopra individuate,
in particolare per quanto riguarda l’introduzione delle informazioni
all’interno del Sistema Informativo. Con l’introduzione della Firma
Digitale si aggiungono a tali funzionalità quelle rivolte alla predisposi-
zione della documentazione elettronica.
Nel seguito vengono descritte le attuali aree dedicate agli opera-
tori di formazione e ai funzionari regionali preposti alla gestione e le
modifiche apportate con l’introduzione della Firma Digitale.
9.4.1 Area rivolta agli operatori di formazione

L’area riservata agli operatori permette la navigazione sui progetti
suddivisi per fase di avanzamento, come illustrato nelle figure seguenti
che riportano le pagine di ingresso ai progetti in fase di presentazione
e, una volta finanziati, di gestione.
Area Operatori: Fase di Presentazione

Area Operatori: Fase di gestione
I link in corrispondenza delle diverse fasi (Avvio, Certificazione,

Rendicontazione e Conclusione) permettono di effettuare, per ogni
singolo progetto, le seguenti operazioni:
• l’inserimento sul database delle informazioni da comunicare
da parte dell’operatore nelle diverse fasi
• la conferma dei dati, operazione che rende definitive e im-
modificabili le informazioni immesse
• la produzione di report sulla base delle informazioni inserite,
da firmare e consegnare cartacei al protocollo
• l’accesso ai prototipi/fac-simili della documentazione aggiun-
tiva, prevista nelle diverse fasi
Per quanto riguarda gli ulteriori allegati che compongono il
fascicolo di documenti da produrre, ricordiamo, a titolo esemplifica-
tivo, che, nella fase di avvio, viene reso disponibile in MonitorWEB il
cosiddetto kit di avvio ossia l’insieme dei documenti utili, da scari-
care, compilare e trasmettere. Il kit di avvio cambia a seconda del
bando.
Come meglio esemplificato in seguito, col Progetto Firm@, la
gestione del fascicolo si integra maggiormente con le funzionalità di

inserimento e conferma dei dati. Una volta terminato l’inserimento
dei dati nel database, l’operatore procede con l’upload sul sistema
informativo dei documenti da trasmettere e attiva le funzionalità di
trasmissione al protocollo informatico.
E’ qui riportato un esempio di kit di avvio attualmente disponi-
bile su MonitorWEB.
Area Operatori: Kit di avvio
9.4.2 Area rivolta ai funzionari regionali

L’area rivolta ai funzionari regionali prevede attualmente la
possibilità, per ogni singolo funzionario, di accedere alla gestione
dei progetti, appartenenti ai bandi di propria competenza, attraverso
una maschera di ricerca che permette di impostare criteri di selezione
quali:
- IdProgetto
- IdBando
- IdOperatore
- Stato
- IdAzione

Area Regione: Fase di gestione da parte dei funzionari
Una volta ricercato il/i progetti, è possibile accedere:

• alle informazioni inserite nel database
• ai report prodotti automaticamente dal Sistema
Il collegamento con la documentazione pervenuta cartacea si può
effettuare solo accedendo all’archivio cartaceo per il codice identificati-
vo (IdProgetto) del progetto in esame. Con l’introduzione della firma
digitale il funzionario ha accesso ai documenti pervenuti in modalità
elettronica direttamente da MonitorWEB.
9.5 Modifiche apportate al Sistema Informativo con l’intro

duzione della Firma Digitale
9.5.1 Descrizione delle procedure prima dell’introduzione della Firma
Digitale
Le funzionalità offerte dal sistema informativo MonitorWEB a
supporto dell’attività degli operatori e dei funzionari nelle procedurece
,,, e  descritte nel paragrafo ., si possono riassumere nel modo
seguente:

9.5.1.1 Area rivolta agli operatori di formazione
1. compilazione delle informazioni relative ai progetti
l’operatore accede al sistema MonitorWEB e, quindi, all’am-
biente funzionale dedicato alla specifica fase di avanzamento
del progetto. Attraverso apposite form elettroniche compila le
informazioni significative per quella fase
2. operazione di conferma e conseguente congelamento delle infor-
mazioni
l’operatore conferma i dati inseriti determinando l’avanzamen-
to di stato del progetto e il congelamento delle informazioni
inserite. Questa operazione abilita la possibilità di stampa dei
report da trasmettere cartacei alla Regione.
l’operatore stampa su carta i report prodotti dal Sistema e il
soggetto incaricato vi appone la firma.
4. completamento del fascicolo con documentazione compilata dal
l’operatore in modalità off line rispetto al Sistema Informativo
l’operatore allega alla documentazione prodotta gli altri
allegati previsti, il cui prototipo/fac-simile può essere o meno
disponibile sul sito.
5. trasmissione del fascicolo al Protocollo Regionale
l’operatore porta/spedisce la documentazione al protocollo
regionale.
9.5.1.2 Area rivolta ai funzionari regionali

1. ricezione della documentazione da parte del protocollo
il protocollo effettua la ricezione. Rilascia all’operatore la
data di arrivo al protocollo, che fa testo per quanto riguarda
i termini di scadenza e, in un momento successivo, effettua la
protocollazione rilasciando data e numero di protocollo. Viene
assegnatlo un unico numero di protocollo al documento prin-
cipale e a tutti i suoi allegati
2. smistamento della comunicazione al funzionario incaricato della
gestione
in base alla competenza (es. tipo di bando) la documentazione
viene smistata al funzionario di riferimento

3. verifica formale e di contenuto da parte del funzionario di gestione
Il funzionario effettua il controllo formale della documenta-
zione richiedendo eventualmente all’operatore documentazio-
ne integrativa
9.5.2 Descrizione delle procedure dopo l’introduzione della Firma Digitale

Con l’introduzione della Firma Digitale, il processo si articola nel
modo seguente:
9.5.2.1 Area rivolta agli operatori di formazione

1. compilazione delle informazioni relative ai progettiresta inalterato
2. operazione di conferma e conseguente congelamento delle informa
zioni resta inalterato
una volta terminato l’inserimento a Sistema dei dati relativi
ad una singola procedura (Presentazione, Avvio etc.), l’ope-
ratore che desidera servirsi della firma digitale accede ad una
nuova sezione, dedicata alla trasmissione dei documenti, in cui
ha a disposizione le funzioni per la produzione, il recupero
(download) e il successivo caricamento (upload) dei documenti
sulla macchina server del Sistema Informativo MonitorWEB.
L’operatore effettua il download sul proprio Computer
dei documenti prodotti automaticamente dal Sistema, li fir-
ma col. proprio client di firma e ne rieffettua il caricamento
(upload) sul Sistema. Al momento del caricamento, Moni-
torWEB effettua i necessari controlli di coerenza
4. completamento del fascicolo con documentazione compilata dal
l’operatore in modalità off line rispetto al Sistema Informativo
all’interno della sezione sono disponibili le funzioni di
download dei documenti che hanno il prototipo o il fac-si-
mile presente sul sistema. L’utente li può scaricare sul proprio
client, completare e effettuarne l’upload
5. trasmissione della documentazione al protocollo regionale
l’operatore effettua, con apposita funzione messa a disposizio-
ne da MonitorWEB, la trasmissione via e-mail dei documenti
caricati al Protocollo Elettronico, secondo le specifiche ripor-
tate nel capitolo 3.

9.5.2.2 Area rivolta ai funzionari regionali
1. ricezione della documentazione da parte del Protocollo Regionale
l’e-mail pervenuta viene processata dal Sistema di Protocollo
attraverso l’interfaccia realizzata da Lombardia Informatica e,
attraverso una tabella di dati condivisa tra i due sistemi, ven-
gono restituite a MonitorWEB le informazioni relative a data
di arrivo, data e numero di protocollo
2. smistamento della comunicazione al funzionario incaricato della
gestione
il funzionario regionale, in base alle informazioni intrinseche
nel progetto (numero di bando) accede attraverso il sistema ai
documenti di propria competenza caricati tramite upload
3. verifica formale e di contenuto da parte del funzionario di gestione
rimandendo all’interno di MonitorWEB, grazie al proprio di-
spositivo di firma, il funzionario regionale verifica il documen-
to e la firma digitale apposta e valida il documento stesso
9.6 Sintesi della soluzione informatica adottata

Nel seguito viene schematizzata l’architettura hardware della so-
luzione informatica adottata e viene esplicitato il flusso procedurale
complessivo.

9.6.1 Architettura del Sistema

Lo schema evidenzia l’insieme dei sistemi che compongono la
soluzione architetturale e le loro connessioni:
• il Sistema MonitorWEB, costituito da 4 web server in balan
cer che accedono ad un ulteriore server di database
• il Server di Posta della Regione Lombardia, utilizzato per spe-
dire via e-mail al protocollo, a cura di MonitorWEB, i docu-
menti di progetto
• il server di posta con la casella di posta certificata del protocollo
elettronico
• il Sistema di Protocollo che si interfaccia al server di posta cer-
tificata per recepire e archiviare i documenti e restituire l’esito
della protocollazione al Sistema che ha effettuato l’inoltro. Su
questo Sistema, infatti, è presente la tabella di database utiliz-
zata per la restituzione delle informazioni a MonitorWEB

9.6.2 Il flusso procedurale
Lo schema riassume il flusso procedurale descritto nel capitolo

.. evidenziando sia le operazioni effettuate a cura degli operatori che
quelle delegate ai funzionari regionale

10 Modalità di attuazione della sperimentazione
10.1 Individuazione della procedura di test: l’Avvio dei

Progetti
In base all’analisi riportata nel presente documento, si sono indi-
viduate, all’interno dell’iter burocratico dei progetti FSE, diverse fasi
omogenee che comportano scambio di documentazione operatori �
Regione e in cui è, quindi, auspicabile prevedere l’introduzione della
firma digitale.
L’intento del Progetto Firm@, tuttavia, è soprattutto quello di
realizzare una fase di sperimentazione, che permetta di testare le mo-
dalità di trasmissione al protocollo informativo e di far emergere even-
tuali problemi e criticità legati all’uso di questo nuovo strumento di
validazione.
Si è ritenuto preferibile, quindi, concentrare le attenzioni e gli
sforzi su una singola fase, tenendo conto che, una volta emersi e risolti
gli eventuali problemi insorti, l’estensione della sperimentazione alle
altre fasi omogenee non comporta ulteriori incognite.
In particolare, è stato individuato nell’ Avvio dei progetti la fase
più adatta per la sperimentazione. La scelta è dovuta a diversi fattori di
ordine pratico. Per esempio nel periodo di attivazione della sperimen-
tazione sono previsti gli avvii delle attività di progetti attualmente in
valutazione, mentre non è prevista la pubblicazione di nuovi bandi.
L’avvio, inoltre, è solitamente una fase che si svolge, per un certo ban-
do, in un limitato periodo di tempo in cui è previsto che tutti i progetti
finanziati inizino l’attività. Tale periodo, per i bandi di prossima pub-
blicazione, corrisponde, appunto al periodo previsto per la sperimen-
tazione (novembre-dicembre ).
10.2 Supporto informatico alla gestione della Firma Digitale

Segue la descrizione dei moduli software previsti nel Progetto
Firm@ per la gestione documentale, suddivisi nelle 2 aree:
• Area Operatori
• Area Regione
I moduli dell’Area Operatore si suddividono a loro volta in:

• Moduli per la gestione documentale
permettono all’operatore di accedere alle funzioni operative di
propria competenza quali la predisposizione e l’inoltro della
documentazione
• Moduli per la consultazione
permettono all’operatore di accedere ai documenti legati ad
un progetto, organizzati per fascicolo, ossia per fase di avan-
zamento del progetto stesso. I fascicoli attualmente previsti
sono: Presentazione, Avvio, Variazione, Conclusione, Certi-
ficazione.
I moduli dell’Area Regione si suddividono a loro volta in:
• Moduli di interfaccia col Protocollo Elettronico Regionale:
permettono di recepire l’esito della protocollazione dei docu-
menti pervenuti elettronicamente effettuata a cura delle proce-
dure di Protocollazione Regionale e di metterlo a disposizione
degli utenti del Sistema Informativo MonitorWEB
• Moduli per la protocollazione su MonitorWEB della docu
mentazione pervenuta cartacea:
permettono ai funzionari di inserire in MonitorWEB i dati di
protocollo dei documenti pervenuti cartacei
• Moduli per la gestione documentale:
permettono ai funzionari di accedere alla documentazione tra-
smessa dagli operatori, di verificarne la correttezza e di aggior-
narne lo stato di avanzamento per il corretto proseguo dell’iter
della pratica
• Moduli per la consultazione dei documenti:
permettono di accedere ai documenti legati ad un progetto
10.2.1 Area rivolata agli operatori di formazione

10.2.1.1 Moduli per la gestione documentale
L’ambiente di gestione documentale permette all’operatore di
predisporre e trasmettere la documentazione firmata, utile per com-
pletare la fase di Avvio del progetto. L’interfaccia utente è semplice ed
intuitiva, realizzata attraverso la schermata seguente:

Area Operatore: Predisposizione e trasmissione della
documentazione elettronica firmata
10.2.1.1.1 Preparazione della documentazione firmata

L’attività si articola nel modo seguente:
• Dopo aver inserito e confermato nel Sistema Informativo le in-
formazioni richieste per la fase di Avvio, l’operatore ha accesso
alla sezione documentale, sopra riportata, per la predisposizio-
ne della documentazione elettronica da trasmettere al protocol-
lo. Come già anticipato nel capitolo precedente, i documenti
vanno scaricati (download) a cura dell’operatore sul proprio
computer, firmati attraverso il proprio programma client di
firma digitale e caricati (upload) nuovamente sul Sistema. Le
funzioni di download e upload vengono effettuate attraverso le
funzionalità messe a disposizione del Sistema Informativo.
L’elenco dei documenti da caricare e trasmettere viene predi-
sposto in automatico dal Sistema. Alcuni documenti sono obbligatori
per tutti gli operatori, altri solo per alcuni di loro (es.il documento di
costituzione dell’ATS è obbligatorio solo per gli operatori che non si
presentano come attuatori singoli), altri ancora sono facoltativi.
Per ogni documento viene riportato:

o IdDocumento:
codice che individua in modo univoco il documento all’inter-
no di una tabella anagrafica che li comprende tutti
o Descrizione:
descrizione estesa del documento
o Presentazione:
indica se il documento deve essere necessariamente presentato
solo su supporto cartaceo, oppure se sono possibili entrambe
le modalità
o C/E:
indica la modalità di presentazione scelta dall’operatore
o Origine:
indica una delle seguenti tipologie:
documenti prodotti e compilati dal Sistema in modo automa-
tico, a partire dalle informazioni analitiche inserite dall’ope-
ratore. Tali documenti devono essere firmati e ricaricati sul
Sistema
documenti il cui prototipo è disponibile sul sistema per essere
scaricato (download), completato, firmato e caricato firmato
(upload)
documenti non disponibili sul Sistema, da produrre e caricare
(upload) a cura dell’Ente
o Stato
indica lo stato del documento del documento tra uno dei se
guenti:

Idstato Stato
A In attesa di protocollazione
B Da Trasmettere
D Trasmesso cartaceo, da protocollare
G Generato
M Annullato dal funzionario regionale
N Annullato dal protocollo
P Protocollato
S Scartato dal protocollo
T Trasmesso, in attesa di protocollazione
V Valicato
X Non validato
Le funzionalità a disposizione dell’operatore sono le seguenti:

permette di effettuare il download del documento sulla macchina
dell’operatore
permette di effettuare l’upload di un documento locale sulla mac-
china server del Sistema Informativo
selezione della presentazione cartacea
permette di visualizzare il documento
permette di eliminare un documento non ancora trasmesso in
Regione
permette la visualizzazione delle informazioni riassuntive del do-
cumento, in particolare quelle relative alla sua protocollazione
L’operatore effettua, a sua discrezione, il download e l’upload dei
files che ritiene necessario trasmettere per completare la fase di avvio.
Appone la firma, attraverso il proprio software apposito, ai documenti
prima di effettuarne l’upload.
Nel caso in cui il documento preveda la firma, MonitorWEB,
al momento dell’upload, effettua la verifica che l’utente stia caricando
effettivamente un file firmato.
Nel caso in cui il documento sia stato prodotto da MonitorWEB,
inoltre, al momento dell’upload viene verificata la corrispondenza tra il
contenuto del file che si sta caricando con quello generato dal sistema.

10.2.1.1.2 Trasmissione della documentazione firmata
L’attività si articola nel modo seguente:
• l’Ente Gestore, attraverso il link Trasmetti documenti, invia al
Protocollo Elettronico Regionale, la domanda e i relativi alle-
gati elettronici previsti dal dispositivo, secondo le specifiche
fornite da Lombardia Informatica nel documento “Specifiche
tecniche per l’interoperabilità fra Portali verticali e Sistema di
Protocollo”. Il processo di trasmissione dei documenti si artico-
la, di fatto, nelle seguenti microoperazioni:
- Predisposizione dei messaggi e-mail
Per ogni documento da trasmettere, viene predisposto un diverso
messaggio e-mail, così costituito:
1. un documento primario in formato PDF firmato (con firma
forte o debole se accreditata dalla Regione (es. CRS))
2. N documenti allegati (in uno dei formati suggeriti dalla Regione
nel Manuale di Gestione) firmati o no.
3. un file XML compilato utilizzando la DTD “Segnatura.dtd”
(la stessa definita dal CNIPA per lo scambio di informazioni
fra protocolli della PA). Il file XML, di cui si allega un esem-
pio, deve contenere le informazioni utili ad identificare univo-
camente il Portale mittente, il richiedente il finanziamento e la
singola richiesta, in particolare:
• nella sezione <Identificatore> devono essere presenti
le informazioni identificative del Portale e del messaggio:
- <CodiceAmministrazione>, è il codice iden-
tificativo assegnato da Regione Lombardia al
Portale, è composto da 3 caratteri
- <NumeroRegistrazione>, è l’identificativo
della richiesta inviata dal Portale e deve essere
composta dai tre caratteri del CodiceAmmi-
nistrazione, da un numero a 7 cifre(sequenza
nell’anno) e da un numero a 4 cifre(anno), se-
parati dal “trattino”
• nella sezione <Mittente> devono essere contenute le
informazioni relative all’ente o privato che richiede il
finanziamento
• nella sezione <Destinazione> devono essere contenu-

te le informazioni della AOO di Regione Lombardia
destinataria del messaggio (cosi come riportate nel-
l’esempio)
4. l’oggetto composto in accordo alla seguente sintassi:
XXX – NNNNNNN – NNNN – stringa libera
Dove
XXX : Identificativo del Portale
NNNNNNN: numero di sette cifre (progressivo nell’anno di
riferimento)
AAAA: Anno di riferimento di 4 cifre.
Stringa libera: l’oggetto del messaggio componibile autono
mamente dal Portale
Le suddette informazioni devono essere separate da carattere
“-“ (trattino)
- Invio di ogni e-mail al Protocollo Elettronico Regionale
- Aggiornamento dello stato dei documenti in Trasmesso e in
attesa di protocollazione
10.2.1.2 Moduli per la Consultazione

Questo ambiente, attivabile dal link relativo ai Progetti Finanziati
nell’ambiente di Gestione Progetti descritto nel capitolo 4.4.1, per-
mette all’operatore di consultare i documenti relativi ad un progetto.
I documenti sono organizzati in fascicoli al fine di agevolare la ricerca
di uno specifico documento. L’ambiente viene realizzato attraverso le
videate seguenti:

Area Operatore: Consultazione della documentazione
elettronica firmata (1)
Area Operatore: Consultazione della documentazione

elettronica firmata (2)

L’operatore ha la possibilità di effettuare download e visualizzazione
dei documenti già esaminati dal funzionario regionale
10.2.2 Area rivolta ai funzionari regionali

10.2.2.1 Moduli di interfaccia MonitorWEB - Protocollo Elettronico Regionale:
Questi moduli permettono di acquisire all’interno di Moni-
torWEB l’esito della protocollazione elettronica.
Una volta che l’e-mail perviene alla Casella di Posta Certificata,
vengono esaminati i file ad essa allegati (ossia il file XML e il documen-
to eventualmente firmato) e si presenta la seguente casistica:
- l’e-mail viene ricevuta correttamente e in attesa di essere pro-
tocollata
- l’e-mail viene protocollata e vengono assegnati al/ai documen-
to/i in essa contenuti numero e data di protocollo
- il documento viene protocollato con eccezione
Questo caso si verifica quando Il certificato è valido ma non
è di una C.A. oppure il certificato è scaduto. Il personale ad-
detto alla ricezione alimenta, attraverso una maschera prevista
all’interno del Sistema del Protocollo le informazioni relative
all’eccezione che si è verificata. Tale informazione, come me-
glio esplicitato in seguito, viene restituita a MonitorWEB e
resa disponibile ai funzionari. Nel casi in cui il certificato sia
revocato o sospeso viene protocollato regolarmente.
- il documento non viene protocollato. Non vengono protocolla-
te e-mail con documenti firmati ma pervenuti con contenuto
non integro oppure firmati ma con un certificato non valido.
In questo caso (cosiddetto di ripudio) il Sistema del Protocollo
invia all’indirizzo e-mail del mittente un messaggio del tipo: ri-
fiutata email con oggetto: <OGGETTO> dove <OGGETTO>
è l’oggetto dell’e-mail contenente il documento rifiutato.
In modalità batch notturna, apposite procedure a cura di Lom-
bardia Informatica, provvedono ad aggiornare una tabella di Database,
disponibile in sola lettura alle amministrazioni che utilizzano il proto-
collo Elettronico, con lo stato e i dati di protocollazione dei documenti
pervenuti durante il giorno alla casella di posta certificata.
La tabella preposta alla restituzione delle informazioni ha la se-
guente struttura:
- Codice del portale che ha effettuato la richiesta

- Codice della richiesta
- Oggetto della e-mail con cui è pervenuto il documento
- Data e ora di ricezione
- Indirizzo e-mail del mittente
- Indirizzo e-mail del destinatario
- Codice dell’Area Organizzativa Omogenea protocollante
- Numero di Protocollo
- Anno di protocollo
- Data e ora di Protocollo
- Struttura assegnataria
- Assegnatario
- Motivo dell’eventuale scarto
- Stato di riscontro
- Data di creazione
- Data di ultima modifica
I valori possibili contenuti nel campo sono i seguenti:
- e-mail pervenuta, in attesa di protocollazione
- e.mail scartata dal protocollista
- e-mail protocollata
- e-mail annullata
10.2.2.2 Moduli per la gestione documentale

I moduli per la gestione documentale da parte dei funzionari
regionali permettono di effettuare operazioni sia sui documenti perve-
nuti per via elettronica attraverso il Protocollo Elettronico Regionale,
sia sui documenti pervenuti cartacei. Su questi ultimi il funzionario ha
la possibilita di inserire i dati di protocollazione.
Le funzionalità a disposizione dei funzionari sono le seguenti:
• Ricerca dei progetti con documenti da elaborare attraverso
l’impostazione dei seguenti criteri:
- stato del documento
- tipo di fascicolo (Avvio, Conclusione, Certificazione,etc)

- operatore
- progetto
- identificativo documento
• Accesso ai fascicoli documentali dei progetti selezionati attra
verso la ricerca
• Accesso ai documenti contenuti nei singoli fascicoli, suddivisi per:
- Documenti pervenuti
- Documenti non presentati
- Documenti già validati a cura del funzionario
- Documenti non validati dal funzionario
- Documenti presenti come FAC-SIMILE su
MonitorWEB
• Possibilità di inserimento dei dati di protocollazione nel caso
di documenti pervenuti cartaceamente.
• Possibilità di modiificare lo stato del documento, segnalando la re-
lativa validazione o non validazione indicando contemporanea-
mente eventuali note. Le informazioni così inserite possono essere
recepite in tempo reale dagli operatori di formazione
L’ambiente di gestione documentale da parte dei funzionari viene
realizzato attraverso le videate seguenti:
10.2.2.3 Moduli per la consultazione dei documenti

Questi moduli funzionali permettono al funzionario l’accesso
in sola consultazione ai documenti legati ad un progetto, all’interno
dell’area Gestione Progetti. Tale area propone al funzionario il quadro
sinottico dei progetti di competenza, suddivisi per bando e per stato
di avanzamento.
A partire dall’elenco dei progetti Finanziati, è possibile acce-
dere ai fascicoli di ciascun progetto e, quindi, visualizzare/scaricare
(download) i singoli documenti di un fascicolo.
L’interfaccia grafica è la seguente:

Area di gestione regionale: Funzione di Ricerca dei documenti
Area di gestione regionale: Accesso ai fascicoli di un progetto

Area di gestione regionale: Accesso ai documenti di un
fascicolo di progetto
Area di counsultazione regionale: Gestione Progetti

Finanziati

Area di counsultazione regionale: Accesso ai fascicoli di
un progetto
Area di counsultazione regionale: Accesso in lettura ai

singoli documenti

Bibliografia
AA.VV. “Il Protocollo nella Pubblica Amministrazione” Università della

Calabria 
AA.VV. “La documentazione amministrativa”, Maggioli, 
AA.VV. “Speciale E-government” in Guida agli Enti Locali de Il Sole 24
Ore n°34/
CAMMARATA e MACCARONE, “La firma digitale sicura” Giuffrè 
CHIRENTI “Innovazione nella pubblica Amministrazione: Dal sistema
di protocollo informatico alla automazione dei flussi di lavoro”, Agorà
Edizioni 
GUERCIO, “Archivistica Informatica”, Carocci Editore 
MERLONI, “L’informazione delle pubbliche amministrazioni”, Mag-
gioli, 
PIAZZA e BUTTI, “Il protocollo informatico per la pubblica ammini-
strazione”, Maggioli 
RIDOLFI, “Firma elettronica, tecniche, norme, applicazioni”, Angeli 
TOMMASI, “La firma digitale guida pratica all’uso” Maggioli 

Sitografia
www.anci.it/cie/
www.buoniesempi.it
www.cantieripa.it
www.card.infocamere.it
www.cartaidentita.it
www.cnipa.gov.it
www.comune.bologna.it/firma_digitale/
www.comune.modena.it/firma/
www.comune.pordenone.it/servizi/protocollo.htm
http://comunicare.provincia.parma.it
www.corteconti.it
www.crcitalia.it
www.crs.lombardia.it
www.ct.rupa.it
www.forumpa.it
www.governo.it/GovernoInforma/Dossier/carta_nazionale_servizi/
www.governo.it/GovernoInforma/Dossier/firma_digitale/
www.governo.it/GovernoInforma/Dossier/protocollo_informatico/
www.indicepa.gov.it/
www.innovazione.gov.it
www.interlex.it
www.lispa.it
http://mizar.comune.livorno.it/firmadigitale/
www.monitorweb.it

www.protocollo.gov.it
http://protocollo.rupar.puglia.it/
www.provincia.fi.it/firmadig/prog.htm
www.provincia.torino.it/e_gov/firma.htm
www.regionedigitale.net
www.regione.emilia-romagna.it/firma.digitale/
www.regione.lombardia.it
www.studiocelentano.it
www.ulss.tv.it/firmaelettronica/
www.unict.it/direzione/consip/Firma_digitale.pdf
http://utenti.lycos.it/FirmaDigitale

Progetto Firm@

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Progetto Firm@

Uploaded by

Copyright:

Available Formats

Carla Almirante Angelo Cardani Ruggero Civitarese Filippo Chesi

20100 Milano – Via Vittor Pisani 13 – Tel. 02-6700230

Progetto graﬁco: Francesca Caricato

Parte I - Aspetti generali dei progetti di e-gov 9

3. I presupposti tecnologici ed infrastrutturali 42

5. Allegato: le fonti normative di riferimento 92

Parte II - Il progetto ﬁrm@ 97

7. Aspetti di contesto 106

8 Il Protocollo Informatico della Regione Lombardia 127

9 Introduzione della Firma Digitale nella Gestione FSE 131

10 Modalità di attuazione della sperimentazione 151

Il Progetto Firm@ si inserisce nel più vasto panorama dei pro-

7 PROGETTO FIRM@ Documento di progettazione

8 PROGETTO FIRM@ Documento di progettazione

1.1 Aspetti qualiﬁcanti e portata innovativa nei progetti di

10 L’impatto Economico dei Fondi Strutturali

1.2 Le diverse forme dei progetti di e-government

Livello 1: Informativo (Information). Sono disponibili on line solo

11 PROGETTO FIRM@ Documento di progettazione

13 PROGETTO FIRM@ Documento di progettazione

14 PROGETTO FIRM@ Documento di progettazione

1.2.3 Le tipologie di servizio di e-government oﬀerto

15 PROGETTO FIRM@ Documento di progettazione

Sistema di e-government Caratteristiche

livello minimo di servizio percepito

La matrice successiva mostra invece un altro modo di interpre-

16 PROGETTO FIRM@ Documento di progettazione

17 PROGETTO FIRM@ Documento di progettazione

1.3 Concezione e attuazione di un progetto di e-gov

18 PROGETTO FIRM@ Documento di progettazione

Concezione e progettazione del modello “a tendere”

Sviluppo della soluzione tecnologica

19 PROGETTO FIRM@ Documento di progettazione

Attivazione del servizio

Fasi Sotto-fasi Attività principali

20 PROGETTO FIRM@ Documento di progettazione

21 PROGETTO FIRM@ Documento di progettazione

22 PROGETTO FIRM@ Documento di progettazione

2.1 La razionalizzazione dei processi e il ridisegno

L’esplicitazione dei contenuti e delle modalità innovative del ser-

23 PROGETTO FIRM@ Documento di progettazione

24 L’impatto Economico dei Fondi Strutturali

25 PROGETTO FIRM@ Documento di progettazione

Ruolo dello sportello e-gov

Queste scelte in molti casi riescono a fare la diﬀerenza tra progetti

2.2 La gestione dell’interazione con l’utente

26 PROGETTO FIRM@ Documento di progettazione

27 PROGETTO FIRM@ Documento di progettazione

28 PROGETTO FIRM@ Documento di progettazione

Tipi di documenti ﬁrmati digitalmente:

30 PROGETTO FIRM@ Documento di progettazione

2.2.3 La gestione documentale: scambi e archiviazione

31 PROGETTO FIRM@ Documento di progettazione

32 PROGETTO FIRM@ Documento di progettazione

2.3 Il problema della sicurezza delle transazioni

34 PROGETTO FIRM@ Documento di progettazione

2.3.2 Gestione delle transazioni economiche

35 PROGETTO FIRM@ Documento di progettazione

36 PROGETTO FIRM@ Documento di progettazione

37 PROGETTO FIRM@ Documento di progettazione

38 PROGETTO FIRM@ Documento di progettazione

2.3.3 Tutela della privacy

39 PROGETTO FIRM@ Documento di progettazione

40 PROGETTO FIRM@ Documento di progettazione