Controls

valid · 71 days to renewal

enforced · max-age 730d

healthy · db connected · 88ms round-trip

Application and PostgreSQL run on a Hetzner Cloud server in Nuremberg; object storage is Hetzner Object Storage in Falkenstein. No customer data is stored outside EU.

Database volumes are encrypted at rest by Hetzner and object storage uses server-side encryption; TLS terminates at the reverse proxy and HSTS is enforced. Confirmed 08.07.2026, recorded in the encryption posture document.

The database is backed up on a schedule to a storage location separate from the server.

enforced · 9 directives

enforced · X-Frame-Options: DENY

A customer account may complete its first sign-in without a second factor and must enrol a TOTP factor from its second sign-in; once enrolled, the factor is challenged on every fresh login. An organisation can require it from the first sign-in.

Every tenant request resolves the active organisation membership and role; mutations check the required permission server-side, and tenant filters are applied in every query. Cross-tenant and wrong-role paths are covered by automated tests.

Second-factor secrets and integration credentials are encrypted with AES-256-GCM in the application before they are written to the database.

Record changes are written to a per-organisation audit log that the application never updates or deletes; each day’s entries are sealed into a hash chain anchored to the previous day.

Dependabot, CodeQL and Semgrep run on every pull request and on a schedule; findings are queued for triage.

The repository is scanned for committed credentials on every push and daily, in addition to GitHub’s own secret scanning.

The classes of data we process, where each is processed and the transfer basis for the one non-EU sub-processor are published at /trust/sub-processors.

Every third party that processes customer data is listed at /trust/sub-processors with its purpose and location; the list is maintained in code and changes are announced.

A GDPR Article 28 agreement is published at /dpa and applies to every customer.

The DPA commits Veritome to notify the controller without undue delay and within 72 hours of becoming aware of a personal data breach.

The DPA commits Veritome to delete or return all personal data within 30 days of termination, at the controller’s choice, with a certificate of destruction on request.

Customer content sent to Aria is processed to generate a response under a data processing agreement with Mistral and is not used to train models. Veritome trains no models of its own.

security@veritome.eu is monitored, published in security.txt under RFC 9116 with a PGP key, and the disclosure policy at /trust/security sets response times and safe harbour.

Administrative access to production is reviewed on a schedule.

Every change reaches production through a pull request into the staging branch with automated lint, type, unit, integration and security checks, review, a test on staging, and a promotion to production; direct pushes are blocked.

Reported vulnerabilities are acknowledged within 48 hours and triaged within 5 business days; critical, high and medium findings are fixed within 30, 60 and 90 days, as published at /trust/security.