Sicherheit, die Sie nachprüfen können, statt ihr nur zu vertrauen.

Innerhalb der Plattform ersetzt die PII-Grenze die Namen von Mitarbeitenden, Führungskräften und Unterzeichnenden, Arbeitgeber- und Firmennamen, Daten, geschäftliche E-Mail-Adressen und Mitarbeiter-IDs durch konsistente Pseudonyme, bevor eine Anfrage die Engine erreicht, und stellt sie in der Antwort wieder her. Sie umschliesst die Engine-Aufrufe der HR-Plattform, des Lifecycle-Workers, von ZeugnyAI Chat (das die Engine nur über die Plattform erreicht) und des Word-Gateways.

Eine Anfrage wird abgelehnt statt gesendet, wenn der Verschlüsselungsschlüssel oder der Dokumentumfang fehlt, einer bekannten Person oder einem bekannten Arbeitgeber kein Pseudonym zugeordnet ist, ein Namensteil zwischen zwei Personen mehrdeutig ist oder der Audit-Eintrag nicht geschrieben werden kann.

Geburtsort, Nationalität, Berufsbezeichnungen, Abteilungen, die Unternehmensbeschreibung und Aufgabentexte werden wie eingegeben gesendet; der Text braucht die meisten davon. In Freitext eingegebene Namen werden nur ersetzt, wenn sie zu einer bekannten Person oder einem bekannten Arbeitgeber passen. Ein strengerer Modus, der nicht erkannten Freitext zur Prüfung durch Menschen zurückhält, ist gebaut; seine Aktivierung in der Managed Cloud ist geplant.

Zu jedem Zeugnis kann HR jeden Übergang zur und von der Engine öffnen: Zeit, Richtung, die Anzahl ersetzter Elemente je Kategorie, den SHA-256-Hash der Nutzdaten und die verwendeten Pseudonyme. Echte Werte werden dort nie angezeigt. Die Ansicht lässt sich als CSV exportieren.

Datenbank, Backups, Dateispeicher, Key Vault, Logs und Anwendungsserver der Managed Cloud laufen in Microsoft Azure Switzerland North (Zürich). Backups und Dateispeicher werden in eine zweite Schweizer Region, Switzerland West, repliziert. app.zeugny.com wird direkt nach Zürich aufgelöst, ohne zwischengeschaltetes Content-Delivery-Network. Die IP-Adresse einer unterzeichnenden Person wird als Unterzeichnungsnachweis gespeichert und an keinen Geolokalisierungsdienst Dritter gesendet; das Land wird aus einem Header gelesen, der am Netzwerkrand (Edge) gesetzt wird.

Alle Apps akzeptieren nur HTTPS, mindestens mit TLS 1.2; in der Praxis wird TLS 1.3 ausgehandelt. Der Datenbankserver akzeptiert nur TLS-Verbindungen, mindestens mit TLS 1.2, und die Datenbankverbindungen der Plattform fordern TLS an.

Azure verschlüsselt Datenbank, Backups und Dateispeicher im Ruhezustand. Zusätzlich verschlüsselt die Plattform Pseudonym-Zuordnungen und Engine-API-Schlüssel mit AES-256-GCM unter Hauptschlüsseln, die im Azure Key Vault liegen. Andere Datensätze stützen sich auf die Verschlüsselung von Azure.

Nach Ablauf der Aufbewahrungsfrist (standardmässig 10 Jahre nach Ende des Arbeitsverhältnisses) schwärzt ein stündlicher Job Name, E-Mail-Adresse, Geburtsdatum und -ort sowie Nationalität eines ehemaligen Mitarbeitenden, löscht Entwürfe und entfernt die Pseudonym-Zuordnungen. Stellenzuordnungen, der Audit-Trail und ausgestellte Zeugnisse bleiben erhalten; ausgestellte Zeugnisse enthalten weiterhin den Namen. Auf Anfrage setzen wir für Ihr Unternehmen eine andere Frist; eine Konfiguration in Eigenregie ist geplant.

Mitarbeitende stellen Auskunfts- und Löschbegehren selbst unter «Datenschutz», und HR verfolgt jedes einzelne anhand einer Frist von 30 Tagen. Eine Löschung schwärzt die Daten der Person, entfernt Vault-Einträge und Freigaben und stellt eine Bestätigung aus. Ein Auskunftsbegehren erzeugt eine Zusammenfassung; eine herunterladbare Kopie der Daten ist geplant.

HR-Verantwortliche können für ein Arbeitsverhältnis und alle seine Zeugnisse eine Aufbewahrungssperre (Legal Hold) verhängen, die die Löschung aussetzt. Mitarbeitende können ein Zeugnis beanstanden; eine akzeptierte Beanstandung erzeugt eine neue Version, und der Verlauf bleibt im Audit-Trail.

Die Plattform kann den Pseudonymisierungsschlüssel eines Unternehmens vernichten, wodurch dessen gespeicherte Zuordnungen unlesbar werden. Die Funktion ist gebaut und getestet; sie als Betreiberaktion zur Verfügung zu stellen, ist geplant. Kopien in Backups laufen nach dem regulären Backup-Zeitplan ab.

Führungskräfte oder HR bewerten jeden Aspekt von Leistung und Verhalten. Die KI schreibt Text, der zu diesen Bewertungen passt, und kann sie nicht ändern. Das Gesamtniveau wird aus den Bewertungen berechnet und nicht vom Modell gewählt.

Jeder wertende Satz hält den Aspekt und die Bewertung fest, die er ausdrückt, und HR sieht dies im Editor, sodass sich jeder Satz auf die zugrunde liegende Bewertung zurückführen lässt.

Vor der Prüfung durch HR durchläuft jeder KI-Entwurf die Fairness-Analyse der Engine. Ein blockierender Befund hält das Zeugnis zurück, bis eine Änderung ihn behebt oder ein HR-Verantwortlicher ihn übersteuert; die Übersteuerung wird im Audit-Trail festgehalten. Arbeitsbestätigungen, die ohne KI aus einer Vorlage erstellt werden, überspringen diesen Schritt.

Kein Zeugnis gelangt ohne Prüfung und Finalisierung durch HR-Verantwortliche oder Administratoren zu Mitarbeitenden. Automatisierungen können Anfragen starten, aber nie finalisieren.

Wir verwenden Kundendaten weder zum Training noch zum Fine-Tuning noch zur Evaluation von Modellen, und Kundenanfragen gelangen nie in unseren Referenzkorpus.

Jedes Zeugnis nennt seine Rechtsordnung, Schweiz, Deutschland oder Österreich, ausdrücklich, statt sie aus dem Text zu erraten. Bisher wurden nur die Schweizer Regeln überprüft; Beurteilungen für Deutschland und Österreich sind als eingeschränkt gekennzeichnet.

Zeugnistext wird von Modellen auf Microsoft Azure AI Foundry geschrieben, auf einer Ressource in Switzerland North mit einer Bereitstellung als EU Data Zone Standard, sodass Anfragen innerhalb der EU-Datenzone verarbeitet werden. Entscheidungs-, Extraktions- und Retrieval-Schritte nutzen zudem Microsoft Decision-1 (eine Azure-AI-Foundry-Ressource in Sweden Central mit einer Bereitstellung als EU Data Zone Standard), OpenRouter und Voyage AI, und die Plattform nutzt OpenRouter direkt, um Berufsbezeichnungen und Aufgaben vorzuschlagen. Anbieter erhalten ausschliesslich pseudonymisierten Text. Jede Anfrage, die die Engine an OpenRouter sendet, verlangt Anbieter, die keine Nutzerdaten sammeln; eine Einstellung zum Abschalten gibt es nicht. Zero-Data-Retention-Routing ist geplant.

Passwörter werden mit scrypt gehasht und müssen mindestens 8 Zeichen lang sein. E-Mail-Adressen werden vor der ersten Passwort-Anmeldung verifiziert, und passwortlose Magic-Links laufen nach 5 Minuten ab. Anmeldeversuche sind pro IP-Adresse ratenbegrenzt.

Sitzungen werden auf dem Server gespeichert und können widerrufen werden. Sitzungs-Cookies sind HttpOnly, Secure und SameSite=Lax und laufen nach 7 Tagen ab. Ein deaktiviertes Konto wird bei seiner nächsten Anfrage abgewiesen.

Mit Single Sign-on gilt die MFA Ihres Identitätsanbieters für jede Anmeldung. Staff-Konten in unserer Control Plane benötigen für jede Sitzung einen zweiten Faktor (Authenticator-Code oder Backup-Code), und ohne ihn wird keine Engine-Operator-Anmeldung ausgestellt. Ein integrierter zweiter Faktor für die Passwort-Anmeldung von Kunden ist geplant.

Single Sign-on je Unternehmen mit OIDC oder SAML, per DNS verifizierten Domains, Zuordnung von Gruppen zu Rollen und einem optionalen reinen SSO-Modus. Es ist in der Managed Cloud aktiviert, und wir verbinden Ihren Identitätsanbieter auf Anfrage. SCIM 2.0 legt Benutzer an, deaktiviert sie und beendet ihre Sitzungen; ein ohne Rolle bereitgestellter Benutzer erhält die am wenigsten privilegierte HR-Rolle (HR-Koordinator), und die SCIM-Endpunkte sind ratenbegrenzt. Self-Hosted bindet jeden OIDC-Anbieter an.

Jede Route prüft beziehungsbasierte Berechtigungen. HR-Koordinatoren können Entwürfe erstellen, aber nicht finalisieren, keinen Befund übersteuern und das offizielle Dokument weder unterzeichnen noch herunterladen. Arbeitnehmervertretungen sehen nur aggregierte Zahlen; Führungskräfte sehen ihre direkt unterstellten Mitarbeitenden.

In der Managed Cloud teilen sich die Unternehmen eine Schweizer Datenbank. Die Anwendung beschränkt jede Anfrage auf ein Unternehmen und prüft die Berechtigungen für jedes Objekt. Bei Self-Hosted hat jeder Kunde eine eigene Datenbank. Eine Durchsetzung auf Zeilenebene in der Datenbank ist als zweite Schicht geplant.

Personen ohne Konto, etwa bewertende Führungskräfte, Prüfende eines Entwurfs oder Mitarbeitende, die ein Zeugnis abholen, erhalten Links, die Zugriff auf genau ein Objekt gewähren, ablaufen und widerrufen werden können. Die Plattform speichert nur einen SHA-256-Hash jedes Link-Tokens.

Staff-Konten werden nur auf Einladung angelegt und benötigen eine Administratorrolle, und jede Aktion in der Control Plane erfordert eine eigene Berechtigung. Jede Staff-Sitzung muss einen zweiten Faktor bestehen (Authenticator-Code oder Backup-Code), bevor sie die Control Plane nutzen kann, und ohne ihn wird keine Engine-Operator-Anmeldung ausgestellt. Staff-Konten können sich nicht als andere Benutzer ausgeben: Die Admin-Endpunkte für Impersonation sind deaktiviert. Änderungen an Unternehmen, Engine-Schlüsseln und Staff-Konten werden protokolliert.

Anmeldungen und Formularübermittlungen werden gegen den Ursprung der Anfrage geprüft, und Sitzungs-Cookies sind SameSite=Lax.

Die vier Web-Apps (App, Control, Chat und die Website) senden HSTS, eine Content-Security-Policy mit einer Nonce pro Antwort, Frame-Schutz (X-Frame-Options DENY und frame-ancestors none), X-Content-Type-Options nosniff und eine Referrer-Policy. Sensible Seiten senden zusätzlich no-store- und no-referrer-Header.

Die Anmeldung ist pro IP-Adresse ratenbegrenzt. Jede öffentliche Link-Seite, einschliesslich der Verifizierungsseiten hinter dem QR-Code, erlaubt 60 Anfragen pro Minute und Client, und die SCIM-Endpunkte erlauben 600 Anfragen pro Minute und Unternehmen und Client.

Jedes Unternehmen hat einen eigenen Engine-Schlüssel mit einer Begrenzung der Anfragerate; er kann rotiert und widerrufen werden. Die Engine speichert nur einen SHA-256-Hash davon, und die Plattform speichert ihn mit AES-256-GCM verschlüsselt. Ergebnisse sind nur für den Schlüssel oder das Unternehmen lesbar, die sie erstellt haben.

Hochgeladene Scans unterschriebener Papierzeugnisse müssen PDF, PNG oder JPEG sein, bis 10 MB, und der Dateiinhalt muss dem angegebenen Typ entsprechen.

Produktions-Secrets liegen im Azure Key Vault mit rollenbasiertem Zugriff und Soft Delete und gelangen als Key-Vault-Referenzen zu den Apps. Keines ist im Quellcode gespeichert, und die Produktion verweigert den Start ohne ihre Schlüssel.

Die Produktion läuft auf verwalteten Diensten: Azure-App-Service-Containern und Azure Database for PostgreSQL für die Plattform, Cloudflare Workers für die Engine. Wir betreiben keine eigenen virtuellen Maschinen.

Die Apps erreichen die Datenbank über einen privaten Endpunkt. Die Datenbank hat zusätzlich einen öffentlichen Endpunkt. Seine Firewall-Zulassungsliste enthält die Adressbereiche von Cloudflare, damit sich Cloudflare Workers, darunter die Engine, über Hyperdrive verbinden können. Bei Migrationen, Deployments und Backups lässt eine temporäre Regel den ausführenden CI-Runner zu und wird entfernt, sobald der Job endet. TLS und Passwörter schützen jede Verbindung.

Azure-Ressourcen sind in versionierten Vorlagen definiert, und App-Einstellungen stammen aus versionierten Dateien, die auf Key Vault verweisen.

Benachrichtigungen werden von notifications.zeugny.com gesendet, das eine DMARC-Richtlinie «reject» veröffentlicht; auch die Hauptdomain zeugny.com veröffentlicht eine DMARC-Richtlinie «quarantine». Die Benachrichtigungen enthalten die Empfängeradresse, Namen und einen Link. security@, privacy@ und hello@zeugny.com sind überwachte Postfächer.

Jeder Lebenszyklus-Schritt und jede Änderung wird in ein Audit-Protokoll geschrieben, in dem jeder Eintrag den Hash des vorherigen trägt, sodass ein veränderter Eintrag die Kette bricht. Die Kette wird geprüft, wenn ein Dossier oder eine Verifizierungsseite geöffnet wird, und das Dossier jedes Zeugnisses lässt sich mit seinen Audit-Einträgen herunterladen.

Alle fünf Minuten prüft ein separater Monitor den Zustand von Plattform, Worker und Control Plane. Einmal täglich führt er über die Engine eine vollständige Analyse eines fiktiven Zeugnisses durch. Azure-Verfügbarkeitstests überwachen den Monitor selbst von drei europäischen Standorten aus, sodass der Ausfall einer der beiden Seiten einen Alarm auslöst.

Anwendungs-, HTTP- und Datenbank-Logs gehen an Azure Log Analytics in Switzerland North und werden 30 Tage aufbewahrt. Engine-Anfrage-Logs enthalten nur Metadaten; die Laufzeit-Logs der Engine bei Cloudflare können Fragmente von pseudonymisiertem Text enthalten.

Betrifft ein Vorfall Ihre Daten, informieren wir Ihre benannte Kontaktperson unverzüglich, nachdem wir ihn bestätigt haben, darüber, was geschehen ist, welche Daten betroffen sind und was wir dagegen unternehmen. Ein schriftlicher Plan zur Reaktion auf Vorfälle liegt im Entwurf vor und wird nach rechtlicher Prüfung veröffentlicht; regelmässige Übungen sind geplant.

Die Datenbank kann auf jeden Zeitpunkt der letzten 35 Tage wiederhergestellt werden. Zusätzlich sichert ein geplanter Job alle Datenbanken jede Nacht als Dump. Er läuft auf einem von ZeugnyAI betriebenen CI-Runner, der sich per TLS verbindet, jeden Dump in eine temporäre Datei schreibt, ihn in Azure Storage in Switzerland North hochlädt und die Datei löscht. Die letzten 30 Dumps jeder Datenbank werden aufbewahrt, und gelöschte Dumps bleiben 30 weitere Tage wiederherstellbar. Die gespeicherten Backups, Point-in-Time und Dumps, liegen in Switzerland North und werden in eine zweite Schweizer Region, Switzerland West, repliziert.

Das Wiederherstellungsverfahren ist dokumentiert. Wiederherstellung getestet am 9. November 2026: Eine Point-in-Time-Wiederherstellung der Produktionsdatenbank auf einen temporären Server war in 7 Minuten abgeschlossen, und ihr Inhalt wurde geprüft. Weitere Wiederherstellungstests in regelmässigen Abständen sind geplant.

Die Managed Cloud läuft in Azure Switzerland North. Datenbank-Backups und Dateispeicher werden in eine zweite Schweizer Region, Switzerland West, repliziert. Eine Wiederherstellung des Datenbank-Backups in Switzerland West wurde am 10. November 2026 getestet. Eine Standby-Datenbank mit automatischem Failover ist geplant.

Jede Änderung im Hauptzweig, die die Prüfungen besteht, wird in einer separaten Staging-Umgebung bereitgestellt. Ein Produktions-Release setzt einen bestandenen Smoke-Test auf Staging für denselben Commit voraus. Die Engine gelangt nur aus Commits in die Produktion, die die Prüfungen bestanden haben: Ein CI-Job setzt den Release-Branch auf den getesteten Commit, und Cloudflare stellt aus diesem Branch bereit.

Typprüfungen, Unit- und Integrationstests und Produktions-Builds laufen bei jeder Änderung, und End-to-End-Tests laufen bei Änderungen, die sie betreffen. Abhängigkeiten werden aus einem eingefrorenen Lockfile installiert.

Entwicklung, Staging und Produktion verwenden getrennte Datenbanken, Schlüssel und Key Vaults. Tests verwenden nie Produktionsdaten oder Produktions-Zugangsdaten.

Releases in die Produktion durchlaufen automatisierte Kontrollen. Die Produktionspipeline der Engine deployt ausschliesslich von einem Release-Branch, den die CI erst auf einen Commit setzt, nachdem die Tests für diesen Commit auf main bestanden haben. Die Produktionspipeline der Plattform läuft ausschliesslich für Commits auf main mit erfolgreichem CI-Lauf und erst nach einem Abnahmelauf in der Staging-Umgebung. Self-Hosted-Kunden können jede Änderung in ihrem Repository prüfen. Eine erzwungene unabhängige Prüfung jeder Änderung ist geplant.

Quellcode-Snapshots für Kunden werden vor der Freigabe auf Zeichenfolgen, die wie Secrets aussehen, und auf verbotene Pfade geprüft. Warnungen zu Sicherheitslücken in Abhängigkeiten (Dependabot) sind für die Repositorys der Plattform und der Engine aktiviert. Code-Scanning und Secret-Scanning des Repositorys sind geplant.

Self-Hosted-Kunden erhalten einen Snapshot der Plattform, der nur Dateien einer Allowlist enthält, als privates Repository und bauen die Container selbst. Interne Werkzeuge sind ausgeschlossen, und ein Release wird gestoppt, wenn verbotene Pfade oder Zeichenfolgen, die wie Secrets aussehen, gefunden werden.

Der Produktionszugriff ist nach dem Need-to-have-Prinzip auf benannte Administratoren beschränkt. Eine formale Funktionstrennung zwischen Entwicklung und Betrieb ist geplant.

Jeder Anbieter, der für die Cloud Daten bearbeitet, ist auf dieser Seite mit Zweck, erhaltenen Daten und Standort aufgeführt.

Ein Standard-Auftragsbearbeitungsvertrag nach dem Schweizer DSG und der DSGVO liegt im Entwurf vor und wird nach rechtlicher Prüfung veröffentlicht. Bis dahin prüfen und unterzeichnen wir Ihren Vertrag.

Formelle schriftliche Richtlinien für Informationssicherheit, Zugriffskontrolle, Reaktion auf Vorfälle und Anbieter liegen im Entwurf vor und werden nach rechtlicher Prüfung veröffentlicht. Diese Seite beschreibt die aktuelle Praxis.

Ein externer Penetrationstest ist geplant. Self-Hosted-Kunden dürfen ihre eigene Installation jederzeit testen; für die Managed Cloud vereinbaren wir Umfang und Zeitpunkt mit Ihnen.