Q

The answer box is free text. About forty characters wide.

The CTO typed "EU (Frankfurt)" and then stopped, because he had just remembered Sentry. Then he remembered the nightly backup job. Then he stopped typing altogether and messaged the one person who might know where the backup job writes to, who replied that she thought it was fine, probably.

Most EU data residency SaaS requirements are narrower than the sentence in the questionnaire suggests. The buyer is nearly always asking about personal data at rest and in normal processing, not about every byte your system touches, and the honest scope is usually four separate categories that get answered as one. Split them apart, answer the narrow question properly, and the work is frequently a quarter rather than a rearchitecture. Answer the broad question by promising everything sits in one region, and you have signed up for a project that eats a year.

What is the buyer actually asking?

Ask them, before you estimate anything. The question arrives as a template and the person who sent it usually did not write it.

There are three quite different things behind that spreadsheet cell. It can be a contractual requirement their legal team will not move on, common in financial services, healthcare and public sector procurement. It can be a policy position their security team holds and can grant exceptions to. Or it can be an inherited template question with nobody behind it, which is more often the case than founders expect, and which a short call resolves in ten minutes.

When it is real, what sits underneath is their own obligation as a controller. They have to name you as a processor, disclose your subprocessors to their own auditor, and document where personal data goes. Satisfying that usually means personal data at rest in the EU, a complete and accurate subprocessor list, and Standard Contractual Clauses covering any transfer outside it. That is a documentation and inventory problem with a small architecture component attached.

The legal weather is worth knowing because it explains the tone of the question. After the Court of Justice invalidated Privacy Shield in the Schrems II judgment of 16 July 2020, transfers to US providers needed SCCs plus a transfer impact assessment, and that is when this question started appearing in every European procurement pack. The EU-US Data Privacy Framework adequacy decision adopted on 10 July 2023 restored a lawful route for certified US recipients. Plenty of questionnaires still in circulation were written between those two dates and read as though a US subprocessor is automatically disqualifying. It is not, and pointing at the framework certification of a given vendor sometimes closes the item outright.

Then split the data. Personal data belonging to their users is the thing they care about. Product telemetry and aggregate metrics usually are not, provided they carry no identifiers. Backups are in scope and everyone forgets them. Application logs are in scope more often than teams believe, because somebody logged a full request body during an incident in 2022 and the line is still there.

What are my architecture options and what do they cost?

Three, and the gap between the first and the second is much wider than it looks on a diagram.

Most companies reading this need the first row. If you serve one regulatory jurisdiction and your customers are all inside it, running entirely in eu-central-1 or eu-west-1 answers the question completely, and the exercise is a migration rather than a redesign. Whether that is easy depends mostly on how your infrastructure is put together in the first place, and the hosting model you chose determines whether this is a Terraform variable or a fortnight of manual work.

Per-tenant routing earns its cost only when you have two jurisdictions with requirements that genuinely conflict, such as a US federal customer alongside an EU customer, or a Swiss or UK localisation demand stacked on top. The hidden bill is not the routing layer, which is a day of work at the edge. It is that you now operate two of everything, and schema migrations that run twice will eventually run once, on a Friday, leaving the two estates in different states with no alarm firing.

Teams buy the third row to satisfy a requirement from the first more often than any other error in this area, and I have watched it happen twice with the architecture diagram already drawn before anyone reread the question. Residency and availability both get solved with the phrase "multi-region", and they are different problems. Residency asks where the bytes rest. Availability asks what happens when a region fails, which is a question about replication lag, failover and the scaling decisions underneath your backend, and it costs an order of magnitude more. A buyer asking where data lives has not asked you to survive the loss of Frankfurt.

Why does this conversation always stall on backups?

Because the database gets moved by a person who is thinking about the database, and the backup job was written three years earlier by someone who has left.

The pattern is consistent enough to be predictable. Primary storage migrates to an EU region, the team updates the architecture diagram, everyone signs off. The nightly dump keeps writing to an S3 bucket created in us-east-1 in year one, and nothing anywhere raises an error, because S3 bucket names are a global namespace and the code only ever references the name. There is no region in the connection string to notice.

Go and check the adjacent paths this afternoon while you are in there. Automated RDS backups stay in the region of the instance, which is fine, but any cross-region snapshot copy configured for disaster recovery is a deliberate export and lands wherever it was pointed. An S3 Cross-Region Replication rule somebody added for durability does exactly what it says, quietly and continuously. The analytics warehouse that syncs nightly from production is a full copy of customer data sitting in whatever region the warehouse lives in, which is very often not the one on the diagram.

I have found some version of this three times in the last two years. The giveaway is usually that the backup bucket predates the region migration by two years or more, though on one of those occasions it was a genuinely recent job pointed at an old bucket, which took much longer to spot.

Who belongs on the subprocessor list?

Every external service your application sends customer data to. The list is a legal document under Article 28 of the GDPR, and it is assembled almost everywhere by a person going through the company card statement from memory.

That method finds the vendors with invoices. It misses the free tier, the trial that never got cancelled, and the SDK an engineer added in a sprint because the ticket needed a PDF generated. Those are the ones that hurt, because being wrong on this list is worse than the underlying transfer, since it turns a technical detail into a false statement in a signed agreement.

Build it from the system instead of from memory. Take the outbound domains your production environment actually resolved over a week, reconcile them against the dependency manifests, and reconcile that against the vendor list finance holds. The three sets never match on the first pass. Every gap is either a subprocessor you failed to disclose or a service nobody uses and nobody has cancelled.

The categories that go missing in almost every audit I have run are the small ones: transactional email, SMS, feature flags, geocoding, document generation, OCR, and whichever model provider somebody wired in last quarter.

Where is customer data leaking that is not on the architecture diagram?

In error tracking and in whatever model provider you call, and both hide for the same reason: they entered the system as an HTTP call inside a function rather than as a box on a diagram.

Sentry captures request context by default, and depending on configuration that can include headers, request bodies and user identifiers, which is personal data leaving your infrastructure on every exception. Sentry does offer an EU data region, and the detail that catches teams is that the region is chosen when the organisation is created, so moving an existing one is a support-assisted migration rather than a settings toggle. Product analytics has the same shape, and PostHog similarly runs an EU cloud you have to select up front.

Model providers are the other one. Prompts assembled from customer records go wherever that API terminates, most default to US processing, and none of it appears on a diagram because it entered the codebase as a single client library import. It also tends to be the newest integration in the stack and therefore the least likely to appear in the DPA you signed in 2024.

Both of these are cheap to fix if you catch them while choosing, and genuinely painful afterwards. That asymmetry is the argument for doing the outbound inventory before the questionnaire arrives rather than during.

For the large majority of B2B SaaS companies at this stage, a single EU region satisfies the requirement in full, and per-tenant routing is a project we would happily quote for and you should not buy. One jurisdiction means one region. Buy the routing layer when a second jurisdiction with a conflicting rule actually appears on a signed contract, rather than when somebody imagines it might.

Residency rarely arrives on its own, either. The same procurement pack usually carries the certification the same buyer will ask for next, and the two projects share about a third of their evidence.

Both of them sit inside the rest of the enterprise readiness list, which is worth reading in one go rather than discovering one question at a time.

Questions that come up in the procurement thread

Does GDPR require data to be stored in the EU? No. It restricts transfers outside the EEA unless a lawful mechanism covers them, which includes adequacy decisions and Standard Contractual Clauses. Residency is a common way buyers reduce their own assessment burden, not a blanket legal requirement.

A customer wants data stored in the EU. How long does that take? Two to four weeks if you run one stack on managed cloud services and the change is a region plus a data migration. Longer if you self-host, and considerably longer if any customer must stay outside the EU, because that turns it into a routing project.

Do we need a separate database per customer for data residency? Almost never. Per-tenant isolation and per-region isolation are different requirements, and residency is satisfied by the region the data sits in, whatever the tenancy model above it.

What goes on a subprocessor list for a SaaS startup? Every third party that processes customer personal data on your behalf, including hosting, error tracking, analytics, email and SMS delivery, support tooling and model providers. Build it from outbound network calls, since a list built from invoices misses the free tiers.

Can we use a US provider after Schrems II? Yes, where a lawful transfer mechanism applies. The EU-US Data Privacy Framework adequacy decision of July 2023 covers certified US recipients, and SCCs with a transfer impact assessment remain available for those who are not.

Before you answer question 47, get a list of every outbound domain your production environment resolved in the past 24 hours and compare it to the vendor list your finance team keeps. The gap between those two documents is the honest answer to the buyer's question, and it takes an afternoon to produce.