Security you can check, not just trust.

Inside the platform, the PII boundary replaces the names of employees, managers and signatories, employer and company names, dates, work e-mail addresses and employee IDs with consistent pseudonyms before a request reaches the engine, and restores them in the answer. It wraps the engine calls of the HR platform, the lifecycle worker, ZeugnyAI Chat (which reaches the engine only through the platform) and the Word gateway.

For each certificate, HR can open every crossing to and from the engine: time, direction, the number of replaced items per category, the SHA-256 of the payload and the pseudonyms used. Real values are never shown there. The view exports as CSV.

All apps accept HTTPS only, with TLS 1.2 as the minimum; TLS 1.3 is negotiated in practice. The database server accepts TLS connections only, with TLS 1.2 as the minimum, and the platform's database connections request TLS.

Azure encrypts the database, backups and file storage at rest. On top of that, the platform encrypts pseudonym mappings and engine API keys with AES-256-GCM under master keys held in Azure Key Vault. Other records rely on Azure's encryption.

Once the retention period has passed (10 years after the end of employment by default), an hourly job redacts a former employee's name, e-mail address, date and place of birth and nationality, erases drafts and deletes the pseudonym mappings. Job assignments, the audit trail and issued certificates are kept; issued certificates still contain the name. We set a different period for your company on request; self-service configuration is planned.

Employees file access and deletion requests themselves under My privacy, and HR tracks each one against a 30-day deadline. Erasure redacts the employee's records, removes vault entries and shares, and issues a receipt. An access request produces a summary; a downloadable copy of the data is planned.

The platform can destroy a company's pseudonymisation key, which makes its stored mappings unreadable. The function is built and tested; making it available as an operator action is planned. Backup copies expire on the regular backup schedule.

Certificate text is written by models on Microsoft Azure AI Foundry, on a resource in Switzerland North with an EU Data Zone Standard deployment, so requests are processed within the EU data zone. Decision, extraction and retrieval steps also use Microsoft Decision-1 (an Azure AI Foundry resource in Sweden Central with an EU Data Zone Standard deployment), OpenRouter and Voyage AI, and the platform uses OpenRouter directly to suggest job titles and tasks. Providers receive pseudonymised text only. Every request the engine sends to OpenRouter requires providers that do not collect user data, with no setting to switch this off. Zero-data-retention routing is planned.

Passwords are hashed with scrypt and need at least 8 characters. E-mail addresses are verified before the first password sign-in, and passwordless magic links expire after 5 minutes. Sign-in attempts are rate-limited per IP address.

Sessions are stored on the server and can be revoked. Session cookies are HttpOnly, Secure and SameSite=Lax and expire after 7 days. A deactivated account is refused on its next request.

With single sign-on, your identity provider's MFA applies to every sign-in. Staff accounts in our control plane need a second factor (an authenticator code or a backup code) for every session, and no engine operator login is issued without it. A built-in second factor for customer password sign-in is planned.

Per-company single sign-on with OIDC or SAML, DNS-verified domains, group-to-role mapping and an optional SSO-only mode. It is switched on in the managed Cloud, and we connect your identity provider on request. SCIM 2.0 creates and deactivates users and ends their sessions; a user provisioned without a role gets the least-privileged HR role (HR coordinator), and the SCIM endpoints are rate-limited. Self-Hosted connects any OIDC provider.

Every route checks relationship-based permissions. HR coordinators can draft but cannot finalise, override a finding, sign or download the official document. Works councils see aggregate figures only; managers see their own direct reports.

In the managed Cloud, companies share one Swiss database. The application confines every request to one company and checks permissions on each object. Self-Hosted gives each customer its own database. Row-level enforcement in the database is planned as a second layer.

People without an account, such as a rating manager, a draft reviewer or the employee collecting a certificate, get links that grant access to exactly one object, expire and can be revoked. The platform stores only a SHA-256 hash of each link token.

Staff accounts are created by invitation only and need an administrator role, and each action in the control plane requires its own permission. Every staff session must pass a second factor (an authenticator code or a backup code) before it can use the control plane, and no engine operator login is issued without it. Staff cannot impersonate users: the admin impersonation endpoints are disabled. Changes to companies, engine keys and staff are logged.

Sign-in and form submissions are checked against the request's origin, and session cookies are SameSite=Lax.

The four web apps (app, control, chat and the website) send HSTS, a Content-Security-Policy with a per-response nonce, frame protection (X-Frame-Options DENY and frame-ancestors none), X-Content-Type-Options nosniff and a referrer policy. Sensitive pages also send no-store and no-referrer headers.

Sign-in is rate-limited per IP address. Every public link page, including the verification pages behind the QR code, allows 60 requests per minute per client, and the SCIM endpoints allow 600 requests per minute per company and client.

Each company has its own engine key with a request rate limit; it can be rotated and revoked. The engine stores only a SHA-256 hash of it, and the platform stores it encrypted with AES-256-GCM. Results are readable only by the key or company that created them.

Uploaded scans of signed paper certificates must be PDF, PNG or JPEG, up to 10 MB, and the file content must match the declared type.

Production secrets live in Azure Key Vault with role-based access and soft delete, and reach the apps as Key Vault references. None are stored in source code, and production refuses to start without its keys.

Production runs on managed services: Azure App Service containers and Azure Database for PostgreSQL for the platform, Cloudflare Workers for the engine. There are no virtual machines of our own to maintain.

The apps reach the database through a private endpoint. The database also has a public endpoint. Its firewall allow-list holds Cloudflare's address ranges, so Cloudflare Workers, including the engine, can connect through Hyperdrive. During migrations, deployments and backups, a temporary rule admits the CI runner doing the work and is removed when the job ends. TLS and passwords protect every connection.

Azure resources are defined in versioned templates, and app settings come from versioned files that reference Key Vault.

Notifications are sent from notifications.zeugny.com, which publishes a DMARC reject policy, and zeugny.com itself publishes a DMARC quarantine policy. Notifications contain the recipient's address, names and a link. security@, privacy@ and hello@zeugny.com are monitored mailboxes.

Every lifecycle step and change is written to an audit log in which each entry carries the hash of the previous one, so an edited entry breaks the chain. The chain is checked when a dossier or verification page is opened, and each certificate's dossier can be downloaded with its audit entries.

Every five minutes, a separate monitor checks the health of the platform, worker and control plane. Once a day it runs a full analysis of a fictional certificate through the engine. Azure availability tests watch the monitor itself from three European locations, so an outage of either side raises an alert.

Application, HTTP and database logs go to Azure Log Analytics in Switzerland North and are kept for 30 days. Engine request logs hold metadata only; the engine's runtime logs on Cloudflare can contain fragments of pseudonymised text.

If an incident affects your data, we inform your named contact without undue delay after we confirm it, with what happened, which data is affected and what we are doing about it. A written incident response plan is drafted and is published after legal review; regular exercises are planned.

The database can be restored to any point in the last 35 days. In addition, a scheduled job dumps all databases every night. It runs on a ZeugnyAI-operated CI runner, which connects over TLS, writes each dump to a temporary file, uploads it to Azure Storage in Switzerland North and deletes the file. The last 30 dumps of each database are kept, and deleted dumps stay recoverable for 30 more days. The stored backups, point-in-time and dumps, are kept in Switzerland North and replicated to Switzerland West, a second Swiss region.

The restore procedure is documented. Restore tested on 9 November 2026: a point-in-time restore of the production database to a temporary server completed in 7 minutes and its contents were checked. Further restore tests on a recurring schedule are planned.

The managed Cloud runs in Azure Switzerland North. Database backups and file storage are replicated to a second Swiss region, Switzerland West. A restore of the database backup into Switzerland West was tested on 10 November 2026. A standby database with automatic failover is planned.

Every change on the main branch that passes the checks is deployed to a separate staging environment. A production release requires a passing smoke test on staging for the same commit. The engine reaches production only from commits that passed the checks: a CI job moves the release branch to the tested commit, and Cloudflare deploys from that branch.

Type checks, unit and integration tests and production builds run for every change, and end-to-end tests run for changes that affect them. Dependencies install from a frozen lockfile.

Development, staging and production use separate databases, keys and key vaults. Tests never use production data or credentials.

Production releases pass automated gates. The engine's production pipeline deploys only from a release branch, which CI moves to a commit after the tests have passed for that commit on main. The platform's production pipeline runs only for commits on main with a successful CI run, and only after an acceptance run on the staging environment. Self-Hosted customers can review every change in their repository. Enforced independent review of every change is planned.

Customer source snapshots are checked for secret-shaped strings and forbidden paths before release. Dependency vulnerability alerts (Dependabot) are enabled on the platform and engine repositories. Code scanning and repository secret scanning are planned.

Self-Hosted customers receive an allowlisted snapshot of the platform as a private repository and build the containers themselves. Internal tooling is excluded, and a release stops if forbidden paths or secret-shaped strings are found.

Production access is limited to named administrators on a need-to-have basis. Formal separation of duties between development and operations is planned.

Every provider that processes data for the Cloud is listed on this page with its purpose, the data it receives and its location.

Formal written policies for information security, access control, incident response and vendors are drafted and are published after legal review. This page describes current practice.

An external penetration test is planned. Self-Hosted customers are welcome to test their own installation at any time; for the managed Cloud we agree scope and timing with you.