Eighteen months after go-live, a quality team asks their eQMS vendor to add a tenant for the new site — in a different region. The answer that comes back is not a settings change; it is a project quote with re-qualification in it, and nobody in the funding meeting remembers hearing "the region is chosen once" during evaluation. The scenario is a composite, but it is a common one, and it is the gap this post is about.
"Which regions do you support?" appears in almost every regulated software RFP. It is a reasonable question that produces a nearly useless answer, because a list of region names tells you nothing about what picking one from that list will do to you.
The better question is: what does choosing one lock in?
Data residency gets sold as a checkbox — a row in a comparison table, ticked or not ticked. It sits alongside the Part 11, Annex 11 and ALCOA+ controls covered in our guide to GxP cloud software requirements, but it behaves differently from all of them. It is an architecture decision with consequences that outlast most of the people who make it, and those consequences are worth understanding before you sign rather than at your first deployment review.
Compliance picks the region. Architecture lives with it.
Two different groups own the two halves of this decision, and they usually meet each other too late.
Your regulator, your customers' contracts, and your data protection obligations determine which region you can land in. That is a compliance question and it belongs to QA, legal and regulatory affairs. It is also the half that gets asked during evaluation, usually in a security questionnaire.
What that region then constrains — how the system feels to use, which platform capabilities you can have, what your recovery options look like — is an architecture question, and it is almost never asked during evaluation at all. It surfaces later, as a series of separate surprises that nobody connects back to a decision made in a procurement meeting.
One distinction is worth making explicit, because it is misquoted constantly: the GMP texts do not pick your region for you. EU GMP Annex 11 expects you to know where your regulated data is held, to have a written agreement with the hosting supplier, and to exercise oversight of that arrangement — it cares that the location is controlled and accounted for, not which location you chose. When a hard residency mandate exists, it comes from data-protection law, sovereignty rules, or your customers' contracts, not from the GMP chapter. Conflating the two produces requirements nobody actually set.
| Asked during evaluation | Surfaces after go-live |
|---|---|
| Which regions do you support? | The region cannot be changed without a migration project |
| Is our data stored in the EU? | The DR copy restores into a region nobody assessed |
| Do you have SCCs? | A managed service the roadmap needs is not in our region |
| What will screens feel like from our heaviest site? | Users in Asia batch their entries because every screen is slow |
The four constraints below are what the second half looks like in practice.
Lock-in 1: the choice is made once, at provisioning
This is the one that catches teams hardest, because software has trained everyone to expect that things are configurable.
Region is never a toggle: it is established when the tenant is created, and the data is laid down inside that boundary from the first record onward. Moving afterwards means relocating the database, the file storage and the application configuration together, and then re-establishing that the system still does what your validation package says it does.
For a validated GxP system there is no maintenance window that covers this — the move means an impact assessment, a change-control record, and re-qualification of whatever the change touches. Budget it as a project, never as a preference.
This is the same principle that makes per-tenant validation and sponsor segregation a design decision rather than a configuration one: once a tenant boundary is established, the things that cross it become projects.
The practical consequence: the region conversation has to happen before provisioning, with the people who understand the constraints in the room together. A region chosen in a security review — after the commercial decision has effectively been made — is a region chosen by whoever happened to be answering the questionnaire.
Lock-in 2: latency is felt by your users, not by your architects
Architects evaluate latency as a number. Users experience it as friction on every screen, every day.
A team in Singapore working on a tenant provisioned in Frankfurt will feel it on every page load. That can still be the correct decision — if your data-protection obligations or your customers' contracts require an EU region, it may be the only available one. But make the trade knowingly, and watch what it does downstream.
The quality angle is the part that gets missed. When a system is slow, people adapt. They batch their entries at the end of a shift. They keep working notes elsewhere and transcribe later. They record what happened after the fact rather than as the work happens.
None of that is a control failure. Every step of it is a reasonable human response to friction. But contemporaneous recording is one of the ALCOA+ attributes that makes a record trustworthy, and it degrades quietly through workarounds long before anyone files a deviation about it. Latency is a user-experience problem that becomes a quality problem if you let it run.
Lock-in 3: cloud regions are not feature-identical
Vendors present region lists as though every region is the same product in a different building. They are not.
The variance shows up in four places:
- Managed services arrive in different regions at different times — and some never arrive.
- Encryption options and database engine versions differ by region.
- Instance families and managed backup features differ by region.
- A platform capability that depends on a specific managed service exists only where that service does.
Which means: if your target architecture depends on a particular service, your real region list is shorter than the vendor's marketing page. Sometimes considerably shorter.
The question to ask is not "do you support region X" but "which of your platform capabilities are unavailable or delayed in region X". A vendor who has genuinely deployed into that region can answer specifically. A vendor who has only listed it will answer generally.
Lock-in 4: disaster recovery is downstream of this
Backup and restore get discussed as their own topic, usually months after the region decision, usually with a different set of people. They are not independent.
Where your backups can be stored, which secondary regions are available for replication, how quickly you can restore into a different location, whether your recovery target is even achievable — all of it is constrained by the primary region you already picked. Choosing a region with limited neighbours quietly narrows every recovery option you will have afterwards.
There is a regulatory dimension too. If your recovery plan involves restoring into a second region, that second location is part of your data residency story, and it needs the same scrutiny as the first. A DR plan that restores your regulated records somewhere your residency commitments do not cover is not a recovery plan. It is an incident waiting for a specific Tuesday.
The questions to put in your RFP
Four questions, all answerable in writing, all better asked during evaluation than after go-live:
- Which regions can you provision us in? Named specifically, not "we're multi-region".
- What exactly sits inside that boundary? Application tier, file storage and database — or only some of them? Partial answers here are the ones worth chasing, and the answer belongs in writing alongside the vendor's security and privacy detail.
- Which of your capabilities are unavailable or delayed in that region? A vendor who has actually deployed there can be specific.
- What is the backup and restore posture for that specific region? Including where restored data would land.
Score the answers. A vendor treating residency as an architecture decision will answer all four concretely. A vendor treating it as a checkbox will answer the first and get vague after that.
How region selection works in Complere
The four RFP questions above deserve our own answers, in writing, in the same shape we told you to demand:
- Where you can land. You select the region at provisioning — US, EU, India, GCC or ANZ — and the choice is fixed in the agreement, not in a settings screen.
- What sits inside the boundary. Application tier, file storage and your tenant's own database are provisioned together in the selected region — each tenant's records live in that tenant's own database, so the residency boundary and the isolation boundary are the same boundary.
- Who can reach it, and from where. Customer-side access is role-based with SSO; internal access to production is least-privilege, MFA-enforced, and logged. That is the written answer to the access half of the GDPR question above — ask every vendor for theirs.
- Where recovery lands. Backup copies stay inside the same regulatory jurisdiction: the DR copy region is documented per environment and holds backups only — never a live application or database. Restore procedures are exercised on a defined cadence and recorded.
Standard Contractual Clauses sit in the DPA where transfers apply. We have written separately about why shared-table tenancy makes the audit trail harder to defend, and about what a tenant of one means for CDMO quality systems. The per-tenant design is a deliberate choice with a price — it costs more to run and it is harder to operate. For regulated records we think that is the correct trade.
The four constraints above apply to us exactly as they apply to any other vendor. Region is chosen once. Latency is real. Service availability varies by region. DR follows the primary. We would rather you weighed those before go-live, which is the whole reason this page exists.
If residency is on your evaluation list, bring QA and IT to the same conversation and ask all four questions. The answers are more interesting than the region list.
