Legal

Security posture, in plain language.

Last updated · 12 July 2026
The position
What we encrypt, how we authenticate, where the data sits, what happens if something goes wrong. Written for the security team at a restaurant group deciding whether Verdscore clears their bar — and for the ones already in.

Encryption

  • In transit: TLS 1.2+ everywhere. HTTPS-only cookies. HSTS on verdscore.ai and its subdomains. Certificates issued by Cloudflare + Let's Encrypt, rotated automatically.
  • At rest: Full-disk AES-256 encryption on all Postgres volumes (Hetzner Cloud, Frankfurt). Backups encrypted at rest (AWS S3, eu-central-1) with server-side KMS.
  • Passwords: bcrypt (cost 12). Plaintext never seen by application code, never logged, never present in database dumps.

Authentication + session

  • Email + password with rate-limited signup and login (10 attempts per hour on signup, per-account throttling on login).
  • HTTP-only, Secure, SameSite=Lax session cookies. CSRF tokens on every state-changing request.
  • Cloudflare Turnstile on all public forms (signup, contact, paste-URL, custom inquiry) to block automated abuse.
  • Team members join via one-time invite links. Role-based access at the venue level; admin actions are audit-logged.

Hosting + data residency

  • Primary: Hetzner Cloud in Nuremberg, Germany. All customer data is stored in the EU by default.
  • Backups: AWS S3 eu-central-1 (Frankfurt), encrypted, retention 30 days.
  • Edge / CDN: Cloudflare (global). Only public HTTP metadata traverses edge — no application data cached in Workers KV.

See Subprocessors for the complete third-party list.

Access controls

  • Production database access limited to the single operator account. All access is logged in system audit trails.
  • Application code deploys via CI/CD from git — no production shell access is required for routine operation.
  • Any admin action that touches customer data (impersonation, manual override, grant issuance, plan change) is logged with actor, target, timestamp, and reason.
  • Secrets stored in per-environment `.env` files outside the git tree; rotated on compromise, ownership hand-off, or annually — whichever comes first.

Incident response

  • Detection: Uptime monitoring + Telegram alerts on service failures, DB errors, and unusual spend spikes.
  • Triage: Owned by the operator on-call (single-founder company — no round-robin gap).
  • Breach notification: 72-hour commitment under GDPR Article 33 to notify affected customers and — where required — supervisory authorities.
  • Post-mortem: Published to affected customers within 14 days; system-wide incidents summarised on /legal/status.

LLM handling

Verdscore uses Anthropic (Claude) as its sole LLM subprocessor for review analysis + reply drafting. Requests use the zero-retention API tier — Anthropic does not retain prompts or completions for model training. See Subprocessors for the certification detail.

Audit + compliance

  • SOC 2: Not currently certified. Progress against SOC 2 Type II controls is tracked internally and available on request under NDA.
  • Penetration test: External test scheduled annually; most recent summary available on request under NDA.
  • Vulnerability disclosure: Report to [email protected] with subject “security”. Acknowledged within 24 hours. Good-faith research is welcome and will not lead to legal action.

Business continuity

  • Daily encrypted database backups; 30-day retention.
  • Recovery tested quarterly with a fresh restore into a staging environment.
  • Application is stateless — a full rebuild from git plus a database restore takes under an hour.
Questions about this document? Send me a message — I read every one.
Security · Verdscore.ai · Verdscore