Technical & Organizational Measures

Annex 1 to the DPA: measures per Art. 32 GDPR, status 20 July 2026

These TOMs describe the actually implemented architecture and are updated when it changes. German master: /de/legal/tom/

1. Encryption & pseudonymization (Art. 32(1)(a))

  • Client-side end-to-end encryption: drop content is encrypted in the user's browser with AES-256-GCM (WebCrypto) before transmission. The key travels in the URL fragment, which browsers by design never send to servers. The provider stores ciphertext only.
  • Optional passphrase mixed into the key client-side via HKDF-SHA256; never leaves the browser.
  • Access tokens stored server-side as SHA-256 hashes only; a database dump alone grants no drop access (two-token design).
  • IP pseudonymization: audit trail stores IPs exclusively as SHA-256 hashes.
  • Transport encryption: TLS 1.2+ with HSTS everywhere.

2. Confidentiality & access control (lit. b)

  • Physical: operation exclusively in ISO 27001-certified data centers (Hetzner, Germany).
  • System access: administration via SSH public keys and MFA-protected accounts only; no password logins.
  • Data access: least privilege; production database accessed only by the application. Architectural property: even privileged administrators cannot decrypt drop content: no key material exists server-side.
  • No third-party scripts on drop pages (rules out fragment exfiltration by third-party code); no ad trackers.
  • Deliberate non-logging: no access logs with URLs on drop paths; chat-integration invoke payloads are never logged.

3. Integrity (lit. b)

  • Authenticated encryption: AES-GCM detects any ciphertext tampering; tampered drops cannot decrypt.
  • Atomic read transactions: burn-after-read is enforced atomically in the database; a one-time drop can be read exactly once even under concurrent access.
  • Audit trail (Team plan): created/read/burned/expired events with timestamps: metadata only, never content.
  • Input validation & rate limiting on all public endpoints; signature-verified webhooks (Stripe, Slack, Microsoft).

4. Availability & resilience (lit. b/c)

  • Stateless application layer, horizontally scalable; infrastructure reproducible as code.
  • Daily database backups (containing ciphertext and metadata only) to EU object storage (Hetzner, Falkenstein) with 30-day retention, plus continuous transaction-log archiving; restore tested end-to-end at setup and at least yearly thereafter.
  • Availability and error-rate monitoring through the Kubernetes platform (health checks, automatic restart of failing instances, zero-downtime rolling deployments).

5. Deletion concept

  • Self-deletion by design: drops are permanently deleted immediately on their final read, and within 60 seconds of expiry (hard DELETEs: no soft delete, no trash).
  • Burned, expired and never-existing drops are indistinguishable in API responses (no existence oracle).
  • Residual data in backups expires with backup rotation after at most 30 days.
  • Account and audit data deleted after contract end per section 10 of the DPA.

6. Processor control & organization (Art. 32(1)(d), Art. 28)

  • Subprocessors within EU/EEA only for core-service data; Art. 28(4) agreements in place; current list in the Trust Center.
  • Defined responsibilities for privacy and security; documented incident-response process with a 48-hour notification commitment.
  • Open-source client cryptography: external verifiability as an organizational measure.
  • Change management via version control, code review and automated tests (incl. crypto roundtrip and burn-semantics concurrency tests).
  • Review and evolution of these measures at least yearly and upon relevant changes.