Technical and Organisational Measures (TOMs)

Annex 1 to the Data Processing Agreement / Anlage 1 zum AVV — Art. 32 GDPR

Last updated: 2026-10-01

0. Scope and status

This document describes the measures OrgOps GmbH has in place for the myvibecode.app platform, which hosts customers' web apps and their PostgreSQL databases. It describes what is actually implemented today. OrgOps is a small company and does not operate a certified information security management system (no ISO 27001 or comparable certification). Known gaps are listed openly in section 6.

1. Confidentiality (Art. 32(1)(b) GDPR)

1.1 Physical access control

  • OrgOps operates no servers on its own premises. All platform and app systems run on cloud servers of Hetzner Online GmbH in data centres in Falkenstein and Nuremberg (Germany) and Helsinki (Finland).
  • Physical security of these data centres is the responsibility of Hetzner as sub-processor and is governed by Hetzner's data processing agreement and its published technical and organisational measures.

1.2 System access control

  • Passwordless sign-in: platform accounts sign in with single-use magic links. The link token is 32 random bytes; only its SHA-256 hash is stored; it expires after 15 minutes and can be used once.
  • Brute-force and abuse limits: at most 5 login-link requests per email address and 10 per client IP address per hour, plus a platform-wide limit. IP addresses are kept only as keyed hashes (HMAC) and only for the one-hour window.
  • Sessions: signed session token in a __Host- prefixed cookie (HttpOnly, Secure, Path=/, no Domain attribute, SameSite=Lax), so hosted apps on sibling subdomains cannot set or overwrite it. Lifetime 30 days.
  • CSRF protection: cookie-authenticated state-changing requests require an exact-match Origin header; requests without it are rejected.
  • API, deploy and connect tokens are random values; only their SHA-256 hashes are stored. One-time download links expire after 15 minutes.
  • Network perimeter: a Hetzner Cloud firewall in front of all servers admits from the internet only HTTP/HTTPS (80/443), SSH (22) and the Kubernetes API (6443). Cluster-internal ports (overlay network, kubelet) are reachable only from the private network.
  • Administrative access to servers uses SSH public-key authentication (keys provisioned by infrastructure code); access to the Kubernetes API requires the cluster's client credentials, which are held as protected CI/CD variables.

1.3 Data access control

  • Per-app isolation in Kubernetes: every app runs in its own namespace with a default-deny network policy for ingress and egress. Inbound traffic is allowed only from the ingress controller; outbound traffic only to DNS, the database connection pooler and the public internet — never to other apps or internal cluster networks.
  • App containers get no Kubernetes service-account token (automountServiceAccountToken: false), and have CPU and memory limits.
  • Per-app database: every app has its own PostgreSQL database and its own login role. The default right of every role to connect to every database (CONNECT for PUBLIC) is revoked, so one app's credentials cannot open another app's database.
  • Credentials: database credentials and app secrets (environment values the customer enters) are stored as Kubernetes Secrets in the app's own namespace and injected at runtime; secret values are write-only in the dashboard. Databases of new apps get a random per-app password.
  • Authorisation in the platform: every app-related request is checked server-side against the app's owner and members; the admin area is enforced server-side and limited to explicitly configured administrator accounts.
  • Platform Brain (optional assistant for the customer's coding agent): runs on OrgOps' own LLM server, not on a third-party AI API. It can read the app's deployed source files (bounded number and size per conversation) and app metadata, but has no access to the app's database. Conversation transcripts containing file contents are kept only in memory and are not written to the platform database.

1.4 Separation control

  • Separate Kubernetes namespace, network policies, database, database role, secrets and private source repository per app.
  • The platform's own data (accounts, events) is held in a separate PostgreSQL cluster from the customers' app databases.

1.5 Pseudonymisation

  • The platform itself stores no IP addresses in clear text (rate limiting uses keyed hashes only). Pseudonymisation of data inside an app is the customer's responsibility as controller.

1.6 Encryption

  • In transit (public): the platform and all apps are served over HTTPS with Let's Encrypt certificates (a wildcard certificate for *.myvibecode.app, individual certificates for verified custom domains).
  • Backups are transferred to object storage over HTTPS; platform email is submitted via SMTP with STARTTLS.
  • At rest: see section 6 — disk, secret and backup encryption at rest is not currently configured by the platform.

2. Integrity (Art. 32(1)(b) GDPR)

2.1 Transfer control

  • Cluster nodes communicate over a Hetzner private network; internal ports are not exposed to the internet (see 1.2).
  • The customer's self-service database export is streamed directly to the authenticated requester and is not stored on the platform.
  • Invitation and notification emails escape user-supplied content to prevent injection.

2.2 Input control

  • Platform actions (sign-ins and failed sign-in attempts, app creation, deployments, deletions, member invitations, token issuance, administrative changes) are recorded as timestamped entries in an append-only event log.
  • Infrastructure and platform changes are made through version control and CI/CD pipelines (infrastructure as code), which leaves a traceable history of who changed what and when.
  • Changes to data inside an app are under the control of the customer's app.

3. Availability and resilience (Art. 32(1)(b), (c) GDPR)

  • Database backups: the app databases run on PostgreSQL managed by CloudNativePG with continuous write-ahead-log (WAL) archiving and hourly base backups to S3-compatible Hetzner Object Storage, with a 7-day retention window (point-in-time recovery within that window).
  • The platform database is additionally dumped hourly to the same object storage.
  • Database data lives on Hetzner block-storage volumes that are separate from the servers.
  • Self-service export: customers can download a full dump of their app database at any time (dashboard or mvc backup) and their source code.
  • Monitoring and alerting: Prometheus/Alertmanager/Grafana with email alerts to the operator, plus a public status page (status.myvibecode.app).
  • Health checks restart failed platform components; per-app resource limits prevent a single app from exhausting a node; a connection pooler protects the database from connection floods.
  • Component versions are pinned and upgraded deliberately.

4. Rapid restore (Art. 32(1)(c) GDPR)

  • The deployment pipeline can recreate the app database cluster from the object-storage backup (base backup + WAL replay). A documented restore drill procedure exists that restores into a throw-away cluster without touching production. See section 6 on its status.

5. Regular review and organisational measures (Art. 32(1)(d) GDPR)

  • All infrastructure is defined as code; changes go through version control and CI/CD rather than manual changes on servers.
  • Security-relevant rules (access, membership, limits, tokens, DNS/domain checks) are covered by automated tests.
  • Privacy by default: no tracking or analytics on the platform; only the email address is collected for an account.
  • Sub-processors are selected for EU data residency and listed publicly (Sub-processors); changes are announced as set out in the DPA.
  • Security incidents are handled and notified as set out in section 10 of the DPA.
  • These TOMs are reviewed whenever the infrastructure changes materially.

6. Known limitations and planned improvements

In the interest of transparency, the following measures are not in place today. The items are planned; their implementation will be reflected in this document.

  • Encryption at rest: block-storage volumes, Kubernetes Secrets and backups in object storage are not encrypted by the platform (the platform relies on the provider's storage). Planned: volume encryption and encrypted backups.
  • Internal traffic: traffic between cluster nodes and between apps and the database inside the private network is not additionally encrypted. Planned: encrypted node-to-node networking and TLS to the database.
  • HTTP→HTTPS redirect: HTTPS is available on all hosts, but plain HTTP requests are not yet redirected platform-wide (session cookies are Secure-only and are never sent over HTTP). Planned.
  • Administrative endpoints: SSH (22) and the Kubernetes API (6443) are reachable from the internet (key/certificate-authenticated). Planned: restriction to known addresses or a VPN.
  • Database credentials of older apps: apps created before the per-app random passwords still use a password derived from a server-side secret. Planned: rotation to random per-app passwords. A small number of databases created under an older ownership model may not yet have the cross-app CONNECT revocation applied.
  • High availability: the app database cluster runs as a single instance (no hot standby), the platform runs as a single replica and the ingress runs on a single node; maintenance or failures can cause downtime. No uptime is guaranteed (see Terms).
  • Backups: backups are kept with the same provider (Hetzner) as the primary data; there is no second-provider copy. The restore procedure is documented and prepared but has not yet been rehearsed end-to-end. Planned: regular restore drills.
  • Sessions cannot yet be revoked server-side before they expire. Planned.
  • Formal ISMS: no certification and no formal, documented ISMS. Planned: written security policies and a periodic review cycle.

Contact

Questions about these measures: mail@orgops.io