GDPR data residency controls need evidence, not promises

An EU region selector is useful, but it does not prove that personal data stays in that region. Buyers need to trace every copy and every person who can reach it: the live database, object storage, logs, backups, model-provider requests, telemetry, and support sessions. If one path leaves the promised boundary, the residency claim needs a transfer mechanism and evidence behind it.

That is why GDPR data residency controls should be evaluated as a chain of enforceable facts. A console screenshot shows a setting. It does not show what the setting covers, whether an administrator can override it, or what happens during an incident. Procurement should require a contract commitment, a system description, and a repeatable test for each material claim.

This article gives buyers a practical standard for AI app builders. It is not a substitute for advice from counsel on a particular transfer, jurisdiction, or risk profile.

Region pinning must define every data class

Region pinning is credible only when the supplier defines both the geographic boundary and the data covered by it. "EU hosting" can mean that the primary database sits in Frankfurt while prompts go to a model endpoint elsewhere, logs land in a global analytics service, and backups replicate across regions. The label says little until the supplier maps the data flow.

Ask for a data-location schedule that names the allowed country or set of countries for each data class. At minimum, the schedule should cover application records, uploaded files, prompts and model responses, embeddings, secrets, authentication data, logs, metrics, traces, crash reports, support attachments, and backups. It should also state whether "EU" means the EU, the wider EEA, or a supplier-defined group that includes other countries.

The control needs a clear scope. Does the selected region apply to the builder workspace, the generated application's production runtime, or both? Does it cover preview environments, branch deployments, temporary build workers, queues, caches, search indexes, content-delivery caches, and disaster-recovery copies? An app builder can keep the finished database in one region while processing source code, prompts, and build output somewhere else.

Require the supplier to identify exceptions in writing. A narrow exception can be manageable if the buyer understands the data, purpose, destination, retention period, and safeguard. An undefined "operational data may be processed globally" clause defeats the point because operational data often contains user identifiers, request paths, prompt fragments, and error payloads.

The best evidence combines three layers. The contract or order form names the committed region and change process. Architecture documentation maps each data class to a service and location. A technical record, such as an API response or deployment record, proves the setting for the buyer's own tenant.

For example, ask the supplier to produce a tenant record with a stable shape:

{
  "tenant_id": "acme-eu",
  "workspace_region": "eu-central",
  "runtime_region": "eu-central",
  "backup_regions": ["eu-central", "eu-west"],
  "support_access_policy": "eea_only",
  "effective_at": "2026-07-01T00:00:00Z"
}

The names will differ by product. The useful part is that the record distinguishes workspace, runtime, backup, and support policy instead of collapsing them into one green "EU" badge. Ask who can change these values, whether the buyer can detect a change, and what happens to existing copies after a move.

Backups need their own residency promise

Backups must follow an explicit location, retention, deletion, and restore policy. They are separate copies with separate infrastructure, access paths, and lifetimes. A supplier that only promises where "customer data at rest" resides may not have committed its backup vaults, snapshots, or disaster-recovery replicas to the same boundary.

Ask where every backup copy is stored, including database snapshots, object versions, replicated volumes, configuration backups, and provider-managed recovery copies. Require the supplier to state whether replication remains within one country, moves among EEA countries, or crosses into a third country. Availability architecture can justify a second region, but it does not make that second location irrelevant.

Retention answers need numbers and events. Procurement should obtain the normal backup retention period, any longer archival tier, the time until expired media becomes unrecoverable, and the treatment of backups after contract termination. "Deleted according to policy" is not testable. A schedule that says daily recovery points expire after a stated period and terminated tenant backups become inaccessible and age out on a stated timetable can be tested.

Logical deletion and physical expiry are different. A deleted record may remain inside an encrypted backup until that recovery point expires. That can be compatible with a documented retention design, but the supplier should explain how it prevents ordinary restoration from silently reactivating deleted data. Mature restore procedures replay deletion markers or require a post-restore reconciliation before the system returns to service.

Ask for one recent restore-test artifact with sensitive details removed. It should identify the source backup region, restore destination, people or service roles involved, approval record, and disposal of the restored copy. A generic disaster-recovery policy proves that somebody wrote a policy. A restore record proves that the operating process knows where the copy went.

Encryption does not erase a location question. It can reduce risk, especially when keys and administrative roles are separated, but a third-country backup can still be a transfer that needs a valid mechanism and assessment. Procurement should capture key ownership, key location, restore permissions, and whether provider personnel can obtain plaintext during recovery.

A subprocessor list must describe the actual chain

A useful subprocessor register connects each company to a purpose, data category, processing location, and transfer basis. A list of logos or legal names is an inventory, not an explanation of how the buyer's data moves. AI app builders often depend on cloud hosting, model providers, observability services, email delivery, authentication, customer support, and abuse monitoring. Each role can see a different slice of data.

GDPR Article 28 requires a processor to obtain prior specific or general written authorization before appointing another processor. Under general authorization, the processor must inform the controller of intended additions or replacements so the controller can object. Procurement should turn that rule into an operating requirement: a stable register, advance notice through a channel the buyer monitors, a defined notice period, and a stated objection process.

The register should answer five points for every subprocessor:

• the legal entity that receives or can access data
• the service and narrow processing purpose
• the personal-data categories and affected product features
• the countries of storage and remote access
• the applicable transfer mechanism and onward subprocessor path

Do not accept "cloud infrastructure" as the location for a model service. Ask whether prompts are sent to the model provider, whether the provider retains them, whether humans may review them, and whether the buyer can disable a provider or choose an endpoint. If the builder uses a mixture of models, the routing logic matters: a selected project region cannot control a request that the routing layer sends to an unapproved endpoint.

Notice of change must arrive before the change takes effect. A web page that can change without notification leaves procurement performing continuous manual surveillance. Contract language should say what information the notice contains and what happens after a justified objection. The supplier does not have to promise that its supply chain will never change, but the buyer needs time to assess a new transfer before data starts flowing.

Ask the supplier to reconcile three things during diligence: its public register, the DPA annex, and a current architecture or data-flow diagram. Names and locations often drift between documents after a vendor migration. A mismatch does not automatically mean the control has failed, but it does mean the buyer lacks a reliable record until the supplier resolves it.

The DPA should turn settings into obligations

The data processing agreement should state the processing instructions, security duties, deletion terms, audit rights, and subprocessor controls that apply to the purchased service. Product documentation can explain a feature, but the DPA and order documents determine what the supplier has promised to this buyer.

Article 28(3) of the GDPR lists the elements a controller-processor contract must cover, including subject matter and duration, nature and purpose, types of personal data, categories of data subjects, confidentiality, security assistance, deletion or return, and information needed to demonstrate compliance. The European Data Protection Board's Guidelines 07/2020 add a useful warning: a processing agreement should not merely restate the GDPR. It should contain specific information about how the requirements will be met and the level of security required.

That specificity matters for residency. Attach a schedule that identifies the buyer's selected regions, covered environments, approved remote-access countries, backup locations, and approved subprocessors. State that the supplier cannot materially widen those locations without the agreed notice or change procedure. If sales material says "EU only" but the DPA permits processing anywhere the supplier or its affiliates operate, the contract wins when the two conflict.

Review role allocation as well. For customer content used solely to provide the service under the buyer's instructions, the supplier will commonly act as processor. The supplier may claim a separate controller role for billing, account security, fraud prevention, or its own legal obligations. Do not reject every separate purpose on sight. Require the supplier to identify those purposes, data categories, legal basis, retention, and sharing instead of hiding them inside a broad right to use all service data.

AI training deserves an unambiguous clause. Ask whether the supplier or any model provider uses prompts, application data, source code, or output to train or improve general models. If the answer is no, put that restriction in the DPA or controlling product terms and extend it to subprocessors. If the answer depends on a setting, record its default, administrator, scope, and audit trail.

Audit language should produce usable evidence without demanding unrestricted access to a multi-tenant facility. Independent assurance reports, penetration-test summaries, security documentation, and targeted written responses may handle routine reviews. The buyer should retain a path to additional information or a proportionate audit when those materials do not resolve a material concern or an incident calls the control into question.

SCCs solve only the contractual part of a transfer

Standard Contractual Clauses can provide an Article 46 transfer tool, but signing them does not prove that every transfer is lawful or adequately protected. Buyers must select the correct module, complete the annexes, map onward transfers, and assess whether the clauses work in practice for the destination and data.

The European Commission's 2021 SCCs use four modules based on the parties' roles. A typical EEA customer sending data to a processor outside the EEA may use Module 2. A processor sending data to a subprocessor in a third country may need Module 3. The right choice depends on who exports, who imports, and whether the importer is already subject to the GDPR for that processing, so counsel should confirm the chain rather than pasting Module 2 into every agreement.

Completed annexes are evidence. They should name the parties, data subjects, data categories, sensitive data and safeguards, transfer frequency, purpose, retention, competent supervisory authority, technical and organizational measures, and subprocessors. Blank annexes, generic descriptions such as "all customer data," or a promise to fill details later leave the clauses detached from the actual service.

The EDPB's Recommendations 01/2020 set out a six-step approach: know the transfers, identify the transfer tool, assess the law or practice of the third country, adopt supplementary measures where needed, complete formal steps, and re-evaluate at appropriate intervals. The recommendations also treat remote access from a third country as a transfer. This is the point buyers miss when they focus on the storage map.

A transfer impact assessment should match the service rather than exist as a generic legal memo. It should identify the importer and destination, the data and people affected, access paths, applicable law and practices, government-access risk, onward transfers, and supplementary measures. Record who approved the assessment and what change would trigger a new review.

Encryption helps only when its design addresses the access risk. If a service must decrypt prompts for a support worker or model endpoint in the destination country, encryption in transit does not prevent that recipient from reading the data. Useful supplementary measures may instead include strict access segregation, pseudonymization where the recipient lacks the reidentification data, customer-controlled keys for workloads that can remain opaque, access logging, and contractual challenge or notification duties where lawful.

Adequacy can change the legal route for a destination, but it does not eliminate the need to know the destination or control the processor. Procurement should ask the supplier to identify which transfers rely on an adequacy decision and which rely on SCCs or another mechanism. The answer belongs in the transfer inventory, not in a blanket sentence that says the supplier "complies with GDPR."

Support access is processing where the operator sits

Remote support access from outside the EEA is a data transfer when the operator can view personal data, even if the database never leaves its EU region. Treat support location, authorization, and session evidence as residency controls. Storage location and human access location answer different questions.

Ask the supplier to separate routine support from privileged engineering access. A first-line agent may need account metadata but not production content. An on-call engineer may need temporary access during a severe incident. The control should give each role the least data and shortest time it needs, with stronger approval for production access.

Procurement should require named access locations or an enforceable region policy, not "global follow-the-sun support" with no country list. The supplier should disclose employees, affiliates, and contractors that can obtain production access, the countries from which they work, and the transfer mechanism for each non-EEA path. If emergency access can override a location restriction, document the trigger, approver, duration, and buyer notification.

Run a support-access test before approval or during a proof of concept:

1. Create a test tenant in the contracted EU region and add a unique synthetic customer record.
2. Open a support case that would normally require inspection, but do not paste the record into the ticket.
3. Ask the supplier to show the access request, approver, operator country, role granted, and expiry.
4. Confirm that the session log records the tenant, action, timestamp, and reason without copying sensitive content into the log.
5. Revoke access, then ask for evidence that the role or session can no longer reach the tenant.

Use synthetic data because a diligence test should not create a new exposure. The expected output is a small evidence pack: ticket identifier, approval event, temporary entitlement, session audit entries, and revocation event. If the supplier cannot run a live test in a shared service, ask for a recent redacted sample and a walkthrough tied to the documented control.

Break-glass access needs the same scrutiny. It may skip normal approval to restore service, but it should never skip identity, logging, expiry, and retrospective review. Ask how the supplier prevents staff from using emergency roles for ordinary debugging and how the buyer learns that such access occurred.

Do not demand screen recording by default. Recordings can create another rich copy of personal data and credentials. Structured audit events often give better evidence with less exposure: who accessed which tenant, from what country, under which ticket, using which role, for how long, and what categories of action they performed.

Evidence must survive changes and incidents

Procurement should collect evidence with an owner, date, scope, and refresh trigger. A polished answer during sales review goes stale when the supplier adds a model provider, moves its support team, changes its backup design, or launches a new region. Evidence management is part of the control, not filing work after the decision.

Use a control-to-evidence matrix in the approval record. Give each entry four fields: the control claim, contract evidence, technical evidence, and refresh trigger.

1. For approved workspace and runtime regions, keep the order form and location schedule beside the tenant region record and data flow map. Refresh them after a region or architecture change.
2. For backup locations, pair the backup and deletion schedule with a restore test record. Refresh them after a backup provider or disaster recovery change.
3. For the approved subprocessor chain, pair the DPA authorization clause with a register reconciled to the architecture. Review it after an addition or replacement notice.
4. For third country transfers, pair SCCs or an adequacy reference with the transfer inventory and assessment. Review them after a destination, law, or access change.
5. For support location, pair the support access schedule with approval, session, and revocation logs. Refresh them after a support country or role change.

Assign each row to a person on both sides. The supplier owner answers changes and evidence requests. The buyer owner decides whether a notice needs privacy, security, engineering, or legal review. A shared mailbox with no accountable reviewer is not an operating control.

Define notification thresholds. A new subprocessor that only sends service-status email may require a lighter review than a model provider receiving prompts. A new backup country, an expanded support location, a change in training use, or an override of the contracted region should stop new sensitive deployment until the buyer completes its assessment.

Incident evidence should show whether the residency boundary held. Require the supplier's incident process to preserve relevant region configuration, administrative changes, support access, export events, and subprocessor involvement. The DPA should set the notification duty and cooperation terms, while the incident runbook should identify the records that can answer where affected data was stored and viewed.

Certifications can support this file, but they do not replace service-specific answers. An assurance report may test access management and backup controls while saying nothing about the exact regions purchased by one tenant. Map the report's scope and exceptions to the control row, then fill the remaining gap with contract or tenant evidence.

Requirements should produce testable answers

Write residency requirements so a supplier can answer yes, no, or not applicable and attach a named artifact. Broad questions invite broad assurances. "Describe your approach to GDPR" will produce several polished pages and almost no approval evidence. A requirement tied to data, location, behavior, and proof exposes gaps quickly.

A workable requirement for hosting says: "The supplier shall store and process production customer content, prompts, generated source code, and authentication records only in the countries listed in Schedule A, except for the transfers listed in Schedule B." The schedules matter as much as the sentence. Schedule A defines the approved boundary. Schedule B forces the parties to name an exception instead of relying on a general right buried elsewhere.

Use separate requirements for separate controls. The following prompts work well in an RFP or security addendum:

• List every service component that does not inherit the tenant's selected region, with its data, country, purpose, and retention.
• Identify all countries from which personnel can access production content and attach the approval and logging standard for that access.
• State every backup and disaster-recovery location, retention period, deletion event, and permitted restore destination.
• Provide the current subprocessor register and mark which entities can receive prompts, source code, application records, or support attachments.
• Map each third-country transfer to an adequacy decision, SCC module, or other relied-on mechanism and provide the assessment owner and review date.

Avoid absolute wording that the architecture cannot sensibly meet. "No data ever leaves Germany" may accidentally prohibit delivery of an email to the buyer's own administrator abroad or an authorized user reading the application while travelling. Define whether the requirement covers supplier-controlled storage and processing, network transit, access by the buyer's users, or all of them. Precision makes the protection stronger because everyone can identify a violation.

Separate mandatory controls from preferences before issuing the questionnaire. If EU-only support access is mandatory, say so and reject a conflicting design. If it is a preference, evaluate a documented third-country path with its transfer tool and safeguards. Suppliers give unreliable answers when buyers label every question "critical" and later waive half of them during commercial negotiation.

Require evidence freshness. Architecture diagrams and subprocessor registers should carry an effective date. Contract annexes should identify the service version or offering they cover. Operational samples should come from the current control, not a retired system. Set an expiry or event-based review for evidence that can change, while permanent signed terms remain in the file until amended.

Finally, make conflicts explicit. The supplier should identify any response that depends on a premium tier, optional configuration, customer action, or planned feature. Procurement can then place the prerequisite in the order and hand it to the implementation owner. A control that depends on a setting fails if nobody knows who must turn the setting on.

Score the claim, not the sales language

A buyer can score residency readiness by asking whether every material data path has all three forms of proof: a binding promise, a current system description, and tenant-specific or recent operational evidence. Missing one layer creates a precise follow-up instead of a vague argument about whether the supplier is "GDPR compliant."

Use four decision states:

• Verified: the evidence agrees, covers the purchased service, and has a refresh process.
• Conditionally approved: a limited gap has an owner, deadline, and compensating control.
• Restricted: the service may handle only data that fits a defined lower-risk use case.
• Rejected: a material transfer or access path remains unknown, unbounded, or contractually permitted against the buyer's requirement.

This approach also prevents two bad procurement habits. The first is rejecting any global supplier merely because it has staff outside Europe, even when those staff cannot access the buyer's environment. The second is approving an "EU hosted" product without checking model routing or support access. Jurisdictional footprint is context. Actual data flows and enforceable controls decide the exposure.

Apply the score to the exact edition and configuration being purchased. Enterprise controls described in a security deck may not exist on a free or self-service tier. Region choice may apply only to hosted production, while previews or the builder workspace follow a default location. Record prerequisites, plan restrictions, and settings in the order form so the approved design matches what administrators can deploy.

Koder.ai can run applications on AWS infrastructure in different countries, but a buyer should still require the chosen country, covered components, and access paths to appear in the evidence pack. Product capability starts the conversation; procurement evidence closes it.

Do not accept a roadmap promise for a control required before personal data enters the service. A roadmap can support a future reassessment. Until the feature exists and the supplier can bind, describe, and demonstrate it, restrict the workload or choose another design.

The approval record should end with the residual risk, not a marketing verdict. Name any allowed cross-border access, the legal route, the data exposed, the supplementary measures, and the person who accepted it. That record gives privacy teams something they can defend and engineers a boundary they can actually operate.