Data residency

Where the term comes from and where it is standardised

Data residency, Datenresidenz in German, comes from the contractual practice of cloud providers. It describes a commitment: in which country or region a customer's data is stored and processed. Large providers implement this commitment through the choice of a region, smaller ones through the location of their data centres.

The term does not appear in European data protection law. The General Data Protection Regulation does not prescribe a storage location. It links its territorial scope in Art. 3 to the establishment of the controller and to the location of the data subjects, and in Chapter V it regulates transfers to third countries. Accordingly, a server in Germany is neither required nor sufficient in itself.

The closest thing to it is an audit catalogue: the BSI's C5 criteria catalogue requires providers to disclose the general conditions of their service, including the subservice providers used, the geographical location of the data centres and how investigation requests from government agencies are handled. This is not a definition of data residency, but it is the most widespread way of making it verifiable.

What has a location and what the statement is worth

The question of location never has just one answer. In a platform that stores files and makes them searchable with AI, every single step has its own location, and these locations can differ.

• Primary storage, meaning the stored files themselves.
• The backups. They are often held in a different region from the original, which is precisely their purpose.
• The search index and the vector store. They contain text passages in plain text or as embeddings and must therefore be treated under data protection law in the same way as the documents themselves.
• Computing the embeddings and generating answers. Two separate steps that may be handled by different providers.
• Logs, error monitoring and telemetry. The providers involved here are also part of a complete location statement.
• Access by operations and support. A data centre in Frankfurt is of little help if remote maintenance is carried out from outside.

From this follows how to treat the statement in practice: a blanket commitment such as servers in Germany is not a verifiable statement unless it specifies which of these steps it applies to and which are excluded.

How providers implement data residency

• Choosing a region with a hyperscaler: the customer selects a European region. The data is held there, but the operator stays the same. This answers the question of location, not the question of jurisdiction.
• Sovereign offerings: operation by a local partner, sometimes with a separate company and its own staff. The set-ups vary widely; what matters is who has technical access.
• European providers with their own data centres: location and operator coincide. The review effort shifts to the subprocessors, who are involved nonetheless.
• In-house operation: the location is undisputed, but operation, updates and resilience are entirely the user's responsibility.
• Evidence through an attestation: a C5 report or an ISO 27001 certification substantiates audited information. It does not substantiate the same thing as a self-declaration, and that is the whole difference.

How Nexoria implements this

Nexoria states the location for each processing step, not as a blanket statement. The following table reproduces the information from the security overview and the processing register under Art. 30, including other services and integrations.

The rows of the table are short forms. The approved wording is authoritative, and it reads: Files, the knowledge index and semantic search run on dedicated servers in Germany. The website and dashboard are also hosted in Germany.

Document embeddings and semantic search run on servers in Germany, using models that Nexoria operates there itself. Answer generation by Nex uses Mistral AI. Internet searches run on our own search infrastructure on German servers. Search queries are not forwarded to Bing or Google.

File storage, the knowledge index and semantic search are operated on dedicated servers in Germany.

Core platform, other services and context

For the core platform, the following applies: Files, the knowledge index and semantic search run on dedicated servers in Germany. Answer generation by Nex uses Mistral AI. The following also applies: Other services and enabled integrations need to be considered separately: error monitoring via Sentry, based in the USA, without access to document content, payment processing via Stripe, as well as Microsoft Graph and Gmail when the email integration is enabled. For the optional VoiceBot, Telnyx (headquarters USA, EU branch Ireland) provides the telephone connection in Frankfurt; speech recognition and speech synthesis are handled by Voxtral from Mistral AI. The components and providers involved are listed under Security and privacy and in the processing register.

• This information is a self-declaration by Nexoria, without an external C5 attestation and without certification of the provider. The details are available under Security.
• A location is not a legal consequence. Which law an operator is subject to and who can demand access from it is a different question, see Data sovereignty.
• The table above reflects the status as of the date at the bottom of this page. Subprocessors change; the processing register under Art. 30 is always authoritative.
• ChatGPT (OpenAI), Claude (Anthropic), Gemini (Google) and Langdock can optionally be connected to Nexoria. Nexoria also works without these integrations. When connected, shared content is transferred to the respective provider. That provider's terms, processing locations and settings apply.

The difference between location and control is the heart of the matter. It is explained under Data sovereignty in detail, and the full processing overview is available under Security.