Conformità SaaS: un approfondimento sulle principali normative UE

Cos'è un prodotto SaaS "puro"?

SaaS, o software as a service, si riferisce a un software eseguito su un server centrale o nel cloud e accessibile da remoto. Questo modello ha rivoluzionato il modo in cui il software viene venduto, consentendo alle aziende di passare da un modello di vendita basato su licenza a uno basato su ricavi ricorrenti. Si può dire che sia stato questo a innescare l'enorme boom tecnologico a cui abbiamo assistito negli ultimi 15 anni e oltre.

Tuttavia, oggi pochissimi servizi sono SaaS "puri". Questo perché c'è stata una spinta a trasferire parte del carico di elaborazione su dispositivi edge e client locali. Spesso, servizi che un tempo erano SaaS puri ora vengono distribuiti con client nativi per dispositivi mobili e desktop. Questi client possono essere principalmente un frontend per il servizio, ma di fatto spostano quasi sempre parte dell'elaborazione sul dispositivo.

Quindi, perché è importante?

Naturalmente, c'è sempre una discussione filosofica da fare, osservando come l'informatica abbia attraversato cicli di elaborazione centralizzata e decentralizzata. Ma in realtà c'è una discussione molto più concreta su come questo influisca sulla tua conformità, specialmente quando si tratta di normative UE.

Cyber Resilience Act (CRA)

Il CRA entrerà pienamente in vigore alla fine del 2027. Si tratta di un atto estremamente ampio volto a migliorare la sicurezza informatica dei prodotti connessi venduti all'interno dell'UE. Impone obblighi significativi alle aziende, tra cui:

• Sicurezza per impostazione predefinita. Qualsiasi prodotto in grado di connettersi a Internet deve essere sicuro per impostazione predefinita. Ciò significa che deve essere sicuro senza che l'utente debba configurare o modificare nulla.
• Dichiarazione di conformità. I prodotti sono obbligati a dichiarare la propria conformità ai requisiti del CRA. Spesso si tratta di un'autodichiarazione, ma alcuni prodotti a rischio più elevato, come qualsiasi dispositivo indossabile commercializzato per bambini, dovranno essere valutati da un organismo notificato.
• Monitoraggio delle vulnerabilità. Ogni vulnerabilità e ogni incidente di sicurezza informatica, sospetto o accertato, deve essere segnalato su una piattaforma centrale ENISA.
• Aggiornamenti di sicurezza per l'intero ciclo di vita. È necessario rilasciare patch di sicurezza per l'intero ciclo di vita del prodotto, che è di 5 anni per impostazione predefinita. È inoltre necessario indicare chiaramente la data in cui tali patch non saranno più fornite.

SaaS puro escluso?

Il CRA esclude determinati prodotti anche se sono "connessi". Ad esempio, non si applica ai prodotti che sono già tenuti a essere sicuri in base ad altre normative (ad esempio, i dispositivi medici ai sensi del MDR). La rilevanza per questo articolo è che il CRA non si applica ai servizi SaaS puri. Ma è importante sottolineare che i servizi SaaS supportati da un client locale o collegati a qualsiasi dispositivo devono essere conformi al CRA. Questo potrebbe spingere le aziende a pensarci due volte prima di lanciare un client locale per il proprio servizio, se questo non offre alcun vantaggio aggiuntivo all'utente.

GDPR

Il GDPR ha implicazioni significative per i prodotti SaaS, tra cui la residenza dei dati (dove vengono archiviati ed elaborati), l'affidabilità dei dati e i diritti degli interessati.

Residenza dei dati

La scelta del provider cloud può essere determinante ai fini del GDPR. Molti di questi provider, come Google, AWS o Azure, hanno sede negli Stati Uniti. Attualmente questo non rappresenta un problema, ma non è sempre stato così. Qualche anno fa abbiamo dovuto affrontare gravi criticità innescate dalla sentenza Schrems II della CGUE. Un requisito fondamentale del GDPR è che i dati possano essere elaborati solo all'interno dell'UE o in una giurisdizione che l'EDPB ha dichiarato dotata di leggi sulla protezione dei dati "equivalenti". La sentenza Schrems II ha stabilito che gli Stati Uniti non soddisfacevano tale soglia. In sostanza, ciò ha imposto alle aziende di adottare misure di sicurezza e controlli legali aggiuntivi per poter utilizzare i provider cloud statunitensi. Attualmente è in vigore un trattato UE-USA che si è dimostrato in grado di fornire tutele sufficienti, ma periodicamente emergono nuovi casi legali che tentano di ribaltare lo status quo.

Alcuni servizi SaaS scelgono di aggirare le parti più complesse del GDPR mantenendo tutti i dati personali sul dispositivo locale ed elaborando nel cloud solo dati anonimi. Un buon esempio è l'uso della privacy differenziale da parte di Apple per proteggere i log di monitoraggio dei dispositivi.

Affidabilità dei dati

Un'altra questione riguarda gli obblighi verso gli interessati. Uno di questi è l'obbligo di proteggere i dati personali in proprio possesso e di facilitarne l'accesso. Ciò significa che è necessario pianificare il backup, l'affidabilità del servizio e il disaster recovery. Troppo spesso le aziende dispongono di backup ma non di un piano per ripristinare i dati in caso di problemi. O, peggio, i loro backup sono stati compromessi da un lento degrado del database di produzione, che viene poi replicato all'interno dei backup stessi.

Il nostro consiglio: pianificate adeguatamente il disaster recovery e verificate di poter ripristinare con successo i dati dai backup. Ricordate inoltre di archiviare i backup periodici in una posizione diversa dal cluster di produzione.

AI Act

L'AI Act ha implicazioni concrete per le aziende SaaS, specialmente per quanto riguarda l'elaborazione dei dati di addestramento. Gli obblighi specifici dipenderanno dal livello di rischio del vostro prodotto di intelligenza artificiale.

Sistemi di IA a rischio basso e medio

Qualsiasi sistema di IA deve rispettare gli obblighi di trasparenza previsti dall'AI Act. Ciò significa che dovete:

• Informare gli utenti che stanno interagendo con un sistema di IA. Ad esempio, il vostro chatbot deve comunicare all'utente che sta parlando con un'intelligenza artificiale.
• Garantire che la vostra IA si comporti in modo etico. Ciò significa che:
  • Non utilizza tecniche manipolatorie
  • Non esegue valutazioni del comportamento sociale (social scoring)
  • Non deve sfruttare alcuna vulnerabilità

Sistemi di IA ad alto rischio

L'AI Act definisce ad alto rischio i sistemi che pongono minacce significative alla salute, alla sicurezza o ai diritti fondamentali. Ciò significa che molti sistemi di IA utilizzati nell'assistenza sanitaria o nelle infrastrutture critiche sono classificati come ad alto rischio e devono soddisfare requisiti aggiuntivi rigorosi.

• Implementare un sistema di gestione del rischio che venga mantenuto aggiornato durante l'intero ciclo di vita del prodotto
• Garantisci una buona governance dei dati. Ciò significa utilizzare dati di addestramento di alta qualità, cercare di ridurre al minimo i bias nei dati e monitorare il modello per rilevare eventuali derive o tentativi di data poisoning.
• Mantieni una documentazione tecnica completa che possa essere utilizzata per dimostrare la tua conformità.
• Implementa il log di audit e assicurati di avere la tracciabilità di tutti gli esiti del modello.
• Soddisfa ulteriori requisiti di trasparenza, come spiegare agli utenti il funzionamento del sistema e le sue eventuali limitazioni.
• Supervisione umana. Assicurati che ci sia sempre un essere umano a supervisionare il sistema. Può trattarsi di un approccio human-in-the-loop (HITL) o human-on-the-loop (HOTL).
• Garantisci l'accuratezza, la sicurezza e la robustezza del sistema.

Normative locali

Ultimo ma non meno importante, in tutta l'UE esistono innumerevoli normative locali che possono avere un impatto significativo sui servizi SaaS. Esistono decine di queste normative locali che potrebbero influenzare il modo in cui progetti e distribuisci il tuo prodotto SaaS. In linea di massima, i 3 impatti principali riguarderanno:

• Residenza dei dati: ad esempio, in quale paese è consentito elaborare i dati?
• Affidabilità dei dati: ad esempio, esistono regole su dove devono essere archiviati i backup?
• Cybersecurity: esistono certificazioni o controlli specifici che devi implementare?

In alcuni casi, queste regole si applicano solo a determinati dati sensibili, come le cartelle cliniche. Altre, invece, hanno un ambito di applicazione molto più ampio. Ecco 3 esempi:

• C5. Il catalogo dei criteri di conformità per il cloud computing (Cloud Computing Compliance Criteria Catalogue) della Germania era originariamente destinato a definire i controlli di sicurezza per i fornitori di cloud. Tuttavia, è diventato sempre più un requisito de facto per qualsiasi SaaS utilizzato in ospedali o compagnie assicurative.
• HDS. L'Hébergeur de Données de Santé francese definisce regole rigorose per il trattamento dei dati sanitari. Stabilisce severi controlli di sicurezza in 6 aree, tra cui data center fisici, servizi di infrastruttura cloud ed esternalizzazione dei backup. I prodotti SaaS per la salute possono essere eseguiti solo su fornitori cloud certificati HDS.
• ENS. L'Esquema Nacional de Seguridad spagnolo è uno standard di sicurezza informatica obbligatorio che si applica a tutti i servizi digitali in Spagna. I prodotti sono classificati come a rischio basso, medio o alto, con requisiti diversi a seconda del livello di rischio.

‍