Overview
Regulated complaint operations need clear answers about where customer data lives, who can reach it, and what happens to it during backups, restores, and disaster scenarios. This article documents the current data residency posture for the Complaint Analyst platform.
Every claim in this document is grounded in the production deployment configuration or the application source code. If your procurement review needs additional artefacts (architecture diagrams, signed sub-processor list, transfer impact assessment), use the diligence request form at the bottom of this page.
Primary Hosting Region
The production environment runs on Hetzner Cloud in the EU, with the primary application servers in the Frankfurt (Germany) region. Customer-facing traffic is fronted by Cloudflare with TLS termination at the edge and end-to-end TLS to the application origin.
The application database is managed PostgreSQL on Supabase, also provisioned in the EU. Complaint records, user accounts, knowledge base content, and audit trail entries are persisted only in this EU-hosted database.
Backups & Point-in-Time Recovery
The managed PostgreSQL provider takes encrypted backups on a continuous basis and retains point-in-time recovery windows that allow restoring the database to a specific moment within the retention period. Backup encryption uses AES-256 at rest, consistent with the live database.
Backups are stored in the same EU jurisdiction as the primary database. Restore drills are exercised as part of the disaster recovery process described below, rather than being treated as a one-time setup activity.
Attachment & File Storage
Customer attachments uploaded through the intake API or analyst workflow are written through a single storage backend abstraction. Production deploys this backend against an S3-compatible object store in the EU region; the same code path supports local-disk storage for development and self-hosted environments.
Filenames are normalised and prefixed before storage so that the persisted object key never reflects untrusted input directly. Object access is gated by short-lived presigned URLs rather than public buckets, so the underlying objects cannot be enumerated from the internet.
Tenant Isolation
Every domain model in the platform carries a tenant_id column, and the standard query path scopes reads and writes by the caller's tenant. Tenant scoping is exercised by the automated compliance test suite, which runs in the CI pipeline on every release path.
Administrative endpoints that can cross tenant boundaries are gated behind a separate dependency and are intended for platform operations only. Application endpoints used by analysts cannot be coerced into returning data for a tenant the caller is not a member of.
Sub-processors
Complaint Analyst relies on a small number of well-known sub-processors to operate the platform. The current list is published here so that compliance reviewers can match it against their own DPA exhibit:
Hetzner Online GmbH (Germany) — primary application hosting. Supabase (EU region) — managed PostgreSQL, including encrypted backups. Cloudflare, Inc. — DNS, edge TLS termination, and DDoS protection (no complaint payloads are stored at the edge). Anthropic PBC — AI inference for complaint analysis, called only after the PII masking service has stripped personal identifiers from the prompt.
Material changes to the sub-processor list are documented in the product changelog and surfaced through the trust packet on request, rather than only on a static page.
Cross-Border Transfers
Complaint data does not leave the EU under normal operations. The narrow exception is the AI inference call to Anthropic for complaint analysis: the request is sent over TLS, contains text that has already been routed through the PII masking service, and is not retained in the inference provider's logs for training under the production configuration.
Where a sub-processor is incorporated outside the EU but processes only metadata or transit-level information (for example, edge DNS and TLS termination), the relationship is governed by Standard Contractual Clauses and the supplier's published data processing addendum.
Disaster Recovery
The disaster recovery posture is built around three commitments: a documented restore procedure, a recovery point objective measured in minutes thanks to point-in-time recovery, and a recovery time objective measured in hours rather than days for the application tier.
The deployment pipeline is reproducible from source: Docker images, Alembic migrations, and configuration are all version-controlled. A clean rebuild of the application tier from the latest images, pointed at a restored database snapshot, is the supported recovery path.
Deletion, Export & Offboarding
Tenant offboarding follows the published data handling policy: complaint records and associated attachments are exported in a portable format on request, identifying data is removed in line with the GDPR erasure workflow, and regulated-record retention obligations under FCA expectations are still honoured for the records that must be retained.
Where retention obligations require keeping a record beyond a deletion request, the surviving record is reduced to the minimum information needed to satisfy the obligation, rather than being kept in full.
Questions & Diligence Materials
If your review needs more detail than this page provides — for example a signed sub-processor list, an architecture diagram, or a transfer impact assessment — request the trust packet using the form below. We will route the request to the right follow-up rather than dropping you into a generic sales pipeline.