Content Autopilot for Coaches · EU-Hosted · GDPR-compliant
CastLoop
English
DeutschEnglishEspañolItalianoFrançais
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.
  • VM snapshot backups: IONOS provider-managed, rotating daily. No standalone pg_dump backups — the provider snapshot layer is assessed as sufficient.

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 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: April 2026 · Version 1.0 · Annex 1 to the DPA

← Back to the DPA To homepage