Misure di sicurezza e quadro di affidabilità avanzato

1. Modello di sicurezza e responsabilità condivisa

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

I dati tecnici di accesso possono essere trattati per sicurezza, diagnosi di malfunzionamenti, prevenzione abusi e dimostrazione di responsabilità. La registrazione deve essere proporzionata: log applicativi e di sicurezza non dovrebbero contenere sequenze genomiche, referti o contenuto trasmesso sensibili se non strettamente necessario e autorizzato.

Le misure devono essere riesaminate in funzione di minacce, vulnerabilità, incidenti e cambiamenti architetturali. Eventuali attestazioni o certificazioni dell’organizzazione non devono essere presentate come certificazione automatica del singolo prodotto o dell’ambiente del cliente.

Per implementazioni enterprise, la decisione deve essere tradotta in una matrice RACI, evidenze verificabili, criteri di accettazione, controlli tecnici e un riesame periodico; le eccezioni devono essere approvate, motivate, limitate nel tempo e tracciate.

2. Governance della sicurezza

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

I dati tecnici di accesso possono essere trattati per sicurezza, diagnosi di malfunzionamenti, prevenzione abusi e dimostrazione di responsabilità. La registrazione deve essere proporzionata: log applicativi e di sicurezza non dovrebbero contenere sequenze genomiche, referti o contenuto trasmesso sensibili se non strettamente necessario e autorizzato.

Le misure devono essere riesaminate in funzione di minacce, vulnerabilità, incidenti e cambiamenti architetturali. Eventuali attestazioni o certificazioni dell’organizzazione non devono essere presentate come certificazione automatica del singolo prodotto o dell’ambiente del cliente.

Nei progetti sanitari o multicentrici, il requisito deve essere collegato al protocollo, al registro delle decisioni, alla DPIA o al fascicolo di sicurezza quando pertinenti, evitando che una configurazione tecnica sostituisca una valutazione giuridica o scientifica.

3. Identità, autenticazione e 2FA

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

Il soggetto giuridico responsabile deve essere identificabile senza ambiguità. I dati societari, i canali di contatto e l’eventuale ruolo privacy sono pubblicati in modo separato dalla denominazione commerciale del prodotto; eventuali divisioni o unità organizzativa interna non modificano la titolarità giuridica salvo espressa comunicazione.

L’autenticazione a due fattori riduce il rischio di compromissione delle credenziali e può essere resa obbligatoria per i ruoli previsti dalla policy. Il Superadmin mantiene la possibilità di configurare tale policy; recupero, reset e disattivazione devono essere tracciati e protetti da controlli equivalenti.

La conformità è un processo continuo: cambiamenti di finalità, dati, fornitori, motori, hosting, integrazioni o normativa richiedono una valutazione di impatto e, se necessario, aggiornamento di contratto, misure, istruzioni e documentazione.

4. Autorizzazioni, controllo degli accessi basato sui ruoli (RBAC) e principio del minimo privilegio

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

La destinazione d’uso corrente deve essere richiamata nei materiali, nei manuali e nei processi di attivazione iniziale. Qualunque modifica che introduca una finalità medica, diagnostica, prognostica, predittiva o terapeutica richiede una nuova analisi di qualificazione del software e, se applicabile, un percorso MDR/IVDR e una rivalutazione ai sensi dell’AI Act.

I permessi sono assegnati per ruolo e perimetro organizzativo secondo il minimo privilegio. Devono essere riesaminati periodicamente e al mutare delle mansioni; operazioni ad alto impatto, esportazioni e funzioni amministrative sono riservate a ruoli esplicitamente autorizzati.

UESE conserva evidenze proporzionate alla funzione e al rischio. L’organizzazione cliente rimane responsabile delle proprie autorizzazioni, dei protocolli, delle basi giuridiche e delle decisioni sanitarie o scientifiche che eccedono il perimetro del servizio affidato a UESE.

5. Segregazione logica tra organizzazioni

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

I dati tecnici di accesso possono essere trattati per sicurezza, diagnosi di malfunzionamenti, prevenzione abusi e dimostrazione di responsabilità. La registrazione deve essere proporzionata: log applicativi e di sicurezza non dovrebbero contenere sequenze genomiche, referti o contenuto trasmesso sensibili se non strettamente necessario e autorizzato.

La separazione multi-tenant è realizzata applicando il contesto organizzativo a ogni interrogazione e operazione applicativa. Il cliente deve evitare configurazioni che consentano condivisioni improprie tra progetti; eventuali istanze dedicate o on-premise possono essere valutate per requisiti di isolamento ulteriori.

Per implementazioni enterprise, la decisione deve essere tradotta in una matrice RACI, evidenze verificabili, criteri di accettazione, controlli tecnici e un riesame periodico; le eccezioni devono essere approvate, motivate, limitate nel tempo e tracciate.

6. Cifratura e gestione dei segreti

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

Credenziali e segreti applicativi devono essere cifrati o sottoposti a hashing con algoritmi appropriati alla funzione. I dati in transito richiedono TLS; checksum e catene di integrità possono supportare la verifica delle evidenze, ma non sostituiscono copia di sicurezza, controllo accessi o validazione scientifica.

Le misure devono essere riesaminate in funzione di minacce, vulnerabilità, incidenti e cambiamenti architetturali. Eventuali attestazioni o certificazioni dell’organizzazione non devono essere presentate come certificazione automatica del singolo prodotto o dell’ambiente del cliente.

Nei progetti sanitari o multicentrici, il requisito deve essere collegato al protocollo, al registro delle decisioni, alla DPIA o al fascicolo di sicurezza quando pertinenti, evitando che una configurazione tecnica sostituisca una valutazione giuridica o scientifica.

7. Protezione dei dati genomici e archivio

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

Dati relativi alla salute e dati genetici sono categorie particolari ai sensi dell’art. 9 GDPR. Il titolare deve individuare una base dell’art. 6 e una condizione dell’art. 9, valutare eventuali norme sanitarie e di ricerca nazionali e applicare garanzie adeguate; la pseudonimizzazione riduce il rischio ma non trasforma automaticamente i dati in anonimi.

FASTQ, BAM/CRAM e grandi dataset non dovrebbero transitare attraverso upload PHP ordinari sullo hosting condiviso. La piattaforma governa metadati, riferimenti, checksum e autorizzazioni, mentre i contenuto trasmesso voluminosi devono essere conservati su archivio digitale autorizzato, preferibilmente in territorio e condizioni compatibili con il progetto.

La conformità è un processo continuo: cambiamenti di finalità, dati, fornitori, motori, hosting, integrazioni o normativa richiedono una valutazione di impatto e, se necessario, aggiornamento di contratto, misure, istruzioni e documentazione.

8. Integrità, hashing e tracciabilità

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

Credenziali e segreti applicativi devono essere cifrati o sottoposti a hashing con algoritmi appropriati alla funzione. I dati in transito richiedono TLS; checksum e catene di integrità possono supportare la verifica delle evidenze, ma non sostituiscono copia di sicurezza, controllo accessi o validazione scientifica.

Le misure devono essere riesaminate in funzione di minacce, vulnerabilità, incidenti e cambiamenti architetturali. Eventuali attestazioni o certificazioni dell’organizzazione non devono essere presentate come certificazione automatica del singolo prodotto o dell’ambiente del cliente.

UESE conserva evidenze proporzionate alla funzione e al rischio. L’organizzazione cliente rimane responsabile delle proprie autorizzazioni, dei protocolli, delle basi giuridiche e delle decisioni sanitarie o scientifiche che eccedono il perimetro del servizio affidato a UESE.

9. Registrazione eventi e audit

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

Le misure devono essere riesaminate in funzione di minacce, vulnerabilità, incidenti e cambiamenti architetturali. Eventuali attestazioni o certificazioni dell’organizzazione non devono essere presentate come certificazione automatica del singolo prodotto o dell’ambiente del cliente.

Per implementazioni enterprise, la decisione deve essere tradotta in una matrice RACI, evidenze verificabili, criteri di accettazione, controlli tecnici e un riesame periodico; le eccezioni devono essere approvate, motivate, limitate nel tempo e tracciate.

10. Sicurezza applicativa e sviluppo

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

I dati tecnici di accesso possono essere trattati per sicurezza, diagnosi di malfunzionamenti, prevenzione abusi e dimostrazione di responsabilità. La registrazione deve essere proporzionata: log applicativi e di sicurezza non dovrebbero contenere sequenze genomiche, referti o contenuto trasmesso sensibili se non strettamente necessario e autorizzato.

Il ciclo di sviluppo prevede controllo delle dipendenze, revisione delle modifiche, test e gestione degli aggiornamenti. Le vulnerabilità sono valutate secondo gravità, esposizione e impatto; le correzioni critiche possono richiedere manutenzione urgente e comunicazioni dedicate ai clienti interessati.

Nei progetti sanitari o multicentrici, il requisito deve essere collegato al protocollo, al registro delle decisioni, alla DPIA o al fascicolo di sicurezza quando pertinenti, evitando che una configurazione tecnica sostituisca una valutazione giuridica o scientifica.

11. Gestione delle vulnerabilità e degli aggiornamenti correttivi

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

Il ciclo di sviluppo prevede controllo delle dipendenze, revisione delle modifiche, test e gestione degli aggiornamenti. Le vulnerabilità sono valutate secondo gravità, esposizione e impatto; le correzioni critiche possono richiedere manutenzione urgente e comunicazioni dedicate ai clienti interessati.

Le misure devono essere riesaminate in funzione di minacce, vulnerabilità, incidenti e cambiamenti architetturali. Eventuali attestazioni o certificazioni dell’organizzazione non devono essere presentate come certificazione automatica del singolo prodotto o dell’ambiente del cliente.

La conformità è un processo continuo: cambiamenti di finalità, dati, fornitori, motori, hosting, integrazioni o normativa richiedono una valutazione di impatto e, se necessario, aggiornamento di contratto, misure, istruzioni e documentazione.

12. Sicurezza delle integrazioni e API

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

Le integrazioni devono essere censite e autorizzate. Il cliente deve stabilire quali dati possono uscire dal proprio perimetro, quali credenziali utilizzare, chi governa le API e quali condizioni contrattuali si applicano al destinatario; token, endpoint e segreti devono essere gestiti con minimo privilegio e rotazione appropriata.

I dati tecnici di accesso possono essere trattati per sicurezza, diagnosi di malfunzionamenti, prevenzione abusi e dimostrazione di responsabilità. La registrazione deve essere proporzionata: log applicativi e di sicurezza non dovrebbero contenere sequenze genomiche, referti o contenuto trasmesso sensibili se non strettamente necessario e autorizzato.

UESE conserva evidenze proporzionate alla funzione e al rischio. L’organizzazione cliente rimane responsabile delle proprie autorizzazioni, dei protocolli, delle basi giuridiche e delle decisioni sanitarie o scientifiche che eccedono il perimetro del servizio affidato a UESE.

13. Copia di sicurezza, ripristino e resilienza

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

I dati tecnici di accesso possono essere trattati per sicurezza, diagnosi di malfunzionamenti, prevenzione abusi e dimostrazione di responsabilità. La registrazione deve essere proporzionata: log applicativi e di sicurezza non dovrebbero contenere sequenze genomiche, referti o contenuto trasmesso sensibili se non strettamente necessario e autorizzato.

Le copie di sicurezza applicative devono essere cifrate, testate e custodite separatamente dall’ambiente primario. RPO e RTO non sono valori impliciti del software ma obiettivi contrattuali che dipendono dall’hosting e dal piano di continuità; il ripristino deve includere verifiche di integrità e funzionalità prima della riapertura.

RTO e RPO, se previsti, devono essere espressi in modo esplicito nello SLA e coerenti con l’infrastruttura. In assenza di valori sottoscritti non possono essere desunti dal materiale pubblico; disaster recovery e ripristino applicativo devono essere periodicamente testati quando richiesto dal piano di continuità.

Per implementazioni enterprise, la decisione deve essere tradotta in una matrice RACI, evidenze verificabili, criteri di accettazione, controlli tecnici e un riesame periodico; le eccezioni devono essere approvate, motivate, limitate nel tempo e tracciate.

14. Registrazione degli eventi, monitoraggio e risposta agli incidenti

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

Gli eventi sono classificati per gravità e impatto, contenuti e documentati. Se UESE opera quale responsabile, notifica al titolare senza ingiustificato ritardo le violazioni di cui viene a conoscenza e fornisce le informazioni disponibili per consentire le valutazioni ex artt. 33 e 34 GDPR; le comunicazioni alle autorità restano in capo al soggetto competente.

Le misure devono essere riesaminate in funzione di minacce, vulnerabilità, incidenti e cambiamenti architetturali. Eventuali attestazioni o certificazioni dell’organizzazione non devono essere presentate come certificazione automatica del singolo prodotto o dell’ambiente del cliente.

Nei progetti sanitari o multicentrici, il requisito deve essere collegato al protocollo, al registro delle decisioni, alla DPIA o al fascicolo di sicurezza quando pertinenti, evitando che una configurazione tecnica sostituisca una valutazione giuridica o scientifica.

15. Gestione dei fornitori e catena di fornitura

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

I destinatari devono essere limitati a persone autorizzate e fornitori necessari. Prima di affidare trattamenti a terzi vengono valutati ruolo, sicurezza, localizzazione, subfornitura e condizioni contrattuali; la catena di sub-responsabili è governata secondo l’art. 28 GDPR e le eventuali procedure di autorizzazione pattuite.

Le misure devono essere riesaminate in funzione di minacce, vulnerabilità, incidenti e cambiamenti architetturali. Eventuali attestazioni o certificazioni dell’organizzazione non devono essere presentate come certificazione automatica del singolo prodotto o dell’ambiente del cliente.

La conformità è un processo continuo: cambiamenti di finalità, dati, fornitori, motori, hosting, integrazioni o normativa richiedono una valutazione di impatto e, se necessario, aggiornamento di contratto, misure, istruzioni e documentazione.

16. Accessi amministrativi e operazioni privilegiate

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

Le misure devono essere riesaminate in funzione di minacce, vulnerabilità, incidenti e cambiamenti architetturali. Eventuali attestazioni o certificazioni dell’organizzazione non devono essere presentate come certificazione automatica del singolo prodotto o dell’ambiente del cliente.

UESE conserva evidenze proporzionate alla funzione e al rischio. L’organizzazione cliente rimane responsabile delle proprie autorizzazioni, dei protocolli, delle basi giuridiche e delle decisioni sanitarie o scientifiche che eccedono il perimetro del servizio affidato a UESE.

17. Test, verifiche e miglioramento continuo

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

Le misure devono essere riesaminate in funzione di minacce, vulnerabilità, incidenti e cambiamenti architetturali. Eventuali attestazioni o certificazioni dell’organizzazione non devono essere presentate come certificazione automatica del singolo prodotto o dell’ambiente del cliente.

Per implementazioni enterprise, la decisione deve essere tradotta in una matrice RACI, evidenze verificabili, criteri di accettazione, controlli tecnici e un riesame periodico; le eccezioni devono essere approvate, motivate, limitate nel tempo e tracciate.

18. Limiti della dichiarazione pubblica e documentazione cliente

UESE adotta un modello di sicurezza a difesa in profondità, con controlli organizzativi, applicativi e infrastrutturali proporzionati al rischio. La sicurezza effettiva dipende anche da hosting, configurazione, integrazioni, identità federate, endpoint, procedure del cliente e fornitori: il modello è pertanto di responsabilità condivisa e deve essere formalizzato nel piano di sicurezza del singolo progetto.

La documentazione è soggetta a controllo di versione e può essere aggiornata per riflettere evoluzioni tecniche, scientifiche o normative. Le banche dati importate dal cliente restano sotto la responsabilità del soggetto che ne dispone l’uso; l’esistenza di una funzione di importazione non attribuisce a UESE diritti sul contenuto né garantisce che la fonte possa essere riutilizzata.

Le informazioni fornite all’utente devono essere sufficienti a comprendere finalità, input, natura del punteggio, principali limiti e condizioni di non utilizzo. La spiegabilità richiesta è proporzionata al rischio e al ruolo dell’utente; un punteggio numerico privo di contesto non è considerato spiegazione adeguata.

Nei progetti sanitari o multicentrici, il requisito deve essere collegato al protocollo, al registro delle decisioni, alla DPIA o al fascicolo di sicurezza quando pertinenti, evitando che una configurazione tecnica sostituisca una valutazione giuridica o scientifica.