Content autopilot for video and podcast, hosted in Germany.
CastLoop
English
DeutschEnglishEspañolItalianoFrançaisNederlands
Log in
· Art. 32 GDPR

Technical and organizational measures

Annex 1 to the Data Processing Agreement (DPA). Describes the security measures implemented pursuant to Art. 32 GDPR.

This is a convenience translation. The legally binding version is the German original: German version.

As of: April 2026. These TOMs are regularly adapted to the state of the art. Material changes are communicated to the customer.

1. Confidentiality

The processor operates a sole proprietorship without additional employees with data access. All sub-processors deployed (see DPA § 7) are bound to confidentiality. The own end devices (developer workstations) are FileVault-encrypted, secured by Touch ID and strong passwords as well as with automatic screen locking.

2. Pseudonymization (Art. 32 (1) lit. a GDPR)

  • In logs, email addresses are not referenced in plain text but exclusively as tenant_id or anonymized user ID (pino log redaction).
  • IP addresses are hashed for rate limiting via a secret IP_HASH_SALT (HMAC-SHA-256); the original IPs are not stored persistently.
  • IPv4 is normalized to /32, IPv6 to /64, to further restrict traceability.

3. Encryption (Art. 32 (1) lit. a GDPR)

3.1 Encryption in transit

  • All connections: HTTPS / TLS 1.2+ (HSTS enabled).
  • SMTP connections to IONOS via STARTTLS, TLS 1.2+ enforced.
  • Database connections internally via UNIX socket or TLS.

3.2 Encryption at rest

  • OAuth tokens (social media): AES-256-GCM “envelope encryption” with versioned keys (ENCRYPTION_KEY, ENCRYPTION_KEY_V2…V16). Format: v{N}:iv:tag:ct. The AAD context is bound to tenantId:socialAccountId:platform — tampering with the row context causes decryption to fail.
  • Passwords: Argon2id with OWASP 2024 parameters (m=19456 KiB, t=2, p=1). Legacy bcrypt hashes are detected at login and transparently rehashed to Argon2id.
  • VM disk encryption: The IONOS cloud infrastructure provides disk encryption at the provider level.
  • Secrets: .env files exclusively with file permissions 0600, never in the Git repo.

4. Physical / infrastructure access control

  • The production system runs in the IONOS data centers in Germany (ISO 27001, ISO 22301 certified). Physical access is secured on the provider side (24/7 security service, biometrics, video surveillance).
  • SSH access to the servers: exclusively via public key (no password login), over a non-standard SSH port (2222), with Fail2ban against brute force, and with IdentitiesOnly=yes enforcement.
  • The firewall (firewalld) restricts incoming connections to port 2222 (SSH), 80 (HTTP redirect to HTTPS) and 443 (HTTPS).
  • SELinux in enforcing mode.

5. Logical access control (application level)

  • Authentication: email + password (Argon2id) or SSO (Google / Microsoft / Apple). JWT-based session tokens with ES256 signatures and kid rotation (CURRENT + optional PREVIOUS key slot for zero-downtime rotation).
  • Refresh token rotation: family-based rotation with a 10-second grace window in Redis; ≥3 grace hits of the same old token ID trigger theft_detected and family revoke.
  • Multi-tenant isolation via Postgres row-level security (RLS): app connections run under the DB role castloop_app (without BYPASSRLS). Each transaction sets app.tenant_id via SET LOCAL. Migrations run under castloop_migrator (with BYPASSRLS). Even a SQL injection cannot break out of the own tenant scope (defense in depth).
  • Rate limiting: Redis Lua script (atomic check+increment) against brute force and abuse.
  • CSRF: SameSite-Strict cookies + CSRF tokens.
  • CSP: Content Security Policy with per-request nonce and strict-dynamic, prevents XSS.
  • SSH access to the server: only a single administrator (the owner).

6. Separation control

  • Separate databases per project on the shared server (own Postgres DB castloop with own user castloop_user, no access to other DBs).
  • Production, staging and development environments are separated from one another; production secrets never reach staging/dev.
  • Mollie key strict mode: in production exclusively live_* keys, in staging/dev exclusively test_* keys — enforced via zod superRefine.

7. Integrity (Art. 32 (1) lit. b GDPR)

  • RLS prevents cross-tenant data manipulation (see 5).
  • Postgres advisory locks (key 821912301) gate Drizzle migrations — two parallel deploys cannot migrate at the same time.
  • AAD-bound OAuth token encryption: tampering with the row context causes the decryption to fail (integrity protection via AES-GCM tag).
  • Mollie webhook idempotency: dedicated mollie_webhook_events table with idempotency key (resource_id, payload_hash) (sha256 over canonical JSON).
  • Input validation on the client and server side (zod schemas).

8. Availability

  • pm2 auto-restart: castloop-api, castloop-worker and castloop-app run under pm2 supervision and restart automatically on a crash.
  • Graceful shutdown: SIGTERM/SIGINT drain HTTP requests and BullMQ jobs; hard-capped by SHUTDOWN_TIMEOUT_MS.
  • Healthcheck endpoint for monitoring.
  • Data backup: daily backup of the database and the stored files, kept locally for 14 days and additionally stored encrypted (restic) in the object storage of IONOS SE (daily backups 14 days, weekly 8 weeks, monthly 12 months). Failed or missing backups trigger an alert email. In addition, there are daily rotating VM snapshots (IONOS-managed).

9. Resilience

  • Rate limiting protects against overload.
  • BullMQ with retry mechanisms (exponential backoff) for clip rendering and platform publishing.
  • Mollie ingest orphan sweeper (60s interval, 120s grace, BullMQ jobId=eventId dedupe) prevents payment drift when webhooks fail.
  • Independent ioredis connections for BullMQ vs. app code prevent key prefix collisions.

10. Recoverability (Art. 32 (1) lit. c GDPR)

  • Daily encrypted database and file backups with tested restore as well as daily rotating VM snapshots (IONOS-managed).
  • Deployment via Git + rsync enables a rollback to an earlier commit within a few minutes.
  • Idempotent, advisory-lock-gated migrations allow a safe re-run in the event of partial failures.

11. Procedure for regular review

  • Dependency updates (npm audit, Dependabot) at least monthly.
  • OS patches (AlmaLinux) at least monthly.
  • Log monitoring: pino logs with redaction of sensitive fields (passwords, tokens, JWTs, authorization/cookie headers, API keys, DATABASE_URL, REDIS_URL, SMTP_PASS).
  • Annual internal TOM review, with adaptation to the state of the art where necessary.
  • External penetration testing as needed / upon customer request.

12. Commissioning control

  • Written DPA contracts with all deployed sub-processors (see DPA § 7), insofar as these are to be classified as processors under data protection law.
  • Documented instruction channels: customer dashboard, Terms/DPA contractual framework, informal email to info@castloop.de.
  • No use of further sub-processors without 30 days' prior notice to the customer (see DPA § 7).

As of: 24 October 2026 · Version 1.1 · Annex 1 to the DPA

← Back to the DPA To homepage