Allegato B. Misure tecniche e organizzative (art. 32 Regolamento UE 2016/679)

Premessa

Il presente Allegato descrive le misure tecniche e organizzative che CodeDesign S.r.l. (di seguito il "Fornitore") adotta ai sensi dell'art. 32 del Regolamento UE 2016/679 per garantire un livello di sicurezza adeguato al rischio nel trattamento dei dati personali svolto per conto del Cliente.

Le misure sono descritte per funzione e per effetto. Il Fornitore non riporta dettagli implementativi, denominazioni di sistemi interni, indirizzi, componenti o parametri di configurazione la cui divulgazione ridurrebbe l'efficacia delle misure stesse. Informazioni ulteriori sono messe a disposizione del Cliente con le modalità e i limiti dell'art. 4.8 dell'Allegato A.

Il presente Allegato descrive lo stato delle misure alla data di versione. Può essere aggiornato dal Fornitore purché il livello complessivo di sicurezza non sia ridotto, secondo l'art. 12.5 dei Termini e la sezione 15 che segue.

1. Organizzazione della sicurezza

1.1 Ruoli. Il Fornitore ha attribuito in modo formale le seguenti responsabilità:

• a) Responsabile della sicurezza delle informazioni: valutazione dei rischi di sicurezza, verifica dell'efficacia delle misure, proposta e verifica delle azioni correttive.
• b) Referente per la protezione dei dati personali: coordinamento della materia della protezione dei dati, qualificazione e gestione delle violazioni sotto il profilo giuridico, tenuta del registro delle violazioni, rapporti con l'autorità di controllo, presidio della casella privacy@codedesign.it.
• c) Responsabile della gestione degli incidenti: presa in carico delle segnalazioni, contenimento tecnico, raccolta e conservazione delle evidenze, ricostruzione della portata dell'evento, coordinamento del ripristino.
• d) Direzione: decisione sulle notifiche all'autorità di controllo e sulle comunicazioni agli interessati quando il Fornitore agisce come titolare, approvazione delle risorse per le azioni correttive.

1.2 Responsabile della protezione dei dati. Il Fornitore non ha designato un responsabile della protezione dei dati ai sensi dell'art. 37 del Regolamento, avendo valutato che non ne ricorrano i presupposti. La valutazione è riesaminata con cadenza almeno annuale. Il punto di contatto resta la casella privacy@codedesign.it.

1.3 Sistema di gestione. Il Fornitore ha avviato l'adozione di un sistema di gestione della sicurezza delle informazioni conforme alla norma ISO/IEC 27001:2022 ed è in corso il relativo percorso di certificazione. Alla data del presente Allegato la certificazione non è stata conseguita. Il Fornitore non dichiara di essere certificato e comunicherà ai Clienti l'eventuale conseguimento, aggiornando il presente Allegato.

1.4 Riesame. Le misure descritte nel presente Allegato sono riesaminate con cadenza almeno annuale, dopo ogni violazione di dati personali classificata a rischio medio o alto e dopo ogni modifica rilevante dell'architettura del Servizio.

2. Controllo degli accessi e autenticazione

2.1 Identità centralizzata. L'accesso alla piattaforma avviene esclusivamente attraverso un sistema centralizzato di gestione delle identità, distinto dall'applicazione. Le credenziali degli utenti non sono conservate dall'applicazione.

2.2 Verifica dell'indirizzo di posta elettronica. La politica di autorizzazione predefinita di tutte le interfacce applicative richiede, oltre all'autenticazione, che l'indirizzo di posta elettronica dell'utente risulti verificato. L'accesso è negato in mancanza di tale requisito.

2.3 Autenticazione a due fattori. È disponibile un secondo fattore di autenticazione mediante codice monouso inviato all'indirizzo di posta elettronica dell'utente, configurabile sul sistema di identità.

2.4 Validazione delle sessioni. I token di accesso sono validati in profondità: verifica del destinatario, verifica dell'emittente rispetto a un elenco esplicito, verifica della durata e della scadenza, verifica della firma con rifiuto dei token non firmati, tolleranza limitata sugli orologi. Gli esiti negativi sono registrati con il motivo del rifiuto, senza mai registrare il token.

2.5 Chiavi di accesso applicative. Le chiavi di accesso rilasciate al Cliente per l'uso automatizzato del Servizio sono generate con entropia elevata, sono conservate a riposo esclusivamente sotto forma di impronta crittografica e sono mostrate in chiaro una sola volta, al momento della creazione. Una chiave priva di ambiti dichiarati non consente l'autenticazione su alcun canale. Ogni chiave può essere limitata a specifici Dipendenti digitali. Le chiavi hanno stato e scadenza verificati a ogni utilizzo.

2.6 Separazione dei privilegi delle chiavi. Una chiave applicativa non può in alcun caso ottenere privilegi di piattaforma, di sistema o di organizzazione, ed è soggetta a un elenco esplicito di operazioni sempre negate, tra cui la gestione dell'abbonamento, la modifica dei crediti e la gestione delle quote. Quando una richiesta reca sia l'identità di un utente sia una chiave applicativa, prevale sempre il profilo di autorizzazione dell'utente.

2.7 Permessi granulari e comportamento fail-closed. L'autorizzazione è fondata su permessi atomici risolti dal sistema, non sul piano di abbonamento. Ogni interfaccia dichiara in modo esplicito il permesso richiesto e nega l'accesso in mancanza di dichiarazione o di permesso. Nessun profilo diverso dall'amministratore di piattaforma può creare o modificare definizioni di ruolo, e quindi non può attribuirsi privilegi superiori a quelli posseduti.

2.8 Accesso per conto di un utente. La funzione con cui il personale del Fornitore opera per conto di un Utente del Cliente è ammessa ai soli profili espressamente abilitati, non è attivabile mediante la sola dichiarazione del richiedente, richiede privilegi superiori per operare su profili amministrativi ed è registrata nel registro di audit, insieme ai tentativi negati.

2.9 Autorizzazioni verso i servizi collegati. Le autorizzazioni OAuth verso i servizi collegati dal Cliente sono ottenute con il flusso di codice di autorizzazione con estensione a prova di chiave (PKCE) e con parametro di stato firmato e verificato con confronto a tempo costante. Il rinnovo dei token avviene a flusso singolo con blocco distribuito.

2.10 Token a vita breve. Le sessioni delle funzioni di trascrizione in tempo reale e le sessioni di prova degli agenti vocali usano token a durata limitata, monouso per le sessioni di prova, con firma verificata. In assenza della chiave di firma nessun token è considerato valido.

2.11 Custodia dei token lato client. Il portale del Cliente conserva il token di accesso esclusivamente in memoria, senza scriverlo nella memoria locale del browser. L'applicazione per dispositivi mobili conserva le credenziali nell'archivio sicuro del sistema operativo e applica l'uscita coordinata con cancellazione delle chiavi. I portali secondari non espongono alcun token al browser, mantenendo la sessione lato server in forma cifrata.

3. Separazione dei dati fra Clienti

3.1 Perimetro. L'unità di separazione è l'ambiente applicativo del singolo Cliente. Ogni risorsa, richiesta, credenziale e registro è riferita a tale ambiente, e l'appartenenza dell'utente all'ambiente è verificata a ogni richiesta.

3.2 Natura della misura. La separazione è realizzata mediante controlli applicativi espliciti nei servizi, integrati da una regola unica di verifica dell'accesso applicata come difesa in profondità. Il Fornitore dichiara con trasparenza che si tratta di controlli applicativi presidiati da prove automatiche anti-regressione e non di una separazione strutturale a livello di archivio dati.

3.3 Prove automatiche. L'integrazione continua esegue, a ogni modifica, prove che verificano: che ogni interfaccia dichiari il permesso richiesto, con elenco esplicito e motivato delle sole eccezioni ammesse; che non sia possibile accedere a risorse appartenenti ad altri Clienti; che le limitazioni dei privilegi delle chiavi applicative siano rispettate. Il fallimento di tali prove impedisce l'integrazione della modifica.

3.4 Cancellazione logica. Le entità principali del modello dati sono soggette a cancellazione logica con filtro globale, in modo che un record cancellato non sia mai restituito dalle interrogazioni ordinarie.

3.5 Separazione dei Dipendenti digitali. Ogni Dipendente digitale del Cliente è eseguito in un contenitore dedicato, con volumi di archiviazione propri, con la base di conoscenza montata in sola lettura e con lo spazio di lavoro separato. L'archivio locale con conversazioni, memoria e trascrizioni risiede nel volume del singolo contenitore.

3.6 Canale interno dei Dipendenti digitali. Le chiamate dal contenitore verso i servizi centrali sono autenticate con una credenziale derivata, verificata con confronto a tempo costante e vincolata all'identità del Dipendente digitale, con controllo di coerenza contro il sistema di orchestrazione e con protezione contro lo scambio di identità fra Dipendenti digitali diversi.

3.7 Separazione nell'osservabilità. Ogni interrogazione su registri e tracce tecniche deve contenere il riferimento all'ambiente del Cliente, in mancanza del quale è rifiutata, e l'appartenenza dell'utente a quell'ambiente è verificata. Ai profili non amministrativi sono rimossi dai risultati i campi tecnici che potrebbero contenere frammenti di contenuto.

3.8 Rivenditori. I privilegi attribuiti a un rivenditore operano soltanto sulle risorse legate al rivenditore da una relazione esplicita registrata nel sistema. La qualifica di rivenditore è modificabile dal solo amministratore di piattaforma e la modifica è registrata nel registro di audit.

4. Cifratura

4.1 Cifratura dei dati in transito

• a) Tutte le comunicazioni fra i client e la piattaforma avvengono su canale cifrato con protocollo TLS, con reindirizzamento obbligatorio del traffico non cifrato al di fuori degli ambienti di sviluppo.
• b) I metadati del sistema di identità sono recuperati esclusivamente su canale cifrato.
• c) I collegamenti temporanei con cui sono resi disponibili i file sono emessi in sola lettura, esclusivamente su canale cifrato, con scadenza non superiore a un'ora.
• d) Le connessioni ai server di posta in entrata e in uscita configurati dal Cliente avvengono su canale cifrato, con negoziazione protetta.
• e) La posta consultata dall'applicazione per dispositivi mobili è trasmessa esclusivamente su canale cifrato con verifica del certificato del server, senza alcuna deroga: un certificato non valido comporta il rifiuto della connessione.
• f) La politica di accesso da origini diverse non consente la trasmissione di credenziali di sessione, di modo che nessun cookie possa essere inviato da un'origine terza.

4.2 Cifratura applicativa dei dati a riposo

• a) Il Fornitore applica una cifratura applicativa con algoritmo AES a 256 bit in modalità GCM, con involucro versionato, vettore di inizializzazione casuale e tag di autenticazione. Una chiave di lunghezza non conforme è rifiutata all'uso e una decifratura non riuscita genera un errore senza mai restituire il dato.
• b) Sono protetti con tale cifratura: le credenziali e le chiavi di accesso ai servizi configurati dal Cliente, le credenziali delle caselle di posta e dei flussi di lavoro, i segreti di firma dei canali e dei webhook, le credenziali e i token dei connettori attivati dal Cliente, le stringhe di connessione agli archivi documentali del Cliente, nonché le trascrizioni, gli elenchi dei partecipanti e i risultati delle riunioni elaborate dall'applicazione per dispositivi mobili.
• c) Precisazione di trasparenza. La cifratura applicativa di cui alla lettera b) non si estende ai contenuti delle conversazioni di chat né ai documenti caricati nelle librerie di conoscenza, che sono protetti dai controlli di accesso descritti nelle sezioni 2 e 3 e dalla cifratura a riposo dell'archiviazione sottostante di cui al comma 4.3.

4.3 Cifratura a riposo dell'infrastruttura

La cifratura a riposo dei supporti di archiviazione è fornita dai fornitori di infrastruttura secondo le loro condizioni di servizio. Il Fornitore non dichiara tale misura come da sé verificata e non la assume come proprio impegno contrattuale fino all'acquisizione dell'attestazione scritta del fornitore di infrastruttura cloud e del fornitore del server dedicato.

4.4 Copie di sicurezza

Le copie di sicurezza dei Dipendenti digitali sono cifrate presso l'origine, prima della trasmissione all'archivio remoto: senza la chiave di cifratura le copie non sono utilizzabili.

5. Gestione dei segreti

5.1 Archivio centralizzato. Le credenziali e i segreti necessari all'erogazione del Servizio sono conservati in un archivio dedicato, organizzato per ambiti separati, con il valore cifrato al momento della scrittura secondo il comma 4.2.

5.2 Chiave principale. La chiave principale di cifratura è unica, non risiede nel codice sorgente né nei file di configurazione versionati ed è custodita nell'archivio delle chiavi del fornitore di infrastruttura cloud, da cui è resa disponibile all'applicazione come impostazione protetta.

5.3 Risoluzione al momento dell'uso. I segreti sono risolti soltanto nel momento in cui servono e con comportamento fail-closed: un riferimento che non si risolve genera un errore e non produce mai un valore vuoto. Le configurazioni trasmesse ai Dipendenti digitali contengono esclusivamente riferimenti ai segreti, mai i valori.

5.4 Non restituibilità. I valori dei segreti non sono mai restituiti dalle interfacce di programmazione della piattaforma: l'esclusione è imposta per costruzione dal serializzatore delle risposte e non dipende dal singolo sviluppatore. L'archivio dei segreti a disposizione del Cliente è a sola scrittura: i valori immessi non sono più rileggibili.

5.5 Registri. I valori dei segreti sono oscurati nei registri tecnici, anche quando risolti al momento dell'uso, e non compaiono nei registri di avvio dei Dipendenti digitali.

6. Registrazione e monitoraggio

6.1 Registro di audit delle operazioni amministrative. Il Fornitore mantiene un registro delle operazioni amministrative che riporta per ciascuna operazione: data e ora, autore reale, eventuale soggetto che ha operato per conto di un utente, ambiente e organizzazione interessati, categoria e tipo di azione, oggetto interessato, dettagli e indirizzo di provenienza. Sono coperte, fra le altre, le operazioni su ruoli e permessi, utenti e appartenenze, crediti e quote, domini e gruppi, concessioni sulle risorse e segnalazioni di assistenza, nonché gli accessi per conto di un utente.

6.2 Accesso al registro. La consultazione del registro è protetta da permesso dedicato. La vista riferita a un singolo Cliente è sempre filtrata sull'ambiente di quel Cliente.

6.3 Conservazione. Le voci del registro di audit sono conservate per 24 mesi e quindi cancellate automaticamente.

6.4 Precisazione di trasparenza. Il registro di audit copre le operazioni amministrative e di configurazione. Il Fornitore non dichiara un registro immutabile né un registro degli accessi ai contenuti dei Clienti.

6.5 Osservabilità. La piattaforma produce tracce, metriche e registri tecnici con un sistema di osservabilità, arricchiti con il riferimento all'ambiente del Cliente. L'accesso è soggetto ai controlli del comma 3.7.

6.6 Contenuti esclusi dai registri. Le regole di scrittura del codice vietano la registrazione di segreti, token e contenuti estesi degli utenti, e sono presidiate dalla revisione delle modifiche.

6.7 Allarmi operativi. Il Fornitore mantiene allarmi automatici sugli eventi rilevanti per la continuità e per la sicurezza, tra cui l'esito negativo delle verifiche periodiche di ripristino e il riavvio ripetuto dei servizi, con notifica a una casella presidiata.

6.8 Pagina di stato pubblica. Il Fornitore pubblica una pagina di stato del Servizio, alimentata da sonde interne e verso i fornitori a monte, con notifiche per posta elettronica, canale di sottoscrizione e avvisi interni. Per scelta di sicurezza la pagina non espone il nome né il numero dei Dipendenti digitali dei Clienti.

7. Copie di sicurezza e continuità

7.1 Ambiente dei Dipendenti digitali

7.1.1 Versioni. L'archivio a oggetti che ospita le copie mantiene le versioni non correnti per 30 giorni, a protezione dalle cancellazioni accidentali.

7.1.2 Verifica automatica. Una verifica automatica eseguita ogni 6 ore effettua un ripristino reale di un Dipendente digitale a rotazione a partire dall'archivio remoto e confronta le impronte crittografiche dei dati ripristinati. L'esito negativo genera un allarme; a cadenza regolare è generata comunque una conferma di funzionamento della verifica stessa.

7.1.3 Prova di ripristino. L'ultima prova di ripristino reale, condotta con perdita simulata dei volumi, è stata superata il 10 luglio 2026, con tempo di ripristino misurato di circa 15 minuti, identità dei dati ripristinati verificata per impronta crittografica e servizio riattivato al primo tentativo.

7.1.4 Perimetro. Non rientrano nel perimetro delle copie di sicurezza, per scelta documentata, le registrazioni delle riunioni acquisite tramite partecipante automatico, il codice applicativo e le cache degli spazi di lavoro.

7.2 Ambiente della piattaforma cloud

Le copie di sicurezza del database e dell'archivio dei file della piattaforma cloud sono quelle previste dai servizi gestiti del fornitore di infrastruttura. Il Fornitore non dichiara, alla data del presente Allegato, obiettivi di tempo di ripristino e di perdita massima di dati per tale ambiente: gli obiettivi saranno dichiarati e assunti come impegno quando la relativa configurazione sarà verificata e documentata.

8. Conservazione e cancellazione dei dati

8.1 Cancellazioni automatiche. Il Fornitore esegue le seguenti cancellazioni o anonimizzazioni automatiche:

8.2 Conversazioni vocali. La conservazione delle conversazioni vocali è configurabile dal Cliente per ciascun agente. Una elaborazione notturna applica un doppio criterio, considerando sia la scadenza comunicata dal fornitore vocale per la singola conversazione sia il termine configurato dal Cliente, e applica il primo dei due che scade. La cancellazione comporta la rimozione effettiva del file audio dall'archivio e l'azzeramento della trascrizione, del riassunto, dell'analisi, del numero di telefono del chiamante e del riferimento all'audio, con nuovo tentativo in caso di errore. Resta una riga tecnica residua priva di dati personali, conservata al solo fine di evitare duplicazioni in fase di importazione e di dimostrare l'avvenuta dichiarazione di natura artificiale.

8.3 Modalità senza conservazione. Il Cliente può attivare una modalità in cui la conversazione vocale è registrata priva di contenuto sin dal momento dell'acquisizione.

8.4 Cancellazione su azione del Cliente. La cancellazione di un documento comporta la rimozione del file dall'archivio, la rimozione dei relativi indici di ricerca e la cancellazione logica del record. La cancellazione di una libreria comporta la cancellazione dei documenti che contiene. La cancellazione di un Utente comporta la cancellazione logica nella piattaforma e la cancellazione effettiva sul sistema di identità, con registrazione nel registro di audit.

8.5 Precisazione di trasparenza. Per le conversazioni di chat e per i documenti delle librerie di conoscenza non è previsto un termine automatico di cancellazione: essi sono conservati per la durata del Contratto, sono cancellabili su azione del Cliente secondo il comma 8.4 e sono cancellati al termine del Contratto secondo l'art. 10 dell'Allegato A.

8.6 Cancellazione al termine del Contratto. Si applica integralmente l'art. 10 dell'Allegato A, che disciplina la scelta fra restituzione e cancellazione, i termini di 60 e 90 giorni e il blocco dell'accesso nel periodo intermedio.

9. Sviluppo sicuro

9.1 Rami protetti e revisione. I rami principali del codice accettano modifiche esclusivamente mediante richiesta di integrazione sottoposta a revisione. Non è consentita la scrittura diretta.

9.2 Verifiche automatiche. A ogni richiesta di integrazione l'integrazione continua esegue il ripristino delle dipendenze, la compilazione in configurazione di rilascio e l'esecuzione della suite di prove, con privilegi minimi assegnati all'esecutore. Un controllo dedicato impedisce l'integrazione di modifiche prive della documentazione dell'impatto per l'utente.

9.3 Rilascio senza credenziali statiche. Il rilascio in produzione avviene mediante identità federata verso il fornitore di infrastruttura, senza credenziali statiche memorizzate nel sistema di integrazione continua. La nuova versione è pubblicata su un ambiente di prova e promossa in produzione soltanto dopo la verifica, con possibilità di ritorno immediato alla versione precedente.

9.4 Regole di codifica presidiate da strumenti automatici. Il Fornitore utilizza strumenti di analisi statica propri che vietano la gestione generica delle eccezioni nei servizi, vietano la soppressione silenziosa degli errori e impongono la protezione delle chiamate rischiose. La costruzione manuale delle risposte di errore è impedita in fase di compilazione.

9.5 Prove di sicurezza anti-regressione. La suite comprende prove dedicate su: copertura del controllo dei permessi su ogni interfaccia, impossibilità di accedere a risorse di altri Clienti, elenco delle operazioni negate alle chiavi applicative, visualizzazione unica delle chiavi, limitazione delle chiavi ai singoli Dipendenti digitali, cifratura dei dati a riposo, conservazione e cancellazione delle conversazioni vocali, verifica delle firme dei webhook, protezione contro le richieste verso risorse di rete interne, uso della estensione a prova di chiave e dello stato firmato nelle autorizzazioni, isolamento dell'esecuzione degli script e funzioni di pseudonimizzazione.

9.6 Esecuzione isolata degli script. Gli script definiti dal Cliente negli automatismi sono eseguiti in un ambiente isolato, privo di accesso a risorse esterne e limitato per profondità di ricorsione, memoria, tempo, numero di istruzioni e durata delle espressioni di ricerca.

9.7 Contratto di errore. Le risposte di errore restituite ai client non contengono tracce di esecuzione né dettagli interni: sono restituite in formato normalizzato con un identificativo di correlazione utile all'assistenza.

9.8 Precisazione di trasparenza. Il Fornitore non dichiara, alla data del presente Allegato, l'esecuzione automatica in integrazione continua di analisi delle vulnerabilità delle dipendenze, di scansione dei segreti o di analisi statica di sicurezza del codice di terze parti.

10. Protezione da abusi e da usi impropri

10.1 Limitazione della frequenza delle richieste. Le interfacce applicative sono protette da limiti di frequenza, con risposta normalizzata e indicazione del tempo di attesa. Sono previste politiche distinte per il widget di chat con limite istantaneo e budget giornaliero per Cliente, per l'utente autenticato e per il traffico anonimo, nonché regole configurabili per singolo percorso e per singolo Cliente.

10.2 Limiti di elaborazione. I lavori in esecuzione differita sono soggetti a un limite di concorrenza per Cliente, non superabile. Il consumo del Servizio è soggetto a quota, con comportamento fail-closed al superamento.

10.3 Validazione dell'origine del widget. Il widget di chat accetta richieste soltanto da origini dichiarate e verificate. L'assenza dell'origine comporta il rifiuto.

10.4 Integrità delle comunicazioni in ingresso. Tutti i webhook ricevuti dai fornitori esterni sono soggetti a verifica della firma, con confronto a tempo costante. Per il canale vocale la verifica comprende il rifiuto in mancanza del segreto e una protezione contro il riuso della stessa richiesta basata sul riferimento temporale.

10.5 Comunicazioni in uscita. I webhook inviati verso i sistemi del Cliente sono firmati, in modo che il destinatario possa verificarne l'autenticità.

10.6 Protezione contro le richieste verso risorse interne. Gli indirizzi che la piattaforma contatta su richiesta del Cliente sono sottoposti a un controllo che rifiuta la richiesta quando anche un solo indirizzo risolto appartiene a spazi riservati, interni o di servizio dell'infrastruttura. Il controllo è ripetuto a ogni nuovo tentativo di invio.

11. Strumenti di tutela a disposizione del Cliente

11.1 Area di residenza dei dati vocali. La selezione dell'area europea del fornitore vocale, con effetto sulle chiamate e sulle trascrizioni del proprio ambiente, è disponibile per i Clienti del Piano Enterprise; per gli altri piani si applica l'area globale. Per gli abbonamenti vocali condivisi messi a disposizione dal Fornitore si applica in ogni caso l'area globale. Le funzioni riservate al Piano Enterprise sono disponibili ove previste nella proposta commerciale accettata dal Fornitore, secondo l'art. 2.3 dei Termini; i piani sono descritti nel listino pubblicato all'indirizzo https://evolus.ai/it/prezzi.

11.2 Instradamento delle richieste ai modelli e limitazione dei fornitori. Sono disponibili per i Clienti del Piano Enterprise, ove previste nella proposta commerciale accettata dal Fornitore secondo l'art. 2.3 dei Termini: la definizione dell'elenco dei fornitori di inferenza ammessi per il proprio ambiente, che è applicata dal sistema e prevale sulle preferenze impostate a livello di singola funzione; l'instradamento europeo delle richieste ai modelli, mediante l'endpoint dell'Unione europea del servizio di instradamento; l'instradamento sui soli endpoint a conservazione zero. Per gli altri piani si applicano l'instradamento globale e i fornitori di inferenza dell'elenco pubblicato nella pagina dei sub-responsabili, all'indirizzo https://evolus.ai/it/sub-responsabili.

11.3 Conservazione delle conversazioni vocali. Per tutti i piani il Cliente può configurare il termine di conservazione per ciascun agente vocale e può attivare la modalità senza conservazione, secondo i commi 8.2 e 8.3.

11.4 Pseudonimizzazione e oscuramento. La piattaforma mette a disposizione funzioni di pseudonimizzazione dei dati personali e di oscuramento dei documenti. L'oscuramento dei documenti in formato PDF è realizzato mediante rasterizzazione, di modo che il testo oscurato non sia più presente nel file prodotto. Un blocco di pseudonimizzazione è utilizzabile all'interno degli automatismi definiti dal Cliente.

11.5 Protezioni non disattivabili. I Dipendenti digitali applicano protezioni che non possono essere disattivate dal Cliente né aggirate mediante istruzioni, in materia di conferma esplicita dell'utente prima delle azioni rilevanti, verifica dell'identità del destinatario, verifica dell'autenticità del mittente e dichiarazione di natura artificiale. Il canale vocale applica inoltre un insieme di regole non disattivabili a tutela dei dati personali dei dipendenti, delle comunicazioni interne, dei dati economici e delle opinioni.

11.6 Dichiarazione di natura artificiale. La dichiarazione di natura artificiale è riapplicata dal sistema sulle comunicazioni in uscita, non è rimovibile dal Cliente e la relativa prova è conservata. Il Fornitore esegue una verifica periodica di conformità sulle comunicazioni generate.

11.7 Applicazione per dispositivi mobili. L'audio dei messaggi vocali non è conservato sui sistemi del Fornitore oltre l'elaborazione, restando la sola misurazione della durata ai fini del consumo. L'audio delle riunioni registrato sul dispositivo è collocato in un'area esclusa dalle copie di sicurezza di sistema. L'accesso alla fotocamera è escluso dai permessi dell'applicazione. Le richieste di permesso dichiarano espressamente all'utente che il contenuto transita dai sistemi del Fornitore e dal fornitore di intelligenza artificiale.

12. Fornitori e sub-responsabili

12.1 Selezione. Il Fornitore seleziona i sub-responsabili sulla base delle garanzie offerte in materia di protezione dei dati e di sicurezza delle informazioni, e stipula con ciascuno un accordo sul trattamento dei dati con obblighi non meno onerosi di quelli assunti verso il Cliente.

12.2 Elenco pubblico. L'elenco dei sub-responsabili è pubblicato in forma versionata all'indirizzo https://evolus.ai/it/sub-responsabili, con indicazione dell'attività svolta, del Paese di stabilimento e della base giuridica del trasferimento, ove applicabile.

12.3 Variazioni. Le aggiunte e le sostituzioni sono comunicate al Cliente con un preavviso di almeno 30 giorni, con diritto di opposizione motivata, secondo l'art. 5 dell'Allegato A.

12.4 Trasferimenti. Le basi giuridiche dei trasferimenti verso Paesi terzi e le funzioni di riduzione dei trasferimenti riservate al Piano Enterprise sono disciplinate dall'art. 6 dell'Allegato A.

13. Gestione degli incidenti e delle violazioni di dati personali

13.1 Procedura documentata. Il Fornitore mantiene una procedura documentata di gestione delle violazioni di dati personali, che definisce i canali di rilevazione e di segnalazione, i ruoli e le responsabilità, le fasi operative con i relativi termini, i criteri di valutazione del rischio per gli interessati, i modelli di comunicazione e le regole di chiusura, di analisi delle cause e di verifica delle azioni correttive.

13.2 Segnalazione interna. Ogni persona che opera per il Fornitore è tenuta a segnalare senza ritardo, e comunque entro un'ora, ogni evento sospetto, attraverso i canali dedicati e senza svolgere analisi preliminari, con divieto di alterare o distruggere le evidenze.

13.3 Contenimento e conservazione delle evidenze. La procedura prevede misure tipizzate di contenimento, tra cui la revoca delle sessioni e delle autorizzazioni, il blocco degli account, l'isolamento del contenitore interessato, la sospensione della singola funzione, la rotazione dei segreti, la revoca dei collegamenti temporanei ai file e il blocco delle comunicazioni in uscita, nonché il congelamento e l'estrazione delle evidenze con verifica di integrità.

13.4 Notifica al Cliente. Il Fornitore notifica al Cliente ogni violazione che riguardi i suoi dati entro 48 ore dal momento in cui ne viene a conoscenza, a prescindere dal livello di rischio, con il contenuto previsto dall'art. 33, paragrafo 3, del Regolamento, e trasmette aggiornamenti periodici fino alla chiusura del caso, secondo l'art. 9 dell'Allegato A.

13.5 Registro delle violazioni. Il Fornitore tiene un registro delle violazioni di dati personali che documenta le circostanze, gli effetti, i provvedimenti adottati, le decisioni sulle notifiche e le relative motivazioni, comprese le quasi violazioni intercettate prima di produrre effetti.

13.6 Riesame e prova. La procedura è riesaminata almeno annualmente e dopo ogni violazione classificata a rischio medio o alto, ed è sottoposta a una prova di simulazione con cadenza annuale.

14. Personale

14.1 Riservatezza. Le persone autorizzate al trattamento dei dati dei Clienti hanno sottoscritto accordi di riservatezza, il cui obbligo permane dopo la cessazione del rapporto.

14.2 Autorizzazione e istruzioni. L'autorizzazione al trattamento è attribuita alle sole persone che ne hanno necessità per l'erogazione del Servizio, per l'assistenza, per la manutenzione e per la sicurezza, con istruzioni scritte sulle modalità del trattamento.

14.3 Accesso ai dati dei Clienti. L'accesso del personale ai dati dei Clienti avviene mediante gli strumenti della piattaforma, è soggetto ai controlli della sezione 2 ed è registrato secondo il comma 2.8 e la sezione 6.

14.4 Formazione. Un programma di formazione del personale in materia di protezione dei dati personali e di sicurezza delle informazioni è in corso di adozione nell'ambito del sistema di gestione di cui al comma 1.3. Il Fornitore non dichiara, alla data del presente Allegato, formazione già erogata.

15. Revisione del presente Allegato

15.1 Aggiornamento. Il Fornitore può aggiornare il presente Allegato per riflettere l'evoluzione tecnica e organizzativa delle misure, purché il livello complessivo di sicurezza non sia ridotto, ai sensi dell'art. 12.5 dei Termini.

15.2 Versionamento. Ogni versione è identificata da un codice e da un'impronta informatica SHA-256 del testo. Le versioni precedenti restano accessibili al Cliente per tutta la durata del Contratto.

15.3 Comunicazione. Gli aggiornamenti sono comunicati con le modalità e i preavvisi dell'art. 13 dei Termini. Gli aggiornamenti che comportino una riduzione delle garanzie danno diritto al recesso senza penali secondo l'art. 13.2 dei Termini.

15.4 Riesame periodico. Il Fornitore riesamina le misure con la cadenza del comma 1.4 e aggiorna il presente Allegato in caso di variazione sostanziale.