Docs Italia beta

Documenti pubblici, digitali.

7. Governance del Punto di accesso telematico

7.1. Adesione al Punto di accesso telematico dei Soggetti erogatori

Il Gestore DEVE gestire le adesioni dei Soggetti erogatori secondo quanto indicato all’allegato 1 con modalità idonee a garantire l’onboarding dei Soggetti erogatori in tempi rapidi e con modalità efficienti per garantire agli utenti finali l’accesso a un numero crescente di Servizi in rete, e a tal fine valuta, di concerto con i soggetti coinvolti, l’adesione da parte di Pubbliche Amministrazioni in forma aggregata ai sensi del 7.1.2 Soggetti aggregatori, nonché l’opportunità di avvalersi di partner tecnologici comuni a più Soggetti erogatori.

Al fine di aderire al Punto di accesso telematico, i Soggetti erogatori DEVONO stipulare con il Gestore la documentazione contrattuale applicabile, come di seguito descritta.

La documentazione contrattuale standard è predisposta da sottoscritta dal Soggetto erogatore. Essa consta di una lettera di adesione contenente almeno i seguenti allegati:

  • i termini e condizioni di adesione, fornitura e di utilizzo del Punto di accesso telematico (T&C);
  • l’accordo per il trattamento dei dati personali, contenente la nomina a responsabile del Gestore (“DPA”);
  • l’elenco dei soggetti aggregati (compilato solo ove il Soggetto erogatore sia aggregatore di altre PA ai sensi del 7.1.2 Soggetti aggregatori);
  • i termini aggiuntivi applicabili ai Moduli attivati alla data di adesione.

La documentazione contrattuale standard PUÒ essere sostituita o integrata, anche nel tempo, da apposita convenzione predisposta con il Soggetto erogatore e stipulata con lo stesso e/o da ulteriori termini aggiuntivi destinati a regolare i Servizi in rete Servizi che richiedono una disciplina specifica per i quali la documentazione standard non è conferente o sufficiente, nei seguenti casi:

  • Servizio i cui termini e condizioni sono definiti da norma primaria o secondaria;
  • Servizio che richiede uno sviluppo ad hoc.

7.1.1. Soggetti singoli

Per l’erogazione dei Servizi, i Soggetti erogatori DEVONO:

  • identificare le tipologie di Servizi in rete che intendono erogare, in conformità al 7.2. Selezione e sviluppo dei Servizi in rete;
  • attivare la procedura di adesione, sottoscrivendo la relativa documentazione contrattuale applicabile, come descritto in premessa al 7.1 Adesione al Punto di accesso telematico dei Soggetti erogatori;
  • prendere visione della documentazione correlata al rapporto di adesione al Punto di accesso telematico, con particolare riferimento alle specifiche per l’integrazione tecnologica contenute nella Documentazione API nella versione pubblicata dal Gestore;
  • predisporre l’integrazione tra i Sistemi degli enti e il Punto di accesso per il tramite delle API indicate nella Documentazione API previa registrazione al Portale e configurazione dei Servizi in rete;
  • eseguire con esito positivo le attività di test ai sensi del 7.2.3 Verifica e test dei Servizi in rete;
  • inserire l’anagrafica completa che descrive ciascun Servizio in rete e procedere alla sua attivazione.

I Soggetti erogatori DEVONO rispettare, e garantiscono il rispetto da parte dei propri dipendenti, delegati e/o degli altri soggetti che a qualsiasi titolo agiscono per proprio conto, dei diritti e degli interessi degli utenti finali, sono responsabili del contenuto dei Servizi in rete e utilizzano il Punto di accesso telematico esclusivamente per le finalità istituzionali che gli competono.

Nell’offerta dei propri Servizi in rete, i Soggetti erogatori DEVONO verificare e controllare l’esattezza e l’adeguatezza dei contenuti, nonché la loro conformità alla normativa applicabile.

7.1.2. Soggetti aggregatori

I Soggetti erogatori POSSONO aderire al Punto di accesso telematico in qualità di aggregatori di altri Soggetti erogatori.

L’adesione in forma aggregata DOVREBBE essere privilegiata quando è in grado di garantire la partecipazione, da parte di realtà amministrative di ridotte dimensioni, ai processi di trasformazione digitale, grazie all’accesso a risorse tecniche e organizzative adeguate a mantenere un livello efficiente dei Servizi in rete, nel rispetto dell’autonomia e dell’indipendenza dell’offerta dei servizi locali.

Il rapporto di aggregazione tra Soggetti erogatori è regolato dagli accordi (compresi gli accordi di cooperazione di cui all’art. 15 della L. 241/1990) e dagli atti amministrativi necessari a conferire al soggetto aggregante i poteri e le attribuzioni necessarie a sottoscrivere il rapporto di adesione anche per conto e a beneficio dei soggetti aggregati, assumendo il rispetto degli obblighi ivi contenuti da parte dei soggetti aggregati stessi.

7.1.3. Partner tecnologi

I soggetti aggregatori e i singoli soggetti aggregati POSSONO avvalersi dei partner tecnologici per lo svolgimento delle attività relative alla gestione del processo di adesione, di aggregazione e delle attività tecniche necessarie per l’integrazione tecnologica.

7.2. Selezione e sviluppo dei Servizi in rete

Al fine di ampliare l’offerta dei Servizi in rete, il Gestore DEVE mettere a disposizione di tutti i Soggetti erogatori le necessarie API, le cui modalità tecniche sono descritte nella Documentazione API, per l’integrazione dei Sistemi degli enti con il Punto di accesso telematico. I Soggetti erogatori, per la realizzazione dei propri Servizi in rete erogati per il tramite del Punto di accesso telematico DEVONO attuare le modalità tecniche di integrazione definite nella Documentazione API.

Nel caso di Servizi in rete le cui caratteristiche sono definite da norma primaria o secondaria, il Soggetto erogatore richiedente, se del caso di concerto con altri Soggetti erogatori, valuta (o, nel caso di sviluppo definito da una norma, attua), a titolo gratuito o oneroso a seconda dei casi:

  • il co-sviluppo con il Gestore;
  • l’affidamento dello sviluppo o dell’implementazione in capo al Gestore o ad altro soggetto terzo, fermo restando il rispetto del principio del riuso, ove possibile.

7.2.1. Individuazione del Servizio in rete

7.2.1.1. Catalogo delle tipologie di Servizi in rete

Il Gestore DOVREBBE rendere disponibile un catalogo delle tipologie dei Servizi in rete già disponibili nel Punto di accesso telematico, indicando quando un determinato servizio in rete in rete è ancora in fase di beta test.

I soggetti di cui all’articolo 2, comma 2 del CAD DEVONO prontamente implementare ed utilizzare i Servizi in rete già presenti nel catalogo. I Servizi in rete in beta test sono facoltativi per i soggetti di cui all’articolo 2, comma 2 del CAD fino al loro rilascio in produzione.

7.2.1.2. Definizione di un nuovo Servizio in rete

Qualora sorgesse la necessità di sviluppare un nuovo Servizio in rete, il Soggetto erogatore ne DEVE farne richiesta al Gestore.

Il Gestore (i) valuta la fattibilità della richiesta, (ii) verifica il possibile interesse per il servizio da parte di altri Soggetti erogatori, (iii) determina i costi e tempi di sviluppo e implementazione, (iv) valuta gli aspetti tecnici, di sicurezza, di conformità alle norme, ivi inclusa la normativa sul trattamento dei dati personali e (v) e comunica le relative risultanze al Soggetto erogatore e PUÒ coinvolgere gli altri soggetti interessati.

Il Soggetto erogatori o i Soggetti erogatori, DOVREBBERO affidare lo sviluppo al Gestore. Nel caso in cui il Soggetto erogatore, o i Soggetti erogatori, evidenziano sulla base delle risultanze comunicate dal Gestore motivati impedimenti per lo sviluppo e implementazione del nuovo Servizio in rete da parte del Gestore ne danno comunicazione a quest’ultimo.

7.2.2. Realizzazione del servizio in rete

Il Gestore DEVE definire un piano di lavoro condiviso con il Soggetto erogatore per determinare le reciproche responsabilità al fine di assicurare la messa in esercizio del Servizio in rete.

Nella fattispecie di implementazione di un Servizi in rete presente nel catalogo di cui al 7.2.1.1 Catalogo delle tipologie di Servizi in rete il Gestore definisce un template di piano di lavoro che il Soggetto erogatore DEVE compilare e condividere con il Gestore stesso.

Per l’esecuzione del piano di lavoro il Soggetto erogatore PUÒ avvalersi dei servizi di supporto offerti dal Gestore.

7.2.3. Verifica e test dei Servizi in rete

I Soggetti erogatori DEVONO effettuare i test di integrazione indicati dal piano di test predisposto dal Gestore prima di attivare un Servizio in rete. I test vengono effettuati in ambienti e con utenze dedicate o comunque utilizzando codici fiscali fittizi forniti dal Gestore oppure codici fiscali personali forniti volontariamente dai tester.

7.3. Gestione delle anomalie dei Servizi in rete e assistenza agli utenti finali

Il Gestore e i Soggetti erogatori DEVONO stabilire le responsabilità reciproche.

Il Gestore e i Soggetti erogatori DEVONO rispondere alle anomalie di propria pertinenza, in particolare se dovute a eventi relativi alla sicurezza delle informazioni, in accordo alle procedure documentate e DEVONO assicurare che i meccanismi di segnalazione siano facili, accessibili e disponibili quanto più possibile.

Le anomalie dei Servizi in rete fruiti per il tramite del Punto di accesso telematico DEVONO essere:

  • rilevate o segnalate il più velocemente possibile attraverso appropriati canali;
  • valutate e classificate (ad esempio, come issue operative, eventualmente legate a vulnerabilità di sistema / applicazione, o incidenti relativi alla sicurezza delle informazioni) anche al fine di identificare l’impatto e l’estensione di un eventuale incidente.

Il Gestore e i Soggetti erogatori DEVONO, per le parti di propria competenza, assicurare che l’uso delle risorse e dei sistemi sia messo a punto in maniera tale da garantire opportuno monitoraggio e, quindi, adeguata rilevazione di potenziali eventi anomali.

Il Gestore e i Soggetti erogatori DEVONO, per le parti di propria competenza, assicurare che la registrazione degli eventi, delle eccezioni e dei malfunzionamenti sia effettuata, mantenuta e riesaminata periodicamente al meglio delle possibilità, anche attraverso un sistema di monitoraggio automatizzato in grado di generare rapporti consolidati e allarmi su anomalie e sulla sicurezza.

Il Gestore e i Soggetti erogatori DEVONO, per le parti di propria competenza, definire le procedure di gestione degli eventi anomali per assicurare una risposta rapida, efficace e ordinata in particolare quando questi sono ricondotti a:

  • incidenti relativi alla sicurezza delle informazioni e dei dati personali;
  • vulnerabilità tecniche sui sistemi o sul software.

Il Gestore e i Soggetti erogatori DEVONO, per le parti di propria competenza, prendere in considerazione le seguenti prassi per la gestione degli incidenti:

  • pianificazione e preparazione della risposta;
  • monitoraggio, per rilevazione e analisi degli eventi/incidenti o dei punti di debolezza relativi alla sicurezza delle informazioni e dei dati personali;
  • valutazione e presa di decisione;
  • regole per escalation, ripristino controllato e comunicazione verso stakeholder interni ed esterni.

Il Gestore e i Soggetti erogatori DEVONO, per le parti di propria competenza, registrare i risultati delle valutazioni e delle decisioni prese, la conoscenza acquisita dall’analisi e dalla soluzione delle anomalie al fine di utilizzarle per ridurre l’impatto degli incidenti futuri.

Il Gestore e i Soggetti erogatori DEVONO, per le parti di propria competenza, intraprendere azioni appropriate e tempestive per rispondere all’identificazione di potenziali vulnerabilità tecniche, attraverso un processo per la loro gestione efficace (monitoraggio, valutazione del rischio, azioni di riduzione). Le informazioni sulle vulnerabilità tecniche DOVREBBERO essere ottenute in modo tempestivo, l’esposizione a tali vulnerabilità DEVE essere valutata e appropriate misure DEVONO essere intraprese per affrontare i rischi relativi:

  • definendo una scala temporale per reagire alle notifiche di vulnerabilità tecniche potenzialmente pertinenti;
  • identificando una potenziale vulnerabilità tecnica e determinandone i rischi relativi e le azioni da intraprendere tra cui l’applicazione delle patch ai sistemi vulnerabili o l’adozione di altri controlli;
  • portando a termine le azioni intraprese coerentemente con:
    • loro urgenza;
    • controlli collegati alla gestione dei cambiamenti;
    • procedure di risposta agli incidenti relativi alla sicurezza delle informazioni e dei dati personali (per comunicare dati sulle vulnerabilità alle funzioni adibite alla risposta agli incidenti e per fornire procedure tecniche da eseguire in caso di incidente);
    • test e valutazione delle soluzioni individuate, per assicurare che siano efficaci e non comportino effetti collaterali intollerabili, o valutazione dei rischi e individuazione di appropriate azioni di individuazione e correzione in caso non esista (ancora) una contromisura adatta.

Il Gestore e i Soggetti erogatori DEVONO, per le parti di propria competenza, mantenere un log di audit di tutte le procedure intraprese.

Il Gestore e i Soggetti erogatori DEVONO, per le parti di propria competenza, predisporre, considerate le [LG RECOVERY], adeguati piani di continuità operativa per il ripristino delle condizioni anomale, includendo tutti i necessari accorgimenti per il backup e per il ripristino di dati e del software.

Il personale e i collaboratori del Gestore e dei Soggetti erogatori DOVREBBERO:

  • essere consapevoli delle procedure per segnalare gli eventi anomali e del punto di contatto al quale gli eventi sono segnalati;
  • monitorare l’uso delle proprie risorse e sistemi per una adeguata rilevazione di potenziali eventi anomali, ulteriore rispetto a quanto effettuato dal gestore, registrando e riesaminando periodicamente eventi, eccezioni e malfunzionamenti;
  • segnalare il più velocemente possibile ogni evento anomalo, in particolare se ritenuto relativo alla sicurezza delle informazioni e dei dati personali;
  • collaborare con il gestore nella valutazione e classificazione degli eventi;
  • comunicare in maniera tempestiva le informazioni sulle potenziali vulnerabilità tecniche che dovessero rilevare;
  • correggere eventuali anomalie, rispettando (sulla base delle responsabilità individuate e delle istruzioni fornite) le indicazioni del Gestore per la risoluzione di incidenti e/o vulnerabilità.

Il Gestore e i Soggetti erogatori DEVONO, per le parti di propria competenza, mettere a disposizione degli utenti finali efficaci canali per riportare e segnalare le anomalie riscontrate e DEVONO definire tempi di risposta certi alle segnalazione ricevute.

I Soggetti erogatori, tramite i propri canali istituzionali, e il Gestore, tramite apposito sistema di feedback, DEVONO rispondere prontamente alle richieste degli utenti finali nel rispetto degli indicatori di qualità di cui 7.4.4 Indicatori dei servizi di supporto.

I Soggetti erogatori e il Gestore, per le parti di rispettiva competenza, DEVONO altresì svolgere attività di ricerca e coinvolgimento degli utenti finali per monitorare il livello di qualità e individuare i miglioramenti necessari rispetto ai Servizi offerti tramite il Punto di accesso telematico:

  • in fase di analisi e progettazione, consultando i cittadini nell’identificazione e nella definizione dei Servizi e delle funzionalità da veicolare attraverso il Punto di accesso telematico;
  • in fase di sviluppo e test, coinvolgendo i cittadini, con particolare riferimento ad alcune categorie, nella validazione dei modelli e dei contenuti proposti;
  • in fase di produzione, raccogliendo il feedback dei cittadini sull’utilizzo dei Servizi e sui requisiti per successive implementazioni.

7.4. Indicatori di qualità

Il rapporto tra Gestore e Soggetti erogatori in merito ai Servizi in rete è regolato dai livelli di qualità attesi nell’erogazione degli stessi, nello specifico sono oggetto di interesse:

  • i Servizi in rete individuati in accordo dal Soggetto erogatore e Gestore;
  • il piano di lavoro, condiviso tra Gestore e Soggetto erogatore, per la realizzazione dei Servizi in rete;
  • deliverable realizzati dal Gestore, dal Soggetto erogatore o da terze parti per conto degli stessi, in attuazione del piano di lavoro per la realizzazione dei Servizi in rete;
  • API realizzata dal Soggetto erogatore per assicurare l’integrazione con il Punto di accesso telematico, funzionali alla messa in esercizio dei Servizi in rete;
  • servizi di supporto assicurati dal Gestore per la realizzazione e manutenzione dei Servizi in rete;
  • servizi di supporto agli utenti da parte del Gestore e del Soggetto erogatore.

In quanto segue si riportano gli indicatori di qualità utilizzati dal Gestore e i Soggetti erogatori per definire gli accordi sui livelli qualità dei servizi che il Gestore garantisce ai Soggetti erogatori e che i Soggetti erogatori garantiscono agli utenti finali.

Gli stessi indicatori di qualità sono utilizzati dal Gestore e dai Soggetti di cui all’articolo 2, comma 2, dai fornitori di identità digitali e dai prestatori dei servizi fiduciari qualificati per concordare i livelli di qualità assicurati dai servizi resi disponibili, da questi ultimi, al Punto di accesso telematico in ottemperanza al comma 1-bis dell’articolo 50-ter del CAD.

7.4.1. Indicatori sulla qualità dello sviluppo

7.4.1.1. Difettosità in avvio

Il presente indicatore rileva la difettosità residua funzionale e non funzionale all’avvio di un servizio/API. Nello specifico:

  • sono raccolti l’aderenza ai requisiti di accessibilità, usabilità, sicurezza e prestazioni per permettere la piena fruizione delle funzionalità dei Servizi in rete da parte degli utenti finali;
  • sono raccolti l’aderenza ai requisiti di sicurezza e prestazioni per permettere la piena fruizione delle funzionalità delle API realizzate.

L’indicatore è determinato come rapporto tra il numero di requisiti funzionali e non funzionali del servizio/API non soddisfatti in fase di collaudo e il numero di requisiti funzionali e non funzionali dello stesso servizio/API individuati dai requirements dello stesso.

7.4.1.2. Difettosità in avvio in esercizio

Il presente indicatore rileva la difettosità residua funzionale e non funzionale nell’esercizio di un servizio. Nello specifico:

  • sono raccolti l’aderenza ai requisiti di accessibilità, usabilità, sicurezza e prestazioni per permettere la piena fruizione delle funzionalità dei Servizi in rete da parte degli utenti finali;
  • sono raccolti l’aderenza ai requisiti di sicurezza e prestazioni per permettere la piena fruizione delle funzionalità delle API realizzate.

L’indicatore è determinato come rapporto tra il numero di requisiti funzionali e non funzionali del servizio/API non soddisfatti determinati in esercizio e il numero di requisiti funzionali e non funzionali dello stesso servizio/API individuati dai requirements dello stesso.

7.4.2. Indicatori del piano di lavoro

7.4.2.1. Rispetto del piano di lavoro

L’indicatore verifica il rispetto della pianificazione del piano di lavoro misurando il rispetto della scadenza temporale di ciascuna milestone (determinazione dello scostamento tra data prevista e data effettiva), quali ad esempio:

  • la date di consegna degli artefatti;
  • per i cicli agili, ogni data pianificata nello Sprint Planning;
  • la data pianificata di “pronti al collaudo”;
  • la data pianificata di termine collaudo con esito positivo;
  • la data pianificata di avvio in esercizio.

Eventuali ripianificazione del piano di lavoro determinato da ritardi da problematiche relative alle API realizzata dal Soggetto erogatore non sono in alcun modo imputabili al Gestore.

7.4.2.2. Giorni di sospensione del collaudo

La sospensione del collaudo è indice di una grave carenza qualitativa e incompletezza delle attività realizzative. La sospensione può attivarsi automaticamente alla presenza di malfunzionamenti bloccanti in collaudo o su decisione del Soggetto erogatore qualora si verifichino situazioni “anomale” che, a giudizio della stessa, sia per numerosità sia per gravità, sia per non rispetto dei tempi massimi previsti per la risoluzione delle difformità, non consentano lo svolgimento o la prosecuzione delle attività di collaudo.

L’indicatore è determinato dal tempo trascorso tra la sospensione del collaudo e il suo riavvio.

Ogni impedimento determinato da problematiche relative alle API realizzata dal Soggetto erogatore non sono in alcun modo imputabili al Gestore.

7.4.3. Indicatori dei servizi/API realizzati

7.4.3.1. Tempo di risposta delle richieste su percentile

Il tempo che intercorre tra una request e la relativa response, è indice dell’efficienza di un servizio/API. Nel dettaglio il tempo di risposta è calcolata, in esercizio, come il tempo intercorso tra il momento di ricezione della request e il momento di inoltro della relativa response. Le latenze determinata dal canale di comunicazione del servizio/API non sono oggetto del presente indicatore.

Il presente indicatore è determinato dalla media di un percentile fissato delle request pervenute nell’unità di tempo, dove il percentile e l’unità di tempo per la determinazione dell’indicatore sono individuate in accordo tra il Gestore e il Soggetto erogatore per singolo servizio/API, ad esempio tempo medio dell’85% delle richieste pervenute in 10 minuti.

La fonte per la determinazione dei tempi di ricezione delle request e il momento di inoltre delle relativa response è rappresentato dai log file tenuti dal Gestore.

7.4.3.2. Numero di richieste per unità di tempo

Il numero di richieste soddisfatte da un servizio/API è indice della capacità di carico gestibile dallo stesso.

Il presente indicato è determinato dal numero di request soddisfate, cioè a cui il servizio/API è riuscito a produrre response, nell’unità di tempo, l’unità di tempo per la determinazione dell’indicatore sono individuate in accordo tra il Gestore e il Soggetto erogatore per singolo servizio/API, ad esempio numero di request soddisfatte in 10 minuti.

La fonte per la determinazione il numero di request soddisfatte è rappresentato dai log file tenuti dal Gestore.

7.4.3.3. Numero di richieste con risposta di errore per unità di tempo

Il numero di richieste con risposta di errore di un servizio/API è indice inverso della efficacia dello stesso.

Il presente indicato è determinato del numero di request con error response nell’unità di tempo, l’unità di tempo per la determinazione dell’indicatore sono individuate in accordo tra il Gestore e il Soggetto erogatore per singolo servizio/API, ad esempio numero di request con error response in 10 minuti. Si evidenzia che tale indicatore è inversamente proporzionale all’efficacia del servizio/API.

La fonte per la determinazione del numero di request con error response è rappresentato dai log file tenuti dal Gestore.

7.4.4. Indicatori dei servizi di supporto

7.4.4.1. Tempestività di ripristino dell’operatività

Il presente indicatore si applica a non conformità funzionali e non funzionali rilevate ed è calcolato come la differenza in ore tra il momento dell’avvio del processo di risoluzione del malfunzionamento e il termine della risoluzione delle stesso.

7.4.4.2. Tempestività di risposta a segnalazioni di anomalie

Il presente indicatore si applica a non conformità funzionali e non funzionali evidenziate dal Soggetto erogatore e/o dagli utenti finali dei Servizi in rete. L’indicatore è calcolato come la differenza in ore tra il momento della segnalazione e la presa in carico della stessa da parte del Gestore.

Il presente indicatore si applica anche a non conformità funzionali e non funzionali evidenziate dal Gestore e/o dagli utenti finali dei Servizi in rete. L’indicatore è calcolato come la la differenza in ore tra il momento della segnalazione e la presa in carico della stessa da parte del Soggetto erogatore.