SECURITY · TRUST CENTER
Security as the default — not an add-on.
We build security where it belongs: into the database, the servers in front of it, and the strict separation of your data from other customers'. No theater — verifiable practice.
All data resides on servers in Germany — rented from Hetzner Online GmbH in Falkenstein (Vogtland). Encrypted backups go to an offsite store operated by STRATO AG, also in Germany.
The application runs in separate Linux containers behind a reverse proxy. Database and cache have no published ports — they are reachable only from the internal container network.
The AI runs at IONOS, processing in Germany; we do not use any other AI provider. Speech recognition for voice messages runs in our own container on our own machine — recordings never leave it.
In transit: TLS only. HSTS is set; the security headers (including Content-Security-Policy and Permissions-Policy) are part of the automated check chain rather than left to chance. Certificate expiry is monitored.
Backups: database and file backups are encrypted with age before they leave the server. The private key is not kept on the backed-up machine. Transfer uses SFTP.
Passwords are hashed with Argon2id and never stored or logged in clear text. Credentials for third-party systems (webhook secrets and the like) are stored encrypted.
We do not currently use full-disk encryption at the operating system level. We write that here rather than leave it out.
SilentChat is multi-tenant. Separation is enforced in the database layer, not merely in the interface: every query carries the tenant identifier as a filter, using reusable scopes rather than hand-written conditions — including lookups by id, where a check after the fact in the handler is the classic gap.
The cache separates too: keys carry the tenant identifier as a prefix. So do the realtime connections — a widget only listens in its own conversation.
Route coverage is checked before every release. Gaps found are documented and fixed; most recently a cross-tenant write on the product board on 7 July 2026.
Sign-in by email and password, by one-time link without a password, via Google, or via SAML 2.0 and OpenID Connect for enterprise customers. Two-factor authentication (TOTP) with recovery codes and the option to remember individual devices.
Sign-in attempts are rate limited. On security-critical paths the limiter is fail-closed: if the cache is unavailable, requests are refused rather than waved through — availability does not outrank abuse protection there.
Within a tenant there is a role and permission model with eight predefined roles plus custom roles on the larger plans. Enforcement is server-side; the interface only hides. Sessions can be revoked centrally — a suspended account loses access immediately, not when its token expires.
The database is backed up on a schedule, files once a day. Both are encrypted and transferred to an offsite store.
Retention: 30 days rolling — deliberately aligned with the deletion period in the DPA, so a deletion cannot survive in an older backup.
Restore has been rehearsed, not just described: on 6 July 2026 database and files were actually restored from the offsite backup.
No point-in-time recovery. We do not archive transaction logs. Potential data loss equals the interval between backups, not minutes. This is a deliberate decision; the reasoning is in the disaster recovery runbook.
Every release runs through an automated check chain against a real database in containers: unit and integration tests, browser-level interface checks, plus dedicated checks for translations, route coverage, security headers and the registration of database migrations.
Dependencies are scanned for known vulnerabilities; critical findings are fixed immediately rather than deferred to a maintenance window.
No external security assessment. No third-party penetration test has taken place so far. That, too, is stated here rather than omitted.
There is a written procedure for personal data breaches — from detection through assessment to notifying the supervisory authority within 72 hours (Art. 33 GDPR) and informing data subjects. The same exists for infrastructure outages and for runaway AI cost.
Report to security@silentchat.de. We reply on business days.
No 24/7 on-call rotation. SilentChat is run by a small team; we do not promise response times outside business hours.
The application writes structured logs with limited retention and automatic rotation. Personal data does not belong in them — email addresses and names are masked before writing; identifiers instead of clear text is the rule.
A health endpoint reports database, cache, background workers and speech recognition separately. Every AI call is logged with model, purpose, consumption and cost and can be inspected in the admin area; cost ceilings apply per tenant and for the installation as a whole.
Every administrative action lands in the tenant audit log: who, when, what, from which address.
TRUST CENTER
Whitepapers, pen test reports, SOC statements.
Available on request under NDA for Enterprise customers.