Data Residency
Storage locations, processing regions and third-country transfers for Caelex products (including Atlas)
Effective: 28 July 2026 · Caelex, Julian Polleschner, Berlin · Version 2.1
This statement describes where Caelex stores and processes client and application data, and which third-country transfers may occur. It is a technical and organisational description — not legal advice and not a substitute for a data processing agreement (DPA).
Earlier versions that implied a blanket “EU only — no transfer to the United States” claim were inaccurate. The two-tier presentation below separates client content (EU) from support services (in part third-country, with safeguards).
The German version at /legal/data-residency is the legally binding text. This English version is a convenience translation. In the event of conflict, the German text prevails.
1. Summary
Client content — the persistent database and file vault — is stored in the European Union (primarily Frankfurt am Main). That assurance applies to the production Caelex stack, to the extent described below.
Support services — including AI inference (EU Bedrock preferred; optional US fallback), embeddings, transactional email, error monitoring and analytics — may use third-country providers. Transfers rest, depending on the provider, on the EU–US Data Privacy Framework (DPF), Standard Contractual Clauses (SCCs, Module 3), adequacy decisions and, where contractually agreed, zero data retention.
2. Tier 1 — client content in the EU
Client content here means: mandate and organisation data, chats and related metadata, vault files and metadata, audit entries, and comparable production application data in the primary database and the file vault.
2.1 Persistent database (PostgreSQL via Neon)
- Region: AWS Europe Central 1 (Frankfurt am Main)
- Data: mandates, chats, parties, deadlines, notes, knowledge base, audit logs and other application data
- Backup: point-in-time recovery in the same regional cluster (vendor-limited, typically max. 30 days)
- Standby replicas: EU regions per Neon configuration
- Provider support access: rare, request-based; contractually covered by DPA/SCCs
2.2 File vault (Cloudflare R2)
- Region: EU jurisdiction (Frankfurt storage region preferred)
- Data: uploaded vault files (e.g. pleadings, decisions, contracts)
- Access: signed URLs with limited validity; no public buckets
- Encryption at rest: AES-256 per Cloudflare standard
2.3 Application hosting (Vercel)
- Primary region: Frankfurt (fra1) for dynamic requests involving client data, where configured on the platform
- Edge network: global; functions with client-data access are intended to be pinned to EU regions
- Logs: EU processing depending on plan and configuration
2.4 Rate limiting / caching (Upstash Redis)
- Region: EU-West (Dublin/Ireland), where configured
- Data: rate-limit counters, short-lived session/cache values — no mandate content
3. Tier 2 — support services with possible third-country exposure
The following categories may process data outside the EU. Details and current entries: /legal/sub-processors-en.
- AI inference (Anthropic Claude): Atlas chat is product-side EU-only (AWS Bedrock in the EU via AI Gateway, fail-closed); a US direct path exists only as an ops escape hatch (ATLAS_CHAT_ALLOW_US_FALLBACK), not as the default
- Embeddings for semantic search: may run via US providers (e.g. OpenAI via Gateway as a sub-sub-processor); typically short queries and text excerpts, not full vault deposit as the destination
- Transactional email (e.g. Resend): delivery metadata and message content during delivery
- Error and performance monitoring (e.g. Sentry): stack traces and diagnostics; PII scrubbing where configured — residual risk remains
- Web analytics / Speed Insights: after consent, where the banner applies; cookieless/aggregated metrics depending on configuration
- Payment processing (Stripe Payments Europe): separate controllership for payment data; partial processing outside the EU possible
4. Third-country transfers and Schrems II
For Tier-1 storage (database, vault, primary EU hosting, EU cache), no intended third-country transfer is contemplated.
For Tier-2 support services, Caelex relies — depending on the provider — on one or more of the following measures:
- Adequacy decision of the European Commission (where applicable, e.g. Canada)
- EU–US Data Privacy Framework for certified US providers
- EU Standard Contractual Clauses (SCCs), typically Module 3, in the provider contracts
- Transfer impact assessments (TIAs), where documented and available on request as a redacted summary
- Zero data retention / no training, where contractually and technically agreed with the provider
- PII scrubbing and data minimisation, where technically sensible
Instruments such as DPF, SCCs and zero data retention mitigate risks associated with US access powers; a residual risk remains. This statement does not replace a firm's internal data-protection or professional-law review.
5. Encryption and access (Atlas)
- Transport: TLS (modern on the provider side, typically TLS 1.2+)
- Application layer: sensitive text fields and chat contents may be encrypted per organisation with AES-256-GCM (key derivation: master secret + organisation ID)
- Tenant isolation: organisation- and membership-filtered queries; no product UI for Caelex staff to browse other firms' chats
- Break-glass: persons with production-database access and encryption secrets can technically decrypt in an emergency — we do not claim a zero-knowledge architecture
6. Evidence and audit
Upon reasoned request and under NDA where required, Caelex will make available, to the extent reasonably practicable:
- Indications of the region of Tier-1 services
- DPF certification status and SCC notes of sub-processors
- Provider trust-centre links
- SOC 2 / ISO reports of sub-processors, where released
- Caelex records of processing (Art. 30 GDPR) in appropriate form
7. Scope and changes
This statement applies to the production Caelex stack (marketing site and products including Atlas), unless a product-specific statement provides otherwise. Changes to routing, storage or sub-processor configuration are recorded here and in the sub-processor register.
Whether, and in what form, the assurances described here become part of a DPA with a particular firm is governed by the signed contract with the correct Caelex entity — not by this webpage alone.
Contact
Caelex, Julian Polleschner, Berlinlegal@caelex.euprivacy@caelex.euVersion 2.1 · 28 July 2026