Sicurezza da verificare, non solo di cui fidarsi.

All'interno della piattaforma, il confine PII sostituisce con pseudonimi coerenti i nomi di dipendenti, manager e firmatari, i nomi di datori di lavoro e aziende, le date, gli indirizzi e-mail di lavoro e gli ID dei dipendenti prima che una richiesta raggiunga l'engine, e li ripristina nella risposta. Si applica alle chiamate all'engine della piattaforma HR, del lifecycle worker, di ZeugnyAI Chat (che raggiunge l'engine solo tramite la piattaforma) e del gateway Word.

Una richiesta viene rifiutata, non inviata, quando mancano la chiave di cifratura o l'ambito del documento, quando a una persona o a un datore di lavoro noti non è assegnato alcuno pseudonimo, quando una parte di un nome è ambigua tra due persone o quando non è possibile scrivere la voce di audit.

Luogo di nascita, nazionalità, denominazioni di funzione, reparti, descrizione dell'azienda e testo dei compiti vengono inviati come inseriti; il testo ne ha bisogno per la maggior parte. I nomi digitati nel testo libero vengono sostituiti solo se corrispondono a una persona o a un datore di lavoro noti. Una modalità più rigorosa che trattiene per la verifica umana il testo libero non riconosciuto è sviluppata; la sua attivazione nel Cloud gestito è pianificata.

Per ogni certificato, HR può aprire ogni passaggio da e verso l'engine: ora, direzione, numero di elementi sostituiti per categoria, SHA-256 del payload e pseudonimi utilizzati. I valori reali non vengono mai mostrati. La vista può essere esportata in formato CSV.

Database, backup, archiviazione dei file, key vault, log e server applicativi del Cloud gestito operano in Microsoft Azure Switzerland North (Zurigo). Backup e archiviazione dei file sono replicati in una seconda regione svizzera, Switzerland West. app.zeugny.com si risolve direttamente su Zurigo, senza alcuna content delivery network intermedia. L'indirizzo IP di chi firma viene conservato come prova di firma e non viene inviato ad alcun servizio di geolocalizzazione di terze parti; il Paese viene letto da un header impostato al margine della rete (edge).

Tutte le app accettano solo HTTPS, con TLS 1.2 come minimo; in pratica viene negoziato TLS 1.3. Il server del database accetta solo connessioni TLS, con TLS 1.2 come minimo, e le connessioni al database della piattaforma richiedono TLS.

Azure cifra a riposo il database, i backup e l'archiviazione dei file. In aggiunta, la piattaforma cifra le mappature degli pseudonimi e le chiavi API dell'engine con AES-256-GCM, con chiavi master custodite in Azure Key Vault. Gli altri record si affidano alla cifratura di Azure.

Trascorso il periodo di conservazione (per impostazione predefinita 10 anni dopo la fine del rapporto di lavoro), un processo orario oscura nome, indirizzo e-mail, data e luogo di nascita e nazionalità di un ex dipendente, cancella le bozze ed elimina le mappature degli pseudonimi. Le assegnazioni di funzione, l'audit trail e i certificati emessi vengono conservati; i certificati emessi contengono ancora il nome. Su richiesta impostiamo per la Sua azienda un periodo diverso; la configurazione self-service è pianificata.

I dipendenti presentano da sé le richieste di accesso e di cancellazione in «Privacy» e HR segue ciascuna con un termine di 30 giorni. La cancellazione oscura i dati del dipendente, rimuove le voci del vault e le condivisioni e rilascia una ricevuta. Una richiesta di accesso produce un riepilogo; una copia scaricabile dei dati è pianificata.

I responsabili HR possono applicare un legal hold a un rapporto di lavoro e a tutti i relativi certificati, il che sospende l'eliminazione. I dipendenti possono contestare un certificato; una contestazione accolta produce una nuova versione e la cronologia resta nell'audit trail.

La piattaforma può distruggere la chiave di pseudonimizzazione di un'azienda, rendendo illeggibili le mappature da essa conservate. La funzione è sviluppata e testata; renderla disponibile come azione dell'operatore è pianificato. Le copie nei backup scadono secondo la normale pianificazione dei backup.

Il testo dei certificati viene scritto da modelli su Microsoft Azure AI Foundry, su una risorsa in Switzerland North con un deployment EU Data Zone Standard, per cui le richieste vengono elaborate all’interno della zona dati dell’UE. I passaggi di decisione, estrazione e recupero utilizzano inoltre Microsoft Decision-1 (una risorsa Azure AI Foundry in Sweden Central con un deployment EU Data Zone Standard), OpenRouter e Voyage AI, e la piattaforma utilizza OpenRouter direttamente per suggerire denominazioni di funzione e compiti. I fornitori ricevono esclusivamente testo pseudonimizzato. Ogni richiesta che l'engine invia a OpenRouter richiede fornitori che non raccolgono dati degli utenti, senza alcuna impostazione per disattivare questo requisito. L'instradamento con zero data retention è pianificato.

Le password sono sottoposte a hash con scrypt e richiedono almeno 8 caratteri. Gli indirizzi e-mail vengono verificati prima del primo accesso con password e i magic link senza password scadono dopo 5 minuti. I tentativi di accesso sono soggetti a un limite di frequenza per indirizzo IP.

Le sessioni sono memorizzate sul server e possono essere revocate. I cookie di sessione sono HttpOnly, Secure e SameSite=Lax e scadono dopo 7 giorni. Un account disattivato viene rifiutato alla richiesta successiva.

Con il single sign-on, l'MFA del Suo identity provider si applica a ogni accesso. Gli account del personale nel nostro control plane richiedono un secondo fattore (codice di autenticazione o codice di backup) a ogni sessione e senza di esso non viene rilasciato alcun accesso operatore all'engine. È pianificato un secondo fattore integrato per l'accesso con password dei clienti.

Single sign-on per azienda con OIDC o SAML, domini verificati tramite DNS, mappatura da gruppo a ruolo e una modalità opzionale solo SSO. È attivo nel Cloud gestito e collegiamo su richiesta il Suo identity provider. SCIM 2.0 crea e disattiva gli utenti e termina le loro sessioni; un utente di cui viene effettuato il provisioning senza ruolo riceve il ruolo HR con meno privilegi (coordinatore HR) e gli endpoint SCIM sono soggetti a limiti di frequenza. Self-Hosted si collega a qualsiasi provider OIDC.

Ogni route verifica i permessi basati sulle relazioni. I coordinatori HR possono redigere bozze ma non possono finalizzare, applicare un override a un riscontro, firmare né scaricare il documento ufficiale. Le rappresentanze dei lavoratori vedono solo dati aggregati; i manager vedono i propri collaboratori diretti.

Nel Cloud gestito le aziende condividono un unico database svizzero. L'applicazione limita ogni richiesta a una sola azienda e verifica i permessi su ogni oggetto. Self-Hosted assegna a ogni cliente un proprio database. L'imposizione a livello di riga nel database è pianificata come secondo livello.

Le persone senza account, come un manager che esprime una valutazione, un revisore di bozze o il dipendente che ritira un certificato, ricevono link che concedono l'accesso a un solo oggetto, scadono e possono essere revocati. La piattaforma memorizza solo un hash SHA-256 del token di ciascun link.

Gli account del personale vengono creati solo su invito e richiedono il ruolo di amministratore; ogni azione nel control plane richiede un proprio permesso. Ogni sessione del personale deve superare un secondo fattore (codice di autenticazione o codice di backup) prima di poter usare il control plane e senza di esso non viene rilasciato alcun accesso operatore all'engine. Il personale non può impersonare gli utenti: gli endpoint di impersonation dell'amministrazione sono disattivati. Le modifiche ad aziende, chiavi dell'engine e personale vengono registrate.

L'accesso e l'invio dei moduli vengono controllati rispetto all'origine della richiesta e i cookie di sessione sono SameSite=Lax.

Le quattro app web (app, control plane, chat e sito web) inviano HSTS, una Content-Security-Policy con un nonce per risposta, la protezione dai frame (X-Frame-Options DENY e frame-ancestors none), X-Content-Type-Options nosniff e una referrer policy. Le pagine sensibili inviano inoltre gli header no-store e no-referrer.

L'accesso è soggetto a un limite di frequenza per indirizzo IP. Ogni pagina pubblica con link, comprese le pagine pubbliche di verifica raggiungibili tramite il codice QR, consente 60 richieste al minuto per client, e gli endpoint SCIM consentono 600 richieste al minuto per azienda e client.

Ogni azienda ha una propria chiave dell'engine con un limite di frequenza delle richieste; può essere ruotata e revocata. L'engine ne memorizza solo un hash SHA-256 e la piattaforma la memorizza cifrata con AES-256-GCM. I risultati sono leggibili solo dalla chiave o dall'azienda che li ha creati.

Le scansioni caricate di certificati cartacei firmati devono essere in formato PDF, PNG o JPEG, fino a 10 MB, e il contenuto del file deve corrispondere al tipo dichiarato.

I segreti di produzione risiedono in Azure Key Vault con accesso basato sui ruoli e soft delete e arrivano alle app come riferimenti a Key Vault. Nessuno è memorizzato nel codice sorgente e la produzione si rifiuta di avviarsi senza le proprie chiavi.

La produzione gira su servizi gestiti: container Azure App Service e Azure Database for PostgreSQL per la piattaforma, Cloudflare Workers per l'engine. Non vi sono macchine virtuali proprie da mantenere.

Le app raggiungono il database tramite un private endpoint. Il database dispone anche di un endpoint pubblico. L'elenco di indirizzi consentiti del suo firewall contiene gli intervalli di indirizzi di Cloudflare, affinché i Cloudflare Workers, engine incluso, possano connettersi tramite Hyperdrive. Durante migrazioni, deployment e backup, una regola temporanea ammette il runner CI che svolge il lavoro e viene rimossa al termine del job. TLS e password proteggono ogni connessione.

Le risorse Azure sono definite in template versionati e le impostazioni delle app provengono da file versionati che fanno riferimento a Key Vault.

Le notifiche vengono inviate da notifications.zeugny.com, che pubblica una policy DMARC di tipo reject; anche il dominio principale zeugny.com pubblica una policy DMARC di tipo quarantine. Le notifiche contengono l'indirizzo del destinatario, i nomi e un link. security@, privacy@ e hello@zeugny.com sono caselle monitorate.

Ogni fase del ciclo di vita e ogni modifica viene scritta in un registro di audit in cui ogni voce contiene l'hash della precedente, così una voce modificata interrompe la catena. La catena viene verificata all'apertura di un dossier o di una pagina di verifica e il dossier di ogni certificato può essere scaricato insieme alle sue voci di audit.

Ogni cinque minuti un monitor separato controlla lo stato di piattaforma, worker e control plane. Una volta al giorno esegue tramite l'engine un'analisi completa di un certificato fittizio. I test di disponibilità di Azure sorvegliano il monitor stesso da tre sedi europee, così l'interruzione di una delle due parti genera un avviso.

I log applicativi, HTTP e del database confluiscono in Azure Log Analytics in Switzerland North e vengono conservati per 30 giorni. I log delle richieste all'engine contengono solo metadati; i log di runtime dell'engine su Cloudflare possono contenere frammenti di testo pseudonimizzato.

Se un incidente riguarda i Suoi dati, informiamo il referente da Lei indicato senza ingiustificato ritardo dopo averlo confermato, comunicando che cosa è accaduto, quali dati sono interessati e che cosa stiamo facendo al riguardo. Un piano scritto di risposta agli incidenti è redatto e verrà pubblicato dopo la verifica legale; sono previste esercitazioni periodiche.

Il database può essere ripristinato a qualsiasi momento degli ultimi 35 giorni. Inoltre, un job pianificato esegue ogni notte il dump di tutti i database. Gira su un runner CI gestito da ZeugnyAI, che si connette via TLS, scrive ogni dump in un file temporaneo, lo carica in Azure Storage in Switzerland North ed elimina il file. Vengono conservati gli ultimi 30 dump di ciascun database e i dump eliminati restano recuperabili per altri 30 giorni. I backup archiviati, point-in-time e dump, si trovano in Switzerland North e sono replicati in Switzerland West, una seconda regione svizzera.

La procedura di ripristino è documentata. Ripristino testato il 9 novembre 2026: un ripristino point-in-time del database di produzione su un server temporaneo si è concluso in 7 minuti e il suo contenuto è stato verificato. Sono pianificati ulteriori test di ripristino a intervalli regolari.

Il Cloud gestito opera in Azure Switzerland North. I backup del database e l'archiviazione dei file sono replicati in una seconda regione svizzera, Switzerland West. Un ripristino del backup del database in Switzerland West è stato testato il 10 novembre 2026. È pianificato un database standby con failover automatico.

Ogni modifica sul branch main che supera i controlli viene distribuita in un ambiente di staging separato. Una release di produzione richiede uno smoke test superato in staging per lo stesso commit. L'engine raggiunge la produzione solo da commit che hanno superato i controlli: un job di CI porta il branch release al commit testato e Cloudflare distribuisce da quel branch.

Controlli dei tipi, test unitari e di integrazione e build di produzione vengono eseguiti per ogni modifica, e i test end-to-end per le modifiche che li riguardano. Le dipendenze vengono installate da un lockfile congelato.

Sviluppo, staging e produzione utilizzano database, chiavi e key vault separati. I test non utilizzano mai dati o credenziali di produzione.

Le release di produzione superano controlli automatici. La pipeline di produzione dell'engine distribuisce solo da un branch release, che la CI porta su un commit dopo che i test su main sono stati superati per quel commit. La pipeline di produzione della piattaforma viene eseguita solo per commit su main con un'esecuzione CI riuscita e solo dopo un'esecuzione di accettazione nell'ambiente di staging. I clienti Self-Hosted possono esaminare ogni modifica nel proprio repository. È pianificata una revisione indipendente imposta per ogni modifica.

Gli snapshot del codice sorgente per i clienti vengono controllati prima della release alla ricerca di stringhe che hanno l'aspetto di segreti e di percorsi vietati. Gli avvisi sulle vulnerabilità delle dipendenze (Dependabot) sono attivi sui repository della piattaforma e dell'engine. Sono pianificate la scansione del codice e la scansione dei segreti del repository.

I clienti Self-Hosted ricevono, come repository privato, uno snapshot della piattaforma selezionato tramite allowlist e costruiscono autonomamente i container. Gli strumenti interni sono esclusi e una release si interrompe se vengono rilevati percorsi vietati o stringhe che hanno l'aspetto di segreti.

L'accesso di produzione è limitato ad amministratori designati nominativamente, solo in base alla necessità. È pianificata una separazione formale dei compiti tra sviluppo e operazioni.

Ogni fornitore che tratta dati per il Cloud è elencato in questa pagina con la sua finalità, i dati che riceve e la sua ubicazione.

Un contratto standard sul trattamento dei dati ai sensi della LPD e del RGPD è redatto e verrà pubblicato dopo la verifica legale. Fino ad allora esaminiamo e firmiamo il Suo.

Le policy formali scritte per sicurezza delle informazioni, controllo degli accessi, risposta agli incidenti e fornitori sono redatte e verranno pubblicate dopo la verifica legale. Questa pagina descrive la prassi attuale.

È pianificato un penetration test esterno. I clienti Self-Hosted sono invitati a testare la propria installazione in qualsiasi momento; per il Cloud gestito concordiamo con Lei ambito e tempistiche.